Final Wallet: Security and Capabilities
The security view of the wallet, in the documentation: the custody model, a table of every capability with what protects it, and the threats with their answers.
Last updated 2026-09-08 · maintained in the Final Wiki
Everything a Final Wallet can do, and what protects each capability. The plain how-to is the User guide; this page is the security view of the same wallet.
#The custody model
A Final Wallet is a smart-contract account behind a stable per-user proxy on every chain the Final network serves. Its identity is your Final Identity: the key commitments of your certificate, never an externally owned account. Every action is an intent you sign on your device; the wallet verifies your signature and executes. Nobody at Final DeFi can sign for you, nobody can be compelled to, and no endpoint anywhere accepts your private keys. Recovery exists for a lost key and always waits for inactivity and a delay; it cannot take a wallet from someone holding a stolen key.
#Three kinds of account, and the road each takes
- A Final Wallet with a Final Identity (post-quantum) executes through intents only: a ticket you sign, admitted and executed by the Final gateway on the chosen chain. There is no other road.
- A Final Wallet controlled by an owner key (not yet post-quantum) has two roads behind a switch in Send: the intent, the default, or owner transport — a standard transaction from the owner key to the gateway's owner-transport entry. The switch disappears when the wallet turns post-quantum. Owner transport carries everyday actions only: on that road the wallet refuses every function that would change who owns it, its recovery settings or validators, its post-quantum keys or a sub-account's forced escape, and recovery itself never travels on it; a frozen wallet cannot use it; it closes for good when the wallet turns post-quantum; and the protocol can retire it on a chain once and irreversibly.
- An EOA account — the owner key acting as itself — is an ordinary externally owned account in the extension: it sends standard transactions, signed inside the extension's core and broadcast through the plane's tunnel; a dapp gets
eth_sendTransactionfor it behind an approval — that, and the standard methods every wallet answers, is all a site sees of it: on the wallet dashboard it pays a Final wallet's creation deposit like any browser wallet, and no Final action runs from it. The contract-account protections on this page do not apply to it.
#Capabilities, and what protects each
| Capability | What you can do | What protects it | ||
|---|---|---|---|---|
| One address, every chain | Every chain the Final network serves shares your address — the list comes from Final Chain's tree, Pre-Final Chain built in; creating the wallet elsewhere is one action, and the first chain is paid for from a deposit at that chain's gateway | The address derives from your certificate's attestation, so it cannot be predicted or squatted on a chain you have not used | ||
| Networks, assets, prices | Networks you add yourself sit beside the served ones; every asset in the registry is listed on its chain by itself; balances on the testnets are priced like their mainnet twins | A chain of yours the network does not serve is labelled Final DeFi unsupported chain; a registry asset cannot be removed from the list, so a token cannot be made to disappear; an asset without a mark (PHI before its listing) is shown as unpriced, never as a fault | ||
| Intents, gasless | Send, call, approve; the protocol carries the intent and shows the fee before you sign | The wallet checks your signature and the fee you signed; what the execution did not use stays on your deposit at that gateway and pays your next intent | ||
| Immediate, gated, scheduled, private | Execute now, after a second look, at a chosen time (cancel until 90 seconds before), or privately | Encrypted on your device; outsiders see only the target chain, the deadline and the schedule; what will execute is a record on the state plane before it runs — see [[oracles | Oracles]] | |
| Sub-accounts and controllers | Separate pockets under one identity, each with its own address and budget, able to pay their own fees, optionally bound to a protocol's controller under rules you accept and can leave | Wallet-owned custody routes with their own scope; a controller lane that fails closed and can spend at most one route's budget; escape needs no controller cooperation — see [[sub-accounts | Sub-accounts, controllers and agents]] | |
| Agents | Give a bot, an automation or an AI agent a bounded allowance: allowlisted targets and functions, per-token caps, a dispatch limit, an expiry, named sub-accounts | Enforced by a chain-global wallet module; approvals denied by default; ownership, recovery, keys and module administration structurally out of any agent's reach; three independent checks on every dispatch; revocable in one action | ||
| Post-quantum mode | Switch a wallet to post-quantum authorization, per wallet, one-way | Transactions under ML-DSA-87, account changes under SLH-DSA-SHAKE-256s, verified in the state plane's precompiles | ||
| Receipts and status | Every intent answers with a receipt and a status you can read back | The receipt carries the real transaction hash; state readers answer by lookup, never by scanning | ||
| Recovery and guardians | A recovery authority or your own guardians restore control after inactivity and a delay; dormant funds route to a vault for your claim | Any action of yours cancels a queued recovery; guardians can cancel, never rotate; recovery keys are pre-committed successors | ||
| Freeze and rotation | Freeze the account; rotate keys without waiting for inactivity | Live: both act on the account ledger, and the account plane is carried to every chain as soon as it changes | ||
| PHI Launch Sale | Buy PHI on any supported chain in any accepted asset; delivered on the chain you choose and usable at once | Purchases are admitted and priced on the state plane at attested marks | ||
| vAssets and morphing | Real assets locked on their chain, usable elsewhere and verifiable; exposure long or short without a sale, bounded by the per-asset cap the asset registry sets | LaBRADOR-based proofs published on the target chain; a morphed position can lose only what it morphed. both arrive with the release — see [[vassets | vAssets]] and [[morphing | Morphing]] |
| Fee tiers | Locked PHI on any chain raises your tier and discounts service fees | The [[particle-ladder | Particle Ladder]] is read from the state plane | |
| The interfaces | The web dashboard today; the browser extension with the release — the everyday wallet in the browser's side panel or a floating window (a header button switches; approvals are their own popups), the longer flows on the wallet dashboard of the plane, which works with the extension as a site does; the extension shows its version and the newest it knows of | The extension announces its own provider and never intercepts another wallet's; its post-quantum core runs in an isolated WebAssembly module; the dashboard asks and the extension approves and signs — one approval per action, no key or signature leaves it, and the plane and the identity are one state for both surfaces; ordinary accounts keep a plain typed-data signing lane; it is downloaded from the wallet dashboard and nowhere else and updates through the browser's store (in Testnet mode also from the wallet dashboard); every link it opens lands on the wallet host, which resolves onward to the chain's explorer | ||
| The connection | The wallet talks to our nodes | With the release, over [[network-protocol | Final Network Protocol]] tunnels terminating at the node, not at a TLS edge |
Plainly: everything the wallet can do — one address on every chain, gasless intents of four kinds, sub-accounts, agents, post-quantum mode, recovery, freeze and rotation, the sale, vAssets and morphing, fee tiers — is protected by a check made on the state plane or in the wallet contract itself, never by trust in a server.
#Threats, and the answer
| Threat | Answer | |
|---|---|---|
| A large quantum computer | Every key is post-quantum under two hardness families — see [[pq-cryptography | Post-quantum cryptography]] |
| A party between you and the chain | Intents and oracle marks are records on the state plane; execution must match the admitted record | |
| A phishing page or a rogue provider | The extension is its own provider; the address is derived from your certificate; nothing you paste can be a key, because no page asks for one; every link the wallet opens lands on our wallet host first | |
| A stolen device | The recovery stage is held apart and cold; key rotation supersedes the live stage | |
| Lost keys | Recovery after inactivity and a delay, by the authority or your guardians | |
| A compromised operator | No operator spend keys; single-use accounts; secrets split K-of-N and released only while an intent is executable | |
| A compromised bot or protocol | An agent or a controller can spend at most the one route's budget you set; it cannot touch the wallet, another pocket, your keys or your authority; you revoke or escape unilaterally |
Plainly: a quantum computer, an intermediary, a phishing page, a stolen device, lost keys, a compromised operator or a compromised bot each meets a specific answer — post-quantum keys, records on the state plane, a wallet that is its own provider, a cold recovery stage, delayed recovery, no operator spend keys, and budgets that cannot reach your authority.
#Where to go next
Final Identity (create yours) · Final Certificates · Security-first architecture · Intents · Recovery and guardians · Fees and PHI