Portefeuille utilisateur
Stocke les éléments de signature localement, présente les faits de la transaction, applique des contrôles de risque locaux et ne signe qu'après approbation de l'utilisateur.
L'autorité de signature reste entre les mains de la personne qui détient le portefeuille.
VelarumPay achemine et valide les demandes, mais ne transfère pas les clés privées vers un serveur et n'accorde pas aux marchands ni aux agents la capacité de signer les transactions utilisateur.
Limites essentielles
Conçu pour réduire l'autorité, pas pour la masquer.
La sécurité commence par définir ce que chaque participant peut et ne peut pas faire.
Platform API
Authentifie, valide, achemine, stocke l'état de la demande, applique des règles et synchronise le statut. Ne signe pas pour les utilisateurs.
Marchand ou agent
Crée des demandes et lit le statut autorisé dans le cadre d'un accès à portée limitée. Ne peut pas exporter des clés, approuver ni signer.
Contrôles
Organisé en couches autour du cycle de vie de la demande.
Aucun libellé unique ne rend un paiement sûr. Le produit combine conservation locale des clés, validation déterministe, connexions limitées et vérification explicite par l'utilisateur.
Conservation locale des clés
Les phrases de récupération, clés privées et éléments de signature dérivés restent sur l'appareil de l'utilisateur.
Approbation par défaut
Les paiements réels exigent que l'utilisateur du portefeuille vérifie et approuve avant la signature locale.
Connexions à portée limitée
Les connexions reçoivent des capacités limitées et explicites, et peuvent être révoquées.
Expiration
Les demandes et les invitations ont des limites de temps et ne peuvent pas rester indéfiniment exploitables en silence.
Idempotence
Les nouvelles tentatives de création sont conçues pour ne pas produire de demandes de paiement en double.
Historique des statuts
L'état de la demande et les événements aident au diagnostic sans donner aux observateurs un pouvoir de signature.
La vérité avant la présentation
Les faits de la chaîne ne peuvent pas être annulés par un texte marketing.
Un contexte de transaction peut expliquer un achat. Il ne peut pas modifier le réseau, l'actif, le montant, le destinataire, le contrat ou l'émetteur, le mémo ou les frais en cours d'examen.
01
Faits de paiement immuablesRéseau, actif, montant, destinataire, contrat ou émetteur, mémo et frais
02
Contexte de transaction séparéMotif, preuves, détails de commande et activité de l'agent
03
Risque visible de non-correspondanceDes affirmations contradictoires sont une raison de s'arrêter, pas de réinterpréter les faits
Limites du testnet officiel
L'architecture de sécurité n'est pas un certificat de publication.
La Official Testnet reste soumise à des tests d'appareil, des exercices de déploiement, un examen des licences, un examen juridique et des éléments de preuve de publication.
Utilisez uniquement des parcours de test et explicitement activésNe déduisez pas la sécurité en production, la disponibilité réglementaire, la prise en charge du réseau, la prise en charge des actifs ou l'achèvement d'un audit à partir de ce site web ou d'un exemple de protocole.
Pour les utilisateurs du portefeuille
- Ne partagez jamais une phrase de récupération ni une clé privée.
- Vérifiez le destinataire exact et le réseau.
- Rejetez les demandes inattendues ou urgentes.
- N'utilisez que les capacités indiquées comme prises en charge dans votre build.
Pour les intégrateurs
- Gardez les tokens hors des journaux client et du code source.
- Demandez les portées minimales nécessaires.
- Utilisez des chaînes de montants exacts et l'idempotence.
- Ne placez pas d'éléments privés ou de signature dans les métadonnées.
Vous avez trouvé un problème de sécurité ?
N'incluez pas de secrets ni de données utilisateur sensibles dans le premier message. Le processus de divulgation coordonnée reste une partie de la préparation du testnet officiel.