On 2025-01-16, SSP Wallet v1.9.0 closes out a multi-week security review with Halborn of SSP's Account Abstraction Solidity contracts — the Factory and Account Implementation behind every Ethereum and Sepolia address. The audit came back clean on the things that matter, with only three Informational and two Low findings, all in unused or dead code. We still chose to address every one of them, redeploy the contracts, and ship the cleaner versions in v1.9.0. That redeploy is a breaking change for Ethereum and Sepolia users: your deterministic address on those two chains will change after upgrading.
TL;DR
- Halborn audited the Solidity portion of SSP's Account Abstraction: the Factory and Account Implementation contracts.
- Findings: 3 Informational, 2 Low, 0 Medium, 0 High. All in unused or dead code paths. Previously deployed contracts were and remain secure.
- We redeployed anyway to keep the codebase entirely clean — new Factory + Account Implementation contracts ship in v1.9.0.
- Breaking change: Ethereum and Sepolia addresses change after upgrade. Move funds before upgrading, or contact SSP support for a migration guide.
- UTXO chains — Bitcoin, Zcash, Bitcoin Cash, Flux — are unaffected.
What Halborn audited
The scope was the Solidity side of the Schnorr-multisig ERC-4337 contracts we shipped in v1.6.0 and have iterated on since. Concretely: the @runonflux/account-abstraction repository — the Factory contract that deterministically deploys an account when a user first transacts, and the Account Implementation contract that defines how that account validates UserOperations, checks Schnorr signatures, and follows ERC-4337's bundler-and-EntryPoint flow.
Halborn's technical team ran the full battery of tests they reserve for production smart contracts. The repository, in their words, is strong, respects the ERC-4337 recommendations, and implements Schnorr cleanly. That conclusion matters because the Schnorr implementation is the part of the design with the smallest body of prior art — every other piece of the AA stack has been audited many times across the industry, but aggregated Schnorr signatures inside an ERC-4337 validator are something we built ourselves.
What they found
The report contains 3 Informational and 2 Low priority findings — no Medium, no High, no Critical. You can read the full report at halborn.com/audits/influx-technologies/account-abstraction-schnorr-multisig.
Every finding sits in code that was either unused on the live contracts or part of a path that didn't execute against real user funds — defensive scaffolding, leftover branches from an earlier iteration, that sort of thing. None of them describe a way for an attacker to take funds, forge a signature, or break an account. The deployed contracts on Ethereum mainnet remained fully secure throughout the audit window and afterwards.
Why we redeployed anyway
Two reasons. First, a clean codebase is its own form of security. Dead code that compiles into a deployed contract is dead code that future auditors, integrators, and contributors have to reason about. Cutting it out reduces the surface that any future review needs to look at — fewer branches, fewer assumptions, fewer ways to mis-read the contract.
Second, when you have the chance to ship the version that addresses every finding instead of the version that defers them, you take it. So we did. v1.9.0 ships against newly deployed Factory and Account Implementation contracts that incorporate every Halborn recommendation. The @runonflux/account-abstraction repository's stable branch is now main (npm ^1.1.0); the master branch and npm ~1.0.0 are kept available for anyone wishing to stay on the older deployed contracts.
The BREAKING CHANGE for Ethereum and Sepolia users
Because the Factory is what deterministically derives your account address from your public keys, redeploying the Factory means the same keys derive a different address. For users with funds on Ethereum mainnet or Sepolia, that is the practical impact of v1.9.0: after upgrading, the address SSP shows you for Ethereum or Sepolia is a new one. Any ETH or ERC-20 sitting at the old address won't move on its own.
There are two ways to handle this safely. The straightforward path is to move your funds off the old address before you upgrade — send them out to another wallet or exchange, then upgrade, then send them to your new address. The other path, for users who've already upgraded or who have larger or more complex positions, is to contact SSP support for a migration guide so we can walk you through retrieving the old funds with the old contracts.
UTXO chains are not affected. Bitcoin, Zcash, Bitcoin Cash, and Flux addresses derive from your keys without going through an EVM contract, so v1.9.0 does not change those addresses. Only Ethereum and Sepolia are involved.
More to come
This article covers the AA contracts audit specifically, on its release day. The bigger story — Halborn's full set of reviews across the SSP wallet, the contracts, and the SDK — is laid out in Inside SSP's 2025 Halborn audits, which puts this audit in context with the other two.
Source: SSP Wallet v1.9.0 release notes.