PointCast / Wallet field guide / checked 2026-10-06
The Wallet Is the Controller
From Bitcoin’s desktop client to MetaMask, Phantom, Kukai and programmable accounts: follow the powers beneath the wallet icon.
A PointCast field guide to keys, permissions and the changing shape of digital ownership
Educational architecture guide, not investment advice. PointCast lessons use fictional data. They never request a recovery phrase, private key, password, wallet connection or transaction.
Press start: what a wallet actually holds
The little wallet icon makes a large promise: your digital belongings, ready whenever you need them. But the picture is misleading. A blockchain wallet usually does not contain coins in the way a leather wallet contains cash. It is closer to a controller, a key cabinet and a very opinionated dashboard. The network keeps the shared record. Your wallet helps you inspect that record and authorize changes to it.
That distinction is the opening move in understanding everything that follows. Deleting an app is different from deleting an account. Seeing a balance is different from being able to spend it. Signing something is different from sending a payment. And a friendly sign-in screen tells you surprisingly little about who can ultimately authorize a transaction.
PointCast’s guide follows the wallet from a desktop companion to a programmable permission system. The pixel-art scenery is playful; the control model deserves plain language. We will use three case studies, MetaMask, Phantom and Kukai, to ask the same questions: What does the software do? What gives a person control? What happens when the device, company, login or network support disappears? You can explore every lesson here without connecting a real wallet.
Bitcoin Developer Guide: Wallets
Sources: Bitcoin Developer Guide: Wallets ↗
Level 01: the desktop client
Bitcoin’s early experience bundled together jobs that now often live in separate products. In the original January 8, 2009 release announcement, the software connected to peers, offered coin generation and let people send payments. It was explicitly described as experimental. Wallet software was part of operating a new network, rather than a polished doorway into thousands of apps.
Bitcoin’s central innovation was not an unusually attractive account screen. Digital signatures authorized transfers, while the peer-to-peer system established a shared ordering of transactions to address double-spending. A signature alone cannot tell a recipient whether the same value has been promised elsewhere; the network’s consensus machinery handles the shared-history problem.
This early arrangement exposes a useful boundary. Wallets prepare and authorize; the network validates and records. Those jobs can share a computer, but they are not the same job. A modern wallet may delegate blockchain queries to remote infrastructure and still keep signing on a local device. Conversely, a person can run a node without handing it spending authority. The interface is one layer of the system, not the system itself.
Bitcoin v0.1 released, original announcement Bitcoin: A Peer-to-Peer Electronic Cash System
Sources: Bitcoin v0.1 released, original announcement ↗ Bitcoin: A Peer-to-Peer Electronic Cash System ↗
Level 02: coins, accounts and addresses
On Bitcoin, the spending model revolves around unspent transaction outputs, often shortened to UTXOs. A wallet finds outputs it can spend and constructs a transaction that consumes selected outputs and creates new ones. A familiar balance is a convenient summary of those spendable pieces. Change is a new output, not loose digital coins returned to a pouch.
Ethereum uses account-based state. An externally owned account, or EOA, is controlled through a private key; a contract account follows deployed code. An address identifies an account, but an address is not necessarily a public key. Ethereum EOA addresses are derived from public keys, and contract addresses arise through contract-creation rules.
The distinction matters when someone says, “I have one wallet.” They may mean one app, one recovery phrase, one account or one visible address. A single app can manage many accounts. A single recovery root can derive many keys. A multichain interface can group several network-specific addresses under one account label. These layers make everyday use easier, but they should never be collapsed into one universal identifier.
Bitcoin Developer Guide: Transactions Ethereum accounts
Sources: Bitcoin Developer Guide: Transactions ↗ Ethereum accounts ↗
Level 03: one backup, many branches
Backing up a growing collection of unrelated keys was an awkward early-wallet problem. Hierarchical deterministic wallets changed the shape of that work. BIP-32, assigned in 2012, describes deriving a tree of key pairs from a single seed. A root can lead to organized branches instead of a drawer full of unrelated secrets.
BIP-39, assigned in 2013, specifies a human-readable mnemonic and its conversion into a seed. Its words encode computer-generated randomness and a checksum; they are not meant to be a clever sentence somebody invents. An optional mnemonic passphrase participates in seed derivation. That passphrase is different from a password that merely unlocks a local app.
BIP-44, assigned in 2014, adds a commonly used hierarchy for purpose, coin type, account, change and address index. The consequence is practical: restoring the same words is not always enough to make two applications show the same accounts immediately. Derivation conventions and discovery behavior matter too. These standards explain a family of widely used designs, not a universal recovery rule for every wallet or blockchain. A recovery phrase is powerful precisely because it can represent much more than the account currently visible on screen.
BIP-32: Hierarchical Deterministic Wallets BIP-39: Mnemonic code for generating deterministic keys BIP-44: Multi-Account Hierarchy for Deterministic Wallets
Sources: BIP-32: Hierarchical Deterministic Wallets ↗ BIP-39: Mnemonic code for generating deterministic keys ↗ BIP-44: Multi-Account Hierarchy for Deterministic Wallets ↗
Level 04: move the signing boundary
Hardware wallets gave a physical shape to a useful separation: the machine displaying a website need not be the machine holding a signing secret. Trezor records the Model One launch on July 29, 2014. The important architectural idea is a dedicated signer that reviews and signs requests while keeping key material within the device’s intended security boundary.
A connected wallet app can then act as an interface. It assembles a proposed operation, asks the hardware device to sign and relays the result. Watching a balance does not require exposing the private key to that interface. The device, the host app and the network remain separate parts of the path.
This does not make intent automatic. A signer can protect a secret while authorizing an unwanted action that its owner misunderstood. A tiny display, abbreviated address or blind-signing flow can become the weak link between intention and authorization. In PointCast’s controller metaphor, sturdy hardware protects the controller’s circuitry; it cannot decide whether the player selected the right door. The useful question is what the trusted display actually lets a person verify before approval.
Trezor Model One tenth-anniversary history Bitcoin Developer Guide: Wallets
Sources: Trezor Model One tenth-anniversary history ↗ Bitcoin Developer Guide: Wallets ↗
Level 05: the wallet becomes a web interface
Ethereum’s Frontier network launched on July 30, 2015. Its programmable contracts expanded what a wallet interaction might mean: a payment, a token transfer, a contract deployment or a call into an application’s logic. The wallet’s review screen had to translate more than an amount and a recipient.
MetaMask, founded in 2016, helped establish the browser-wallet pattern. A website could request a connection and ask a wallet to prepare a transaction or signature. This made the browser a meeting point between ordinary web interfaces and independently verifiable state. It also created a new design problem: a familiar-looking page could ask for surprisingly broad authority.
Phantom’s 2021 beginnings represent another phase of the same story. Wallet teams increasingly competed on comprehensible balances, collectibles, mobile access and the experience of moving between apps. Kukai’s 2020 DirectAuth release explored a different entrance: an existing online identity could help a person access a Tezos wallet. These were not simply new skins over an identical account model. They changed where users encountered complexity, and which dependencies they needed to understand.
Ethereum Launches MetaMask tenth-anniversary announcement About Phantom Tezos Foundation: Exploring DirectAuth on Tezos by Kukai Wallet
Sources: Ethereum Launches ↗ MetaMask tenth-anniversary announcement ↗ About Phantom ↗ Tezos Foundation: Exploring DirectAuth on Tezos by Kukai Wallet ↗
Level 06: follow a request through the machine
Consider a fictional app asking to record a game result on Ethereum. First the page constructs a request. A provider interface carries it to wallet software. EIP-1193 defines an Ethereum JavaScript provider API, including requests and events for account or chain changes. The provider is an interface for communication, not a vault that should reveal private keys to the page.
Next the wallet identifies the account and network, interprets the requested action and presents whatever review its implementation supports. If the user authorizes a transaction, an appropriate signer produces a signature. An RPC endpoint can relay the signed transaction; network participants validate and include it according to the chain’s rules. The app then observes a receipt or updated state.
Every arrow is a place for confusion. A request can be rejected, a transaction can remain pending, a simulation can differ from later conditions, or execution can fail. “The wallet opened” does not mean “the operation happened.” A useful interface names the stage: requested, reviewed, signed, submitted, included, failed or sufficiently finalized for the application’s purpose. Clear status is part of security, because uncertainty encourages repeated actions.
EIP-1193: Ethereum Provider JavaScript API Ethereum transactions
Sources: EIP-1193: Ethereum Provider JavaScript API ↗ Ethereum transactions ↗
Level 07: four different meanings of yes
Connect is usually a request to disclose selected account information and establish an app-to-wallet interaction channel. It is not, by itself, an unlimited spending grant. Yet a known public address and its activity remain observable on a public chain even after an app connection is removed.
Sign means authorize a particular message or transaction. Some messages merely demonstrate account control; others carry economically meaningful authority. EIP-712 supplies structured data and domain separation, but readable fields do not certify a request as safe. A signature deserves review even when there is no immediate network fee.
Approve has a precise token-contract meaning in ERC-20: an owner sets an allowance for a spender, which can then use transferFrom within that allowance. It is distinct from the wallet’s generic button labeled Approve. ERC-2612 shows why signatures also matter here: a signed permit can later be submitted to create an allowance.
Disconnect removes an application connection in the wallet. Revoke changes an existing permission or allowance through the mechanism that created it. Those are different operations. Closing a tab, locking an app or disconnecting a site should never be presented as a universal cancellation button for authority already granted elsewhere.
EIP-712: Typed structured data hashing and signing ERC-20: Token Standard ERC-2612: Permit Extension for ERC-20 Signed Approvals MetaMask: Revoke smart contract allowances/token approvals
Sources: EIP-712: Typed structured data hashing and signing ↗ ERC-20: Token Standard ↗ ERC-2612: Permit Extension for ERC-20 Signed Approvals ↗ MetaMask: Revoke smart contract allowances/token approvals ↗
Level 08: the work has a cost
Gas is a measure of execution work on Ethereum, not another name for a wallet’s service charge. The fee depends on the work used and applicable fee rates. A transaction that reaches execution and fails can still incur a fee, because the network already spent resources attempting it. A wallet’s estimate is useful planning information, not a promise that the final cost or outcome cannot change.
A token balance and a fee-paying balance are also different things. Holding a token on one network does not automatically provide the fee asset needed to transact on another. Some products sponsor a user’s fee or arrange payment using another asset, but the underlying cost still has a payer and a mechanism.
Do not universalize Ethereum’s vocabulary. Bitcoin’s fees relate to transaction construction and available block space; other chains have their own accounting. Even the broad claim that every chain needs its own native gas token has exceptions: MetaMask’s current network guide notes stablecoin-based fee arrangements on Arc and Tempo. PointCast’s fee diagrams therefore label the network and payer explicitly rather than decorating every action with the same floating coin.
Ethereum gas and fees Bitcoin Developer Guide: Transactions MetaMask: How to add a network
Sources: Ethereum gas and fees ↗ Bitcoin Developer Guide: Transactions ↗ MetaMask: How to add a network ↗
Level 09: one dashboard, different rules
Multichain is an interface capability, not proof that chains have become interchangeable. Solana stores state in accounts owned by programs, and its transactions contain instructions. A Solana account address can identify a key-pair account or a program-derived address; not every address has a corresponding private key that a person can export.
Tezos distinguishes user, or implicit, accounts from originated smart-contract accounts. Familiar tz-prefixed user addresses and KT1 contract addresses convey different roles. Tezos layer 1 and an EVM-compatible system such as Etherlink also should not be silently treated as the same network merely because they share an ecosystem.
These differences affect what software must display and what applications can request. An asset symbol is not sufficient identification. The network, token contract or mint, destination format and supported account type may all matter. A common wallet interface can hide switching friction while keeping those distinctions visible at the moment they count. The best multichain lesson is not to memorize every chain’s internals. It is to ask which rules govern this particular request, instead of assuming a familiar icon implies familiar behavior.
Solana: Accounts Solana: Transactions Tezos: Accounts and addresses Tezos: Architecture
Sources: Solana: Accounts ↗ Solana: Transactions ↗ Tezos: Accounts and addresses ↗ Tezos: Architecture ↗
Level 10: custody is a set of powers
“Who holds the keys?” is a useful starting question, but a complete custody map asks who can sign, who can recover, who can block access and who can change those arrangements. An exchange account, a local software signer, a hardware-backed account and a distributed signing service can present similar balances while assigning those powers differently.
MPC is a broad cryptographic technique. In threshold-signature wallet designs, multiple participants can cooperate to generate a valid signature without assembling the full private key in one place. That is different from splitting an encrypted backup into pieces and later reconstructing a key on a client. Both can involve distributed components; they are not the same mechanism.
Neither “MPC” nor “seedless” alone settles custody. A design may require a service to participate, provide an independent recovery path, or impose organization-level policies. Fireblocks’ descriptions illustrate how quorum and recovery arrangements are implementation-specific. The PointCast test is concrete: draw the required participants during ordinary signing and again during disaster recovery. If those two pictures differ, that difference belongs in the explanation, not behind a reassuring label.
Fireblocks: MPC 101 Fireblocks: Direct Custody Principles
Sources: Fireblocks: MPC 101 ↗ Fireblocks: Direct Custody Principles ↗
Level 11: familiar login, unfamiliar consequences
Social login and social recovery answer different questions. Login uses an identity provider to authenticate someone. Guardian-based recovery lets a defined set of people or devices help replace or restore control under an account’s rules. A product can implement either, both or neither.
Kukai’s published DirectAuth documentation describes OAuth authentication followed by Torus-network shares that reconstruct a private key on the client. That account-access path should not be rebranded as a guardian vote. MetaMask’s current social-login documentation describes another design: an encrypted recovery phrase, distributed key-management machinery and the combination of a supported login and a user-created password. Phantom’s current instructions distinguish Google/Apple sign-in from local device unlock, with a PIN still relevant to wallets created in a PIN-based flow.
A passkey belongs to another layer again. WebAuthn credentials authenticate within a relying-party scope. A wallet can build account access or signing around them, but a passkey is not automatically a blockchain address or a complete recovery plan. The essential design question is what the login unlocks and what survives when the login provider or original device is unavailable.
Kukai: DirectAuth MetaMask: How social login works Phantom: Create a wallet with Google or Apple W3C: Web Authentication Level 3
Sources: Kukai: DirectAuth ↗ MetaMask: How social login works ↗ Phantom: Create a wallet with Google or Apple ↗ W3C: Web Authentication Level 3 ↗
Level 12: the account becomes programmable
Smart accounts let code participate in deciding what counts as valid authorization. That can support multiple signers, recovery rules, spending limits or alternative authentication, depending on the implementation. ERC-1271 provides a standard way for a contract to report whether a signature is valid, rather than assuming every account’s authority is one ordinary key-pair signature.
ERC-4337 supplies a higher-layer transaction path built around UserOperations, bundlers and an EntryPoint contract; an optional paymaster can handle sponsorship arrangements. It is not a claim that every wallet now exposes every smart-account feature. EIP-7702 addresses a different layer: an EOA can designate contract code whose logic runs in its account context. Ethereum’s Pectra upgrade activated on May 7, 2025.
Crucially, a 7702 delegation is not merely a temporary visual mode that vanishes when a tab closes. Its designation persists until changed or cleared. The signing key still matters, and delegated code introduces its own trust boundary. Programmability creates room for better guardrails, but it also creates more policy and code to inspect. “Smart” describes capability, not an automatic improvement in judgment.
ERC-1271: Standard Signature Validation Method for Contracts ERC-4337: Account Abstraction Using Alt Mempool EIP-7702: Set Code for EOAs Ethereum: Pectra
EIP-7702 delegates broad account authority to code. The authorization tuple does not itself impose granular spending limits or action restrictions; those limits depend on the delegated code implementation. A code delegation therefore deserves a different review from merely sharing account information.
Sources: ERC-1271: Standard Signature Validation Method for Contracts ↗ ERC-4337: Account Abstraction Using Alt Mempool ↗ EIP-7702: Set Code for EOAs ↗ Ethereum: Pectra ↗
The next controller should explain its powers
The story does not end with a single winning wallet shape. A browser extension, mobile interface, hardware signer, passkey-backed account and institutional threshold system can coexist because they solve different problems. Their shared challenge is making authority legible.
PointCast’s position is that a useful wallet should be able to answer ordinary questions in ordinary language: What am I authorizing? Who else can act? How much can they do? When does that authority end? What will it cost? How do I recover, and how do I leave? A simulation, a warning or an audit can help answer parts of that checklist, but none should become a decorative badge that substitutes for the answer.
The next pages compare three concrete products through those questions. They are case studies rather than a podium. Feature lists change, and old tutorials can become wrong while remaining beautifully indexed. That is why every current-feature claim here carries an October 6, 2026 check date, with discrepancies called out instead of smoothed away.
Press start does not need to mean connect. Read the diagrams, inspect the mock requests and practice explaining the difference between access and authority. Understanding that difference is the most portable wallet skill.
Sources:
Three current product cases / checked 2026-10-06
Same questions. Different control models.
MetaMaskFrom browser bridge to programmable permission layer
The original move
MetaMask’s history begins in 2016 with an Ethereum browser wallet. Its enduring contribution to the interface story is the bridge between an ordinary website and an account-controlled action. The page can make a request; the wallet mediates access to the signer. That familiar browser-extension shape is still useful, but it no longer describes the full network scope of the product.
What the current product documents
As checked on October 6, 2026, MetaMask’s network guide lists Ethereum, Bitcoin, Linea, Base, Solana, Tron, Polygon, BNB Chain, Arbitrum, Monad, Robinhood Chain, OP, Sei, Avalanche, zkSync Era, MegaETH, HyperEVM, Arc and Tempo. It also describes adding compatible custom networks. That does not imply identical app, token, hardware or transaction support on each chain. The old shorthand “MetaMask is only an EVM wallet” is no longer accurate.
Its social-login documentation currently names Google, Apple and Telegram, combined with a wallet password. It describes an encrypted recovery-phrase backup and distributed key management. The same documentation warns that the chosen social identity is associated with linked wallet addresses. Easier recovery and identity separation are different design goals.
MetaMask: How to add a network MetaMask: How social login works
Sources: MetaMask: How to add a network ↗ MetaMask: How social login works ↗
Read the smart-account claim carefully
MetaMask’s smart-account help page says the feature is auto-enabled for new users. It describes pointing an existing EOA at MetaMask delegation code without moving assets or changing the address. It also explicitly says the general smart-account benefits listed on that page are not all available in MetaMask. A feature category such as social recovery is therefore not evidence that a particular consumer account already has a guardian-recovery setup.
For builders, the Smart Accounts Kit supplies actual contracts, libraries and services for programmable behavior and delegated permissions. Developer-tool availability and a capability in the consumer app should remain separate labels. The practical question is which chain, account, app and implementation support the intended operation today.
MetaMask: What is a smart account MetaMask Smart Accounts Kit
Sources: MetaMask: What is a smart account ↗ MetaMask Smart Accounts Kit ↗
PointCast field note
MetaMask makes a strong teaching case for the difference between connecting, signing and granting continuing authority. The interface can represent all three, sometimes in close succession. A reader should be able to identify the request’s target, network and scope before interpreting a familiar button label.
Our mock MetaMask lesson pairs two cards: “Let this app see this account” and “Let this spender use up to 20 practice tokens.” They look equally simple, but create different powers. A third card switches on a code delegation. The lesson is complete only when the reader can explain why disconnecting the app would not necessarily undo either of the latter permissions.
MetaMask: Revoke smart contract allowances/token approvals
Sources: MetaMask: Revoke smart contract allowances/token approvals ↗
PhantomA polished dashboard is still a map of separate networks
The original move
Phantom dates its beginnings to January 2021. Its case study centers on lowering the cognitive cost of interacting with blockchain apps: one recognizable interface, a coherent asset view and security cues close to the action. The product’s Solana origins are useful historical context, but a current description must account for its multichain scope.
Sources: About Phantom ↗
A current list, with two important departures
On October 6, 2026, Phantom’s supported-network page lists Solana, Ethereum, Robinhood Chain, Arc, HyperEVM, Bitcoin with Native SegWit and Taproot, Base, Polygon and BNB Chain. It explicitly lists Arbitrum, Optimism, Avalanche, Unichain and Linea as unsupported. This is a product support boundary, not a statement about whether an EVM address can exist elsewhere.
Older Phantom articles still mention Sui and Monad. The newer official notices say Sui support ended September 24, 2026, with Monad’s transition dated August 26, 2026. The current network list excludes both. Ending support changes what the Phantom interface can do; it does not erase assets from those blockchains. This is a concrete example of why wallet portability matters.
Phantom: Supported networks Phantom: Ending support for Sui Phantom: Ending support for Monad
Sources: Phantom: Supported networks ↗ Phantom: Ending support for Sui ↗ Phantom: Ending support for Monad ↗
Which recovery flow was created?
Current Phantom instructions offer Google or Apple sign-in and an exportable recovery phrase. They say a four-digit PIN is required together with the login if the wallet was created in a flow that asked for one; it is no longer correct to claim that every new Phantom wallet requires that PIN. A browser password or mobile biometric unlock protects access on the current device and does not replace the recovery method.
Phantom documents transaction previews, malicious-domain warnings and spam protections. It also documents supported Ledger integrations, with model and connection restrictions. These features can reduce risk without proving that a particular asset, app or proposed operation is safe.
Phantom: Create a wallet with Google or Apple Phantom: How your wallet is secured Phantom: Supported hardware wallets
Sources: Phantom: Create a wallet with Google or Apple ↗ Phantom: How your wallet is secured ↗ Phantom: Supported hardware wallets ↗
PointCast field note
The design question is how much complexity a unified view can hide before it hides something necessary. A token symbol and a familiar thumbnail may feel like enough information until a network is unsupported or a permission behaves differently than expected.
Our Phantom lesson uses identical practice-token symbols on two fictional network cards. Readers must match the asset, network and recipient requirements before a simulated transfer can proceed. The exercise rewards a correct explanation, not speed. A second state removes one network from the mock dashboard while leaving its ledger record visible, making the app-versus-account distinction tangible.
Sources:
KukaiThe social entrance is not the recovery model
The original move
Kukai is a Tezos wallet whose public source repository describes a web-based interface. In November 2020, the Tezos Foundation documented version 1.9’s DirectAuth launch, including then-supported Google, Reddit and Twitter identities. That historical list should not be republished as a verified list of working login providers in 2026.
The interesting product question was immediate: could someone reach a blockchain account through an identity they already understood? DirectAuth made that question concrete long before “seedless” became a common marketing label.
Kukai source repository Tezos Foundation: Exploring DirectAuth on Tezos by Kukai Wallet
Sources: Kukai source repository ↗ Tezos Foundation: Exploring DirectAuth on Tezos by Kukai Wallet ↗
What the published architecture actually says
Kukai’s DirectAuth guide describes an OAuth proof being verified by Torus-network nodes. Those nodes supply shares used to reconstruct a private key on the client. The guide describes distributed key generation and an account tied to the OAuth identity.
That is a social-login-based key-access design. It is not, on the evidence reviewed, a guardian-based social-recovery system in which friends vote to rotate an account’s owner. Nor should its client-side reconstruction be described as threshold signing that never reconstructs a full key. Similar vocabulary can conceal materially different security boundaries.
The public guide is old. PointCast can explain its documented architecture while declining to infer current provider uptime, exact production dependencies or every current interface choice from that page alone.
Sources: Kukai: DirectAuth ↗
One app, more than one control path
Kukai’s documentation separately describes a seed-phrase software wallet backed by an encrypted keystore file, and an import/connect flow with a Ledger option. The live Ledger page says keys stay on the Ledger device and notes a Safari limitation. The software-wallet password and an optional mnemonic passphrase play different roles; treating both as a generic “wallet password” would make recovery harder to explain.
Its import guide also distinguishes legacy and HD wallet types. That is a useful reminder that a matching set of seed words does not guarantee a matching displayed account when wallet type or derivation differs. The guide contains unfinished compatibility placeholders, so this article does not claim an exhaustive modern import-compatibility matrix.
Kukai: Setup a New Wallet Kukai: Import & Connect Kukai: Connect Ledger
Sources: Kukai: Setup a New Wallet ↗ Kukai: Import & Connect ↗ Kukai: Connect Ledger ↗
PointCast field note
Kukai’s strongest lesson is that onboarding should be traced all the way through to recovery. The login button is the beginning of a dependency map, not the end of one.
Our mock lesson offers three doors labeled Login-based access, Encrypted local file and Hardware signer. Readers follow each door to the components required for a signature and then remove one component to test the recovery story. The exercise never accepts a real email, recovery phrase, private key or device connection. Its goal is conceptual fluency: the same wallet brand can expose different control arrangements, so evaluate the chosen arrangement rather than the logo.
Sources:
A dated chronology.
2008
The peer-to-peer payment design
Bitcoin’s paper combines digital signatures with a shared transaction history to address double-spending.2009-01-08
A desktop client for an experimental network
The original Bitcoin v0.1 announcement bundles peer connectivity, payments and coin generation in one release.2012-02-11
A tree of keys
BIP-32 is assigned: one seed can derive an organized hierarchy of key pairs.2013-09-10
A human-readable backup format
BIP-39 is assigned: mnemonic encoding and conversion into a seed. Not a universal wallet-recovery format.2014-04-24
A shared account hierarchy
BIP-44 is assigned: a path structure for multiple coin types, accounts and addresses.2014-07-29
A dedicated hardware signer
Trezor records the launch of Model One. The history here does not adjudicate every competing “first hardware wallet” claim.2015-07-30
Ethereum Frontier launches
Contract execution expands the kinds of requests wallet software must explain.2016
MetaMask’s browser-wallet beginning
The wallet becomes a familiar mediator between web apps and Ethereum accounts.2020-11-06
DirectAuth changes the entrance
Tezos Foundation coverage documents Kukai’s social-login-based DirectAuth release.Tezos Foundation: Exploring DirectAuth on Tezos by Kukai Wallet ↗
2021-01
Phantom begins
Phantom’s own history dates the team’s start to January 2021.2021-09-29
ERC-4337 is proposed
The specification is created; its UserOperation path avoids requiring a consensus-layer change. This is the proposal date, not a universal deployment date.2025-05-07
Pectra brings EIP-7702 to Ethereum mainnet
EOAs can designate contract code, adding a new path toward programmable account behavior.2026-08-26
Phantom’s Monad transition
The official notice specifies this transition date; the current support list excludes Monad.Phantom: Ending support for Monad ↗ Phantom: Supported networks ↗
2026-09-24
Phantom ends Sui support
A current reminder that wallet-interface support and onchain ownership are different layers.2026-10-06
PointCast verification checkpoint
Network lists, recovery language and standard status checked for this edition. Recheck before using this as current product guidance.
Original teaching diagrams
Inspect the mechanism.
The wallet is five layers
The app asks, the wallet explains, the signer authorizes, and the network validates. Read access does not require spending authority.
1App interface
The requesting app proposes an action; it does not gain signing authority merely by asking.
2Provider / connection channel
The connection channel carries requests and account information. It is distinct from the signer.
3Wallet policy and review
Wallet review interprets a request and applies policy; a familiar screen alone is not evidence of safety.
4Signer: device, hardware or quorum
The signer authorizes according to its device, key or quorum rules.
5Network state
The network validates and records. A returned receipt is observable state, not control over a key.
| From | To | Meaning |
|---|---|---|
| App interface | Provider / connection channel | Proposed request |
| Provider / connection channel | Wallet policy and review | Request and context |
| Wallet policy and review | Signer: device, hardware or quorum | Authorized operation |
| Signer: device, hardware or quorum | Network state | Signed operation, relayed via RPC |
| Network state | App interface | Observed state / receipt |
Sources: EIP-1193: Ethereum Provider JavaScript API ↗ Ethereum transactions ↗ Bitcoin Developer Guide: Wallets ↗
Four buttons, four different powers
A friendly button label does not tell you the scope or duration of authority. Read the mechanism. EIP-7702 grants broad account authority to delegated code; granular limits come from that implementation, not the authorization tuple.
1Connect account information
Connection shares account information; disconnecting removes that connection.
2Sign a typed message
A message signature may carry meaningful authority even without an immediate network fee.
3Set token allowance
An allowance authorizes a named spender up to a limit; disconnecting does not revoke it.
Sources: EIP-1193: Ethereum Provider JavaScript API ↗ EIP-712: Typed structured data hashing and signing ↗ ERC-20: Token Standard ↗ ERC-2612: Permit Extension for ERC-20 Signed Approvals ↗ EIP-7702: Set Code for EOAs ↗
Follow the recovery dependencies
Compare normal access with recovery. Social login, guardian recovery, key reconstruction and threshold signing are separate concepts.
1Phrase-derived software account
A recovery root and the correct account derivation are distinct from a local app password.
2OAuth-mediated key access
Kukai’s published legacy DirectAuth architecture uses OAuth/Torus-mediated key access; it is not guardian recovery.
3Hardware signer
The hardware device controls signing. Its recovery dependencies remain separate from the display app.
Sources: BIP-39: Mnemonic code for generating deterministic keys ↗ Kukai: DirectAuth ↗ Kukai: Setup a New Wallet ↗ Kukai: Connect Ledger ↗ Fireblocks: MPC 101 ↗
Two roads to programmable behavior
ERC-4337 specifies an execution path; EIP-7702 lets an EOA designate code. They can work together but are not synonyms.
14337: UserOperation
A UserOperation is not itself a regular network transaction.
2Bundler
A bundler assembles operations; it is not the chain’s validator.
3EntryPoint
EntryPoint coordinates the specified validation and execution path.
4Smart account validation / execution
Actual account features depend on the implementation.
57702: EOA authorization
An EOA authorizes a code designation under EIP-7702.
6Delegated code in EOA context
Delegated code executes in EOA context; designation persists until changed.
Sources: ERC-4337: Account Abstraction Using Alt Mempool ↗ EIP-7702: Set Code for EOAs ↗
The dashboard can change; the ledger remains
A wallet can stop showing a network without deleting its records. Continued access still requires a compatible wallet and control path.
1Wallet display
The interface decides what it displays.
2Supported network A
A supported network has a compatible interface path.
3No-longer-supported network B
Removing support changes the app, not the separate network’s history.
4Network B ledger
Continued access requires a compatible control and recovery path.
Sources: Phantom: Ending support for Sui ↗ Phantom: Ending support for Monad ↗
Follow the evidence.
- Bitcoin: A Peer-to-Peer Electronic Cash System ↗2026-10-06 · checked 2026-10-06
Signatures, transaction ordering, double-spending, public ledger architecture.
Primary source; paraphrased, no source artwork reproduced.
- Bitcoin v0.1 released, original announcement ↗2026-10-06 · checked 2026-10-06
January 8, 2009 release; combined desktop/node experience; explicitly experimental release.
Primary source; paraphrased, no source artwork reproduced.
- Bitcoin Developer Guide: Wallets ↗2026-10-06 · checked 2026-10-06
Wallet roles; key management; full-service, signing-only and watch-only separation.
Primary source; paraphrased, no source artwork reproduced.
- Bitcoin Developer Guide: Transactions ↗2026-10-06 · checked 2026-10-06
UTXOs, outputs and spending conditions; Bitcoin transaction model.
Primary source; paraphrased, no source artwork reproduced.
- BIP-32: Hierarchical Deterministic Wallets ↗2026-10-06 · checked 2026-10-06
Assigned 2012-02-11; deterministic tree of key pairs from one seed.
Primary source; paraphrased, no source artwork reproduced.
- BIP-39: Mnemonic code for generating deterministic keys ↗2026-10-06 · checked 2026-10-06
Assigned 2013-09-10; mnemonic encoding, seed derivation, optional passphrase.
Primary source; paraphrased, no source artwork reproduced.
- BIP-44: Multi-Account Hierarchy for Deterministic Wallets ↗2026-10-06 · checked 2026-10-06
Assigned 2014-04-24; derivation path hierarchy and account discovery.
Primary source; paraphrased, no source artwork reproduced.
- Trezor Model One tenth-anniversary history ↗2026-10-06 · checked 2026-10-06
Vendor records July 29, 2014 Model One launch; separate hardware signing context.
Primary source; paraphrased, no source artwork reproduced.
- Ethereum Launches ↗2026-10-06 · checked 2026-10-06
July 30, 2015 Frontier launch.
Primary source; paraphrased, no source artwork reproduced.
- Ethereum accounts ↗2026-10-06 · checked 2026-10-06
EOAs and contract accounts; keys and Ethereum address derivation; accounts distinct from wallets.
Primary source; paraphrased, no source artwork reproduced.
- Ethereum transactions ↗2026-10-06 · checked 2026-10-06
Signed state-changing operations, transaction lifecycle, nonce and gas fields.
Primary source; paraphrased, no source artwork reproduced.
- Ethereum gas and fees ↗2026-10-06 · checked 2026-10-06
Gas measures computational work; fees, failed execution and native ETH payment.
Primary source; paraphrased, no source artwork reproduced.
- EIP-1193: Ethereum Provider JavaScript API ↗2026-10-06 · checked 2026-10-06
Provider request transport; account/chain changes; connectivity distinct from account authorization.
Primary source; paraphrased, no source artwork reproduced.
- ERC-20: Token Standard ↗2026-10-06 · checked 2026-10-06
approve, allowance and transferFrom; contract-defined token accounting.
Primary source; paraphrased, no source artwork reproduced.
- ERC-2612: Permit Extension for ERC-20 Signed Approvals ↗2026-10-06 · checked 2026-10-06
Signature-based allowance with owner, spender, value, deadline and nonce.
Primary source; paraphrased, no source artwork reproduced.
- EIP-712: Typed structured data hashing and signing ↗2026-10-06 · checked 2026-10-06
Structured signing and domain separation; not a guarantee that a request is harmless.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask: Revoke smart contract allowances/token approvals ↗2026-10-06 · checked 2026-10-06
Disconnecting a dapp and revoking an onchain allowance are separate actions.
Primary source; paraphrased, no source artwork reproduced.
- Solana: Accounts ↗2026-10-06 · checked 2026-10-06
Accounts as state containers, owner program, public-key addresses and program-derived addresses.
Primary source; paraphrased, no source artwork reproduced.
- Solana: Transactions ↗2026-10-06 · checked 2026-10-06
Transactions consist of instructions; signatures; fee payer; atomic execution.
Primary source; paraphrased, no source artwork reproduced.
- Tezos: Accounts and addresses ↗2026-10-06 · checked 2026-10-06
Implicit/user accounts and originated/smart-contract accounts; tz and KT1 address prefixes.
Primary source; paraphrased, no source artwork reproduced.
- Tezos: Architecture ↗2026-10-06 · checked 2026-10-06
Nodes, RPC clients, wallets and indexers; Etherlink distinct from Tezos layer 1.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask tenth-anniversary announcement ↗2026-10-06 · checked 2026-10-06
2016 founding; evolution from Ethereum browser wallet; publication 2026-07-14. Marketing superlatives not adopted.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask: How to add a network ↗2026-10-06 · checked 2026-10-06
Current network list including Bitcoin, Solana, Tron and EVM networks; custom EVM RPC flow; Arc/Tempo fee caveat.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask: What is a smart account ↗2026-10-06 · checked 2026-10-06
Current auto-enabled feature statement; 7702 delegation; unchanged address/root-key responsibility; general capabilities not all shipped.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask Smart Accounts Kit ↗2026-10-06 · checked 2026-10-06
Available developer toolkit, programmable account behavior and delegated permissions; not universal consumer support.
Primary source; paraphrased, no source artwork reproduced.
- About Phantom ↗2026-10-06 · checked 2026-10-06
January 2021 start and 2021 beta history.
Primary source; paraphrased, no source artwork reproduced.
- Phantom: Supported networks ↗2026-10-06 · checked 2026-10-06
Current nine-network support list and unsupported EVM networks.
Primary source; paraphrased, no source artwork reproduced.
- Phantom: Create a wallet with Google or Apple ↗2026-10-06 · checked 2026-10-06
Current onboarding; PIN conditional on wallet creation flow; local unlock differs from recovery; exportable phrase.
Primary source; paraphrased, no source artwork reproduced.
- Phantom: How your wallet is secured ↗2026-10-06 · checked 2026-10-06
Current self-custody, recovery methods, previews, blocklist, spam filtering and limits.
Primary source; paraphrased, no source artwork reproduced.
- Phantom: Supported hardware wallets ↗2026-10-06 · checked 2026-10-06
Model and connection dependent Ledger integration; no universal hardware support claim.
Primary source; paraphrased, no source artwork reproduced.
- Phantom: Ending support for Sui ↗2026-10-06 · checked 2026-10-06
Sui support ended 2026-09-24; loss of interface support does not delete onchain assets.
Primary source; paraphrased, no source artwork reproduced.
- Phantom: Ending support for Monad ↗2026-10-06 · checked 2026-10-06
Announced transition 2026-08-26; current supported-networks page excludes Monad; Sui notice related link confirms ended support. Full main article intermittently unavailable to parser.
Primary source; paraphrased, no source artwork reproduced.
- Tezos Foundation: Exploring DirectAuth on Tezos by Kukai Wallet ↗2026-10-06 · checked 2026-10-06
2020-11-06 coverage of version 1.9 DirectAuth; historically Google/Reddit/Twitter, not a present provider list.
Primary source; paraphrased, no source artwork reproduced.
- Kukai: DirectAuth ↗2026-10-06 · checked 2026-10-06
Published OAuth/Torus distributed key generation and client-side private-key reconstruction model; not guardian recovery. Documentation is legacy and not proof of current provider uptime.
Primary source; paraphrased, no source artwork reproduced.
- Kukai: Setup a New Wallet ↗2026-10-06 · checked 2026-10-06
Seed phrase and encrypted-keystore software-wallet option; separate password role.
Primary source; paraphrased, no source artwork reproduced.
- Kukai: Import & Connect ↗2026-10-06 · checked 2026-10-06
Keystore, seed and Ledger paths; legacy-vs-HD and derivation compatibility caveats; documentation contains unfinished placeholders so no exact comprehensive compatibility claim.
Primary source; paraphrased, no source artwork reproduced.
- Kukai: Connect Ledger ↗2026-10-06 · checked 2026-10-06
Live public Ledger connection page; private keys remain on device; Safari support unavailable on inspected page.
Primary source; paraphrased, no source artwork reproduced.
- Kukai source repository ↗2026-10-06 · checked 2026-10-06
Public Tezos web-wallet source; Apache-2.0 listing; links 2022 audit. Source/audit availability is not a security guarantee.
Primary source; paraphrased, no source artwork reproduced.
- ERC-4337: Account Abstraction Using Alt Mempool ↗2026-10-06 · checked 2026-10-06
UserOperation, bundler, EntryPoint, optional paymaster; current standard marked Final.
Primary source; paraphrased, no source artwork reproduced.
- EIP-7702: Set Code for EOAs ↗2026-10-06 · checked 2026-10-06
EOA delegation designator to contract code; persistent until replaced/cleared; authorization security considerations.
Primary source; paraphrased, no source artwork reproduced.
- Ethereum: Pectra ↗2026-10-06 · checked 2026-10-06
Successful Ethereum-mainnet activation 2025-05-07; EIP-7702 availability.
Primary source; paraphrased, no source artwork reproduced.
- ERC-1271: Standard Signature Validation Method for Contracts ↗2026-10-06 · checked 2026-10-06
Contract-defined signature validity; distinction from private-key-owned EOA.
Primary source; paraphrased, no source artwork reproduced.
- EIP-5792: Wallet Call API ↗2026-10-06 · checked 2026-10-06
Final interface for call batches, status and capabilities; capability negotiation not universal support.
Primary source; paraphrased, no source artwork reproduced.
- ERC-7710: Smart Contract Delegation ↗2026-10-06 · checked 2026-10-06
Draft status as checked; interoperable capability delegation proposal.
Primary source; paraphrased, no source artwork reproduced.
- ERC-7715: Request Permissions from Wallets ↗2026-10-06 · checked 2026-10-06
Draft status as checked; scoped permission request/revocation interfaces.
Primary source; paraphrased, no source artwork reproduced.
- W3C: Web Authentication Level 3 ↗2026-10-06 · checked 2026-10-06
Public-key credentials, relying-party scope, user verification; WebAuthn not itself a blockchain custody model.
Primary source; paraphrased, no source artwork reproduced.
- FIDO Alliance: Passkeys ↗2026-10-06 · checked 2026-10-06
Passkeys, phishing resistance, synced or device-bound credential modes.
Primary source; paraphrased, no source artwork reproduced.
- Fireblocks: MPC 101 ↗2026-10-06 · checked 2026-10-06
Implementer account of distributed threshold signing without assembling full key; vendor claims treated as implementation-specific.
Primary source; paraphrased, no source artwork reproduced.
- Fireblocks: Direct Custody Principles ↗2026-10-06 · checked 2026-10-06
Vendor-specific signing quorum and independent recovery design; motivates distinguishing custody from product label.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask Agent Wallet documentation ↗2026-10-06 · checked 2026-10-06
Existing CLI and programmatic wallet product; user-defined limits; version-specific chain support. No performance, profit, insurance or universal safety claim adopted.
Primary source; paraphrased, no source artwork reproduced.
- MetaMask Agent Wallet Quickstart ↗2026-10-06 · checked 2026-10-06
Existing sign-in, wallet-mode and safety-mode distinctions. Product setup instructions are not reproduced as an action invitation.
Primary source; paraphrased, no source artwork reproduced.
Editorial verification and limits
- All narrative prose, educational scenarios and diagram concepts in this package are newly written for PointCast. No source photographs, screenshots, illustrations, code samples or long quotations are reproduced.
- Product names identify subjects of commentary. They do not imply endorsement or affiliation. If third-party marks or screenshots are later added, review their own usage terms separately.
- Standards and source repositories have their own licenses. Linking and paraphrasing here does not relicense their code or artwork.
- Use named links beside claims, not a source list alone. The prose already embeds direct primary-source links; source_ids also support accessible reference rendering.
- Feature verification is dated October 6, 2026. Network support, recovery flows, hardware compatibility, standards status and regional availability can change.
- Phantom’s current canonical support articles supersede stale help pages listing Sui/Monad or claiming every social-login wallet requires a PIN. The newer login page makes PIN requirements conditional.
- Kukai’s public DirectAuth guide is legacy documentation. It supports an explanation of the published OAuth/Torus architecture, not a claim about current provider availability, production uptime or guardian recovery.
- The current MetaMask Agent Wallet pages contain differing rollout and security-detail wording across marketing, FAQ and developer pages. This package relies only on the existence of documented CLI capabilities and mode distinctions; it does not promise universal availability, simulation coverage, insured losses or transaction safety.
- No accounts were created, no wallet was connected and no transaction or signature was requested while preparing this material.