ERC-735

ERC-735 is a proposal for a standard interface for Claim Holder contracts, which are often paired with ERC-725 identity contracts. Its primary function is to allow an Ethereum-based identity to issue, add, remove, and query claims made by or about itself. A claim is a statement from an issuer (another identity) about the subject (the claim holder), such as a verification of an email address, a KYC attestation, or a proof of membership. This standard does not define the validity or trustworthiness of a claim; it merely provides a structured way to store and reference them on-chain.

The standard specifies key functions like addClaim, removeClaim, and getClaim. Each claim contains metadata including the claim type, the issuer's address, the signature scheme used, the actual data of the claim, and a URI pointing to external evidence. By separating the identity (ERC-725) from the claims about it (ERC-735), the design allows for modular and upgradable identity systems. This enables use cases where an identity can aggregate verifications from multiple, potentially trusted, sources without modifying its core identity contract.

In practice, ERC-735 is a foundational component for Decentralized Identity (DID) and Self-Sovereign Identity (SSI) systems on Ethereum. For example, a university (issuer) could sign a claim attesting that a specific Ethereum address (subject) holds a degree. The graduate's identity contract would store this signed claim via ERC-735. A third party, like an employer, could then cryptographically verify this claim by checking the issuer's signature. While not as widely adopted as some token standards, ERC-735 provides the critical attestation layer for more complex identity frameworks like those proposed by the Decentralized Identity Foundation (DIF).

ERC-735, or Ethereum Request for Comments 735, defines a smart contract interface for managing claims. A claim is a signed piece of data from an issuer (a trusted entity) about a subject (typically a user's Ethereum address). The core mechanism involves three primary functions: adding a claim, removing a claim, and querying claims. Claims are stored with metadata including the claim type, scheme, issuer address, signature, data, and a URI for off-chain evidence. This structure allows any external contract or dApp to programmatically verify assertions about an identity without relying on a centralized database.

The standard specifies several claim types (e.g., 1 for KYC, 2 for accreditation) and signature schemes (e.g., ECDSA, EIP-191). When an issuer creates a claim, they hash the claim data, sign it with their private key, and submit it to the subject's claim holder contract. The subject must then invoke addClaim to store this signed data on-chain. Verification is performed off-chain by a relying party, who can cryptographically check the issuer's signature against the stored data and the issuer's known public key, ensuring the claim's authenticity and integrity.

A key innovation of ERC-735 is its separation of the Claim Holder and Claim Verifier roles. The Claim Holder is a smart contract, often deployed per user or attached to an ERC-725 identity, that stores claims. The Claim Verifier is any logic, on-chain or off-chain, that interprets these claims. This design enables modularity; for instance, a DeFi protocol (the verifier) can check for a specific KYC claim type from a known regulator (the issuer) stored in a user's holder contract before permitting a transaction, enabling compliant decentralized applications.

ERC-735 is intrinsically linked with ERC-725, which defines a standard for blockchain identities. ERC-725v2 identities can implement the ERC-735 interface directly, creating a unified identity and claim management system. This combination allows an Ethereum Address to act as a programmable agent with attached verifiable credentials. Use cases extend beyond KYC to include proof-of-membership, skill attestations, and reputation scores, forming a foundational layer for decentralized identity (DID) and trust frameworks within the Web3 ecosystem.

While powerful, ERC-735 has limitations. Storing claim data fully on-chain can be costly, which is why the standard supports linking to off-chain data via the URI field. Furthermore, the standard does not define revocation mechanisms or the trustworthiness of issuers; these are social and application-layer concerns. Despite its status as a draft proposal and not a final standard, ERC-735's design has significantly influenced subsequent identity solutions like Verifiable Credentials and the work of the Decentralized Identity Foundation.

ERC-725 and ERC-735 form a symbiotic architectural pair for decentralized identity. ERC-725 defines a smart contract-based proxy account that acts as a programmable, blockchain-native identity. This identity can hold assets, execute transactions via its attached keys, and, crucially, interact with other smart contracts. ERC-735 is then implemented as an extension within an ERC-725 identity, adding the specific functionality to publish, manage, and revoke verifiable claims. Think of ERC-725 as the 'wallet' or 'container' for the identity, and ERC-735 as a specialized 'module' installed into that container to handle attestations.

The relationship is explicitly defined in the ERC-735 specification, which states that a claim holder contract MUST implement the ERC-735 interface and SHOULD implement ERC-725. This design allows the claim data (managed by ERC-735) to be intrinsically linked to the identity's keys and execution logic (managed by ERC-725). For example, a CompanyIdentity (ERC-725) could have an attached ClaimsRegistry (ERC-735) holding a claim issued by a trusted auditor verifying its business license. Any third-party dApp can then query the CompanyIdentity to find and verify this credential in a single, standardized interaction.

This modular separation of concerns provides significant flexibility. An ERC-725 identity can choose not to use ERC-735 if claim management is not needed, or it can implement multiple claim schemes. Furthermore, because ERC-725 identities are upgradeable proxy contracts, the claim logic can be improved or replaced over time without losing the core identity and its associated assets. This foundational pattern of a core identity (ERC-725) with pluggable functionality has influenced later, more integrated identity standards like ERC-725v2 and the broader Ethereum Attestation Service (EAS) ecosystem, which builds upon these core concepts of separable identity and verifiable data.

ERC-735 is an Ethereum Request for Comments (ERC) standard, numbered 735, that was proposed in 2017 by Fabian Vogelsteller, the co-author of the widely adopted ERC-20 token standard. Its formal title is "Claim Holder" and it was designed to work in tandem with ERC-725, the "Identity" standard. The number 735 follows sequentially from ERC-725, reflecting their intended symbiotic relationship. The proposal was part of a broader vision for a decentralized identity framework on Ethereum, where an ERC-725 identity contract could hold and manage claims issued by third parties via ERC-735.

The core concept of ERC-735 was to create a standardized way for smart contracts to request, hold, and verify claims—also known as attestations—about an identity. A claim could be any verifiable statement, such as a proof-of-age, a KYC certification, or a membership credential. The standard defined functions for adding, removing, and querying claims, with each claim containing metadata like the claim issuer's address, the claim type, and the actual data. This structure aimed to move identity verification logic on-chain, enabling trustless interactions based on verified attributes.

Despite its innovative design, ERC-735 was never formally finalized or widely implemented as an official Ethereum Standard (EIP). It remained in a draft state. The complexity of on-chain claim management, coupled with high gas costs and evolving architectural preferences, limited its adoption. The broader ecosystem began to favor off-chain attestation models, where verifiable credentials are signed and stored off-chain (e.g., using W3C Verifiable Credentials) and only minimal proofs or references are brought on-chain as needed for verification.

The historical significance of ERC-735 lies in its role as a foundational thought experiment that helped shape the discourse around decentralized identity (DID). It directly influenced later, more successful standards and systems. Its concepts are evident in the ERC-1056 (Lightweight Identity) standard, the ERC-780 (Claim Registry) proposal, and the architecture of Soulbound Tokens (SBTs) and non-transferable badges, which serve as on-chain attestations of reputation or membership.

Today, ERC-735 is studied as an important milestone in the evolution of blockchain-based identity. While superseded by more efficient and scalable approaches, its proposal provided a crucial early blueprint for how smart contracts could manage trust and verifiable data, paving the way for the current generation of decentralized identifiers (DIDs) and verifiable credential ecosystems that prioritize user sovereignty and privacy.