Bond Module

[robert-zaremba]

Technical discussion about Bond Module design.
#726

[robert-zaremba]

I'm reviewing the initial proto definition for bonds. It looks like a Bond here is an NFT? It will have a face value, but bonds won't be fungible nor divisible, right?
In that case I would strongly consider implementing bonds on top of Cosmos SDK NFT module.

[aaronc]

To me it actually strikes me as fungible because it seems like it can be split between different owners. @tonda100 @horavamartin can you clarify as to whether or not it is divisible?

[robert-zaremba]

This what I would think about, but the current design has a single bond (with unique ID -> #726 (comment)) with a face value.... so a followup thread / question below.

[robert-zaremba]

Bond Emission.

1. Normally, whenever bonds are emitted, there is a stock of bonds and each bond has a face value. That bonds are fungible. This design doesn't imply that - I see that emission creates a new denom with face value, but doesn't define amount of bonds (coins) to emit.
   Moreover who and how should decide about the face value currency? Is it going to be denominated in Regen?
2. Are there multiple emissions for the same Bond supported?

[yddgd]

@robert-zaremba , you are right, since it is the batch issuance, the better name would be probably MsgIssueBondBatch. @horavamartin, please update.

[yddgd]

predefined emissions: when a new emission is created, all bonds in that emissions were created and assigned to the issuer.

Yes, they might be assigned to the issuer as well, although I would prefer to be assigned directly to the owner.

at maturity the bond holder can redeem the bond for the principle + unpaid coupons. (PS: handling coupons will require a separate discussion - we need to remember if a coupon payment for a given bond was done or not).

It is not clear to me why you propose to not cease the bond at maturity? I think it should function as I wrote in the second bullet point.

In my opinion, there should not be any bondholder action required for either coupon or face value payout on coupon payout term or maturity. Thats why I would prefer daily coupon, but it seems that this option is undesirable. Hence we indeed have to keep track of the paid out coupons. What would be your suggestions to do so?

At 10. and 11., I probably not expressed that correctly. What should happen is setting the bond the status matured, but the ownership does not change, similarly to the retired ecocredit.

Bonds in given emission were fungible, however for handling coupons I designed a multi-level bond - each bond has sub denoms representing a stage with respect to coupons paid.

You probably need to take me further with the multi-level bond - is there somewhere for me to read more to understand that better?

[robert-zaremba]

Yes, they might be assigned to the issuer as well, although I would prefer to be assigned directly to the owner.

Issuer is the owner, right? And then he will sell the bonds.

[robert-zaremba]

In my opinion, there should not be any bondholder action required for either coupon or face value payout on coupon payout term or maturity. Thats why I would prefer daily coupon, but it seems that this option is undesirable. Hence we indeed have to keep track of the paid out coupons. What would be your suggestions to do so?

I would prefer to limit the "automatic actions" handled by a blockchain. Especially something that is repeated. It would require end blocker function and could be expensive if there will be many many bonds.

Instead, we should use an algorithm which will accumulate the unpaid rewards, and user will be able to redeem it. It would require break down the bond into sub-denoms, to know if the given bond received reward or not.

[robert-zaremba]

You probably need to take me further with the multi-level bond - is there somewhere for me to read more to understand that better?

The idea is that we need to distinguish bonds which received payments. So we need to break down the time into epochs according to the reward payment. For bond B, we will have B_1, B_2, .... B_n.
At epoch e2, if a user has a x bonds from epoch e1: B_e1 he can exchange it to x bonds B_e1 and x * (e2-e1) reward units.

[neuschool]

I fully agree that 'Green Bonds' are a significant driver in the adoption of web3 for the carbon vertical. I would like to suggest adding layers of MRV / remote sensing would be a big value add. Currently bonds are very un-transparent in terms of fulfilling the conditions of the bond agreement.

With web3 and remote sensing tech we can ensure that the conditions are met and in addition stream the earnings / coupons into the market on a more frequent basis creating a more consistent and predictable cash flow model. This all supports a more efficient market and de-risks the bond as the buyer gets more frequent coupon payments...