Standard / EIP·EVM
EIP-6492 — Signature Validation for Predeploy (Counterfactual) Contracts
Wrapper format that lets a counterfactual smart account (deterministic address, not yet deployed) produce a signature that off-chain verifiers can validate. The wrapper is `abi.encode(create2Factory, factoryCalldata, originalSignature) || 0x6492649264926492649264926492649264926492649264926492649264926492`. Status: Final (Standards Track / ERC).
- 01Sign-In-With-Ethereum for undeployed ERC-4337 accounts
- 02off-chain orders from counterfactual smart accounts
- 03passkey / Coinbase Smart Wallet onboarding (sign before first tx)
- 04Permit / Permit2 from undeployed accounts
- pnpm add viem # verifyMessage / verifyTypedData natively unwrap and validate 6492 signatures
- pnpm add ethers # ethers v6 provider.verifyMessage handles 6492
- # Reference universal validator: 0x6492649264926492649264926492649264926492 (deterministic, every chain)
Use EIP-6492 to wrap signatures from counterfactual smart accounts so verifiers can validate them before the account is deployed. Producer side: encode `abi.encode(address factory, bytes factoryCalldata, bytes signature)` then concatenate the magic suffix `0x6492649264926492649264926492649264926492649264926492649264926492` (32 bytes). Verifier side: detect the suffix, and use the universal validator pattern — call `eth_call` to a one-shot `ValidateSigOffchain` deployer-validator that (a) deploys the account if `code.length == 0` (via the wrapped factory call), (b) calls `isValidSignature(hash, innerSig)` on it, (c) returns whether the magic 1271 value `0x1626ba7e` came back. With viem, `verifyMessage`/`verifyTypedData`/`verifyTypedSignature` do this transparently. After the account is deployed, signatures should be sent UNWRAPPED (raw ERC-1271) — but verifiers should accept either form indefinitely.
- ⚑The magic suffix MUST be the trailing 32 bytes — verifiers check `sig[-32:] == 0x6492...`. Mid-buffer matches are not valid; do not slice from anywhere else.
- ⚑Verification REQUIRES an `eth_call`-capable RPC (state override or actual deploy-in-call). Pure off-chain ECDSA verifiers will fail. The on-chain `staticcall(0x6492...)` to the universal validator MUST be `staticcall` — the wrapper deploys the account inside the call and reverts the deployment after returning, so block state is unchanged.
- ⚑After the account is deployed, sending a 6492-wrapped signature still works but wastes gas/calldata. Switch to raw 1271 once `code.length > 0`.
- ⚑The factory call inside the wrapper must be IDEMPOTENT — wrappers are commonly retried. A factory that reverts on already-deployed addresses (or one that uses non-deterministic deploys) will break the validator.
- ⚑Inner signature semantics depend on the account: for 4337 accounts the inner sig is whatever `isValidSignature` expects (often packed `validator || sig` for ERC-7579). Do not assume raw ECDSA.
- ⚑Some marketplace/order systems strip trailing zero bytes from signatures — the magic suffix has no zero bytes (all `0x64` `0x92`) so this is safe, but custom truncation logic still breaks 6492 wrappers.