Le 11 février 2024, SSP Connect a cessé d'être un simple protocole de consultation et d'identité pour devenir aussi un protocole de paiement. La version v1.1.0 de SSP Wallet ajoute une méthode pay à SSP Connect, permettant à n'importe quelle dApp ou n'importe quel site web de demander un paiement on-chain réel à un utilisateur SSP sans réimplémenter la tuyauterie du portefeuille. La forme de la requête est délibérément réduite : trois paramètres, dont l'un est intentionnellement une chaîne.
TL;DR
- SSP Connect expose désormais une action
payaux côtés de ses flux d'identité existants. - Une demande de paiement prend exactement trois paramètres :
chain,addressetamount. amountest une chaîne par choix de conception, afin de préserver la précision décimale sur le fil.- Le flux de signature continue de tourner de bout en bout sur les deux appareils de l'utilisateur ; la dApp ne voit jamais de clés.
- Les intégrateurs devraient formater
amountavecBigNumber.toFixed()(ou équivalent) avant l'envoi.
Qu'est-ce que SSP Connect
SSP Connect est le pont entre un utilisateur de SSP Wallet et le monde extérieur. C'est le même protocole de session léger introduit en même temps que le lancement de SSP Wallet, où le portefeuille lui-même est un véritable multisig 2-sur-2 réparti entre une extension de navigateur et une SSP Key résidant sur le téléphone. Avant cette version, Connect servait surtout à des requêtes en lecture seule : appairer une session, partager une adresse, vérifier qu'un utilisateur donné contrôle un compte donné. Point essentiel : les secrets ne quittent jamais les deux appareils de l'utilisateur ; Connect ne fait que transporter intentions et réponses entre ceux-ci et la partie qui fait confiance.
Ce que fait l'action pay
La méthode pay étend Connect de « dis-moi qui tu es » à « laisse-moi te demander un paiement ». Une dApp construit une requête pay, la confie à Connect, et l'utilisateur est invité dans l'interface de son portefeuille à approuver, modifier ou rejeter la demande. Si l'utilisateur approuve, le flux de signature multisig s'exécute comme toujours — l'extension prépare, le téléphone co-signe — et la transaction qui en résulte est diffusée. La dApp reçoit une confirmation propre ou un rejet propre, et ne touche jamais à une clé privée.
Les trois paramètres
chain est une chaîne nommant l'actif supporté par SSP avec lequel payer, par exemple 'flux'. Il est obligatoire. La valeur correspond aux identifiants d'actifs que SSP utilise déjà en interne, de sorte que les intégrateurs n'ont pas à apprendre un nouveau schéma de nommage.
address est la destination du paiement — une simple chaîne dans le format d'adresse qu'attend la chaîne choisie. Il est lui aussi obligatoire. SSP effectue la validation habituelle de format et de checksum côté réception avant de présenter la demande à l'utilisateur.
amount est la valeur à envoyer, exprimée dans l'unité principale de cette chaîne. Par exemple, '4.56' signifie 4,56 FLUX, et non 4,56 de la plus petite unité indivisible. Il est obligatoire et, surtout, il est typé comme chaîne plutôt que comme nombre.
Pourquoi « amount » est une chaîne
Les nombres en JavaScript sont des doubles IEEE-754, ce qui est exactement la mauvaise représentation pour de l'argent. 0.1 + 0.2 ne vaut pas 0.3, et les montants de jetons à 18 décimales ne tiennent simplement pas dans un double sans arrondi silencieux. Forcer amount à être une chaîne évite entièrement cette classe de bugs de précision à la frontière du protocole : ce que la dApp a calculé en interne — typiquement avec une bibliothèque big-decimal — survit intact jusqu'au portefeuille. Les notes de version recommandent de formater la valeur avec BigNumber.toFixed() avant l'envoi, ce qui est la manière standard de rendre un big-decimal sous forme de chaîne exacte, sans notation scientifique.
Que faire ensuite
Si vous maintenez une dApp ou un site web qui utilise déjà SSP Connect pour l'identité, le chemin de mise à jour est court : conservez votre session existante, ajoutez une requête pay là où, auparavant, vous auriez invité l'utilisateur à copier une adresse. Validez chain par rapport à la liste des actifs supportés par SSP que vous voulez réellement accepter, validez address côté client afin que l'utilisateur voie les erreurs avant d'atteindre le portefeuille, et formatez toujours amount via le toFixed() (ou équivalent) de votre bibliothèque big-decimal pour que la chaîne envoyée soit exactement celle que vous avez calculée. Le portefeuille s'occupe du reste — confirmation, signature, diffusion — sans jamais exposer de clés à votre origine.
Source : Notes de version SSP Wallet v1.1.0.