Cuentas inteligentes y gobernanza
ERC-6492: signatures from an account that is not deployed yet
An empty address can have a planned contract identity; verification must follow the correct model.
Los artículos y gráficos técnicos están en inglés. La navegación está disponible en 7 idiomas.
Guías de referencia
Why code may not exist yet
Smart-account systems can determine an account address before deploying the account’s contract. This can avoid paying deployment costs until they are needed. It creates a verification problem: a service cannot simply call a signature-validation function on code that does not yet exist. Absence of current code also does not establish that the address should be treated as an ordinary externally owned account. 1
A wrapper supplies preparation context
ERC-6492 defines a wrapped signature format carrying information needed to prepare or deploy the account for validation, together with the account signature. A compatible verifier handles that preparation in the specified validation flow and then uses the contract-signature model. ERC-1271 defines the contract’s signature-validation interface. This is a conceptual description, not a recipe for executing arbitrary preparation data. 1 2
Validity is contextual
A valid account signature answers a question about the message and account rules under the verification context. It is not proof of a person’s legal identity, and it does not make any unrelated transfer appropriate. Chain context, deployment configuration and the intended message domain must remain explicit. A service that supports only basic key recovery can reject legitimate smart accounts or make incorrect assumptions about them.
What the user should be shown
A sign-in flow should explain what message is being approved and for which service, even if the account deployment is deferred. Researchers should preserve the account address, chain, signed-message purpose and verification method rather than reducing the evidence to ‘signature valid’. Wallets and applications should use maintained standards-aware implementations and test compatibility without asking users to disclose keys.
Ejemplo concreto
A new smart account signs a website login before its first on-chain action. Its address has no contract code yet. A compatible service can validate the intended contract-account signature using the preparation context; checking for existing bytecode alone would misclassify the account.