Summary: ERC-7913 is best cataloged as signer-abstraction infrastructure for smart accounts rather than as a cryptography library, passkey product, or wallet UX feature. Its core move is to standardize how contracts represent and verify signers that do not have their own Ethereum addresses by splitting identity into a verifier contract plus opaque key bytes. The important categorization clue is that ERC-7913 changes the authority model from “signer equals address” to “signer equals verifier plus key description,” which makes non-Ethereum keys portable inside account-abstraction systems.
What it does:
Defines a minimal verifier interface verify(bytes key, bytes32 hash, bytes signature) that returns a magic value when a signature is valid
Represents a signer as verifier || key, where the verifier is a contract address and the key is arbitrary non-empty bytes
Preserves backward compatibility with EOAs and ERC-1271 contracts by treating 20-byte signers with empty key material as ordinary address-based identities
Lets smart accounts and other systems use non-address-native keys such as P256, RSA, WebAuthn-style credentials, email-derived proofs, or other verifier-defined schemes without deploying one identity contract per key
Pushes verification logic into stateless or trust-minimized verifier contracts instead of forcing every non-EVM signer to masquerade as its own address-bearing account
Gives account frameworks a portable signer representation that can support social recovery, threshold signing, and alternate hardware or Web2-rooted credentials
Key claims:
The final ERC says it extends signer description and signature verification to keys that do not have an Ethereum identity of their own, which is the clearest sign this belongs in the corpus as authority infrastructure rather than as a single cryptography primitive
The motivation says account abstraction increasingly needs non-secp256k1 verification for P256, RSA, email, JWT, and similar schemes, framing ERC-7913 as a general signer-transport layer for smart accounts
The specification requires a verifier contract plus non-empty key bytes and says verifiers should be stateless, showing that ERC-7913 is standardizing a trust-minimized verification boundary rather than a mutable key registry
The rationale says the model avoids deploying one ERC-1271 identity contract per key, which reveals the mechanism value: separate account addresses that hold assets from the heterogeneous keys that control them
The backwards-compatibility section defines a single bytes-based signer format that can still fall through to ERC-1271 or EOA verification when the key portion is empty, making ERC-7913 a unifying signer envelope instead of an isolated niche path
The security section says verifier contracts should be trustless, non-upgradeable, and ideally pure or effectively immutable, which matters because the verifier becomes a durable root of authority for long-lived recovery or guardian systems
OpenZeppelin’s smart-account docs recommend that developers use ERC-7913 verifiers instead of writing a new signer abstraction for each signature scheme, which is strong evidence that the standard is already becoming implementation-facing wallet plumbing
OpenZeppelin’s cryptography docs ship SignerERC7913, multisigner variants, and ready-made ERC-7913 verifiers for P256, RSA, and WebAuthn, which is the clearest practical signal that ERC-7913 can become the common adapter layer for heterogeneous signers
Whitepaper: No standalone ERC-7913 whitepaper or litepaper surfaced in this pass. The clearest current sources were the final ERC, the raw ERC markdown, and OpenZeppelin’s smart-account and cryptography documentation; see ../../whitepapers/erc-7913-primary-sources-2026-05-07.md.