sounds interesting.
Why that’s not been proposed as an EIP (on Ethereum) ?
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:
1 Like
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 ?
1 Like
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!)
1 Like
- There doesn’t appear to be a standard way to pay or collect the coupon.
- Many of the
viewmethods can behave arbitrarily (for examplecouponRateandcouponType), with specifications beingRECOMMENDED.
1 Like
Why including cross-chain transfer capabilities into the specification? It looks overbloated to me.
2 Likes
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.
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.
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!
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.
Yes
exactly. And all of its meanings are merely suggestions.
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.
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
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.
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.
No
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.
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?
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.
No, I am really sorry, that wasn’t and isn’t my thinking.
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.
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.