Between late December 2024 and the end of January 2025, SSP went through three independent security audits with Halborn, the firm behind security reviews for projects across the Web3 stack. The reviews covered SSP's three pillars — the wallet and key apps, the smart contracts behind ERC-4337 multisig, and the SDK that other developers can build against. All three reports are public.
This post is a short recap: what was in scope, what dates each audit ran, what Halborn found, and where you can read the reports yourself.
TL;DR
- Three audits in one window (Dec 23, 2024 – Jan 22, 2025).
- Scope: the SSP Wallet browser extension and SSP Key mobile app, the relay server they communicate through, the ERC-4337 + Schnorr smart contracts on Ethereum, and the public SDK.
- Findings: no critical or high issues. A small number of low and informational findings — most in unused or dead code paths — all addressed.
- Reports are public on Halborn's site and mirrored in the SSP repos.
Three audits, one window
The audits ran in parallel rather than back-to-back, which is unusual for a project of SSP's size. The reason is structural: the three components Halborn reviewed talk to each other constantly, and each one's threat model assumes specific guarantees from the other two. Auditing them in the same window gave Halborn a complete view of how a real SSP transaction flows from the browser, through the relay, into the smart contract, and back — instead of one slice at a time.
1. SSP Wallet, SSP Key & SSP Relay
Dates: December 30, 2024 – January 22, 2025 Public report: halborn.com — SSP Wallet, Relay & Key
This was the broadest engagement. Halborn looked at:
- The browser-extension client (key generation, encryption at rest, signing flows).
- The mobile companion app (Android and iOS) that holds the second key in SSP's 2-of-2 multisig setup.
- The relay server that brokers messages between the two — including the protocol shape and how it holds up to malicious or malformed traffic.
- The cryptographic primitives used end-to-end: how seeds are generated, how AES-GCM is applied, how signatures are produced and verified.
- The 2FA mechanisms layered on top.
If you've used SSP, almost everything you touch directly is in the scope of this audit.
2. Smart contracts: ERC-4337 + Schnorr
Dates: December 23, 2024 – January 3, 2025 Public report: halborn.com — Account Abstraction Schnorr MultiSig
The on-chain side of SSP — its account abstraction implementation on Ethereum and EVM-compatible chains — is a separate codebase with a different threat model. Smart-contract bugs are unforgiving: once a contract is deployed and holding value, you can't quietly patch it.
Halborn's scope here:
- The ERC-4337 EntryPoint integration and the SSP-specific account contracts.
- Schnorr signature aggregation and on-chain verification.
- Access control, ownership, and upgrade procedures.
- Gas-optimization patterns (including whether any optimization opened a footgun).
- Every external call the contracts make.
3. The SDK
Dates: January 2 – January 14, 2025 Public report: halborn.com — Schnorr Signatures SDK
Third parties don't only consume SSP through the wallet UI — they can integrate the underlying account-abstraction primitives directly via the SDK. That makes the SDK its own surface to harden: any sloppy default it ships becomes everyone-who-imports-it's problem.
Halborn looked at API ergonomics from a security angle, input validation, secure-logging practices, and whether the SDK's documentation steers integrators toward safe usage patterns instead of the common pitfalls.
What Halborn found
Across all three audits combined, the headline number is zero critical and zero high-severity findings. The reports do contain a small set of low-severity and informational items — most of them in unused branches or dead code paths that were already slated for removal. Every flagged item was addressed before the reports were published.
That last clause matters. "Audited" by itself is a weak claim if findings sit unfixed. The version of SSP you can install today is the one that includes the post-audit fixes.
What this means for you
A clean audit is a snapshot, not a forever-promise. New code lands, dependencies shift, and threat models evolve. But the 2025 reviews give you three things you didn't have before:
- Independent confirmation of the cryptography. SSP's security claim rests on real 2-of-2 multisig with each key on a separate device. Halborn looked at how the keys are generated, how they're stored, and how they're combined into signatures. The protocol matches the claim.
- A public threat model. The reports describe what was tested, not just what was found. If you're evaluating SSP for self-custody, you can read the same scope documents Halborn worked from.
- A maintenance bar. Future SSP releases will be measured against the post-audit baseline. If something regresses, the diff is visible.
How to verify yourself
You don't need to take this post's word for any of it. The full PDFs are linked above on Halborn's site, and the SSP team mirrors them in the project's documentation repository — including the audit-summary index in ssp-docs. Each PDF includes the methodology, the full finding list, severity ratings, and remediation status. They're written for a security-engineer reader but they're approachable.
If you'd rather start with the protocol itself before the audit, the introduction to 2-of-2 multisig is the right entry point.