🔐Artichoke Alpha Phase Report
This report is a compilation of our findings during the Alpha Testing phase of Artichoke protocol and implications for further development.
Liquidity Fragmentation and Management
It is apparent that Uniswap is leading liquidity management innovation. They’ve built the go-to AMM almost every DeFi protocol relies on, sparking innovation across the entire DeFi ecosystem – much of it happening on Arbitrum.
Artichoke's primary intention is to create a new building block on top of AMMs and provide a solution that helps new projects build strong and deep liquidity – mitigating the challenge of liquidity fragmentation.
To put it simply: liquidity fragmentation occurs whenever 1 USDC (considering most liquidity is held in USDC) is deposited in any AMM across any blockchain, as that USDC only provides liquidity to one asset at a time in that particular blockchain.
The main problem liquidity fragmentation introduces is increased slippage when swapping assets.
Slippage is the difference between the starting and final price P0 and PF that averages the swapping price and stacks with every step (or “hop”) in the swap.
Considering a single liquidity pool comprised of reserves X and Y (which determines P0 = X / Y) and reserves deltas dX and dY, assuming a user wants to swap dY we can calculate dX (the amount the user is receiving) as:
Where is the trading fee which depends on the AMM configuration.
Evidently, the most important ratio in the formula is dY / Y in the sense that if Y is higher and dY is constant the dY / Y “impact ratio” will always be lower in that specific pool.
Until Artichoke’s approach (and, paradoxically, the spirit of Uniswap V1 which inspired most of the innovative concepts we are developing, combined with this UniV4 discussion closely resembling our tCHOKE design in their governance forum) any Y asset underwent triple fragmentation in the following order:
A specific liquidity pool
A specific AMM instance
A specific blockchain
In practice, this means that 5.000.000 USDC (Y asset) evenly distributed among 5 different liquidity pools generates, in turn, dY / (Y / 5) “impact ratios” when swapping any X asset - we are looking for lower impact ratios.
As mentioned before, this effect stacks with every hop between liquidity pools in the swap even when the swap is happening “intra-ecosystem” (when swapping using only Uniswap liquidity pools, for example) – compounding its negative impact for the trader.
So, even when liquidity might be available as is already deployed in the AMM, the “usable liquidity” for every swap is minimal and liquidity providers face the difficult decision of answering the question “which pool will have the most volume this week?”, risking the underlying value in terms of opportunity cost of any asset they might hold.
Considering the current state of AMMs, users do not have any tools to rely on when assessing options for deploying their funds to provide liquidity - which is one the most critical actions for the whole crypto ecosystem.
Things are changing, though. There has been a lot of active discourse about liquidity management lately all over the industry and we are proud of being part of the discussion, despite the challenges and opportunity costs this represents for the Artichoke Protocol.
Since we started building Artichoke natively on Arbitrum a lot has happened:
Uniswap announced the development of Uniswap V4 and the long term vision in which they expect liquidity to concentrate within the Uniswap protocol instead of the numerous emerging forked Uniswap-based-AMMs which contribute on deepening liquidity fragmentation and ecosystem inefficiency
The entire industry is consolidating around the rollup / L2 vision, which we expect to also fragment liquidity if not handled properly by builders and liquidity providers. The emerging cross-messaging capabilities between multiple rollups and Ethereum itself enable what is known as DeFi pooling, where funds are held in one blockchain (to be simplistic, increasing the amount of Y asset available and therefore usable in that particular blockchain) but are deployed/used via transactions happening in any other blockchain.
Technical takeaways & audits
As most of our colleagues in Arbitrum know, building (not forking) a DeFi protocol and having it be as composable as possible with the entire ecosystem is a major challenge.
There are a lot of both technical and financial moving parts that should be properly audited in order to avoid incurring inconsistencies - furthermore opportunity costs are high, as once the protocol is deployed, migrating liquidity is challenging for users.
In early June 2023 we deployed the first minimum viable product of the strategies the Artichoke protocol will use to manage liquidity and started experimenting with hedging LP positions across all available liquidity. We also analyzed the first version of the synthetic asset tChoke, which is the liquidity connector asset between all tails.
Findings:
Providing the same available aggregated liquidity (in terms of USDC), TailManagers are successfully able to utilize it up to xN times (being N the amount of tails the Omnipool is built on when comparing with N individual pools) given the asset if sufficiently liquid in secondary markets and tChoke price volatility is up to 5% over a 24h period.
Initial approximations for “sufficiently liquid” is that liquidity held outside Artichoke is at least 83-85% higher than in the protocol itself.
Liquidity in arbitrage relayers between tails and outsider liquidity pools must be incentivized from within the protocol based on the configuration of each TailManager. Incentives need to be in place, in order to properly ensure a healthy arbitrage liquidity and competition and it will be desirable to include providing arbitrage liquidity features in mid-term.
tChoke price for minting and redemption must consider a weighted value of assets deposited in the sum of tails and token weights should be variable depending on secondary markets conditions as well as protocol governance - given the impossibility of considering overall market condition, with CRV as a leading the example nowadays - this implies the need and challenge of setting up a reliable liquidity oracle for each new tail upon creation besides the underlying concentrated liquidity pool TWAP.
A “perpetual representation of liquidity” can be created from these specific parameters.
a) Important note about this aspect: we are really excited about the possibility of creating perpetual instruments using different Artichoke parameters since, with sufficient liquidity deployed, they might represent an oracle for novel tradeable indexes.
What needs to be improved
The optimal tChoke volatility and correct -safe- weighted values are still to be exactly determined. While the first contributes to liquidity efficiency on each tail, the latter ensures that attack vectors are minimized, which will be especially important if tails are created frequently. A better simulation should be carried out as deployed strategies are not fully representing the theoretical behavior we expect tChoke to have.
Deploying Artichoke on a specific AMM might contradict the ecosystem trend, especially considering the announcement of Uniswap V4. Initial design was too AMM-specific and the on-going liquidity fragmentation definitely jeopardizes both liquidity positions as well as protocol configuration parameters. Without partnerships with liquidity aggregators or proper incentives, newly listed tokens might struggle with getting enough traction.
What is uncertain yet
Hedging positions and therefore minimizing impermanent loss is the highest impact attack vector of the protocol. While auditors were unable to fully drain a TailManager, there are some time-sensitive operations not working as expected in the initial design. Besides this, although impermanent loss is always undesirable, there might be some considerations the trader is making which should not be assumpted by the protocol. We are thinking about a “risk-aversion plugin system” that lets each user choose the amount of risk willing to be taken when creating a position.
Plunge protection optimal configuration - we will cover this item in a separate article.
Outlook
With these reassuring outcomes of Alpha Phase, which reaffirmed our design choices and the underlying concepts of Artichoke, we are excited to go forward towards public MVP deployment - a detailed action plan will be published shortly as it is out of the scope of this report.
We thank our community for the patience and support as well as our audit & testing partners for their time and feedback
Last updated