From fc9f36cd2a65a9ee24574a3a6e93675a032d301b Mon Sep 17 00:00:00 2001 From: ferparis Date: Mon, 13 May 2019 11:34:14 +0200 Subject: [PATCH 01/12] Payoutable --- EIPS/payoutable-token-draft.md | 302 +++++++++++++++++++++++++++++++++ 1 file changed, 302 insertions(+) create mode 100644 EIPS/payoutable-token-draft.md diff --git a/EIPS/payoutable-token-draft.md b/EIPS/payoutable-token-draft.md new file mode 100644 index 00000000000000..48e4444e38356e --- /dev/null +++ b/EIPS/payoutable-token-draft.md @@ -0,0 +1,302 @@ +--- +eip: +title: Payoutable Token +author: Fernando Paris +status: Draft +type: Standards Track +category: ERC +created: 2019-05-10 +requires: 20 + +--- + +## Simple Summary +An extension to the ERC-20 standard token that allows Token wallet owners to request payut from their wallet, by calling the smart contract and attaching a payout instruction string. + +## Actors + +#### Token Wallet Owners +The person or company who owns the wallet, and will order payout. + +#### Token contract operator +The entity, company responsible/owner of the token contract, and token issuing/minting. This actor is in charge of trying to fullfill all payout request(s), reading the payout instruction(s), and corelate the payout details. + +#### Orderer +An actor who is enable to initiate payout orders on behalf ot a token wallet owner. + + +## Abstract +Token wallet owners (or approved addresses) can order payout requests through blockchain. This is done by calling the ```orderPayoutFrom``` or ```orderPayoutFrom``` methods, which initiate the workflow for the token contract operator to either honor or reject the payout request. In this case, payout instructions are provided when submitting the request, which are used by the operator to determine the destination of the funds. + +In general, it is not advisable to place explicit routing instructions for the payouts on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives. such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field on encrypted form. + + +## Motivation +Nowadays most of the token payout requests, a previous centralized transaction, to be able to define the payout destination to be able to execute the payout (burn transaction). +In the aim of trying step by step to bring all the needed steps into decentralization, exposing all the needed steps of token lifecycle and payment transactions, a payout request can allow wallet owner to initiate the payout order via blockchain. +Key benefits: + +* Payout, burning traceability is enhanced bringing the initation into the ledger. All payment, payout statuses can be stored on chain. +* Almost all money/token lifecycle is covered via an decentralized approach, complemented with private communications which is common used in the ecosystem. + + + +In this case, the following movement of tokens are done as the process progresses: + +* Upon launch of the payout request, the appropriate amount of funds are placed on a hold with no notary (i.e. it is an internal hold that cannot be released), and the payout is placed into a ```Ordered``` state +* The operator then can put the payout request ```InProcess```, which prevents the _orderer_ of the payout from being able to cancel the payout request +* After checking the payout is actually possible the operator then executes the hold, which moves the funds to a suspense wallet and places the payout into the ```FundsInSuspense``` state +* The operator then moves the funds offchain (usually from the omnibus account) to the appropriate destination account, then burning the tokens from the suspense wallet and rendering the payout into the ```Executed``` state +* Either before or after placing the request ```InProcess```, the operator can also reject the payout, which returns the funds to the payer and eliminates the hold. The resulting end state of the payout is ```Rejected``` +* When the payout is ```Ordered``` and before the operator places it into the ```InProcess``` state, the orderer of the payout can also cancel it, which frees up the hold and puts the payout into the final ```Cancelled``` state + + +## Specification + +```solidity +interface IPayoutable /* is ERC-20 */ { + enum PayoutStatusCode { + Nonexistent, + Ordered, + InProcess, + FundsInSuspense, + Executed, + Rejected, + Cancelled + } + function approveToOrderPayout(address orderer) external returns (bool); + function revokeApprovalToOrderPayout(address orderer) external returns (bool); + function orderPayout(string calldata operationId, uint256 value, string calldata instructions) external returns (bool); + function orderPayoutFrom(string calldata operationId, address walletToBePaidOut, uint256 value, string calldata instructions) external returns (bool); + function cancelPayout(string calldata operationId) external returns (bool); + function processPayout(address orderer, string calldata operationId) external returns (bool); + function putFundsInSuspenseInPayout(address orderer, string calldata operationId) external returns (bool); + function executePayout(address orderer, string calldata operationId) external returns (bool); + function rejectPayout(address orderer, string calldata operationId, string calldata reason) external returns (bool); + + function isApprovedToOrderPayout(address walletToDebit, address orderer) external view returns (bool); + function retrievePayoutData(address orderer, string calldata operationId) external view returns (address walletToDebit, uint256 value, string memory instructions, PayoutStatusCode status); + + event PayoutOrdered(address indexed orderer, string indexed operationId, address indexed walletToDebit, uint256 value, string instructions); + event PayoutInProcess(address indexed orderer, string indexed operationId); + event PayoutFundsInSuspense(address indexed orderer, string indexed operationId); + event PayoutExecuted(address indexed orderer, string indexed operationId); + event PayoutRejected(address indexed orderer, string indexed operationId, string reason); + event PayoutCancelled(address indexed orderer, string indexed operationId); + event ApprovalToOrderPayout(address indexed walletToBePaidOut, address indexed orderer); + event RevokeApprovalToOrderPayout(address indexed walletToBePaidOut, address indexed orderer); +} + +``` + +### Functions + +#### approveToOrderPayout + +Wallet owner, allows a given address to be payout orderer. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer. + +#### revokeApprovalToOrderPayout + +Wallet owner, Revokes a given address to be payout orderer. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer. + +#### orderPayout + +Creates a payout request, that will be processed by the token operator.All payout requests,orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. On operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. + + +| Parameter | Description | +| ---------|-------------| +| operationId | The unique ID per token holder to identify the request | +| value | The amount to be paid out. | +| instruction | A string including the payment instruction. | + +#### orderPayoutFrom + +Creates a payout request, on behalf of a wallet owner, that will be processed by the token operator. All payout requests,orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. On operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. + +| Parameter | Description | +| ---------|-------------| +| operationId |he unique ID per token holder to identify the request | +| walletToBePaidOut | The wallet to be paid out on behalf. +| value | The amount to be paid out. | +| instruction | A string including the payment instruction. | + +#### cancelPayout + +Cancels a payout request. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer, to correlate the right data. +| operationId | The unique ID per token holder to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | +| reason | The unique ID per token holder to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | + + +#### processPayout + +Marks a payout request as on process. After the status is on process, order cannot be cancelled. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer, to correlate the right data. +| operationId | The unique ID per orderer to identify the request is in process. + +#### putFundsInSuspenseInPayout + +Put a given payout in suspense. Can only be done it is in process. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer, to correlate the right data. +| operationId | The unique ID per orderer to identify the request is in process. + +#### executePayout + +Burn the amount of tokens and marks a payout request as executed. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer, to correlate the right data. +| operationId | The unique ID per orderer to identify the request that has been executed. + +#### rejectPayout + +Rejects a given operation with a reason. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer, to correlate the right data. +| operationId | The unique ID per orderer to identify the request that has been executed. +| reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used | + +#### isApprovedToOrderPayout + +Checks that given player is allowed to order payout requests, for a given wallet. + +| Parameter | Description | +| ---------|-------------| +| walletToBePaidOut | The wallet to be paid out, and checked for approval permission. +| orderer | The address of the orderer, to be checked for approval permission. + + +#### retrievePayoutData + +Retrieves all the payout request data. Only operator, tokenHolder, and orderer can get the given operation data. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the orderer, to correlate the right data. +| operationId | The unique ID per token holder to identify the payout order. + + +## Events + + +#### Payout Ordered + +Emitted when an token wallet owner orders a payout request. + +| operationId | The unique ID per token holder to identify the request | +| walletToBePaidOut | The wallet that is requested to be paid out | +| value | The amount to be funded. | +| instruction | A string including the payment instruction. | + +#### PayoutFundsInSuspense + +Emitted when an operator puts fund in suspense. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the payout request orderer. | +| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | + +#### PayoutInProcess + +Emitted when an operator accepts a payout request, and the operation is in process. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the payout request orderer. | +| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | + + +#### PayoutExecuted + +Emitted when an operator has executed a payout request. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the payout request orderer. | +| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | + + +#### PayoutRejected + +Emitted when an operator has rejected a payout request. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the payout request orderer. | +| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | +| reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used | + + +#### PayoutCancelled + +Emitted when a token holder, orderer, has cancelled a payout request. This can only be done if the operator hasn't put the payout order in process. + +| Parameter | Description | +| ---------|-------------| +| orderer | The address of the payout request orderer. | +| operationId | The unique ID per payout issuer to identify the payout. Operation ids are unique per requester/orderer. | + + +#### ApprovalToOrderPayout + +Emitted when a given player, operator, company or a given persona, has been approved to start payout request for a given token holder. + +| Parameter | Description | +| ---------|-------------| +| walletToBePaidOut | The wallet that the player is allowed to start payout requests | +| orderer |The address that allows the the player to start requests. | + +#### RevokeApprovalToOrderPayout + +Emitted when a given player has been revoked initiate payout requests. + +| Parameter | Description | +| ---------|-------------| +| walletToBePaidOut | The wallet that the player is allowed to start payout requests | +| orderer |The address that allows the the player to start requests. | + + + + +## Rationale +This standards provides a functionality to allow token holders to start payout requests in a decentralized way. + +It's important to hightlight that the token operator, need to process all payout request, updating the payout status based on the linked payment that will be done. + +Payout instruction format is open. ISO payment standard like is a good start point, + + + +## Backwards Compatibility +This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20. + +## Implementation +The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilders/payotable-token) contains the work in progress implementation. + +## Contributors +This proposal has been collaboratively implemented by adhara.io and io.builders. + +Copyright +Copyright and related rights waived via CC0. From c7ad8feca7648d8cc75f4c6e27da6397e0514423 Mon Sep 17 00:00:00 2001 From: Ferparishuertas Date: Mon, 13 May 2019 18:57:41 +0200 Subject: [PATCH 02/12] Update payoutable-token-draft.md --- EIPS/payoutable-token-draft.md | 54 +++++++++++++++++----------------- 1 file changed, 27 insertions(+), 27 deletions(-) diff --git a/EIPS/payoutable-token-draft.md b/EIPS/payoutable-token-draft.md index 48e4444e38356e..6c3b37652dfb73 100644 --- a/EIPS/payoutable-token-draft.md +++ b/EIPS/payoutable-token-draft.md @@ -11,39 +11,39 @@ requires: 20 --- ## Simple Summary -An extension to the ERC-20 standard token that allows Token wallet owners to request payut from their wallet, by calling the smart contract and attaching a payout instruction string. +An extension to the ERC-20 standard token that allows Token wallet owners to request payout from their wallet, by calling the smart contract and attaching a payout instruction string. ## Actors #### Token Wallet Owners The person or company who owns the wallet, and will order payout. -#### Token contract operator -The entity, company responsible/owner of the token contract, and token issuing/minting. This actor is in charge of trying to fullfill all payout request(s), reading the payout instruction(s), and corelate the payout details. +#### Token contract owner / agent +The entity, company responsible/owner of the token contract, and token issuing/minting. This actor is in charge of trying to fulfill all payout request(s), reading the payout instruction(s), and correlate the payout details. #### Orderer -An actor who is enable to initiate payout orders on behalf ot a token wallet owner. +An actor who is enabled to initiate payout orders on behalf ot a token wallet owner. ## Abstract Token wallet owners (or approved addresses) can order payout requests through blockchain. This is done by calling the ```orderPayoutFrom``` or ```orderPayoutFrom``` methods, which initiate the workflow for the token contract operator to either honor or reject the payout request. In this case, payout instructions are provided when submitting the request, which are used by the operator to determine the destination of the funds. -In general, it is not advisable to place explicit routing instructions for the payouts on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives. such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field on encrypted form. +In general, it is not advisable to place explicit routing instructions for the payouts on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives, such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field in encrypted form. ## Motivation -Nowadays most of the token payout requests, a previous centralized transaction, to be able to define the payout destination to be able to execute the payout (burn transaction). -In the aim of trying step by step to bring all the needed steps into decentralization, exposing all the needed steps of token lifecycle and payment transactions, a payout request can allow wallet owner to initiate the payout order via blockchain. +Nowadays most of the token payout requests, need a previous centralized transaction, to be able to define the payout destination to be able to execute the payout (burn transaction). +In the aim of trying to bring all the needed steps into decentralization, exposing all the needed steps of token lifecycle and payment transactions, a payout request can allow wallet owner to initiate the payout order via blockchain. Key benefits: * Payout, burning traceability is enhanced bringing the initation into the ledger. All payment, payout statuses can be stored on chain. -* Almost all money/token lifecycle is covered via an decentralized approach, complemented with private communications which is common used in the ecosystem. +* Almost all money/token lifecycle is covered via a decentralized approach, complemented with private communications which is common use in the ecosystem. In this case, the following movement of tokens are done as the process progresses: -* Upon launch of the payout request, the appropriate amount of funds are placed on a hold with no notary (i.e. it is an internal hold that cannot be released), and the payout is placed into a ```Ordered``` state +* Upon launch of the payout request, the appropriate amount of funds are placed on a hold with a predefined notary defined by the platform, and the payout is placed into a ```Ordered``` state * The operator then can put the payout request ```InProcess```, which prevents the _orderer_ of the payout from being able to cancel the payout request * After checking the payout is actually possible the operator then executes the hold, which moves the funds to a suspense wallet and places the payout into the ```FundsInSuspense``` state * The operator then moves the funds offchain (usually from the omnibus account) to the appropriate destination account, then burning the tokens from the suspense wallet and rendering the payout into the ```Executed``` state @@ -64,8 +64,8 @@ interface IPayoutable /* is ERC-20 */ { Rejected, Cancelled } - function approveToOrderPayout(address orderer) external returns (bool); - function revokeApprovalToOrderPayout(address orderer) external returns (bool); + function authorizePayoutOperator(address orderer) external returns (bool); + function revokePayoutOperator(address orderer) external returns (bool); function orderPayout(string calldata operationId, uint256 value, string calldata instructions) external returns (bool); function orderPayoutFrom(string calldata operationId, address walletToBePaidOut, uint256 value, string calldata instructions) external returns (bool); function cancelPayout(string calldata operationId) external returns (bool); @@ -74,7 +74,7 @@ interface IPayoutable /* is ERC-20 */ { function executePayout(address orderer, string calldata operationId) external returns (bool); function rejectPayout(address orderer, string calldata operationId, string calldata reason) external returns (bool); - function isApprovedToOrderPayout(address walletToDebit, address orderer) external view returns (bool); + function isPayoutOperatorFor(address walletToDebit, address orderer) external view returns (bool); function retrievePayoutData(address orderer, string calldata operationId) external view returns (address walletToDebit, uint256 value, string memory instructions, PayoutStatusCode status); event PayoutOrdered(address indexed orderer, string indexed operationId, address indexed walletToDebit, uint256 value, string instructions); @@ -83,15 +83,15 @@ interface IPayoutable /* is ERC-20 */ { event PayoutExecuted(address indexed orderer, string indexed operationId); event PayoutRejected(address indexed orderer, string indexed operationId, string reason); event PayoutCancelled(address indexed orderer, string indexed operationId); - event ApprovalToOrderPayout(address indexed walletToBePaidOut, address indexed orderer); - event RevokeApprovalToOrderPayout(address indexed walletToBePaidOut, address indexed orderer); + event PayoutOperatorAuthorized(address indexed walletToBePaidOut, address indexed orderer); + event PayoutOperatorRevoked(address indexed walletToBePaidOut, address indexed orderer); } ``` ### Functions -#### approveToOrderPayout +#### authorizePayoutOperator Wallet owner, allows a given address to be payout orderer. @@ -99,7 +99,7 @@ Wallet owner, allows a given address to be payout orderer. | ---------|-------------| | orderer | The address of the orderer. -#### revokeApprovalToOrderPayout +#### revokePayoutOperator Wallet owner, Revokes a given address to be payout orderer. @@ -109,7 +109,7 @@ Wallet owner, Revokes a given address to be payout orderer. #### orderPayout -Creates a payout request, that will be processed by the token operator.All payout requests,orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. On operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. +Creates a payout request, that will be processed by the token operator. All payout requests, orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. An operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. | Parameter | Description | @@ -120,11 +120,11 @@ Creates a payout request, that will be processed by the token operator.All payou #### orderPayoutFrom -Creates a payout request, on behalf of a wallet owner, that will be processed by the token operator. All payout requests,orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. On operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. +Creates a payout request, on behalf of a wallet owner, that will be processed by the token operator. All payout requests, orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. On operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. | Parameter | Description | | ---------|-------------| -| operationId |he unique ID per token holder to identify the request | +| operationId |The unique ID per token orderer to identify the request | | walletToBePaidOut | The wallet to be paid out on behalf. | value | The amount to be paid out. | | instruction | A string including the payment instruction. | @@ -136,8 +136,8 @@ Cancels a payout request. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per token holder to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | -| reason | The unique ID per token holder to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | +| operationId | The unique ID per token orderer to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | +| reason | The unique ID per token orderer to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | #### processPayout @@ -147,16 +147,16 @@ Marks a payout request as on process. After the status is on process, order cann | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per orderer to identify the request is in process. +| operationId | The unique ID per orderer to identify that the request is in process. #### putFundsInSuspenseInPayout -Put a given payout in suspense. Can only be done it is in process. +Put a given payout in suspense. Can only be done if it is in process. | Parameter | Description | | ---------|-------------| | orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per orderer to identify the request is in process. +| operationId | The unique ID per orderer to identify that the request is in process. #### executePayout @@ -259,7 +259,7 @@ Emitted when a token holder, orderer, has cancelled a payout request. This can | operationId | The unique ID per payout issuer to identify the payout. Operation ids are unique per requester/orderer. | -#### ApprovalToOrderPayout +#### PayoutOperatorAuthorized Emitted when a given player, operator, company or a given persona, has been approved to start payout request for a given token holder. @@ -268,7 +268,7 @@ Emitted when a given player, operator, company or a given persona, has been appr | walletToBePaidOut | The wallet that the player is allowed to start payout requests | | orderer |The address that allows the the player to start requests. | -#### RevokeApprovalToOrderPayout +#### PayoutOperatorRevoked Emitted when a given player has been revoked initiate payout requests. @@ -298,5 +298,5 @@ The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilder ## Contributors This proposal has been collaboratively implemented by adhara.io and io.builders. -Copyright +## Copyright Copyright and related rights waived via CC0. From fead77f52fb3fbc5dc59cc3cd560351fcd6d35f6 Mon Sep 17 00:00:00 2001 From: Daniel Lehrner Date: Tue, 14 May 2019 09:35:09 +0200 Subject: [PATCH 03/12] added EIP number, used links for contributors --- EIPS/{payoutable-token-draft.md => eip-2021.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename EIPS/{payoutable-token-draft.md => eip-2021.md} (99%) diff --git a/EIPS/payoutable-token-draft.md b/EIPS/eip-2021.md similarity index 99% rename from EIPS/payoutable-token-draft.md rename to EIPS/eip-2021.md index 6c3b37652dfb73..a218572ce48e41 100644 --- a/EIPS/payoutable-token-draft.md +++ b/EIPS/eip-2021.md @@ -1,5 +1,5 @@ --- -eip: +eip: 2021 title: Payoutable Token author: Fernando Paris status: Draft @@ -296,7 +296,7 @@ This EIP is fully backwards compatible as its implementation extends the functio The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilders/payotable-token) contains the work in progress implementation. ## Contributors -This proposal has been collaboratively implemented by adhara.io and io.builders. +This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/). ## Copyright Copyright and related rights waived via CC0. From 60148e6187ac27cb99de4022aaedd42383edfe72 Mon Sep 17 00:00:00 2001 From: Daniel Lehrner Date: Tue, 14 May 2019 16:28:18 +0200 Subject: [PATCH 04/12] added requirement to ERC-1996 --- EIPS/eip-2021.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index a218572ce48e41..234d1eb1a3365a 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -6,7 +6,7 @@ status: Draft type: Standards Track category: ERC created: 2019-05-10 -requires: 20 +requires: 20, 1996 --- @@ -287,10 +287,10 @@ It's important to hightlight that the token operator, need to process all payout Payout instruction format is open. ISO payment standard like is a good start point, - +This EIP uses [EIP-1996][EIP-1996] to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not. ## Backwards Compatibility -This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20. +This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20 and ERC-1996. ## Implementation The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilders/payotable-token) contains the work in progress implementation. @@ -300,3 +300,5 @@ This proposal has been collaboratively implemented by [adhara.io](https://adhara ## Copyright Copyright and related rights waived via CC0. + +[EIP-1996]: https://github.com/ethereum/EIPs/pull/1996 From fd573bf1342f5c55481024c17278495ff04d70e0 Mon Sep 17 00:00:00 2001 From: Daniel Lehrner Date: Thu, 6 Jun 2019 15:29:25 +0200 Subject: [PATCH 05/12] made operation id globally unique --- EIPS/eip-2021.md | 92 ++++++++++++++++++++---------------------------- 1 file changed, 38 insertions(+), 54 deletions(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 234d1eb1a3365a..44ab7b946256b3 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -1,13 +1,13 @@ --- eip: 2021 title: Payoutable Token -author: Fernando Paris +author: Fernando Paris , Julio Faura , Daniel Lehrner +discussions-to: https://github.com/ethereum/EIPs/issues/2106 status: Draft type: Standards Track category: ERC created: 2019-05-10 requires: 20, 1996 - --- ## Simple Summary @@ -24,13 +24,11 @@ The entity, company responsible/owner of the token contract, and token issuing/m #### Orderer An actor who is enabled to initiate payout orders on behalf ot a token wallet owner. - ## Abstract Token wallet owners (or approved addresses) can order payout requests through blockchain. This is done by calling the ```orderPayoutFrom``` or ```orderPayoutFrom``` methods, which initiate the workflow for the token contract operator to either honor or reject the payout request. In this case, payout instructions are provided when submitting the request, which are used by the operator to determine the destination of the funds. In general, it is not advisable to place explicit routing instructions for the payouts on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives, such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field in encrypted form. - ## Motivation Nowadays most of the token payout requests, need a previous centralized transaction, to be able to define the payout destination to be able to execute the payout (burn transaction). In the aim of trying to bring all the needed steps into decentralization, exposing all the needed steps of token lifecycle and payment transactions, a payout request can allow wallet owner to initiate the payout order via blockchain. @@ -39,8 +37,6 @@ Key benefits: * Payout, burning traceability is enhanced bringing the initation into the ledger. All payment, payout statuses can be stored on chain. * Almost all money/token lifecycle is covered via a decentralized approach, complemented with private communications which is common use in the ecosystem. - - In this case, the following movement of tokens are done as the process progresses: * Upon launch of the payout request, the appropriate amount of funds are placed on a hold with a predefined notary defined by the platform, and the payout is placed into a ```Ordered``` state @@ -50,7 +46,6 @@ In this case, the following movement of tokens are done as the process progresse * Either before or after placing the request ```InProcess```, the operator can also reject the payout, which returns the funds to the payer and eliminates the hold. The resulting end state of the payout is ```Rejected``` * When the payout is ```Ordered``` and before the operator places it into the ```InProcess``` state, the orderer of the payout can also cancel it, which frees up the hold and puts the payout into the final ```Cancelled``` state - ## Specification ```solidity @@ -69,13 +64,13 @@ interface IPayoutable /* is ERC-20 */ { function orderPayout(string calldata operationId, uint256 value, string calldata instructions) external returns (bool); function orderPayoutFrom(string calldata operationId, address walletToBePaidOut, uint256 value, string calldata instructions) external returns (bool); function cancelPayout(string calldata operationId) external returns (bool); - function processPayout(address orderer, string calldata operationId) external returns (bool); - function putFundsInSuspenseInPayout(address orderer, string calldata operationId) external returns (bool); - function executePayout(address orderer, string calldata operationId) external returns (bool); - function rejectPayout(address orderer, string calldata operationId, string calldata reason) external returns (bool); + function processPayout(string calldata operationId) external returns (bool); + function putFundsInSuspenseInPayout(string calldata operationId) external returns (bool); + function executePayout(string calldata operationId) external returns (bool); + function rejectPayout(string calldata operationId, string calldata reason) external returns (bool); function isPayoutOperatorFor(address walletToDebit, address orderer) external view returns (bool); - function retrievePayoutData(address orderer, string calldata operationId) external view returns (address walletToDebit, uint256 value, string memory instructions, PayoutStatusCode status); + function retrievePayoutData(string calldata operationId) external view returns (address walletToDebit, uint256 value, string memory instructions, PayoutStatusCode status); event PayoutOrdered(address indexed orderer, string indexed operationId, address indexed walletToDebit, uint256 value, string instructions); event PayoutInProcess(address indexed orderer, string indexed operationId); @@ -86,7 +81,6 @@ interface IPayoutable /* is ERC-20 */ { event PayoutOperatorAuthorized(address indexed walletToBePaidOut, address indexed orderer); event PayoutOperatorRevoked(address indexed walletToBePaidOut, address indexed orderer); } - ``` ### Functions @@ -97,7 +91,7 @@ Wallet owner, allows a given address to be payout orderer. | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer. +| orderer | The address of the orderer. | #### revokePayoutOperator @@ -105,27 +99,26 @@ Wallet owner, Revokes a given address to be payout orderer. | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer. +| orderer | The address of the orderer. | #### orderPayout -Creates a payout request, that will be processed by the token operator. All payout requests, orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. An operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. - +Creates a payout request, that will be processed by the token operator. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| -| operationId | The unique ID per token holder to identify the request | +| operationId | The unique ID to identify the request | | value | The amount to be paid out. | | instruction | A string including the payment instruction. | #### orderPayoutFrom -Creates a payout request, on behalf of a wallet owner, that will be processed by the token operator. All payout requests, orders, will be linked to the orderer, associating operationId to orderer, to avoid global collision between operationIds. On operationId cannot be repeated for a given orderer, but there can be two equal operation id's for distinct orderers. +Creates a payout request, on behalf of a wallet owner, that will be processed by the token operator. The function must revert if the operation ID has been used before. | Parameter | Description | | ---------|-------------| -| operationId |The unique ID per token orderer to identify the request | -| walletToBePaidOut | The wallet to be paid out on behalf. +| operationId |The unique ID to identify the request | +| walletToBePaidOut | The wallet to be paid out on behalf. | | value | The amount to be paid out. | | instruction | A string including the payment instruction. | @@ -135,9 +128,8 @@ Cancels a payout request. | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per token orderer to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | -| reason | The unique ID per token orderer to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | +| operationId | The unique ID to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | +| reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used. | #### processPayout @@ -146,8 +138,7 @@ Marks a payout request as on process. After the status is on process, order cann | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per orderer to identify that the request is in process. +| operationId | The unique ID to identify that the request is in process. | #### putFundsInSuspenseInPayout @@ -155,8 +146,7 @@ Put a given payout in suspense. Can only be done if it is in process. | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per orderer to identify that the request is in process. +| operationId | The unique ID to identify that the request is in process. | #### executePayout @@ -164,8 +154,7 @@ Burn the amount of tokens and marks a payout request as executed. | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per orderer to identify the request that has been executed. +| operationId | The unique ID to identify the request that has been executed. | #### rejectPayout @@ -173,8 +162,7 @@ Rejects a given operation with a reason. | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per orderer to identify the request that has been executed. +| operationId | The unique ID to identify the request that has been executed. | | reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used | #### isApprovedToOrderPayout @@ -183,9 +171,8 @@ Checks that given player is allowed to order payout requests, for a given walle | Parameter | Description | | ---------|-------------| -| walletToBePaidOut | The wallet to be paid out, and checked for approval permission. -| orderer | The address of the orderer, to be checked for approval permission. - +| walletToBePaidOut | The wallet to be paid out, and checked for approval permission. | +| orderer | The address of the orderer, to be checked for approval permission. | #### retrievePayoutData @@ -193,18 +180,18 @@ Retrieves all the payout request data. Only operator, tokenHolder, and orderer c | Parameter | Description | | ---------|-------------| -| orderer | The address of the orderer, to correlate the right data. -| operationId | The unique ID per token holder to identify the payout order. - +| orderer | The address of the orderer, to correlate the right data. | +| operationId | The unique ID to identify the payout order. | ## Events - #### Payout Ordered Emitted when an token wallet owner orders a payout request. -| operationId | The unique ID per token holder to identify the request | +| Parameter | Description | +| ---------|-------------| +| operationId | The unique ID to identify the request | | walletToBePaidOut | The wallet that is requested to be paid out | | value | The amount to be funded. | | instruction | A string including the payment instruction. | @@ -216,7 +203,7 @@ Emitted when an operator puts fund in suspense. | Parameter | Description | | ---------|-------------| | orderer | The address of the payout request orderer. | -| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | +| operationId | The unique ID to identify the payout. | #### PayoutInProcess @@ -225,8 +212,7 @@ Emitted when an operator accepts a payout request, and the operation is in proce | Parameter | Description | | ---------|-------------| | orderer | The address of the payout request orderer. | -| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | - +| operationId | The unique ID to identify the payout. | #### PayoutExecuted @@ -235,8 +221,7 @@ Emitted when an operator has executed a payout request. | Parameter | Description | | ---------|-------------| | orderer | The address of the payout request orderer. | -| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | - +| operationId | The unique ID to identify the payout. | #### PayoutRejected @@ -245,10 +230,9 @@ Emitted when an operator has rejected a payout request. | Parameter | Description | | ---------|-------------| | orderer | The address of the payout request orderer. | -| operationId | The unique ID per payout orderer to identify the payout. Operation ids are unique per requester/orderer. | +| operationId | The unique ID to identify the payout. | | reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used | - #### PayoutCancelled Emitted when a token holder, orderer, has cancelled a payout request. This can only be done if the operator hasn't put the payout order in process. @@ -256,8 +240,7 @@ Emitted when a token holder, orderer, has cancelled a payout request. This can | Parameter | Description | | ---------|-------------| | orderer | The address of the payout request orderer. | -| operationId | The unique ID per payout issuer to identify the payout. Operation ids are unique per requester/orderer. | - +| operationId | The unique ID per payout issuer to identify the payout. | #### PayoutOperatorAuthorized @@ -277,18 +260,19 @@ Emitted when a given player has been revoked initiate payout requests. | walletToBePaidOut | The wallet that the player is allowed to start payout requests | | orderer |The address that allows the the player to start requests. | - - - ## Rationale This standards provides a functionality to allow token holders to start payout requests in a decentralized way. -It's important to hightlight that the token operator, need to process all payout request, updating the payout status based on the linked payment that will be done. +It's important to highlight that the token operator, need to process all payout request, updating the payout status based on the linked payment that will be done. Payout instruction format is open. ISO payment standard like is a good start point, This EIP uses [EIP-1996][EIP-1996] to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not. +The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. + +The `operationId` is a competitive resource. It is recommended, but not required, that the hold issuers used a unique prefix to avoid collisions. + ## Backwards Compatibility This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20 and ERC-1996. @@ -299,6 +283,6 @@ The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilder This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/). ## Copyright -Copyright and related rights waived via CC0. +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). [EIP-1996]: https://github.com/ethereum/EIPs/pull/1996 From 316bb440490ce930d385e46d2188ac02ce9c754a Mon Sep 17 00:00:00 2001 From: Daniel Lehrner Date: Wed, 17 Jul 2019 12:16:24 +0200 Subject: [PATCH 06/12] added reference implementation --- EIPS/eip-2021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 44ab7b946256b3..89d0bc22a649d8 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -277,7 +277,7 @@ The `operationId` is a competitive resource. It is recommended, but not required This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20 and ERC-1996. ## Implementation -The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilders/payotable-token) contains the work in progress implementation. +The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilders/payoutable-token) contains the reference implementation. ## Contributors This proposal has been collaboratively implemented by [adhara.io](https://adhara.io/) and [io.builders](https://io.builders/). From 108e606019d443a82114ed89a54b588cf2239606 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sat, 23 Nov 2019 00:05:53 +0000 Subject: [PATCH 07/12] Add links to EIP-20/1066/1996 --- EIPS/eip-2021.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 89d0bc22a649d8..2b81c72cd1a625 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -7,11 +7,11 @@ status: Draft type: Standards Track category: ERC created: 2019-05-10 -requires: 20, 1996 +requires: 20, 1066, 1996 --- ## Simple Summary -An extension to the ERC-20 standard token that allows Token wallet owners to request payout from their wallet, by calling the smart contract and attaching a payout instruction string. +An extension to the [ERC-20] standard token that allows Token wallet owners to request payout from their wallet, by calling the smart contract and attaching a payout instruction string. ## Actors @@ -129,7 +129,7 @@ Cancels a payout request. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that is going to be cancelled. This can only be done by token holder, or the payout initiator/orderer. | -| reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used. | +| reason | The specific reason that explains why the payout request was rejected. [EIP-1066] codes can be used. | #### processPayout @@ -163,7 +163,7 @@ Rejects a given operation with a reason. | Parameter | Description | | ---------|-------------| | operationId | The unique ID to identify the request that has been executed. | -| reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used | +| reason | The specific reason that explains why the payout request was rejected. [EIP-1066] codes can be used | #### isApprovedToOrderPayout @@ -231,7 +231,7 @@ Emitted when an operator has rejected a payout request. | ---------|-------------| | orderer | The address of the payout request orderer. | | operationId | The unique ID to identify the payout. | -| reason | The specific reason that explains why the payout request was rejected. EIP 1066 codes can be used | +| reason | The specific reason that explains why the payout request was rejected. [EIP-1066] codes can be used | #### PayoutCancelled @@ -267,14 +267,14 @@ It's important to highlight that the token operator, need to process all payout Payout instruction format is open. ISO payment standard like is a good start point, -This EIP uses [EIP-1996][EIP-1996] to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not. +This EIP uses [EIP-1996] to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not. The `operationId` is a string and not something more gas efficient to allow easy traceability of the hold and allow human readable ids. It is up to the implementer if the string should be stored on-chain or only its hash, as it is enough to identify a hold. The `operationId` is a competitive resource. It is recommended, but not required, that the hold issuers used a unique prefix to avoid collisions. ## Backwards Compatibility -This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20 and ERC-1996. +This EIP is fully backwards compatible as its implementation extends the functionality of [ERC-20] and [ERC-1996]. ## Implementation The GitHub repository [IoBuilders/payoutable-token](https://github.com/IoBuilders/payoutable-token) contains the reference implementation. @@ -285,4 +285,6 @@ This proposal has been collaboratively implemented by [adhara.io](https://adhara ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). -[EIP-1996]: https://github.com/ethereum/EIPs/pull/1996 +[ERC-20]: https://eips.ethereum.org/EIPS/eip-20 +[EIP-1066]: https://eips.ethereum.org/EIPS/eip-1066 +[EIP-1996]: https://eips.ethereum.org/EIPS/eip-1996 From b42753d133df168a1c4f517588b4968b5661cff4 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sat, 23 Nov 2019 00:08:22 +0000 Subject: [PATCH 08/12] Fix spellin --- EIPS/eip-2021.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 2b81c72cd1a625..b22a45b501d989 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -27,14 +27,14 @@ An actor who is enabled to initiate payout orders on behalf ot a token wallet ow ## Abstract Token wallet owners (or approved addresses) can order payout requests through blockchain. This is done by calling the ```orderPayoutFrom``` or ```orderPayoutFrom``` methods, which initiate the workflow for the token contract operator to either honor or reject the payout request. In this case, payout instructions are provided when submitting the request, which are used by the operator to determine the destination of the funds. -In general, it is not advisable to place explicit routing instructions for the payouts on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives, such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field in encrypted form. +In general, it is not advisable to place explicit routing instructions for the payouts on a verbatim basis on the blockchain, and it is advised to use a private communication alternatives, such as private channels, encrypted storage or similar, to do so (external to the blockchain ledger). Another (less desirable) possibility is to place these instructions on the instructions field in encrypted form. ## Motivation Nowadays most of the token payout requests, need a previous centralized transaction, to be able to define the payout destination to be able to execute the payout (burn transaction). In the aim of trying to bring all the needed steps into decentralization, exposing all the needed steps of token lifecycle and payment transactions, a payout request can allow wallet owner to initiate the payout order via blockchain. Key benefits: -* Payout, burning traceability is enhanced bringing the initation into the ledger. All payment, payout statuses can be stored on chain. +* Payout, burning traceability is enhanced bringing the initiation into the ledger. All payment, payout statuses can be stored on chain. * Almost all money/token lifecycle is covered via a decentralized approach, complemented with private communications which is common use in the ecosystem. In this case, the following movement of tokens are done as the process progresses: From 5a93143573c16a902b5ce9e853f25d76bc099919 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sat, 23 Nov 2019 00:17:00 +0000 Subject: [PATCH 09/12] Fix spelling --- EIPS/eip-2021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index b22a45b501d989..12bcb206f5c52e 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -22,7 +22,7 @@ The person or company who owns the wallet, and will order payout. The entity, company responsible/owner of the token contract, and token issuing/minting. This actor is in charge of trying to fulfill all payout request(s), reading the payout instruction(s), and correlate the payout details. #### Orderer -An actor who is enabled to initiate payout orders on behalf ot a token wallet owner. +An actor who is enabled to initiate payout orders on behalf of a token wallet owner. ## Abstract Token wallet owners (or approved addresses) can order payout requests through blockchain. This is done by calling the ```orderPayoutFrom``` or ```orderPayoutFrom``` methods, which initiate the workflow for the token contract operator to either honor or reject the payout request. In this case, payout instructions are provided when submitting the request, which are used by the operator to determine the destination of the funds. From 42da6237f178af148f151fe11f1c1a3b2ccbfec8 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sat, 23 Nov 2019 00:17:18 +0000 Subject: [PATCH 10/12] Fix whitespace --- EIPS/eip-2021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 12bcb206f5c52e..7d6b5a8a2d6865 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -5,7 +5,7 @@ author: Fernando Paris , Julio Faura , Daniel discussions-to: https://github.com/ethereum/EIPs/issues/2106 status: Draft type: Standards Track -category: ERC +category: ERC created: 2019-05-10 requires: 20, 1066, 1996 --- From c3bd685f4ab54678fff6a6cb1f27723af4256c63 Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sat, 23 Nov 2019 00:18:22 +0000 Subject: [PATCH 11/12] Fix markdown --- EIPS/eip-2021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 7d6b5a8a2d6865..4cfe7009d465e2 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -183,7 +183,7 @@ Retrieves all the payout request data. Only operator, tokenHolder, and orderer c | orderer | The address of the orderer, to correlate the right data. | | operationId | The unique ID to identify the payout order. | -## Events +### Events #### Payout Ordered From 024773fa6b7a72974d7018b2d20733f428e8999f Mon Sep 17 00:00:00 2001 From: Alex Beregszaszi Date: Sat, 23 Nov 2019 00:24:23 +0000 Subject: [PATCH 12/12] Typos. --- EIPS/eip-2021.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-2021.md b/EIPS/eip-2021.md index 4cfe7009d465e2..416f7b5ae605fc 100644 --- a/EIPS/eip-2021.md +++ b/EIPS/eip-2021.md @@ -265,7 +265,7 @@ This standards provides a functionality to allow token holders to start payout r It's important to highlight that the token operator, need to process all payout request, updating the payout status based on the linked payment that will be done. -Payout instruction format is open. ISO payment standard like is a good start point, +Payout instruction format is open. ISO payment standard like is a good start point. This EIP uses [EIP-1996] to hold the money after a payout is ordered. The token contract owner or agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the payout is executed or not.