ERC-7913 primary sources — 2026-05-07

Project status in this pass

• No standalone ERC-7913 whitepaper or litepaper surfaced.
• The clearest source of truth was the final ERC itself, backed by the raw ERC markdown and OpenZeppelin’s implementation-facing documentation.
• The sources consistently frame ERC-7913 as signer-abstraction infrastructure for heterogeneous keys rather than as a single signature algorithm.

Primary-source snapshots

1) Canonical ERC page

• URL: https://eips.ethereum.org/EIPS/eip-7913
• Key excerpt/signals:
  • The abstract says ERC-7913 extends signer description and signature verification to keys that do not have their own Ethereum identity.
  • The motivation names P256, RSA, email, JWT, and other non-address-native signing schemes as the target surface.
  • The spec requires verifier contracts to expose a verify(bytes key, bytes32 hash, bytes signature) interface.
• Why it mattered:
  • This is the clearest evidence that ERC-7913 belongs in the corpus as generalized authority infrastructure.

2) Raw ERC markdown

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7913.md
• Key excerpt/signals:
  • The signer format is a bytes object that concatenates verifier || key, with the verifier occupying the first 20 bytes.
  • Empty-key cases fall back to ordinary EOA or ERC-1271 verification semantics.
  • The verifier should be stateless and the key itself should carry algorithm-specific material.
• Why it mattered:
  • These details show that ERC-7913 is trying to unify address-based and address-less signers under one portable signer envelope.

3) Security guidance in the ERC text

• URL: https://raw.githubusercontent.com/ethereum/ERCs/master/ERCS/erc-7913.md
• Key excerpt/signals:
  • The ERC says verifier contracts should be trustless, non-upgradeable, and ideally pure or otherwise dependent only on immutable code and key material.
  • It highlights long-lived use cases such as guardians and social recovery, where verifier durability matters over years.
  • It notes that stateless verifiers align cleanly with ERC-7562 scope rules.
• Why it mattered:
  • This is the strongest clue that the verifier contract becomes a durable root of trust in the account-authority stack.

4) OpenZeppelin smart-account docs

• URL: https://docs.openzeppelin.com/contracts/5.x/accounts
• Key excerpt/signals:
  • OpenZeppelin lists SignerERC7913, MultiSignerERC7913, and weighted multisigner variants as first-class smart-account signer options.
  • The docs explicitly say developers do not need to implement a new AbstractSigner for each signature scheme if they provide an ERC-7913 verifier.
  • ERC-7913 is presented alongside ECDSA, P256, RSA, EIP-7702, and ZK-email signer options in the account stack.
• Why it mattered:
  • This is strong evidence that ERC-7913 is already being treated as an implementation-facing adapter layer for heterogeneous signer schemes.

5) OpenZeppelin cryptography docs

• URL: https://docs.openzeppelin.com/contracts/5.x/api/utils/cryptography
• Key excerpt/signals:
  • The cryptography docs list SignerERC7913, multisigner variants, and ready-made ERC-7913 verifiers for P256, RSA, and WebAuthn.
  • The docs describe ERC-7913 as support for keys that do not have their own Ethereum address.
  • The library placement inside general cryptography and account utilities shows the standard is expected to compose directly with existing signature-checking flows.
• Why it mattered:
  • This is the clearest practical evidence that ERC-7913 can serve as a common adapter layer across multiple non-Ethereum signer families.

Working conclusion

ERC-7913 is best cataloged as generalized signer-abstraction infrastructure for smart accounts and wallet authority systems. The decisive evidence in this pass was the final ERC’s verifier || key signer model, its trust-minimized verifier guidance, and OpenZeppelin’s concrete downstream support for ERC-7913-based P256, RSA, WebAuthn, and multisigner flows.