In this article we delve into the technical details of Slipstream, Velodrome's concentrated liquidity pools, including the challenges we faced in implementing a friendly user experience without compromising on decentralization.
While we continue working on the documentation and refining app screens for Slipstream, we hope this write-up will engage and inspire developers who share our values to join us in building the next generation of 100% onchain products everyone will love to use.
Why build Slipstream in-house?
Concentrated liquidity pools (clAMM) have proven to be a highly effective design for delivering low slippage onchain swaps. Early on we understood that, combined with Velodrome's liquidity engine, clAMM pools would have the potential to capture a growing share of volume on the Optimism network.
After careful consideration, we decided Velodrome would be best served if we designed a personalized implementation of clAMM for several reasons:
Buying an existing solution was too costly and contradicted our promise to token holders of sharing 100% of protocol rewards.
We couldn't find an efficient, decentralized AMM implementation that suited our product needs.
We believed we could create a concentrated liquidity solution requiring less maintenance, making it more user-friendly and sustainable.
The layers cost
Every layer of composability in DeFi incurs fees. This is rarely openly discussed, but that's how protocols make money.
If Velodrome were to acquire a license from a third party to operate the concentrated liquidity pools, this would cost the protocol a share of the fees the pools generated, on top of the cost of licensing its use.
Any new deployment of the same pools would then also require additional costs and leave Velodrome at feature parity with competing protocols owning the same license – all of this at the expense of the overall product experience.
In terms of operations, Velodrome would depend on the security and development speed of the vendor, which would lock them in a difficult position if other partners of the vendor get priority with updates.
So far Velodrome has managed to build robust functionality into just one layer. It charges zero fees for:
Incentives
Relay, also known as compounder/convertor
Best-in-class voting dashboard
Slipstream (and yes, we’ve removed the protocol fees)
All features that in other ecosystems are often operated as independent layers, each extracting its own fee.
With the introduction of Slipstream, non-staked liquidity is subject to a special fee, which has a 10% default value and can go up to 50%. All of these fees are bundled with existing pool fees and directed to voters.
Building a true decentralized exchange
Most decentralized exchanges continue to run on Web2 infrastructure. With the launch of Velodrome v2, we've transitioned entirely onchain while maintaining competitive UX and efficient product updates, setting us apart as potentially the largest decentralized AMM product today. Our onchain API and IPFS web app contribute to this achievement.
Note: the decentralization of the protocol operations via open governance remains a top priority and is planned to take place later this year.
During Slipstream's R&D phase, prioritizing decentralization was a challenge. We initially considered forking an implementation and automating staking and rewards functionality. However, our commitment to decentralization led us to fork the most proven open-source concentrated liquidity implementation and push ourselves to rebuild staking from the ground up.
On Velodrome, liquidity providers receive emissions while trading fees generated by a pool are distributed to those who voted for the very same pool.
While designing Slipstream, we faced two main functional challenges: how to stream VELO incentives to liquidity providers in a capital-efficient way by taking advantage of all the features of concentrated liquidity, as well as how to fetch all the fees that were owed to the gauge for distribution to the voters.
For the first issue, a variable known as RewardGrowthGlobalX128
was introduced, similar to that of FeeGrowthGlobalX128
. This variable represents the reward growth of emissions collected per unit of liquidity for the entire life of the pool, and makes calculating rewards simple as we can compare the current value to a historical snapshot to determine what portion of rewards are owed to the user.
The second issue arises from the fact that liquidity deposits in Slipstream are not fungible by definition. Consequently, fees that should be awarded to voters must be collected separately for each position.This issue was remedied by repurposing the collectProtocol
function to bulk collect all fees attributable to the gauge. Thus, on every swap, we would calculate the gauge’s share of the fees (proportional to the amount of liquidity staked) and then, once per week, would pull all the fees into the gauge. Fees levied on unstaked liquidity are collected in the same way.
Today we're happy to say that Slipstream adds no overhead to the protocol’s maintenance and does not compromise Velodrome’s decentralization.
Designing user-friendly concentrated liquidity
Velodrome is designed to reward liquidity providers. With Slipstream, VELO emissions flow exclusively to the liquidity staked within the price range boundaries of the pool's active trading price. In the context of concentrated liquidity, this could create an even larger competitive advantage for professional market makers using concentrated pools.
To reduce the constant need for re-balancing a deposit to remain within the incentivized price range, we've redesigned the minimal price range boundaries (tick space) based on the liquidity factors.
We came up with the following generally available choices for the concentrated pool types:
For stable token pools, use a price range boundary of 0.5% (tick space 50) for tokens like USDC, DAI, LUSD
For volatile token pools, use a price range boundary of 2% (tick space 200) for tokens like OP and WETH
In addition to these, two more options are available on demand:
For highly correlated tokens like stable coins and liquid staked tokens, a price range boundary of 0.01% (tick space 1) is available
For emerging tokens like AERO and VELO, a price range boundary of 20% (tick space 2000) is available to reduce liquidity pool re-balance needs
Finally, the pool fee was also redesigned to be adjusted independently from the pool type. Fees can now reflect partner protocols’ needs and can be adjusted based on the market's volatility. To reduce operational overhead, we are working on a dynamic fee module that will adjust itself on demand.
Keeping the web app intuitive
Slipstream brought some design and user-experience challenges–particularly with respect to the liquidity deposit flow, which has been redesigned probably three times by now.
While we were very happy with the intuitiveness of Velodrome v2’s existing flow, the introduction of concentrated liquidity, where a pool can have multiple deposits—both staked and unstaked—forced us to reconsider how we display deposits and let users manage them. With Slipstream we've added a simple (and hopefully straightforward) way for everyone to add and create new liquidity pools that should scale across any new potential pool implementations.
This opens up flexibility not just for basic (also called constant product or v2) pools, where all deposits cover all of a single price range (zero to infinite), but for any new type of pools, including concentrated pools, which can have multiple deposits, each responsible for a specific price range.
We've also made it easy to add or withdraw liquidity at any time, even if the existing deposit is staked, all reported in real-time by our dashboard fetching data directly onchain. We believe we can make the app even faster, so another engineering challenge for us is to keep optimizing the RPC reads further on to reduce even more the screens loading and refreshing time, and thus the number of RPC calls and costs.
To keep the web app light, most of the underlying math around ticks and Q96 notation values was also moved onchain, which helps maintain high precision in deposit estimates while adding a single new dependency: the charting library (which you will see soon as part of the liquidity distribution chart in the deposit screen).
We have a strict policy on the third-party libraries added to the web app, so it really makes us sleep better at night knowing our dependencies footprint is minimal.
Finally, we are happy to say that v3 of the web app had a net zero impact on the codebase size:
169 files changed, 3879 insertions(+), 3837 deletions(-)
A note on security
Slipstream is a fork of Uniswap v3. And we've tried to do our best and build on top of the good things our friends brought onchain. The challenge here was to make only strictly necessary changes to the existing implementation due to the complexity and risk of introducing any regressions or potential security issues.
We went with the most stable version built on Solidity v0.7.6 and for every one line of code, we've added two more in tests. Overall, from approx.
407 files changed, 35986 insertions(+), 5192 deletions(-)
the tests folder shows
195 files changed, 25886 insertions(+), 1984 deletions(-)
We achieved this by maintaining the existing test coverage (both regular and invariant) and extending it to include coverage for the new features. The strong test coverage was very welcome and helped a lot with the audit from our friends at Spearbit.
On top of our features, we've also made changes to support popular community requests, such as:
NoDeletageCall removal
Universal Router optional support for permit2 in favor of ERC20 allowances
Universal Router unspent ETH refund, audited by Jeiwan himself
Ability to create a pool when minting with the position manager
Position manager unspent ETH on deposits refund
Return of the emissions if a gauge has no staked liquidity
Closing notes...
We'd like to say thank you to everyone on the team for the incredible work we've put into this release, and to our partners who trusted us and supported our vision.
If the problem-solving challenges we're sharing resonate with you; you feel excited about building onchain products for the next billion users; and you enjoy working with small, dedicated teams, please reach out!
We'd be happy to hear from developers with front-end experience who will complement our team and help us lead Velodrome to be the Superchain MetaDex.