On February 11, 2024, SSP Connect graduated from a viewer-and-identity protocol into a payment protocol. The v1.1.0 release of SSP Wallet adds a pay method to SSP Connect, letting any dApp or website request a real on-chain payment from an SSP user without re-implementing wallet plumbing. The shape of the request is deliberately small: three parameters, one of which is intentionally a string.
TL;DR
- SSP Connect now exposes a
payaction alongside its existing identity flows. - A payment request takes exactly three parameters:
chain,address, andamount. amountis a string on purpose — to preserve decimal precision across the wire.- The signing flow still runs end-to-end on the user's two devices; the dApp never sees keys.
- Integrators should format
amountwithBigNumber.toFixed()(or an equivalent) before sending.
What SSP Connect is
SSP Connect is the bridge between an SSP Wallet user and the outside world. It is the same lightweight session protocol introduced alongside the SSP Wallet launch, where the wallet itself is a true 2-of-2 multisig split between a browser extension and a phone-resident SSP Key. Before this release, Connect was mostly used for read-only requests: pairing a session, sharing an address, verifying that a given user controls a given account. Crucially, secrets never leave the user's two devices; Connect simply carries intents and responses between them and the relying party.
What the pay action does
The pay method extends Connect from "tell me who you are" into "let me ask you for a payment". A dApp constructs a pay request, hands it to Connect, and the user is prompted on their wallet UI to approve, edit, or reject the request. If the user approves, the multisig signing flow runs as it always does — extension prepares, phone co-signs — and the resulting transaction is broadcast. The dApp gets a clean confirmation or a clean rejection, and it never touches a private key.
The three parameters
chain is a string naming the SSP-supported asset to pay in, for example 'flux'. It is mandatory. The value matches the asset identifiers SSP already uses internally, so integrators do not have to learn a new naming scheme.
address is the destination of the payment — a plain string in whatever address format the chosen chain expects. It is also mandatory. SSP performs the usual format and checksum validation on the receiving end before showing the request to the user.
amount is the value to send, expressed in that chain's main unit. For example, '4.56' means 4.56 FLUX, not 4.56 of the smallest indivisible unit. It is mandatory and, importantly, it is typed as a string rather than a number.
Why "amount" is a string
JavaScript numbers are IEEE-754 doubles, which is exactly the wrong representation for money. 0.1 + 0.2 is not 0.3, and 18-decimal token amounts simply do not fit in a double without silent rounding. Forcing amount to be a string side-steps the entire class of precision bugs at the protocol boundary: whatever the dApp computed internally — typically with a big-decimal library — survives the trip to the wallet unchanged. The release notes recommend formatting the value with BigNumber.toFixed() before sending, which is the standard way to render a big-decimal as an exact, non-scientific-notation string.
What to do next
If you maintain a dApp or a website that currently uses SSP Connect for identity, the upgrade path is short: keep your existing session, add a pay request where you previously would have prompted the user to copy an address. Validate chain against the list of SSP-supported assets you actually want to accept, validate address client-side so the user sees errors before they reach the wallet, and always format amount through your big-decimal library's toFixed() (or equivalent) so the string you send is exactly what you computed. The wallet handles the rest — confirmation, signing, broadcast — without ever exposing keys to your origin.
Source: SSP Wallet v1.1.0 release notes.