Inside SSP's Account Abstraction Architecture

SSP is a self-custodial wallet built around 2-of-2 multisig. One key lives in the SSP Wallet browser extension, the second lives in the SSP Key mobile app, and no transaction settles unless both devices approve it. On EVM chains, SSP delivers that guarantee with ERC-4337 account abstraction: the wallet is a smart account whose validation logic accepts a single Schnorr-aggregated signature built from the two keys. This article walks through that architecture end to end — every component, the exact signing flow, and the security property it produces.

If account abstraction is new to you, start with Account Abstraction from First Principles and the focused ERC-4337 explainer. Here we assume you know roughly what a smart account and a UserOperation are, and we focus on how SSP wires them together.

The pieces SSP relies on

Before tracing the flow, it helps to name the components and what each one does:

• The smart account. On EVM chains your SSP wallet is not an EOA controlled by one key. It is an ERC-4337 smart account — a contract that holds your funds and contains its own validation logic. That logic is the heart of the design: it accepts a transaction only when the supplied signature matches the wallet's expected aggregate key.
• The two devices. Key 1 lives in the SSP Wallet browser extension. Key 2 lives in the SSP Key mobile app. Each device holds one share and produces one partial signature. Neither share can authorize anything on its own.
• The UserOperation. Instead of a normal transaction, the extension expresses your intent as a UserOperation — a structured object describing what the account should do and the signature that authorizes it.
• The bundler. A bundler picks the UserOperation out of the dedicated mempool, packs it into an actual on-chain transaction, and pays the base-layer gas to submit it.
• The EntryPoint. A single audited EntryPoint contract is the on-chain entry for every ERC-4337 operation. It calls into your smart account to run that account's validation logic, then triggers execution if validation passes.

A paymaster can optionally cover gas for a UserOperation; that is its own topic, covered in Gas Sponsorship and Paymasters Explained.

The exact signing flow

Here is what happens, step by step, when you send a transaction from SSP on an EVM chain:

  SSP Wallet extension (key 1)          SSP Key mobile app (key 2)
        |                                     |
        | 1. initiate tx                      |
        | 2. build UserOperation              |
        | 3. partial Schnorr sig  --- push -->| 4. approve
        |                                     | 5. partial Schnorr sig
        |                                     |
        |        6. aggregate (MuSig2 / secp256k1)
        |                v
        |        ONE Schnorr signature
        |                |
        v                v
  7. UserOperation --> 8. bundler --> 9. EntryPoint --> smart account
                                                  |
                                          validate aggregate sig
                                                  |
                                         valid? --> execute call

Reading it as prose:

1. You initiate a transaction in the SSP Wallet browser extension, which holds key 1.
2. The extension builds an ERC-4337 UserOperation describing the action.
3. Key 1 produces a partial Schnorr signature over that operation.
4. The request is pushed to the SSP Key mobile app (key 2) for approval.
5. Key 2 produces its own partial signature.
6. The two partials are aggregated, MuSig2-style over secp256k1, into one Schnorr signature.
7. The UserOperation, now carrying that single aggregated signature, is ready to send.
8. It goes to a bundler, which packs it into a transaction and pays the gas.
9. The bundler submits it to the EntryPoint contract, which invokes SSP's smart account. The account validates the single aggregated signature against the wallet's expected aggregate key and, if valid, executes the call.

Both devices are required to reach step 6, which is what makes this a true 2-of-2. Remove either partial signature and aggregation cannot produce a signature the contract will accept.

Why the chain only sees one signature

The detail that makes SSP's design elegant is the aggregation in step 6. The extension and the phone do not each attach a separate signature to the operation. Their two partial Schnorr signatures combine — MuSig2-style, over the same secp256k1 curve Ethereum already uses — into a single Schnorr signature. The smart account checks that one signature against one expected aggregate key.

This has two consequences worth dwelling on:

• The on-chain footprint stays small. The UserOperation carries one signature, not two. There is no list of signers to store or iterate, and no per-signer verification loop. The contract does the same amount of validation work it would for a single signer.
• The chain cannot tell it is multisig. What lands at the EntryPoint looks like an ordinary signed operation. The 2-of-2 enforcement happens in how the signature was produced — across two devices — not in some visibly multi-party structure on-chain. To an outside observer the wallet behaves like any other smart account.

That is the difference between SSP's approach and a naive multisig that posts N separate signatures and verifies each one. The mechanics of doing multisig this way on EVM are explored further in EVM Multisig the Account Abstraction Way.

What each device actually protects

It is worth being precise about the security property, because it is the whole point of the architecture.

• Neither key alone can move funds. Key 1 in the extension can build a UserOperation and sign its half, but a half-signature aggregates to nothing the contract will accept. Key 2 on the phone can approve and sign its half, but it cannot originate or complete a transfer by itself.
• Compromise of one device is not enough. An attacker who fully controls your browser extension still cannot spend, because they cannot produce key 2's partial signature without the phone. The reverse holds too. The threat model that a single-key EOA cannot survive — one leaked key, total loss — does not apply here.
• Approval is explicit and on a second screen. Because step 4 pushes the request to the SSP Key app, you see and approve the operation on a physically separate device before it can be aggregated and sent.

This is the same 2-of-2 property described in What Is 2-of-2 Multisig?, realized on EVM chains through account abstraction rather than a native multisig opcode.

The benefits, recapped

Pulling the threads together, the architecture buys SSP users a specific combination that is hard to get otherwise:

• Multisig security across every supported EVM chain. The same 2-of-2 design runs on Ethereum, Polygon, Base, BNB Smart Chain, and Avalanche, because ERC-4337 is a contract-level standard rather than a chain-specific feature.
• A small on-chain footprint. One aggregated signature means the smart account validates like a single signer, keeping verification lean.
• Single-signer-like UX. From your side it feels like approving a transaction on two devices, not assembling a committee. There are no co-signer addresses to manage and no separate multisig contract to configure per transfer.
• No protocol changes required. Because everything rides on ERC-4337, SSP gets all of this without waiting for base-layer account abstraction to ship.

A note on the audit

Security architecture is only as trustworthy as its review. SSP's smart contracts were audited by Halborn in 2025. An external audit does not make any system flawless, but it is a meaningful trust signal for the contract logic that enforces the 2-of-2 rule described above.

Where to go next

This article traced SSP's account abstraction end to end. To go deeper on the surrounding standard and concepts:

• Account Abstraction from First Principles — why EOAs are limiting and what account abstraction means.
• What Is Account Abstraction (ERC-4337)? — the standard in isolation, including the UserOperation, bundler, and EntryPoint roles.
• Gas Sponsorship and Paymasters Explained — how a paymaster can cover gas for a UserOperation.
• EVM Multisig the Account Abstraction Way — the multisig-on-EVM mechanics in more detail.

For the formal specification, see EIP-4337; for the broader effort, Ethereum's account abstraction roadmap tracks where it is heading. The takeaway: SSP turns the abstract promise of a programmable account into a concrete 2-of-2 wallet, where two devices produce one signature and the chain simply sees a valid operation.