Title: ERC_7092__Financial_Bonds
Category: ERCs

Author: samsay
Date: 2023-05-27T21:12:29.827Z

Implementing a standard API for Financial Bonds. This standard allows Institutions, Corporations, Municipalities, Decentralized Exchanges and Individuals to issue bonds in the Primary Market, to exchange bonds in the Secondary Market, and to redeem bonds when they mature.
The standard defines all the basic properties needed to model a financial bond, such as the issue date, the maturity date, the coupon rate, the principal, and the currency.
The standard could then be used to create bonds with embedded options such as CALLABLE bonds, PUTTABLE bonds, and CONVERTIBLE bonds.
Link to the draft EIP:   Financial bonds - ERC-7092
https://github.com/ethereum/ERCs/pull/279

Author: xinbenlv
Date: 2023-05-29T22:20:58.139Z

Thank you for the EIP. This seems interesting!
/**
* @notice Returns the bond maturity date, i.e, the date when the pricipal is repaid. This is a Unix Timestamp like the one returned by block.timestamp
*         The maturityDate MUST be less than the issueDate
*/
function maturityDate() external view returns(uint256);

Should it be “greater than” rather than “less than” here?

Author: samsay
Date: 2023-05-30T09:43:21.819Z

Hello @xinbenlv
Thank you for the comment.
You’re right, it should be “greater than”, rather than “less than”. Going to correct it right now.

Author: ToDestiny
Date: 2023-06-01T15:56:38.228Z

This is really great! Let’s disrupt the TradFi and give back power to the people!

Author: samsay
Date: 2023-06-01T16:17:42.632Z

@ToDestiny
Yes, By proposing Tokenized bonds, more people could be interested in the Bond Market. And since smart contracts will replace intermediaries, people will have more power on their bonds, they can manage their bonds by their own.

Author: ownerlessinc
Date: 2023-09-22T00:38:38.530Z

I’m very well inclined to help build this ERC!!
Is there an active repo open for contribution?

Author: samsay
Date: 2023-09-25T19:02:26.836Z

Hello @ownerlessinc
Thank you for your interest.
Could you send me a message on LinkedIn ? I will let you know how you can contribute to the ERC (give you access to the repo)
Here is my LinkedIn
https://www.linkedin.com/in/samuel-ongala-edoumou/

Author: SamWilsn
Date: 2023-10-30T20:37:35.506Z

I would recommend putting the optional functions (eg. currencyOfCoupon, couponType, etc) into their own interfaces. Even if you don’t explicitly support ERC-165 (which do I recommend you do), putting them into interfaces will make it easier for anyone who wants to use ERC-165.

Author: samsay
Date: 2023-10-31T03:21:30.341Z

Hello @SamWilsn,
Supporting ERC-165 was one of the option I thought about for ERC-7092. I abandoned that idea because these functions are optional. But now that you have pointed it out I think using the interfaces for optional functions is a good option that  need to be considered.

Author: samsay
Date: 2023-11-01T00:30:27.211Z

ERC-7092 now supports ERC-165
Thank you @SamWilsn for your suggestion.

Author: Mani-T
Date: 2023-11-01T05:47:23.089Z

This is a step in the right direction for simplifying the tokenization of bonds.

Author: samsay
Date: 2023-11-07T17:54:05.682Z

Thank you @Mani-T
We tried to make the standard as close as to what in done in TradFi in order to let Issuers, Investors and Institutions that issue Bonds to move to Tokenize bonds without significant disruption, but also to allow people who cannot invest in the bond Market to participate, thanks to fractionalization that lowers the entry barrier for retail investors.

Author: BorisB
Date: 2023-12-03T15:10:54.460Z

Hello @samsay
Could you please elaborate on _spender, in traditional finance that would be the buyer/lender ?
Thank you

Author: samsay
Date: 2023-12-03T22:37:19.351Z

Hello @BorisB,
In traditional finance, bonds are managed by intermediaries and orders are passed and settled by broker dealers or OTC. As a consequence, _spender in the traditional fiance are usually those intermediaries that are approved to spend bonds on behalf of bondholders.
The ERC-7092 has the ability to remove those intermediaries, and allows bonds to be traded from one investor to another directly, or to use the traditional schema with intermediaries replaced by smart contracts. Therefore, the _spender could be either the investor who holds the bond, or the smart contract that has been approved by the bondholder to spend their bonds.
If we consider a case a traditional institution would like to issue bonds on behalf of their clients (issuers) through the ERC-7092, they may consider the following steps:

Create the Bond Contract, which implements the ERC-7092 standard interface
Create a Bank Contract, which MUST be considered as the core contract where all transactions should take place. This contract is responsible for all the work done by broker dealers and Investment Banks. It MUST define an array of MANAGERS in charge of triggering some actions like calling the issueBonds function when the total issue size is reached, or calling the redeemBonds function when bonds Mature. Investors MUST approve the Bank Contract to Transfer their bonds in case bonds are traded in the secondary market. In that case, the _spender is still the bondholder (investor), but the transfer of bonds can be done only by the Bank Contract that has been approved by the holder.

There could be a case where bonds need to be listed on a bond exchange. Listing bonds may require the _spender or investor to transfer their bonds to the exchange which then becomes the _spender in charge of selling bonds on behalf of bondholder.
Another case is when bonds are traded from one investor to another without any intermediary. In that case, the _spender is always the investor or bond owner.
In short, what the bond _spender should be, depends on how project owners want bonds to be managed.

Author: BorisB
Date: 2023-12-04T15:36:15.288Z

Hi @samsay
Thank you for describing the potential use cases, that is very helpful.
Boris

Author: Atlas
Date: 2024-01-26T10:33:47.187Z

Thanks for all your work on this! I’ve been looking primarily at the IERC7092CrossChain portion for adaptation to our system, and have a concern about the destination address data type.
For support to more ecosystems, might it be better to use a bytes format in case a destination chain may require larger recipient addresses?

Author: samsay
Date: 2024-01-28T02:42:19.965Z

Hello @Atlas,
Thank you for your suggestion.


The destination address in cross-chain functions is the address of the smart contract to interact with on the destination chain. Its type MUST be address as it is defined in the IERC-7092 interface.


However if by destination address you meant the destination chain ID which is of type bytes32, this of course could have been expressed as bytes. But it seems like a bytes32 is more likely sufficient to store this parameter. For example

ChainLink uses uint64 to represent the destination chain ID (see here). We’ve already tested successfully the cross-chain transfer of bonds issued through ERC-7092 by using chainlink CCIP.
Toposphere uses bytes32 to represent the destination chain ID (see here). Cross-chain functionalities not yet tested, but a complete application using ERC-7092 already deployed on their chain: Bonds issuance, bonds transfer, coupon payment, listing bonds on exchange, selling and buying bonds on exchange, unlisting bonds from exchange, updating bonds price on exchange, etc. (youtube video on Bonds issued and managed with ERC-7092).
CryptoLink uses directly the destination chain ID like 1 for Ethereum Mainnet, 5 for Ethereum Goerli, 43113 for Avalanche testnet, etc. (see here). Working on it right now to test bonds management accros several chains



I confess that your suggestion is quite interesting, but using bytes instead of bytes32 could lead to some issue if one refers to this check here

Author: Atlas
Date: 2024-01-28T07:17:53.563Z

Hello @samsay,
Thanks for your reply, and the comment on the bytes, you’re right.
I was suggesting destination address and not destination chain - for example, if I were to transfer to Cardano recipient addr1v8fet8gavr6elqt6q50skkjf025zthqu6vr56l5k39sp9aqlvz2g4
I have to admit that I have just begun to dig into the specifics of ERC, and I believe that it may not come into play where you need the recipient address on the destination chains, so I think my comment here might not apply as far as recipient wallets, apologies  but it may apply when sending requests to destination contracts, for example:
    function crossChainApprove(address _spender, uint256 _amount, bytes32 _destinationChainID, address _destinationContract) external returns(bool);

I believe that the address type may not be large enough for example on Cardano to address a destination contract?

Author: samsay
Date: 2024-01-28T16:21:05.742Z

Hello @Atlas,
Sure! the address type couldn’t be used to store large chains of characters like some cardano addresses.
However, if you look at what is being proposed through cross-chain protocols like chainlink, topos, cryptoLink, etc., you will realize that all the chains proposed are EVM compatible.
Of course, in case of non-EVM compatible destination chain, extra functions could be added on top of IERC-7092 to deal with address format on other blockchains. These functions will have same signature as the one defined in the IER-7092, only the type of the destinationContract should be adapted to fit the length on the destination chain.

Author: bumblefudge
Date: 2024-03-05T16:07:29.496Z

samsay:

Of course, in case of non-EVM compatible destination chain, extra functions could be added on top of IERC-7092 to deal with address format on other blockchains


sounds like a job for CAIP-2/CAIP-10?

Author: samsay
Date: 2024-03-08T02:37:19.196Z

sounds interesting.
Why that’s not been proposed as an EIP (on Ethereum) ?

Author: bumblefudge
Date: 2024-03-08T15:44:03.857Z

it’s a chain-agnostic standard, not an ethereum standard.  links to the documentation sites of other L1s aren’t really welcome in EIPs 
there’s basically a separate standing WG for that stuff:
https://org.chainagnostic.org/

Author: samsay
Date: 2024-03-10T22:26:57.434Z

hello @bumblefudge,
Yes, I got it. I was asking why you the standard hasn’t been published as an EIP. What motivated the chain-agnostic choice ?

Author: bumblefudge
Date: 2024-03-11T19:49:15.415Z

sorry not sure i follow.  CAIP-2 and CAIP-10 allow EVM- and completely non-EVM chains to use an heirarchical URN scheme with sub-namespaces per L1 to share a mega-namespace.  does that answer the question? an EIP could be written that just re-states the final CAIP, but i’d rather CAIPs just had equal status as EIPs in some contexts, that would be a better long-term outcome for the CAIP process (it would get better feedback/review from EIP authors, if nothing else!)

Author: wjmelements
Date: 2024-06-18T02:01:25.221Z

There doesn’t appear to be a standard way to pay or collect the coupon.
Many of the view methods can behave arbitrarily (for example couponRate and couponType), with specifications being RECOMMENDED.

Author: ivica
Date: 2024-06-19T22:01:27.272Z

Why including cross-chain transfer capabilities into the specification? It looks overbloated to me.

Author: samsay
Date: 2024-07-04T15:30:19.443Z

The coupon payment enter into the standard through the couponRate and couponType parameters. When implementing this standard, these two parameters are used for the coupon calculation. Once the value of the coupon is obtained, the interest can be paid through a function implemented for that need. That’s why these two parameters are RECOMMENDED, because they are necessary for the coupon calculation.

Author: samsay
Date: 2024-07-04T15:39:37.388Z

The cross-chain transferability property of tokenized assets is necessary to:

Enhance Liquidity
Allow a broader adoption

However, as it is stated in the standard, all cross-chain transfer capabilities or functions are OPTIONAL, projects don’t have to implement those capabilities. The CrossChain interface being OPTIONAL, developers who which to implement these capabilities could decide to use another cross-chain solution.

Author: wjmelements
Date: 2024-07-14T21:56:37.600Z

samsay:

the interest can be paid through a function implemented for that need.


My complaint is that these aren’t standardized. Even the meaning of couponType isn’t specified. Every bond can define their own different way to collect the coupon payments, and can invent their own couponType. How chaotic!

Author: samsay
Date: 2024-07-16T22:54:29.652Z

Are sure that the meaning of couponType is not specified ?
0 → Zero coupon
1 → Fixed rate
2 → Floating rate
Mind you! The coupon type is OPTIONAL.
image1934×242 26 KB

Author: wjmelements
Date: 2024-07-16T23:10:08.996Z

samsay:

Are sure that the meaning of couponType is not specified ?


Yes



 samsay:

Mind you! The coupon type is OPTIONAL.


exactly. And all of its meanings are merely suggestions.

Author: samsay
Date: 2024-07-16T23:41:17.064Z

The standard specifies that the couponType MUST be a uint8 integer. So any uint8 used as the bondType should be compliant with the standard.
What you called suggestions here are just an example showing how the bond type could be mapped to a uint8. It is not not a RECOMMENDATION, developers could use what fits well for their projects, keeping in mind that the value MUST be a uint8 as specified by the standard.

Author: samsay
Date: 2024-07-16T23:50:27.211Z

As for the couponRate, the standard specifies that it MUST be a uint256.
The standard RECOMMENDS the use of basis point unit because this unit is widely used in Finance to express interest rates. A recommendation is not a MUST, the only requirement for couponRate to fall under this standard is IT MUST BE a UINT256

Author: wjmelements
Date: 2024-07-17T18:22:37.226Z

samsay:

couponType MUST be a uint8 integer.





 samsay:

As for the couponRate, the standard specifies that it MUST be a uint256.


This is no specification at all. If the meaning of the value is not specified, it cannot be interpreted. It is not helpful that they are always a uint256 or a uint8 if they cannot be reliably interpreted. It might as well not be part of your specification since it doesn’t specify anything.

Author: samsay
Date: 2024-07-18T21:36:31.367Z

Are you trying to say that it is not helpful that the balanceOf method of ERC-20 standard which is defined to be a uint256 always returns a uint256 ?
The standard does specify that couponRate returns the bond interest rate, the same way the ERC-20 standard specifies that balanceOf returns the account balance of an account.
Please, read each method documentation for the meaning of the value that is returned. The screenshot bellow shows the documentation for the couponRate, as you can see, the standard does specify that couponRate returns the bond interest rate.
image1856×266 34.8 KB

Author: wjmelements
Date: 2024-07-19T18:47:21.644Z

samsay:

Are you trying to say that it is not helpful that the balanceOf method of ERC-20 standard which is defined to be a uint256 always returns a uint256 ?


No



 samsay:

The standard does specify that couponRate returns the bond interest rate, the same way the ERC-20 standard specifies that balanceOf returns the account balance of an account.


The meaning of account balance in erc20 is defined. It corresponds to the parameter of transfer. The meaning of bond interest rate is not. If it returns 1000, what does that mean? It might mean 10%. It might not. There’s also no defined way to obtain that interest. Therefore it’s not useful information.



 samsay:

he screenshot bellow shows the documentation


Do you think I didn’t read your unstandard before the first time I complained about it? Are you going to understand any of my criticisms, or was it sufficient for you to know they were of the string type?

Author: wjmelements
Date: 2024-07-20T23:39:07.627Z

I already demonstrated to you that I know the meaning of basis points. However your standard does not mandate basis points; they are merely a suggestion. Do you not see that as a problem? Or do you not understand rfc 2119? Are you even an engineer?
Your unstandard leaves nothing defined, yet tries to do too much, and therefore cannot be useful to anyone. One cannot build anything on top of it because anything implementing it can behave arbitrarily. There’s no defined way to collect a coupon. There’s no defined meaning of couponType so you can’t detect zero-coupon bonds even if they return 0. Nothing means anything.

Author: samsay
Date: 2024-07-21T00:08:15.247Z

wjmelements:

Do you think I didn’t read your unstandard before the first time I complained about it? Are you going to understand any of my criticisms, or was it sufficient for you to know they were of the string type?


No, I am really sorry, that wasn’t and isn’t my thinking.

Author: samsay
Date: 2024-07-21T00:34:22.738Z

Have you been paid to say what you wrote ? It seems so.
So please, if you think this standard is useless, then go find another one. There are several standards that can be used for bonds, 6123 for example. What you said is your interpretation and only yours, not for projects that are currently implementing this standard.
Are you even an engineer ?
If YOU were, then you could realize that your question on a way to collect coupon is a nonsense, ERC-7092 is a standard that represents bonds as a token that can be transferred from one account to another. Any token is nothing but a balance that can be transferred. Additional information and methods can be added on top of a token, such as coupon payment on a bond. Those methods have nothing to do with the token, but are added on top on the token for a defined action.
ERC-20 doesn’t implement the mint and burn functions,  but any project dealing with ERC-20 implements these functions because tokens need to be minted, and sometimes burned.
So your understanding of what should a standard be and which functions should it define seems questionable.
Collecting coupons could be added on top of the standard, but isn’t surely needed for the token definition.

Author: wjmelements
Date: 2024-07-21T01:02:13.141Z

samsay:

Have you been paid to say what you wrote ? It seems so.


I’m the CTO of a US BD. So instead of a shill, consider me a dissatisfied customer. I was disappointed by your standard. I believe I have finally conveyed my objections in a way you can understand. Our key disagreement is on the purpose and importance of standardization.

Author: samsay
Date: 2024-07-21T01:49:54.934Z

wjmelements:

I’m the CTO of a US BD. So instead of a shill, consider me a dissatisfied customer. I was disappointed by your standard. I believe I have finally conveyed my objections in a way you can understand. Our key disagreement is on the purpose and importance of standardization.


I’m the CTO of a US BD: Frankly, who cares!
consider me a dissatisfied customer:   Nonsense! you cannot be a customer since the standard is open source, I am selling nothing through the published standard. If you were trying to implement it and felt unsatisfied, try another one please.

Author: samsay
Date: 2024-07-21T14:24:38.014Z

wjmelements:

My complaint is that these aren’t standardized. Even the meaning of couponType isn’t specified. Every bond can define their own different way to collect the coupon payments, and can invent their own couponType. How chaotic!


Bellow is the screenshot of ERC-137 for Ethereum Domain Name Services (ENS), It is said that Labels domains may be of any length, but it is RECOMMENDED that labels be restricted to no more than 64 characters each.
Does that prevent projects to implement ENS ? Would you have the courage to say here that the Ethereum Name Services (ERC-137) is not an Ethereum standard ?
Read ERC standards and you will find several of them with the same kind of RECOMMENDATION.
So read first (do research), understand the subject, then ask questions. Only after you’ve done all that that you should complain
image2136×1362 381 KB