EVM Multisig the Account Abstraction Way

Multisig is simple to describe — require more than one signature to move funds — but the way it is built differs sharply between blockchains. On Bitcoin, multisig is baked into the protocol. On Ethereum and other EVM chains, it is not, and that single fact shapes how every serious multisig wallet on Ethereum works, SSP included. This article explains why EVM multisig is different, gives a plain-language tour of the account-abstraction tooling that makes it possible, and shows exactly how SSP delivers a true 2-of-2 on Ethereum.

If you are arriving here from the start of the EVM series, Ethereum in SSP sets the foundation; this post is the deep dive into the security mechanics underneath it. The reading level here is a step up — intermediate — because doing the topic justice means touching ERC-4337 and signature aggregation honestly rather than hand-waving.

Why EVM multisig differs from Bitcoin multisig

The cleanest way to understand SSP on Ethereum is to first see why the Bitcoin approach cannot simply be copied over.

Bitcoin has native script multisig. The protocol includes an opcode that lets you lock funds behind a rule like "any two of these three public keys must sign." A multisig address on Bitcoin is just an address with that spending rule attached, and the network enforces it directly. SSP uses this on Bitcoin and the other UTXO chains through BIP-48 script multisig — two keys, one script, both signatures required. If this base model is new to you, what is 2-of-2 multisig is the place to start.

Ethereum has no equivalent. On an EVM chain there are only two kinds of accounts. The first is an EOA — an externally owned account, controlled by exactly one private key. One key, one signer, full stop; there is no native opcode to require two signatures on an EOA. The second is a smart-contract account, which has code instead of a single controlling key and does whatever that code says.

So on Ethereum, "multisig" has always meant a smart-contract wallet: a contract programmed to release funds only when its multi-signature rule is satisfied. This is the model that wallets such as Gnosis Safe / Safe pioneered, and it works well. The trade-off is that classic on-chain multisig contracts typically store each owner's signature and verify them one by one on-chain, which costs gas and grows with the number of signers. Account abstraction offers a cleaner path, and that is the path SSP takes.

A short, honest ERC-4337 primer

Account abstraction is the idea that your wallet should be a smart contract — a programmable account — rather than a plain key-pair. ERC-4337 is the standard that delivers this on Ethereum without changing the base protocol. You do not need to master it to use SSP, but a few terms make the rest of this article click. For the full treatment, read what is account abstraction (ERC-4337); here is the user-level map.

• Smart account. Your funds live in a smart-contract account whose code defines what counts as a valid transaction. Because it is code, the account can enforce custom rules — including "require a valid 2-of-2 signature."
• UserOperation. Instead of submitting a normal transaction, a smart account expresses its intent as a UserOperation — a structured request that says what it wants to do and carries the signature data that authorizes it.
• Bundler. A bundler is a service that collects UserOperations, wraps them into a real on-chain transaction, and submits them. It pays the gas up front and is reimbursed; it never gains the ability to move your funds.
• EntryPoint. A single, audited EntryPoint contract is the trusted on-chain coordinator. It receives bundled UserOperations and calls each smart account to validate and then execute its operation.
• Paymaster. An optional paymaster contract can sponsor gas or let fees be paid in a token rather than the native coin. It is optional and orthogonal to the multisig itself.

The key insight: with a smart account, the rule for "who may authorize a transaction" is software you control, not a fixed protocol behavior. That is exactly the freedom multisig needs on a chain that has no native multisig.

How SSP does 2-of-2 on EVM

SSP keeps the same promise on every chain it supports: two keys on two devices, and neither one alone can move your money. Key 1 lives in the SSP Wallet browser extension; key 2 lives in the SSP Key mobile app. You build and sign a transaction in the extension, then approve it on your phone via a push — both signatures are required.

On Bitcoin that guarantee comes from BIP-48 script multisig. On EVM chains SSP recreates it as an ERC-4337 smart account that verifies a Schnorr-aggregated 2-of-2 signature. Here is the idea at a high level, kept general where the exact contract internals are not the point.

Each of your two keys produces a partial signature over the transaction. Rather than sending both signatures to the chain separately, the two devices combine them — using MuSig2-style signature aggregation — into a single, compact signature. The smart account is programmed to accept a UserOperation only when that one aggregated signature verifies against the wallet's expected key. The chain therefore sees one ordinary-looking signature, yet that signature is mathematically impossible to produce without both keys taking part.

This design has real advantages over storing and checking N separate signatures on-chain:

• Smaller on-chain footprint. One aggregated signature is cheaper to verify and store than two independent ones, which tends to mean lower gas for the security you get.
• Identical UX to a single-signer wallet. Because the chain validates a single signature, your smart account behaves like any normal account from the network's point of view. Sending ETH, moving ERC-20 tokens, or interacting with DeFi all feel the same — the second signature happens quietly between your two devices.
• The same model everywhere. Schnorr and this aggregation approach build on well-studied cryptography over secp256k1, and the same smart-account design carries across the EVM chains SSP supports, including Ethereum, Polygon, Base, BNB Smart Chain, and Avalanche.

SSP's smart contracts behind this were audited by Halborn in 2025. For the deeper account-abstraction mechanics — how the EntryPoint, bundler, and validation step fit together — defer to the account abstraction (ERC-4337) explainer rather than treating any single contract detail here as canonical.

What this means for you as a user

The cryptography is interesting, but what matters day to day is the protection it buys.

• Both devices are required to move funds. A transaction is only valid once the extension and the SSP Key have each contributed their part. Possession of one device — or one key — is not enough.
• Losing one device is not losing your money. Because no single device can sign alone, a lost or wiped phone or a reinstalled browser does not hand anyone control of your funds. Restoring access is a separate topic with its own safeguards; recovery is covered in its own guides, not here.
• A single compromised key is not a single point of failure. If malware or phishing captures what is on one device, it still cannot produce the aggregated 2-of-2 signature the smart account demands. An attacker would need to compromise both your devices at once — a far higher bar than draining a one-key wallet.

These are general protections, not absolute guarantees; good seed-phrase hygiene and device security still matter. But the structural point stands: two independent factors must agree before value moves.

A neutral contrast with single-key EOA wallets

Most Ethereum wallets are single-key EOAs. They are simple and widely supported, and for many users they are fine. The trade-off is that one private key is the whole story: whoever holds it can move everything, so a single leaked seed phrase or one compromised machine can be terminal.

A smart-contract multisig changes that risk profile by requiring agreement between two keys rather than trusting one. Other smart-contract multisig wallets exist — Safe is a well-known example — and they solve the same core problem in their own way. SSP's particular choice is to deliver 2-of-2 through ERC-4337 with an aggregated Schnorr signature, so you get multisig security with the on-chain footprint and everyday feel of a single-signer account.

Where to go next

If you want the conceptual groundwork, read what is account abstraction (ERC-4337) and the foundational what is 2-of-2 multisig. To see how this fits the wider Ethereum picture in SSP, return to Ethereum in SSP. And for the standard itself, the canonical sources are the ERC-4337 specification and the Ethereum Foundation's account abstraction overview. The throughline is the same one that runs across every chain SSP supports: two keys, two devices, one signature — and you in control.