Which chain works on which network, what each security tier actually is, the contract addresses you can check yourself, and the parts that are not proven yet. No claim on this page is softer than the code behind it.
Base and Arbitrum One have mainnet deployments at byte-identical addresses. Everything else is a testnet, and the table says which.
Standard accounts deployed 2026-06-16, Protected accounts 2026-06-18. Real funds, real chain. The maximum tier is testnet-only, so a mainnet account uses the standard tier.
Deployed 2026-07-04 from the same pinned tag, with runtime bytecode verified byte-identical to Base and the same public key resolving to the same account address on both.
The wallet's default network, so a new install starts on play money. This is where the maximum tier actually exists.
Devnet only: the Falcon program is deployed to devnet and nowhere else. Falcon rather than SPHINCS+ because a SPHINCS+ signature does not fit inside a Solana transaction.
Mutinynet signet only, and a different guarantee from the smart-account chains. Bitcoin cannot verify a post-quantum signature, so what ships is key hiding through P2WSH plus address rotation: the public key is never exposed while funds sit still. Spending is still classical ECDSA. This protects coins at rest, not in transit, and only while you do not reuse an address.
Both are post-quantum. They differ in what they assume and what they cost to verify on-chain.
keccak-SPHINCS+, a SPHINCS+ variant
Hash-based, with no lattice or elliptic-curve assumption anywhere in it. It is the SPHINCS+ design behind NIST's SLH-DSA (FIPS 205), but with keccak in place of SHAKE and its own parameter set, which is what makes an on-chain verify affordable at roughly 0.66M gas for a 5,936-byte signature. Those substitutions put it outside FIPS 205 compliance. That is a deliberate trade for EVM cost, not a certified configuration, and it has not been audited.
The default, and the right choice for almost everyone.
Falcon-1024 (FN-DSA, FIPS 206 draft)
A lattice scheme with a higher security category and far smaller signatures, at a much higher verify cost. FIPS 206 is still a draft rather than a finished standard. Testnet only on EVM today, so it is not available on mainnet.
Cold storage you expect to touch rarely.
Your account is a smart contract that checks a post-quantum signature on-chain for every operation. A classical key still carries the transaction and pays gas, and that is all it can do. Stealing it does not move funds. The one exception is deliberate: on a Protected account, a recovery owner you set yourself can sweep the account to that one fixed address without a post-quantum signature, so a faulty policy can never trap your funds.
Accounts cannot be upgraded from a classical account, deliberately. An account that can be migrated has a window where a classical key still holds authority, and that window is the vulnerability you were trying to remove.
The factory is deployed with CREATE2 at a fixed address, so your account address is identical across Base, Arbitrum One, Base Sepolia and any chain the contracts reach later. On Arbitrum the runtime bytecode was checked byte-identical to Base and the same public key confirmed to resolve to the same account address. It behaves like one address rather than a different one per chain.
Keys are generated and stored locally, encrypted with your password, with optional biometric unlock on top. There are no accounts and no server in the path of your funds. You can restore from a recovery phrase or an encrypted backup file.
An opt-in account type, live on Base, Arbitrum One and Base Sepolia, for people who want guardrails on top of self-custody. Choosing it at creation adds:
The contracts behind an account. The deploy is deterministic, so the same three addresses hold on Base, Arbitrum One and Base Sepolia.
A security product that hides this section has not earned the claims in the ones above it.
No external audit has been done, and the signature verifier is new code. Being live on mainnet is not the same as being proven. The wallet says so itself and tells you to keep balances small; that advice is real.
It is the SPHINCS+ design behind SLH-DSA, but with keccak instead of SHAKE and its own parameter set, because that is what makes verifying it on-chain affordable. Those changes put it outside FIPS 205. The security argument is the same hash-based one; the certification is not.
On a Protected account, if you set a recovery owner at creation, that address can sweep the account without a post-quantum signature. It is a deliberate escape hatch so a faulty policy can never trap funds, and it cannot be redirected anywhere else, but it does mean the post-quantum key is not the only key that can move value. It is off unless you choose it.
What ships on Bitcoin is key hiding and address rotation, so the public key is not exposed while coins sit still. Spending still uses classical ECDSA, and the protection depends on never reusing an address. It is a weaker guarantee than the smart-account chains, by necessity.
Solana runs on devnet and Bitcoin on Mutinynet signet. Base and Arbitrum One are the only mainnet deployments.
Falcon-1024 accounts exist on testnets. No mainnet deployment offers them, so a mainnet account is a standard-tier account.
A born-2FA account requiring both the post-quantum key and a registered passkey exists in the contracts, with its addresses already fixed. Nothing is deployed yet, and the wallet hides the feature until it is.
Where the wallet wraps a recovery phrase with a passkey, that is local encryption convenience. The post-quantum key remains the on-chain authority, so passkey unlock is not a second factor against someone who already has your phrase.
