Hi team.
in view of the stringent regulations on smartcontracts and in general on the intermediation of cryptocurrency exchanges, @Eike Haß [IF] and I came up with the idea of proposing an atomic exchange (Swap) method for L1 tokens.
We discovered the idea had been discussed some time ago but then the it seems the L2 capabilities made it unnecessary. Now, however, it might make sense to revisit is because, in synthesis, it could guarantee atomic exchanges of different tokens between addresses of two (or more) users. It would then be an unmediated exchange that is not expected to be restricted by possible future legislation.
The fact that the exchange tx is atomic elevates the security of the exchange to the security of the entire L1, however, it does not prevent the creation of a business model similar to that of the nascent L2 DEXs.
Our addition to the previous discussion is that a Swap should optionally specify multiple receiving addresses and “token-types”.
This would for example allow to create some sort of “book service provider” (and even more than one) that lists all the swap txs not yet completed by an opposite tx. And including a fee to the address of the “book service provider” who, alerted by the presence of an incoming tx (confirmed only when the swap is completed) can publish the proposal. The proposal will be removed from the book once someone enters the opposite transaction and both are confirmed or a timeout has expired.
Another interesting use case I am studying is the use of atomic swap to send an NFT containing a receipt when a token payment is received (with the required toke and correct number).
This feature eliminates the administrative tasks required to handle the payment in the real world and reduces the risk of losing information about the incoming value (in tokens). One can easily connect the NFT to an ERP and subsequently the NFT can be burned.
This feature do not requeire changes to the protocol, but just add a new unlock condition similar to the Transfer of Funds with Expiration (Transfer of Funds with Expiration | Shimmer Wiki):
- A new Swap Output gets created with the desired payouts (amount, type, target) specified → this concludes a valid TX
- Alice discovers the Swap Output, consumes it in a transaction including all specified payouts (similar to the non-expired claim (Transfer of Funds with Expiration | Shimmer Wiki) but with the payout Outputs on the Outputs side) → this concludes a valid TX
- Eve also discovers (the now outdated/consumed) Swap Output and tries to consume it in a transaction including all specified payouts on the Outputs side → the transaction will not validate as the Swap Output was already consumed, the payouts will not be created, no tokens are “lost”