bashoswap
Search…
⌃K

Whitepaper

This is only the DEX part of Bashoswap. Currently it doesn't restrict trading to a stablecoin because the Bashoswap stablecoin hasn't been developed.

General design

Uniswap v2's design is the base. i.e. we have liquidity pools, product of liquidity pool must never decrease through a trade, adding to the pool gives you the geometric mean of what you added as liquidity pool tokens, when you withdraw you get back a portion of the funds corresponding to your geometric mean / the geometric mean of the whole pool.

Throughput solution

We have global mutable state in the form of liquidity pools. We need to ensure that users can operate on this shared mutable state in a timely manner.
Considering the properties of Cardano, small transactions are more likely to go through due to the FIFO nature. Because of this, we want the transactions of the protocol to be as small as possible.
We employ "sharding" to reduce the contention of the protocol. Once a liquidity pool is used often enough, it will be split up. If a liquidity pool isn't used often enough, it's a candidate for merging with a liquidity pool with the same pair of tokens.
End-users who want to interact with the protocol will generally create one transaction per liquidity pool, in such a fashion that only one of them can be accepted (by making them all consume a shared UTXO).
Due to the limited size of liquidity pools, larger trades will have to be split into multiple trades.

Transaction chaining

It is likely possible to chain transactions such that transaction A with output Ao and transaction B with input Ao can be put into the same block.
If it is not possible, it is likely simple to implement such a change in Cardano and have it be accepted via a CIP.
Through this mechanism, users can cooperate off-chain to reduce contention, such that a user can consume a liquidity pool output by the trade of another user in the same block.
Security
FIXME: We need to figure out a way to make honest users more successful than dishonest users. Intuitively there should be a way.

Sharding

We will have the concept of "superblocks", which will be a specific span of time, e.g. 10 minutes. Each transaction must have a validity range that matches the current superblock exactly. If the superblock changes, then we will look at how many trades happened throughout the last superblock. If more than some threshold happened (e.g. once every 10 seconds on average), then the user must split the pool.
If a pool is used less than some threshold, it is a candidate for merging, notably this means a user has the option of merging it with another pool of the same type.
Minimum ADA
For pools that trade with ADA, this is easy to satisfy. For other pools, however, this is highly problematic. The solution is to have a small ADA fee too for other pools, that can cover splitting.
Pools that trade with ADA will be called ADA pools, other pools are non-ADA pools.
Non-ADA pools will stop accumulating ADA fees once they reach some threshold.
Once all liquidity is withdrawn from a non-ADA pool, the ADA will be donated to the protocol, and be locked up within ADA fund UTXOs.
If when splitting a non-ADA pool, we don't have enough ADA to create a new UTXO, we can cover the remaining ADA by either taking it from another non-ADA pool, or by taking it from an ADA fund UTXO.
When merging non-ADA pools, the contained ADA is simply combined.
Limits on how many pools you can use
By using more pools at once, you effectively have one bigger pool, which means that the trade will be more fair, as the ratio(s) will be offset less. However, there should be a balance, such that it's not most cost-effective to use all pools always, since that would ruin the point and the throughput. It should be such that a trade, if possible using a subset of the pools within while keeping the change to the total ratio under some percentage, then the trade should be rejected.
Liquidity pool tokens
There is the question of how to handle liquidity pool tokens. When a pool splits, then we need to split up the liquidity pool tokens between the two new pools. Adding funds to one of the pools must also not mean you can withdraw from the other.
To achieve this, when splitting, the token name changes. We however create a new UTXO per new pool that contains the corresponding (i.e. half) amount of the old LP tokens but with the new name. We can withdraw from this UTXO if we burn the corresponding amount of the old LP tokens.
When we merge, we do the same thing but in reverse. The UTXO now supports burning either of two LP token types.

Parameterisation

There are a lot of parameters here that we can not know the optimal value for. All parameters are local to a single pool. The parameters should be controllable by the creator of the pool. The parameters could potentially modify the script hash, but to keep the protocol simple, we avoid this and use a single script and pass in the parameters "at run-time". The parameters can be stored in a separate UTXO that is referenced to reduce the size of the datums.

Formal specification

This will be done in Bashoswap's internal specification language which is to be open sourced. This will concretely define the exact semantics of the protocol.

Bash Token

$Bash will be the native Utility token of the Bashoswap platform with several utilities.
We aim to evolve into a decentralized Autonomous Organization (DAO) where decisions are taken by $Bash token holders, based on the amount of tokens they hold.

Bashoswap Token Utility

$Bash Token will be utilized in the following ways:
Staking: Basho token Holders will be able to stake $Bash tokens to generate additional yield earned from trading fees.
Governance: Governance model allowing for stakers of Bash to participate and vote on community proposals and amendments.

12: Bash Token Distribution

The Bash Token distribution is described as follows:
Token Name: Bashoswap
Token Ticker: BASH
Max Supply: 500,000,000
Our token mechanics are structured so that there are a multitude of influences for material appreciation. Starting with growing transactions and constant onboarding of new clients we start to build a higher use for our token and a higher demand. With this kind of assistance to the velocity of our token along with its use in crypto trading, it can measurably reach its true intrinsic value.
With the growing use of the token by businesses on the platform we effectively reduce price risk relative to the dollar for all holders, setting a comfortable base for which we can assume, following price discovery on exchanges, our cryptocurrency will not fall through. This also sets the investment standard for traders to buy knowing that eventually, $Bash tokens will reach certain support levels where there is only more upside as we grow.
We encourage the reader to do its own research, and decide whether to invest in our project or not.