{"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":"ERC-6492 defines a signature wrapper that lets a verifier validate a counterfactual smart-account signature by simulating its factory deployment when the account is not yet deployed. A compatible wallet, factory, verifier, and account implementation are still required; the wrapper does not create a universal wallet or authentication flow.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-6492","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-6492","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-6492","type":"official-spec"}],"lastReviewed":"2026-09-18","specConstraints":[{"id":"counterfactual-deployment-before-validation","constraint":"When the ERC-6492 wrapper is detected, a verifier must deploy the contract before calling isValidSignature.","appliesTo":"wallet","normativity":"normative","specQuote":"The signature verifier MUST perform a contract deployment before attempting to call `isValidSignature` if the wrapper signature format is detected.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#specification","designImplication":"Represent counterfactual verification as a simulation or deployment-aware path, and do not report an ERC-1271 result before the wrapper's deployment step has been processed."},{"id":"erc6492-magic-suffix","constraint":"The wrapper format is identified by the exact ERC-6492 magicBytes suffix.","appliesTo":"wallet","normativity":"normative","specQuote":"The wrapper format is detected by checking if the signature ends in `magicBytes`, which MUST be defined as `0x6492649264926492649264926492649264926492649264926492649264926492`.","specSection":"Specification","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#specification","designImplication":"Detect the wrapper by its specified suffix before applying ordinary signature parsing, and label unsupported or malformed wrappers as unverified."},{"id":"preparation-calldata","constraint":"A deployed-but-not-ready signer may wrap a signature with preparation target and calldata that make the contract ready for ERC-1271 verification.","appliesTo":"account-implementation","normativity":"normative","specQuote":"`prepareTo` and `prepareData` must contain the necessary transaction that will make the contract ready to verify using [ERC-1271](./eip-1271.md) (e.g. a call to `migrate` or `update`)","specSection":"Specification / Signer side","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#signer-side","designImplication":"Show preparation as a distinct, potentially state-changing step and do not imply that a wrapper proves the account is already ready to validate without executing or simulating its declared preparation."},{"id":"verification-order","constraint":"Full ERC-6492 verification follows the specified wrapper, contract-code/ERC-1271, and EOA fallback order.","appliesTo":"wallet","normativity":"normative","specQuote":"Full signature verification MUST be performed in the following order:\n\n- check if the signature ends with magic bytes, in which case do an `eth_call` to a multicall contract that will call the factory first with the `factoryCalldata` and deploy the contract if it isn't already deployed; Then, call `contract.isValidSignature` as usual with the unwrapped signature\n- check if there's contract code at the address. If so perform [ERC-1271](./eip-1271.md) verification as usual by invoking `isValidSignature`\n- if the [ERC-1271](./eip-1271.md) verification fails, and the deploy call to the `factory` was skipped due to the wallet already having code, execute the `factoryCalldata` transaction and try `isValidSignature` again\n- if there is no contract code at the address, try `ecrecover` verification","specSection":"Specification / Verifier side","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#verifier-side","designImplication":"Keep wrapper detection and account validation ahead of EOA recovery, and show which verification path produced the result instead of collapsing all signatures into an EOA-style check."},{"id":"validation-order-safety","constraint":"Verifier ordering must check magicBytes before ERC-1271 and ecrecover, and must not run ecrecover before ERC-1271 verification.","appliesTo":"wallet","normativity":"rationale","specQuote":"- checking for `magicBytes` MUST happen before the usual [ERC-1271](./eip-1271.md) check in order to allow counterfactual signatures to be valid even after contract deployment\n- checking for `magicBytes` MUST happen before `ecrecover` in order to avoid trying to verify a counterfactual contract signature via `ecrecover` if such is clearly identifiable\n- checking `ecrecover` MUST NOT happen before [ERC-1271](./eip-1271.md) verification, because a contract may use a signature format that also happens to be a valid `ecrecover` signature for an EOA with a different address. One such example is a contract that's a wallet controlled by said EOA.","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#rationale","designImplication":"Make the ordered checks observable in wallet diagnostics and prevent an EOA-looking signature from bypassing a contract account's current validation rules."},{"id":"signature-format-compatibility","constraint":"The wrapper remains compatible with ERC-1271, EOA signatures, and typed-data signatures.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"This ERC is backward compatible with previous work on signature validation, including [ERC-1271](./eip-1271.md) and allows for easy verification of all signature types, including EOA signatures and typed data ([EIP-712](./eip-712.md)).","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#backwards-compatibility","designImplication":"Keep a single verification surface for legacy contract, EOA, and typed-data signatures while clearly identifying which account and format was checked."},{"id":"wrapper-recognition","constraint":"Magic bytes allow a verifier to recognize a contract signature without checking the blockchain first.","appliesTo":"wallet","normativity":"backwards-compatibility","specQuote":"allows quick recognition of the signature type: thanks to the magic bytes, you can immediately know whether the signature is a contract signature without checking the blockchain","specSection":"Backwards Compatibility / Using ERC-6492 for regular contract signatures","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#using-erc-6492-for-regular-contract-signatures","designImplication":"Use the wrapper marker to choose the verification path early, but still perform the contract and account checks needed to establish a valid result."},{"id":"side-effect-free-validation","constraint":"Deployment-aware validation introduces re-entrancy risk; validation should avoid side effects or use an explicit side-effects path.","appliesTo":"account-implementation","normativity":"security-considerations","specQuote":"However, deploying a contract requires a `CALL` rather than a `STATICCALL`, which introduces reentrancy concerns. This is mitigated in the reference implementation by having the validation method always revert if there are side-effects, and capturing its actual result from the revert data.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#security-considerations","designImplication":"Keep signature checks isolated from unexpected state changes, label any side-effectful validation path, and do not treat a simulation that mutated state as a harmless read."},{"id":"live-authentication-state","constraint":"Verification must check the deployed account's current authentication methods because contract accounts can change them dynamically.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"contract accounts can dynamically change their methods of authentication. This issue is mitigated by design in this EIP - even when validating counterfactual signatures, if the contract is already deployed, we will still call it, checking against the current live version of the contract.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#security-considerations","designImplication":"Do not cache a signature result as permanent authority; bind it to the account's current validation state and show when authorization has changed."},{"id":"cross-network-replay","constraint":"Most use cases need replay protection because a counterfactual signature can become valid on another network with the same factory and bytecode conditions.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"As per usual with signatures, replay protection should be implemented in most use cases. This proposal adds an extra dimension to this, because it may be possible to validate a signature that has been rendered invalid (by changing the authorized keys) on a different network as long as 1) the signature was valid at the time of deployment 2) the wallet can be deployed with the same factory address/bytecode on this different network.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-6492#security-considerations","designImplication":"Include chain and account-context replay protection in authorization flows and warn when a signature's domain does not bind it to the intended network."}],"lastUpdated":"2026-09-18","summary":"ERC-6492 defines a signature wrapper that lets a verifier validate a counterfactual smart-account signature by simulating its factory deployment when the account is not yet deployed. A compatible wallet, factory, verifier, and account implementation are still required; the wrapper does not create a universal wallet or authentication flow.","designerTakeaways":["Offer pre-deployment SIWE or message verification only when the verifier supports the ERC-6492 wrapper and selected factory.","Keep deployment details quiet only while cost, timing, risk, and verifier state remain clear.","Show the counterfactual address and preserve continuity after deployment, while handling factory or verification failure explicitly."],"applicability":{"whenToUse":["The selected smart-account factory and verifier support counterfactual signature validation.","Your auth flow uses SIWE or another off-chain message verification path.","The product can show deployment state, factory assumptions, and an ordinary fallback when validation fails."],"whenToAvoid":["You only support EOAs or deployed accounts and do not need counterfactual verification.","Your verifier cannot validate the wrapper, factory, deployment simulation, or returned signer.","The flow requires deployed contract code before any supported action can proceed."]},"prototypeFirst":[{"screen":"Counterfactual verification","why":"Show the pre-deployment path only when the selected verifier and factory support the wrapper.","covers":["Wrapper verified","Stable account address"],"include":["Factory and address context","Verification result","Session next step"]},{"screen":"Undeployed or unsupported account","why":"A wrapper can be valid only for a compatible factory, verifier, and account implementation.","covers":["Missing factory support","Deployment simulation unavailable"],"include":["Plain-language reason","Fallback action"]},{"screen":"Verification failure and fallback","why":"The user needs a clear path when the wrapper or simulated deployment cannot be verified.","covers":["Invalid wrapper","Factory or signature failure"],"include":["Retry path","Support context"]},{"screen":"Deployment status disclosure","why":"Users may need to understand the account's current deployment and factory context.","covers":["Counterfactual address","Factory and calldata","Deployed or undeployed 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 and then invokes the account's ERC-1271 isValidSignature. Auth succeeds only after the wrapper, factory, and account validation pass, 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":"Undeployed account","trigger":"The verifier receives an ERC-6492-wrapped signature for an account without deployed code.","userNeed":"Know that verification can proceed without pretending deployment already happened.","designResponse":"Show the counterfactual address and the factory/verifier assumptions."},{"state":"Verification pending","trigger":"The backend or wallet is simulating factory deployment and signature validation.","userNeed":"Know whether sign-in is still being checked.","designResponse":"Show progress and avoid creating a session until verification succeeds."},{"state":"Account deployed","trigger":"The account has code at the counterfactual address after first execution.","userNeed":"Keep the same account identity and explain the status change.","designResponse":"Preserve address/session continuity and update deployment status."},{"state":"Signature verified","trigger":"The wrapper, factory simulation, and underlying ERC-1271 signature validation succeed.","userNeed":"Know that the app can create its scoped session.","designResponse":"Create the session and show the verified counterfactual address."},{"state":"Wrapper or deployment invalid","trigger":"The wrapper, factory, deployment simulation, underlying account validation, or signature check fails.","userNeed":"Avoid a false session and know how to recover.","designResponse":"Explain the failed check and offer ordinary verification, retry, or another supported account path."}],"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":"When do you show deployment status?","recommendation":"Keep it secondary unless deployment affects cost, timing, risk, or the next action.","rationale":"The counterfactual address can remain stable, but the verifier and user still need an honest account-state boundary."}],"problemsSolved":[{"problem":"Verification can require deployment before a smart account exists","oldWay":"A verifier rejects a signature because the account address has no code yet","newWay":"A compatible verifier can use the ERC-6492 wrapper and factory simulation","impact":"high"},{"problem":"Users may confuse a counterfactual address with a deployed account","oldWay":"The app hides deployment state or treats simulation as on-chain confirmation","newWay":"The UI distinguishes verified, undeployed, deployed, and unsupported states","impact":"high"},{"problem":"Factory or wrapper failures are difficult to recover from","oldWay":"A generic signature error leaves users unsure which account path failed","newWay":"Mapped verification, factory, deployment, and fallback states explain what to do next","impact":"medium"}],"uxPatterns":[{"name":"Counterfactual Sign-In","description":"Authenticate with a not-yet-deployed smart account.","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.","components":["StatusBadge","Tooltip"],"userFlow":["Account connected","Query deployment status","Show Active or Activates on first use"]}],"antiPatterns":[{"pattern":"Presenting a counterfactual signature as universal wallet support","why":"ERC-6492 requires a compatible wrapper verifier, factory, account, and client flow","instead":"Show verification scope and a deployment or ordinary-account fallback","severity":"critical"},{"pattern":"Treating simulation as on-chain deployment","why":"A verifier can validate a counterfactual account without changing chain state","instead":"Use outcome language with deployed/undeployed status and simulation disclosure","severity":"high"},{"pattern":"No fallback when counterfactual verification fails","why":"Factory, verifier, or wallet support may be missing or incompatible","instead":"Explain the limitation and offer an ordinary signature or supported account path","severity":"high"}],"vocabulary":[{"use":"Account address","avoid":"Deployed wallet","why":"The address may be valid before the account has on-chain code."},{"use":"Account not deployed yet","avoid":"Account does not exist","why":"A counterfactual account can be verifiable before deployment."},{"use":"Verify signature","avoid":"Deploy to sign in","why":"ERC-6492 can remove an upfront deployment requirement when the verifier supports it."}],"technicalNotes":"ERC-6492 wraps an ERC-1271 signature with factory and calldata so an off-chain verifier can simulate deployment for an undeployed account. After wrapper and deployment handling, the verifier invokes the account's ERC-1271 isValidSignature and applies that account's state-dependent validation. The verifier must recognize the wrapper, validate the selected factory and account, and check the underlying signature; a successful simulation does not deploy the account or authenticate every client automatically.","relatedStandards":[{"id":"ERC-1271","relationship":"Underlying contract signature validation interface"},{"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://ercs.ethereum.org/ERCS/erc-6492","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-6492","type":"discussion"}],"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://ercs.ethereum.org/ERCS/erc-6492","discussion":"https://ethereum-magicians.org/search?q=ERC-6492"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}