Category: bond / obligation token standard / class-nonce tokenization primitive / metadata-rich redemption interface
Summary: ERC-3475 is best understood as a lower-layer interface for tokenized obligations, not just as another bond wrapper or LP-token alternative. Its core move is to represent obligations inside one contract as a two-dimensional grid: classId names a bond family and nonceId names a specific issuance condition, maturity bucket, or redemption state inside that family. Around that grid it standardizes batch issuance, transfer, redemption, burn, approval, supply accounting, progress reporting, and metadata/value schemas. That makes ERC-3475 analytically useful because it exposes where practical control sits in tokenized-obligation systems: who is allowed to issue and redeem, how maturity conditions are encoded, how much state lives onchain, and whether secondary-market divisibility exists before richer compliance or distribution layers are added.
What it does:
Models obligations through classId plus nonceId, letting one contract host many related bond types and many issuance states per bond family
Standardizes batch-oriented Transaction[] flows for transfer, issue, redeem, burn, and approve, rather than forcing one-token-one-call patterns
Exposes separate supply views for total, active, redeemed, and burned balances at the class-and-nonce level
Adds class and nonce metadata/value structures so redemption conditions, descriptive fields, and other obligation parameters can be stored and queried onchain
Includes getProgress(classId, nonceId) as a standard hook for maturity or redemption-status reporting, making time/liquidity-condition tracking explicit rather than hidden in bespoke app logic
Supports both per-class operator approval and per-class-and-nonce allowance accounting, which makes delegated movement a visible policy surface instead of a generic ERC-20 allowance clone
Key claims:
The most important design insight is the split between classId and nonceId. ERC-3475 does not treat a bond as one fungible bucket; it treats it as a family of obligations whose issuance terms, maturity conditions, and metadata can differ while still sharing one broader instrument namespace.
The EIP’s own terminology is revealing: a Bank issues, redeems, or burns bonds once conditions are met. That makes issuer or controller power explicit instead of hiding it behind neutral token language.
The batch Transaction[] design matters because it treats bond movement as portfolio manipulation across multiple instrument slices, not just as sending one fungible balance number from A to B.
Its metadata-and-values architecture is analytically useful even beyond bonds. It shows one path for putting redemption conditions and instrument descriptors onchain without collapsing everything into separate contracts or offchain documents.
The Debond implementation README makes the intended comparison class clearer than the EIP alone: the standard was pitched as a richer replacement for simple LP-token patterns where one ERC-20 balance cannot express multiple redemption states or obligation terms.
ERC-3475 belongs in the corpus because it gives the compliance / tokenization cluster a reusable lower-bound comparison point for obligation state, maturity logic, and issuer-controlled redemption before identity, transfer-restriction, and administrator-policy layers get stacked on top.
Whitepaper: No standalone ERC-3475 whitepaper surfaced in this pass. The strongest primary materials were the canonical EIP text and Debond’s official example-implementation README collected in ../../whitepapers/erc-3475-primary-sources-2026-05-12.md.