On the EIP, the description of Burn seems not to be correct
burn(address from, uint256 classId, uint256 nonceId, uint256 amount) allows the transfer of any number of bond types from an address to another.
The “_amount” is the list of amount of the bond, that will be transferred from "_from"address to “_to” address.
There is no _to address in the definition
thanks
indeed the motivation of this standard is to compose an structure that can be referred to issue , redeem bonds at same time without referring to any offchain / onchain smart contract protocols
thanks for finding the mistake in the description , indeed we dont need the “_to” address as in the implementation users have to reduce the amount of the bonds from the class structure . similar to the ERC20 where the _to is address(0). we will rectify the omission .
Could you be more price on how you are going to issue bonds through this EIP ? I know that bonds are financial instruments usually issued by corporations and government to borrow money, therefore it is more likely that the decentralized bonds you are proposing from this EIP will even face regulation from institutions or just be unauthorized in some countries.
One more question about class and nonce, in traditional bond systems there are no such parameters as characteristics of bonds, what is the advantage of introducing those news bond characteristics ?
In the EIP it says that AMM is gas efficient, what makes it gas efficient? Is it just the structure or there is something more to it for gas savings?
What is the difference between your standard and EIP 1450 which is stagnant now.
?
Link for reference: EIP-1450: ERC-1450 A compatible security token for issuing and trading SEC-compliant securities
Hello guys,
Is this standard Fungible or not Fungible? The text doesn’t explicitly define it.
Thank you
Thanks for question .
Regarding issuance of the bonds , it depends on the :
then we will need to understand the different counterparts in the process of issuing the bonds . for our reference implementation we considered the following (which are explained in our whitepaper for v1 implementation here) :
Banks : these are the orchestrator for issuance and redemption of bonds after maturity(and only this entity has the right to issue compliant bonds ).
Automated Pair Maker (APM) : this is the analogy of AMM but being single consolidated pools , where unlike the AMM , the bonds can be issued for single or multiple underlying collaterals
Secondary market maker(auction marketplace): to provide possiblity for P2P transfer and bidding of bonds .
Regarding the question of compliance :
Indeed our standard provides the minimal interface for encoding the information needed for compliance across different institutions . but we need to insure that the issuer entity (either the Bank contract as explained above or any external entity ) needs to encode the necessary information and corresponding metadata in the bond data structure , so that the destination marketplace (like the secondary market / APM or other offchain entity for certification / price oracles etc) can decode and validate the information .
if you want an reference of the ease of our standard in handling this issue , checkout one of the latest issuance of bonds by an major french bank using modified version of ERC20 standard here , we see that the bonds issued only defines the corresponding supply , standard and maturity date . thus it lacks the other parameters required to check the overall supply , redemption conditions and to be sold on the secondary exchange , we will be needing the parent contract to fetch the details .
so in traditional bonds systems , we indeed have the notion of bonds and class . for example , the class information defines tghe category of the bond (name , category (based on redemption time , zero coupon , fixed rate and floating rate etc))and the nonce corresponds to the current state of the bonds (active , redeemed supply , interest rate , redemption time etc).
The advantage of using our implementation of bond structure is its unifies the different categories of bonds , their issuance from the single contract type .
thanks for the question ,
So if i understand correctly , you posed question from the rationate “AMM optimization” .
indeed ERC3475 allows to simplify the management of Liquidity Pool management as each bonds store the state of bond supply and type , thus there is no need to issuance of seperate contracts everytime an new LP pair is added into the pool , along with beenfits of consolidated liquidity (thus avoiding common attack vectors like Impermanent Loss etc). in our reference implementation (explained in whitepaper , which we call as APM (Automated Pair Maker))
but along with that i wanted to also clarify that this standard is agnostic to the underlying liquidity maangement , and you can indeed have integration across different liquidity providers (Both APM or the traditional AMM)
Thanks for the question ,
So indeed as explained before : our standard is agnostic to the issuance of various types of bonds and the entities handling the operations of the bonds (via the approvals ) , whereas seeing the standard ERC1450 seems that its hardcoded and modified version of ERC20 which is specific to standard compliance , along with the issue that we highted that it will be needing seperate onchain contracts / offchain information in order to check for redemption and transfer .
Thanks for Q,
Its Non fungible in the sense that both the metadata , ownership and other details can be upgraded based on the different operations in the lifecycle , something that is an necessary process in the bonds lifecycle (from issuance to the redemption of the bonds ).
Can we add memo like field for transfers? For example in Steller/Ripple, using Memo, exchange can track deposit to same address via different memo numbers. Can it be implemented here as well?
This is awesome. I think this EIP will be the first to bring bonds to Blockchain through a dedicated standard. I had seen previous standards to bring Stocks and other similar instruments to the blockchain but none for bonds. Arguably, bonds can be complex and a dedicated standard would be really great to have.
Indeed , so if you read the standard section NonceInfos
NonceInfos
nonceInfos(uint256 classId, uint256 nonceId)allows anyone to read the information of a bond class’ nonce.The
"class"is the class nonce of bond, the first bond class created will be 0, and so on.The
"nonce"is the nonce of the bond. This param is for distinctions of the issuing conditions of the bond.
if you consider the Nonce to be transaction between counterparties of an particular type , then the NonceInformation can be define as the reference information about the nature of transaction (as defined by the memos) , beyond that also as classInfos are also defined , this is more helpful for transactions between the two different entities from different jurisdictions to get more information about the class of the transaction between the two different types of bond exchanges .
Hi dear developers,
I noticed that in the EIP, we have nonceInfos() to get a list of the value from the keys(classID, nonceID). But what will happen if we want to store in the same time an address, an integer and str. How the smart contract can interpreter this, and how the front end can translate those value for the users. Do we have a key dictionary. It’s this a part of EIP? I think we will need more detailed documents on the structure of the metadata.
so the nonceInfo there can be indeed arbitrary array consisting of different types of address (and indeed our KPI ).
But what will happen if we want to store in the same time an address, an integer and str.
Yes you can indeed store that in an array given that you provide the sequential metadata corresponding to each of the inputs so that the counterperties and their corresponding frontend logic can decode / encode the information (its defined by nonceInfoDescription)
How the smart contract can interpreter this, and how the front end can translate those value for the users. Do we have a key dictionary. It’s this a part of EIP?
yes you can do that by setting the nonceInfoDescription(uint256 nonceInfo) external view returns (string[] memory nonceInfoDescription)
PS: currently the nature of the nonceInfoDescription is defined as the string (rather than an array of strings) , so we will have to incorporate this correction now .
I think we will need more detailed documents on the structure of the metadata.
correct indeed , so we will create an PR with the changes
but if you could also explain some example of the metadata information needed to parse the store issuance and redemption information , feel free to discuss .
Got it, looking forward to read the documents and to see how far this EIP can go.
What is an example of the metadata you would need for a bond issued from an AMM as an LP token?
Also, I think you may have left something out here, under Metadata Information:
“Info describing the information about the nature of classes , this includes the nonceInfoDescription , details concerning the…”
Thank you for bringing this EIP in my notice. Being in the Banking space and also a blockchain enthusiast, I cleary see the need for this standard. Few years ago, my bank did a small experiment for bonds transfer using ERC 20 but again it did not get traction. I think that, with this standard and being able to support multiple metadata, the transition of bonds as instrument to DeFi can be surely accelerated. I am sharing the link of my bank’s smart contract for bond transfer. Indeed it was an interesting experiment
https://etherscan.io/address/0x4914f3a6b16c3e43aec333950193e345cf167554
So for an AMM , the metadata can be represented in the JSON format as follows for an single bond , not here values corresponding of the issuance , redemption conditions of the bonds on the given AMM pais :
[
{
"key": “ClassId”,
"type": “uint”,
"value": ["1"]
},
{
"key": “NonceId”,
"type": “uint”,
"value": ["0", "1", "2"],
},
{ "key":"values" ,
"type":"string[]",
"value": []
}
,
{
"key": “NonceInfodescription”,
"type": “string[]”,
"value": ["amount", "maturityTime", "APY"]
},
{
"key":"NonceValues" ,
"type":"string[]",
"value": ["1000", "6months","5%"]
},
{ "key":"symbol",
"type":"string",
"value": ["testToken-UNI-LP"]
},
{
"key": “issuer_address”,
"type": “address”,
"value":["0xBankAddress"]
},
{
"key": “class_type”,
"type": “str[]”,
"value": ["fixedRate", "floatingRate", "type-AAA"]
},
{
"key": “LP Address”,
"type": “address”,
"value":["0xe34139463bA50bD61336E0c446Bd8C0867c6fE65"]
},
]
this is not an exhaustive description of all the details needed for defining such bond , but has the necessary details that can be needed for bonds functionality , but overall the structure remains the same JSON serialisable format for the frontend .
so i am not able to find this sentence in the current version of the EIP , could you refer the link of the specific document that will be great .