ERC-7573: Conditional-upon-Transfer-Decryption for Delivery-Versus-Payment

Oh and to somehow couple ERC-7573 and ERC-6123, it would also be easier to use int256 as transactionID type cause the ISDC.afterTransfer also uses uint256 as its transactionID so you could take advantage of this pattern.

1 Like

I could not answer all the aspects that were brought up here due to some overload. Sorry for that.

We made some minor updates to the ERC 7573 since its initial version. To summarize:

  • The ILockingContract now can now use a hashing for the key (instead of using the encrypted key). Hence, for any key K there will be a pair E(K), H(K). This concept was already described in the initial version of the paper, but the argument “encryptedKey” was re-used with the “hashedKey”. We added two separate argument. This also allows that the corresponding event emits the pair E(K), H(K).

  • The IDecryptionContract event TransferKeyReleased has an additional argument “sender”. In our white paper, we describe using multiple decryption oracles performing partial decryption (c.f. threshold encryption). To distinguish the different decryption oracles, the TransferKeyReleased event carries the additional argument “sender”.

  • Following Julius suggestion to change byte32 to uint256.

  • In the white paper we propose a key format and an implementation for the decryption oracle that ensures that only keys originating from eligible contracts are decrypted. In addition, we discuss the optional functionality that the decryption oracle can provide encrypted keys . By this, the users do not need to know any details of the encryption method. We elaborate on the aspect that the encryption oracle is a requirement originating from a fundamental property common to (most) blockchains: that argument values can be observed before code execution.

The contracts are available at “@finmath.net/dvp”: “0.3.1”

To some extend an off-chain decryption is a requirement that stems from a property that is common to (most) blockchains: That function arguments can be observed prior to function execution. For the DvP this results in a race condition. We tried to illustrate this in the white paper.