PointCast / Wallet field guide / checked 2026-10-06
Your Next Wallet, Explained
A practical map of passkeys, smart accounts, recovery and agent permissions.
Educational architecture guide, not investment advice. PointCast lessons use fictional data. They never request a recovery phrase, private key, password, wallet connection or transaction.
The future wallet is a permission dashboard
A better wallet future is easy to describe and hard to build: people should understand what they are authorizing, recover from ordinary mistakes and leave a service without losing control. That does not require one universal wallet brand. It requires understandable boundaries between identity, account rules, signing, network execution and the interfaces that display the result.
PointCast’s /wallet learning hub starts there. It is a place to compare architectures and rehearse decisions with fictional data. You can explore the material without an account, an extension or a funded address. Existing PointCast wallet sign-in can remain a separate, clearly labeled product path; a lesson should never quietly become an authorization request.
The ideas below are divided into three kinds of claim: primitives and products that exist, standards still being developed, and PointCast design proposals. That distinction is the hub’s most important interface feature. An attractive mockup should not make a future possibility look like an available security guarantee.
Sources:
Passkeys can simplify the entrance
Passkeys are already real authentication technology. They use public-key credentials and can be synced across a provider’s ecosystem or bound to a device. Their relying-party scope improves resistance to common phishing patterns. This is a meaningful advance over asking people to repeatedly type reusable passwords into websites.
For a wallet, the next question is what the passkey controls. It might unlock local access, authenticate to a recovery service or participate in the validation rules of a smart account. Those arrangements have different failure modes. A biometric gesture on a phone is the visible interaction; the recovery and custody model sits underneath it.
PointCast proposes a recovery-map panel beside any simplified sign-in explanation. It would show the original device, sync provider, alternate authenticator and account recovery rules as separate pieces. Removing one piece in the mock diagram would reveal whether access still works and why. The goal is not to frighten readers away from convenience. It is to make the dependencies visible before they become an emergency.
FIDO Alliance: Passkeys W3C: Web Authentication Level 3
Sources: FIDO Alliance: Passkeys ↗ W3C: Web Authentication Level 3 ↗
Programmable accounts can make permissions smaller
Account abstraction is already more than a research slogan. ERC-4337 specifies a UserOperation path with bundlers and EntryPoint execution. EIP-7702 is an Ethereum-mainnet capability following Pectra. These mechanisms give implementers room to offer batching, alternative authorization rules and fee arrangements, but the mechanism alone does not select a safe policy for the user.
Consider a hypothetical museum account that lets an assistant mint one attendance badge, from one approved contract, during one afternoon. That is a narrower permission than handing over unrestricted signing authority. Whether a particular wallet can actually enforce every part of that policy is an implementation question, not something the phrase “smart account” answers.
PointCast’s proposed permission card therefore has six visible fields: actor, action, target, maximum quantity, expiration and revocation path. If a system cannot enforce a field, the card says so. The reader can then distinguish an onchain constraint from an app preference or a promise in documentation. Smaller permissions are useful only when the boundary is real.
ERC-4337: Account Abstraction Using Alt Mempool EIP-7702: Set Code for EOAs MetaMask Smart Accounts Kit
Sources: ERC-4337: Account Abstraction Using Alt Mempool ↗ EIP-7702: Set Code for EOAs ↗ MetaMask Smart Accounts Kit ↗
Portability includes the exit
Wallet choice is often framed as a list of features at sign-up. A more revealing test is what happens at the exit: the app stops supporting a network, the provider closes, the original phone breaks or the user wants a different interface.
Phantom’s 2026 Sui support notice offers a concrete example. Removing a network from a wallet interface did not remove the assets from that network. But continued access still depends on a compatible control and recovery path. A portable secret is not the whole story for accounts with specialized validation code, multiple participants or provider-specific recovery arrangements.
The /wallet hub should therefore treat export and recovery as a rehearsal on paper, never as a request to paste real credentials. A mock portability checklist asks what must be known: account type, network, derivation conventions where relevant, signer arrangement and any external service needed for recovery. Readers can compare two architectures without moving a cent. A system’s graceful-exit story belongs beside its welcome screen, rather than buried in its help center.
Phantom: Ending support for Sui Kukai: Import & Connect Fireblocks: Direct Custody Principles
Sources: Phantom: Ending support for Sui ↗ Kukai: Import & Connect ↗ Fireblocks: Direct Custody Principles ↗
Agents need a small sandbox, not a magic brain
Agent wallets are already a product category. MetaMask’s current developer documentation describes an Agent Wallet CLI with programmatic balance, signing and transaction functions. Its setup distinguishes wallet modes and safety settings. That establishes a present implementation, not proof that autonomous execution is universally safe or suitable for a particular person.
PointCast’s proposed agent lab stays entirely fictional. The agent can request one practice badge from a mock museum contract, use at most five practice units and act only within a simulated session. A hostile instruction embedded in a pretend webpage asks it to change the recipient. The exercise shows why content encountered during a task must not gain the power to rewrite the user’s permission.
The desired future is inspectable delegation: a readable instruction, an enforceable boundary, a visible activity record and a way to stop further action. Better reasoning can help interpret requests, but it should not replace those controls. Nor should transaction simulation be described as predicting every future state or detecting every malicious design.
MetaMask Agent Wallet documentation MetaMask Agent Wallet Quickstart
Sources: MetaMask Agent Wallet documentation ↗ MetaMask Agent Wallet Quickstart ↗
Standards are a map, not a universal feature flag
A wallet ecosystem needs common interfaces if apps are to ask for capabilities without guessing at each brand’s internals. EIP-5792, marked Final when checked, defines methods for submitting groups of calls, checking their status and querying wallet capabilities. A capability query is important precisely because a caller cannot assume every wallet supports the same behavior.
Other pieces remain in progress. ERC-7710’s delegation interface and ERC-7715’s wallet permission-request interface were both marked Draft on October 6, 2026. Implementations can experiment with draft standards, and a product can ship a related feature before a standard reaches Final. Neither situation turns draft text into an ecosystem-wide guarantee.
The hub’s status labels should say Implemented protocol capability, Documented product feature, Draft standard or PointCast concept. Every label links to evidence and carries a check date. This keeps the future section interesting without flattening an active engineering debate into a launch announcement. Readers can follow the direction of travel while seeing which bridges are already built.
EIP-5792: Wallet Call API ERC-7710: Smart Contract Delegation ERC-7715: Request Permissions from Wallets
Sources: EIP-5792: Wallet Call API ↗ ERC-7710: Smart Contract Delegation ↗ ERC-7715: Request Permissions from Wallets ↗
A practical decision framework
Begin with the activity, not the mascot. A person only inspecting public records may need a block explorer or watch-only view. A person using a particular app needs compatibility with that app’s actual network and account requirements. A group managing a shared account needs a deliberate policy for authority changes and recovery, not merely several copies of one secret.
Then draw three diagrams: normal use, device loss and service failure. For each, identify which participants are required and what each can do. Ask whether the interface clearly distinguishes a connection from a message signature, an asset allowance and a code delegation. Ask where fees are paid and whether a displayed estimate includes any separate service charge.
Finally, inspect the evidence behind the reassuring parts. Is an audit tied to a specific implementation and version? Is a preview informational or enforced? Does hardware support include the exact device and network? Can permissions expire, and can revocation actually stop future actions? These questions do not yield a universal best wallet. They produce a more useful result: a set of explicit tradeoffs matched to the task.
Sources:
A quieter kind of progress
The future wallet may become less visually prominent as authentication and account rules blend into everyday applications. That can be good design when it removes irrelevant ceremony. It becomes poor design when it removes the moment at which a person understands that a new party can act on their behalf.
PointCast’s proposal is a compact control panel with a long memory: a clear summary of current powers, a history of changes, and a recovery explanation that can be understood before it is needed. Our pixel-art vocabulary gives each dependency a recognizable shape, but the labels remain textual and accessible. Animation illustrates a transition; it never replaces the explanation.
A good next step is available right now: practice on the mock permission cards below. Explain the proposed action, identify the trust boundary and decide which missing fact prevents an informed decision. There is no speed bonus and no leaderboard for taking risks. The useful achievement is leaving the page able to ask a better question.
Sources:
Dated evidence / checked 2026-10-06
Shipped, documented, draft or proposed?
Implemented protocol capability
EIP-7702 on Ethereum mainnet
Activated with Pectra in May 2025; contract delegation persists until changed or cleared. Wallet and chain support still vary.
Deployed architecture / Final specification
ERC-4337
UserOperations, bundlers and EntryPoint-based account abstraction. Specific account features depend on implementation.
Established authentication technology
Passkeys
WebAuthn-based credentials, synced or device-bound. Their wallet role depends on the surrounding account design.
Documented product feature
MetaMask smart accounts
Consumer help documents current capability and explicitly distinguishes general benefits that have not all shipped.
Documented product
Agent Wallet CLI
MetaMask publishes current setup and command documentation. This is not a guarantee of safety, returns or universal availability.
MetaMask Agent Wallet documentation ↗ MetaMask Agent Wallet Quickstart ↗
Draft standard
ERC-7710 and ERC-7715
Delegation and wallet permission-request interfaces remain Draft as checked.
ERC-7710: Smart Contract Delegation ↗ ERC-7715: Request Permissions from Wallets ↗
PointCast concept
Permission Lab and Recovery Map
Educational simulations proposed below. They do not connect, sign, transact or create real accounts.
Seven questions before choosing a tool.
What is the actual task?
Network, app, asset identifier and supported account type; consider a read-only view when no authorization is needed.
Who can authorize ordinary actions?
Local signer, hardware device, multiple keys, threshold participants or contract policy.
How does recovery work?
Required devices, secrets, identity providers, guardians, quorum and service availability.
Which permission is being granted?
Connection, signature, token allowance, account code delegation or another scoped permission.
Who pays and what can fail?
Network fee, separate service charge, sponsor conditions and failed-execution behavior.
How do I leave?
Compatible alternative interfaces, derivation/account information and independent recovery where applicable.
What evidence supports the claim?
Current official documentation, implementation details and version-specific audits; never a security superlative alone.
University of El Segundo / self-guided practice
Wallets: Access, Authority and Recovery
PointCast’s self-guided educational project. Not an accredited institution or degree program.
- Explain why assets are recorded onchain rather than inside an app
- Distinguish keys, accounts, addresses and recovery methods
- Separate connect, sign, approve, permit, disconnect and revoke
- Compare MetaMask, Phantom and Kukai using dated evidence
- Explain account abstraction without confusing available primitives and future features
- Design a bounded, inspectable mock agent permission
Exercise 1 / 5 minutes
Name the power
Distinguish connection, signature and continuing authority.
A fictional gallery asks to view account PC-PLAYER, then asks for permission to spend 20 practice tickets. Which request changes a token allowance, and which can be removed just by disconnecting the site?
- account
- PC-PLAYER
- token
- PRACTICE-TICKET
- allowance
- 20
- network
- SIM-NET
Compare your reasoning
The spending request changes the allowance. Disconnecting removes the app connection, not the already granted allowance.
- Names both mechanisms
- Explains why closing the tab is insufficient
- Does not infer that a free signature is harmless
ERC-20: Token Standard ↗ MetaMask: Revoke smart contract allowances/token approvals ↗ ERC-2612: Permit Extension for ERC-20 Signed Approvals ↗
Exercise 2 / 7 minutes
A fee-free signature?
Read meaningful fields in a signed permission.
A mock message names owner PC-PLAYER, spender PC-GALLERY, value 50, nonce 3 and a submission deadline tomorrow. No network fee is charged when it is signed. Explain why this can still matter.
Compare your reasoning
A signature can authorize a permit submitted later to set an allowance. The absence of an immediate fee does not establish the absence of authority. Verify the intended spender, amount, domain and deadline in the mock record. The deadline limits when the signed permit can be submitted. An allowance already created does not automatically expire at that deadline.
- Identifies later submission
- Names scope and submission deadline
- Separates message signing from transaction submission
- Explains that the created allowance does not automatically expire at the permit submission deadline
ERC-2612: Permit Extension for ERC-20 Signed Approvals ↗ EIP-712: Typed structured data hashing and signing ↗
Exercise 3 / 10 minutes
Recover the explanation
Separate local unlock from account recovery.
Compare a fictional local app password, a mnemonic passphrase and a Google-login recovery dependency. Sketch what each protects. Use labels only; never use personal credentials.
Compare your reasoning
A local unlock password protects one app instance or encrypted local data. A mnemonic passphrase participates in seed derivation. A login dependency authenticates to a service-defined access or recovery path. The exact product determines what else is required.
- Does not call all three passwords interchangeable
- Shows the device boundary
- States what is unknown about the hypothetical service
BIP-39: Mnemonic code for generating deterministic keys ↗ MetaMask: How social login works ↗ Phantom: Create a wallet with Google or Apple ↗
Exercise 4 / 5 minutes
Remove a network
Distinguish an interface from the ledger.
The mock wallet removes SIM-NET-B from its supported list. The separate ledger still shows PC-PLAYER’s record. What changed, and what has not been established?
Compare your reasoning
The interface lost support. The ledger record did not disappear. Whether another interface can access it depends on a compatible account and recovery path; the display alone does not prove recovery is available.
- Identifies interface-only change
- Does not claim assets were deleted
- Names compatibility as a separate requirement
Exercise 5 / 12 minutes
Give a robot a small job
Design bounded delegation without trusting a model to police itself.
A fictional assistant may collect one free attendance badge from PC-MUSEUM during a simulated hour. Define target, action, quantity, expiry, revocation and what requires a new approval. Then insert a pretend webpage instruction asking it to change recipient.
Compare your reasoning
The original bounded permission remains authoritative. The webpage cannot expand it. A policy boundary should reject the changed recipient and any extra action; a human can separately consider a new request. No real agent or wallet is involved.
- All six fields are explicit
- Distinguishes user policy from encountered content
- Explains enforcement location and failure behavior
ERC-7710: Smart Contract Delegation ↗ ERC-7715: Request Permissions from Wallets ↗ MetaMask Smart Accounts Kit ↗
Exercise 6 / 8 minutes
Audit the claim
Distinguish present capability from future possibility.
Sort four cards: “EIP-7702 activated on Ethereum mainnet,” “ERC-7715 is Draft,” “this smart account supports guardians,” and “PointCast will display every permission.” Which claims are established by the provided sources and which require implementation evidence?
Compare your reasoning
The first two are sourced status claims. Guardian support requires evidence for the particular implementation. The PointCast claim is a proposed product behavior until implemented and tested.
- Does not infer universal product support from a standard
- Uses the verification date
- Recognizes the difference between design intent and working behavior
Ethereum: Pectra ↗ ERC-7715: Request Permissions from Wallets ↗ MetaMask: What is a smart account ↗
Exercise 7 / 25 minutes
Design a wallet’s pause screen
Synthesize a readable permission and recovery interface.
Create a paper or static-screen design for a fictional community archive. It should show current permissions, the payer for one proposed action, a recovery-dependency map and an exit explanation. Include a paragraph on what the design cannot guarantee.
Compare your reasoning
There is no single correct visual solution. A successful design clearly labels the account and network; shows actor, scope, target, quantity and duration; separates local connections from ledger permissions; and communicates recovery dependencies without collecting credentials.
- Authority is readable without color alone
- Both normal use and failure are explained
- Unknowns and implementation assumptions are stated
- No prompt asks for secrets or real transactions
Self-assessed practice. No credential, qualification, token reward, investment action or live-wallet activity is required.
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.