This proposal introduces fixed-income financial bonds with key characteristics defined to facilitate bond issuance in the primary market and enable buying or selling bonds in the secondary market. The standard also provides cross-chain functionalities for bonds operations and management across multiple blockchains.
Fixed-income instruments are a widely utilized asset class for corporations and other entities raising funds. However, transitioning to tokenized bonds is challenging due to existing standards like ERC-3475, which introduces unfamiliar concepts and leads to unnecessary gas consumption. Additionally, the lack of named variables like coupon, maturity date, and principal, makes it difficult to implement ERC-3475 since developers need to remember which metadata is assigned to each parameter.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Every contract compliant with this ERC MUST implement the following Token Interface as well as the ERC-165 interface:
The IERC7092ESG interface is OPTIONAL for contracts implementing this proposal. This interface MAY be used to improve the standard usability.
currencyOfCoupon The currency used for coupon payment may be different from the currency used to repay the principalcouponType MAY be employed to signify the interest rate that the issuer has committed to paying to investors, which may take various forms such as zero coupon, fixed rate, floating rate, and more.couponFrequency refers to how often the bond pays interest to its bondholders, and is typically expressed in terms of time periods, such as: Annual, Semi-Annual, Quarterly, or Monthly.dayCountBasis is used to calculate the accrued interest on a bond between two coupon payment dates or other specific periods. Some of the day count basis are: Actual/Actual, 30/360, Actual/360, Actual/365, or 30/365The standard permits the implementation of the IERC7092CrossChain interface for cross-chain management of bond tokens. This interface is OPTIONAL and may be used by applications to allow cross-chain transactions. Any function initiating a cross-chain transaction MUST explicitly define the destination chain identifier destinationChainID and specify the target smart contract destinationContract.
The design of this ERC aims to simplify the migration to tokenized bonds by maintaining consistency with traditional bond standards. This approach allows fixed-income instruments to be represented as on-chain tokens, manageable through wallets, and utilized by applications like decentralized exchanges, while avoiding the complexities and inefficiencies associated with other standards. This ERC facilitates the creation of new bond tokens with characteristics akin to traditional bonds, enhancing accessibility, liquidity, and cost-efficiency in bond trading and management.
The use of traditional finance terminology, like issueVolume and principalOf, is aimed at maintaining consistency with traditional bond language, which eases the adaptation for traditional entities.
The totalSupply and balanceOf functions are not defined as they can be derived from issueVolume and principalOf, and denomination. However, these functions can be be added in any contract implementing this standard, ensuring the proper relationship between these values.
This ERC is not backwards compatible with existing standards like ERC-20 or ERC-1155 due to the absence of certain functions like totalSupply or balanceOf. A pure implementation of this standard is RECOMMENDED for issuing tokenized bonds, as any hybrid solution with other mentioned standards SHOULD fail.
The complete Reference Implementation can be found here.
Bonds with embedded options like callable, puttable, or convertible bonds can be created by inheriting from the reference ERC7092.sol that integrates the proposed interface.
This standard is designed specifically for tokenizing bonds. It does not inherently manage information pertaining to bondholders' identities. However, to enhance compliance with regulatory requirements and improve transparency, an identity registry can be added on top of this standard to store the identity of all authorized investors.
By maintaining an identity registry, issuers can ensure that bond tokens issued under the ERC7092 standard are transferred only to registered and authorized entities. This practice aligns with regulatory compliance measures and provides a structured way to manage and verify the identity of bondholders. It also helps prevent unauthorized or non-compliant transfers of bond tokens.
Implementing this ERC requires careful consideration of security risks related to functions approving operators to manage owner's bonds and functions allowing bond transfers. The use of these functions necessitates robust validation to ensure only the bond owner or approved accounts can call them.
Copyright and related rights waived via CC0.