This piece is a continuation from The Real World Asset Enforcement and Liquidation Protocol article.
For a TLDR, watch our new video on how the CashBox system works below
To create an efficient liquidity layer on top of real world assets, we are replacing Uniswap in our architecture below with a custom solution.
The problem with Uniswap (or other AMMs such as Balancer or Bancor etc) is that they are capital inefficient liquidity solutions because the LP has to provide value on both sides of the equation. In Bancor and Curve, you can choose to supply value on just one side, but it does not mean it will work just with that. Someone else still needs to cover the other leg, or as in the case of Curve, they convert part of your supplied asset to meet the necessary requirements.
Secondly, the price of both supplied assets also varies in Uniswap. So in the case of real estate backed collateral where it should not be as variable, we face an issue. Technically this can be arbitraged away, but the nature of the slow moving underlying collateral liquidation process means that it would cause more problems in the short run.
And then the question remains, where does the LP even get the collateral tokens.
What we really need is a simple cash box, where people who are LPs supply cash (stable) tokens such as USDC/USDT etc.
This cash box becomes a perpetual counterparty to anyone with collateral tokens. There would be a price feed which determines the collateral tokens price.
In effect the pool acts similar to an investment fund, and the price of its newly minted pool tokens reflects the price mechanisms of an investment fund.
So on day 1 if someone supplies 100 USDC to the pool, he will get 100 Pool tokens (PT) that represent his claim on the pool.
Let’s consider that this pool becomes a perpetual counterparty to a tokenized share called APL.
APL price on day 1 is 10.
Someone approaches the pool with 5 APL tokens and claims 50 USDC that are sitting in the pool.
The 5 APL get added to the pool.
In the pool now there are 50 USDC and 5 APL.
If someone tries to redeem 10 APL, that will not work (prevented in the UI itself) as the pool does not have enough liquidity.
If someone tries to redeem 5 APL again, then it should only withdraw from the USDC balance.
Which means 5 APL go in and 50 USDC go to the redeemer.
New pool balance is 10 APL.
Let’s say the APL price now changes to 20 via price feed.
The PT in circulation are 100, and value of APL is 10*20=200
This means the price of PT is now 2 (changed from 1)
If someone now tries to supply USDC to the pool to mint PT, then it will be based on this new price.
If they supply 100 USDC, then they get 50 PT.
If the price of APL goes down to .5, then the PT AUM is 10*.5=50
New PT price is hence .5
And if someone supplies 100 USDC they get 200 PT.
The Pool hence behaves like a fund that mirrors the price of the collateral it is acting as a counterparty to. It will however be also very cash rich and still give the LPs fairly accurate exposure to the price of the collateral token.
When the PT holder wants to redeem, they should get APL and not the USDC they put in.
So using example 1, current PT in circulation is 150 and Pool has 100 USDC and 10 APL.
Price of APL is as dictated by the price feed oracle.
Assuming we used the first example where APL price was 2, and if the PT holder tries to redeem 50 PT, then it would work as follows.
Price of PT is 2, value of 50 PT is hence 100
Price of APL is 20, which means 5 APL will flow from the pool to the PT holder and PT will get burnt.
At this point the pool will have 100 USDC and 5 APL.
And the circulating supply of PT would drop by 50 down to 100.
Price of PT remains unchanged as assets and tokens have gone down proportionally.
Now consider that 100 PT are set for redemption.
100 PT are worth 2 each, which is total 200
Price of APL is 20, which means 10 APL are needed.
But the pool only has 5.
So the way it will work is all 5 APL will go to the PT holder.
And then another 100 USDC will go to the PT holder.
100 PT get burnt.
So the system will always try to redeem the maximum extent of APL first in return of PT burning and if it cannot satisfy then it will try to complete the redemption request via the USDC.
So the flow is:
USDC goes in and PT comes back.
APL goes in and USDC comes back. If not enough USDC, then prevent transaction.
PT goes in and APL comes back. If not enough APL then balance is covered via USDC.
Price of APL is fed in via price feed.
Price of PT gets updated based on AUM and determines the number of new PT to be minted.
Make provisions to have ability to pause deposits and withdrawals of all tokens.
Such a solution would in theory also allow us to market the liquidity pools as assets in their own right that mimic the price of the assets they are counterparty to. So there could be a Tesla, APPLE, FB, Real estate or other such pool and become attractive assets in their own right due to their permissionless acquisition.
Once you have the APL you can approach the registry platform and convert back to real assets as described in the whitepaper.