[Draft ERC] IBond: A Standard Interface for Fixed-Rate Bonds

EIPs
, ,
1

Summary

I created IBond as a standard for fixed-rate bonds that the Ethereum community can agree on. A shared standard would make bonds easy for third parties, such as wallets, to track and allow tradable bond markets to proliferate across EVM chains.

For now, I am sharing only IBond: an interface for a zero-coupon bond, the simplest type of bond. IBond extends ERC-20, making each bond an ERC-20 token with a zero-coupon payment at maturity.

A very important detail is that the bond can operate and pay the user without requiring the bondholder to execute any on-chain transactions. The experience should match a brokerage account: once you buy the bond, you automatically receive payment and have your bond burned without submitting a transaction yourself.

IBond can be extended for many different types of bonds (coupon, callable, convertible, etc.).

The interface uses familiar financial terminology and is designed to be easy to read. The goal is adoption by RWA companies and banks, creating a shared standard that allows fixed-rate financial instruments to proliferate on-chain.

I wanted to prove that the interface worked well, so I built a complete proof of concept. That process allowed me to work through IBond in detail and reduce it to the minimum necessary interface. The proof of concept includes the following:

  • I mirrored the entire fixed-rate U.S. Treasury market ($7 trillion) to show that the interface works for the world’s largest bond market.

  • I built a playground for launching corporate-style bonds to show that the interface works with one of the most dynamic bond markets.

  • I built the following extensions for bonds: callable, convertible, coupon, puttable, regulated, reopenable, retireable, and subscription bonds.

  • I calculated that running a 10-year note on Base, with 20 coupon payments for 2,500 holders, would cost roughly $300, showing that operating real bonds on-chain can be economical.

I have chosen to share only IBond for now because it is the core interface on which everything else depends. There is no point in sharing the rest until the core is agreed upon.

I have completed a draft ERC and built a working proof of concept. Before opening the formal EIP PR, I want feedback on the core design and on whether this is the right interoperability boundary.

If anyone wants to collaborate, please reach out here. The goal is to build all the bond extensions and release them publicly as open source, but I will put in that effort only if there is real interest in seeing them built.

Draft EIP and interface: IBond

Working proof of concept: EVM Bonds

More details are provided below.

Problem

Tokenized bonds are being issued across RWA platforms, but no shared bond interface has become the standard across issuers, wallets, custodians, and indexers.

Crypto has historically used its own bond terminology, which is not always TradFi-friendly. Bonds, however, are inherently dominated by TradFi, so this standard should adopt the language used by banks, brokerages, and fixed-income markets: issuer, face principal, denomination, issue date, maturity, funding state, whether payments are on time, and what each holder can currently claim.

We have also created a poor user experience by requiring bondholders to claim their payments. The holder of an EVM bond should not have to do anything. The bond should work as it would in a brokerage account, with payments deposited automatically.

Bonds have yet to take off on Ethereum because we have not made a strong attempt at a shared bond interface. We should solve this now. Crypto companies such as Coinbase and MicroStrategy already issue bonds in traditional markets; they should also be able to issue them on a blockchain. Eventually, they will.

Proposal

IBond is a small interface for one fungible fixed-rate bond series per contract. It inherits ERC-20; IBond standardizes the bond-specific terms, accounting, servicing state, and actions.

Here is the complete proposed IBond interface, including its NatSpec (scroll within the grey window to see the whole interface):

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.24;
import {IERC20Minimal} from "./IERC20Minimal.sol";

/// @title IBond
/// @notice ERC-20-compatible interface for an on-chain-settled, principal-at-maturity bond series.
interface IBond is IERC20Minimal {

enum Lifecycle {
  /// @notice Terms exist and the bond has not started regular servicing.
  Created,
  /// @notice the bond is outstanding and servicing before maturity.
  Live,
  /// @notice The bond has reached its maturity date.
  Matured,
  /// @notice No bond units remain outstanding and settlement is complete.
  Settled
}

enum PaymentStatus {
  /// @notice No due payment is currently late under the bond's payment-status rules.
  Performing,
  /// @notice A due payment is unpaid but has not reached its default condition.
  Late,
  /// @notice The payment has reached a contractual or authoritative default condition.
  Default
}

event BondUnitsIssued(address indexed issuer, address indexed receiver, uint256 principalAmount, uint256 bondUnits);
event PrincipalFunded(address indexed payer, uint256 amount, PaymentStatus indexed status);
event BondUnitsRedeemed(address indexed holder, address indexed receiver, uint256 bondUnits, uint256 principalAmount);

// -------------------------------------------------------------------------
// View functions
// -------------------------------------------------------------------------

/// @notice Returns the on-chain obligor responsible for bond payments.
function issuer() external view returns (address);

/// @notice Returns the ERC-20 token in which the bond is denominated and settled.
function asset() external view returns (address);

/// @notice Returns the maximum face principal the bond can issue and owe at maturity.
function principalCap() external view returns (uint256);

/// @notice Returns the timestamp that anchors the bond's regular servicing schedule.
function issueDate() external view returns (uint64);

/// @notice Returns the timestamp when the bond matures.
function maturityDate() external view returns (uint64);

/// @notice Returns the current lifecycle state.
function lifecycle() external view returns (Lifecycle);

/// @notice Returns the current principal payment status.
function principalPaymentStatus() external view returns (PaymentStatus);

/// @notice Returns the face principal represented by bond units counted as issued.
function issuedPrincipal() external view returns (uint256);

/// @notice Returns bond token units currently issued. Redemptions do not lower this value.
function issuedBondUnits() external view returns (uint256);

/// @notice Returns the face principal represented by one whole displayed bond token i.e. 10 ** decimals().
function denomination() external view returns (uint256);

/// @notice Returns the principal amount represented by a holder's bond token balance.
function principalOf(address holder) external view returns (uint256);

/// @notice Converts bond token units to represented principal.
function bondUnitsToPrincipal(uint256 bondUnits) external view returns (uint256);

/// @notice Converts principal amount to bond token units.
function principalToBondUnits(uint256 principalAmount) external view returns (uint256);

/// @notice Returns whether maturity principal has been fully funded for redemption.
function principalFunded() external view returns (bool);

/// @notice Returns the bond asset currently claimable by a holder.
function holderClaimable(address holder) external view returns (uint256);

// -------------------------------------------------------------------------
// State changing functions
// -------------------------------------------------------------------------

/// @notice Issues bond units under the implementation's issuance rules.
function issue(uint256 bondUnits, address receiver) external returns (uint256 principalIssued);

/// @notice Funds the exact remaining maturity principal cash for redemption.
function fundPrincipal() external returns (uint256 funded);

/// @notice Claims bond asset currently owed to the caller.
function claim(address receiver) external returns (uint256 claimed);

/// @notice Claims bond asset owed to a holder, using bond-token ERC-20 allowance.
function claimFrom(address holder, address receiver) external returns (uint256 claimed);
}

There are essentially three state-changing operations:

  • issue() allows the issuer to create bonds and send them to a holder.
  • fundPrincipal() allows the issuer to repay the bond, making claim() available.
  • claim() and claimFrom() allow a holder’s bond to be burned and the holder to receive the assets they are entitled to. claimFrom() lets the issuer do this automatically for bondholders by using ERC-20 allowance.

There are two types:

  • Lifecycle represents whether a bond is Created, Live, Matured, or Settled. The first three states are based on timestamps. A bond becomes Settled once it is Matured and all bond units have been burned.
  • PaymentStatus represents whether a bond is performing, late on a payment, or in default. It deliberately uses only these three states because each bond may have many legal factors that determine its true status.

The view functions are self explanatory with their descriptions above.

Auctions, subscriptions, coupon schedules, calls, puts, conversion, reopenings, transfer restrictions, custody, identity systems, legal documents, and marketplaces remain outside the core. Those mechanics can vary without changing what the bond owes or how an integration reads its state.

Relationship to existing ERCs and other financial standards

  • ERC-3475: Abstract Storage Bonds represents multiple bond classes and nonces in one contract and relies heavily on a metadata model. IBond instead uses one contract per fungible series and exposes the main financial terms and accounting as typed views.

  • ERC-7092: Financial Bonds established important bond-specific terminology and actions. IBond differs by defining explicit principal/unit conversion, issued and circulating-unit accounting, separate lifecycle and payment-performance state, maturity-principal funding, and holder-claimable amounts.

This proposal is deliberately narrower than a complete issuance or RWA protocol. It standardizes the bond itself, while allowing different auction, settlement, compliance, custody, and legal architectures around it.

IBond represents a deliberately constrained ACTUS Principal-at-Maturity profile as an ERC-20 claim token with executable on-chain funding and holder settlement. It complements broader security-token frameworks such as CMTAT: legal documents, compliance, identity, and transfer controls remain composable extensions.

Working proof of concept

IBond is implemented, tested, and usable now.

The proof of concept includes zero-coupon and coupon-bearing bonds, a reference base implementation, and optional extensions for issuer-serviced payments, batching, subscriptions, reopenings, calls, puts, conversion, retirement, payment-status windows, and regulated-transfer controls.

At EVM Bonds you can:

  • configure and deploy an experimental corporate or U.S. Treasury-style bond on Base Sepolia;

  • inspect live IBond reads from deployed corporate-bond replicas;

  • browse active U.S. Treasury bills mirrored as individual read-only bond contracts; and

  • review a gas model for distributing and servicing bonds at institutional scale.

The site and contracts are experimental and unaudited, but they demonstrate that the proposed interface works across actual coupon, principal, issuance, servicing, redemption, and reopening flows.

Not in scope

  • Privacy — We are not considering private transactions here. Transactions would remain pseudonymous as long as a user’s identity is not publicly linked to their address.

  • KYC/AML requirements — These are not core to what we are implementing here, although an extension for them is 100% necessary.

  • Subscriptions / auctions — This implementation assumes that the bond has already been sold and that the issuer has a list of addresses and their bond-token allocations to set up at launch. Subscriptions and auctions should eventually happen on-chain, but they are a separate concern.

Feedback

I would appreciate feedback on the interface: whether anything should be added or removed, and whether other projects are working on something similar. Please reach out in this thread.