ERC-5528 Refundable Tokens (Refundable Fungible Token)
Final · Tokens · created 2022-08-16
An extension standard that adds escrow (conditional holding of funds) to ERC-20 token trades, so that if the trade is not completed, the buyer can get the deposited tokens back to the original wallet.
Why it is needed
Cryptocurrency is a pseudonymous system where parties transact only by address, so there is no automatic way to recover funds that have already been paid. Even if tokens are sent to a seller and the trade does not proceed as promised, the buyer has no way to get the money back. In traditional finance, a trusted escrow service that holds the money until the trade is finished solves this problem. In the decentralized crypto world, a smart contract can play the same role without a third-party arbiter. This standard defines the interface of an escrow service that can return tokens to the original wallet if the escrow is not completed.
What to implement
function escrowFund(address _to, uint256 _value) public returns (bool): Deposits _value tokens into escrow to address _to. A payable contract receives the call and forwards it to the same function on the escrow contract.function escrowRefund(address _from, uint256 _value) public returns (bool): Refunds _value tokens from address _from. The buyer uses it to recover funds while the escrow is in progress or after it has failed.function escrowWithdraw() public returns (bool): Withdraws funds from the escrow account. When the escrow is complete, the seller and buyer take each other's tokens.
In depth
Two Kinds of Contracts
Two kinds of contracts take part in the escrow process of this standard. The Payable Contract is the token that the seller and buyer use when putting funds into the escrow contract, and it MUST override the EIP-20 interface. The Escrow Contract defines the escrow policy and holds the payable contract's tokens for a period of time, and it does not need to override the EIP-20 interface. In other words, the token side is the existing EIP-20 plus three functions, and the escrow side is a separate contract responsible for policy and custody.
constructor: Policy Is Fixed at Deployment
The escrow contract defines the details of the escrow policy in its constructor in a form that cannot be changed. The policies that MUST be defined are two: the seller token contract address and the buyer token contract address. Beyond these, the escrow period, the maximum or minimum number of investors, the maximum or minimum amount of tokens to deposit, the exchange rate between seller and buyer tokens, and KYC verification of users MAY be defined optionally. Because the policy is fixed in the constructor, participants can check the conditions in the deployed contract before taking part.
escrowFund Behavior Rules
escrowFund deposits _value tokens to address _to. On the escrow contract side, _to must be a user address, msg.sender must be the payable contract address, and policy validation MUST be performed. On the payable contract side, _to must be the escrow contract address, and it MUST call the same function on the escrow contract interface. It passes msg.sender as the parameter _to, so that the escrow contract recognizes the actual user address that sent the tokens. The escrow contract may reject tokens that do not fit the policy.
escrowRefund Behavior Rules
escrowRefund refunds _value tokens from address _from. On the escrow contract side, _from must be a user address, msg.sender must be the payable contract address, and policy validation MUST be performed. On the payable contract side, _from must be the escrow contract address, and it calls the same function on the escrow contract while passing msg.sender as the parameter _from so that the user address is recognized. This function can be called while the escrow process is in progress or when the escrow has failed.
escrowWithdraw Behavior Rules
escrowWithdraw withdraws funds from the escrow account. The escrow contract MUST check that the escrow process is complete and MUST send the remaining seller token and buyer token balances to the msg.sender's seller or buyer contract wallet. Implementing this function in the payable contract is optional. When the escrow process ends in success, the seller can take the buyer's tokens and the buyer can take the seller's tokens.
Design Rationale and Backward Compatibility
The three functions escrowFund, escrowRefund and escrowWithdraw are designed based on the EIP-20 transfer function. The whole interface focuses on handling the refund problem that arises in escrow operations. A payable contract that implements this standard is fully backward compatible with the EIP-20 specification, so existing wallets and contracts can handle it as an ordinary EIP-20 token. The original text's test case shows a condition in which the exchange rate is 1 to 1 and the escrow ends in success when the number of buyers reaches 2, and before that the buyer can get a refund of the deposited tokens. This standard is finalized with Final status.
Things to watch out for
- Risk of Escrow Contract Defects: Because the escrow contract controls the rights of both the seller and the buyer, a defect in the escrow contract can directly lead to unexpected behavior and loss of funds.