Locking is a Feature

In Delivery-versus-Payment (DvP) protocols like ERC-7573, at least one token must be locked to ensure atomicity, even if only for a short period during the transaction.

While locking may appear as an inconvenient necessity, it is in fact a feature that becomes valuable in the construction of conditional trades or multi-party DvPs.

If n parties wish to perform bilateral transactions atomically, there are at least m := 2 • (n - 1) transactions, of which m-1 require locking. The last one can operate directly, and its success or failure decides whether the other locks are released or reverted.

A multi-party delivery versus payment is a valuable trade feature. Consider, for example, the case where counterparty A wishes to buy a token Y (e.g., a bond) from counterparty C, but in order to fund this transaction, counterparty A wishes to sell a token X (e.g., another bond) to counterparty B. However, A does not want to sell bond X if the purchase of Y fails. A multi-party DvP allows these two transactions to be bound into a single atomic unit.

While for a two-party DvP with two tokens only one token requires locking—and hence a DvP can be constructed without locking on the cash chain—a three-party DvP with three tokens in general requires the ability to lock all three tokens.

This highlights that locking is not just a constraint, but a required feature to enable advanced and economically meaningful protocols.

The sequence diagram below shows a DvP between two contracts on two different chains, secured by an encrypted-hashed key. The key is generated by the key decryption oracle interally binding to the eligible contract. Upon successful transfer of the first token (e.g. delivery) it is conditionally decrypted allowing to unlock the other token (e.g. payment).

N-DvP with ERC-7573

A multi-party DvP can be created elegantly by combining multiple two-party DvPs, for example based on the ERC-7573 protocol.

The procedure is simple: instead of finalizing the respective two-party DvP by a call to transferAndDecrypt, the two-party DvP is first confirmed with a call to confirm, leaving the finalization open.

At any time, any party can call cancelAndDecrypt to release the failure key and revert all lockings.

Once all parties are linked with their respective two-party DvPs, a single call to transferAndDecrypt performs locking of the token implementing the IDecryptionContract and releases either the success key on success or the failure key on failure.