Please describe your proposed solution.
Problem Space
Existing Cardano DEX projects on mainnet represent some blend of two models:
- Order Book Style - This is often used by centralized exchanges as it is reasonably easy to implement. This pattern has fewer problems with transaction throughput within Cardano’s UTXO model, as independent BUY and SELL orders can be matched together without blocking other orders in parallel on chain. This model is exemplified by Muesliswap. This style of exchange is known for being vulnerable to price manipulations through placing of wash orders. Typically an automated actor is matching orders though, and orders can be ignored as well, though this can be overcome by allowing the automated actions to be performed by anyone by use of an open-source bot.
- Automated Market Maker (AMM) Style, With Order Batching - The automated market maker model, popularized by Uniswap, offers a solution to provide good price discovery, even in low trading volume, by creating a liquidity position which manages the price. Unfortunately, this model is notoriously difficult to run on Cardano, again without the use of an automated actor, this time to collect orders and make the aggregated adjustments to a single liquidity pool in order to complete a trade for each order. Again we have an element of trust, that the automated actor could leave off orders, and we have increased latency as there is no guarantee that your order will be matched immediately, resulting in price slippage which can be a suboptimal experience for the user. These batched transactions are actually quite large and can use up many of the resources needed in a block.
This brings us to the central problem Bashoswap seeks to solve - Can an AMM-Style DEX operate without batching on the Cardano Layer 1 network?
We assert that such a DEX can be built by utilizing the same technique leveraged by DripDropz and Heidrun to keep their services fast even in high-congestion. We call this technique ‘Transaction Chaining’ as each transaction holds a piece of secret information from the transaction that precedes it, before the prior transaction is included in a block.
This technique involves getting users to share the outcome of their transactions with each other off-chain, utilizing a service which is essentially a ticketing system, pre-approving the order of trades before they settle into a block. This service too could become decentralized.
Breaking things down a little more, let’s imagine Bob and Alice interacting with a DEX
- Alice places a trade on the DEX, her transactions have a number of UTXO-inputs and new outputs generated. These outputs contain critical information including the price of the tokens that would be paid by the next trader after Alice. In order to place her order, Alice must have it signed by a decentralized swap verifier service. Alice’s order may be included in this block, but the settlement is pre-approved.
- Bob is preparing to place an order, he is able to receive the important data from the decentralized swap verifier, learning about the new pricing information and other critical data, so that he can now place his own order. His order is also validated by the service, which stores information about the outcome of Bob’s transaction. To prevent a user from breaking the chain, the layer 1 smart contract must cryptographically ensure that the legitimate swap verifier has been used.
This changes the usage of an AMM DEX considerably. Both Alice and Bob are able to know with certainty the price they will receive for their trades. Since transaction order is known long before the transactions settle on chain, there is less room for extractable value exploits. Because each swap transaction will be quite small, many such transactions may fit into a single block. Especially after the introduction of reference scripts in the Vasil Hardfork, this model may represent a serious step forward for usability onchain.
For additional information about this technique - we would like to refer you to Andrew Westbergs’s youtube channel, where he discusses this method at length: https://www.youtube.com/watch?v=EGwJCiMy4_E&t=694s
Please describe how your proposed solution will address the Challenge that you have submitted it in.
Bashoswap aims to create a proof-of-concept implementation of a transaction-chaining DEX, which can be brought to market as we work toward the broader feature set in our roadmap.
We have already been in development through Q1 and Q2 of 2022, and currently have a working onchain prototype capable of executing swaps. In this proposal we wish to complete the off-chain portion of the dApp and begin connecting our prototype to our User interface to reach one of our next major milestones.
In this proof of concept, our first stage is to create a simple centralized Swap-verifier service as described above, to be able to demonstrate and verify our claims about throughput and price stability. We will then seek to decentralize this design. One such approach to decentralization may create business opportunities for Stakepool Operators and Input Endorsers.
How will these resources help Cardano?
We assert that improved techniques for building high-throughput defi apps on Cardano helps everyone building on the chain by providing better best-practices and by enabling better user experiences, we make progress on the chain together. Our smart contracts and resources will be open sourced and other developers will be able to create similar solutions across the ecosystem.
What are the main risks that could prevent you from delivering the project successfully and please explain how you will mitigate each risk?
Of course, this is the first such implementation of an application with this mechanism in a DEX, and that carries inherent risks. Other risks include market forces, ability to fund the rest of the project, on-chain security and effectively decentralizing our verifier service. Cardano is still a very young ecosystem and it will be critical to operate efficiently as we move toward our goals.