ERC-3475

ERC-3475's core innovation is its two-tiered identifier system. Each bond is defined by a classId (e.g., a specific issuer or risk profile) and a nonceId (a specific issuance series within that class). This allows a single contract to manage thousands of distinct bonds, each with its own metadata, redemption logic, and lifecycle, unlike ERC-20 which requires a new contract per token.

The standard stores extensive metadata for each bond class and series directly on-chain via the getClassMetadata and getNonceMetadata functions. This can include:

• Issuer information and legal terms
• Maturity dates and interest rates
• Redemption rules and call schedules This creates a self-contained, verifiable record, eliminating reliance on external data sources for core bond logic.

ERC-3475 supports complex financial operations through distinct, purpose-built functions, moving beyond simple transfers. Key functions include:

• redeem: For claiming principal at maturity.
• transferFrom: For standard ownership transfer.
• transferFromRedeem: Allows a delegate to redeem on behalf of the holder. This granularity enables automated treasury management and sophisticated DeFi integrations.

While introducing a new data structure, ERC-3475 is designed for interoperability. Wrapper contracts can be built to represent a specific bond series (classId, nonceId) as a standard ERC-20 token for trading on DEXs, or as an ERC-721 NFT for unique representation. This bridges the gap between complex on-chain data and existing DeFi infrastructure.

The standard's flexibility enables the on-chain creation of sophisticated instruments previously limited to TradFi, such as:

• Callable/Puttable Bonds: Bonds that can be redeemed early by the issuer or holder.
• Tranched Debt: Separating risk into senior and junior classes (e.g., for credit derivatives).
• Asset-Backed Securities (ABS): Representing pools of underlying assets with different series for various cash flow rights.

ERC-3475 solves key limitations of using simple ERC-20 tokens for bonds:

• No Proliferation: One contract vs. thousands of ERC-20 contracts.
• Rich Data: On-chain metadata vs. off-chain references.
• Complex Logic: Native support for redemptions and calls vs. custom external logic.
• Atomic Operations: Multi-step actions (like transfer-and-redeem) in a single transaction.

The standard's core function is to split a pool of underlying assets into multiple debt classes with varying risk-return profiles. This enables:

• Senior Tranches: Lower risk, lower yield, first claim on cash flows.
• Mezzanine Tranches: Medium risk and return.
• Equity/Junior Tranches: Highest risk, potential for highest yield, first-loss position. This structure allows investors to select exposure matching their risk appetite and provides issuers with a tool for capital optimization.

ERC-3475 serves as the foundational layer for advanced DeFi protocols, enabling:

• Structured Vaults: Yield-generating strategies that issue tranched tokens representing different risk segments of the strategy's returns.
• Credit Derivatives: The creation of synthetic instruments that allow for the trading of credit risk.
• Liquidity Provision: More capital-efficient lending markets where liquidity providers can choose their risk tier, potentially increasing overall pool depth.

Beyond simple transfers, ERC-3475 defines a rich, standardized metadata interface for debt instruments. This allows wallets, explorers, and analytics platforms to uniformly display and interpret complex bond data, including:

• Maturity schedules and interest payment dates.
• Redemption rules and collateral details.
• Class-specific parameters like seniority and currency. This interoperability is critical for the composability and usability of structured debt across the ecosystem.

The explicit, on-chain representation of debt classes and their terms provides a transparent audit trail for regulatory compliance. Features include:

• Immutable record of ownership and transaction history for each tranche.
• Programmable logic for enforcing transfer restrictions (e.g., accredited investor checks).
• Clear delineation of rights and obligations encoded in the contract, aiding in legal enforceability and reducing settlement friction for institutional adoption.

ERC-3475 introduces a two-layer token model within a single contract to represent complex debt instruments.

• Class IDs represent the bond's tranches or series (e.g., Senior, Subordinated).
• Non-Fungible Token IDs within each class represent individual bonds with unique attributes like maturity date, coupon rate, and principal. This structure allows a single contract to manage thousands of distinct bonds efficiently, unlike ERC-20 which would require a separate contract for each issuance.

The standard is designed to tokenize traditional debt securities, enabling their full lifecycle on-chain.

• Issuance: A DAO or corporation can programmatically create a bond class and issue specific bond tokens to investors.
• Secondary Trading: Each bond (NFT ID) can be traded on decentralized exchanges or OTC markets.
• Redemption & Coupons: The contract can automate interest payments (coupons) and principal repayment at maturity directly to the token holder, without manual claims.

ERC-3475 solves specific limitations of existing token standards for financial products.

• vs. ERC-20: A single ERC-3475 contract can manage multiple bond series, avoiding contract sprawl. It natively supports multiple redemption data points (principal, interest).
• vs. ERC-721: While both are non-fungible, ERC-3475's class structure allows for efficient grouping and batch operations (like paying interest to all holders of a specific class), which is cumbersome with standalone NFTs.

A key innovation is its abstract storage design. The standard does not mandate how bond data (values, dates, metadata) is stored within the contract.

• Flexibility: Developers can implement optimal storage patterns (mappings, arrays) for their specific use case.
• Interface Compliance: As long as the contract implements the core readMetadata, transfer, and redeem functions defined in the interface, it is compliant. This separates the interface from the implementation.

ERC-3525 is another advanced token standard often discussed alongside ERC-3475. Key comparisons:

• Similarity: Both can represent complex financial instruments with an ID and value slots.
• Difference: ERC-3525's SFT is designed for assets where tokens of the same ID (slot) are fungible, but tokens across slots are not. It excels in representing liquidity positions or vesting schedules.
• Contrast: ERC-3475 is more specifically architected for debt, with explicit functions for redemption and a focus on abstract storage for bond metadata.

ERC-3475 embeds compliance logic and issuer-defined metadata directly within the token contract. This allows for:

• Programmable restrictions on transfers based on investor accreditation status or jurisdiction.
• Immutable audit trails of bond lifecycle events (issuance, coupon payments, redemption).
• Transparent disclosure of underlying asset data, reducing reliance on off-chain legal agreements. The standard's structure ensures that key financial terms are verifiable on-chain, enhancing data integrity for regulators and investors.

The multi-dimensional nature of ERC-3475 tokens complicates their regulatory classification. A bond token with classId (bond series) and nonceId (individual bond) could be viewed as:

• A security if marketed with an expectation of profit from the efforts of the issuer.
• A record-keeping tool for an existing, compliant security. The critical factor is the economic reality of the offering, not the technical standard. Issuers must ensure the underlying asset complies with securities laws (e.g., SEC Regulation D, EU's MiCA).

Most standard ERC-20 wallets cannot natively display or interact with the nested data structures of ERC-3475. This creates custody risks:

• Loss of access if wallets misinterpret token balances or metadata.
• Incompatibility with major custodial services designed for simpler fungible tokens.
• User error in selecting the correct classId and nonceId for transactions. Specialized interfaces or smart contract wallets with enhanced logic are required for secure management, raising the barrier to entry and operational complexity.

While ERC-3475 defines an interface, the security of the implementation is paramount. Key risks include:

• Implementation bugs in the core logic for redeeming bonds or paying coupons.
• Oracle dependency for triggering payments based on off-chain events (e.g., interest rate changes). A compromised oracle can lead to incorrect payouts.
• Upgradability risks if the contract uses proxy patterns; a malicious upgrade could alter token terms. Rigorous audits of both the token contract and any dependent oracle systems are essential.

Issuers can encode transferability rules within the token's logic, impacting secondary market liquidity and compliance.

• Whitelists: Can restrict transfers to pre-approved addresses (KYC/AML).
• Lock-ups: Can enforce holding periods to comply with securities regulations.
• Complexity for DEXs: Automated Market Makers (AMMs) like Uniswap are not designed for tokens with such conditional logic, limiting trading venues. These built-in restrictions are a double-edged sword: they ensure regulatory compliance but can fragment liquidity and reduce market efficiency.

Tokenizing real-world assets (RWAs) like bonds does not dissolve the legal entity behind them. Considerations include:

• Issuer Liability: The on-chain token is a representation; the legal issuer remains liable for obligations.
• Enforceability: On-chain compliance logic must mirror and enforce off-chain legal covenants. Discrepancies create legal risk.
• Global Jurisdiction: A bond token traded globally must navigate conflicting securities, tax, and AML laws across jurisdictions where holders reside. Clear legal frameworks defining the relationship between the digital token and the traditional legal instrument are critical for adoption.