A fresh look at Atomic Swap

We are working on a DEX based on atomic swap, and from talking to people, I have realized that they don't see the actual problems that we are trying to solve.

The main disadvantage of today's DEX, I believe, is that you can't buy a native token from another blockchain, or a token issued on another blockchain. This aspect of the architecture has led to the use of wrapped tokens and bridges. For example, if you want to trade bitcoin on DEX, you buy WBTC instead of native bitcoin.

So what's the problem here anyway?
WBTC is issued by a centralized organization, so using it carries additional risk. The organization that issued WBTC, which is the custodian and holds the collateral for it can suddenly close down. BTC that are collateralized can be stolen or seized by the authorities. Of course, this problem does not only apply to WBTC, but to every wrapped token.

If you bought WBTC and want to exchange it for native BTC to reduce the risk, you will have to trust a centralized organization once again. Usually people deposit WBTC on a centralized exchange, exchange WBTC for BTC at a rate close to 1:1 for BTC and withdraw it from the exchange to their non-custodial wallet.
But wait a minute, we invented DEX in the first place to stop using centralized exchanges, why did we use it again?

Is there any method to change WBTC to BTC without using an exchange and at least avoiding KYC?
Yes, there is such a method, bridges. A simple bridge is like an exchange, a centralized organization, but does not require KYC and registration for its users. Bridges only deal with crypto, no fiat, so it's easier for them to ignore the regulators.

The centralization of the bridge is a bit obscured. Both blockchains between which the bridge allows token transfers have smart contracts with liquidity. In one blockchain the user sends an asset to the smart contract, in the other blockchain the user receives a payment from the smart contract.

The centralized nature of the simple bridge is that there is no technical possibility for the smart contract of one blockchain to transfer information about the incoming transfer to the smart contract of another blockchain. And this data is transmitted by a centralized bridge server.

What is the disadvantage of the bridge?
It works automatically, quickly, does not require registration and KYC, the client solves its task perfectly!

The centralized bridge server can be hacked, the employees can be fraudulent, the bridge owners can be pressured by regulators, law enforcers or criminals, and all the liquidity of the bridge can be withdrawn. Something like this happened recently with Multichain bridge, about $130 million of liquidity was drained out. If the bridge goes down, first of all the bridge partners who provided liquidity to the bridge will suffer. Also those who started exchanging without knowing that the bridge has already collapsed will suffer.

Also, many bridges themselves are the issued the wrapped tokens. All tokens issued by the bridge will be worthless, and it will be the losses of those who held these tokens (in purpose to trade them on DEX in particular).
Note that if we had the ability to buy native BTC on DEX immediately, rather than a wrapped token, we wouldn't need to use bridges either.

The issue of centralized bridges is a concern for the community.
And not for nothing, we have already seen scams of bridges and tokens issued by them. The idea was to replace the centralized bridge server with decentralized validators collateralized in the bridge token. The validators are motivated to transfer data between blockchains honestly, since they will lose their collateral in case of fraud.
There are already several projects that have successfully implemented this idea.

Of course a decentralized bridge is better than a centralized bridge.
But it is a technologically complex and expensive mechanism. The more complex the mechanism is, the higher the probability that hidden defects will be discovered there, the higher the risk of hackers breaking in. There is also a vector of attack through the economic model of motivation of validators.

Solution: I offer you a new look at atomic swap.

The idea was invented 10 years ago, there were projects that used it and they did not become popular. All the implementations of atomic swap that I found hid its essence as far away from the user as possible, and bound the sender and receiver in the interface. The user was required to at once select both blockchains being exchanged.

I think this was a fundamental mistake, an incorrect separation of essence. It's hard to think about, it's hard to explain to the user, it's a big barrier to adoption.
For example, we don't think of buying bread as a single transaction with card payment.
We say I bought bread. I paid for it with a card.
Two different actions, despite the fact that they are closely related.

Imagine that in your crypto wallet you have a checkbox "HTLC" when sending a transfer.
HTLC is short for Hash Time Lock Contract, a special transaction type added to bitcoin core a long time ago. Etherium does not have HTLC in the core as a special transaction type, but its functionality is easily implemented by smart contract.
When the user checks this box, there are fields to enter additional data:
- Protection Hash.
- Time after which the transfer can be canceled.

Sending a transfer with hash protection form

Otherwise, this transaction looks like a regular transfer.
Also, the wallet should have a function for tracking incoming incomplete HTLC transactions.
When viewing such a transaction, a field for entering Key should be displayed.

It should also display the Hash and the time left to complete the transfer. If the recipient has entered the correct Key, the transaction is completed successfully and the money is credited to the account. (Key is correct if its sha256 hash is equal to the one specified at transaction creation).

Also in the wallet history of transfers should be displayed the status of the transaction. At the moment when the recipient entered the Key, having completed the transfer, the sender in the history of transactions should see that the transaction is completed and the value of the Key that was entered.

Let's imagine that we have two wallets in different blockchains with such functionality, for example in BTC and ETH.
Their users will be able to make an exchange without trusting each other, without a guarantor and without the risk of being cheated by each other.

Here's how Alice and Bob conduct an exchange:
- Alice selects Key, and sends an HTLC transaction to Bob's Ethereum wallet.
- Bob sees the incoming HTLC transaction in his Ethereum wallet, copies the protection hash from it, and sends a counter HTLC transaction to Bitcoin, with the same protection hash.
- Alice sees the incoming HTLC transaction in Bitcoin, she knows the Key, enters it and gets the money.
- Bob sees in his Bitcoin wallet's transaction history that the transaction status has changed to completed. He sees the Key with which the transaction was completed. He copies the Key, enters it into the Ethereum wallet and receives the money.

You see, we didn't need any intermediary, neither centralized nor decentralized to transfer Key between blockchains. Just an HTLC transaction implemented in their wallets' interface.
Alice was motivated to disclose Key to the Bitcoin blockchain to get the money.
Bob was motivated to copy Key from the Bitcoin blockchain and enter it into Ethereum to get the money.
They also did not need to put any additional software or even authorize their wallets on the web3 site in this example.

As soon as another wallet, such as the Tron blockchain, has the same functionality, they will be able to swap with its users. For compatibility, all that is needed is for everyone to use the same hash function, sha256, as in bitcoin.
That looks like an amazing flexibility of communication between different systems!

Moreover this model can be realized far beyond cryptocurrencies. Centralized systems like paypal, sepa, banks can also implement a similar hash protected transfer functionality.
From a legal point of view, their clients don't get any new features, and it looks like a minor technical feature. Clients already have the right to transfer funds to each other. If the bank previously required customers to provide documents to explain the transfer, nothing has changed here as well, it is still a transfer between the bank's customers. Adding this functionality will only allow users to execute p2p transactions using this bank without the risk of being cheated by the counterparty.

A bank or a payment company that has implemented a transfer with hash protection will have an advantage in the eyes of customers who have already learned this mechanism in crypto.

What is interesting, except money with hash protection you can transfer any digital assets, such as NFT, domain names, valuable items in games, as soon as the developers of the service will add such functionality.

The question arises of course: how will users find each other?
I think that the best solution is the protocol of "universal exchange order".
Something like a mempool where everyone can send their request for exchange with data about assets, amounts, exchange rate, contacts for communication. The protocol should be open, like bitcoin or torrent. Everyone can start his own node, see all the current requests for exchanges and filter the necessary ones for himself. Developers will be able to create nodes for their applications and sites focused on niche markets by asset lists, language interface, display handy charts and ratings invented by them collected by onchain by the speed of completion of past transactions, etc.

Deep automation is also possible, a personal opensource wallet bot that performs trades. But the user should still be able to send a simple transaction with hash protection, just from his wallet. And it will not be important to the user whether another person or a bot trader executed a transaction with him.

Now we are working on a prototype, in EVM blockchains swaps have already been implemented.
As partners we are interested in web3 funds, wallet developers, representatives of core blockchain development teams.
WhatsApp +5491133440476, Telegram akamitch

TL;DR: Why wrapped tokens are insecure. How to make a new type of DEX: trustless, real cross-chain, without bridges and wrapped tokens, compatible with fiat systems and even selling domains.