Trustless Exchange of Native Assets

[lzpap]

Trustless Exchange of Native Assets

With the Tokenization & Smart Contract update of the chrysalis protocol IOTA becomes a multi-asset ledger with configurable outputs.

There are two kinds of native assets that may live in the ledger:

• Native tokens: tokens that are minted/burned via foundries. They are represented as native token balances in any outputs.
• Non-Fungible Tokens (NFTs): unique tokens with attached metadata represented by NFT Outputs in the ledger.

Both assets might be owned by user wallets on L1, or they can be deposited into smart contract chains (L2) for example to be traded on decentralized exchanges or marketplaces.

How can one exchange such assets with other parties? What mechanisms are needed on protocol level or what higher layer tools are required for trustless asset exchange?

Swaps

Swaps are trustless exchanges of digital assets and cryptocurrencies that are agreed upon by both parties.

The atomicity of the swap mechanism ensures that either both parties receive their intended assets or none of them, hence the trustless nature.

Depending on the swap mechanism, parties might need to establish off-chain communication and engage in a cooperative process to carry out the swap. In such cases an additional trusted communication medium has to be in place.

A distinction has to be made based on the assets to be exchanged:

• On-chain, or on-ledger swapping means exchange of assets that reside in the same ledger. Swapping two IOTA native tokens is an on-chain swap because both tokens are tracked inside the IOTA ledger.
• Cross-chain swapping means exchange of assets that reside in different ledger, on different chains. Swapping IOTA coins to ETH coins is a cross-chain swap.

Atomic Cross-Chain Swaps

To carry out cross-chain swaps one has to have access to both ledgers, and those ledgers must support a set of technical features to make swaps possible.

Hash Time Locked Contracts

One way to do it is to support the same hash function in both protocols that provide hashlocks, furthermore timelocks need to be available as well. In other words, both protocols must support Hash Time Locked Contracts (HTLCs).

The process of Alice and Bob performing a cross-chain atomic swap is illustrated below:

src: https://hackernoon.com/making-mast-meaningful-bitcoin-atomic-swaps-become-private-ff003f7c2b7a

1. Alice comes up with a secret X.
2. Alice locks her coins on Blockchain Y. The funds can be unlocked by either Bob's signature and the secret X value, or by Alice's signature if enough time passes.
3. Bob locks his coins on Blockchain W. The funds can be unlocked by either Alice's signature and the secret X, or by Bob's signature if enough time passes.
4. Alice unlocks funds on Blockchain W with her signature and the secret key. In the process, she has to reveal X.
5. Bob monitors Blockchain W and acquires secret X because Alice had to reveal it. He can now spend the funds on Blockchain Y.

Schnorr Adaptor Signatures

An alternative to hashlocks is Schnorr signatures which reduce the transaction footprint and increase privacy. The method makes use of the additive nature of Schnorr signatures.

The technical details are rather complicated, on a high level, the secret X is part of the multisignature address generation process. The protocol doesn't need to care about it, an atomic swap transaction looks like a normal transaction and is pretty lightweight on the protocol.

Conclusion

Regardless of the method chosen, parties do have to communicate off-chain, exchange addresses and secrets, while they also have to monitor both blockchains for transactions.

As a consequence, centralized bridge solutions emerged that are not trustless but offload these duties from users, trading security for convenience. Must crypto users do not seem to care.

The current IOTA protocol supports the Ed25519 signature scheme, which uses a variant of Schnorr signatures based on Curve25519. As such, cross-chain atomic swaps using adaptor signatures could already be performed directly from L1 as long as the counterparty supports the same signature scheme. Additionally, HTLCs are planned to be supported in the future.

On-Chain Swaps

On-chain swaps happen on the same ledger, which simplifies the procedure as multi-ledger access is not required. Only assets that are residing on the same network can be the subject to on-chain swapping.

Requirements of on-chain swaps:

• Swapping parties do not have to trust each other.
• Exchange of the assets is atomic, meaning that either both parties receive their intended assets or none of them.

Let's explore the different approaches that might be possible for on-chain swaps on IOTA.

Scenario: Alice has 10 AliceToken that she wants to swap for Bob's 15 BobToken.

1. P2P Off-Ledger Transaction Creation

Even if Alice and Bob do not trust each other, they can participate in the interactive off-chain process of constructing a transaction together, also called CoinJoin. They need to have a communication channel between them to facilitate the process:

1. Alice and Bob exchange information on who wants to swap what. For example Alice wants to swap her 10 AliceToken to Bob's 15 BobToken.
2. Bob shares with Alice the ID of his output that holds 15 BobToken and also his address.
3. Alice constructs a transaction with the following inputs:
   • Input#1: 10 AliceToken locked to Alice's address
   • Input#2: 15 BobToken output locked to Bob's address
     and the following outputs:
   • Output#1: 10 AliceToken output locked to Bob's address
   • Output#2: 15 BobToken output locked to Alice's address
4. Alice creates the unlock block for Input#1 using a valid signature.
5. Alice sends the partially signed transaction to Bob.
6. Bob creates the unlock block for Input#2. If he were to change anything in the transaction, Alice's signature would be invalidated.
7. Bob submits the transaction to the network.

Pros

• Works with the current protocol version. (Chrysalis Pt 2)
• Atomicity of swap is guaranteed.
• Either party might terminate the process by stopping the collaboration.
• Feeless on IOTA L1.

Cons

• Alice and Bob need to have a communication channel.
• Requires input and cooperation from both parties.

2. Hash Time Locked Contracts

The same process that was described above for cross-chain atomic swaps can be applied to on-chain atomic swaps. Alice and Bob need to have a communication medium to share addresses and hashed secrets, furthermore the protocol needs to support HTLCs.

Pros

• Atomicity of swap is guaranteed.
• Either party might terminate the process by stopping the collaboration.
• Feeless on IOTA L1.

Cons

• Alice and Bob need to have a communication channel.
• Alice and Bob need to monitor the ledger for outputs/transactions.
• Needs special HTLC support from the protocol.
• Complex two-party computation requiring multiple rounds.

3. Schnorr Adaptor Signatures

Instead of relying on HTLCs, Schnorr signatures provide another way to do on-chain atomic swaps. Still, there has to be an off-chain communication channel between the parties, but it is more lightweight on the protocol and preserves the privacy of the swapping parties.

Pros

• Works with the upcoming (Tokenization & SC) upgrade of the protocol.
• Atomicity of swap is guaranteed.
• Either party might terminate the process by stopping the collaboration.
• Lightweight on the protocol.
• Enhanced privacy.
• Feeless on IOTA L1.

Cons

• Alice and Bob need to have a communication channel.
• Complex two-party computation requiring multiple rounds.

4. Payment Channels

IOTA's version of bitcoin's Lightning Network was Flash Channels. These are off-chain payment channels that make it possible for parties to transact off-chain with high frequency. Such a payment channel can be opened by depositing funds to a multisignature address, generated by the participating parties. A second layer cryptography protocol is employed to carry out off-chain transactions, and when closing the channel, submitting the settlement transaction to the network.

Flash Channels are not supported any more since the Chrysalis Pt2 update, but it should be possible to revive them.

Pros

• Atomicity of swap is guaranteed.
• Either party might terminate the process by stopping the collaboration.
• Lightweight on the protocol, only opening and closing transactions are published.
• Feeless on IOTA L1.

Cons

• Alice and Bob need to have a communication channel.
• A L2 protocol needs to be developed for carrying out the off-chain transacting.
• Complex two-party computation requiring multiple rounds.

5. L2 Smart Contracts

Alice and Bob can ease the process and get rid of the necessary communication layer by relying on a L2 smart contract.

They both deposit their to-be-swapped assets into a smart contract chain, and call a smart contract to offer a swap. Upon this call, they can specify the conditions of the swap (price, expiry, etc.). The other party will query the smart contract for available swap offers and if there is one that they wish to enter, they just call the accept offer endpoint of the contract with needed funds and parameters to carry on with the execution of the swap.

Once the smart contract reallocates the ownership of assets, both Alice and Bob can withdraw them to their L1 wallets.

Pros

• Doesn't need special support from the L1 protocol, just a functioning L2 smart contract.
• Atomicity of swap is guaranteed.
• Does not require a separate communication channel.
• Swap offers submitted to the smart contract can be canceled any time.

Cons

• Smart contract calls might incur transaction fees.
• The smart contract chain/validators need to be trusted

Smart contracts also enable more advanced use cases of the same logic, for example DEXs and AMMs that pool offers and hence provide liquidity and market making.

6. L1 Output Feature Block

With the introduction of new output types and feature blocks, behavior of certain outputs can be programmed. Spending constraints can be embedded in outputs, for example timelock, expiry or dust return conditions.

What they all essentially do is to tie the spending of the output to some conditions defined on the spending transaction that defines their context. This context can record for example the original sender of the output too, making it possible to define spending conditions in relation to the sender's address.

The dust return feature is one example: When Alice wants to send native tokens to Bob, she can only create an output to Bob's address that also contains some dust deposit. Therefore, simply sending the native tokens with an output means that Alice loses ownership of the dust deposit, since the created output now belongs to Bob. In order not to loose those coins, Alice can define a dust return condition on the output: whenever Bob consumes this output, he will have to create an output that sends back the dust deposit to Alice. If Alice wants to get back the dust deposit in reasonable time, she also puts an expiry block on the output and states: if Bob doesn't consume this output in 1 hour, ownership of the output is transferred back to her.

The basic idea of swapping directly on L1 with output feature blocks follows the same logic, but the details should be carefully designed.

Swapping without smart contracts on L1 means that the actual swap is always required to have at least 2 parties both agreeing to the swap. There is no market maker entity who coordinates the activity of the involved parties, swapping on L1 requires user interaction.

6.1 Targeted Swap with L1 Outputs

Alice has 10 AliceCoins which she wants to swap for 15 BobCoins. She knows Bob has BobCoins.

• She creates an output with Dust Deposit + 10 AliceCoins underAliceAddress.
• She specifies in the swap feature block, that this output can only be spent by BobAddress in a transaction that deposits Dust Deposit + 15 BobCoins to AliceAddress
• Bob's wallet receives Alice's output (swap offer) as it is mapped to BobAddress by nodes.
• Bob may accept the offer by consuming the output in a transaction that deposits Dust Deposit + 15 BobCoins to AliceAddress. He can take the 10 AliceCoins present in the consumed output and transfer it to an address of his choice.

Pros

• Alice only needs to know Bob's address.
• The output can only be spent by either Alice or Bob.
• Alice can cancel the offer by consuming the output with her signature, which lifts the spending constraint.
• Alice can put an expiration time on the output so that after a certain time, only she can consume the output.
• Atomicity of swap is guaranteed.
• Feeless on IOTA L1.

Cons

• More complex output validation logic with swap feature blocks.
• The ownership of the output is non-deterministic from the protocol point of view: At a given point in time, the output might be consumed by Alice or by Bob. This can lead to race conditions and double spends, which have to be resolved by the consensus. The conflicts will be ordered during White-flag processing, so if either party sees the other's spend, they could construct a transaction which precedes the spend in the White Flag ordering.
• The previous point introduces an attack vector for smart contract chains processing such outputs: an attacker might force the chain to produce invalid double spends in the chain anchor transaction, which results in chain reorg and denial of service.
• Alice might expect non-existing assets in return for AliceCoins. Bob then has no way to complete the swap, but the output is still mapped to his address, therefore it will be fetched by Bob's wallet when querying for outputs. Since node APIs have a hard limit on the number of returned outputs (1000 atm), Alice can DoS Bob's address with unspendable outputs so that he can not fetch other outputs truly belonging to him.
• The root cause of the previous problem is that the Tangle is not only a ledger, it is also an indexing (Address -> Output) mechanism to fetch the content of the ledger for clients. If one can create such indexes indefinitely without losing money, anyone’s address can be attacked. Previously, such indexing can only be created when an output was sent to a new address, so that the sender loses control of the funds. With spending constraints and swap feature blocks, it is not true anymore.

6.2 Open Swap with L1 Outputs

Alice has 10 AliceCoins which she wants to swap for 10 BobCoins. She doesn't know who has BobCoins.

• She creates an output with Dust Deposit + 10 AliceCoins under AliceAddress.
• She specifies in the swap feature block, that this output can only be spent in a transaction that deposits Dust Deposit + 10 BobCoins to AliceAddress.
• Whoever owns 10 BobCoins and is willing to swap them for 10 AliceCoins can include and unlock this output in a transaction that deposits the needed assets to AliceAddress.

Pros

• Alice doesn't need to know who will be the other party in the swap.
• Whoever fulfills the swap offer doesn't have to provide a signature to unlock the output, only has to fund the transaction with enough funds and deposit the needed tokens.
• Alice can cancel the offer by consuming the output with her signature, which lifts the spending constraint.
• Alice can put an expiration time on the output so that after a certain time, only she can consume the output.
• Atomicity of swap is guaranteed.
• Feeless on IOTA L1.

Cons

• Non-deterministic output ownership: the swap offer output can be consumed by anyone. Leads to race conditions on whose spend is the first in the White Flag ordering during confirmation.
• Such swap offers can not be fulfilled by smart contract chains. If an output can be unlocked by multiple parties at the same time, it means that its ownership is not deterministic. It can be Alice, Bob or the chain who actually owns it: it depends on who unlocks it first. This is terrible for smart contract chains, as there is no guarantee of request determinism and possibly results in the chain producing invalid state updates and hence rollbacks.
• How do other parties know that such a swap offer exists? Alice would have to share the output ID off-chain with interested parties.

6.3 General Observations

The Option to Cancel

The option to cancel a swap seems to be a convenience feature for user experience. However, it immediately introduces non-deterministic output ownership which might lead to race conditions during confirmation and attacks against smart contract chains.

Note, that in IOTA we can not cancel a pending transaction by "reverting it". In Ethereum for example, it is possible to cancel a pending transaction if it is only in the mempool and hasn't been added to a block yet: you just send a transaction with the same nonce but higher fees. In IOTA, as soon as the transaction is sent to the Tangle, the only way to "revert it" is to introduce a double spend before confirmation happens. Since confirmation times are orders of magnitude faster than in Ethereum, it gives just a very small time window (~10s) and the double spend also needs to come first in the White Flag ordering.

Layer 2 approaches (1-5) which are built on top of L1 however may implement the option to cancel without introducing race conditions on L1.

Open Ended Swaps

When the other party of the swap is not known or irrelevant, the protocol must allow non-deterministic output ownership which leads to aforementioned problems.

From a practical point of view, the one creating an open ended swap also has to make sure to disseminate the availability of it to interested parties unless relying on a trusted third party to monitor the Tangle for such swaps.

6.4 Swap Feature Block Solution

In order not to cause problems, the swap output feature block must avoid:

• non-deterministic output ownership
• DoS attacks on user wallets.

Therefore, a swap feature block on L1:

• must be a targeted swap,
• can not be cancelable,
• must not be able to DoS the receiver's wallet.

The simple design is as follows:

Targeted Swap Block

Defines a targeted swap offer to the Address of the output.

Name	Type	Description
Block Type	uint8	Set to value 4 to denote a Targeted Swap Block.
Swap Amount	uint64	Amount of IOTA coins the consuming transaction should deposit to the Sender of the output.
Swap Native Tokens Count	uint8	The number of native tokens and their balance the party fulfilling the swap has to deposit to the Sender of the output.
Swap Native Tokens optAnyOf	Native Token Name Type Description Token ID ByteArray[38] Identifier of the native token. Derivation defined here. Amount uint256 Amount of tokens.
Swap Native NFTs Count	uint8	The number of NFTs the party fulfilling the swap has to deposit to the Sender of the output.
Swap NFTs optAnyOf	NFT Address Name Type Description Address Type uint8 Set to value 16 to denote an NFT Address. Address ByteArray[20] The raw bytes of the nft address which is a BLAKE2b-160 hash of the outputID that created it.

Additional Syntactic Transaction Validation Rules

• Swap Amount + Swap Native Tokens Count + Swap Native NFTs Count must be > 0.
• Swap Native Tokens Count must not be greater than Max Native Token Count.
• Swap Native NFTs Count must not be greater than Max Outputs Count.
• An output that contains a Targeted Swap Block must have a Sender Block defined.

Additional Semantic Transaction Validation Rules

• If the embedding output is unlocked with respect to Sender, the Targeted Swap Block is always valid. (Such an unlock can only be valid when an Expiration Block is present.)
• If the embedding output is unlocked with respect to Address, the Targeted Swap Block is valid if and only if the transaction deposits Swap Amount of IOTA coins, all Swap Native Tokens of their corresponding amounts, and all Swap NFTs to the output's Sender address. The deposit outputs must not contain any feature blocks that implement spending restrictions (dust return, timelocks, expiry, swap blocks, etc.).
• If a transaction unlocks multiple outputs each containing a Targeted Swap Block with the same Sender field, all their Swamp Amount, Swap Native Tokens and Swap NFTs values are summed up and the transaction must deposit at least those sums to the Sender address.

Additional Ideas

• An Expiration Block in combination with the swap feature makes it possible to limit the time the recipient has to agree to the swap.
• The Address (recipient) field of the output shall not be added to the general Address -> Output LUT in nodes if the output contains a swap block.
• The Address (recipient) field of the output could be mapped in a separate LUT, which is exposed only under a different API endpoint. Of course this endpoint has the same DoS problems, but at least it is isolated to swap offers and doesn't affect regular outputs.
• The Address (recipient) field of the output could be unmapped, leaving it up to off-chain communication or third party service to index it for the recipient.

Conclusion

Several ways have been shown how to facilitate trustless exchange of digital assets, on-chain and cross-chain.

Both have their pros and cons for the protocol and user experience. While the latter can be greatly enhanced by layer 2 applications built on top of the protocol, the former needs to be handled with utmost importance.

L1 is great for executing payments, but less suited as a communication channel or data indexing layer for clients. It is not the job of the core protocol to implement unattackable indexing for client side applications. A prime example of this is Cardano L1 smart contracts, where outputs are only indexed by script hashes. Unless a client knows the pre-image of the hash, it is impossible to find out who owns such an output and what one can do with it.

IOTA Smart Contracts on the other hand is a layer 2 solution where any application logic can be coded and also be exposed from smart contracts to clients. It is a good alternative to implement swaps, as any swapping logic can be programmed on it. DEXes, as a generalization of the swapping feature, can also run on ISC. Then users don't even need to bother to find another party, the automated market making mechanisms will execute the swap.

Of course the downside is that smart contracts might incur transaction fees on L2.

Feeless layer 1 swaps are only possible if the parties do have some off-chain communication method or use a trusted third party service for this purpose.

Questions

• What do you think, which approach(es) IOTA should follow to enable swaps and why?
• Do you have other ideas that work well for the protocol? How do you get around the non-deterministic output ownership and the indexing problem?
• Would you rely on a trusted third party to aggregate L1 swaps for clients or would you rather pay a small fee for market making with smart contracts?
• Would it be possible to integrate an off-chain communication method into Firefly so that the L2 approaches (1-5) can be implemented directly in the wallet?

[WillHawkMuc]

With needing an off-chain communication method being a common downside for the L1 scenarios - wouldn't IOTA Streams be the communication method of choice for these scenarios?

[Wollac]

Yes, you can always use encrypted on-tangle messages, i.e. Streams, instead of a dedicated separate network connection. That is equivalent.
What might actually be preferable depends on your particular use-case: Whether you prefer communicating over the Tangle or a faster direct p2p communication.

[lukastanisic99]

What's the reason of having to specify Bob's address? You can specify the token you want as the condition and anyone can unlock the UTXO.
Example:
Alice has 10 AliceTokens
She wants 20 IOTA tokens

She creates a UTXO that anyone can consume. Someone consumes Alices's UTXO with 20 IOTA tokens which would go to Alice's address and they'd get 10 AliceTokens. This would happen atomically (either the swap fully happened or it didn't).
Alice can of course cancel the swap by consuming her own UTXO.

Race condition can happen (multiple parties want to consume the same UTXO), but under OTV (Multiverse) there would always exist a winner.

This allows for a L1 DEX to be formed without any communication. Parties can use a plugin to query the Tangle for UTXO that can be consumed and an efficient market could be formed. This would all be trustless and feeless.

[lukastanisic99]

Ah sorry I didn't see 6.2 this is covered already! Great

[hmoog]

Another option would be to implement an AMM style liquidity pool on L1 in the form of an output type.

This would most probably be the most flexible and powerful option as it would ensure the ability to "always" find a trading partner.

[lukastanisic99]

Yes that would assure that a trade is always possible, but AMMs cannot be feeless. No one wants to provide liquidity for free. Regardless, it's a worthy option to have.

[hmoog]

That is a true, AMMs can not be feeless because you need to incentivize the liquidity providers with the rewards but I think thats fine as that is part of the pool specification and the fees are not "base layer fees".

[lukastanisic99]

Another thing is that you can't really parallelize a liquidity pool. You need the liquidity to stay concentrated so all funds would be in a single UTXO. There would be a lot of race condition and most users probably wouldn't have a good experience. Where with the open atomic swap (6.2) you can have many UTXOs for the same trading pair and all those UTXOs can be consumed at the same time. If a user can't get his 'taker' order to execute he can create a maker order (creates a new UTXO) and someone will probably consume it. I think AMMs make more sense on account based ledgers and the 6.2 proposal for UTXO based ledgers. But the AMM is too possible with UTXO I just don't know how popular will it be when you'll need to pay fees and it's harder to parallelize.

[sdellava]

I would like to reopen this discussion with particular reference to Section 6.2 "Open Swap with L1 Outputs."
I think that evolutions that have been introduced in the protocol now make it more practical and easier to implement this functionality.

In fact, I think that the L2 technology is now widely developed and therefore there is no conflict with an atomic swap functionality on L1.

I would like to propose only one change to the Targeted Swap Block: it must be possible to specify more than one output address.

This is one possible use case:

• Bob wants to swap N tokens T1 of his address BOBADD1 for M tokens T2, and he wants this swap to occur within the next 10 minutes at most
• Bob also wants to donate K token T3 to address INFOADD from his BOBADD2, if the transaction is confirmed

In parallel Alice wants to do the reverse operation, so she enters a transaction that:

• sends M token T2 from her address ALICEADD1 to adress BOBADD1

The transaction is confirmed, so the address ALICEADD1 contains N tokens T1, address BOBADD1 contains M tokens T2, and the address INFOADD contains K tokens T3

The transaction is deterministic, i.e., it is confirmed if the amounts and the destination address given by Alice is BOBADD1, and the transaction is entered within the time limit given by BOB.

Conflict
What happens if Alice and Marta enter the same tx in paeallel?
Nothing in particular. It is a conflict that the protocol will handle by finding consensus on which of the two is the one to be confirmed.

Compatibility with L2
This type of Unlock tx output is not usable by L2, but this has no adverse effect. L2 applications will be able to use the tokens moved to L1 after the unlock condition is completed.

How does Alice know that BOB has entered a transaction of her interest?
Adding an additional output to the swap transaction makes it possible to create a simple monitor on the INFOADD address that is used as an "annouce channel."
The owner of the address is not directly involved in the token swap, but provides a service to all potential peers, somewhat like Bloombergs does for those who invest in the stock market, distributing the contents of financial market books.

Another interesting use case is the NFT exchange.
In this case:

• Bob wants to exchange uo NFT A for M token T1 and wants this exchange to take place within the next 10 minutes at most.
• Bob also wants to donate K token T2 to the INFO1 address, if the transaction is confirmed

The information that the NFT is for sale will be posted on a site or in an RSS information channel by the owner of the INFOADD address

[sdellava]

Yes, one can certainly write an INX-plug in that exposes REST APIs that can be used by apps/web apps to "react" to the insertion of an interesting proposal by issuing a coincident exchange transaction.

But the simplest solution for human users is to build a simple web page that displays all unspent txs that reference the ( in the example) INFOADD address

Clicking on the humanly displayed tx that illustrates the proposed exchange activates Firefly (IOTA Links), which sets up the correct transaction.

This approach would be ideal especially for exchanging/buying NFTs.

Of course, there is a risk that such a web site could be fake, inducing users to make nonexistent swaps by sending their tokens to an address without getting anything in return.

To avoid this risk, instead of the destination address, Firefly can receive the id of the swap tx and autonomously build the transaction proposal, which the user must then confirm.

[sdellava]

Update: Using the link to create a tx in Firefly made me notice that there is another risk to avoid. If Alice does not realize that the swap tx entered by Bob has already been spent (thus confirmed), her tx may still be confirmed but she will not receive Bob's tokens, which have already been sent elsewhere.

So, the rules for unlocking and confirming the two TXs need to be revised in this way:

Bob posts a tx, which we call BOBTX, to swap N T1 tokens from his BOBADD1 address for M T2 tokens, and he wants the swap to be completed in a maximum time of T minutes.

• Bob's transaction remains pending until an other transaction is created that sends M T2 tokens to his address BOBADD1, or the timout T expires.
• If the timout expires the tx can no longer be confirmed.

Alice sees BOB's tx and decides to enter a tx, which we call ALICETX, that sends M T2 tokens from its address ALICEADD1 to address BOBADD1.

- ALICETX is valid and can be confirmed only if the BOBTX input has not already been spent.

[eike-hass]

If Alice does not realize that the swap tx entered by Bob has already been spent (thus confirmed), her tx may still be confirmed

I believe this is a non-issue. The Swap is represented as an Output, an Output can only be consumed once. If an old listing exists somewhere and Alice tries to consume the Output it will fail as it is spend already.
If two parties at the very same time try to consume the un-spend Output the consensus will guarantee only one of the transactions (including payouts) will go through. This is what makes it truly atomic.

[sdellava]

This means that ALICETX must include BOBADD1 as input and move N T1 tokens.

So the rules change to:

• Bob sends a transaction, BOBTX, to exchange N T1 tokens from his BOBADD1 address for M T2 tokens, to be completed in a T timeout.
• The BOBTX transaction remains pending until either another transaction sends M T2 tokens to BOBADD1, or until timeout T expires.
• Alice sees BOB's tx and inserts a tx, ALICETX, which moves M T2 token from its address ALICEADD1 to its address BOBADD1 and N T1 token from BOBADD1 to its ALICEADD1.
• Both txes are valid and confirmed if their inputs have not been previously spent and if timout T has not expired.

[eike-hass]

Consider the Transfer of Funds with Expiration as a starting point:

1. A new Swap Output gets created with the desired payouts (amount, type, target) specified -> this concludes a valid TX
2. Alice discovers the Swap Output, consumes it in a transaction including all specified payouts (similar to the non-expired claim but with the payout Outputs on the Outputs side) -> this concludes a valid TX
3. 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"

[sdellava]

Always thinking about upcoming legislation, this new network feature could support another important upcoming regulation: the digital sales receipt.

The sales receipt, issued by companies selling services or products to individuals, is not mandatory in all countries of the European Union, but where it is required, ways to make it digital (while also saving a lot of paper) are being discussed.

The issue is debated because it impacts privacy: with a traditional approach (already in use for digital invoicing) all receipts would be sent to a central system that would then learn about every expenditure made by the private citizen.

One possible solution is to create an NFT containing the digital version of the receipt, encrypted with the customer's public key. This NFT would be exchanged atomically upon receipt of payment (in tokens) and in compliance with the GDPR cannot contain personal data of the customer.

The complete procedure might look like this:

• the customer sends the supplier's app his address
• the supplier prepares the NFT encrypted with the customer's public key (address)
• the supplier enters a transaction asking to exchange the NFT for N tokens (which at the exchange represent the amount the customer has to pay in Euros, so possibly also a stablecoin)
• the customer enters the payment tx which completes the exchange and then receives its encrypted digital receipt.

Authorities will always be able to verify that a certain supplier's cash input coincides with the issuance of a receipt to an address, which, however, is not representative of a specific individual. The supplier keeps the unencrypted copy so that it can prove that the encrypted version actually contains the given data (hash comparison).

This system ensures the privacy of citizens, and no one can use the data from the digital receipt system for massive analysis of all citizen purchases.

Finally, the citizen can always destroy his NFT receipt, as he does with the paper one today.

[WernerderChamp]

• Spamming wallets is already very possible today. All you need is to create inputs that have the highest possible locktime (as of now this is in year 2106 when unixtime reaches the uint32 limit). At 43.100 glow per output, you only need 43,1 SMR to create the 1000 outputs. Preventing this fully (or at least making it impractible expensive) looks like a tedious job.
• We could add an additional index to the indexing plugin, like offers by token, essentially creating some sort of orderbook. Or for targeted swaps index by receiver address.

[sdellava]

I agree with you about the spam concern. Spam is "application independent" and this TIP is not actually a proposal to change the protocol, but just add an unlock condition.

Regarding the "indexing" that could be a great additional feature that can allow to build real decentralized exchgange application.

Today we have many DEXs but actually no one of them is really "fully decentralized" because they relay on a web site. Of course all features provided by the web site are accessibile directly calling the Smartcontract API, but I'm not sure there are so many users out there able to do that. So, in my view, a mobile or desktop app able to interact autonomously with the network is a mandatory component of a DEX. If we add the atomic swap capabilities to the network, the app become the only functional component required to execute what we can consider the fundamental act of freedom in the decentralized economy, exchanging value.

BTW, this option put Firefly in pole position to become the first non custiodian wallet able to natively create and swap NFT.

[Buddh1n1]

I'm very much in favor of 6.2 and i don't think it needs a swap feature block as everything necessary is already implemented in stardust.
Just 2 small changes are necessary, which should be backwards compatible:

• make the address unlock condition optional (so that everyone can fulfill the "order")
• add an optional dictionary of <token-id, amount> to the return unlock condition and remove the limitation on token amount

We can then offer a grant for someone to develop an open source UI (preferably as a webpage or firefly module) to interact with this "order book" - or let developers implement it with their own additional fee.

As DEXes are the number 1 usecase of crypto currently, this would be a great selling point ("feeless DeFi"), is a great match for our stardust ledger in general with our native assets (can also create NFT "orders"), can be implemented really easily and bring highly welcome demand to throughput / mana.

[sdellava]

Perfect. I'm ready to work on a web and mobile APP to allow to create swap tx with a simple click. The user wallet will be triggered and so the user can submit the tx in the usual way.

[sdellava]

Good morning everyone.

This feature is certainly very important for many business use cases that I am encountering. Some I have described before, but I have new requests.

The concern of many stakeholders is that the atomic swap can be used as to create spam. I think that spam should and is handled regardless of the type of tx. However, if we want to avoid with absolute certainty this risk, it is sufficient to define that an atomic swap tx must have a time validity that can be set and in any case not exceed a maximum (e.g.24). Exceeding this time it becomes invalid.

[Buddh1n1]

seems very reasonable to me.
another (maybe additional) approach is to have the wallet filter out such spam if the user chooses to, as it's trivial to identify

[EddyTheCo]

What about if we use the Storage Deposit Return Unlock Condition but we allow that Return Amount> amount with Return Amount≤Max IOTA Supply.

Alice sees(2nd layer application...) that 10 Bobcoins cost 300 IOTA.
While Bob sees that 15 Alicecoins cost 300 IOTA.

If Bob wants to 'swap' his 10 coins with 15 Alicecoins. He has to sell his 10 coins to somebody and buy 15 AliceCoins from somebody.

They can see(2nd layer application...) at any time who is interested in buying their tokens.
Bob creates an output with the 10 BobCoins with a Storage Deposit Return Unlock Condition with Return Amount=300IOTA+storageDeposit, Return Address a Bob-controlled address, and with an Address Unlock Condition the address of someone who showed interest in their tokens.

With this, we allow the sale of Outputs(I do not think it is possible right now)(Only works for NFT and Basic Output).
This sale is open although the transaction is not.

With this, the swap is not atomic between different native tokens but is atomic between outputs and base tokens.
This method fulfills these requirements:

• must be a targeted swap,
• can not be cancelable,
• must not be able to DoS the receiver's wallet.

Pros

• Bob can put an expiration time on the output so that only he can consume the output after a certain time.
• Feeless on IOTA L1.
• More general(Allows sale of Outputs).
• Minimum change of the protocol.

Cons:

• Client applications will get a negative balance when consuming those outputs(but who cares about client developers).

Does this make sense?

Methods 1 and 4 are the same and just need MultiAddresses.

[sdellava]

It makes sense, but it is restrictive.

An atomic L1 swap between a generic token allows not only the scamping of valued tokens, but also NFTs.

The generic proposal, on the other hand, simply defines that one who wants to make a swap indicates what type and how many tokens he or she wants in exchange for the quntity and type of a token he or she owns.

Technically, this TIP is easily implemented as Eike explains here: #42 (reply in thread)

[EddyTheCo]

My approach works also for NFTs. Is not restrictive at all.

"The generic proposal, on the other hand, simply defines that one who wants to make a swap indicates what type and how many tokens he or she wants in exchange for the quntity and type of a token he or she owns."
This is restrictive and will take up much space on the nodes.

[sdellava]

Ok. Sorry for misunderstanding. I'm fine with any implementation strategy.