Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

changing the ERC with EIP along with their relative links #5336

Merged
merged 9 commits into from
Jul 26, 2022
Merged

changing the ERC with EIP along with their relative links #5336

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
4e7c32e
wip: minor changes about ERC -> EIP and spaces
GrandGarcon Jul 24, 2022
f27d6f4
EIP-N linking error validation rule patch
GrandGarcon Jul 25, 2022
b00e7a4
minor fixes
dr-chain Jul 25, 2022
24aba9c
Apply suggestions from code review
dr-chain Jul 25, 2022
14df9f6
Merge branch 'master' into dhruvMalik007-patch-1
dr-chain Jul 25, 2022
e8be585
minor fixes
dr-chain Jul 25, 2022
d954bed
minor fix
dr-chain Jul 25, 2022
28f69fe
check of this EIP rule (EIP-1)
GrandGarcon Jul 26, 2022
b27fe95
minor refactor
GrandGarcon Jul 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 25 additions & 22 deletions EIPS/eip-3475.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
eip: 3475
title: Abstract Storage Bonds
description: Interface for creating tokenized obligations with abstract on-chain metadata storage
author: Yu LIU (@yuliu-debond), Waroon D. (@dr-chain), Cedric Ngakam (@drikssy), Dhruv Malik (@GrandGarcon), Samuel Gwlanold (@Edoumou), Toufic Batrice (@toufic0710)
author: Yu Liu (@yuliu-debond), Varun Deshpande (@dr-chain), Cedric Ngakam (@drikssy), Dhruv Malik (@GrandGarcon), Samuel Gwlanold (@Edoumou), Toufic Batrice (@toufic0710)
discussions-to: https://ethereum-magicians.org/t/eip-3475-multiple-callable-bonds-standard/8691
status: Last Call
last-call-deadline: 2022-07-30
Expand All @@ -17,20 +17,21 @@ This API standard allows the creation of tokenized obligations with abstract on-

## Motivation

Current LP tokens are simple EIP-20 tokens with no complex data structure. To allow more complex reward and redemption logic to be stored on-chain, we need a new token standard that can manage:

Current LP tokens are simple [EIP-20](./eip-20.md) tokens with no complex data structure. To allow more complex reward and redemption logic to be stored on-chain, we need a new token standard that can manage:

- Multidimensional token ID.
- Store on-chain metadata.
- Non-specified storage.
- Non-specified and flexible storage.
- Gas efficient.

This proposal allows the creation of any obligation with the same interface. It will enable any 3rd party wallet applications or exchanges to read these tokens' balance and redemption conditions. These bonds can also be batched as tradeable instruments. Those instruments can then be divided and exchanged in secondary markets.

Also, a significant reason the standard's name (abstract storage bond) is derived from the ability to store all the specifications (metadata/values and transaction as defined in the following sections) without needing external storage.
Also, the significant reason behind the standard's name (abstract storage bond) is its ability to store all the specifications (metadata/values and transaction as defined in the following sections) without needing external storage.

The functions defined in this EIP provide a gas-efficient solution for creating, trading, and burning bonds. They offer more optimisation options for existing AMM solution.

These bonds can also be batch called for issuance and, in turn, be divided and exchanged in a secondary market. The defined functions in this standard do operations on the serialized array, rather than storing them in struct mappings, giving significant benefits in storage and query gas costs.
The bonds can also be called in batch for issuance and can be divided and exchanged in a secondary market. The functions defined in this standard do operations on the serialized array, rather than storing them in struct mappings, resulting in significant savings of gas costs for storage and query.

## Specification

Expand All @@ -45,7 +46,7 @@ pragma solidity ^0.8.0;

/**
* transferFrom
* @param _from argument is the address of the bond holder whose balance about to decrease.
* @param _from argument is the address of the bond holder whose balance is about to decrease.
* @param _to argument is the address of the bond recipient whose balance is about to increase.
* @param _transaction is the `Transaction[] calldata` (of type ['classId', 'nonceId', '_amountBonds']) structure defined in the rationale.
* @dev transferFrom MUST have the `isApprovedFor(_from, _to, _transaction[i].classId)` approval to transfer `_from` address to `_to` address for given classId (for all transaction in the array structure).
Expand All @@ -70,7 +71,7 @@ function transferAllowanceFrom(address _from,address _to, Transaction[] calldata
/**
* issue
* @dev allows issuing any number of bond types to an address.
* @dev it MUST be issued by a single entity (for instance, a role-based ownable contract that has integration with the liquidity pool of the deposited collateral by _to address).
* @dev it MUST be issued by a single entity (for instance, a role-based ownable contract that has integration with the liquidity pool of the deposited collateral by `_to` address).
* @param `_to` argument is the address to which the bond will be issued.
* @param `_transaction` is the `Transaction[] calldata` (ie array of issued bond class, bond nonce and amount of bonds to be issued).
* @dev transferAllowanceFrom MUST have the `allowance(_from, msg.sender, _transactions[i].classId, _transactions[i].nonceId)`
Expand All @@ -85,7 +86,7 @@ function issue(address _to, Transaction[] calldata _transaction) external;
* @dev permits redemption of bond from an address.
* @dev the calling of this function needs to be restricted to the bond issuer contract.
* @param `_from` is the address from which the bond will be redeemed.
* @param `_transaction` is the `Transaction[] calldata` structure (ie array of tuples with the pairs of (class, nonce and amount) of the bonds that are to be redeemed). Further defined in the rationale section.
* @param `_transaction` is the `Transaction[] calldata` structure (i.e., array of tuples with the pairs of (class, nonce and amount) of the bonds that are to be redeemed). Further defined in the rationale section.
* @dev redeem function for a given class, and nonce category MUST BE done after certain conditions for maturity (can be end time, total active liquidity, etc.) are met.
* @dev furthermore, it SHOULD ONLY be called by the bank or secondary market maker contract.
*/
Expand All @@ -98,7 +99,7 @@ function redeem(address _from, Transaction[] calldata _transaction) external;
* @dev permits nullifying of the bonds (or transferring given bonds to address(0)).
* @dev burn function for given class and nonce MUST BE called by only the controller contract.
* @param _from is the address of the holder whose bonds are about to burn.
* @param `_transaction` is the `Transaction[] calldata` structure (i.e. array of tuple with the pairs of (class, nonce and amount) of the bonds that are to be burned). further defined in the rationale.
* @param `_transaction` is the `Transaction[] calldata` structure (i.e., array of tuple with the pairs of (class, nonce and amount) of the bonds that are to be burned). further defined in the rationale.
* @dev redeem function for a given class, and nonce category MUST BE done only after certain conditions for maturity (can be end time, total active liquidity, etc).
* @dev furthermore, it SHOULD ONLY be called by the bank or secondary market maker contract.
*/
Expand All @@ -110,8 +111,8 @@ function burn(address _from, Transaction[] calldata _transaction) external;
* approve
* @dev Allows `_spender` to withdraw from the msg.sender the bonds of `_amount` and type (classId and nonceId).
* @dev If this function is called again, it overwrites the current allowance with the amount.
* @dev approve should only be callable by the bank, or the owner of the account.
* @param _spender argument is the address of the user who is approved to be transferred the bonds.
* @dev `approve()` should only be callable by the bank, or the owner of the account.
* @param `_spender` argument is the address of the user who is approved to transfer the bonds.
* @param `_transaction` is the `Transaction[] calldata` structure (ie array of tuple with the pairs of (class,nonce, and amount) of the bonds that are to be approved to be spend by _spender). Further defined in the rationale section.
*/
// approve(0x82a55a613429Aeb3D01fbE6841bE1AcA4fFD5b2B,[[0,1,30000]]);
Expand All @@ -122,10 +123,10 @@ function approve(address _spender, Transaction[] calldata _transaction) external
* SetApprovalFor
* @dev enable or disable approval for a third party (“operator”) to manage all the Bonds in the given class of the caller’s bonds.
* @dev If this function is called again, it overwrites the current allowance with the amount.
* @dev approve should only be callable by the bank or the owner of the account.
* @param _operator is the address to add to the set of authorized operators.
* @param classId is the class id of the bond.
* @param _approved is true if the operator is approved (based on the conditions provided), false meaning approval revoked.
* @dev `approve()` should only be callable by the bank or the owner of the account.
* @param `_operator` is the address to add to the set of authorized operators.
* @param `classId` is the class id of the bond.
* @param `_approved` is true if the operator is approved (based on the conditions provided), false meaning approval is revoked.
* @dev contract MUST define internal function regarding the conditions for setting approval and should be callable only by bank or owner.
*/
// setApprovalFor(0x82a55a613429Aeb3D01fbE6841bE1AcA4fFD5b2B,0,true);
Expand Down Expand Up @@ -233,7 +234,7 @@ function getProgress(uint256 classId, uint256 nonceId) external view returns (ui

/**
* allowance
* @dev Authorizes to set the allowance for given `_spende` by `_owner` for all bonds identified by (classId, nonceId).
* @dev Authorizes to set the allowance for given `_spender` by `_owner` for all bonds identified by (classId, nonceId).
* @param _owner address of the owner of bond(and also msg.sender).
* @param _spender is the address authorized to spend the bonds held by _owner of info (classId, nonceId).
* @param classId is the corresponding classId of the bond.
Expand Down Expand Up @@ -313,7 +314,7 @@ This defines the additional information about the nature of data being stored in

### 2. Nonce:

The key value for indexing the information is the 'class'' field. Following are the rules:
The key value for indexing the information is the 'class' field. Following are the rules:

- The title can be any alpha numeric type that is differentiated by the description of metadata (although it can be dependent on certain jurisdictions).
- The title SHOULD not be EMPTY.
Expand Down Expand Up @@ -382,13 +383,14 @@ The `nonceId` is the nonce id of the given bond class. This param is for distinc

The `_amount` is the amount of the bond for which the spender is approved.

**AMM optimization**: One of the most obvious use cases of this EIP is the multilayered pool. The early version of AMM uses a separate smart contract and an EIP 20 LP token to manage a pair. By doing so, the overall liquidity inside of one pool is significantly reduced and thus generates unnecessary gas spent and slippage. Using this EIP standard, one can build a big liquidity pool with all the pairs inside (thanks to the presence of the data structures consisting of the liquidity corresponding to the given class and nonce of bonds). Thus by knowing the class and nonce of the bonds, the liquidity can be represented as the percentage of a given token pair for the owner of the bond in the given pool. Effectively, the EIP 20 LP token (defined by a unique smart contract in the pool factory contract) is aggregated into a single bond and consolidated into a single pool.

**AMM optimization**: One of the most obvious use cases of this EIP is the multilayered pool. The early version of AMM uses a separate smart contract and an [EIP-20](./eip-20.md) LP token to manage a pair. By doing so, the overall liquidity inside of one pool is significantly reduced and thus generates unnecessary gas spent and slippage. Using this EIP standard, one can build a big liquidity pool with all the pairs inside (thanks to the presence of the data structures consisting of the liquidity corresponding to the given class and nonce of bonds). Thus by knowing the class and nonce of the bonds, the liquidity can be represented as the percentage of a given token pair for the owner of the bond in the given pool. Effectively, the [EIP-20](./eip-20.md) LP token (defined by a unique smart contract in the pool factory contract) is aggregated into a single bond and consolidated into a single pool.

## Backwards Compatibility

Any contract that inherits the interface of this EIP is compatible. Also, it is valid for both the issuer and receiver of the bonds, and the client EOA needs this standard interface.

However, any existing EIP-20 token contract can issue its bonds by delegating the minting role to a bank contract with the interface of this standard built-in. Check out our reference implementation for the correct interface definition.
However, any existing [EIP-20](./eip-20.md) token contract can issue its bonds by delegating the minting role to a bank contract with the interface of this standard built-in. Check out our reference implementation for the correct interface definition.

To ensure the reading of transactions, "Issue", "Redeem", "Burn" and "Transfer", Events cited above MUST be emitted when such transaction is passed.

Expand All @@ -407,14 +409,15 @@ Testcase for the minimal reference implementation is available [here](../assets/
[Reference Interface](../assets/eip-3475/IERC3475.sol).
- This demonstration shows only minimalist implementation.

[Debond-ERC3475](../assets/eip-3475/Debond-ERC3475.sol)
[Debond-EIP-3475](../assets/eip-3475/Debond-ERC3475.sol)
- Real use case consisting of more sophisticated logic like:
- Different classes of bonds (fixed/floating rate bonds).
- Redemption conditions.

## Security Considerations
- The `function setApprovalFor()` gives the operator role in this standard. It has all the permissions to transfer, burn and redeem bonds by default.
- If the owner wants to give a one-time allocation to an address, he should call the `function approve()` giving the `Transaction[]` allocated.

- The `function setApprovalFor()` gives the operator role in this standard. It has all the permissions to transfer, burn and redeem bonds by default.
- If the owner wants to give a one-time allocation to an address, he should call the `function approve()` giving the `Transaction[]` allocated.
- The `function issue()` can only be called by the bank contract (what we call issuer in this EIP).

## Copyright
Expand Down
3 changes: 1 addition & 2 deletions assets/eip-3475/Metadata.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,7 @@
# Metadata standards


This documentation consist of various example JSON schemas (examples or standards) that can be referenced by the reader of EIP for implementing EIP-3475 bonds storage.

This documentation consist of various JSON schemas (examples or standards) that can be referenced by the reader of this EIP for implementing EIP-3475 bonds storage.

## 1. Description metadata:

Expand Down