EIP-3475 : Multiple Callable Bonds Standard

EIPs
,
21

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

1 Like
22

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 .

23

Thanks Mehddcrypto,

Indeed me and some of my team-mates were followup on this news since long time . the work done by SG-FORGE in creating treasury of tokens with backing of highly stable offchain real estate was an great boost for other banks considering Real World Asset (RWA) markets for the blockchain .

also i will share the details about the parameters of the deployed smart contract in the thread of discussions for makerdao MIP6 application (thanks to the post)

Our standard seems to fit the use case for issuance of such type of bonds more efficiently without relying on other contracts / offchain services , and giving full security and accessiblity (using setApproval methods ).

24 
// setApprovalFor(0x82a55a613429Aeb3D01fbE6841bE1AcA4fFD5b2B,0,true);
// means that address 0x82a55a613429Aeb3D01fbE6841bE1AcA4fFD5b2B is authorized to transfer bonds from class 0 (across all nonces).
function setApprovalFor(address _operator, bool _approved) external returns(bool approved);

Interface seems to have 2 arguments, while example usage has 3.
I guess interface should look like
function setApprovalFor(address _operator, uint256 _classId, bool _approved) external returns(bool approved);

1 Like
25 
function classMetadata(uint256 metadataId) external view returns ( Metadata memory);

Should we have an input for classId?

function nonceMetadata(uint256 classId, uint256 metadataId) external view returns ( Metadata memory);

nonceId param is missing

/**
* nonceValues
* @dev allows anyone to read the values (stored in struct Values for different class) for given bond (`nonceId`,`classId`).
* @dev the values SHOULD follow a set of structures explained in metadata along with correct mapping corresponding to the given metadata structure
* @param classId is the corresponding classId of the bond.
* @param metadataId is the index of the JSON storage for given metadata information of all values of given metadata. More is defined in metadata.md.
* @returns the Values of the class metadata. — e.g. `[string, uint, address]`.
*/
function nonceValues(uint256 classId, uint256 nonceId, uint256 metadataId) external view returns ( Values memory);

missing comment on uint256 nonceId

Also, how about event for regular approval for specific bonds?

Overall it looks like a huge interface and I don’t exactly understand what is the need of each function.
I think detailed description of a use case would help. Like what is the purpose of each function/struct and why can’t it work without it?

Storing string structs it not a cheap thing to do, for example.

26

Also, regarding Reference Implementation, your DebondERC3475 does not implement IERC3475 interface
Examples

DebondERC3475 - missing
IERC3475 - function transferAllowanceFrom(address _from, address _to, Transaction[] calldata _transaction) external

DebondERC3475 - function classMetadata() external view returns (Metadata[] memory m)
IERC3475 - function classMetadata(uint256 metadataId) external view returns ( Metadata memory)

DebondERC3475 - function nonceMetadata(uint256 classId) external view returns (Metadata[] memory m)
IERC3475 - function nonceMetadata(uint256 classId, uint256 metadataId) external view returns ( Metadata memory)

DebondERC3475 - function classValues(uint256 classId) public view override returns (uint256[] memory)
IERC3475 - function classValues(uint256 classId, uint256 metadataId) external view returns ( Values memory)

DebondERC3475 - function nonceValues(uint256 classId, uint256 nonceId) public view override returns (uint256[] memory)
IERC3475 - function nonceValues(uint256 classId, uint256 nonceId, uint256 metadataId) external view returns ( Values memory)

27

Thanks for finding the issues,

We will be changing this to the new version of the definition as the DebondERC3475 was before on the ancient version of the standard and since then interface has changed significantly.

so we will do all of the changes before the final status validation deadline so as to have finalised version fully compatible.

you can check the current version on our github repo on the latest progress here

28

all of the following functions are now updated based on the latest addition and can be verified here. this will be merged once we will also aggregate the other suggestions from the community members till the end date of the last call status being finalised.

29

Should we have an input for classId?

yes we can used classId for that in most of the cases . but in some cases (specially when the classId is maintained onchain but some metadata is maintained offchain) then its not necessary that metadata will be indexed in the same way as onchain information.

Also, how about event for regular approval for specific bonds?

that is also done in the current version by emit Transfer(msg.sender, from, to, transactions);

Overall it looks like a huge interface and I don’t exactly understand what is the need of each function.
I think detailed description of a use case would help. Like what is the purpose of each function/struct and why can’t it work without it?

well maybe if you want to get more comprehensive introduction of the standard from the basis , there has been many resources added by us:

@Vadim

reply to the question on July 27th (had to edit the answer in the previous response as my previous account is not able to log in and on this one there is the limit on replying max 3 times )

Structs naming is weird.

Nonce usually means number only used once. In your presentation on page-12 you use same nonce multiple times. That’s very confusing.

In our use case nonces is used for issuing only once for specific issuance of the bonds of the given class for the user. so even if he buys another time same class bond but with a different amount, the corresponding redemption time, interest & APY changes. but yeah that should not be the concern generally for now as there has been no collision with other terminology in the traditional finance where nonce is used, apart from the blockchain.

so in the page 12 :

image
image668×530 24.3 KB

here it’s perfectly normal to have similar nonce with different classes as they will not have collision whatsoever when doing the main operations (like issue, redeem, and others ) as they require both class and nonces as the identifier. consider as similar to the different blockchains but having similar nonces for the given block. so even if there has been a transaction or interaction between the blockchains , you need to require nonce along with the chainId of the sender and receiver chains.

Why storing these metadata onchain? It doesn’t look like it’s necessary for functional use.

well I don’t think so and our presentation indeed shows the promise of the on-chain data. this necessitates the need of being independent of other external contracts/oracles to determine the conditions for redemption, interest calculation or bonds. also, the need for Metadata is primarily for the frontend to interpret the bond details in the correct way so that for international transfers with different jurisdictions and languages will be able to encode / decode easily.

All these burned/redeemed/active supply. Are they all necessary? Can’t we just decrease totalSupply like in ERC20?

Yes indeed its necessary given that in bonds they can be invalidated but they still cant be counted as “spend” and will need to be considered for the full supply during lifetime of the bond . unlike ERC20 where the tokens can be either minted or spend . the bonds have possibilities to keep the supply separately in order to have more consistency .

It looks like you are trying to standardize some of your existing solutions…

I don’t understand clearly but if that means we are EIP3475 compatible , yes we are doing that .

Some of described functionality looks excess. It’s not about if this EIP will be finalized. It’s about if it will be used.

thanks for the critique but I don’t agree . if you see the scale of the bonds in the traditional finance and their logic , they indeed need extensive description of their metadata and corresponding values , but on the very minimalistic stage , all the interface function and structure description ideally will be absolutely required by the given bond implementation in order to pass. i will be happy to discuss further implementation based on your use case, but I will also share the reference implementation of the CAST standard soon on this page in order to present people about the challenge in implementing real life bonds.

30

Thanks for additional info
Maybe I’m just stupid or spent too little time on researching, but this looks overloaded and gas-wasteful

Structs naming is weird.

Nonce usually means number only used once. In your presentation on page 12 you use same nonce multiple times. That’s very confusing.

Why storing these metadata onchain? It doesn’t look like it’s necessary for functional use.

All these burned/redeemed/active supply. Are they all necessary? Can’t we just decrease totalSupply like in ERC20?

It looks like you are trying to standardize some of your existing solutions…

Some of described functionality looks excess. It’s not about if this EIP will be finalized. It’s about if it will be used.

That’s just my feedback. You may ignore it if you want

31

Thanks for additional info
Maybe I’m just stupid or spent too little time on researching, but this looks overloaded and gas-wasteful

Structs naming is weird.

Nonce usually means number only used once. In your presentation on page 12 you use same nonce multiple times. That’s very confusing.

We use the term nonce because the idea about this eip is to create a structure for token with abstract storage. If we give a particular name, we will limit the use case of Nonce. Nonce is only created once when write nonce metadata inside. nonce is nothing but a index represent a sub category of token. We are very happy to hear some other name suggestions.

Why storing these metadata onchain? It doesn’t look like it’s necessary for functional use.

You are using a DeFi protocol, why we write the data about date of deposit and interest rate on chain with separated varibles and functions. EIP 3475 is doing the same but with more gas efficient way. If you could provide a real use case that erc 20 token is more gas efficient, we will study that exemple. In the case of AMM lp token use case, the gas fee is tasted. So to state otherwise, please provide data.

All these burned/redeemed/active supply. Are they all necessary? Can’t we just decrease totalSupply like in ERC20?

please read an article about securities issuing to know why this is needed. If decrees on total supply, there will be collateral that we can’t identify with bond. bond data should remain the same no matter what happens.

It looks like you are trying to standardize some of your existing solutions…

we developed solutions first. if we did what you suggested, the standard dont need to be this abstract.

Some of described functionality looks excess. It’s not about if this EIP will be finalized. It’s about if it will be used.

you will see.

That’s just my feedback. You may ignore it if you want

thank-you

33

Hi,
This is Joey from Fairyproof. We are a Web3.0 security company based in Singapore.

Our technical team has analyzed EIP-3475 and noted some security considerations that we’d like to share with your team.

Here are the details: https://medium.com/@FairyproofT/security-considerations-on-implementing-eip-3475-based-tokens-bbebf4da8903

We hope you can take a look at this report and share your thoughts with us - Let me know what you think. Much appreciated! :slight_smile:

1 Like
36

Hi Joey,

Thanks for the article and feedback, some of the recommendations are indeed valid and can be additional points wrt the considerations that we have provided to the EIP doc.

i) From an implementation point of view: We would check whether the bond’s logic data is saved on-chain to ensure its data is sorted permanently on-chain.

Its indeed true, but we need to specify what you have considered by bond’s logic data as its pretty broad: According to the minimalistic implementation, we just need to define the bond financial parameters and risk parameters in the class (ROI, redemption time, rating, …) along with the parameters needed issuance of each instance by the user (time-Of-Issuance, amount,…) are only needed in order to make the token interoperable. other details (underlying collateral details) can be from other off-chain sources (IPFS , oracle).

ii) From a technical point of view: We check whether the access control to the privileged functions is safely and securely managed and maintained.

That is indeed true, so based on the entity that will be issuing bonds (which is defined as bank in the specification) needs to have roles defined so that only they can execute the issue() function after it receives the underlying collateral as a debt instrument.

iii) From a tokenomics point of view: We would check whether the bond issuer has sufficient assets to ensure the application is financially secure.

Here I will disagree, there will be some category of bonds (called floating bonds as explained by the debond protocol for their v1 implementation here can not be having a fixed redemption date, and hence the bondholders will have to check the market liquidity in real-time in order to redeem, but at the same time they will be offered higher APY ).

i do agree that for fixed rate bondholders we will need to have sufficient liquidity, but we will be ensuring this by incentivizing the users to buy the floating rate bonds, and then using the collateral received from them to redeem the fixed rate holders in priority. so by default bond issuer might not have sufficient assets for the given type of class, but for sure it will need to consider sufficient reserves in order to avoid the black swan event.

thanks again for the feedback and article.

happy to get in touch with the team.

37

Hello guys! You can help me with this sequence of questions that I think makes sense not only to answer my questions, but I believe it can help the community to use this protocol to apply real-world functionality!
Without further ado, let’s go to the example:

Assuming that all (Meta)Data) used in this example follows regulatory standards here on
Brazil!
These are.
www.anbima-com-br

These, but not only, are the government entities that regulate the capital markets here in Brazil!
According to anbima files, to create an investment fund you need 3 minimum characteristics.

The Fund. (CNPJ + Various Registration Data)
The Portfolio. (CNPJ + Various Registration Data)
The asset. (CNPJ + ISIN + Various Registration Data)

Each of these entities here in Brazil are considered commercial entities, that is, each of them must have a CPF and an individual to be able to open a commercial entity!
Equivalent identification number BR/USA / Individual Entity (PF) (F)
In Brazil Individual Taxpayer Registration (CPF) Numerical sequence - 804.214.624-85 / In the USA it is Social Security Number(SSN) 565-82-00741

With a valid CPF it is possible according to Brazilian law to open a CNPJ commercial entity

Identification number equivalent to / BR/USA Commercial Entity (CNPJ) NATIONAL REGISTRY OF LEGAL PEOPLE (PJ) (J)

In Brazil CNPJ Numerical sequence - 85.36.671/0001-83 / In the USA it is Employer Identification

Contains all the data to legally create an investment fund.
With the following features.
1 investment fund
With 1 wallet,
With 3 assets,
being;
2 physical assets:
2 commercial buildings for rent for offices.

I chose to use a HYBRID income model for the investor who buys the shares of the fund.
It works like this;
12 Months from the date of signing the contract - For example from the date of the question 09/20/2022 to 09/20/2023
The investor receives 2 types of fixed income, which can be calculated based on the index (CDI)
generally used for the calculation of fixed income investment products in brazil.

Post fixed income that is variable and the IPCA index is generally used to calculate this variable income rate.
Forgot to mention that! In this case! would probably use oracles to fetch this ofchain data… right?!

This product usually has an expiration date (Maturity) of 12 months.
By bringing such an asset to the blockchain, for example, it is possible to make the investor withdraw his investment whenever he wants. With blockchain the investor can obtain other forms of profit etc…

The data below is fictitious! However, the fields are those required by regulatory bodies.
and business etc.
I also believe that using “real” data and a real world business model helps us when coding a real product.

My question is, could you use the Metadata below and create a complete example?? Where and how would each of this information go?

I ask this question because I’m interested in using the protocol in real products, but of course before testing etc…!
But for that I need examples as close to reality as possible and in this case I live in the Brazilian market!
And of course, if that answer requires a higher level of work, I’m willing to hire your consulting service to help me create a product that could be marketed in the real world. But that it had the characteristics that I describe in this post.
I am aware that the blockchain and its features can lower the total cost of an operation like this that involves CPF and CNPJ / Legal entities.
The beautiful world is where we could use both: blockchain+structured data from regulators etc…!
Because the institutional investor, with a lot of $$$ will definitely opt for a system that uses blockchain but that essentially has solid regulatory foundations in the way it handles data and its financial operations!
I’m willing to help with whatever it takes to see this protocol evolve!
Thank you and congratulations to everyone involved in this Wonderful IEP/ERC! It even seems to open up new horizons for financial services.

Below is the example data.

image
image1047×734 98.6 KB

https://abre.ai/exceldataAttached is the complete spreadsheet:
Trad-PTBRtoING-Layout Fundo - Carteiras Ativos GMAA - Google Sheets

Investment Fund Information (HEADER)
Heahder
Field Date
ISIN code BRGMDBLHNPN0
Fund’s CNPJ 8536671000183
Fund Name TECHNOLOGY FUND FOR TOKENIZATION OF GOODS - REAL ESTATE AND SERVICES
Fund Type BRICK: OFFICES - APARTMENTS
Date Position 202200408
Adm. PUBLIC NFT FINANCEIRA S.A.
Adm’s CNPJ 46368572000129
Manager name MATTIELLO BANCO XPT0 DE INVESTIMENTOS S.A
Manager’s CNPJ 72261761000108
Custodian Name PUBLIC NFT BANCO DE CUSTODIA CRYPTOATIVOS S.A
Custodian’s CNPJ 46368572000129
Share Value 100
The amount 11.000.000
PL of the Fund 18000000
Asset Value 21000000
Amounts Receivable 8000000
Amounts Payable 500000
Quotas to Issue 10000000
Quotas to be Redeemed 5000000
Number of Shareholders 500
ANBID code 15658
Fund Type 196
risk level BAD
GRADES The fund has 2 CARJ buildings in Rio de Janeiro - RJ and SEDE I in Brasília - DF.
HEADQUARTERS I is partially leased to Banco do Brasil and has a contract expiring in 2025 and restated by the IGPM.
CARJ is partially leased to Banco do Brasil, has a contract expiring in 2023 and 1 Apartment in the City of Curitiba
correction by the IGPM. Vacancy(05/21) 72.2%
FEES: Administration: Maximum of 3% p.m. on revenue (minimum BRL 36,000.00 monthly adjusted by the IGPM).
CUSTODY AND CONTROLLING 0.8% p.m. on revenue deducted from the administration fee (minimum BRL 17,500.00 monthly adjusted by the IGPM).
BOOKKEEPING Monthly fixed amount of 5,000.00 plus R$ 1.15 per investor, deducted from the management fee
NUMBER OF SHAREHOLDERS 8.741
Layout for Portfolio Attribute Information ( HEADER )
Section Tag header
Field Format
CNPJ or CPF of the Holder 46812995000196
Wallet code 74133312
Date Position 20220408
Portfolio Name BEEOCEAN NFT DIGITAL REPRESENTATION
Kind of person J
Current Account Code 01232323000789032
Name of Manager/Administrator BEEOCEAN INNOVA SIMPLE
Manager’s CNPJ 46812995000196
Custodian Name GMA Digital Bonds CRYPTOATIVOS S.A
Custodian’s CNPJ 46368572000129
PL of the Portfolio 1800000000
Amount of Taxes 5000
Asset Value 1790000000
Amounts Receivable 5000000
Amounts Payable 5000000
** Layout for Stock Position Information
Section Tag actions
Field Format
Paper ISIN code BRGMDBLHNPN4
CUSIP code 513569751
Asset Code (Symbol) GMAA
Available quantity 21,000,000.00
Batch 21.000.000
Warranty / Blocked Quantity 7.000.000
Available Financial Value 12.000.000
Financial Value in Guarantee 4.000.000
Amount of Taxes 50.00
PU Position 20.00
% Credit Provision 0.00
Current Account Type 1
Operation Class V
Lease Expiration Date 2022061212
Rent Fee 3
CNPJ of the Intermediary for Rent 46812995000196
hybrid income CDI (Fixed) + IPCA (Variable)
** Layout for Real Estate Portfolio Position Information
Section Tag properties
Field Format
Property address - street AÇATURA DE CIMA - PARISH OF SÃO JOSE DOS PINHAIS
Property address - number 52
Property address - add-on XPTO - PARISH OF SÃO JOSE DOS PINHAIS
Property address - city JOSE DOS PINHAIS
Property address - state PARANA
Property address - zip code 83005010
Commercial name of the property REAL ESTATE ENTERPRISES XPTO USE
Fund participation in the property 30000000
book value 50000000
Justification for book value 0
Appraisal value 55000000
Evaluation date 20220805
Appraiser type J
CNPJ or CPF of the appraiser 34783976000108
contracted rent 450000
late rent 100000
repurchase option indicator s
Repurchase option date 20220805
Property type 4
legal questioning indicator s
Reason for legal inquiry XPTOUSOCAP
Type of Use 5
registration 559285432391986
CNPJ of the Enterprise 60974116000153
38

thanks for the interest in the standard and description of a real-world asset issuance use case.

Short answer: it’s indeed possible but we will need to discuss this separately between our team members and understand the nature of the workflow of the metadata, issuance, and redemption lifecycle. Given that this thread mostly discusses the potential use cases of the bonds along with the standards that can be implemented.

you have contacted us already in DM so we will reach out to you once we are able to functionally determine the architecture and the opportunity.

Thanks.

1 Like
39

Hi,
We are working with a Brazilian company for the bond issuing, could we arrange a call together and I will explain to you how the metadata is written on-chain and how to read it with our FE solution.
Yu