{ "title": "Questions worth understanding", "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "status": "published edition", "articles": [ { "slug": "eip-7702-wallet-delegation", "title": "Your wallet has an “upgrade” button. What are you agreeing to?", "searchTitle": "EIP-7702 wallet delegation: permissions, revocation and checks", "category": "Wallet permissions", "accent": "#e6ba80", "diagram": "delegation", "interactive": "permissions", "summary": "An Ethereum wallet upgrade can let code act through your existing account. That can make payments easier, but it is a lasting change in how the account works. Closing the app or disconnecting a website does not undo it.", "why": "As wallets bundle payments and offer sponsored fees, more people may encounter account upgrades without recognizing the permission involved. The lasting reader question is how to identify and remove each kind of access.", "overlap": "The existing smart-account and token-approval entries introduce the mechanisms. This guide addresses the specific upgrade decision, persistent delegation and the difference between three removal actions.", "related": [ "ethereum-smart-accounts", "ethereum-token-approvals", "ethereum-wallet-requests" ], "sections": [ { "id": "same-address", "heading": "The address stays familiar; its behavior changes", "sourceIds": [ "7702" ], "paragraphs": [ "Imagine opening the wallet you have used for years and seeing an offer to combine several steps into one. The address need not change. What changes is the code Ethereum uses when that account is called. The mechanism is called EIP-7702 delegation: the account points to a deployed program that supplies its behavior.", "A well-designed program can support batched actions, fee sponsorship or limited permissions. Those features belong to the particular program and its configuration. An upgrade label alone does not tell you which protections it implements. Treat the request as a choice of account software, with consequences beyond the transaction on screen." ] }, { "id": "three-permissions", "heading": "Connection, token approval and delegation are different", "sourceIds": [ "erc20", "7702" ], "paragraphs": [ "Connecting a website lets it communicate with your wallet through the access you allow. A token approval is an on-chain allowance: a named spender can use a specified token up to the amount authorized under that token’s rules. Many Ethereum tokens use the common interface called ERC-20 for this. Delegation changes the code used by the account itself.", "These permissions live in different places. Disconnecting a site does not clear an ERC-20 allowance. Clearing account delegation does not, by itself, erase allowances recorded in token contracts. A cleanup screen that reports one category as empty has answered only that category’s question.", "This distinction is useful even when nothing has gone wrong. You may want to stop using one application while keeping a trusted account program, or remove an old token allowance without changing your wallet setup." ] }, { "id": "lasting-change", "heading": "A failed transaction can still leave the upgrade in place", "sourceIds": [ "7702" ], "paragraphs": [ "Delegation persists until it is replaced or cleared. The protocol processes the authorization before the transaction’s execution, and an execution failure does not roll back a delegation it already processed. A failed swap is therefore not enough evidence that the account change failed too.", "After an unexpected result, inspect the account’s current delegation on the relevant network using a wallet or explorer that exposes it. Record the target address and compare it with the wallet provider’s official documentation. A familiar contract name is a label; the exact address and deployed code are what matter." ] }, { "id": "scope", "heading": "Read the network scope and the program behind the promise", "sourceIds": [ "7702", "4337" ], "paragraphs": [ "The authorization identifies a target program, a network scope and an account counter called a nonce. A chain ID of zero permits use across chains where the authorization otherwise remains valid; a specific chain ID narrows its scope. This does not mean the same program exists or behaves identically everywhere.", "A spending cap shown in a wallet interface is not a cap imposed by EIP-7702 itself. It has to be enforced by the delegated account’s implementation. Likewise, a sponsor paying today’s fee is a service arrangement. It does not establish that the sponsor will fund your next transaction.", "Before accepting, find the provider’s explanation of the target program, the permissions it supports and the supported way to return to an undelegated account. If the wallet cannot explain the change clearly, you can leave the request unsigned while you investigate." ] }, { "id": "removal", "heading": "Removing code is one step in understanding access", "sourceIds": [ "7702", "erc20" ], "paragraphs": [ "The protocol includes a way to clear delegation through a valid authorization to the zero address. Use the wallet’s documented flow and verify the resulting account state; do not interpret this as instructions to send money to the zero address.", "Removing a delegation does not recover a disclosed signing key, cancel every separate signature, or reverse completed transfers. If another person has the key, they may be able to authorize a new change. That is a different problem from an unwanted program chosen while the key remained private.", "Keep a small record of the account, network, old target, removal transaction and observed result. Then inspect token allowances and any remaining application permissions separately. You are building a clear picture of access, rather than relying on one reassuring status badge." ] } ], "example": { "title": "The swap failed, but what happened to the account?", "paragraphs": [ "In this fictional example, Lena authorizes a wallet program and tries to swap 40 tokens in the same transaction. The authorization is valid, but the swap reverts because its price condition cannot be met.", "She should check two results: whether the swap moved tokens, and whether the account now delegates to the program. The failed execution can leave the second result in place. If she later disconnects the swap website, that does not answer the delegation question either." ] }, "table": { "headers": [ "Action", "What it addresses", "What still needs checking" ], "rows": [ [ "Disconnect website", "That website’s wallet connection", "On-chain allowances and delegation" ], [ "Revoke token allowance", "A token’s permission for a spender", "Other tokens and account code" ], [ "Clear delegation", "The account’s delegation indicator", "Key security, token allowances and other signatures" ] ] }, "checklist": [ "Identify the account, network and exact delegation target.", "Read what the program can do and how its limits are enforced.", "Check the current account state after both successful and failed execution.", "Use the provider’s documented removal flow; review token allowances separately." ], "figure": { "title": "Three permissions, three places to check", "caption": "A conceptual map of access. Removing one permission does not automatically remove the others.", "description": "A website connection, token allowance and account delegation appear as three separate branches. Each branch has its own removal action." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "5901c6a5e0b146f1ba4372cd459eabe7a502bfed21bfc28ac81b0ff2e9168c62", "status": "verified by separate automated source review", "sources": [ { "id": "7702", "title": "EIP-7702: Set Code for EOAs", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-7702", "locator": "Behavior; Persistence of code delegation; Interaction with applications and wallets; Security Considerations", "scope": "Protocol rules for delegation persistence, clearing and execution. It does not certify a wallet implementation.", "retrieval": { "id": "7702", "url": "https://eips.ethereum.org/EIPS/eip-7702", "finalUrl": "https://eips.ethereum.org/EIPS/eip-7702", "retrievedAt": "2026-10-02T21:37:35.905114+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/7702.source", "sha256": "a63b7d68b0da3dc668dc99459c66b824a5ef4447a5ae4b1687faafe284f64a61", "text": "evidence/7702.txt", "textSha256": "bf9a3ff992eb37929763f84a8893fd29046950115181636b31c9d9b97986deda" } }, { "id": "erc20", "title": "ERC-20: Token Standard", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-20", "locator": "approve, allowance and transferFrom", "scope": "The token allowance interface, separate from account delegation.", "retrieval": { "id": "erc20", "url": "https://eips.ethereum.org/EIPS/eip-20", "finalUrl": "https://eips.ethereum.org/EIPS/eip-20", "retrievedAt": "2026-10-02T21:37:35.905459+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/erc20.source", "sha256": "98bda5e4707841a68684879878c4c165fdaa47d89ed69ebf232ab9be06ff050e", "text": "evidence/erc20.txt", "textSha256": "f8d11f24fa5eb68a9f5d50d07cd1cdf7b4a8809eb2b2245856957ee9bce040f8" } }, { "id": "4337", "title": "ERC-4337: Account Abstraction Using Alt Mempool", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4337", "locator": "Definitions; EntryPoint; Paymasters; First-time account creation", "scope": "Account operations and infrastructure roles. Support differs by deployed account and version.", "retrieval": { "id": "4337", "url": "https://eips.ethereum.org/EIPS/eip-4337", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4337", "retrievedAt": "2026-10-02T21:37:35.905547+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4337.source", "sha256": "ba69db925f98b811c8b73915af67c25fa70fc8d5d8c8f2c4166ab376e0fcb115", "text": "evidence/4337.txt", "textSha256": "af464789bffb51a4c451b1ec5053a2e58a90f33f1c38f06bf8a0d6a2963e62eb" } } ], "canonical": "https://degreesofsatoshi.com/guides/eip-7702-wallet-delegation/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "5901c6a5e0b146f1ba4372cd459eabe7a502bfed21bfc28ac81b0ff2e9168c62" } }, { "slug": "smart-wallet-portability-provider-shutdown", "title": "Could you still use your wallet if its app disappeared?", "searchTitle": "Smart wallet portability: access if your provider shuts down", "category": "Access and recovery", "accent": "#94d6bf", "diagram": "portability", "summary": "A backup can preserve a signing credential while leaving you without a practical way to use the account. For a smart wallet, portability means being able to identify the account, meet its authorization rules and submit a transaction through another supported route.", "why": "Wallets increasingly combine passkeys, account contracts and hosted services. If these designs spread, people will need to judge whether access survives a provider outage or a product being discontinued.", "overlap": "Existing recovery articles focus on lost access and credentials. This guide evaluates provider-independent operation while access still works, including contract configuration and transaction submission.", "related": [ "smart-account-recovery", "smart-account-bundlers", "smart-account-paymasters" ], "sections": [ { "id": "parts", "heading": "Start by separating the app from the account", "sourceIds": [ "4337", "safe" ], "paragraphs": [ "Your wallet app is the screen you use. The account is the object the network recognizes. A signer provides the authorization, and additional services may read balances, prepare requests or submit them. One company can supply several of these parts, which makes them feel like one thing.", "A smart account is governed by code. An exported key might be one authorized signer, one part of a threshold, or no longer authorized at all. Restoring that key in another app does not automatically recreate the original contract’s transaction format or recovery features.", "Start with a small account record: network, account address, account implementation or version, authorized signers and the rules for approval. Keep secret credentials out of that record. A map of the setup is valuable, but it is not a substitute for the protected material required to authorize transactions." ] }, { "id": "credential", "heading": "“I have my passkey” answers only part of the question", "sourceIds": [ "passkeys", "4337" ], "paragraphs": [ "Some passkeys synchronize through a credential provider; others remain bound to a device. That difference matters if you lose a phone. It does not by itself establish whether another wallet app can use the credential to authorize the same blockchain account.", "Ask the wallet provider for a documented alternative access path. Which supported tool can locate the account? Can it use your signer? Does the account require a provider-controlled cosigner or recovery service? If a dependency cannot be replaced, write it down as an unresolved dependency rather than assuming the word self-custody settles the matter.", "An extra device may help with device loss while doing little for a provider outage. Those are separate failure scenarios, so they deserve separate checks." ] }, { "id": "configuration", "heading": "The rules can matter as much as the keys", "sourceIds": [ "safe" ], "paragraphs": [ "Safe provides a concrete example: its accounts have owners and an approval threshold. A two-of-three owner arrangement requires two qualifying owner signatures for its ordinary transaction path. Optional code extensions, called modules, can introduce additional ways to execute transactions. Guards are checks that can block a transaction.", "This is why an inventory should include configuration, not only an owner list. A guard that blocks a transaction or a module with its own authority can change the practical answer to “can I move these funds?” Other account designs use different structures; use the documentation for the account actually deployed.", "Avoid changing signers or disabling protections merely to test portability. First learn what the current setup requires and which supported alternative can reproduce it." ] }, { "id": "submission", "heading": "Someone still has to get the request onto the network", "sourceIds": [ "4337" ], "paragraphs": [ "One common design for submitting smart-account requests is specified in ERC-4337. In that flow, software called a bundler submits account operations through a coordinating contract called EntryPoint. A separate service contract called a paymaster can sponsor fees. These are distinct jobs: having a usable signer does not make a bundler available, and having a bundler does not guarantee sponsorship.", "A portability plan should explain the fallback for each service. Can the account use another compatible bundler? Can it pay its own fees under its implementation? Which EntryPoint version does the alternative support? Do not assume every smart account offers a direct transaction path or that every provider can process its operations.", "Ask for a worked recovery procedure for the specific account version. An architecture diagram is helpful; a supported procedure you can actually rehearse is stronger evidence." ] }, { "id": "rehearsal", "heading": "Rehearse with a separate, low-value setup", "sourceIds": [ "safe", "4337", "passkeys" ], "paragraphs": [ "Create a separate test account with the same account design, where the provider supports that. Practice identifying it from your account record and using the documented alternative interface. If a test network is available, it can help you learn the steps, though it does not prove production services will behave the same way.", "A meaningful rehearsal reaches a verified result: the intended account authorized the request, the network processed it and the destination received the expected test asset. Seeing the right balance on another screen proves much less.", "Record which services were still involved. If the alternative interface silently used the original provider’s server, you have tested an interface change rather than provider independence. That is still useful information; it tells you which question remains open." ] } ], "example": { "title": "Two backups, one hidden dependency", "paragraphs": [ "A fictional club uses an account with three owners and a two-signature threshold. Two members keep usable credentials on separate devices. They assume that is enough for an outage.", "Their rehearsal finds that the alternative tool cannot construct the transaction format used by their account version. The credentials are intact, but the club has not demonstrated an exit route. Its next task is to identify compatible submission software while the original service is still available.", "A second club uses a compatible tool and successfully submits a small test transaction without the original service. That supports a narrower, useful conclusion: this configuration and procedure worked at the time of the rehearsal. It is worth repeating after a material account upgrade." ] }, "table": { "headers": [ "What you retain", "What it helps with", "What it does not establish" ], "rows": [ [ "Credential backup", "Restoring a signer", "That the signer alone controls the account" ], [ "Account configuration", "Finding the correct authorization rules", "That compatible software remains available" ], [ "Alternative submission route", "Reaching the network", "That fees will be sponsored" ], [ "Recorded rehearsal", "Evidence of a working procedure", "A permanent guarantee after upgrades" ] ] }, "checklist": [ "Record the account address, network, version and authorization rules.", "Identify dependencies on cosigners, recovery services, bundlers and fee sponsors.", "Use a separate test account to rehearse the documented alternative route.", "Retest after material changes and keep the result with your account record." ], "figure": { "title": "What has to survive an app shutdown?", "caption": "Each layer needs a usable path. A credential backup covers only one layer of this conceptual stack.", "description": "Four layers show the credential, account rules, compatible transaction software and network submission. A side path shows an alternative interface reaching the same account." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "80a977e7685f927eb6493b365b2d361601dcc518466baf153a105b93588b9500", "status": "verified by separate automated source review", "sources": [ { "id": "4337", "title": "ERC-4337: Account Abstraction Using Alt Mempool", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4337", "locator": "Definitions; EntryPoint; Paymasters; First-time account creation", "scope": "Account operations and infrastructure roles. Support differs by deployed account and version.", "retrieval": { "id": "4337", "url": "https://eips.ethereum.org/EIPS/eip-4337", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4337", "retrievedAt": "2026-10-02T21:37:35.905547+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4337.source", "sha256": "ba69db925f98b811c8b73915af67c25fa70fc8d5d8c8f2c4166ab376e0fcb115", "text": "evidence/4337.txt", "textSha256": "af464789bffb51a4c451b1ec5053a2e58a90f33f1c38f06bf8a0d6a2963e62eb" } }, { "id": "safe", "title": "Smart Account Concepts", "publisher": "Safe", "url": "https://docs.safe.global/advanced/smart-account-concepts", "locator": "Owners; Threshold; Signature verification; Module Transaction; Safe Guards", "scope": "Safe-specific architecture, used as an example rather than a universal wallet design.", "retrieval": { "id": "safe", "url": "https://docs.safe.global/advanced/smart-account-concepts", "finalUrl": "https://docs.safe.global/advanced/smart-account-concepts", "retrievedAt": "2026-10-02T21:37:35.905627+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/safe.source", "sha256": "f3ee1776f5200e68212ffb41f51761405cea7e2ceb920113bfc54bab3adc085e", "text": "evidence/safe.txt", "textSha256": "d5b42f9f7d323dc8ac2688dea4eb16bd8a677c2c93ca6f84949042280f41235b" } }, { "id": "passkeys", "title": "Passkeys", "publisher": "FIDO Alliance", "url": "https://fidoalliance.org/passkeys/", "locator": "Synced passkeys and device-bound passkeys", "scope": "Authentication credentials and their recovery models; not a guarantee of blockchain account portability.", "retrieval": { "id": "passkeys", "url": "https://fidoalliance.org/passkeys/", "finalUrl": "https://fidoalliance.org/passkeys/", "retrievedAt": "2026-10-02T21:37:35.905709+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/passkeys.source", "sha256": "781fff7c38fe5800800d7a49d9bec452bd6ae4a2533936759492f98a0cde7004", "text": "evidence/passkeys.txt", "textSha256": "11b5e15c9f2a728f41dd9fae8b440050f0c97ed3cfd0d3d1d9818c0de01bcec3" } } ], "canonical": "https://degreesofsatoshi.com/guides/smart-wallet-portability-provider-shutdown/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "80a977e7685f927eb6493b365b2d361601dcc518466baf153a105b93588b9500" } }, { "slug": "prove-age-without-sharing-identity", "title": "Can you prove your age without handing over your identity?", "searchTitle": "Private age proofs: verifiable credentials and selective disclosure", "category": "Identity and privacy", "accent": "#bdb0f4", "diagram": "disclosure", "interactive": "disclosure", "summary": "A service may need to know that you meet an age threshold without needing your name, address or full birth date. Digital credentials can support that narrower disclosure, but the issuer, proof format and service all have to support it. A “verified” badge alone does not tell you what was shared.", "why": "Age checks and digital credentials create a recurring privacy question: how can someone demonstrate eligibility while sharing less? The need is durable even if particular wallet products or legal requirements change.", "overlap": "The current catalogue explains soulbound tokens and public-chain privacy. This article follows a private credential presentation and distinguishes a signed age flag from proving a condition about a hidden birth date.", "related": [ "soulbound-tokens", "eip-712-typed-data", "ethereum-rpc-privacy" ], "sections": [ { "id": "question", "heading": "Begin with the question the service needs answered", "sourceIds": [ "vc" ], "paragraphs": [ "Suppose a fictional service requires users to be at least 18. A photograph of an identity document may reveal much more: full name, birth date, document number and address. The useful design question is whether the service can receive reliable evidence of the age condition while receiving fewer personal details.", "There are three roles. An issuer makes a claim, a holder keeps the credential, and a verifier checks a presentation of it. A school, government agency or other organization might act as an issuer, but the verifier must decide which issuers it trusts for the particular claim.", "Cryptographic verification can show that a claim came from a certain signing key and was not changed in the protected message. It cannot make an issuer’s factual mistake true. Acceptance therefore needs both a valid proof and an appropriate source of the claim." ] }, { "id": "selective", "heading": "Choosing fields is different from proving a new condition", "sourceIds": [ "bbs", "vc" ], "paragraphs": [ "Some credential formats let the holder reveal selected signed claims and keep other claims hidden. This is selective disclosure. For example, if an issuer has signed an “age at least 18” claim, a supporting wallet can present that claim without also revealing a signed postal address.", "That is different from taking a credential that contains only a birth date and proving a mathematical condition about the hidden date. Such a proof needs a mechanism that supports the condition. Do not assume every product advertising private proofs can do arbitrary comparisons.", "The W3C’s BBS specification describes ways to disclose selected information while generating fresh proofs that need not reveal they came from the same credential. The version retrieved for this article is a Candidate Recommendation Draft dated 10 September 2026. That is work in progress, not a claim that every credential wallet implements it or that every verifier accepts it." ] }, { "id": "metadata", "heading": "A small proof can still leave a trail", "sourceIds": [ "bbs", "status" ], "paragraphs": [ "Keeping your name out of a presentation helps, but privacy also depends on the surrounding request. A repeated identifier, a rare combination of attributes, the account you are signed into or the timing of a request can connect activity across services.", "A verifier may also need to check whether a credential has been revoked or suspended. A status design that contacts the issuer with a uniquely identifying query can reveal use patterns. The W3C Bitstring Status List design addresses status information in shared lists and discusses correlation risks; using a list does not remove every way to track a person.", "Ask what the verifier logs, whether the issuer learns each presentation, and whether the same identifier is reused. The privacy of the proof and the privacy of the whole service are related questions, but they are not interchangeable." ] }, { "id": "blockchain", "heading": "A private credential need not become a public token", "sourceIds": [ "vc" ], "paragraphs": [ "The W3C credential model does not require publishing your identity document or each presentation to a public blockchain. The systems used to discover issuer information or check status can vary. Putting a personal identifier on a public chain is a separate design decision with separate consequences.", "If a wallet offers to mint a credential as a token, ask why that public record is needed. Can it connect your eligibility check to a payment address? Can the same task be completed with a presentation shared only with the intended verifier? A public token and a private proof solve different problems.", "Likewise, proving age does not necessarily prove that one person has only one account. A system trying to prevent duplicate registrations needs an additional design for that goal. Sharing less personal information does not remove the need to define exactly what is being proven." ] }, { "id": "request", "heading": "Read a proof request as a request for information", "sourceIds": [ "vc", "bbs" ], "paragraphs": [ "Before approving, look for the service identity, the exact claims requested and the purpose shown. If the request asks for a full birth date when the service describes only an age threshold, the mismatch deserves an explanation. You can decline while you find out whether a narrower presentation is supported.", "A useful consent screen distinguishes what will be revealed from what remains hidden and what metadata accompanies the presentation. It should also explain what happens if the credential is expired or unavailable, without implying that the reader has done something wrong.", "The practical aim is modest and valuable: disclose what the task needs, understand what else travels with it, and keep a record of what you agreed to share." ] } ], "example": { "title": "One eligibility check, two different disclosures", "paragraphs": [ "A fictional credential contains five fields: name, address, birth date, document number and an issuer-signed “18 or older” claim. The example service accepts that issuer and needs only the last claim.", "Presenting all five fields exposes four unnecessary fields for this task. Presenting the supported age claim exposes one of the five example fields. That count is not a privacy score: issuer information, proof metadata and network activity may still be visible.", "If the credential does not contain the age claim and the wallet cannot generate an accepted proof about the birth date, selecting a checkbox cannot create that capability. The service and credential format must support the narrower route." ] }, "table": { "headers": [ "Approach", "What the service can learn", "Important limit" ], "rows": [ [ "Full document image", "The visible document fields", "May disclose more than the task needs" ], [ "Selected signed age claim", "The age flag and presentation metadata", "Requires a signed claim and compatible proof" ], [ "Proof about a hidden birth date", "A supported age condition and proof metadata", "Requires a suitable proof system; not universal" ] ] }, "checklist": [ "Check which issuer the service accepts and why.", "Read the exact claims and identifiers requested.", "Ask how status checks and repeated presentations affect privacy.", "Keep public wallet addresses separate from identity proofs unless linking them is needed and understood." ], "figure": { "title": "Prove the condition. Keep the extra details.", "caption": "A fictional selective-disclosure example using an issuer-signed age flag. It is not a live identity check or a demonstration of arbitrary range proofs.", "description": "A credential has five example fields. Only the age-at-least-18 field travels through a proof to a service; name, address, birth date and document number stay with the holder." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "b7c035aeee767954c7572ddea0fca80835f8a936f8797a0baf897da2f7460980", "status": "verified by separate automated source review", "sources": [ { "id": "vc", "title": "Verifiable Credentials Data Model v2.0", "publisher": "W3C", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "locator": "Ecosystem Overview; Trust Model; Privacy Considerations", "scope": "Issuer, holder and verifier roles; privacy and trust limits. A data model is not a universal acceptance rule.", "retrieval": { "id": "vc", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "finalUrl": "https://www.w3.org/TR/vc-data-model-2.0/", "retrievedAt": "2026-10-02T21:37:36.177438+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/vc.source", "sha256": "a9196a3d0b6601356c4e127bad24f8c7f2c17f6ed22e41b35755a910104156f8", "text": "evidence/vc.txt", "textSha256": "aaf9d9fb66b3f91ca5e2d78dd80b25653a107d99b65fdf887fc048ac26a9df6e" } }, { "id": "bbs", "title": "Data Integrity BBS Cryptosuites v1.0", "publisher": "W3C", "url": "https://www.w3.org/TR/vc-di-bbs/", "locator": "Introduction; Selective Disclosure; Privacy Considerations", "scope": "Candidate Recommendation Draft dated 10 September 2026. A selective-disclosure mechanism, not universal wallet support or arbitrary range-proof support.", "retrieval": { "id": "bbs", "url": "https://www.w3.org/TR/vc-di-bbs/", "finalUrl": "https://www.w3.org/TR/vc-di-bbs/", "retrievedAt": "2026-10-02T21:37:36.297880+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/bbs.source", "sha256": "b61fcd72506d689095ddbf001d338c81e137724584373e00dae65a3a30a441f5", "text": "evidence/bbs.txt", "textSha256": "2d3cea02f34b461ce612061164e6b038747842144327259d65f7f5c8a1c18ae5" } }, { "id": "status", "title": "Bitstring Status List v1.0", "publisher": "W3C", "url": "https://www.w3.org/TR/vc-bitstring-status-list/", "locator": "Privacy Considerations; Herd Privacy", "scope": "Status checking and correlation considerations, not a promise that a deployment is private.", "retrieval": { "id": "status", "url": "https://www.w3.org/TR/vc-bitstring-status-list/", "finalUrl": "https://www.w3.org/TR/vc-bitstring-status-list/", "retrievedAt": "2026-10-02T21:37:36.298080+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/status.source", "sha256": "3cdf3358a09f3b02f2a97e5dac13cf2b63115c2db1260bf7b7c236d8702924ec", "text": "evidence/status.txt", "textSha256": "36b9a134f731590654d3073ca30e1738dede4cbfb2b82af55a9f979bcd304c67" } } ], "canonical": "https://degreesofsatoshi.com/guides/prove-age-without-sharing-identity/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "b7c035aeee767954c7572ddea0fca80835f8a936f8797a0baf897da2f7460980" } }, { "slug": "blockchain-data-permanence-archives", "title": "“On the blockchain” does not mean someone will host it forever", "searchTitle": "Blockchain data permanence: blobs, history pruning and archives", "category": "Records and evidence", "accent": "#8fcfe8", "diagram": "retention", "summary": "A blockchain can help you check whether data matches a committed record. It does not follow that every node will keep every byte, or that a linked image will remain available. Long-term access needs people or services that retain the underlying data.", "why": "Cheaper blockchain data, rollups and tokenized records make retention an increasingly useful question. Readers need to distinguish verifiable records from an ongoing storage service.", "overlap": "Existing entries explain blobs and NFT metadata. This guide brings storage responsibilities together into a preservation workflow for someone who needs to retrieve and explain a record years later.", "related": [ "ethereum-blobs-data-availability", "nft-metadata", "bitcoin-merkle-proofs" ], "sections": [ { "id": "three-jobs", "heading": "Keeping, finding and checking are three different jobs", "sourceIds": [ "4844", "ipfs" ], "paragraphs": [ "Imagine a receipt stored in a file, with a cryptographic commitment recorded elsewhere. A commitment binds to particular data so that a suitable check can detect a mismatch. It is not a compressed backup from which the original file can be recovered.", "Three jobs have to succeed. Someone must retain the bytes. You need a way to find and retrieve them. Then you need enough information to verify what they are. A system can be strong at verification and weak at retrieval.", "This helps explain a common frustration: an identifier still exists, but the page or file behind it does not load. The identifier has not necessarily become invalid. The service that supplied the content may have stopped retaining it or stopped serving your request." ] }, { "id": "blobs", "heading": "Data available for validation is not a permanent archive", "sourceIds": [ "4844" ], "paragraphs": [ "Ethereum can carry batches of data for other systems to read and check. Those batches are called blobs. They are especially useful to rollups: systems that process transactions outside Ethereum’s main execution environment while relying on Ethereum for parts of their data and settlement design. Blob data travels separately from ordinary transaction data, and commitments connect it to the chain.", "The EIP-4844 design specifies a bounded period during which the separate blob data must be served. That means “the network made this data available” and “I can ask any node for it years later” are different statements. A rollup or archive service may retain copies beyond the required window.", "Avoid treating an old retention number in an article as a permanent guarantee. Network rules, client versions and service policies can change. For a real preservation task, record the applicable rule and the archive’s stated coverage on the day you check." ] }, { "id": "history", "heading": "Old transactions and old account state are different records", "sourceIds": [ "4444", "1186" ], "paragraphs": [ "History pruning concerns whether a node retains or serves older records such as block bodies and receipts. EIP-4444 discusses bounding execution history and obtaining older data through other distribution paths. The retrieved document is a draft proposal; it does not establish what every live client currently stores.", "Historical state is another requirement. An old transaction can tell you that an action was recorded, while a question such as “what was this account’s balance at that block?” needs suitable historical state data or a saved proof for that state. A provider that supplies one kind of history may not supply the other.", "When requesting an archive service, describe the actual query you need. “Full history” is too vague to establish whether it includes receipts, historical balances, contract storage, blob data or application files." ] }, { "id": "files", "heading": "A content address identifies a file; a pin keeps a copy", "sourceIds": [ "ipfs" ], "paragraphs": [ "IPFS retrieves content using identifiers tied to content rather than relying only on a familiar web location. That is useful for checking that you received the intended object. Someone still needs to make the object available.", "Pinning tells an IPFS node to retain content instead of removing it during routine storage cleanup. A remote pinning service performs that storage job for you under its own operating arrangements. Neither a content identifier nor an unpaid, unmonitored promise of pinning establishes perpetual availability.", "For material you need to preserve, retain a copy you control and test retrieval from the other copies you depend on. Include associated files: the descriptive file linked to a non-fungible token (NFT) might point to an image stored elsewhere. That descriptive file is called metadata. Preserving only one may leave the other missing." ] }, { "id": "packet", "heading": "Build a record that another person can understand", "sourceIds": [ "4844", "4444", "1186", "ipfs" ], "paragraphs": [ "A useful preservation packet contains the original data, its identifier or checksum—a fingerprint computed from the data—the relevant network and block references, and a plain-language description of what it establishes. Include retrieval time and source, so a later reader can distinguish a historical observation from a current one.", "If the claim relies on a cryptographic proof, keep the proof and the trusted reference it is checked against. A hash by itself establishes much less than a complete verification procedure. If the claim relies on an invoice or an agreement outside the chain, preserve that context too, with access limited to the people who need it.", "Then rehearse retrieval on another device. Can you open the file, identify the network and reproduce the check? This is a more useful preservation test than seeing a green availability badge once. Keep sensitive material private; publishing a preservation packet is a separate decision from keeping one." ] } ], "example": { "title": "The artwork survives; the caption does not", "paragraphs": [ "A fictional collector saves an artwork file but only bookmarks the token’s metadata page. Two years later the bookmarked service is unavailable. The collector still has the image, but cannot recover the exact description that was displayed when it was acquired.", "A fuller packet would have included the image, metadata bytes, relevant content identifiers, token contract and token ID, network, and dated transaction references. Even then, the packet would preserve evidence of the recorded material, not automatically prove copyright ownership.", "The lesson is to list each dependent object before choosing storage. A single visible page can depend on several separately hosted files." ] }, "table": { "headers": [ "Record", "What to retain", "What to check" ], "rows": [ [ "Blob-backed application data", "The data and its verification context", "Which archive has the required period?" ], [ "Historical account claim", "Block reference and suitable state proof or data", "Can the proof be checked against a trusted root?" ], [ "IPFS-linked media", "Content and dependent objects", "Are independent copies still retrievable?" ], [ "Business meaning", "Invoice, agreement or explanatory note", "What does the chain record actually establish?" ] ] }, "checklist": [ "List the bytes you need, including linked files and supporting records.", "Separate transaction history, historical state and application media.", "Keep copies under your control and record their checksums and provenance.", "Periodically test retrieval and verification, not only account billing." ], "figure": { "title": "A lasting reference needs an available record", "caption": "The three lanes describe different responsibilities. Their lengths are illustrative, not network retention periods.", "description": "Separate lanes show a chain commitment, underlying data and an archive copy. The data-serving window ends while the commitment remains; a retained archive copy supplies later retrieval." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "b8e383c136d52c3235dae4531a864f9fce61a104ba7163c2b62d3036253e44cf", "status": "verified by separate automated source review", "sources": [ { "id": "4844", "title": "EIP-4844: Shard Blob Transactions", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4844", "locator": "Parameters; Consensus layer validation; Rationale", "scope": "Blob data and commitments have distinct roles; the original retention parameter is not a current universal service guarantee.", "retrieval": { "id": "4844", "url": "https://eips.ethereum.org/EIPS/eip-4844", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4844", "retrievedAt": "2026-10-02T21:37:36.402734+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4844.source", "sha256": "d1c1eb7c505919bb326f493d163b9200b72ed0de2416deae37db6d75cc07baa5", "text": "evidence/4844.txt", "textSha256": "704761f20e60f51683ba82d8fd2c4694f63ea115a6dc6283cf91e49c56c12e26" } }, { "id": "ipfs", "title": "Pin files", "publisher": "IPFS Docs", "url": "https://docs.ipfs.tech/how-to/pin-files/", "locator": "Pin files using IPFS; Three kinds of pins; Local versus remote pinning", "scope": "Content addressing and responsibility for retaining copies; does not promise perpetual hosting.", "retrieval": { "id": "ipfs", "url": "https://docs.ipfs.tech/how-to/pin-files/", "finalUrl": "https://docs.ipfs.tech/how-to/pin-files/", "retrievedAt": "2026-10-02T21:37:36.595200+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/ipfs.source", "sha256": "3fd4a0313f1c5af3309da80188b6ea14f3ea178d73f769a35b97d72d06690b76", "text": "evidence/ipfs.txt", "textSha256": "e68c1c058990fcefee60c4550496eff91462d68e23ce77efce5832f2e4832f1c" } }, { "id": "4444", "title": "EIP-4444: Bound Historical Data in Execution Clients", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-4444", "locator": "Specification; Rationale; History availability", "scope": "A proposal about old execution history, not evidence that every client has implemented it.", "retrieval": { "id": "4444", "url": "https://eips.ethereum.org/EIPS/eip-4444", "finalUrl": "https://eips.ethereum.org/EIPS/eip-4444", "retrievedAt": "2026-10-02T21:37:36.541546+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/4444.source", "sha256": "0fa0db4982dbcc447e0bcc49cb6ff80a97b70e5417bb9bc902351431cb4a5c90", "text": "evidence/4444.txt", "textSha256": "a60d11ccca7507a0450f3a20359e1b01b290c46de9269341e7a6d36a3babbeb4" } }, { "id": "1186", "title": "EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-1186", "locator": "Abstract; eth_getProof; Returns", "scope": "Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client.", "retrieval": { "id": "1186", "url": "https://eips.ethereum.org/EIPS/eip-1186", "finalUrl": "https://eips.ethereum.org/EIPS/eip-1186", "retrievedAt": "2026-10-02T21:37:36.700685+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/1186.source", "sha256": "bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e", "text": "evidence/1186.txt", "textSha256": "6e76e5fbc153157fdd8a38dd4a3e5c2c2b633f0cd0e52c35c3b5da780cfb53b2" } } ], "canonical": "https://degreesofsatoshi.com/guides/blockchain-data-permanence-archives/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "b8e383c136d52c3235dae4531a864f9fce61a104ba7163c2b62d3036253e44cf" } }, { "slug": "cross-chain-payment-missing-refunds", "title": "Your cross-chain payment is stuck. Where is the money now?", "searchTitle": "Cross-chain payment pending: fills, settlement and refunds", "category": "Payments between networks", "accent": "#e6a3b8", "diagram": "crosschain", "interactive": "crosschain", "summary": "A payment between networks can involve a deposit, a delivery and later repayment to the participant who supplied the destination funds. A pending badge can refer to any of those steps. Find the specific order and its current stage before retrying or assuming a refund is due.", "why": "Interfaces may hide more of the network-switching process over time. Clear explanations of incomplete delivery, order evidence and refunds will remain useful even when users no longer choose a bridge themselves.", "overlap": "The existing intent-based swaps and rollup-withdrawal entries cover broader mechanisms. This guide traces missing destination funds through an order lifecycle and keeps user refunds separate from filler repayment.", "related": [ "intent-based-swaps", "blockchain-bridges", "rollup-withdrawal-troubleshooting" ], "sections": [ { "id": "order", "heading": "Start with what the order promised", "sourceIds": [ "7683" ], "paragraphs": [ "Some cross-chain systems ask you to authorize an outcome, such as receiving a particular token on another network. Specialized participants compete or arrange to deliver that outcome. They are often called solvers or fillers. The order describes the conditions under which delivery counts and the participant is paid.", "Record the source network, destination network, exact tokens, amounts, recipient, deadline and order identifier. A ticker such as USDC is not enough to identify a token on a particular network. You also need the relevant contract address or the protocol’s precise asset identifier.", "The current ERC-7683 draft addresses how protocols describe orders to solvers. Its security discussion explicitly leaves the security of settlement to the underlying protocol. A common order format does not give every route the same refund mechanism or guarantee of completion." ] }, { "id": "deposit", "heading": "A source-chain debit is the beginning of the investigation", "sourceIds": [ "across" ], "paragraphs": [ "In the Across lifecycle described by its documentation, the user deposits on the origin network, a participant called a relayer supplies tokens on the destination network, and the protocol later verifies fills and repays relayers. A contract holds the deposited input under the protocol’s rules; this holding step is called escrow. This is a specific design, not the flow of every bridge.", "It explains why a debit in your source wallet does not by itself demonstrate destination delivery. Locate the origin deposit and the corresponding order. Then look for evidence of the destination delivery, called a fill, with the expected recipient and asset.", "Use the protocol’s official documentation to interpret its status fields. A support tool may display a deposit, a fill and a settlement record separately. Saving the identifiers is more useful than saving a screenshot that says only “processing.”" ] }, { "id": "delivery", "heading": "Delivery and repayment answer different questions", "sourceIds": [ "across", "7683" ], "paragraphs": [ "The filler may provide its own inventory to the recipient before it is repaid elsewhere. In that arrangement, you can receive the promised funds while the filler’s settlement remains unfinished. Conversely, an accepted deposit is not evidence that a filler has delivered anything yet.", "An explorer can help establish that a transaction was recorded, but match it to the actual order. Check the destination chain, recipient, asset and amount. A success status for an unrelated transaction, or for a different step in a larger operation, does not answer the delivery question.", "If the order includes a destination contract action, read how that protocol treats failure of the action. Delivery of a token and success of an intended deposit, purchase or swap may need separate checks. The rules belong to the chosen route." ] }, { "id": "expiry", "heading": "A deadline passing does not create a universal refund button", "sourceIds": [ "7683", "across" ], "paragraphs": [ "An unfilled order may expire under its terms, but what happens next depends on the protocol and order type. The system might require a refund claim, wait for another process, or expose a different recovery path. Read the documented procedure for the exact deployment instead of borrowing one from a similar-looking app.", "Be careful with the word refund. Some protocol records use it for repayment to the relayer who already delivered your funds. That is not necessarily a return to you. Identify the beneficiary before treating a refund record as evidence that your original wallet should have been credited.", "A new order can create a second payment if the original is still eligible for execution. Before retrying, establish whether the first order is filled, expired, cancelled or otherwise unable to complete. If the available records disagree, preserve the evidence and use the protocol’s official support route." ] }, { "id": "support", "heading": "Make the next support message specific", "sourceIds": [ "7683", "across" ], "paragraphs": [ "Prepare a compact packet: order identifier, source transaction, destination transaction if any, both networks, expected token and recipient, and the status observed at a stated time. Describe the missing result in ordinary language: “the source deposit is confirmed, but I cannot find the promised destination transfer.”", "Keep private keys, recovery phrases and signing codes out of support messages. A request to connect to an unfamiliar recovery site or sign an unexplained transaction does not become trustworthy because someone knows your public transaction hash.", "After a resolution, reconcile the actual received asset and amount. If there were fees, a partial result or a separate refund, keep each item in the record. That gives you a useful explanation of the payment rather than only a final status label." ] } ], "example": { "title": "One thousand in, nine hundred ninety-four out", "paragraphs": [ "A fictional order locks 1,000 units of a source token and promises 994 units of a specified destination token. The illustration assumes equal units for comparison and omits market-price changes. The six-unit difference is the quoted cost in this example, not a fee estimate for a real service.", "If the recipient has received the correct 994 units and the order is matched as filled, the user’s delivery can be complete even while the filler waits for repayment. If there is only a source deposit, the same arithmetic does not establish that any destination funds have arrived.", "If the order expires unfilled, inspect the protocol’s actual refund eligibility and procedure. The illustration deliberately gives no automatic refund amount or timing because those terms have not been specified." ] }, "table": { "headers": [ "Observed record", "What it can establish", "What remains open" ], "rows": [ [ "Source deposit", "Input funds entered the identified flow", "Whether delivery occurred" ], [ "Matched destination fill", "The order’s destination transfer", "Any additional action and required finality" ], [ "Filler repayment", "The delivering participant was repaid", "It may say nothing about a user refund" ], [ "Expired order", "A deadline has passed under the rules", "Refund eligibility, procedure and timing" ] ] }, "checklist": [ "Find the order identifier and both network names.", "Match any destination fill to the asset, amount and recipient promised.", "Distinguish your refund from repayment to a filler.", "Establish the first order’s status before creating a replacement payment." ], "figure": { "title": "The recipient can be paid before the filler is repaid", "caption": "A simplified inventory-based flow inspired by the documented Across lifecycle. Timing and refund rules vary by protocol.", "description": "The user deposits on the origin chain. A filler pays the recipient on the destination chain using inventory. A separate later path repays the filler." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "260f41406b720568705c679db7e0d91afa1963121cebe1a7b4ed86e735e4f0e1", "status": "verified by separate automated source review", "sources": [ { "id": "7683", "title": "ERC-7683: Cross Chain Intents", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-7683", "locator": "Abstract; Specification; Security Considerations", "scope": "Interoperable order descriptions do not guarantee the underlying settlement protocol or a refund.", "retrieval": { "id": "7683", "url": "https://eips.ethereum.org/EIPS/eip-7683", "finalUrl": "https://eips.ethereum.org/EIPS/eip-7683", "retrievedAt": "2026-10-02T21:37:36.669881+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/7683.source", "sha256": "a4d5db4af9d56dceb95128dfd269240edbd40eb3f378b21ea28ce530910aa385", "text": "evidence/7683.txt", "textSha256": "ae7e9b43d387fed83b3128f8d1b2b11c508bb34e7576c431222970e98fd60d72" } }, { "id": "across", "title": "Intent Lifecycle in Across", "publisher": "Across", "url": "https://docs.across.to/guides/concepts/intent-lifecycle", "locator": "Phase 1: Initiation; Phase 2: Fill; Phase 3: Settlement", "scope": "Across-specific description of a filler and later repayment. It is not a timing promise for every route.", "retrieval": { "id": "across", "url": "https://docs.across.to/guides/concepts/intent-lifecycle", "finalUrl": "https://docs.across.to/guides/concepts/intent-lifecycle", "retrievedAt": "2026-10-02T21:37:36.670034+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/across.source", "sha256": "07ed4b29598bf0c316a7df9ba23e2e751800fa138b7bb3348bf960973443f1dd", "text": "evidence/across.txt", "textSha256": "f5f3e4ed7fa1d9725f69af92971ffae86b1142a1557758e39d42304e1541c6e0" } } ], "canonical": "https://degreesofsatoshi.com/guides/cross-chain-payment-missing-refunds/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "260f41406b720568705c679db7e0d91afa1963121cebe1a7b4ed86e735e4f0e1" } }, { "slug": "light-client-verify-wallet-balance", "title": "Who checks the balance your wallet shows you?", "searchTitle": "Light clients and wallet balances: verifying RPC responses", "category": "Checking the network", "accent": "#a8c78c", "diagram": "proof", "summary": "Many wallets ask a remote server for blockchain data. A light client can check selected answers against cryptographic evidence without downloading and executing the entire chain. The useful question is exactly which answer was verified, at which block, and under which assumptions.", "why": "More lightweight verification could make remote wallet data easier to check. Readers will still need to distinguish verified balances from prices, labels and other information supplied by services.", "overlap": "The existing RPC and node entries explain where data comes from. This guide follows an account proof from a server to a verified state root, including checkpoints, freshness and unverified display elements.", "related": [ "ethereum-nodes-rpc", "ethereum-rpc-privacy", "simplified-payment-verification" ], "sections": [ { "id": "server", "heading": "A clear display can still be someone else’s answer", "sourceIds": [ "light", "1186" ], "paragraphs": [ "When you open a wallet, it may request a balance from a remote node through an interface called RPC. The response can be fast and useful, but an ordinary response is still information supplied by that server. Attractive formatting does not make it independently checked.", "A light client downloads less information than a full node and uses cryptographic evidence to check selected claims. It does not reproduce every job of a full node. The goal is to make a particular answer checkable while keeping the device’s resource requirements smaller.", "For the reader, the key distinction is between “the server returned this number” and “my software verified this number against a sufficiently trusted chain reference.” Both may appear as the same balance on screen." ] }, { "id": "proof", "heading": "A proof needs a trustworthy reference point", "sourceIds": [ "1186", "helios" ], "paragraphs": [ "Ethereum’s state is summarized by a cryptographic value called a state root. A Merkle proof supplies a path that can connect an account or storage value to that root. If the data does not fit the root, the verification fails.", "But a dishonest source could supply both an invented value and a matching invented root. You therefore need a justified way to obtain the root for the intended chain. Checking a proof without checking its reference point only solves part of the problem.", "EIP-1186 describes the eth_getProof method for obtaining account and storage proofs. Helios is one implementation that combines light-client verification with access to remote execution data. Its documentation identifies a weak subjectivity checkpoint as a root of trust: a recent chain reference used to get started. A malicious checkpoint can lead the client to the wrong chain." ] }, { "id": "balance", "heading": "Native coin balances and token balances take different paths", "sourceIds": [ "1186", "erc20" ], "paragraphs": [ "An Ethereum account record includes its native ETH balance. ERC-20 is a common interface used by Ethereum tokens. A token balance under that interface belongs to the token contract’s state and logic. A proof about your account’s ETH balance does not also prove the number shown for every token in your portfolio.", "Verifying a token balance can require authenticating the relevant contract data and interpreting or executing its balance logic. Storage layouts differ, some contract addresses route requests to replaceable code, and not every value appears as a straightforward balance entry. Do not assume a wallet verifies every contract call because it supports one account-proof method.", "The displayed value in dollars or another ordinary currency adds a separate dependency. Even if the token quantity has been checked, multiplying it by a market price does not verify that price, the token’s liquidity or what you could sell it for. A verified quantity and an estimated valuation should remain distinguishable." ] }, { "id": "freshness", "heading": "A correct old answer can still be the wrong answer for today", "sourceIds": [ "1186", "helios", "light" ], "paragraphs": [ "Verification is tied to a particular chain state. A proof may accurately describe a balance at an older block while omitting a later payment. That makes the block reference and the client’s synchronization status useful parts of the result.", "Ask whether the display uses the newest reported block or one with stronger confirmation assurances, how the client handles stale information, and whether an unavailable proof causes an error or a fallback to unverified data. Exact behavior depends on the implementation and network. A silent fallback can change the meaning of the screen without changing its appearance.", "Light-client verification also relies on assumptions about how the network agrees on its history and on the client’s implementation. It should be described with those assumptions, not as a magic removal of trust. Keeping the software current and understanding its checkpoint source remain part of using it." ] }, { "id": "limits", "heading": "Verified data does not make every label true", "sourceIds": [ "light", "helios", "1186" ], "paragraphs": [ "The owner name attached to an address, a scam warning, a token logo and a price chart may come from separate databases. A cryptographic check on chain data does not validate those editorial labels. Nor does it establish that a recipient is the person you intended to pay.", "A remote provider can also fail to respond. Detecting a false answer and obtaining any answer are different capabilities. Verification helps with integrity; availability still needs a working data path, and privacy still depends on what requests the provider can observe.", "Look for a wallet or client that explains the boundaries in terms you can inspect: verified method, block reference, checkpoint source and fallback behavior. You do not need to memorize the proof format to ask those four questions." ] } ], "example": { "title": "The balance is verified. Is the dollar amount?", "paragraphs": [ "A fictional wallet verifies that an account holds 2 ETH at a particular block. Its interface separately obtains a hypothetical price of $3,000 per ETH and displays $6,000.", "The multiplication is correct: 2 × $3,000 = $6,000. The account proof supports the 2 ETH quantity at that block, not the price feed or a promise that a sale would realize $6,000.", "If the account later sends 0.5 ETH, the earlier proof can remain valid for the earlier block while being out of date for the current balance. “Valid proof” and “current answer” need separate checks." ] }, "table": { "headers": [ "Displayed information", "What supports it", "What a balance proof does not establish" ], "rows": [ [ "Native coin quantity", "Account state at a block", "A later balance or recipient identity" ], [ "ERC-20 quantity", "The token contract’s relevant state and logic", "Universal token-method verification" ], [ "Dollar estimate", "Quantity multiplied by a price input", "That the input price is reliable or realizable" ], [ "Address label", "A separate identification source", "Ownership or attribution merely from a proof" ] ] }, "checklist": [ "Find out which RPC responses are actually verified.", "Check the network, block reference and freshness of the result.", "Identify the checkpoint source and behavior when verification is unavailable.", "Treat currency prices and address labels according to their own evidence." ], "figure": { "title": "An answer becomes checkable when the pieces connect", "caption": "Conceptual account-proof verification. A matching proof is useful only when its reference root is justified for the intended chain.", "description": "A remote server supplies a balance and proof. A separately justified block header supplies the state root. Both enter a verification step, which returns a result scoped to a block." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "440dce0bfb2f46489706a0007c734f110424a55415cdbc80c4a5421cebc50856", "status": "verified by separate automated source review", "sources": [ { "id": "light", "title": "Light clients", "publisher": "Ethereum.org", "url": "https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/", "locator": "How do light clients work?; Light clients and the execution layer", "scope": "Verification with reduced data and remaining consensus assumptions; not full re-execution.", "retrieval": { "id": "light", "url": "https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/", "finalUrl": "https://ethereum.org/developers/docs/nodes-and-clients/light-clients/", "retrievedAt": "2026-10-02T21:37:36.811771+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/light.source", "sha256": "6e341dcc3d334d87d69640dd9f2fa7adba990f36777a7ef21a7de0bb8419035f", "text": "evidence/light.txt", "textSha256": "8d2dc61ebdeefb543c982643241361f934f8e5ee9e89923e3f27599e5d1fb14b" } }, { "id": "1186", "title": "EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-1186", "locator": "Abstract; eth_getProof; Returns", "scope": "Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client.", "retrieval": { "id": "1186", "url": "https://eips.ethereum.org/EIPS/eip-1186", "finalUrl": "https://eips.ethereum.org/EIPS/eip-1186", "retrievedAt": "2026-10-02T21:37:36.700685+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/1186.source", "sha256": "bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e", "text": "evidence/1186.txt", "textSha256": "6e76e5fbc153157fdd8a38dd4a3e5c2c2b633f0cd0e52c35c3b5da780cfb53b2" } }, { "id": "helios", "title": "Helios README", "publisher": "a16z crypto / Helios contributors", "url": "https://raw.githubusercontent.com/a16z/helios/master/README.md", "locator": "Overview; Checkpoints; RPC endpoints", "scope": "One implementation's verification model and checkpoint requirements; not a certification or feature claim about every wallet.", "retrieval": { "id": "helios", "url": "https://raw.githubusercontent.com/a16z/helios/master/README.md", "finalUrl": "https://raw.githubusercontent.com/a16z/helios/master/README.md", "retrievedAt": "2026-10-02T21:37:36.916195+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/helios.source", "sha256": "bf5aedeac1b5ddb1124ff0ba42d3d3191d29cf715880fad9361d29db473512c8", "text": "evidence/helios.txt", "textSha256": "3300b55cf3b86f1d25270fb145251fc5449e4a2840f0666e9d4617c500d749c2" } }, { "id": "erc20", "title": "ERC-20: Token Standard", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-20", "locator": "approve, allowance and transferFrom", "scope": "The token allowance interface, separate from account delegation.", "retrieval": { "id": "erc20", "url": "https://eips.ethereum.org/EIPS/eip-20", "finalUrl": "https://eips.ethereum.org/EIPS/eip-20", "retrievedAt": "2026-10-02T21:37:35.905459+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/erc20.source", "sha256": "98bda5e4707841a68684879878c4c165fdaa47d89ed69ebf232ab9be06ff050e", "text": "evidence/erc20.txt", "textSha256": "f8d11f24fa5eb68a9f5d50d07cd1cdf7b4a8809eb2b2245856957ee9bce040f8" } } ], "canonical": "https://degreesofsatoshi.com/guides/light-client-verify-wallet-balance/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "440dce0bfb2f46489706a0007c734f110424a55415cdbc80c4a5421cebc50856" } } ] }