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-1996: Holdable token #1996

Open
wants to merge 10 commits into
base: master
from

Conversation

@daniel-iobuilders
Copy link

commented May 6, 2019

An extension to the ERC-20 standard token that allows tokens to be put on hold. This guarantees a future transfer and makes the held tokens unavailable for transfer in the mean time. Holds are similar to escrows in that are firm and lead to final settlement.

A hold specifies a payer, a payee, a maximum amount, a notary and an expiration time. When the hold is created, the specified token balance from the payer is put on hold. A held balance cannot be transferred until the hold is either executed or released. The hold can only be executed by the notary, which triggers the transfer of the tokens from the payer to the payee. If a hold is released, either by the notary at any time, or by anyone after the expiration, no transfer is carried out and the amount is available again for the payer.

@daniel-iobuilders

This comment has been minimized.

Copy link
Author

commented May 8, 2019

@axic This is me first proposal, so I'm not exactly sure about the process.
The pipeline fails, but it seems only because the EIP does not have a number yet. It's says that the number will be assigned by an editor. Can you tell me how exactly this is going to happen?

@wighawag

This comment has been minimized.

Copy link
Contributor

commented May 8, 2019

@daniel-iobuilders
Since you created PR 1996 you can rename the file eip-1996.md and use 1996 as EIP number.

@daniel-iobuilders daniel-iobuilders changed the title Holdable token EIP-1996: Holdable token May 8, 2019

@daniel-iobuilders daniel-iobuilders force-pushed the IoBuilders:eip-holdable-token branch from 229f9c2 to 21fcb59 May 8, 2019

@daniel-iobuilders daniel-iobuilders force-pushed the IoBuilders:eip-holdable-token branch from 21fcb59 to 5c1217c May 8, 2019

daniel-iobuilders added some commits May 13, 2019

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

@kikoncuo

This comment has been minimized.

Copy link

commented May 28, 2019

A design question and a possible race condition problem which would allow the user to avoid paying any money on escrow.

  1. Design question: Why are we using string operationIds? This is usually the role of the transaction hash itself, it can be calculated on runtime, the format is not dependant on the user, would be a more standard identifier, and would require less parameters.

  2. Possible race condition: The user could monitor the mempool and whenever a notary calls executeHold, the user could call releaseHold with a higher fee, executing that transaction first and making the executeHold transaction fail. It's not clear to me why the user has this capability, maybe it makes more sense to limit it only after expiration.
    In your example, the user can safely avoid paying for the hotel, (Maybe this is an ok behaviour not exploitable in the real world).

This is a great step to create a bridge with traditional finance, thanks for your effort!

@daniel-iobuilders

This comment has been minimized.

Copy link
Author

commented Jun 4, 2019

@wighawag Are there any other steps to do, before this EIP can be merged?

@daniel-iobuilders

This comment has been minimized.

Copy link
Author

commented Jun 6, 2019

@kikoncuo

Regarding your points:

  1. The intention of the operation id is to allow easy traceability of the status of a hold by external (off chain) systems. Those systems should not need to know anything about the underlying blockchain technology, except that there are events to which they need to react to. While you are right, that this makes the EIP a bit more complex, we think the trade-off is worth it. I've added some explanations about this in the Rational part, to state our idea behind it.
  2. A user, the account who needs to pay if a hold is executed, can not release a hold. I have rewritten this part to make it clearer to the reader. After going over it I can see how this could have been misunderstood before.

Thank you for your feedback! The changes from it have been pushed already.

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