Update EIP-5528: Move to final (ethereum#5790)

* eip-5528 final

* Editor suggestions for EIP-5528

Co-authored-by: Sam Wilson <sam.wilson@mesh.xyz>

EIPS/eip-5528.md

@@ -4,8 +4,7 @@ title: Refundable Fungible Token
 description: Allows refunds for EIP-20 tokens by escrow smart contract
 author: StartfundInc (@StartfundInc)
 discussions-to: https://ethereum-magicians.org/t/eip-5528-refundable-token-standard/10494
-status: Last Call
-last-call-deadline: 2022-10-16
+status: Review
 type: Standards Track
 category: ERC
 created: 2022-08-16
@@ -14,40 +13,41 @@ requires: 20
 
 ## Abstract
 
-This standard is an extension of [EIP-20](./eip-20.md). This specification provides a type of escrow service in the blockchain ecosystem, which includes the following capabilities.
+This standard is an extension of [EIP-20](./eip-20.md). This specification defines a type of escrow service with the following flow:
 
 - The seller issues tokens.
-- The seller creates an escrow smart contract with detailed escrow information. The information could include seller token contract address, buyer token contract address,  lock period, exchange rate, the maximum number of buyers, minimum balance of buyers, additional escrow success conditions, etc.
-- The seller funds seller tokens to the escrow contract.
-- Buyers fund buyer tokens which are pre-defined in the escrow contract.
+- The seller creates an escrow smart contract with detailed escrow information like contract addresses, lock period, exchange rate, additional escrow success conditions, etc.
+- The seller funds seller tokens to the *Escrow Contract*.
+- Buyers fund buyer tokens which are pre-defined in the *Escrow Contract*.
 - When the escrow status meets success, the seller can withdraw buyer tokens, and buyers can withdraw seller tokens based on exchange rates.
 - Buyers can withdraw (or refund) their funded token if the escrow process is failed or is in the middle of the escrow process.
 
 ## Motivation
 
-Due to the nature of cryptocurrencies that guarantee anonymity, there is no way to get it back to the cryptocurrency that has already been paid.
+Because of the pseudonymous nature of cryptocurrencies, there is no automatic recourse to recover funds that have already been paid.
 
-To solve this problem, the Escrow service exists in the real world. However, it is challenging to implement an escrow service coordinated by a third-party arbitrator in a decentralized cryptocurrency ecosystem. To solve this, a smart contract was designed that acts as an escrow and devised a function where each token is sent back to the original wallet if the escrow is not completed.
-
-Escrow smart contract service should support refund EIP-20 tokens in the middle of the escrow process or when the operation fails.
+In traditional finance, trusted escrow services solve this problem. In the world of decentralized cryptocurrency, however, it is possible to implement an escrow service without a third-party arbitrator. This standard defines an interface for smart contracts to act as an escrow service with a function where tokens are sent back to the original wallet if the escrow is not completed.
 
 ## Specification
 
 There are two types of contract for the escrow process:
 
-- `Payable Contract`: The sellers and buyers use this token to fund the `Escrow Contract`.
-- `Escrow Contract`: Defines the escrow policies and holds `Payable Contract`'s token for a certain period.
+- *Payable Contract*: The sellers and buyers use this token to fund the *Escrow Contract*.
+- *Escrow Contract*: Defines the escrow policies and holds *Payable Contract*'s token for a certain period.
 
 This standard proposes interfaces on top of the [EIP-20](./eip-20.md) standard.
 
 ### Methods
 
 #### constructor
 
-The `Escrow Contract` may define the following policies:
+The *Escrow Contract* MUST define the following policies:
+
+- Seller token contract address
+- Buyer token contract address
+
+The *Escrow Contract* MAY define the following policies:
 
-- MUST include seller token contract address
-- MUST include buyer token contract address
 - Escrow period
 - Maximum (or minimum) number of investors
 - Maximum (or minimum) number of tokens to fund
@@ -58,17 +58,17 @@ The `Escrow Contract` may define the following policies:
 
 Funds `_value` amount of tokens to address `_to`.
 
-In the case of `Escrow Contract`:
+In the case of *Escrow Contract*:
 
  - `_to` MUST be the user address.
- - `msg.sender` MUST be the payable contract address.
+ - `msg.sender` MUST be the *Payable Contract* address.
  - MUST check policy validations.
 
-In the case of `Payable Contract`:
+In the case of *Payable Contract*:
 
-  - The address `_to` MUST be the escrow contract address.
-  - MUST call EIP-20's `_transfer` likely function.
-  - Before calling `_transfer` function, MUST call the same function of the escrow contract interface. The parameter `_to` MUST be `msg.sender` to recognize the user address in the escrow contract.
+  - The address `_to` MUST be the *Escrow Contract* address.
+  - MUST call EIP-20's `transfer` function.
+  - Before calling `transfer` function, MUST call the same function of the *Escrow Contract* interface. The parameter `_to` MUST be `msg.sender` to recognize the user address in the *Escrow Contract*.
 
 ```solidity
 function escrowFund(address _to, uint256 _value) public returns (bool)
@@ -78,17 +78,17 @@ function escrowFund(address _to, uint256 _value) public returns (bool)
 
 Refunds `_value` amount of tokens from address `_from`.
 
-In the case of `Escrow Contract`:
+In the case of *Escrow Contract*:
 
  - `_from` MUST be the user address.
- - `msg.sender` MUST be the payable contract address.
+ - `msg.sender` MUST be the *Payable Contract* address.
  - MUST check policy validations.
 
-In the case of `Payable Contract`:
+In the case of *Payable Contract*:
 
-  - The address `_from` MUST be the escrow contract address.
+  - The address `_from` MUST be the *Escrow Contract* address.
   - MUST call EIP-20's `_transfer` likely function.
-  - Before calling `_transfer` function, MUST call the same function of the escrow contract interface. The parameter `_from` MUST be `msg.sender` to recognize the user address in the escrow contract.
+  - Before calling `_transfer` function, MUST call the same function of the *Escrow Contract* interface. The parameter `_from` MUST be `msg.sender` to recognize the user address in the *Escrow Contract*.
 
 ```solidity
 function escrowRefund(address _from, uint256 _value) public returns (bool)
@@ -98,11 +98,11 @@ function escrowRefund(address _from, uint256 _value) public returns (bool)
 
 Withdraws funds from the escrow account.
 
-In the case of `Escrow Contract`:
+In the case of *Escrow Contract*:
  - MUST check the escrow process is completed.
  - MUST send the remaining balance of seller and buyer tokens to `msg.sender`'s seller and buyer contract wallets.
 
-In the case of `Payable Contract`, it is optional.
+In the case of *Payable Contract*, it is optional.
 
 ```solidity
 function escrowWithdraw() public returns (bool)
@@ -131,7 +131,7 @@ The interfaces described in this EIP have been chosen to cover the refundable is
 
 The suggested 3 functions (`escrowFund`, `escrowRefund` and `escrowWithdraw`) are based on `transfer` function in EIP-20.
 
-`escrowFund` send tokens to the escrow contract. The escrow contract can hold the contract in the escrow process or reject tokens if the policy does not meet.
+`escrowFund` send tokens to the *Escrow Contract*. The *Escrow Contract* can hold the contract in the escrow process or reject tokens if the policy does not meet.
 
 `escrowRefund` can be invoked in the middle of the escrow process or when the escrow process is failed.
 
@@ -152,7 +152,7 @@ This test case demonstrates the following conditions for exchanging seller/buyer
 
 ## Security Considerations
 
-Since the escrow contract controls seller and buyer rights, flaws within the escrow contract will directly lead to unexpected behavior and potential loss of funds.
+Since the *Escrow Contract* controls seller and buyer rights, flaws within the *Escrow Contract* will directly lead to unexpected behavior and potential loss of funds.
 
 ## Copyright