Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-2009: Compliance Service #2009

Open
wants to merge 4 commits into
base: master
from

Conversation

@daniel-iobuilders
Copy link

commented May 10, 2019

This EIP proposes a service for decentralized compliance checks for regulated tokens.

A regulated token needs to comply with several legal requirements, especially KYC and AML. If the necessary checks have to be made off-chain the token transfer becomes centralized. Further the transfer in this case takes longer to complete as it can not be done in one transaction, but requires a second confirmation step. The goal of this proposal is to make this second step unnecessary by providing a service for compliance checks.

@daniel-iobuilders daniel-iobuilders changed the title EIP Compliance Service EIP-2009: Compliance Service May 13, 2019

@kikoncuo

This comment has been minimized.

Copy link

commented May 28, 2019

Eip-1462 does something very similar and provides a reference implementation, the difference is that you can't skip those checks, with the proposed system I think you could.

This implementation acts as a layer on top of other tokens but all functions from the original token are not affected by this, so any regular token (ERC20 233 777 etc) can skip all of the checks by calling directly the transfer like functions underneath and therefore skipping/making optional all AML and KYC processes.

@daniel-iobuilders

This comment has been minimized.

Copy link
Author

commented May 29, 2019

@kikoncuo
We mentioned EIP-1462 in the motivation part and as you said, see this proposal as an additional layer on top of something like it and not as a replacement for it.
This EIP is really meant as a service, so yes a token implementer can decide to use everything, only parts of it or of course could add additional checks in their token implementation. The other aspect is that a third-party (e.g. a government) could take care of maintaining KYC / AML rules and not every token implementer would need to implement or maintain those over and over again themself.

@kikoncuo

This comment has been minimized.

Copy link

commented May 29, 2019

I get it now, traditional tokens are not meant to be compatible with this, functionality is very similar to EIP-1462 but works as a deployed contract which other contracts can use. The main difference I see is gas cost:

  1. You can save a lot of gas on deployment of the token contract vs using EIP-1462 (if the service is already deployed).
  2. Transactions to the smart contract will be a bit more expensive than using EIP-1462 (Because of the packing and unpacking of the request to an external contract).

It would be fairly interesting to see the exact gas difference, but my feeling is that you will be saving so much on the deployment and spending so little extra per transaction that this system would be efficient for a long time.

Bests,
E

@llcarr77

This comment has been minimized.

Copy link

commented May 29, 2019

@axic axic added the type: ERC label Jun 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.