EIP-1996: Holdable token

[daniel-iobuilders]

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]

@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]

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

[kikoncuo]

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]

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

[daniel-iobuilders]

@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.