SSP Wallet v1.15.0 widens the door for dApps. The release expands the SSP Wallet API into a general-purpose surface that any website can talk to, asking the wallet for the information it needs and prompting the user for the actions it can offer — all without ever touching keys. What started as a single pay action inside SSP Connect now grows into a real integration platform, with a public spec at SSP_Wallet_API.md that developers can build against today.
From Pay to a full API
The first version of SSP Connect, shipped with v1.1.0, added exactly one outbound action: pay. A dApp could request a payment on a given chain, to a given address, for a given amount, and the wallet handled the signing flow on the user's two devices. That was deliberately scoped. It proved the boundary — wallet owns the signing, dApp owns the request — and gave us something to harden in the wild.
v1.15.0 takes the next step. The wallet now exposes a broader API that lets a website pair with an SSP user, read selective information that the user explicitly approves, and request actions the wallet supports. The model is still the same: the wallet is the authority, the website is a caller, and the user is the one who clicks the green button. What's new is that the surface is no longer a single function — it is a documented interface.
What the API exposes
The expanded API focuses on the things that almost every dApp needs to know before it can be useful to a wallet user, and on the actions the wallet can offer without compromising its security model.
On the read side, the API lets a website ask the wallet for information like the connected user's account identifier, the chains the wallet supports, and the addresses the user agrees to share with this particular site. Crucially, "ask" never means "automatically receive." Every read request triggers a user prompt inside the wallet UI, and the user can grant, scope down, or refuse it.
On the action side, the API keeps the same boundary as the original pay flow. The wallet can be asked to construct, review, and co-sign a transaction; the dApp never sees the signing material. Multisig is non-negotiable: every spend that touches funds is still signed by both halves of the SSP setup — the browser extension and the SSP Key on the user's phone — exactly as it would be for a manually initiated send. There is no API call that lets a website bypass that flow, and there is no "session approval" that turns the wallet into a hot rubber stamp.
Full method signatures, request shapes, and event semantics live in the wallet's SSP_Wallet_API.md spec, which is the source of truth for integrators.
Security model
A wallet API is only as good as its security model, so it is worth being explicit about what v1.15.0 enforces.
Origin checks. Every API call carries the origin of the requesting page, and the wallet treats that origin as the identity of the caller. Permissions are scoped per origin; a permission granted to one site is not a permission granted to its neighbor on the same browser. If a malicious page tries to reuse another site's session, the request is rejected before it ever reaches the user.
Explicit user approval. Reads and actions both require an in-wallet prompt the first time they happen, and material actions — anything that signs or spends — require a fresh prompt every time. The wallet does not silently auto-approve transactions, even for sites the user has connected to before. The dApp does not get to choose what is "trusted enough."
Signing stays local. The thing that has always made SSP an SSP wallet — that signing happens locally on two devices and that no remote service ever holds an unsigned-but-spendable key — is unchanged. The API gives a website a structured way to ask the wallet for a signature; it does not give a website any way to obtain one without the user, or to skip a key.
The multisig invariant is the same invariant the wallet was launched with on day one. The API is a polite knocker on the door, not a back-door key.
Building against it
The spec at SSP_Wallet_API.md is the canonical place to start. It describes the available methods, the events the wallet emits when state changes, and the error codes a dApp should expect. Pair it with the v1.15.0 release notes on GitHub for the full context of what shipped.
For developers from other wallet ecosystems, the model is familiar: session-based pairing, origin-keyed permissions, event-driven state. What is different is what is missing — no "approve all future transactions" trapdoor, and no key material that can leave the user's two devices.
What's next for SSP Connect
SSP Connect is now less a single protocol and more an umbrella for the wallet's outward-facing surface. Expect more documented methods, more events, and tighter examples for the most common integration shapes. The first goal is not to be the biggest API in crypto; it is to be the most boring one — predictable, well-scoped, and conservative about what a website can ask the wallet to do.
If you are building something and want to talk to SSP, the spec is the door.