1. Introduction
Genius DEX v1
Last updated
Was this helpful?
Genius DEX v1
Last updated
Was this helpful?
Genius DEX is decentralized exchange (DEX) designed specifically to take advantage of Cardano’s Extended Unspent Transaction Output (EUTxO)-based smart contract ledger.
The innovation brought by the EUTxO system enables Turing complete smart contracts absent on the original UTxO Bitcoin model. EUTxO-based smart contracts differ substantially from account-based protocols currently dominating the DApp space [1]. Therefore, novel protocol design patterns must be developed for the EUTxO model to take full advantage of the underlying data structure.
From first principles, Genius DEX is a complete redesign of the typical AMM DEX protocol. It is a new generation of DEX leveraging EUTxO architecture’s benefits such as security, determinism, parallelism, scalability and composability.
The Genius DEX offers powerful features such as Smart Swaps enabling programmable and composable orders, and concentrated liquidity positions for higher capital efficiency and yield opportunities.
The DEX’s improved order expressiveness and liquidity flexibility allow for powerful secondary protocols to be built on top of it. Genius’s Smart Liquidity Vault is an example of one such protocol. By leveraging Genius DEX’s advanced functionalities, yield optimization can be achieved with algorithmic trading strategies.
This paper is an overview of key design components behind the Genius DEX. It covers the following concepts: EUTxO smart-contracts, decentralized exchanges, concentrated liquidity, smart swaps, smart order router, and smart liquidity vaults.
A settlement layer is a distributed ledger or database that tracks all transactions past and present into the chainstate. The chainstate is a transparent and up-to-date record of all token ownerships across all participants at a given block. The chainstate is stored in each network’s node and synchronized continuously through a decentralized consensus algorithm.
Account-Based Model is simple; an account is used to hold the total token balance owned by a private key or a smart contract (Fig. 1). The account tracks the global state of the user’s digital assets, where credit is added to the balance, and debit is debited. This represents how traditional bank accounts operate and by extension, many blockchains such as Ethereum.
The simplicity of the accounting model provides a great deal of flexibility especially when defining complex execution logic via smart contracts. The success of the accounting model is behind the explosion of DApps and DeFi protocols, aiding to fuel innovation in the smart contract sphere. However, excessive flexibility comes at the expense of execution guarantees, resulting in system vulnerabilities and attacks [2][3][4][5].
Despite the popularity of the accounting model in smart contract-based blockchains, a key limitation is indeterminism. Unlike Bitcoin’s UTxO model, account-based blockchains, namely Ethereum, are indeterministic. This means the effect a transaction has on the ledger is unpredictable because of the inherit mutability of user accounts. As such, the behavior of a smart contract is dependent on the global state and, thus, the time of processing. Consequently, the lack of transaction behavior predictability leads to a number of issues:
Overpaying for Transactions- Ethereum transaction fees are in part governed by a mechanism that is equivalent to a first-price auction. In this model, every transaction submits a bid. If accepted, they pay the exact bid amount. This is an inefficient bidding system that incentivizes users to overpay for transactions. That being said, Ethereum recently introduced EIP 1559 [6], a proposal specifically designed to improve price predictability. Although a step in the right direction, it doesn’t eliminate fee indeterminism.
Failed Transactions - Submitted transactions are not guaranteed to succeed, however the fee will be charged regardless of the final status. A failed transaction can be caused by non-competitive gas prices (under bidding) that won’t be prioritized. Another cause could be from a programming bug in the contract itself that results in a transaction output “failure” state [7].
Network Congestion - Since the ledger state is both mutable and global, transactions depend on the entire state of the network. As a result, network nodes must update frequently and transactions can only be executed by a single serial process. If one DApp experiences a spike in traffic, the whole network will congest, subsequently affecting all DApps interacting with the ledger. That being said, network congestion can also be an issue on a UTxO blockchain.
Adversarial Behavior - Indeterminism also provides opportunities for adversarial agents to abuse network vulnerabilities. For instance, front running attacks, where a Miner Extractable Value (MEV) searcher bot scans transactions in the Mempool to preemptively set a higher bid fee, profiting at the expense of regular users.
In conclusion, the account-based model’s flexibility comes at a steep cost and introduces issues solved in part by Bitcoin’s UTxO model. However, the base UTxO model lacks the expressiveness required for a Turing Complete smart contract ecosystem. The EUTxO accounting model used by Cardano and Ergo aims at solving just that. EUTxOs provides the programmability of smart contracts of account-based models while also inheriting the determinism of UTxOs.
Unspent Transaction Output (UTxO) is a ledger accounting model used by Bitcoin and Cardano. However, Bitcoin’s UTxO model does not provide the necessary programmable expressiveness required to support a Turing Complete execution language. For that reason, Cardano has developed the Extended Unspent Transaction Output (EUTxO) model [8] which upgrades the base settlement layer to support multi-assets [8] and smart contracts. This novel addition allows Cardano to take advantage of the original Bitcoin design while injecting the power of smart contracts introduced by Ethereum.
A basic UTxO contains two types of information: a value amount of a native token such as ADA and an address such as a public key specifying the owner of the assets contained in the UTxO. Therefore, the assets associated with a digital wallet are stored in each block as multiple UTxOs fragments as opposed to a single wallet account.
As shown in Fig. 2, a transaction can be thought of as a function f(x1,x2,...xn) = (y1,y2...yn) that consumes UTxOs (input x) and produces new UTxOs (output y). UTxOs are immutable and transactions must conserve value (total input value = total output value + transaction fee). These constraints prevent fundamental flaws like double-spending. Any subsequent transactions can then consume these outputs and generate new ones. In that sense, the aggregation of all transactions per block defines the state transition of ownership from one state of the blockchain (block) to the next. This is what we mean by the ledger.
The UTxO protocol maps perfectly onto a State Machine representation; it is therefore an appropriate and more intuitive mental model to use when describing such a system. This will become more apparent in the following sections.
As the name suggests, the EUTxO model extends on Bitcoin’s UTxO model and it does so in two distinct ways:
The concept of the UTxO address is generalized to contain a script rather than just a wallet address. The script defines a validator function that contains an arbitrary set of ‘checks’ in the form of an executable program. The validator simply inspects that a transaction’s checks all pass and that the input UTxOs exist.
Additional data can be appended to both the output and input side of a transaction; datum on the output side can e.g. store the state of the UTxO, redeemer on the input side that has to match the datum to consume them, and the context that defines further conditions regarding e.g. time, fees. Thus the scripts can be expressed beyond cryptographic signatures, by providing state information and state transitions. This is nothing more than a State Machine. Moreover, the EUTxO protocol may require more than one state machine for certain state transitions to converge [9]. Overall, validators can process more complex transactions while maintaining the composability and determinism provided by the UTxO paradigm.
The UTxO model has a fundamentally different data structure from the account-based model. As such, UTxO-based smart contract design patterns also differ substantially from most existing smart-contract blockchains. As a result, DApps on account-based blockchains do not translate directly to Cardano since they need to be completely redesigned to match the underlying data representation. This is where the difficulty lies in bridging Ethereum protocols onto Cardano.
In spite of the large barrier to entry for new developers, the EUTxO model offers a number of benefits:
Security - UTxOs are immutable and can only be consumed once, simplifying transaction validation. Moreover, transactions are inherently stateless as they only track state transitions and validators are inherently local as the validation process only depends on the transaction itself, and its inputs and outputs. The separation of logic description from runtime interpretation is at the heart of functional programming. Such declarative paradigms tend to be more concise, more predictable, and easier to test when compared to imperative programming [10]. The interested reader can refer to the next subsection and the references therein for our brief commentary on functional programming in the industry.
Determinism - How a transaction behaves and impacts the on-chain state can be predicted locally i.e. transactions are validated off-chain in the user’s wallet before interacting with on-chain states (Fig. 3). This level of determinism translates to a predictable transaction cost and ledger state change. As such, a validated transaction is guaranteed to succeed and the transaction costs are fixed. However, a submitted transaction could still be rejected, meaning it is not applied to the ledger state, but no fees are paid. This can happen if an expected input has been consumed by another transaction.
Parallelism - Due to the local dependency of validators and the inherent state fragmentation provided by UTxOs, parallel processing of transactions is both trivial and natural. However, if two transactions try to consume the same input, then processing one will automatically make the other get rejected. This is essentially the UTxO concurrency issue as it is often referred to. Therefore design patterns that trade concurrency for parallelism can benefit from a significant increase in throughput while keeping contract execution time the same [11].
Scalability - Transactions on an account-based model are processed sequentially, which is the equivalent to only being capable of executing a program on a single core of a computer [12]. An under-appreciated fact about the UTxO model is that the transaction’s computation happens off-chain before it is validated on-chain, without degrading any of the security and decentralization of the base layer (Fig. 4). In other words, the settlement layer is simply a verification model that validates the off-chain computation. This precise separation of responsibilities makes modularity and composability a core primitive of Cardano. As a result various novel scaling solutions can easily be “bolted” onto the blockchain, such as off-chain routing bots and isomorphic state channels, Hydra [13], [14].
Composability - Smart contract code on account-based blockchains tends to become monolithic and complex as new features get added to old scripts, bloating the software and negatively impacting interoperability between smart contracts. Conversely, UTxO’s determinism combined with Haskell’s functional programming prevent side effects caused by shared states, making smart contracts compositing much easier. UTxO’s composability is achieved in two ways: 1) writing single-purpose programs (smart contracts) that do one thing well; 2) writing programs that interoperate together, reducing code duplication, and fostering script reuse/sharing across the network. Similar to Linux’s command line, composability is achieved by combining well-defined programs in a virtually unlimited number of ways, enabling a large number of complex behaviors from a small number of simpler primitives.
At the heart of the EUTxO paradigm is functional programming. To have a glimpse of what EUTxO-based DeFi could be, we briefly outline the adoption of functional languages in the real world [15]. For example, in the social media sector, WhatsApp uses Erlang to connect two million users per messaging server; Facebook relies on Haskell logic for active and automatic spam detection in daily news feeds. This illustrates the benefits of achievable scalability and reliability of functional programming. Functional programming is also widely adopted in the financial sector, credits not least to Peyton-Jones et al’s seminal work on modeling financial contracts in Haskell [16]. Functional programs accelerated evaluations of derivatives bringing advantages to large institutions such as Credit Suisse and Jane Street Capital, the latter being one of the world’s largest market makers trading more than $17 trillion worth of securities in 2020 [17]. No one would risk losing such large sums of money, unless the underlying code is without bugs. We expect the benefits of functional programming to similarly supercharge scalability and reliability in DeFi.
Overall, well designed primitives, especially at the ledger level, with built-in guarantees at the core of the protocol can have compounding effects on the rest of the ecosystem. Strong fundamentals not only provide robustness and reliability, but also the building blocks for a flexible and composable system. A system in which expressiveness and complexity emerges from the interaction and combination of simpler components. It is particularly powerful for the development of DApps that can be infinitely extended like a castle of “money legos”.
Consequently, there will come a point where protocols specifically designed for a UTxO architecture won’t be replicable on an account-base model e.g. Ethereum. This is the competitive advantage Cardano can leverage to develop novel features unique in the crypto space.
