Minswap V2 features, throughput and Audit Findings

Today, we are giving an update on the state of the Minswap V2 launch. In this article, we give a timeline, we cover a bit more in depth the features of the Minswap V2 DEX, give a peek into the improvements made thanks to Plutus V2 (scalability, sustainability, composability and more), and delve into the results of the 2 audit procedures.

Timeline

• Beta-testnet: starts on June 3rd, ends June 20th — during this Phase, the most passionate community members will be asked to provide feedback on a private testnet environment.
• Bug Bounty: starts on June 1st, ends on June 20th — during this Phase, Audit Reports and Smart Contract Code will be open sourced and shared, community review and reporting of vulnerabilities will be incentivized.
• Public testnet: June 20th — a public testnet link will be shared for anyone to try it out.
• Minswap V2 Launch: we anticipate the launch to come shortly after the Bug Bounty period has ended, provided no major issues are discovered.

Minswap V2 features

A lot has been said recently about Cardano “DeFi 2.0”. The overarching theme of this narrative is a new iteration of dApps that are much faster, composable, decentralized, versatile and cheaper than the previous and first version of Cardano DeFi dApps. Minswap V2 stands in grand contrast to Minswap V1 in all those verticals, with V2 opening up a plethora of improvements from the get go.

While Minswap V2 includes a cleaner, shooter UI/UX, in this article we are focusing only on new V2 features related to Smart Contract level features:

1) Auto-Routing

This feature is implemented via a Smart Order Routing Algorithm that whenever you swap, it will scour for the best prices, even across multiple pools! If you’re trading from token A to C and A-B and B-C pools offer better liquidity for the trade than A-C, the V2 system will take the efficient route, ensuring rapid and optimized trade execution. Before executing orders, the user will be able to choose a path for its execution, with the most optimal (cheapest) being the recommended option. Essentially, it’s like having an aggregator within Minswap itself.

What does it look like in a use case? → Let’s say you want to make a swap from iUSD to SNEK. The iUSD/SNEK Liquidity Pool is very shallow, but there are big ADA/iUSD and ADA/SNEK Liquidity Pools. When swapping iUSD for SNEK, you will be shown in the UI the most optimal price, and in the backend what happens is iUSD gets swapped for ADA and ADA gets swapped for SNEK.

2) Advanced Order Types

Here is a more detailed overview of the advanced orders that will be available:

• Limit Orders: This type of order is distinct from market orders (also known as Swaps), which execute at the current market price, adjusted for slippage tolerance. Unlike market orders, Limit Orders enable traders to set a specific price at which they wish the trade to execute, potentially below the current market price. With Limit Orders, traders are presented with two options: “Fully Fill” and “Partial Fill”. Traders must determine whether the Limit Order should strictly match the Limit price and execute 100% of the order, or if it can be partially filled over time.
• Stop Order: This type of order enables traders to prevent negative price swings and establish a maximum quantity they are willing to lose. For example, if you own coin XYZ and set a Stop Loss order at 10%, if the market goes against your projection, you will not incur a loss of more than 10%.
• OCO (One Cancels the Other): This combines a stop-loss order with a limit order. Users define a swap amount and two price points: a minimum receive threshold (like a limit order) and a maximum receive threshold (like a stop-loss order). The order will only execute if the market price hits within these two boundaries, providing a bracketed trade strategy that automatically cancels if one condition is met.
• Imagine you’re trying to sell a vintage car. You want to make a good profit but also want to avoid a big loss. So, you decide to sell if the offer is above $20,000 (to make a profit) or below $15,000 (to avoid further loss if the market drops). Once one condition is met (a high enough offer or a risk of low offers), the other option is off the table. This plan is similar to an OCO order, where you set two outcomes, and fulfilling one cancels the other.
• Zap-In: enables traders to provide liquidity in a Pair with a single asset (the other asset will be sold off for the other asset of the pair).
• Zap-Out: enables traders to withdraw liquidity in a Pair in the form of a single asset of your choice (the other asset will be sold off for the other asset of the pair).
• Donation Order: Allows users to donate assets to a specified recipient or cause directly from a liquidity pool. This order type enables the support of community projects, charity, or other initiatives without requiring a direct transfer from the user’s wallet. It can enable better functionality such as distribution of ADA Delegation rewards.
• Deposit with flexible amount: Traders can deposit any amount of Token A and Token B, the AMM V2 will automatically swap a part of Token A or Token B to match the Liquidity Pool requirement. For example if you have 100 ADA worth of coin XYZ and 10 ADA in your wallet, you can choose to provide all ADA worth of XYZ and part of it will be sold before providing Liquidity. This is the power-up version of our beloved Zap-in feature in V1.
• Withdraw into flexible amount: the same feature as Deposit with flexible amount but for withdrawal

2.1) Advanced Order Features

In addition to more order types, we also add extra features to the order contract to enable interesting and convenient trading strategies.

• Fill-or-Kill: Orders can be refunded automatically by the batcher if the price is out of slippage range so that users don’t need to cancel manually.
• Order expiration: When creating orders, users can specify an expiry time and a small tip to cover the transaction fee (~0.2 ADA). After the expiry time passes, anyone can cancel the order and take the tip from the order and return the rest to the users.

3) Minswap V2 Trading Fees

In Minswap V1 there is a standard Fee of 0.3% applied to all Liquidity Pools. Minswap V2 allows for more flexibility in this regard.

3.1) At Pool Creation

Standard Fees: Liquidity Pools may be created at inception with any Fee between 0.05% and 20%. To avoid liquidity fragmentation, only one Liquidity Pool per Asset Pair is possible.

3.2) After Pool Creation

• Adjustable Fees: Trading Fee on a Liquidity Pool may be adjusted to any amount between 0.05% and 20% following a vote on the LP Governance Dashboard. This dashboard won’t be available at V2 launch but soon after.
• Buy and Sell Fees: Trading Fee on a Liquidity Pool may be adjusted differently for Buy and Sell orders between 0.05% and 20% following a vote on the LP Governance Dashboard. This dashboard won’t be available at V2 launch but soon after.
• Dynamic Fees: Extensive research has been done on this vertical. If we look at market makers in TradFi, they quote different “spreads” according to conditions such as volatility. DEXs can learn from that.
• There are multiple ways to implement Dynamic Fees based on market conditions and the type of DEX. Some DEXs will use a volatility measure to inform how the dynamic fee evolves. Others will use historical profitability of different fee pools. Some may use price momentum. Some also may use price oracles to inform the fee (maybe setting fee based on CEX price difference from DEX pool price, etc). At Minswap, we focused on 2 different types of inputs for our dynamic fees: volatility and Impermanent Loss (IL). There is a 2 Part article series about Dynamic Fees where we will dive deeper into this topic, Part 1 will come in 1 week.
• Protocol Fees: In Minswap V1, there is a Parameter called “Protocol Fees” that allows directing 0.05% of the 0.3% swap fee to be directed to a specific wallet in the form of LP Tokens (Fee Switch). Currently, it is directed towards MIN Stakers. This has helped strengthen MIN’s moat, with staking as the vehicle through which DEX revenue is shared. In Minswap V2, this same “Protocol Fees” Parameter exists. If activated, a % of the swap fees may be directed to certain wallets.
• While building V2, Minswap Labs was approached by several Teams, about a feature to direct some of the fee sharing of these Protocol Fees with projects themselves. It is important to note that the 1/6th of Fee to MIN Stakers will remain on most Liquidity Pools, and may, in fact be increased for select partner Pools. Sharing Protocol Fees has several benefits, as if projects make direct revenue from Trading Volumes on Minswap, they’re highly incentivized to increase Volumes, Liquidity and Liquidity Incentives. It ought to be managed through a structured Partner Program with a series of requirements, such as a DAO structure and a minimum of TVL and Volume.

4) Minswap V2 Throughput

Our V1 contract allows a hypothetical max throughput of 8 swap orders per batch, however due to the batcher having to batch orders in a fair first-in-first-out manner, the average max throughput is only 3 swap orders per batch. In V2, we have made significant breakthroughs in both technology and optimization techniques:

• Use of the Aiken compiler.
• Allow the batcher to sort input orders, so we can include as many orders as transaction size allows.
• Use the withdrawal script to de-duplicate the validation of similar scripts in a transaction.
• Use the ByteArray counting technique to check for array uniqueness.
• Use the Skip list technique to speed up indexed array access.
• Use Pattern-matching and Value objects with common shapes to avoid costly indexing.

With that, we have tested the maximum throughput of V2 contract to be 36 swap orders per batch, which is a whopping 10 times or more improvement compared to V1 average max. This will ensure that Minswap V2 batcher can clear a backlog of orders 10 times faster in congestion while still maintaining execution fairness. These improvements are made while maintaining FIFO order matching and do not come at the expense of making users exposed to front running in times of high traffic We are happy to open-source our V2 contract to share the techniques with the Cardano dev community and help bring up the whole efficiency and speed of Cardano Dapps.

5) Minswap V2 Sustainability

In order to maintain a high degree of decentralization, as the blockchain keeps growing, it is crucial to keep node operation requirements low so that it could be run on common hardware across many countries in the world. We have leveraged the Reference Input feature of Plutus V2 so that we only need to deploy the script on-chain once and don’t have to repeat it on every single transaction. With that, we anticipate that V2 will save on average 9 KB per transaction, which is around 28 GB of node storage per year.

A second angle to the Sustainability benefits Minswap V2 brings is related to Batcher Fees. Currently it is 2 ADA per order, and a significant part of that ADA goes to pay transaction fees on the blockchain. With the gains made in throughput, and consequently lower size of the Smart Contract, this means the fees that need to be paid per transaction will be lower. This opens up room to significantly reduce batcher fees on Minswap V2. This is a complex topic, further study and research is needed to determine how Fees are changed, several volunteers are working on this at the moment.

6) Minswap V2 Composability

Minswap V2 will magnify composability across the Cardano ecosystem with innovative pluggable features for order contracts. Each order can be a part of a larger chain of a composed action that can pass their state and tokens down the chain through each transaction. More specifically, the V2 order contract is capable of the following:

• Order’s owner can be a wallet, native script or Plutus script. Those can cancel or update the order. When a script cancels an order, funds will be returned to the sender script with pre-defined datum.
• You can pass tokens and NFTs in an order to the output.
• Order’s output can go to a script address with pre-defined datum.
• Order can expire and return back to a script.
• Order can be filled partially and the unfulfilled portion will be returned back to the script.
• Order can be returned back to sender (script) if price is out of range (fill-or-kill).
• Script can “donate” assets to a pool, for example a DAO can put yield rewards back LPs.

Example with a hypothetical lending protocol:

• A lending contract can reference input a pool to check price, if the price is below a certain threshold the lending contract can be called to liquidate assets, which then create a swap order.
• The lending contract can later cancel the liquidation order based on other conditions.
• The liquidation order output can go to another contract address with a predefined datum and other tokens or NFTs.

Example with composed action:

• Zap to MIN staking: A swap order from ADA to MIN with receiver field set to be staking smart contract.
• Zap to farm: Suppose a farm contract supports stake order, we can create a zap-in order from ADA to LP tokens and the output will be sent to the stake order, which will later be staked to a yield farm.

7) Minswap V2 Extendability

Minswap V2 uses a trading aggregator to route to the pool with best prices across Minswap’s multi-pool ecosystem, whether that pool is in V1, V2 or StableSwap. In the future, when Minswap launches a new pool contract or upgrades the current pool contract, trading experience would still be the same for users. However, to ensure security and non-custodial nature of a DEX, we don’t have any multi-sig or migration mechanism for the pool contract, which means only LPs can withdraw or migrate their funds using their wallet.

The order contract however is independent of the pool contract, so it can be upgraded without liquidity migration as long as its datum shape remains the same. For example, we can later upgrade the order contract with the DCA feature or Plutus V3.

8) Minswap V2 Security — Audits

The Minswap V2 DEX was Catalyst Funded in the Minswap V2 Audit Proposal. We previously wrote one article when the First Audit was concluded by Certik and a second one when Anastasia Labs finished the Second Audit.I n the coming week, an article will be published about the Bug Bounty for the Minswap V2, and the code will be publicly auditable for at least 30 days before deployed. That being said, the code will not be deployed until approved by the DAO in a Forum proposal by Minswap Labs.

Minswap V2 draws from many lessons Minswap Labs made when releasing Minswap V1. For the V1, the priority at the time was to be quick to market. This proved to be a mistake as was learned by a vulnerability that was disclosed after the audit and after open sourcing the code after it was deployed. For Minswap V2, even if it came with a longer time window to deploy, security really has been the number one priority.