What is ERC-1271?
The signature standard for smart accounts, multisigs, and contract wallets.
ERC-1271 exists because not every signer is an EOA. A contract account may require two owners, a module check, a guardian rule, or a session-key policy before it treats a signature as valid.
on this page
The standard, in one card.
- Standard
- ERC-1271 / EIP-1271
- Core function
- isValidSignature(hash, signature)
- Return value
- 0x1626ba7e magic value
- Used by
- smart wallets · multisigs · account abstraction
- Canonical spec
- eips.ethereum.org / EIP-1271
The origin story.#
As multisigs and contract wallets became common, protocols needed a way to accept orders, permits, and messages from accounts that could not be verified with a plain ecrecover check.
What ERC-1271 actually is.#
function isValidSignature(bytes32 hash, bytes memory signature) external view returns (bytes4 magicValue);
isValidSignature wallets · marketplaces · permit flows · orders The caller passes a hash and signature to isValidSignature. If the contract accepts the signature under its own rules, it returns the ERC-1271 magic value. Otherwise it fails or returns a different value.
What's broken about ERC-1271.#
The standard stops at validation. It does not tell the caller which controller signed, what that controller may do, or how the account can recover if the signer is lost.
-
It validates, but does not define permissions.#
ERC-1271 tells callers how to ask whether a signature is valid. It does not standardize roles, session keys, allowed calls, guardians, value limits, or recovery.
ERC-1271isValidSignature(hash, sig)LSP6Key Manager permissionsworkarounds tried- wallet-specific modules
- Safe owners/modules
- ERC-4337 validators
- custom policy contracts
-
Callers still need wallet-specific expectations.#
Two accounts can both support ERC-1271 while using totally different signature schemes, owner sets, modules, or validity windows behind the function.
smart walletssame function, different policyUniversal Profilestandard controller dataworkarounds tried- account SDKs
- signature adapters
- simulation
-
It does not make EOAs recoverable.#
ERC-1271 only applies to contract accounts. If the user is still an EOA, signature validity is still tied to the private key unless another standard such as EIP-7702 or a smart-wallet wrapper is involved.
EOAecrecoverLSP0contract accountworkarounds tried- contract account migration
- EIP-7702 delegation
- ERC-4337 smart accounts
LUKSO designed it differently.#
LUKSO treats the account as a contract from the start. LSP0 supplies the account surface, LSP6 supplies the permission vocabulary, and signature validation becomes one part of a broader account system.
ERC-1271 vs LSP0+LSP6 in one table.#
| row | ERC-1271 | LSP account stack |
|---|---|---|
| standardizes | signature validation function | account plus permission model |
| policy | wallet-defined | LSP6 permission vocabulary |
| caller asks | is this signature valid? | is this controller allowed to do this? |
| account type | any contract wallet | Universal Profile |
FAQ.#
-
What is ERC-1271? #
ERC-1271 is the standard for smart contract signature validation. A caller sends a hash and signature to isValidSignature, and the contract returns a magic value if the signature is valid.
-
Why do smart wallets need ERC-1271? #
A smart wallet may not have one private key that ecrecover can check. Its valid signature may depend on owners, modules, guardians, thresholds, session keys, or custom logic.
-
Is ERC-1271 part of account abstraction? #
It is a supporting primitive. ERC-4337 smart accounts and many contract wallets use ERC-1271-style signature validation, but ERC-1271 by itself is not a full account abstraction system.