From de7486719935081b43e4b01ebc73b356bce68672 Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Tue, 30 Apr 2019 16:11:47 +0200
Subject: [PATCH 01/11] first draft

---
 EIPS/eip-clearable.md | 131 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 131 insertions(+)
 create mode 100644 EIPS/eip-clearable.md

diff --git a/EIPS/eip-clearable.md b/EIPS/eip-clearable.md
new file mode 100644
index 0000000000000..d974ee170154b
--- /dev/null
+++ b/EIPS/eip-clearable.md
@@ -0,0 +1,131 @@
+---
+eip: <to be assigned>
+title: Clearable Token
+author: Daniel Lehrner <daniel@io.builders>
+discussions-to: https://github.com/IoBuilders/EIPs/pull/3
+status: Draft
+type: Standards Track
+category: ERC
+created: 2019-04-30
+requires: 20
+---
+
+<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+
+In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled. [[1]][Wikipedia] 
+
+## Actors
+
+#### Clearing Agent
+
+An account which processes, executes or rejects a clearable transfer.
+
+#### Operator
+An account which has been approved by an account to order clearable transfers on its behalf.
+
+#### Orderer
+The account which orders a clearable transfer. This can be the account owner itself, or any account, which has been approved as an operator for the account.
+
+## Abstract
+<!--A short (~200 word) description of the technical issue being addressed.-->
+
+The clearing process turns the promise of transfer into the actual movement of money from one account to another. 
+
+## Motivation
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.
+
+## Specification
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+
+```solidity
+interface ClearableToken /* is ERC-20 */ {
+    enum ClearableTransferStatusCode { Nonexistent, Ordered, InProcess, Executed, Rejected, Cancelled }
+
+
+    function orderTransfer(string calldata operationId, address to, uint256 value) external returns (bool);
+    function orderTransferFrom(string calldata operationId, address from, address to, uint256 value) external returns (bool);
+    function cancelTransfer(string calldata operationId) external returns (bool);
+    function processClearableTransfer(address orderer, string calldata operationId) external returns (bool);
+    function executeClearableTransfer(address orderer, string calldata operationId) external returns (bool);
+    
+    event ClearableTransferInProcess(address indexed orderer, string operationId);
+    event ClearableTransferExecuted(address indexed orderer, string operationId);
+    event ClearableTransferRejected(address indexed orderer, string operationId, string reason);
+    event ClearableTransferCancelled(address indexed orderer, string operationId);
+    event ApprovalToorderTransfer(address indexed wallet, address indexed orderer);
+    event RevokeApprovalToorderTransfer(address indexed wallet, address indexed orderer);
+}
+```
+
+### Functions
+
+#### orderTransfer
+
+Orders a clearable transfer on behalf of the msg.sender in favor of the payee. It specifies a notary who is responsable to either execute or release the hold.
+
+| Parameter | Description |
+| ---------|-------------|
+| operationId | The unique ID per issuer to identify the clearable transfer |
+| to | The address of the payee, to whom the tokens are to be paid if executed |
+| value | The amount to be transferred. Must be less or equal than the balance of the payer. |
+
+#### orderTransferFrom
+
+Orders a clearable transfer on behalf of the payer in favor of the payee. It specifies a notary who is responsable to either execute or release the hold.
+
+| Parameter | Description |
+| ---------|-------------|
+| operationId | The unique ID per issuer to identify the clearable transfer |
+| to | The address of the payee, to whom the tokens are to be paid if executed |
+| value | The amount to be transferred. Must be less or equal than the balance of the payer. |
+
+#### cancelTransfer
+
+Cancels the order of a clearable transfer. Only the orderer can cancel their own orders. Must not be successful as soon as it is in status `InProcess`.
+
+| Parameter | Description |
+| ---------|-------------|
+| operationId | The unique ID per issuer to identify the clearable transfer |
+
+#### processClearableTransfer
+
+Sets a clearable transfer to status `InProcess`. Only an clearing agent can successfully execute this action.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address which ordered the clearable transfer |
+| operationId | The unique ID per issuer to identify the clearable transfer |
+
+#### executeClearableTransfer
+
+Executes a clearable transfer, . Only an clearing agent can successfully execute this action.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address which ordered the clearable transfer |
+| operationId | The unique ID per issuer to identify the clearable transfer |
+
+## Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+## Backwards Compatibility
+<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+
+This EIP is fully backwards compatible as its implementation extends the functionality of ERC-20.
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+
+The GitHub repository [IoBuilders/clearable-token](https://github.com/IoBuilders/clearable-token) contains the work in progress implementation.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+[1] https://en.wikipedia.org/wiki/Clearing_(finance)
+
+[Wikipedia]: https://en.wikipedia.org/wiki/Clearing_(finance)

From 679ad0ea101485507a716d97228c8d24d4c3360d Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Wed, 8 May 2019 14:37:03 +0200
Subject: [PATCH 02/11] added missing functions

---
 EIPS/eip-clearable.md | 150 +++++++++++++++++++++++++++++++++++++-----
 1 file changed, 135 insertions(+), 15 deletions(-)

diff --git a/EIPS/eip-clearable.md b/EIPS/eip-clearable.md
index d974ee170154b..bdd467a5d4f95 100644
--- a/EIPS/eip-clearable.md
+++ b/EIPS/eip-clearable.md
@@ -15,7 +15,7 @@ requires: 20
 ## Simple Summary
 <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
 
-In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled. [[1]][Wikipedia] 
+> "In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled." [[1]][Wikipedia] 
 
 ## Actors
 
@@ -32,7 +32,7 @@ The account which orders a clearable transfer. This can be the account owner its
 ## Abstract
 <!--A short (~200 word) description of the technical issue being addressed.-->
 
-The clearing process turns the promise of transfer into the actual movement of money from one account to another. 
+The clearing process turns the promise of transfer into the actual movement of money from one account to another. A clearing agent decides if the transfer can be executed or not. The amount which should be transferred is not deducted on the balance of the 
 
 ## Motivation
 <!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
@@ -51,13 +51,20 @@ interface ClearableToken /* is ERC-20 */ {
     function cancelTransfer(string calldata operationId) external returns (bool);
     function processClearableTransfer(address orderer, string calldata operationId) external returns (bool);
     function executeClearableTransfer(address orderer, string calldata operationId) external returns (bool);
-    
+    function rejectClearableTransfer(address orderer, string calldata operationId, string calldata reason) external returns (bool);
+    function retrieveClearableTransferData(address orderer, string calldata operationId) external view returns (address from, address to, uint256 value, ClearableTransferStatusCode status);
+
+    function authorizeClearableTransferOrderer(address orderer) external returns (bool);
+    function revokeClearableTransferOrderer(address orderer) external returns (bool);
+    function isClearableTransferOrdererFor(address orderer, address from) external view returns (bool);
+
+    event ClearableTransferOrdered(address indexed orderer, string operationId, address indexed from, address indexed to, uint256 value);
     event ClearableTransferInProcess(address indexed orderer, string operationId);
     event ClearableTransferExecuted(address indexed orderer, string operationId);
     event ClearableTransferRejected(address indexed orderer, string operationId, string reason);
     event ClearableTransferCancelled(address indexed orderer, string operationId);
-    event ApprovalToorderTransfer(address indexed wallet, address indexed orderer);
-    event RevokeApprovalToorderTransfer(address indexed wallet, address indexed orderer);
+    event AuthorizedClearableTransferOrderer(address indexed orderer, address indexed account);
+    event RevokedClearableTransferOrderer(address indexed orderer, address indexed account);
 }
 ```
 
@@ -65,49 +72,162 @@ interface ClearableToken /* is ERC-20 */ {
 
 #### orderTransfer
 
-Orders a clearable transfer on behalf of the msg.sender in favor of the payee. It specifies a notary who is responsable to either execute or release the hold.
+Orders a clearable transfer on behalf of the msg.sender in favor of the payee. A clearing agent is responsible to either execute or reject the transfer.
 
 | Parameter | Description |
 | ---------|-------------|
-| operationId | The unique ID per issuer to identify the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
 | value | The amount to be transferred. Must be less or equal than the balance of the payer. |
 
 #### orderTransferFrom
 
-Orders a clearable transfer on behalf of the payer in favor of the payee. It specifies a notary who is responsable to either execute or release the hold.
+Orders a clearable transfer on behalf of the payer in favor of the payee. A clearing agent is responsible to either execute or reject the transfer.
 
 | Parameter | Description |
 | ---------|-------------|
-| operationId | The unique ID per issuer to identify the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
 | value | The amount to be transferred. Must be less or equal than the balance of the payer. |
 
 #### cancelTransfer
 
-Cancels the order of a clearable transfer. Only the orderer can cancel their own orders. Must not be successful as soon as it is in status `InProcess`.
+Cancels the order of a clearable transfer. Only the orderer can cancel their own orders. It must not be successful as soon as it is in status `InProcess`.
 
 | Parameter | Description |
 | ---------|-------------|
-| operationId | The unique ID per issuer to identify the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
 
 #### processClearableTransfer
 
-Sets a clearable transfer to status `InProcess`. Only an clearing agent can successfully execute this action.
+Sets a clearable transfer to status `InProcess`. Only a clearing agent can successfully execute this action.
 
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address which ordered the clearable transfer |
-| operationId | The unique ID per issuer to identify the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
 
 #### executeClearableTransfer
 
-Executes a clearable transfer, . Only an clearing agent can successfully execute this action.
+Executes a clearable transfer, which means that the tokens are transferred from the payer to the payee. Only a clearing agent can successfully execute this action.
 
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address which ordered the clearable transfer |
-| operationId | The unique ID per issuer to identify the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+
+#### rejectClearableTransfer
+
+Rejects a clearable transfer, which means that the amount that is held is available again to the payer and no transfer is done. Only a clearing agent can successfully execute this action.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address which ordered the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+| reason | A reason given by the clearing agent why the transfer has been rejected |
+
+#### retrieveClearableTransferData
+
+Retrieves all the information available for a particular clearable transfer.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address which ordered the clearable transfer |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+
+#### authorizeClearableTransferOrderer
+
+Approves an orderer to order transfers on behalf of msg.sender.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be approved as orderer of transfers |
+
+#### revokeClearableTransferOrderer
+
+Revokes the approval to order transfers on behalf of msg.sender.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be revokes as orderer of transfers |
+
+#### isClearableTransferOrdererFor
+
+Returns if an orderer is approved to order transfers on behalf of `from`.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| from | The address on which the holds would be created |
+
+### Events
+
+#### ClearableTransferOrdered
+
+Must be emitted when a clearable transfer is ordered.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+| from | The address of the payer, from whom the tokens are to be taken if executed |
+| to | The address of the payee, to whom the tokens are to be paid if executed |
+| value | The amount to be transferred if executed |
+
+#### ClearableTransferInProcess
+
+Must be emitted when a clearable transfer is put in status `ÌnProcess`.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+
+#### ClearableTransferExecuted
+
+Must be emitted when a clearable transfer is executed.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+
+#### ClearableTransferRejected
+
+Must be emitted when a clearable transfer is executed.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+| reason | A reason given by the clearing agent why the transfer has been rejected |
+
+#### ClearableTransferCancelled
+
+Must be emitted when a clearable transfer is cancelled.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| operationId | The unique ID per orderer to identify the clearable transfer |
+
+#### AuthorizedClearableTransferOrderer
+
+Emitted when an operator has been approved to order transfers on behalf of another account.
+
+| Parameter | Description |
+| ---------|-------------|
+| orderer | The address to be an orderer of transfers |
+| account | Address on which behalf transfers will potentially be ordered |
+
+#### RevokedClearableTransferOrderer
+
+Emitted when an orderer has been revoked from ordering transfers on behalf of another account.
+
+| Parameter | Description |
+| ---------|-------------|
+| operator | The address to be a operator of holds |
+| account | Address on which behalf transfers could potentially be ordered |
 
 ## Rationale
 <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

From 8bee3151e7b80676c0967d3585c5d43fd15d4e67 Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Wed, 8 May 2019 14:37:47 +0200
Subject: [PATCH 03/11] renamed file

---
 EIPS/{eip-clearable.md => eip-draft_clearable.md} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename EIPS/{eip-clearable.md => eip-draft_clearable.md} (100%)

diff --git a/EIPS/eip-clearable.md b/EIPS/eip-draft_clearable.md
similarity index 100%
rename from EIPS/eip-clearable.md
rename to EIPS/eip-draft_clearable.md

From 19775bb4a093f8ca693ac52f6b75807bcd6ce2ac Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Thu, 9 May 2019 09:54:13 +0200
Subject: [PATCH 04/11] namin convetion from ERC777 for operators, small text
 changes

---
 .idea/iobuilders-eips.iml   |  9 ++++
 .idea/misc.xml              |  6 +++
 .idea/modules.xml           |  8 ++++
 .idea/vcs.xml               |  6 +++
 EIPS/eip-draft_clearable.md | 94 ++++++++++++++++++++++---------------
 5 files changed, 85 insertions(+), 38 deletions(-)
 create mode 100644 .idea/iobuilders-eips.iml
 create mode 100644 .idea/misc.xml
 create mode 100644 .idea/modules.xml
 create mode 100644 .idea/vcs.xml

diff --git a/.idea/iobuilders-eips.iml b/.idea/iobuilders-eips.iml
new file mode 100644
index 0000000000000..d6ebd4805981b
--- /dev/null
+++ b/.idea/iobuilders-eips.iml
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<module type="JAVA_MODULE" version="4">
+  <component name="NewModuleRootManager" inherit-compiler-output="true">
+    <exclude-output />
+    <content url="file://$MODULE_DIR$" />
+    <orderEntry type="inheritedJdk" />
+    <orderEntry type="sourceFolder" forTests="false" />
+  </component>
+</module>
\ No newline at end of file
diff --git a/.idea/misc.xml b/.idea/misc.xml
new file mode 100644
index 0000000000000..28a804d8932ab
--- /dev/null
+++ b/.idea/misc.xml
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="JavaScriptSettings">
+    <option name="languageLevel" value="ES6" />
+  </component>
+</project>
\ No newline at end of file
diff --git a/.idea/modules.xml b/.idea/modules.xml
new file mode 100644
index 0000000000000..76c6e7969f1cf
--- /dev/null
+++ b/.idea/modules.xml
@@ -0,0 +1,8 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="ProjectModuleManager">
+    <modules>
+      <module fileurl="file://$PROJECT_DIR$/.idea/iobuilders-eips.iml" filepath="$PROJECT_DIR$/.idea/iobuilders-eips.iml" />
+    </modules>
+  </component>
+</project>
\ No newline at end of file
diff --git a/.idea/vcs.xml b/.idea/vcs.xml
new file mode 100644
index 0000000000000..94a25f7f4cb41
--- /dev/null
+++ b/.idea/vcs.xml
@@ -0,0 +1,6 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<project version="4">
+  <component name="VcsDirectoryMappings">
+    <mapping directory="$PROJECT_DIR$" vcs="Git" />
+  </component>
+</project>
\ No newline at end of file
diff --git a/EIPS/eip-draft_clearable.md b/EIPS/eip-draft_clearable.md
index bdd467a5d4f95..3320d389d32c2 100644
--- a/EIPS/eip-draft_clearable.md
+++ b/EIPS/eip-draft_clearable.md
@@ -7,7 +7,7 @@ status: Draft
 type: Standards Track
 category: ERC
 created: 2019-04-30
-requires: 20
+requires: 1996
 ---
 
 <!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
@@ -15,7 +15,7 @@ requires: 20
 ## Simple Summary
 <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
 
-> "In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled." [[1]][Wikipedia] 
+> "In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled." [[1]][Clearing-Wikipedia] 
 
 ## Actors
 
@@ -32,20 +32,20 @@ The account which orders a clearable transfer. This can be the account owner its
 ## Abstract
 <!--A short (~200 word) description of the technical issue being addressed.-->
 
-The clearing process turns the promise of transfer into the actual movement of money from one account to another. A clearing agent decides if the transfer can be executed or not. The amount which should be transferred is not deducted on the balance of the 
+The clearing process turns the promise of a transfer into the actual movement of money from one account to another. A clearing agent decides if the transfer can be executed or not. The amount which should be transferred is not deducted from the balance of the payer, but neither is it available for another transfer and therefore ensures, that the execution of the transfer will be successful when it is executed.
 
 ## Motivation
 <!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
-The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.
+
+A regulated token needs to comply with all the legal requirements, especially [KYC][KYC-Wikipedia] and [AML][AML-Wikipedia]. Some of these checks may not be able to be done on-chain and therefore a transfer may not be completed in one step. Currently there is no EIP to make such off-chain checks possible. This proposal allows a user to order a transfer, which can be checked by a clearing agent off-chain. Depending on the result of it, the clearing agent will either execute or cancel the transfer. To provide more information why a transfer is cancelled, the clearing agent can add a reason why it is not executed.
 
 ## Specification
 <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 
 ```solidity
-interface ClearableToken /* is ERC-20 */ {
+interface ClearableToken /* is ERC-1996 */ {
     enum ClearableTransferStatusCode { Nonexistent, Ordered, InProcess, Executed, Rejected, Cancelled }
 
-
     function orderTransfer(string calldata operationId, address to, uint256 value) external returns (bool);
     function orderTransferFrom(string calldata operationId, address from, address to, uint256 value) external returns (bool);
     function cancelTransfer(string calldata operationId) external returns (bool);
@@ -54,17 +54,17 @@ interface ClearableToken /* is ERC-20 */ {
     function rejectClearableTransfer(address orderer, string calldata operationId, string calldata reason) external returns (bool);
     function retrieveClearableTransferData(address orderer, string calldata operationId) external view returns (address from, address to, uint256 value, ClearableTransferStatusCode status);
 
-    function authorizeClearableTransferOrderer(address orderer) external returns (bool);
-    function revokeClearableTransferOrderer(address orderer) external returns (bool);
-    function isClearableTransferOrdererFor(address orderer, address from) external view returns (bool);
+    function authorizeClearableTransferOperator(address operator) external returns (bool);
+    function revokeClearableTransferOperator(address operator) external returns (bool);
+    function isClearableTransferOperatorFor(address operator, address from) external view returns (bool);
 
     event ClearableTransferOrdered(address indexed orderer, string operationId, address indexed from, address indexed to, uint256 value);
     event ClearableTransferInProcess(address indexed orderer, string operationId);
     event ClearableTransferExecuted(address indexed orderer, string operationId);
     event ClearableTransferRejected(address indexed orderer, string operationId, string reason);
     event ClearableTransferCancelled(address indexed orderer, string operationId);
-    event AuthorizedClearableTransferOrderer(address indexed orderer, address indexed account);
-    event RevokedClearableTransferOrderer(address indexed orderer, address indexed account);
+    event AuthorizedClearableTransferOperator(address indexed operator, address indexed account);
+    event RevokedClearableTransferOperator(address indexed operator, address indexed account);
 }
 ```
 
@@ -72,7 +72,7 @@ interface ClearableToken /* is ERC-20 */ {
 
 #### orderTransfer
 
-Orders a clearable transfer on behalf of the msg.sender in favor of the payee. A clearing agent is responsible to either execute or reject the transfer.
+Orders a clearable transfer on behalf of the msg.sender in favor of `to`. A clearing agent is responsible to either execute or reject the transfer.
 
 | Parameter | Description |
 | ---------|-------------|
@@ -82,17 +82,18 @@ Orders a clearable transfer on behalf of the msg.sender in favor of the payee. A
 
 #### orderTransferFrom
 
-Orders a clearable transfer on behalf of the payer in favor of the payee. A clearing agent is responsible to either execute or reject the transfer.
+Orders a clearable transfer on behalf of the payer in favor of the `to`. A clearing agent is responsible to either execute or reject the transfer.
 
 | Parameter | Description |
 | ---------|-------------|
 | operationId | The unique ID per orderer to identify the clearable transfer |
+| from | The address of the payer, from whom the tokens are to be taken if executed |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
 | value | The amount to be transferred. Must be less or equal than the balance of the payer. |
 
 #### cancelTransfer
 
-Cancels the order of a clearable transfer. Only the orderer can cancel their own orders. It must not be successful as soon as it is in status `InProcess`.
+Cancels the order of a clearable transfer. Only the orderer can cancel their own orders. It must not be successful as soon as the transfer is in status `InProcess`.
 
 | Parameter | Description |
 | ---------|-------------|
@@ -100,7 +101,7 @@ Cancels the order of a clearable transfer. Only the orderer can cancel their own
 
 #### processClearableTransfer
 
-Sets a clearable transfer to status `InProcess`. Only a clearing agent can successfully execute this action.
+Sets a clearable transfer to status `InProcess`. Only a clearing agent can successfully execute this action. This status is optional, but without it the orderer can cancel the transfer at any time.
 
 | Parameter | Description |
 | ---------|-------------|
@@ -135,31 +136,40 @@ Retrieves all the information available for a particular clearable transfer.
 | orderer | The address which ordered the clearable transfer |
 | operationId | The unique ID per orderer to identify the clearable transfer |
 
-#### authorizeClearableTransferOrderer
+#### authorizeClearableTransferOperator
 
-Approves an orderer to order transfers on behalf of msg.sender.
+Approves an operator to order transfers on behalf of msg.sender.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be approved as orderer of transfers |
+| operator | The address to be approved as operator of clearable transfers |
 
-#### revokeClearableTransferOrderer
+#### revokeClearableTransferOperator
 
 Revokes the approval to order transfers on behalf of msg.sender.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be revokes as orderer of transfers |
+| operator | The address to be revoked as operator of clearable transfers |
 
-#### isClearableTransferOrdererFor
+#### isClearableTransferOperatorFor
 
-Returns if an orderer is approved to order transfers on behalf of `from`.
+Returns if an operator is approved to order transfers on behalf of `from`.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| operator | The address to be an operator of clearable transfers |
 | from | The address on which the holds would be created |
 
+#### transfer
+
+It is up to the implementer of the EIP if the `transfer` function of ERC-20 should always revert or is allowed under certain circumstances.
+
+#### transferFrom
+
+It is up to the implementer of the EIP if the `transferFrom` function of ERC-20 should always revert or is allowed under certain circumstances.
+
+
 ### Events
 
 #### ClearableTransferOrdered
@@ -168,7 +178,7 @@ Must be emitted when a clearable transfer is ordered.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| orderer | The address of the orderer of the transfer |
 | operationId | The unique ID per orderer to identify the clearable transfer |
 | from | The address of the payer, from whom the tokens are to be taken if executed |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
@@ -180,7 +190,7 @@ Must be emitted when a clearable transfer is put in status `ÌnProcess`.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| orderer | The address of the orderer of the transfer |
 | operationId | The unique ID per orderer to identify the clearable transfer |
 
 #### ClearableTransferExecuted
@@ -189,54 +199,59 @@ Must be emitted when a clearable transfer is executed.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| orderer | The address of the orderer of the transfer |
 | operationId | The unique ID per orderer to identify the clearable transfer |
 
 #### ClearableTransferRejected
 
-Must be emitted when a clearable transfer is executed.
+Must be emitted when a clearable transfer is rejected.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| orderer | The address of the orderer of the transfer |
 | operationId | The unique ID per orderer to identify the clearable transfer |
 | reason | A reason given by the clearing agent why the transfer has been rejected |
 
 #### ClearableTransferCancelled
 
-Must be emitted when a clearable transfer is cancelled.
+Must be emitted when a clearable transfer is cancelled by its orderer.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| orderer | The address of the orderer of the transfer |
 | operationId | The unique ID per orderer to identify the clearable transfer |
 
-#### AuthorizedClearableTransferOrderer
+#### AuthorizedClearableTransferOperator
 
 Emitted when an operator has been approved to order transfers on behalf of another account.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address to be an orderer of transfers |
+| operator | The address which has been approved as operator of clearable transfers |
 | account | Address on which behalf transfers will potentially be ordered |
 
-#### RevokedClearableTransferOrderer
+#### RevokedClearableTransferOperator
 
-Emitted when an orderer has been revoked from ordering transfers on behalf of another account.
+Emitted when an operator has been revoked from ordering transfers on behalf of another account.
 
 | Parameter | Description |
 | ---------|-------------|
-| operator | The address to be a operator of holds |
+| operator | The address which has been revoked as operator of clearable transfers |
 | account | Address on which behalf transfers could potentially be ordered |
 
 ## Rationale
 <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
-The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whos implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not.
+
+The operation id is unique per orderer to avoid collisions of it between different orderers.
+
+While not requiring it, the naming of the functions `authorizeClearableTransferOperator`, `revokeClearableTransferOperator` and `isClearableTransferOperatorFor` follows the naming convention of [ERC-777](https://eips.ethereum.org/EIPS/eip-777).
 
 ## Backwards Compatibility
 <!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
 
-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-1996.
 
 ## Implementation
 <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
@@ -248,4 +263,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 
 [1] https://en.wikipedia.org/wiki/Clearing_(finance)
 
-[Wikipedia]: https://en.wikipedia.org/wiki/Clearing_(finance)
+[Clearing-Wikipedia]: https://en.wikipedia.org/wiki/Clearing_(finance)
+[KYC-Wikipedia]: https://en.wikipedia.org/wiki/Know_your_customer
+[AML-Wikipedia]: https://en.wikipedia.org/wiki/Money_laundering#Anti-money_laundering
+[EIP-1996]: https://github.com/ethereum/EIPs/pull/1996

From 439139f6b8feb28f4344134733870d3ae5113ce3 Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Thu, 9 May 2019 09:55:56 +0200
Subject: [PATCH 05/11] removed .idea files

---
 .idea/iobuilders-eips.iml | 9 ---------
 .idea/misc.xml            | 6 ------
 .idea/modules.xml         | 8 --------
 .idea/vcs.xml             | 6 ------
 4 files changed, 29 deletions(-)
 delete mode 100644 .idea/iobuilders-eips.iml
 delete mode 100644 .idea/misc.xml
 delete mode 100644 .idea/modules.xml
 delete mode 100644 .idea/vcs.xml

diff --git a/.idea/iobuilders-eips.iml b/.idea/iobuilders-eips.iml
deleted file mode 100644
index d6ebd4805981b..0000000000000
--- a/.idea/iobuilders-eips.iml
+++ /dev/null
@@ -1,9 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<module type="JAVA_MODULE" version="4">
-  <component name="NewModuleRootManager" inherit-compiler-output="true">
-    <exclude-output />
-    <content url="file://$MODULE_DIR$" />
-    <orderEntry type="inheritedJdk" />
-    <orderEntry type="sourceFolder" forTests="false" />
-  </component>
-</module>
\ No newline at end of file
diff --git a/.idea/misc.xml b/.idea/misc.xml
deleted file mode 100644
index 28a804d8932ab..0000000000000
--- a/.idea/misc.xml
+++ /dev/null
@@ -1,6 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project version="4">
-  <component name="JavaScriptSettings">
-    <option name="languageLevel" value="ES6" />
-  </component>
-</project>
\ No newline at end of file
diff --git a/.idea/modules.xml b/.idea/modules.xml
deleted file mode 100644
index 76c6e7969f1cf..0000000000000
--- a/.idea/modules.xml
+++ /dev/null
@@ -1,8 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project version="4">
-  <component name="ProjectModuleManager">
-    <modules>
-      <module fileurl="file://$PROJECT_DIR$/.idea/iobuilders-eips.iml" filepath="$PROJECT_DIR$/.idea/iobuilders-eips.iml" />
-    </modules>
-  </component>
-</project>
\ No newline at end of file
diff --git a/.idea/vcs.xml b/.idea/vcs.xml
deleted file mode 100644
index 94a25f7f4cb41..0000000000000
--- a/.idea/vcs.xml
+++ /dev/null
@@ -1,6 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<project version="4">
-  <component name="VcsDirectoryMappings">
-    <mapping directory="$PROJECT_DIR$" vcs="Git" />
-  </component>
-</project>
\ No newline at end of file

From ed88a41c718d27a06b5bdc91056f681ddfd569af Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Mon, 13 May 2019 15:19:54 +0200
Subject: [PATCH 06/11] added eips number and contributors

---
 EIPS/{eip-draft_clearable.md => eip-2018.md} | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
 rename EIPS/{eip-draft_clearable.md => eip-2018.md} (98%)

diff --git a/EIPS/eip-draft_clearable.md b/EIPS/eip-2018.md
similarity index 98%
rename from EIPS/eip-draft_clearable.md
rename to EIPS/eip-2018.md
index 3320d389d32c2..c6abaee2b0ef2 100644
--- a/EIPS/eip-draft_clearable.md
+++ b/EIPS/eip-2018.md
@@ -1,5 +1,5 @@
 ---
-eip: <to be assigned>
+eip: 2018
 title: Clearable Token
 author: Daniel Lehrner <daniel@io.builders>
 discussions-to: https://github.com/IoBuilders/EIPs/pull/3
@@ -258,6 +258,9 @@ This EIP is fully backwards compatible as its implementation extends the functio
 
 The GitHub repository [IoBuilders/clearable-token](https://github.com/IoBuilders/clearable-token) contains the work in progress implementation.
 
+## Contributors
+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](https://creativecommons.org/publicdomain/zero/1.0/).
 

From 627328a1bbdc9e2f87a79a74244f25191ccf1c6a Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Thu, 6 Jun 2019 12:48:35 +0200
Subject: [PATCH 07/11] made operation id globally unique

---
 EIPS/eip-2018.md | 48 +++++++++++++++++++++++-------------------------
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md
index c6abaee2b0ef2..60e475e50c72e 100644
--- a/EIPS/eip-2018.md
+++ b/EIPS/eip-2018.md
@@ -1,8 +1,8 @@
 ---
 eip: 2018
 title: Clearable Token
-author: Daniel Lehrner <daniel@io.builders>
-discussions-to: https://github.com/IoBuilders/EIPs/pull/3
+author: Julio Faura <julio@adhara.io>, Fernando Paris <fer@io.builders>, Daniel Lehrner <daniel@io.builders>
+discussions-to: https://github.com/ethereum/EIPs/issues/2104
 status: Draft
 type: Standards Track
 category: ERC
@@ -49,10 +49,10 @@ interface ClearableToken /* is ERC-1996 */ {
     function orderTransfer(string calldata operationId, address to, uint256 value) external returns (bool);
     function orderTransferFrom(string calldata operationId, address from, address to, uint256 value) external returns (bool);
     function cancelTransfer(string calldata operationId) external returns (bool);
-    function processClearableTransfer(address orderer, string calldata operationId) external returns (bool);
-    function executeClearableTransfer(address orderer, string calldata operationId) external returns (bool);
-    function rejectClearableTransfer(address orderer, string calldata operationId, string calldata reason) external returns (bool);
-    function retrieveClearableTransferData(address orderer, string calldata operationId) external view returns (address from, address to, uint256 value, ClearableTransferStatusCode status);
+    function processClearableTransfer(string calldata operationId) external returns (bool);
+    function executeClearableTransfer(string calldata operationId) external returns (bool);
+    function rejectClearableTransfer(string calldata operationId, string calldata reason) external returns (bool);
+    function retrieveClearableTransferData(string calldata operationId) external view returns (address from, address to, uint256 value, ClearableTransferStatusCode status);
 
     function authorizeClearableTransferOperator(address operator) external returns (bool);
     function revokeClearableTransferOperator(address operator) external returns (bool);
@@ -72,21 +72,21 @@ interface ClearableToken /* is ERC-1996 */ {
 
 #### orderTransfer
 
-Orders a clearable transfer on behalf of the msg.sender in favor of `to`. A clearing agent is responsible to either execute or reject the transfer.
+Orders a clearable transfer on behalf of the msg.sender in favor of `to`. A clearing agent is responsible to either execute or reject the transfer. The function must revert if the operation ID has been used before.
 
 | Parameter | Description |
 | ---------|-------------|
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
 | value | The amount to be transferred. Must be less or equal than the balance of the payer. |
 
 #### orderTransferFrom
 
-Orders a clearable transfer on behalf of the payer in favor of the `to`. A clearing agent is responsible to either execute or reject the transfer.
+Orders a clearable transfer on behalf of the payer in favor of the `to`. A clearing agent is responsible to either execute or reject the transfer. The function must revert if the operation ID has been used before.
 
 | Parameter | Description |
 | ---------|-------------|
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 | from | The address of the payer, from whom the tokens are to be taken if executed |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
 | value | The amount to be transferred. Must be less or equal than the balance of the payer. |
@@ -97,7 +97,7 @@ Cancels the order of a clearable transfer. Only the orderer can cancel their own
 
 | Parameter | Description |
 | ---------|-------------|
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### processClearableTransfer
 
@@ -105,8 +105,7 @@ Sets a clearable transfer to status `InProcess`. Only a clearing agent can succe
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address which ordered the clearable transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### executeClearableTransfer
 
@@ -114,8 +113,7 @@ Executes a clearable transfer, which means that the tokens are transferred from
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address which ordered the clearable transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### rejectClearableTransfer
 
@@ -123,8 +121,7 @@ Rejects a clearable transfer, which means that the amount that is held is availa
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address which ordered the clearable transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 | reason | A reason given by the clearing agent why the transfer has been rejected |
 
 #### retrieveClearableTransferData
@@ -133,8 +130,7 @@ Retrieves all the information available for a particular clearable transfer.
 
 | Parameter | Description |
 | ---------|-------------|
-| orderer | The address which ordered the clearable transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### authorizeClearableTransferOperator
 
@@ -179,7 +175,7 @@ Must be emitted when a clearable transfer is ordered.
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address of the orderer of the transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 | from | The address of the payer, from whom the tokens are to be taken if executed |
 | to | The address of the payee, to whom the tokens are to be paid if executed |
 | value | The amount to be transferred if executed |
@@ -191,7 +187,7 @@ Must be emitted when a clearable transfer is put in status `ÌnProcess`.
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address of the orderer of the transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### ClearableTransferExecuted
 
@@ -200,7 +196,7 @@ Must be emitted when a clearable transfer is executed.
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address of the orderer of the transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### ClearableTransferRejected
 
@@ -209,7 +205,7 @@ Must be emitted when a clearable transfer is rejected.
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address of the orderer of the transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 | reason | A reason given by the clearing agent why the transfer has been rejected |
 
 #### ClearableTransferCancelled
@@ -219,7 +215,7 @@ Must be emitted when a clearable transfer is cancelled by its orderer.
 | Parameter | Description |
 | ---------|-------------|
 | orderer | The address of the orderer of the transfer |
-| operationId | The unique ID per orderer to identify the clearable transfer |
+| operationId | The unique ID to identify the clearable transfer |
 
 #### AuthorizedClearableTransferOperator
 
@@ -244,7 +240,9 @@ Emitted when an operator has been revoked from ordering transfers on behalf of a
 
 This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whos implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not.
 
-The operation id is unique per orderer to avoid collisions of it between different orderers.
+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.
 
 While not requiring it, the naming of the functions `authorizeClearableTransferOperator`, `revokeClearableTransferOperator` and `isClearableTransferOperatorFor` follows the naming convention of [ERC-777](https://eips.ethereum.org/EIPS/eip-777).
 

From e58c01e2f347f765c3d6646fd66323239d4fba0e Mon Sep 17 00:00:00 2001
From: Daniel Lehrner <daniel@io.builders>
Date: Tue, 16 Jul 2019 09:43:12 +0200
Subject: [PATCH 08/11] changed to reference implementation

---
 EIPS/eip-2018.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md
index 60e475e50c72e..87e29d18e2295 100644
--- a/EIPS/eip-2018.md
+++ b/EIPS/eip-2018.md
@@ -254,7 +254,7 @@ This EIP is fully backwards compatible as its implementation extends the functio
 ## Implementation
 <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
 
-The GitHub repository [IoBuilders/clearable-token](https://github.com/IoBuilders/clearable-token) contains the work in progress implementation.
+The GitHub repository [IoBuilders/clearable-token](https://github.com/IoBuilders/clearable-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 fc18e1ce8237cfdc75261ca274efd88fb0a77b60 Mon Sep 17 00:00:00 2001
From: Alex Beregszaszi <alex@rtfs.hu>
Date: Fri, 22 Nov 2019 22:43:46 +0000
Subject: [PATCH 09/11] Whitespace change to trigger rebuild.

---
 EIPS/eip-2018.md | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md
index 87e29d18e2295..b16fd7f74cb1d 100644
--- a/EIPS/eip-2018.md
+++ b/EIPS/eip-2018.md
@@ -10,10 +10,7 @@ created: 2019-04-30
 requires: 1996
 ---
 
-<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
-
 ## Simple Summary
-<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
 
 > "In banking and finance, clearing denotes all activities from the time a commitment is made for a transaction until it is settled." [[1]][Clearing-Wikipedia] 
 
@@ -30,17 +27,14 @@ An account which has been approved by an account to order clearable transfers on
 The account which orders a clearable transfer. This can be the account owner itself, or any account, which has been approved as an operator for the account.
 
 ## Abstract
-<!--A short (~200 word) description of the technical issue being addressed.-->
 
 The clearing process turns the promise of a transfer into the actual movement of money from one account to another. A clearing agent decides if the transfer can be executed or not. The amount which should be transferred is not deducted from the balance of the payer, but neither is it available for another transfer and therefore ensures, that the execution of the transfer will be successful when it is executed.
 
 ## Motivation
-<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
 
 A regulated token needs to comply with all the legal requirements, especially [KYC][KYC-Wikipedia] and [AML][AML-Wikipedia]. Some of these checks may not be able to be done on-chain and therefore a transfer may not be completed in one step. Currently there is no EIP to make such off-chain checks possible. This proposal allows a user to order a transfer, which can be checked by a clearing agent off-chain. Depending on the result of it, the clearing agent will either execute or cancel the transfer. To provide more information why a transfer is cancelled, the clearing agent can add a reason why it is not executed.
 
 ## Specification
-<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
 
 ```solidity
 interface ClearableToken /* is ERC-1996 */ {
@@ -236,7 +230,6 @@ Emitted when an operator has been revoked from ordering transfers on behalf of a
 | account | Address on which behalf transfers could potentially be ordered |
 
 ## Rationale
-<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
 
 This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whos implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not.
 
@@ -247,12 +240,10 @@ The `operationId` is a competitive resource. It is recommended, but not required
 While not requiring it, the naming of the functions `authorizeClearableTransferOperator`, `revokeClearableTransferOperator` and `isClearableTransferOperatorFor` follows the naming convention of [ERC-777](https://eips.ethereum.org/EIPS/eip-777).
 
 ## Backwards Compatibility
-<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
 
 This EIP is fully backwards compatible as its implementation extends the functionality of ERC-1996.
 
 ## Implementation
-<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
 
 The GitHub repository [IoBuilders/clearable-token](https://github.com/IoBuilders/clearable-token) contains the reference implementation.
 

From ad1787b234ac951089d1a7ccd75188acd8f87d5e Mon Sep 17 00:00:00 2001
From: Alex Beregszaszi <alex@rtfs.hu>
Date: Fri, 22 Nov 2019 22:44:38 +0000
Subject: [PATCH 10/11] Use canonical URL for EIP-1996.

---
 EIPS/eip-2018.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md
index b16fd7f74cb1d..c9b4d4ae8a0df 100644
--- a/EIPS/eip-2018.md
+++ b/EIPS/eip-2018.md
@@ -258,4 +258,4 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
 [Clearing-Wikipedia]: https://en.wikipedia.org/wiki/Clearing_(finance)
 [KYC-Wikipedia]: https://en.wikipedia.org/wiki/Know_your_customer
 [AML-Wikipedia]: https://en.wikipedia.org/wiki/Money_laundering#Anti-money_laundering
-[EIP-1996]: https://github.com/ethereum/EIPs/pull/1996
+[EIP-1996]: https://eips.ethereum.org/EIPS/eip-1996

From e96da4203f7a20fcce9bda6d9bf7befe3a658e89 Mon Sep 17 00:00:00 2001
From: Alex Beregszaszi <alex@rtfs.hu>
Date: Fri, 22 Nov 2019 22:48:16 +0000
Subject: [PATCH 11/11] Fix spelling typo.

---
 EIPS/eip-2018.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/EIPS/eip-2018.md b/EIPS/eip-2018.md
index c9b4d4ae8a0df..75d72ee2b3738 100644
--- a/EIPS/eip-2018.md
+++ b/EIPS/eip-2018.md
@@ -231,7 +231,7 @@ Emitted when an operator has been revoked from ordering transfers on behalf of a
 
 ## Rationale
 
-This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whos implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token or not.
+This EIP uses [EIP-1996][EIP-1996] to hold the money after a transfer is ordered. A clearing agent, whose implementation is not part of this proposal, acts as a predefined notary to decide if the transfer complies with the rules of the token 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.
 
@@ -241,7 +241,7 @@ While not requiring it, the naming of the functions `authorizeClearableTransferO
 
 ## Backwards Compatibility
 
-This EIP is fully backwards compatible as its implementation extends the functionality of ERC-1996.
+This EIP is fully backwards compatible as its implementation extends the functionality of [EIP-1996][EIP-1996].
 
 ## Implementation