Between v1.29.0 on 2025-12-27 and v1.30.0 on 2026-01-02, SSP shipped two releases that look small in the changelog and large in the architecture diagram. v1.29.0 added request authentication — the wallet verifies the origin and integrity of every dApp request it receives. v1.30.0 added SSP Identity Signing — the wallet can prove its own identity to a remote service, not just sign a transaction. Together they harden the dApp-request surface that opened with WalletConnect, and they turn the original Identity feature into a first-class primitive that services can challenge.
Request authentication lands (v1.29.0)
A dApp request — sign this, approve that, switch to this chain — arrives at the wallet over a transport. With WalletConnect that transport is a relayed session; with the inpage provider it is a Chrome extension message. Each has at least one trust gap: the relay can be impersonated, the page can be a phishing clone, the message can be forged.
Request authentication closes those gaps from the wallet's side. Before SSP renders the confirmation screen, it verifies who is asking and what they are asking for. The origin claimed by the request is checked against the transport that delivered it. The payload is checked for integrity — the wallet does not sign a request that was modified in transit. And the request is checked against the session state the wallet already holds, so a replayed request from a different session does not slip through with someone else's pairing.
None of this changes what you see when a legitimate dApp asks you to sign. The confirmation screen looks the same. What changes is that the path between the dApp and that screen now has guardrails the wallet enforces itself, instead of trusting the transport to be honest about who it is delivering for.
Identity Signing follows (v1.30.0)
A week later, v1.30.0 went the other direction. Until then, an SSP Identity could sign messages — strings that prove the user controls a key. v1.30.0 adds the ability for the wallet to sign as an identity: a remote service can issue a challenge that names the SSP Identity it expects, and the wallet returns a signature that ties the response back to that identity in a way the service can verify.
The difference is subtle and load-bearing. Signing a message proves a key controls something. Identity signing proves a key controls a named identity — a stable handle the service has already associated with permissions, balances, or subscriptions. For services that need to know not just "is a user there" but "is this the same user who set this account up", identity signing closes the loop. v1.30.0 also polished popup request handling — less flicker, fewer dropped popups, faster return-to-focus.
Why this matters for dApps
The dApp threat model shares a small set of root causes. Origin spoofing — a malicious page pretends to be a trusted one. Replayed requests — a signed payload from one session is captured and submitted in another. Phishing surfaces — a request that looks legitimate is in fact bound for an attacker's contract.
Request authentication narrows all three because the wallet stops treating the transport as authoritative. The origin must match the transport, the payload must match what was sent, the session must match the one that was paired. Each check is small on its own; together they make the confirmation screen something the user can trust to reflect reality. Identity signing narrows a different attack — account takeover by re-pairing — because a service that asks the wallet to sign as a named identity turns "a wallet signed in" into a verifiable bind.
How it fits with WalletConnect
WalletConnect opened the door to thousands of dApps. v1.29.0 added the lock to that door, and v1.30.0 added the doorbell. Both land on the same surface: the request flow. Request authentication makes sure the request the wallet sees is the one the dApp sent. Identity signing makes sure the response the dApp sees is the one your wallet sent, signed by the identity the dApp was expecting. The pair turns a WalletConnect session from "two endpoints exchanging blobs" into "two endpoints that can each prove to the other who they are".
From Identity to Identity-Signing
The original SSP Identity feature gave the wallet a stable identity surface — an address derived for messaging and proofs, separate from the transactional addresses you spend from. That was the introduction. v1.30.0 is the follow-up: the same identity, now usable as a credential a service can ask for by name and verify on its side.
This is what it looks like for a wallet to become a first-class identity primitive instead of just a key-holder. v1.29.0 makes the inputs trustworthy; v1.30.0 makes the outputs verifiable. Most users will never see the difference directly. The dApps and services that integrate against this surface, though, will find that SSP can now prove who it is and verify who is asking — every time.