set EIP-5252 into review (ethereum#6673)

* Update eip-5252.md * Update eip-5252.md * Update eip-5252.md * Update eip-5252.md * Update eip-5252.md * Update eip-5252.md * Update eip-5252.md * Update eip-5252.md * Update eip-5252.md
orochi-network · Mar 13, 2023 · d1efc94 · d1efc94
1 parent eed8c6d
commit d1efc94
Showing 1 changed file with 60 additions and 44 deletions.
diff --git a/EIPS/eip-5252.md b/EIPS/eip-5252.md
@@ -1,7 +1,7 @@
 ---
 eip: 5252
 title: Account-bound Finance
-description: An EIP-5114 extension that aids in preventing arbitrary loss of funds
+description: An ERC-5114 extension that aids in preventing arbitrary loss of funds
 author: Hyungsuk Kang (@hskang9), Viktor Pernjek (@smuxx)
 discussions-to: https://ethereum-magicians.org/t/pr-5252-discussion-account-bound-finance/10027
 status: Draft
@@ -12,9 +12,10 @@ requires: 20, 721, 1155, 5114
 ---
 
 ## Abstract
-This EIP proposes a form of smart contract design pattern and a new type of account abstraction on how one's finance should be managed, ensuring transparency of managing investments and protection with self-sovereignty even from its financial operators. This EIP enables greater self-sovereignty of one's assets using a personal finance contract for each individual. The seperation between an investor's funds and the operation fee is clearly specified in the personal smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.	
 
-This EIP extends [EIP-5114](./eip-5114.md) to further enable transferring fund to other accounts for mobility between managing multiple wallets.
+This EIP proposes a form of smart contract design pattern and a new type of account abstraction on how one's finance should be managed, ensuring transparency of managing investments and protection with self-sovereignty even from its financial operators. This EIP enables greater self-sovereignty of one's assets using a personal finance contract for each individual. The seperation between an investor's funds and the operation fee is clearly specified in the personal smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.
+
+This EIP extends [ERC-5114](./eip-5114.md) to further enable transferring fund to other accounts for mobility between managing multiple wallets.
 
 ## Motivation
 
@@ -24,11 +25,12 @@ Smart contracts are best implemented as a promise between two parties written in
 
 The pattern with personal finance contract also offers more transparency than storing mixed fund financial data in the operating team's contract. With a personal finance contract, an account's activity is easier to track than one global smart contract's activity. The pattern introduces a Non-Fungiible Account-Bound Token (ABT) to store credentials from the personal finance contract.
 
-#### Offchain-identity vs Soul-bound token on credentials 
+### Offchain-identity vs Soul-bound token on credentials
 
 This EIP provides a better alternative to off-chain identity solutions which take over the whole system because their backends eventually rely on the trust of the operator, not cryptographic proof (e.g. Proof-of-work, Proof-of-stake, etc). Off-chain identity as credentials are in direct opposition to the whole premise of crypto. Soulbound tokens are a better, verifiable credential, and data stored off-chain is only to store token metadata.
 
 ## Specification
+
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
 The specification consists of two patterns for **Interaction** and **Governance**.
@@ -40,6 +42,7 @@ The specification consists of two patterns for **Interaction** and **Governance*
 The interaction pattern consists of 4 components for interaction; manager, factory, finance, account-bound token, and extension.
 
 Interaction contract pattern is defined with these contracts:
+
 - A soul-bound or account bound token contract to give access to interact with a financial contract with credentials
 - A manager contract that interacts first contact with an investor
 - A factory contract that creates a financial contract for each user
@@ -48,83 +51,90 @@ Interaction contract pattern is defined with these contracts:
 #### Requirements
 
 A soul-bound or account bound token contract is defined with these properties:
-1. It SHALL be non-fungible and MUST satisfy [EIP-721](./eip-721.md).
+
+1. It SHALL be non-fungible and MUST satisfy [ERC-721](./eip-721.md).
 2. Credentials SHOULD be represented with its metadata with `tokenURI()` function.
-3. It MUST only reference factory to verify its minting. 
+3. It MUST only reference factory to verify its minting.
 4. If it is transferrable, it is account-bound. If not, it is soul-bound.
 
 A manager contract is defined with these properties:
+
 1. It MUST be the only kind of contract which calls factory to create.
 2. It SHOULD store all related configurations for financial parameters.
 
 A factory contract is defined with these properties:
+
 1. It SHALL clone the finance contract with uniform implementation.
 2. It MUST be the only contract that can mint account-bound token.
 3. It MUST keep an recent id of account bound token.
 
 A finance contract is defined with these properties:
+
 1. A finance contract MUST only be initialized once from factory contract in constructor.
 2. Funds in the contract SHALL NOT be transferred to other contracts nor accounts unless sender who owns soul-bound or account bound token signs to do so.
 3. Every state-changing function of the smart contract MUST only accept sender who owns soul-bound or account bound-token except global function(e.g. liquidation).
-4. Global function SHOULD be commented as `/* global */` to clarify the function is can be accessed with anyone.  
-4. Each finance contract SHOULD be able to represent transaction that has happened only with those who had account-bound token. 
-5. If soul-bound token is used for access, the finance contract MUST be able to represent transaction that has happened only between whom had the private key and the finance contract.
+4. Global function SHOULD be commented as `/* global */` to clarify the function is can be accessed with anyone.
+5. Each finance contract SHOULD be able to represent transaction that has happened only with those who had account-bound token.
+6. If soul-bound token is used for access, the finance contract MUST be able to represent transaction that has happened only between whom had the private key and the finance contract.
 
 #### Contracts
 
-<figure>
-<img src="../assets/eip-5252/media/media.svg" alt="Diagram" style="width:100%">
-<figcaption align = "center"><b>Fig 1 - Contract Diagram of EIP-5252</b></figcaption>
-</figure>
+![Diagram](../assets/eip-5252/media/media.svg)
 
+::: {.center}
+Contract Diagram of [ERC-5252](eip-5252.md)
+:::
 
 **`Manager`**: **`Manager`** contract acts as an entry point to interact with the investor. The contract also stores parameters for **`Finance`** contract.
 
 **`Factory`**: **`Factory`** contract manages contract bytecode to create for managing investor's fund and clones **`Finance`** contract on **`Manager`** contract's approval. It also mints account-bound tokens to interact with the `Finance` contract.
 
-**`Finance`**: **`Finance`** contract specifies all rules on managing an investor's fund. The contract is only accessible with an account that has an Account-bound token. When an investor deposits a fund to **`Manager`** contract, the contract sends the fund to **`Finance`** contract account after separating fees for operation. 
+**`Finance`**: **`Finance`** contract specifies all rules on managing an investor's fund. The contract is only accessible with an account that has an Account-bound token. When an investor deposits a fund to **`Manager`** contract, the contract sends the fund to **`Finance`** contract account after separating fees for operation.
 
-**`Account-bound token`**: **`Account-bound token`** contract in this EIP can bring the **`Finance`** contract's data and add metadata. For example, if there is a money market lending 
+**`Account-bound token`**: **`Account-bound token`** contract in this EIP can bring the **`Finance`** contract's data and add metadata. For example, if there is a money market lending
 **`Finance`** contract, its **`Account-bound token`** can show how much balance is in agreement using SVG.
 
 **`Extension`**: **`Extension`** contract is another contract that can utilize locked funds in **`Finance`** contract. The contract can access with **`Finance`** contract on operator's approval managed in **`Manager`** contract. Example use case of `Extension` can be a membership.
 
-**`Metadata`**: **`Metadata`** contract is the contract where it stores metadata related to account credentials. Credential related data are stored with specific key. Images are usually displayed as SVG, but offchain image is possible. 
+**`Metadata`**: **`Metadata`** contract is the contract where it stores metadata related to account credentials. Credential related data are stored with specific key. Images are usually displayed as SVG, but offchain image is possible.
 
 ---
 
 ### Governance
 
-The governance pattern consists of 2 components; influencer and governor. 
+The governance pattern consists of 2 components; influencer and governor.
 
 #### Interfaces
 
 #### Requirements
 
 An influencer contract is defined with these properties:
+
 1. The contract SHALL manage multiplier for votes.
 2. The contract SHALL set a decimal to calculated normalized scores.
 3. The contract SHALL set a function where governance can decide factor parameters.
 
 A governor contract is defined with these properties:
+
 1. The contract MUST satisfy Governor contract from OpenZeppelin.
 2. The contract SHALL refer influencer contract for multiplier
-3. The contract MUST limit transfer of account bound token once claimed for double vote prevention. 
+3. The contract MUST limit transfer of account bound token once claimed for double vote prevention.
 
 #### From Token Governance To Contribution Based Governance
 
-|               | Token Governance                 | Credential-based Governance                      |
-|---------------|----------------------------------|--------------------------------------------------|
-| Enforcement   | More tokens, more power          | More contribution, More power                    |
-| Incentives    | More tokens, more incentives     | More contribution, more incentives           |
-| Penalty       | No penalty                       | Loss of power                  |
-| Assignment | One who holds the token | One who has the most influence |
+|             | Token Governance             | Credential-based Governance        |
+| ----------- | ---------------------------- | ---------------------------------- |
+| Enforcement | More tokens, more power      | More contribution, More power      |
+| Incentives  | More tokens, more incentives | More contribution, more incentives |
+| Penalty     | No penalty                   | Loss of power                      |
+| Assignment  | One who holds the token      | One who has the most influence     |
 
-<figcaption align = "center"><b>Token Governance vs Credential Based Governance</b></figcaption>
+::: {.center}
+Token Governance vs Credential Based Governance
+:::
 
 Token governance is not sustainable in that it gives **more** power to "those who most want to rule". Any individual who gets more than 51% of the token supply can forcefully take control.
 
-
 New governance that considers contributions to the protocol is needed because:
 
 - **Rulers can be penalized on breaking the protocol**
@@ -134,16 +144,16 @@ The power should be given to "those who are most responsible". Instead of locked
 
 #### Calculating Influence
 
-**`Influence`** is a multiplier on staked tokens that brings more voting power of a DAO to its contributors. To get **`Influence`**, a score is calculated on weighted contribution matrix. Then, the score is normalized to give a member's position in whole distribution. Finally, the multiplier is determined on the position in every community members. 
+**`Influence`** is a multiplier on staked tokens that brings more voting power of a DAO to its contributors. To get **`Influence`**, a score is calculated on weighted contribution matrix. Then, the score is normalized to give a member's position in whole distribution. Finally, the multiplier is determined on the position in every community members.
 
 #### Calculating score
 
 The weights represent relative importance on each factor. The total importance is the total sum of the factors. More factors that can be normalized at the time of submitting proposal can be added by community.
 
-|    | Description                                         |
-|----|------------------------------------------------|
-| α  | Contribution value per each **`Finance`** contract from current proposal|
-| β  | Time they maintained **`Finance`** per each contract from current timestamp of a proposal|
+|     | Description                                                                               |
+| --- | ----------------------------------------------------------------------------------------- |
+| α   | Contribution value per each **`Finance`** contract from current proposal                  |
+| β   | Time they maintained **`Finance`** per each contract from current timestamp of a proposal |
 
 ```math
 (score per each ABT) = α * (contribution value) + β * (time that abt was maintained from now)
@@ -155,7 +165,7 @@ Normalization is applied for data integrity on user's contribution in a DAO.
 Normalized score can be calculated from the state of submitting a proposal
 
 ```math
-(Normalized score per each ABT) = α * (contribution value)/(total contribution value at submitting tx) + β * (time that abt was maintained)/(time passed from genesis to proposal creation) 
+(Normalized score per each ABT) = α * (contribution value)/(total contribution value at submitting tx) + β * (time that abt was maintained)/(time passed from genesis to proposal creation)
 ```
 
 and have a value between 0 and 1 (since α + β = 1).
@@ -174,27 +184,29 @@ The equation for influence is :
 
 For example, if a user has 3 **`Account-bound tokens`** with normalized score of each 1.0, 0.5, 0.3 and the locked token is 100, and multiplier is 0.5 and base factor is 1.5. Then the total influence is
 
-```math
+````math
 0.5 * {(1.0 + 0.5 + 0.3) / 3} + 1.5 = 1.8
 
  The total voting power would be
 
 ```math
 (voting power) = 1.8 * sqrt(100)  = 18
-```
+````
 
 #### Stakers vs Enforcers
 
-|              | Stakers               | Enforcers                                                                               |
-|--------------|-----------------------|-----------------------------------------------------------------------------------------|
+|              | Stakers                           | Enforcers                                                                               |
+| ------------ | --------------------------------- | --------------------------------------------------------------------------------------- |
 | Role         | stake governance token for voting | Contributed on the system, can make proposal to change rule, more voting power like 1.5 |
-| Populations  | many                  | small                                                                                   |
-| Contribution | Less effect           | More effect                                                                             |
-| Influence       | sqrt(locked token)    | Influence * sqrt(locked token)                                                                      |
+| Populations  | many                              | small                                                                                   |
+| Contribution | Less effect                       | More effect                                                                             |
+| Influence    | sqrt(locked token)                | Influence \* sqrt(locked token)                                                         |
 
-<figcaption align = "center"><b>Fig 1 - Stakers vs Enforcers</b></figcaption>
+::: {.center}
+Stakers vs Enforcers
+:::
 
-**Stakers**:  Stakers are people who vote to enforcers' proposals and get dividend for staked tokens
+**Stakers**: Stakers are people who vote to enforcers' proposals and get dividend for staked tokens
 
 **Enforcers**: Enforcers are people who takes risk on managing protocol and contributes to the protocol by making a proposal and change to it.
 
@@ -206,13 +218,16 @@ For example, if a user has 3 **`Account-bound tokens`** with normalized score of
 
 ## Rationale
 
-#### Gas saving for end user
+### Gas saving for end user
+
 The gas cost of using multiple contracts (as opposed to a single one) actually saves gas long-run if the clone factory pattern is applied. One contract storing users' states globally means each user is actually paying for the storage cost of other users after interacting with the contract. This, for example, means that MakerDAO's contract operating cost is sometimes over 0.1 ETH, limitimg users' minimum deposit for CDP in order to save gas costs. To solve inefficient n-times charging gas cost interaction for future users, one contract per user is used.
 
 #### Separation between investor's and operation fund
+
 The separation between an investor's funds and operation fee is clearly specified in the smart contract, so investors can ensure safety from arbitrary loss of funds by the operating team's control.
 
 ## Backwards Compatibility
+
 This EIP has no known backward compatibility issues.
 
 ## Reference Implementation
@@ -223,9 +238,10 @@ This EIP has no known backward compatibility issues.
 
 - **`Factory`** contracts must ensure that each **`Finance`** contract is registered in the factory and check that **`Finance`** contracts are sending transactions related to their bounded owner.
 
-- Reentrancy attack guard should be applied or change state before delegatecall in each user function in **`Manager`** contract or **`Finance`** contract. Otherwise, **`Finance`** can be generated as double and ruin whole indices. 
+- Reentrancy attack guard should be applied or change state before delegatecall in each user function in **`Manager`** contract or **`Finance`** contract. Otherwise, **`Finance`** can be generated as double and ruin whole indices.
 
-- Once a user locks influence on a proposal's vote, an **`Account Bound Token`** cannot be transferred to another wallet. Otherwise, double influence can happen. 
+- Once a user locks influence on a proposal's vote, an **`Account Bound Token`** cannot be transferred to another wallet. Otherwise, double influence can happen.
 
 ## Copyright
+
 Copyright and related rights waived via [CC0](../LICENSE.md).