User:LesDecroissant/sandbox

= EIP-3475 (Abstract Bonds Standard). =

ERC-3475 (Abstract Bonds standard) is the Ethereum Improvement Proposal standard defined by  the members of the fintech startup Debond, that  defines the interface for the functions to issue and settle the tokenized obligations (bonds, securities etc ) by using on-chain metadata storage.

Background
Current protocols in the DeFI space use LP tokens (Liquidity Provider tokens on top of ERC-20 standard )  only store the  name, symbol and token-supply as the metadata in order to settle P2P transactions in Ethereum. These details are not sufficient in case if someone wants to issue bonds fully on-chain, as you will be needing multiple information like:


 * 1) Track each type of supply  of the bonds that are redeemed, burned or currently are in active circulation.
 * 2) additional parameters that define the interest and rate of redemption conditions
 * 3) Adding additional metadata details to categorise the type of bonds and the data they store  in order to be interoperable across various Bond Exchanges (Including both traditional finance and DEX exchanges ).

Given that bonds markets have been recent entrant in DeFI with various proof of concepts developed  but they have been hard to scale given  the dependence on off-chain asset settlement and information storage  removes the core benefits of the blockchain based bonds being trust-less and interoperable.

Thus the rationale behind this standard was primarily to remove above  issue along with :


 * Creation of any arbitrary type of obligation with same interfaces.
 * Integration of crypto-wallets and other exchanges to read the redemption information
 * To efficiently issue and redeem the bonds as tradable instruments which then can be exchanged in the secondary markets.
 * Efficiency in handling operations on-chain (gas efficiency, storage, etc).

1. Class and Nonce :

 * Class consist of hierarchical information that is used to categorise different types of bonds based on their categories  like  rate of interest,  redemption type (zero-coupon or floating rate) . Unlike the traditional bonds that evaluate the bond classes on the basis of certain standards, this standard allows  addition of metadata and values that are native to each class, so that bond owners and exchanges have clarity about  the bonds issued from the given class.
 * Nonce is the indexation of the bonds issued to the given owner from the given class. this  includes  details like initial supply of the bond, owner address,

Corresponding EIP document defines the metadata standard  in order to explain  how the partners in the exchanges need to store the class/nonce metadata of each value that are stored  in the bonds during the creation of the bond.

2. Miscellaneous Points

 * Class is defined by the central orchestrator contract that has the admin role to whitelist the class and define the corresponding redemption properties.
 * There needs to be the liquidity pool that will store the liquidity deposited by the users in order for the orchestrator to issue the bonds.  All  the current  designs in the current traditional-finance/DeFI ecosystem ( traditional market-makers, automated-market-makers) need to build  the interface functions to add / remove liquidity and this way this standard tends to be  interoperable. apart from that users can build the

Use-Case

 * 1) Building Financial Derivatives  with custom logic of redemption, which has been a challenge due  lack of additional on-chain metrics.
 * 2) Building  multilayered pools:  unlike the current AMM's which are inefficient in terms of gas costs for operations,  multilayered pools  can list multiple asset classes via the single bond. this will be significant optimization than the current bonding services like olympusDAO  that have to create factory contracts for each LP bond pair . thus providing better management of the portfolio and the investment. also based on the minimal implementation of the protocol by the co-authors, the stats show 10 times less gas fees consumption vis-a-vis traditional projects like Uniswap-V3, Curve.



Interface and Implementation:
The interface defined in the relevant  EIP documentation. Users can import this interface and then they should validate the following details before developing your own bonds :


 * Data-structures for the class and nonce respectively.
 * logic for issuing, allowance, transfer and redemption operations
 * admin roles for the addition of class details and changing the parameters of redemption.

Adoption:
After the validation of the EIP standard in end week of august and covered by the media extensively. Also the parent company Debond has been working to build a decentralised protocol and web-application based on this standard. they have defined the protocol implementation in the whitepaper.