{"id":"ERC-6492","name":"Signature Validation for Predeploy Contracts","status":"Final","chain":"both","category":{"id":"onboarding","name":"Onboarding & Access","description":"Getting users into web3 without friction"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"}],"uxImpact":"Smart contract wallets can sign messages before deployment — users don't need an initial transaction to start using their account. Design implications: enable 'Sign-In with Ethereum' and message signing for freshly created accounts with zero transactions, remove 'deploy wallet first' friction from onboarding, show account address even before deployment. Design decisions: decide whether to surface deployment status to users or abstract it away, design consistent verification flows that work for both deployed and counterfactual contracts, handle edge cases where signature was created pre-deployment but verified post-deployment, consider showing 'account not yet deployed' status in explorers.","hasDetailedContent":true,"content":{"id":"ERC-6492","sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/erc-6492","type":"official-spec"}],"lastReviewed":"2026-05-25","lastUpdated":"2026-05-25","summary":"Smart contract wallets can sign messages before deployment — users don't need an initial transaction to start using their account.","designerTakeaways":["You can offer SIWE on day zero for smart accounts that have never sent a transaction.","Your UI can hide deployment complexity unless it affects cost, timing, or risk.","You can show the same address before and after first transaction for continuity."],"applicability":{"whenToUse":["Smart wallet onboarding should not require a deploy transaction before sign-in.","Your auth flow uses SIWE or off-chain message verification.","Users connect counterfactual accounts from ERC-4337 factories."],"whenToAvoid":["You only support EOAs with on-chain history.","Your verifier cannot simulate contract deployment.","The flow requires deployed contract code for every read path."]},"prototypeFirst":[{"screen":"Primary happy path","why":"Prove the core user promise before edge cases.","covers":["Success state","Clear outcome copy"],"include":["Primary CTA","Confirmation feedback","Next step"]},{"screen":"Blocked or unsupported state","why":"Users discover limits when wallets or chains lack support.","covers":["Unsupported wallet","Wrong network"],"include":["Plain-language reason","Fallback action"]},{"screen":"Failure recovery","why":"Trust breaks when errors look like bugs.","covers":["User rejection","Transaction revert"],"include":["Retry path","Support context"]},{"screen":"Advanced disclosure","why":"Power users need technical detail without cluttering the default path.","covers":["Contract address","Token ID","Raw status"],"include":["Expandable section","Copy buttons","Explorer link"]}],"mentalModel":[{"label":"Counterfactual address","description":"The smart account address exists before deployment. Users see one consistent address from onboarding through first transaction."},{"label":"Offchain signature","description":"The wallet signs SIWE or typed data using ERC-6492 proof that wraps factory data for an undeployed contract."},{"label":"Verifier simulation","description":"Your backend or wallet simulates deployment plus signature validity. Auth succeeds without an upfront deploy transaction."},{"label":"First onchain action","description":"The initial transaction may include contract deployment. Hide deployment complexity unless it changes cost, timing, or risk."},{"label":"Continuity","description":"Before and after deploy, address and session identity stay the same. Do not make users reconnect after first transaction."}],"statesToDesign":[{"state":"Ready","trigger":"Prerequisites met.","userNeed":"Understand what happens next.","designResponse":"Enable primary action with plain-language preview."},{"state":"Awaiting signature","trigger":"Wallet prompt open.","userNeed":"Know what they are approving.","designResponse":"Mirror human-readable summary in app and wallet."},{"state":"Pending","trigger":"Transaction submitted.","userNeed":"Confidence it is progressing.","designResponse":"Show status strip with explorer link."},{"state":"Succeeded","trigger":"On-chain confirmation.","userNeed":"See updated ownership or balance.","designResponse":"Celebrate outcome and show new state clearly."},{"state":"Failed or reverted","trigger":"Validation or execution failed.","userNeed":"Fix or retry without guessing.","designResponse":"Name the failed constraint and offer a concrete next step."}],"designDecisions":[{"question":"How much protocol detail do users see?","recommendation":"Lead with outcomes; tuck identifiers behind review.","rationale":"Users decide on consequences, not function selectors."},{"question":"What happens when support is missing?","recommendation":"Block with explanation and fallback path.","rationale":"Silent failure feels like a broken product."},{"question":"How do you label restricted assets?","recommendation":"Use persistent badges for non-transferable, locked, or expiring states.","rationale":"Hidden restrictions cause rage-quits at transfer time."}],"problemsSolved":[{"problem":"Inconsistent behavior across apps","oldWay":"Each team reinvents copy and edge cases","newWay":"Shared standard gives predictable UX patterns","impact":"high"},{"problem":"Users surprised by on-chain rules","oldWay":"Generic transfer UI fails at submit time","newWay":"Standard-aware UI sets expectations upfront","impact":"high"},{"problem":"Support burden from opaque errors","oldWay":"Raw revert reasons in toasts","newWay":"Mapped states explain what to do next","impact":"medium"}],"uxPatterns":[{"name":"Counterfactual Sign-In","description":"Authenticate with a not-yet-deployed smart account.","mockup":"concept/siwe-sign-in","components":["SIWEButton","AddressChip"],"userFlow":["User connects smart account","Signs SIWE message","Server verifies via ERC-6492","Session created"]},{"name":"Deployment Status Chip","description":"Optional indicator for advanced users.","mockup":"concept/siwe-sign-in","components":["StatusBadge","Tooltip"],"userFlow":["Account connected","Query deployment status","Show Active or Activates on first use"]}],"seenInTheWild":[{"app":"Safe","url":"https://safe.global/","note":"Smart accounts commonly exist counterfactually before first execution."},{"app":"Coinbase Smart Wallet","url":"https://www.coinbase.com/wallet/smart-wallet","note":"Passkey smart wallets sign before deployment."},{"app":"Ambire","url":"https://www.ambire.com/","note":"Smart wallet onboarding emphasizes immediate use over deploy-first."}],"antiPatterns":[{"pattern":"Hiding standard-imposed restrictions until submit","why":"Users feel tricked when actions fail at the last step","instead":"Show eligibility and badges before the primary CTA","severity":"critical"},{"pattern":"Protocol jargon in user-facing copy","why":"Non-technical users cannot consent informedly","instead":"Use outcome language with optional technical disclosure","severity":"high"},{"pattern":"No fallback when wallet lacks support","why":"Dead-end flows increase churn","instead":"Explain limitation and offer alternate path or network","severity":"high"}],"vocabulary":[{"use":"Your balance / Your item","avoid":"Token ID / Token contract","why":"Ownership language matches mental models."},{"use":"Cannot transfer yet","avoid":"Transfer reverted","why":"Explain restriction without EVM vocabulary."},{"use":"Confirm in wallet","avoid":"Sign transaction","why":"Matches wallet UX users already know."}],"onMonad":[{"aspect":"Confirmation speed","ethereum":"Multi-step flows can feel slow between signatures","monad":"Sub-second finality tightens feedback loops","designImplication":"Prefer inline status over long pending modals on Monad."},{"aspect":"Transaction cost","ethereum":"Gas can discourage exploratory actions","monad":"Lower fees enable lighter-weight interactions","designImplication":"Safe to offer preview retries and social actions more freely."}],"technicalNotes":"ERC-6492 wraps a signature with factory and calldata so off-chain verifiers can simulate deployment.","relatedStandards":[{"id":"ERC-4361","relationship":"SIWE auth enabled for undeployed accounts"},{"id":"ERC-4337","relationship":"Smart accounts often verified counterfactually"}]},"sources":[{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/erc-6492","type":"official-spec"},{"label":"Discussion","url":"https://ethereum-magicians.org/search?q=ERC-6492","type":"discussion"},{"label":"Official specification","url":"https://eips.ethereum.org/EIPS/erc-6492","type":"official-spec"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-6492","markdown":"https://www.eipsfordesigners.com/standards/ERC-6492/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-6492/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-6492","official":"https://eips.ethereum.org/EIPS/erc-6492","discussion":"https://ethereum-magicians.org/search?q=ERC-6492"},"freshness":{"lastReviewed":"2026-05-25","lastUpdated":"2026-05-25"}}