420 Wallet¶
420 Wallet is the primary account, authorization and ecosystem-navigation application for 420 Integrated. It presents canonical Smart Account state and lets users safely construct, review and authorize account actions without creating a second custody, identity or permission system.
The Genesis release is a web client. Future browser-extension, mobile and desktop clients may present different interfaces, but all qualified clients must reuse the same SmartAccount420, recovery, capability, session and revocation semantics.
Authority¶
420 Wallet is a replaceable user client over canonical account/protocol state.
It may read chain/indexer data, build transactions, simulate supported actions, request signatures, explain capability requests and navigate to registered ecosystem services. It is not consensus-critical and must not become canonical authority for balances, ownership, permissions, identity, application legitimacy or finality.
Canonical account authority remains with the relevant on-chain account and authorization contracts, including SmartAccount420 and CapabilityRegistry420.
Start here¶
The complete task-oriented Wallet journey was built in DOC-6 and remains canonical. Use those guides rather than duplicating them here:
- Wallet onboarding
- Setup, import and protection
- Send, receive and activity
- Connect applications
- Signing and transaction review
- Permissions and sessions
- Recovery and device safety
- Troubleshooting
Application package¶
Use the DOC-8 application pages for the broader Wallet model:
- Getting started
- User guide
- Concepts
- Architecture
- Permissions
- Fees
- Security
- Troubleshooting
- FAQ
- Developer integration
What the Wallet can do¶
A qualified Wallet client can:
- discover and display the user's canonical Smart Account;
- show native
$420, assets and relevant account activity; - construct supported account transactions and batches;
- simulate supported mutations before authorization;
- request owner, passkey, operator, capability or session authorization as appropriate;
- display and revoke reusable permissions;
- guide users through supported recovery flows;
- resolve core ecosystem destinations through Registry-backed or signed/versioned discovery;
- expose 420Docs and Developer Hub as first-class help/integration destinations.
What the Wallet must never do¶
A qualified client must not:
- store user private signing keys on a 420-operated server;
- silently sign, auto-sign or silently grant reusable capabilities;
- bypass Smart Account authorization policy;
- claim that UI state overrides canonical chain state;
- treat a URL alone as proof that an application is canonical or safe;
- expose private signing, passkey or recovery material to support services;
- convert a connection into spending authority without an explicit canonical grant.