HydraSwap
Search…
HydraSwap Whitepaper
Version 1.0.5

# HydraSwap: Decentralized Cross-Chain Exchange

A Cross-chain DEX based on Solana Network
Note: This is only a prototype of our whitepaper. This version is purely for the illustration of ongoing product design and development. As this development progresses, regular updates on product details and coding logic will be made publicly available via this document.

# 1. Market Background

## 1.1 Current Market Pain Points

Decentralized finance (DeFi) is a blockchain-based financial infrastructure that has seen spectacular growth recently. The primary use case being replicating existing financial services in a more open and transparent way. This includes decentralizing trading platforms, by eliminating the need for a third-party with the introduction of smart-contracts.
Decentralized exchanges or DEXs, mark an important development for the industry as it progresses from the ecosystem of centralized exchanges. One of the few key reasons include stronger security guarantees to end users since there is no longer a central party as users are able to transact trustlessly - without a middleman. As such, DEXs have drawn the attention of privacy enthusiasts and investors alike.
DEX platforms like Uniswap and Sushiswap have seen immense growth within a very short time span along with the growth of the ethereum ecosystem. The network has seen financial products and services providers all over the world scramble to find decentralized alternative solutions and DEXes have been the most successful. With the growing popularity of DEXes and increasing trading throughput in DeFi, Ethereum is starting to hit bottlenecks..
• The Ethereum Network currently suffers from high gas costs per transaction and is plagued by network congestion. The only solution to this problem is its planned network upgrade but this will not come into effect for years.
• A number of options in the market currently offer low gas fees and high transaction speed such as COSMOS, BSC, and Solana. However, the larger ecosystem of public chains is not yet strong enough to accommodate public needs and chain interoperability is also lacking.
• The issue of public chain interoperability is due to the differences in technical architecture and the result of this is increased costs for DEXs that are deployed on multiple chains, trickling costs down to the consumer.
• A majority of DEX platforms employ the AMM strategy which is notoriously rigid in its operations and leads to ineffective market setups. This also worsens the already rampant issue of wild marker speculation.
• DEX and the DeFi industry as a whole, have too high of an entry requirement and this acts as a deterrent for users already used to CEX, and this limits long-term growth potential.
In order to succeed and provide the best possible service to users, DEXs need to offer the same hands-on experience that a CEX does, especially for emerging public blockchain systems. Consumer demand is heavily leaning towards cross-chain asset trading and portfolio diversification, even as the larger crypto industry expands. This is the foundation upon which HydraSwap was created.

## 1.2 Why Choose Solana?

Among the existing public blockchains, Solana dramatically outperforms the rest in terms of network throughput. Consider BSC as an example, which is one of the most popular public chains, with its underlying framework, Tendermint, primarily based on the PBFT consensus algorithm. PBFT is an acronym for Practical Byzantine Fault Tolerance algorithm. The consensus mechanism for this is based on weak synchronization.
Per research conducted in 2020, the maximum theoretical TPS value of Asynchronous Byzantine Protocol is only 20k (Dumbo: Faster Asynchronous BFT Protocols). Meanwhile, Solana achieved up to 65k TPS in a practical experiment, which is a market leading figure. Such high throughput is necessary for the realization of our vision of enabling DeFi to become the financial ecosystem of the future. As such, we chose Solana as our mainnet.

## 1.3 What HydraSwap Can Provide for SOL Ecosystem?

ETH is absolutely the number 1 public blockchain in terms of ecosystem. It is miles ahead of its existing competitors. Despite offering superior technical performance, Solona continues to face various restrictions because its cross-chain protocol is yet to be launched. Hence, its network can’t connect with the ETH network, as such; ERC20 assets have no gateway to flow into the SOL ecosystem. To some extent, the SOL ecosystem is isolated from the current DeFi world.
The cross-chain protocol that is set to be launched in HydraSwap would empower different public chains with its support for cross-chain interoperability. Via the cross-chain bridge, ERC20 assets can easily be re-issued on the Solana network so it can be easily traded with other assets on the DEX.
For HydraSwap, user experience is a top priority. On one hand, it lowers the entry requirement into DeFi for users by modularization and simplification. On the other hand, it provides a plethora of efficient tools for project teams, allowing them to organically participate in the DeFi ecosystem. With HydraSwap’s unremitting efforts, we believe the SOL ecosystem can be enriched while also improving user scale and retention, so that the HydraSwap and SOL eco-system can reach a mutually beneficial partnership.

# 2. The Core of HydraSwap: Solana and Cross-Chain

## 2.1 Solana

The core idea behind HydraSwap is to build a DEX application that boasts superior performance, low gas and fully supports cross-chain interactions. Hence we chose Solana as the debut mainnet for HydraSwap. Here are some of Solana’s biggest strengths:
1. Average TPS exceeds 50,000.
2. Average processing time for a single transaction is less than 0.5s.
3. Average gas fee less than \$0.00001
4. Support both USDT and USDC, the most powerful stable coins on the market.
We believe Solana’s superior performance would empower HydraSwap in building a DEX that offers a similar level of trading speed and experience. The rust-language-based devops architecture offers code security that ensures complete protection for user assets. Despite the SOL ecosystem being at an early stage with its developer community and code accumulation, HydraSwap’s development can be well ensured considering our experienced technical background. We are confident that by building a DEX on SOL, the value overflow can be better captured and utilized by developers and users alike as DeFi prospers.

## 2.2 Cross-Chain Bridge

Due to the natural boundaries between different blockchain networks, users could not directly swap their assets across chains. Some organizations adopt centralized solutions to bridge assets for their users, such as Binance. However, it has a strict amount limit and the centralized handles apparently could not meet the expectations from the ever-growing DeFi market. There are some decentralized cross-chain service providers on the market, but seldom of them has mature cross-chain solutions for Solana. To some extent, this results in the isolation of Solana from the wider blockchain ecosystem.
HydraSwap is always striving for bringing the very ease and convenience to more users and making contributions to the prosperity of the Solana ecosystem. That is why we are going to build our Hydra Bridge to provide a seamless cross-chain swap experience for users. With Hydra Bridge, users can enable a token to cross chain through only a few simple deployment steps. When the deployment is done for a token, anyone can swap this token between the chains that the token has been deployed on. At the early stage, Hydra Bridge would support the bridges of Solana-Polygon and Solana-BSC. More blockchain networks will be supported as we progress.

### 2.2.1 Cross Chain Consensus Mechanism

- Practical Byzantine Fault Tolerance (PBFT)
As a classic distributed algorithm, PBFT is essentially a state machine replication algorithm, which models the service as a state machine, and the state machine completes the replica copy of different nodes in the distributed system.
In this way, the state machine implements the operation of the service while preserving the state of the service. All nodes in the blockchain rotate in a view.
In one view, there are three types of roles, client, master, and slave. Both the master node and the slave node are used as backup nodes to complete data backup. PBFT has specific requirements for the number of nodes, f represents the number of Byzantine nodes, R represents the total number of nodes, and 0 to |R| − 1 represents each replica node number in the set. The ideal number of nodes is |R| = 3f + 1. The number of nodes R can be greater than this number.
PBFT Algorithm Procedure
The PBFT algorithm has effectively solved the Byzantine Problem, the core difficulty rooted in the consensus. Based on the realistic situation of cross-chain interaction, the off-chain validator nodes of a cross-chain mechanism should be controlled to a relatively reasonable level. Too many nodes may lead to reverse impact. We adopted the Proof of Authority algorithm to address the consensus issue between different validator nodes.
- Proof of Authority (POA)
POA is an upgraded consensus algorithm based on PBFT, which highly matches the needs of cross-chain protocols in the validator model. Following the atomic broadcast scheme, validator nodes send out cross-chain messages as the original message. Decentralization will be achieved through the consensus among multiple validator nodes.
Meanwhile, when a validator node receives the cross-chain message sent from other nodes, it needs to use its own private key to verify the message. If the validation is approved, it will sign the message and return it to the sending node.
In this solution, multiple cryptographic algorithms should be introduced to collaboratively ensure the security of the cross-chain procedure. For example, threshold signature and aggregate signature could be adopted for the generation of distributed private keys. In this way, the security of consensus authority could be consolidated; both decentralized level and attacking cost of malicious codes will be dramatically enhanced to ensure the system security. Besides, when broadcasting cross-chain messages, RBC (Reliable Broadcast Protocol) should be adopted to guarantee the credibility of broadcast procedure.
- Transition to Proof of Stake
We are going to upgrade the POA nodes to POS nodes in future to promote wider adoption and decentralization. Validator nodes need to stake HYS and a certain amount of LP Token (generated from the liquidity adding actions to cross chain pools) to ensure the fairness and credibility of the offchain consensus. We will use a slashing mechanism for punishing malicious nodes.

### 2.2.2 Bridge Solutions

Currently, there are two types of mainstream cross-chain solutions. For example, if we want to cross from Chain A to Chain B, we can do it in two ways:
- Mint and Burn Bridge: Lock assets on Chain A and mint equivalent amount of assets on Chain B
- Liquidity Bridge: Staking pools are set up on both Chain A and Chain B. After the asset staking action on Chain A is validated by off-chain nodes, assets can be withdrawn from Chain B.
Following these two solutions, cross-chain assets can be also divided into two types:
- Assets that have tokens on one blockchain and adopt mint and burn mechanisms to deploy their cross-chain commands. Tokens are linked through the mapped and mapping contracts and their total supply of tokens stay unchanged. There is no separate new token generated and no additional supply is created.
- Assets have issued separate tokens on different blockchains and usually they are mainstream blockchain assets. The tokens on different chains are not linked technically, but their token issuers officially give credibility to the token. One of the typical examples is USDT. The USDT asset has been issued on a number of mainstream blockchain networks.
Solution Comparison:
Options
Mint and Burn Bridge
Liquidity Bridge
Liquidity
No extra liquidity required
Require extra liquidity staked
Asset Object
Assets that haven’t been circulating across chain
Mainstream stablecoins
Balancing Mechanism
No
Possible
Depends on circulation ratio
Good
We can observe that both solutions have their own advantages. Therefore, we plan to introduce both solutions to develop our Hydra Bridge to adapt to different scenarios.

### A. Mint and Burn Bridge

Mint and Burn Mechanism can be applied to all assets technically. A project sponsor which originates from other blockchain ecosystems can apply for its cross chain deployment on Solana through us. HydraSwap is pleased to help trusted projects to wrap its Solana tokens linked with its mainchain token by a set of dedicated smart contracts. We call it h-token for a new Solana-version token wrapped by HydraSwap. For example, hCAKE to CAKE, hMATIC to MATIC. The cross-chain processes of a token from its mainchain to Solana and from Solana to its mainchain are mutually-reverse:
- Cross-chain process from mainchain to Solana:
Taking CAKE as an example for bridging from BSC to Solana network using Hydra Bridge:
1) A user deposits his/her BEP20 CAKE on its mainchain, Binance Smart Chain, and the token is automatically staked in the token’s staking contract on BSC.
2) The user’s withdrawal request is sent to Solana, at which point the node will verify the user's deposit action on BSC. If more than 3 nodes have validated the action, the token mapping contract on Solana will execute the token minting operation to mint the equivalent amount of hCAKE. The minted hCAKE will be finally sent to the user's destination address on Solana for asset collection.
- Cross-chain process from Solana to mainchain:
1) A user deposits hCAKE on the Solana, and the contract burns the token by sending it into the 0 address (black hole address).
2) The user sends the withdrawal request to BSC, the asset’s mainchain, at which point the node will verify the user's deposit action on Solana. If more than 3 nodes have validated the action, the staking contract on BSC will execute the unstake action. The unstaked CAKE will be sent to the user’s destination address on BSC for asset collection.
To ensure the universal adoption of a token’s cross-chain version, the cross-chain deployment has to be officially applied or authorized by authentic asset issuers. The eligibility will be limited to projects with strong background and high market awareness.

### B. Liquidity Bridge

For those mainstream tokens, especially for stablecoins, there are better and simpler mechanisms to conduct its cross-chain deployment. The Liquidity Bridge mechanism is just built for those mainstream assets that are backed by explicit and reputed official project teams.
Liquidity Bridge is simple from a technical perspective. There are liquidity providers for tokens on each side of the bridge. Liquidity providers can add stablecoin liquidity on either side of the bridge following the price band mechanism. Eg. Adding USDT(SPL) within the range between 1.001 and 1.002. Liquidity providers can make profit from the fee sharing and arbitrage behaviors. In this way, the cross-chain fee can be controlled within an acceptable range and the price band makes the liquidity highly concentrated around the 1:1 ratio. This can dramatically lower the price slippage and attract organic liquidity through the natural incentives.
All of the above is seamless to a user who intends to cross chain. Users can bridge their asset between Solana and another chain at a fast speed in this way. For example, they can deposit the BEP20 USDT into the liquidity pool on BSC and then withdraw the equivalent amount of SPL USDT from its liquidity pool on Solana, vice versa. The entire process is strictly verified by validator nodes, to ensure users’ asset security, efficiency and speed to the maximum extent.
- Cross-Chain Stable-Swap:
We introduce a novel cross-chain stable swap mechanism using concentrated liquidity pools on both sides to enable greater liquidity while introducing market dynamics to the cross-chain transfer mechanism.
When a user transfers tokens from the original chain to Solana, we will mint a ‘stablecoin substitute’ and then fulfill the asset exchange process to a standard token using concentrated liquidity AMM. LPs will be able to add liquidity in these bridge-liquidity pools with custom price ranges to achieve greater capital efficiency. This will decouple the transfer process vs ‘token standardization’ process on the target chain thus making the transfer process faster. More importantly, this will also allow for a market based pricing mechanism to adjust for bridge traffic direction and immediacy needs of the users.
Below is a step-by-step process for swapping USDT(Polygon) into USDT(Solana):
1) Users sends swap request with input of <USDT(Polygon), amount, USDC(Solana), Solana Address>
2) Smart contract on Polygon receives the request and locks the user’ tokens to the USDT staking pool on Polygon.
3) POA nodes verify the transactions and locking action, and then read the balance of staking pools on Polygon.
4) When the validation is approved, POA nodes will notify the smart contract on Solana to mint corresponding amount of hUSD
5) hUSD will be sent into the liquidity pool of hUSD/USDT automatically, and then the hUSD is traded with the USDT added by liquidity providers within specific ranges set by liquidity providers.
6) After the trading, the USDT(Solana) will be sent to the specific Solana address nominated by the user.
From liquidity providers’ angle, the whole procedure will be like:
1) In an open liquidity pool (multiple stablecoin pools including USDT, USDC, DAI and more will be offered), an liquidity provider adds the specific stablecoin as the liquidity. He will get LP Token as a certificate of his liquidity contribution.
2) Corresponding assets represented by the LP Token might change dynamically. For example, after a liquidity provider adds USDT liquidity, part of it might be traded to hUSD. Therefore, sometimes when liquidity providers remove their liquidity, they might receive both USDT and hUSD.
3) Liquidity providers can finally bridge the hUSD back to USDT(Polygon) at 1:1 via the Mint&Burn Bridge.
It is worth noting that because liquidity providers are always reaching deals at advantage prices in the above process, they will never suffer from impermanent loss. There is always a profit gap for bridging hUSD back to USDT(Polygon).
Bootstrapping the bridge is straightforward. We will allow for single-sided concentrated liquidity pools to be added. E.g. a user looking to add liquidity to spUSD-hUSD pool does not need to have any hUSD to start with. LP can simply add single sided liquidity with a price range starting from >1.0.

### 2.2.3 Cross-chain Swap

Based on the cross-chain infrastructure, we have further thought about the protocol design of cross-chain swap.
Most of the existing cross-chain swap platforms are fake-cross-chain. They only deployed different tokens on multiple blockchains but the liquidity actually cannot be shared or swapped across chains. To optimize this, HydraSwap designs its cross-chain structure as an integrated system.
- Cross-chain Swap Logics
Assuming that we want to swap for Chain B assets on Chain A:
1) Users input order info through the Swap front end. Input includes <token A, amount, token B>
2) Swap front end calls the aggregator. The aggregator judges whether it needs cross-chain swap or not and calculate a best routing path.
3) The aggregator send the <order, path> to the smart contract on Chain A.
4) The smart contract generates a cross-chain swap event accoridng to aggregator’s request. Validators verify the event.
5) After the validation is approved, nodes call the smart contract to initiate the cross-chain action.
6) Cross chain action executed.
7) Validator nodes verify whether the proxy smart contract on Chain B has received the cross-chain assets or not.
8) If confirmed, nodes will call smart contract on Chain B to conduct the swap transaction according to order details.
9) When swap is completed, tokens will be automatically bridged back to Chain A and sent back to user’s address.

### 2.2.4 Bridge UI Procedures

Although the above procedures seem complicated to some extent, the actual UI procedures from users’ perspective are much easier.

### A. Token Bridged with Hydra Bridge

Here we take swapping DVD from BSC network to Solana network as an example, users can complete the bridging in a few steps:
1) Users need to select a token that they want to swap across the chain. This token has to be already deployed for cross chain contracts before users can select it to swap. Also, users should have the tokens in their wallet for the request. Here the user selects DVD to swap.
2) Then users need to enter the amount they want to swap, from which chain and to which chain they want to swap. Also, they need to enter a wallet address in the destination chain, which is used to receive the tokens after the token bridging. Here the user selects that he wants to swap the DVD tokens from BSC network to Solana network, and leaves one of his Solana wallet addresses to receive the SPL-DVD.
3) After entering all the required inputs, the system will ask the user to deposit his DVD in the mainchain first, which is Binance Smart Chain in this case.
4) After the deposit transaction is completed, users can click ‘withdraw’ to withdraw corresponding tokens to their destination chain wallet address.
5) By then, users will have successfully swap his DVD tokens from BSC network to hDVD on Solana network.

### B. Cross Chain Swap

Assuming a user wants to swap his USDT(Polygon) to USDC(Solana), he can easily make it with only one stop on HydraSwap.
1) First of all, he needs to select USDT on Polygon network and enter its amount
2) Select USDT on Solana network as the destination asset
3) Enter a wallet address on the destination chain, which is Solana in this case
4) After entering all inputs, users will be able to see the swap route for this transaction. In this case, the route is from USDT(Polygon) to hUSD(Solana) to USDT(Solana).
5) Next, click ‘Swap’, and then the user can leave all the rest to Hydra’s Cross Chain Swap Protocol, which is driven by our liquidity bridge mechanism. The USDT assets will be finally sent to the wallet address nominated by the user.

### C. Liquidity Adding with Price Band

To facilitate with and support the cross-chain swap, HydraSwap will allow liquidity providers to add their stablecoin liquidity with price band facilities.
Liquidity providers are able to add liqiudity with single stablecoin asset. The asset will be paired with hUSD for swap purpose. They can customize the transaction fee tier they wanna charge for their liquidity.
More importantly, liquidity providers can set a price range that they accept their liquidity to be traded within. This has adopted the UniV3-like price band design, which gives them higher flexibility. The price band can help liquidity providers to concentrate their liquidity around a desired range, so that they can enjoy better fund efficiency and lower price slippage.
- Bridge hUSD back to its mainchain asset
When a liquidity provider removes his liquidity, the liquidity sometimes will be returned in the original stablecoin together with hUSD(explained in above sections). Liquidity providers can choose to bridge the hUSDT back to its mainchain via our Mint&Burn bridge.
For example, they only need to select hUSD from the asset list and set the cross chain direction as from Solana to Polygon, and then leave a Polygon address as the destination wallet.
After completing the full procedure, liquidity providers will receive USDT(Polygon) in their wallet.

# 3. Product of HydraSwap

Apart from cross-chain technology, HydraSwap V1 has integrated multiple product modules, including HMM market making mechanism, smart aggregated trading, IHO liquidity pool setup, DeFi arbitrage, one-stop mining, referral program, etc. Plus the cross-chain lending and on-chain derivatives that will be launched in V2 collectively form the Nine Modules of HydraSwap. Here we will introduce the modules in our V1.

## 3.1 Hydra Market Maker

### 3.1.1 Motivation

Constant product market makers (CPMM) have allowed savers to become passive market makers. They provide liquidity in DEXes while earning yield from transaction fees. This has been one of the key innovations in DeFi leading to where we are today. However it is just a start and it is far from the optimal setup. Uni v3 is a great improvement allowing LPs to figure out their own sweet spot when providing liquidity. There still remains a wide gap between passive liquidity provision and how sophisticated market makers function.
In the current setup the CPMMs offer a basic pricing mechanism and the sophisticated market makers do the heavy lifting off chain. Solana has the potential to change that and allow AMMs to become a lot more sophisticated as it alleviates the computational and gas bottlenecks we currently see on Ethereum. This would lead to reduction in overall time & cost overhead for sophisticated market makers as well as improve the P&L profile of purely passive LPs.
With HMM we aim to continue on the path of innovation and introduce further sophistication in the AMM process. In version1 we will introduce a smarter pricing mechanism for incentivising arbitrageurs while protecting the P&L of LPs and improving their impermanent loss profile.
In version 2 we would look to enable a volatility sensitive pricing. This follows from how traditional market makers function. In volatile times trading spreads widen. This dynamic is not fully captured with the naive CPMM model.
In version3 we would combine the above with uni v3 style price bands. In future versions we will continue pushing the boundaries of automated market making.
3.1.2 HMM Model V1.0
Constant product market makers (CPMM) have allowed savers to become passive market makers. They provide liquidity in DEXes while earning yield from transaction fees. This has been one of the key innovations in DeFi leading to where we are today. However it is just a start and it is far from the optimal setup. Uni v3 is a great improvement allowing LPs to figure out their own sweet spot when providing liquidity. There still remains a wide gap between passive liquidity provision and how sophisticated market makers function.
A traditional market maker (MM) would adjust it’s bid and offer once given a position. This is called applying a price skew. A CPMM does the same by moving up and down the bonding curve based on the token balances after a trade. Traditional MMs use sophisticated machine learning tools taking into account various signals for adjusting pricing. CPMM however relies purely on its own token inventory and is completely agnostic to what’s happening in the broader market. Sometimes this price adjustment can be too aggressive. This leads to pnl leakage as well as adverse selection of trades.
With HMM v1, we introduce a tweak to the CPMM model and introduce a reference oracle price to make a more informed price adjustment mechanism.
Introducing c, the “Compensation Parameter”
When a trade is entered vs a CPMM, token balances change and the price moves along the bonding curve. The LPs experience impermanent loss which is equal to the area of the shaded region in red (ignoring fees).
The price adjustment incentivizes arbitrageurs to step in to replenish the token balance and reduce the impermanent loss.
In HMM, we introduce a compensation parameter ‘c’ which controls how much LPs are willing to compensate arbitrageurs. By controlling this, we can improve the pnl profile of LPs and show that the expected impermanent loss is lower than that of the naive CPMM model.
‘c’ can range from 0 to 2. At c=0, the HMM price is always the same as the CPMM price and creates a large incentive for arbitrageurs. At c=’2’, the HMM price creates no incentive for arbitrageurs. ‘c’ only comes into play when the HMM price is BETTER than the oracle price. In between, HMM still creates an incentive for arbitrageurs but it does so while keeping an eye on the oracle price. If the marginal price using CPMM is too aggressive compared to the oracle price then HMM tries to adjust it closer to the oracle price which provides better performance for LPs.
HMM Parameters
$x, y$
：number of base token and quote token currently in the liquidity pool
$P_0$
: DEX price now（
$P_0=y_0/x_0=k/x_0^2$
$X_0$
: amount in the pool of the asset x before trade
$i$
： oracle price
$x_i$
: amount in the pool of the base token ‘
$x$
’ at oracle price i holding
$x*y = k$
constant
$c$
: compensation parameter ∈ [0,2]
HMM Pricing Formula
Neglecting fees:
Marginal price
In CPMM:
$P=y/x=k/x^2$
In HMM:
$P=y/x=k/x^2$
$x$
and
$i≤P$
OR selling x and
$i≥P$
$P=(k/x^2)*(x/x_i)^c$
$x$
and
$i>P$
OR selling x and
$i
The HMM marginal price has a multiplier of
$(x/x_i)^c$
which is used for raising or lowering the CPMM price
When a trader buys token x vs y, token balance goes from
$x_0$
to x_
We calculate the change in quantity for token y using the below equations.
If the oracle price at the time of trading is equal to or less than the DEX price:
• $i≤P_0$
,
If the oracle price at the time of trading is greater than the DEX price:
• $i>P_0$
if the base token balance after trade is greater than or equal to
$x_i$
$x_i≤x-≤x_0$
,
if the base token balance after trade is lower than
$x_i$
$x-≤x_i$
,
When a trader sells token x vs y, token balance goes from
$x_0$
to
$x+$
We calculate the change in quantity for token y using the below equations.
If the oracle price at the time of trading is equal to or greater than the DEX price:
• $i≥P_0$
,
If the oracle price at the time of trading is less than the DEX price:
• $i
if the base token balance after trade is less than or equal to
$x_i$
$x_0≤x+≤x_i$
if the base token balance after trade is greater than
$x_i$
$x+ > x_i$
Lower expected Impermanent Loss with HMM vs AMM
Arbitrageurs step in and trade against the AMM until an equilibrium is reached vs outside sources of liquidity. Let R= the price ratio between when liquidity was supplied and now.
Ignoring fees, the impermanent loss in CPMM can be shown to be equal to:
$2*Sqrt(R)/(1+R)-1$
With HMM, we can show the impermanent loss to be equal to:
[(R^(C/2)-Sqrt(R))/(C-1) + Sqrt(R)+1]/(1+R)-1
This impermanent loss in HMM is strictly lower than CPMM!
Immunity to Wrong Oracle Price
We can show that HMM has inbuilt immunity to incorrect/manipulated oracle price. An attacker trying to manipulate the oracle price will not be able to make the HMM price better than AMM.
To illustrate this, if the oracle price is wrong (e.g.
$i
, while true market price is larger than
$p_0$
), HMM will perform the same as a CPMM i.e. attackers will not be able gain an advantage. As long as the oracle price gives the right indication of whether the market price is greater than or less than current DEX price, LPs will be better off, the degree to which is dependent on accuracy of the oracle price.
Mathematically, It can be easily shown that:
so
so
so after each trade in HMM neglecting fees:
$k'≥k$
3.1.3 Roles in HMM System
Operator——The Creator of Liquidity Pool :
An operator is the one who creates and operates a liquidity pool. Anyone can set up their liquidity pool on HydraSwap (trading pair). One of the prerequisites for the next generation of DEXs to succeed is a permission-free Liquidity pool setup. This could encourage the entire community to build the HydraSwap ecosystem together. Users are able to easily manage their on-chain asset trading pair with ease and at a low cost.
- How to become an Operator
• First, the user needs to create a trading pair and configure the trading pair settings. The setting allows adjusting metrics such as transaction fee, market making strategy, depth, asset ratio, and order book price spread.
• Users will then have to select the oracle service for the trading pair. HydraSwap has integrated its self-developed oracle with high timeliness and sensitivity for the operators to leverage. Meanwhile, its Oracle API has been standardized to allow fast integration with other existing oracle services. If the operators integrate HydraSwap’s oracle, then the HMM mechanism is adopted, else AMM is selected.
• Operators then set an effective range for every parameter. These parameters can be dynamically adjusted by the operator within a given range based on existing market conditions. To break the range, the operator needs to submit a governance proposal.
• Following the successful completion of the setup (contract confirmed), operators receive an NFT that represents his/her identity and rights. Many derivative applications could emerge from this concept.
• The operator can also transfer his/her NFT to other addresses or destroy his/her own Operator role. A perpetual contract with no Operator will be completely governed by LP.
- Operator revenue
• Operators are able to set certain transaction fee rates and earn revenue from every transaction from their contract.
• Operators receive a token incentive from HydraSwap
• Operators are able to participate in the governance liquidity pool
- Risks of Operator: No. However, regular check-in is needed to prove its active state.
Liquidity Provider :
Liquidity providers for HMM are referred to as LP.
- How to become LP
• LP deposits assets into liquidity pool, in single asset or dual assets.
- Revenue of LP
• LPs earn from the price spread and slippage
• Operators provide liquidity mining rewards to LPs
• HydraSwap also distributes a bonus to the LPs of some liquidity pools
- Risks of LP
• The only risk to LPs arises from impermanent loss, which is collectively undertaken by all LPs.
Users are the backbone of the entire market. Leveraging mechanisms like HMM trading or AMM trading, users are always the Taker Party in trading. However, users cannot directly trade with each other directly in this application without HMM or AMM. Preset transaction fees must also be paid during the trading.

### 3.1.4 Limit Order Supported

Our HMM/AMM systems also support Limit price orders. Users can manually set a certain price when placing orders. Hence, the transaction is triggered only when the said price is met. This gives users more flexibility and is also consistent with the trading habits of users coming from centralized exchanges.

We introduce several new order types that will enable traders to achieve greater automation and improved price slippage while executing trades.
1. 1.
IF-DONE Orders: Rule based orders. E.g. leave a BUY ETHUSD order at 2500, if that gets DONE then create a limit order to sell your position at 3000.
2. 2.
Loop Orders: We introduce a new order type that will enable traders to create looped IF-DONE orders. E.g. leave an order to buy at 2500, if it is done then create a limit order to sell at 3000. Run this in a loop!
3. 3.
TWAP (Time weighted average price) Orders: Want to execute a large order over a long period of time? Use our TWAP order to execute a large trade in small chunks over a period of time. This will allow the AMM liquidity to replenish and you can expect to execute with a lower price slippage. You control the time interval and the size of each sub-order.
4. 4.
Sliceberg Orders: Split a large trade into smaller chunks. Our smart-order engine will optimize the order execution in small chunks resulting in enhanced execution. The optimizer will create a series of orders to achieve the best possible execution while allowing for liquidity to replenish.

## 3.3 IHO——A More Reasonable Offering Mode

An IDO (Initial Dex Offering) is a means for new projects to initially supply its token to the public via a DEX. With the rapid development of the DeFi ecosystem, IDOs have become the preferred method for new blockchain projects for token issuance. In comparison to IEOs (Initial Exchange Offerings), IDOs are fully Decentralized and the prices are purely determined by the market. This has attracted the attention of projects and users alike. However, at present, IDOs continue to face several issues like speculator rush, lack of liquidity (2nd pool has to be built as a result), and more. To mitigate risks for investors and to eliminate offerings from fraudulent projects, we plan on deploying our own innovative offering on HydraSwap dubbed IHO (Initial Hydra Offering). An IHO will offer both users and project teams a more flexible investment solution.
Crowd Funding + Liquidity Pool Setup
How an IHO works is described below:
1. 1.
Project teams are responsible for providing the tokens and, nominating the initial price and supply volume.
2. 2.
Project teams can also set up their hard cap before an IHO. When the total funds raised hit the hard cap or exceed it, the price curve stops moving and the IHO cost price doesn’t change any more. All new subscription requests are rejected. However, Hard Cap is an optional setting, and projects can also opt for a non-hard cap IHO and set a soft cap instead. This way, users get to decide the final price.
3. 3.
HydraSwap also allocates the token quota as per some preset rules. This gives all participants a similar price at the end of the offering. In case the IHO doesn’t have a hard cap, and the funds raised have exceeded the soft cap, use enter the bidding phase to determine the final price.
4. 4.
When users are bidding, the cost price for the IHO increases as per the price curve. This price curve complies with the HMM algorithm. When the IHO liquidity pool has been set up, the price curve growth parameter is configured. The price curve then allows the IHO cost price to rise when there are more quotes from the market.
5. 5.
As more subscription requests stack up during the bidding phase, the cost price continues to increase fuelling uncertainty among early participants. The cost price may often exceed their original tolerance. To address this issue we have introduced a blind exit period. After the IHO subscriptions are complete, the cost price of the IHO is published and a blind exit period is allotted. During this period participants can choose to cancel their subscriptions without any restrictions. However, following this period, re-entry isn’t allowed. Also, the price fluctuation during the blind exit period is not disclosed until the period ends.
6. 6.
HydraSwap also allows IHO creators to set a fixed price. No changes are made once the IHO cost price is fixed. Also, the hard cap setting is arranged in ratio to the IHO quota allocated to every user. Since the cost price and base volume are fixed by the project team, the upper limit for fundraising is also fixed. The default ratio is set to 50%, which means half the base is for fundraising and the other half for the early-stage liquidity after IHO. There is no blind exit period in this scenario.
7. 7.
When the IHO is completed, the liquidity pool for it is automatically set up on HydraSwap. The IHO price becomes the initial price for its spot market.
Liquidity Protection
Besides offering a fair start for participants, a balanced constraint must also be attained between users and project teams. The more balanced it is, the more it would add to the healthy development of the project ecosystem. This is the sole reason why the liquidity protection mechanism has been developed.
• The buying depth of the spot market is composed of the assets users deposit. The selling depth is formed by the remaining supply of the IHO.
• The initial liquidity entirely belongs to the creator of the IHO. However, for the entirety of the liquidity protection period, the creator cannot retrieve the liquidity.
• The spot market follows the established price curve: buying tokens results in price increments while selling tokens, results in a price drop.
How to Become Eligible for IHO Participation
We have put a few different modes in place to determine an IHO participants eligibility:
1. 1.
Quota is distributed based on the users’ pledged balance on HYS (HydraSwaps governance token) and previous IHO project token: Users with a long-term investment plan will be preferred in this mode. These people are the ones who contribute to the most market engagement. This greatly mitigates the risks of short-term speculative losses and adds to value earning. HydraSwap will also reward these users.
2. 2.
Quotas distributed according to the liquidity provided by different users: Users can compete for IHO quota with their proof of staked liquidity. This mode not only benefits the Solana ecosystem but also flushes out bots, allowing authentic users to get more quotas.
3. 3.
100% user competition mode: In this mode, Users compete with each other to claim the quota. Every address can claim certain quotas, which must be paid in HYS tokens.
4. 4.
Whitelist mode: here Token quotas will be distributed to users on the whitelist provided by the project team.
5. 5.
There are no bidding procedures in modes 3 and 4. The preset IHO price will be the constant reference for the project..
• Funds spent by investors are not misused by anyone. Instead, it is leveraged to naturally set up an authentic liquidity market.
• Project teams are constantly motivated to work hard. If the secondary market has not been well protected, the funds they earned could drop as a consequence.
• In just one step, both token issuance and market listings are conducted for new projects. Irrespective of the total funds raised, selling liquidity is always ensured to allow further capital inflow.
• For already listed assets but with insufficient liquidity, a large amount of selling liquidity can be released via crowdfunding to improve its liquidity premium.
• Compared to traditional IDOs, IHO advocates a Fair Start. Speculator Rush will be effectively prevented in case of an IHO.
• When compared with AMM liquidity mining, token inflation is unnecessary to pay for liquidity rent. As a result, Tokens are better allocated towards real investors rather than short-term mining players.
• Compared to auctions, IHO has the embedded auction functionality in addition to simple fundraising mechanisms. When IHO is completed, a market with sufficient liquidity will automatically be set-up for you.

Built on the Solana network, HydraSwap boasts a self-developed relay blockchain solution. This not only offers a superior TPS performance but also allows HydraSwap to be compatible with mainstream public chain assets, realizing the mutual trading between every pair of assets in the market. This was the basis upon which HydraSwap developed SmartTrade - a decentralized liquidity aggregation service.
Smart Trade can intelligently help detect the best way to route orders from liquidity sources, that can provide traders with aggregated trading to mitigate the possible risks of price slippage caused due to low liquidity. Based on this module, a major hurdle in DeFi arbitrage trading could be overcome, which is - how to find new opportunities for long-tail price spread arbitrage.

## 3.5 DEFI Arbitrage Module

The world of DeFi currently has multiple public chains that exist independently, without any support for cross-chain infrastructure. As such, Smart contracts with the same base, but on different public chains, cannot achieve Synergy. This provides arbitrage opportunities for speculators.
For instance, some new DeFi coins are showing with a 5-10% price spread between Pancakswap and Uniswap. This can be utilized by arbitrageurs. In some
AMM-driven liquidity pools, these arbitrage opportunities are even supported by strong liquidity. Hence, the success rate of arbitrage and sustainable funds can be calculated quantitatively.
The arbitrage system to be launched by HydraSwap will offer users a simple but intelligent arbitrage function, which allows users to participate in the smart contract arbitrage with no barriers. This would be a new additional option introduced in common DeFi staking. Meanwhile, as arbitrage opportunities in the market are fleeting, we would be encouraging users to conduct their arbitrage by directly configuring the smart contract settings provided by HydraSwap. Users could also choose to publish the arbitrage opportunity they found. Initiators would also receive corresponding rewards based on total user revenue.
Users who find arbitrage opportunities are dubbed operators. Operators can directly set the transaction fee parameters of the arbitrage contract and earn profits. However, they would be required to pledge their corresponding assets as a credit endorsement. If other users lose in their arbitrage trades, the assets pledged by operators would be leveraged as compensation while the arbitrage contract gets terminated. During the early stages of the roll-out, we will provide a simple arbitrage model that is based on DeFi Dex. Later on, more complicated arbitrage logic would be launched gradually via DAO governance.

## 3.6 One-Stop Mining

There are two key reasons behind mining:
a. Token distribution: For a full and independent financial system, currency issuance is primarily related to issues like 「To Who」,「How Many」, and「How To」. In its essence, token distribution is basically a mining plan that addresses the aforementioned issues.
b. Value anchoring and capture: Tokens initially have no value. Through mining, a simple 「input-output」ratio can be attached to tokens, which fulfill value anchoring and capture. For example, in a PoW based structure, miners earn their block rewards by investing in computational power and its maintenance, following which they trade their coins on a secondary market. The concept of 「Shutdown Price」has been derived from this.
Therefore, the process of mining can simply be defined as a means for token distribution and price anchoring.
The liquidity of funds is the core component of the ecosystem’s liquidity when it comes to price anchoring. DeFi is different from traditional industries as it has no self-constructed asset pool to provide liquidity. Thus, it can be concluded that the two main fundamentals behind the success of all DeFi projects are how to design a reasonable model for decentralized asset pools and how to encourage users to contribute liquidity using the interest mechanism. In the case of the profitable mining mechanism, the common concern shared by current DeFi miners is regarding the security of mining pools, such as unaudited smart contracts, hacking risks, misconduct by high authorities, etc.
As such, the mining contract proxy service developed by HydraSwap has established a secure and trusted mining distribution model based on the compound requests of smart contracts. This is an efficient token distribution channel and can effectively control the potential risks behind projects controlled by users. For the project teams, they can directly send tokens to smart contracts by configuring the mining parameters. The smart contract will automatically set up their liquidity mining pools, saving costs for a smart contract audit. Meanwhile, a dedicated interface for one-stop mining will automatically be assigned to users.
Users mining on HydraSwap’s dedicated mining interface would effectively be able to avoid faulty operations and misoperations. The credibility of smart contracts would also be ensured. Hence, users wouldn’t have to move to another platform to mine.

## 3.7 Referral Program

HydraSwap also supports the recording and utilization of referral relations. Users on HydraSwap earn token rewards for inviting others, and they get bonus rewards if his/her invitee participates in an IDO or liquidity mining. We believe this program can effectively help accelerate the community expansion and foster user growth on HydraSwap.
It is not complicated to write referral relations into smart contracts. However, this feature is currently limited by the low efficiency and high costs of current blockchain networks. As of now, the full potential of referral programs hasn’t yet been achieved on any DEX in the market yet. However, backed by Solana’s superior blockchain network, HydraSwap will be able to perfectly duplicate the referral program function, which is widely used by almost all CEXs, fully on a blockchain for the first time.

# 4. Security

## 4.1 System Security

We can all agree upon the fact the security is of the highest priority for any DeFi protocol. Before the launch of our product, all our smart contracts and future upgrades would be going through a strict technical audit. To maximize the decentralized characteristic of the smart contract, there is no Admin key in the protocol’s code. But this is not enough. We will also be inviting professional hackers to try and simulate an attack on our protocol. With this, we would be able to accurately evaluate the security level of our smart contracts.

## 4.2 Security of User Investment

Another concern is regarding the security of user investment. Users on HydraSwap can trade without permission. Even though operators are granted limited authorities, which enhances the security level a bit, users still need to carefully filter the trade settings and undertake corresponding risks. We will encourage our operators to adopt different decentralized oracle services to limit the risk parameters within the smallest range possible (set parameter as fixed if necessary), thereby minimizing the trust cost among users.

# 5. HydraSwap Version 2

The aforementioned content doesn’t fully include our vision for HydraSwap, but it is more of a pragmatic spirit, as we have decided to achieve all our product functions and goals by taking one step at a time. The content in this whitepaper solely relates to HydraSwap V1. We would start the development of V2 as soon as we complete V1. The primary additions in V2 would be centered around staking and options trading. Until then, interested users can refer to the HydraSwap V2 whitepaper to get a more detailed idea regarding function descriptions and technical solutions.

So far, we have introduced our vision for HydraSwap V1. To summarize, here are the main advantages of HydraSwap over existing DEXs:
• Superior Performance：The average 50,000 TPS throughput and less than 0.5s processing speed powered by Solana allow us to deliver a CEX-level user experience.
• Low Gas Cost： Almost 0 gas cost allows us to make complex interactions with smart contracts, such as the commission calculation for referral programs. This is impossible for those high-cost DEXs.
• Strong HMM Market Making Mechanism：High asset utilization rate, low price slippage, dynamic, and multiple market-making strategies. This ensures that a LP retains all rights.
• New Generation IHO Mechanism：Project teams can set up liquidity pools efficiently and effectively. The interests of both project teams and participants will be protected throughout the entire process of token issuance.
• Cross-chain Solution：This allows us to trade, deposit, and withdraw assets between different public chains with no boundaries. The cross-chain interactions are empowered with HydraSwap’s superior performance.

# 7. Token Issuance and Governance

## 7.1 Token Issuance

HYS is HydraSwap’s governance token. Its total supply is 100,000,000. HYS is an SPL token issued on Solana. Through our cross-chain bridge, it can be swapped for BSC, HECO, or ETH-based assets (or other public chain assets), and can be circulated within the financial ecosystem of different public chains. The token distribution plan of HYS is indicated below:
A. Liquidity Mining --- 40%
Used for early stage liquidity mining incentives. Vested in 48 months.
B. Early Investors --- 11%
Seed round and strategic round funding. Vested in 12-months.
C. IDO --- 0.5%
Initial Dex Offering. No lockup.
D. Treasury, CEX, AMM Liquidity --- 5.5%
For CEX and AMM liquidity adding and the treasury prepared for market campaigns or extreme market situations.
E. Ecosystem Fund --- 12%
Used for sustainable community incentives and ecosystem development, including incentives to community partners, cross-chain bridge notaries and other ecosystem cooperative partners. Vested in 48 months.
F. Teams --- 23%
Used for incentives to founding team, including community operators and smart contract developers. Vested in 48 months.