An approval from a smart-contract wallet cannot always be assessed by recovering one ordinary signing address. The account may require several approvals or apply a policy that changes over time. This technical explainer examines ERC-1271, the interface that lets an application ask the account itself whether a proposed signature is acceptable.
TL;DR
- ERC-1271 lets a contract report whether a signature is valid on its behalf.
- A smart account can apply its own signer and authorisation rules.
- A previously successful check may not remain valid after the account changes.
The account defines what counts as approval
The ERC-1271 standard defines an isValidSignature check and a specific success value. Its validation can depend on the contract’s state and authorisation logic. That gives smart accounts a common interface without forcing every account to use the same internal signing policy.
Imagine a hypothetical treasury with three authorised people and a rule requiring two approvals. A marketplace integrating that treasury needs to verify approval by the treasury account. Checking one person’s address would answer a narrower question and could bypass the organisation’s intended requirement.
This is a useful separation of responsibilities. The marketplace decides what message authorises a trade; the treasury decides which evidence is sufficient to approve that message on its behalf. Both sides still need to agree on the message being checked, including its scope and intended context.
A saved approval can become stale
Suppose two people approve an order on Monday, but the treasury removes one of them on Tuesday before the order is executed. Whether that order remains valid depends on the account’s implementation and current policy. A successful check performed on Monday cannot automatically answer Tuesday’s question.
OpenZeppelin’s SignatureChecker documentation explicitly notes that contract signatures can be revocable and that validity may change between blocks. For an integrating service, this means a cached result needs to be treated as an observation at a particular point, rather than a permanent property of the signature bytes.
The operational consequence is straightforward. A service promising to execute only currently authorised instructions should validate at the point where that promise matters. If it instead commits based on an earlier check, it needs to understand and disclose the different guarantee it is offering.
Supporting smart accounts requires deliberate integration
Safe’s signature documentation describes support for multiple signature types, including contract signatures. That illustrates why applications should avoid assuming every account approval has the same format or can be handled by one fixed private-key recovery routine.
For a product team, compatibility is more than making a connect button recognise the wallet. The signing flow, verification service and execution contract all need to support the relevant account model. A user may successfully connect while discovering later that a critical action rejects the account’s valid approval method.
Failure handling also matters. A verification call that fails, returns an unexpected result or cannot be completed should not be silently treated as approval. At the same time, the user deserves an explanation that distinguishes unsupported functionality from a signature that the account has actually rejected.
Records should preserve the decision context
The hypothetical treasury may later need to explain why an order was accepted. Keeping the message, the account address and the state context of verification gives an investigator a starting point. Saving only a green checkmark would provide much less evidence about the decision that was made.
This record should also distinguish signature validity from execution. A valid approval may still describe an order that cannot complete because its price condition is no longer available. Conversely, a service should not describe an earlier successful verification as proof that a later transaction actually settled.
ERC-1271 makes smart-account approval interoperable while allowing accounts to retain flexible policies. The integration challenge is to respect that flexibility throughout the process: verify the correct message, consult the account’s rules at the relevant time and explain the difference between permission, an attempted action and a completed result.
Written by the News Desk and edited by Samuel Rae.
Leave a Reply