
SSP Wallet v2.1.2 and SSP Key v2.1.1: Ethereum Enterprise Signing Restored
Two releases today, and they go together: SSP Wallet v2.1.2 and SSP Key v2.1.1. Update both.
They are bug fixes, but one of them is not a small one. Ethereum enterprise vault signing has been broken since v2.0.0, and this pair is what fixes it.
The message that looked like an attack
If you tried to approve an Ethereum vault transaction on SSP Key at any point since v2.0.0, you saw this:
the transaction does not match what was shown for approval
That is, by design, one of the most alarming things SSP Key can tell you. It is the message that appears when the device recomputes a transaction and gets a different answer from what it was asked to sign — exactly what you would expect to see if something in the chain between the wallet and your phone had tampered with the payment.
Nothing had been tampered with. The check itself was broken.
SSP Key verifies a vault transaction by independently recomputing its hash on the device and comparing that against what it was shown. Recomputing an EVM transaction hash requires the chain id — the number that distinguishes Ethereum from every other EVM network and stops a signature from one chain being replayed on another. The Ethereum and Sepolia configurations were missing it. So the recomputation failed before it had anything to compare, and the verification reported a mismatch it had never actually tested.
The fix adds the missing chain id, and a test now guards every EVM chain against the same gap so a future network cannot be added without one.
It is worth naming what this was: a safety check failing closed. That is the correct direction for a bug of this kind to fail in — the Key refused to sign rather than signing something it could not verify — but it is still a bug, and it made Ethereum enterprise vaults unusable for months.
Two more problems, hiding behind the first
The chain id was the cause. What made it worse was what happened next, and it is a good illustration of how bugs compound.
Every rejected attempt burned a nonce. SSP Key reserves a signing nonce before it verifies a request. Because verification was failing, each attempt consumed a nonce and produced nothing — and once the pool ran down, the retry failed with a different error entirely: "nonces need to be synced". A user chasing the first bug would hit a second one that looked unrelated. The nonce is now consumed only after verification passes, immediately before the signature is produced.
And syncing — the obvious remedy — could make it worse. Force sync used to purge every nonce on the relay before refilling. If the refill then failed, you were left with nothing to sign with at all. The wallet-side wipe also discarded nonces that pending proposals had already reserved, which made those proposals permanently unsignable. Sync now reconciles the relay against the nonces the wallet and Key actually hold, and tops up only what is missing. The Sync Nonces dialog also reports a wallet-side failure honestly, instead of showing success on the strength of the Key's acknowledgement alone.
So: a broken check produced a frightening error, the retries quietly drained a resource, and the documented fix for that resource could destroy pending work. Any one of those is a bug. Together they are the reason this needed two coordinated releases rather than a patch.
Also fixed
A sent transaction is now shown as sent. After a transfer was signed, broadcast and confirmed, a failed status notification to the relay could still surface as Request failed with status code 401 — an error message about a transaction that had actually succeeded. The confirmation screen with the transaction id now always appears, the relay call retries once with fresh authentication, and a failure there is downgraded to an informational notice. Your money had moved; only the reporting was wrong.
Signatures register even if the tab closes. The wallet's signing request now carries the organisation, vault and proposal references, so the relay can attach your signature to the proposal directly. Previously, if the enterprise app page that requested the signature was gone by the time you approved on your phone, the response had nowhere to land.
Fetching pending requests can no longer hang. The relay lookup for pending actions is now bounded by a timeout.
What you should do
Update both applications. These fixes are split across the wallet and the Key, and the Ethereum signing repair needs both halves — updating one alone will not restore it.
Browser extensions update themselves, so the wallet side is likely already current. SSP Key is a mobile app and may need a nudge from your app store.
If you have an Ethereum enterprise vault with proposals that would not sign, they should sign now. If you have proposals that became permanently stuck because a force sync discarded their reserved nonces, those will need to be recreated — the fix prevents it happening again but cannot recover a nonce that was already thrown away.
No keys are affected, nothing needs reconfiguring, and no funds were ever at risk from any of this: a verification that fails closed does not sign, and moving funds needs both devices regardless.
For the previous release and what it fixed, see SSP Wallet v2.1.1.


