Grant: A slippage free trading solution for the OPEN DAO stable coin suite

USDO and other synthetic currencies can now be minted using a fork of Compound at omnicomp.ocp.finance

The design here is quite simple yet effective. USDO is minted via admin (And soon enough via DAO votes), but it enters circulation only when it is borrowed against at omnicomp.

This effectively separates USDO minting from the so called minter at omnicomp and allows us to have potentially many minters.

For instance once the boys at OCP have vetted our tech design in BSC we will bridge USDO to ETH and replicate the same tech design there to launch ETH version of USDO and other currencies.

This means that you can mint USDO on both ETH and BSC and potentially other networks as well in a native manner and also be able to port your minted tokens to other networks without the need for different token contracts.

Separating the mint from the minters also drastically cuts down the chances of any hacks. The chances of a rug pull still exist but that is where we want to hand over the mint to the DAO as soon as possible.

USDO peg is established via interest rate adjustments and redemptions against the collateral via the liquidations module.

But beyond that we need to create utility for all these currencies.

To that effect we have established partnerships with property developers, accountants and more in the real world who are willing to accept our synths in lieu of payment for their products and services.

In addition we also need to revv up onchain demand.

Speculation and trading is probably the most popular use case. We need a trading platform like Synthetix or Mirror etc where these synths can be traded. An AMM based solution that uses Uniswap or other forks like pancake wont work because these are price maker solutions. Not price takers.

We need an exchange that works off Oracles which means it is a price taker solution.

In due course limit orders can be introduced. But a price taker solution also will help establish the peg for our currencies.

For this we are dusting off our old cashbox v0 code, launched way back in Sep 2020 (sounds positively ancient now).

It is a simple exchange solution for 2 tokens.

Consider 2 tokens A and B

Their rate is 1:1

Tom has 100 A and Jerry has 100 B. They dont know each other, but Tom wants 100 B and Jerry wants 100 A.

Tom puts 100 A in a smart contract and gets issued 100 claim tokens.

Jerry puts 100 B in the contract and retrieves the 100 A sitting in there.

Tom can now deposit his 100 Claim tokens and get the 100 B deposited by Jerry.

Very simple!

This contract can be used by many different people as long as they want to swap A and B tokens.

Which means if Tom has 50 A, Harry has 50 A and Jerry has 100 B it can still work in the same manner as before.

While upgraded versions of this contract exist, the lowest version allows claim tokens for only one side.

This means that if Jerry has 100 B tokens and wants A tokens but no one has deposited them yet, he just has to wait till such deposits arrive. There is no mechanism for claim tokens on both sides in v0 and v1 contracts. V2 solves for this issue but we are intentionally choosing v0 because we want to keep the UX simpler.

The contract also supports price updates.

The design is a bit like a fund, so let’s use a slightly different terminology.

Instead of token A we will say cash.

Token B will be shares.

Rate will be price (expressed as cash per share or simply dollars)

Claim tokens can be called as units.

Let’s say the starting price is 1 or 1 cash per share.

Tom puts 100 cash in the fund, he gets 100 units.

This 100 cash is now claimed by someone who puts in 100 shares.

The contract now has 100 shares and the 100 units have a claim to 1 share each.

Now there is a price update and the price of each share is 2. Or 2 cash per share.

The market value of the contract is 100 shares or 100*2 = 200 cash eq.

If now Jerry comes and puts 100 cash in the contract, the contract will have a market value of 100 shares (200 cash) + 100 = 300 cash.

Jerry will get 50 units for his 100 cash. There will now be 150 units in circulation.

If either Tom and Jerry decide to redeem their units, say 50 of them, then they will first get 50 shares for them.

The next 50 units will also get 50 shares (there were 100 shares in the contract).

The next 50 units will however redeem 100 cash.

If Harry tries to sell shares to the contract, the contract first checks if there is enough cash sitting there.

For instance if the price of each share is 2 cash, and Harry tries to sell 50 shares, then he will get the 100 cash which is sitting there.

However if Harry tries to sell 100 shares the order cannot be filled and the message should be please lower your sell order to 50 shares (Cash in the contract/price).

From an implementation perspective for establishing a trading pair between EURO and USDO, two contracts of the above nature will be setup.

One allows you to sell Euro for USDo and the other allows you to sell USDO for EURO.

The reason why 2 contracts are needed is because it keeps the user interface simpler.

We do not want to hassle the end user with having to deal with unit tokens etc.

They simply rock up to the trading platform, place an order and if liquidity exists the order gets filled and if not then it does not.

On the other side we will setup 2 bots which act as counterparty and deal with all the unit or claim tokens etc.

You can deposit funds in these bots and get a token representing your position.

Those who want to provide liquidity can do so by depositing USDO or EURO in either bot.

They would get bot1 and bot2 tokens respectively.

The bots would deploy to the individual swap contracts and serve as the counterparty to those who seek to swap.

Note that this entire solution is a price taker, not a price maker and is designed specifically so as to serve as a mechanism to help the peg for the currency synths we have developed.

If someone wanted to sell USDO and buy EURO, they would be served up a UI that will redirect their transaction to either of the swap contracts based on what they wanted to do.

If EURO to USDO was trading 1:1.25 then selling EURO on Box 1 would get you 1.24 USDO and buying EURO would cost you 1.26 USD. The spread goes to the counterparty bots.

Note that anyone else is also free to be a counterparty alongside the bots we setup.

Separately there would also be a scaled BNB fee which would vary based on the size of the order. If someone tried to drain the entire liquidity by frontrunning the oracles they would be slapped with a significant amount of fee that would effectively negate the benefits of doing so.

This fee can be done in an exponential manner, so that the fee is small at amounts that are small portions of available liquidity but increase exponentially if the entire liquidity is attempted to be drained.

Those who provide liquidity would earn fees via the spread.

The bot would also trade between the boxes.

For instance if you deployed to a USDO bot, it would deploy to the USDO seller contract, but once it receives EURO, it would then go ahead and deploy all the EURO to the EURO seller contract. It would continue to do so by periodically monitoring its positions.

The bot itself would then own a bunch of CB1 and CB2 tokens based on where the funds are deployed at any specific time.

When someone wants to redeem their bot tokens, they would get their prorated CB1 and CB2 back. This can be then redeemed for USDO and EURO respectively. And the user can then go back to a specific currency using the swaps himself.

All of this can be automated as part of the UI UX.

It is necessary to have 2 bots because it becomes impossible to track who owns which Cashbox tokens otherwise.

50000 OPEN tokens would be allocated to any team that develops the above solution.