As a sign of continuous commitment towards better security and full transparency the collective is sharing the incident report on that day.

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

Cooper

@cooper_kunz

we just need one more layer of abstraction bro and i promise users will love it and still be able to be their own bank. all it takes is just one more abstraction it'll all make sense i swear bro just one more

17

2:57 PM • Dec 11, 2023

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.

Quick recap of how the protocol works. Let's start with a simplified visual representation.

Velodrome is a protocol designed to enable token swaps by attracting liquidity. The protocol rewards liquidity providers (LPs) with VELO token emissions (from the Minter), which are distributed to liquidity pools proportionally to the votes each pool receives (casted on a weekly basis by Voters). Liquidity providers must stake their deposited liquidity (in a Gauge) to receive VELO tokens. VELO holders can lock their tokens to vote on the distribution of emissions.

The protocol is 100% immutable, so changes to the protocol mechanics are not supported. As a result, the Minter will distribute tokens based on the same rules in perpetuity.

New version requirements

Velodrome V2 will enable major features such as the concentrated liquidity support, dynamic fees, dynamic emissions rate and Relay, that will enhance Velodrome's performance and user experience.

Developing the best possible version of these features, however, required redesigning the protocol from the ground up.

Since immutable code cannot be changed, Velodrome V2 contracts are designed to interact with V1 to introduce new functionality (e.g., concentrated liquidity) and enable periodic maintenance tasks.

Velodrome V2 will still be 100% immutable, but it will come with:

• a liquidity pool factory registry, which allows us to add new liquidity pool types (eg. concentrated, multi-tokens, custom pools)

• updatable gauges factory, to allow us support maintenance for these new pool type gauges and reward contracts

• updatable rewards/bribes factory, to allows us in case of a security incident, to provide quick and long-term maintenance

The architecture of the V2 emissions

To help understand the V2 emissions design, here's a simplified visual representation of the V1 and V2 changes (dotted lines).

To allow the new functionality, Velodrome V2 will issue a new VELO token, convertible 1-to-1 with V1 token.

Both versions will operate in parallel to minimize disruptions and keep the emissions running according to the expected schedule.

With the old token captured and locked in perpetuity, the new token will take over naturally and follow the same emissions schedule and operational purpose.

As you can see in the diagram, once the voters switch to using the new V2 voter, the rest of the mechanics are identical to V1.

The process for migrating tokens from V1 to V2 will be as seamless as possible for end-users and partners. Their VELO tokens and locked positions (veNFTs) will be easily convertible to V2 versions.

V1 token convertor

To allow our users to redeem the V1 tokens for V2s, we designed a special liquidity pool, called $VELO V1-V2 Convertor Pool, that will accept V1 tokens for V2 tokens at a 1-to-1 rate.

The pool can be used as a regular pool by our routers or partner aggregators, thus facilitating a seamless conversion of new tokens. Similarly, holders of V1 locked positions will be able to convert their veNFTs to a V2 equivalent with the same vesting time and underlying locked token balance.

The V2 tokens will be provided directly by the new minter contract, via a management contract, called the SinkManager.

Capturing V1 tokens

Since V1 token will be emitted in perpetuity, the migration process will leverage Velodrome's existing mechanics to capture and lock all V1 tokens:

1. The SinkManager contract will receive all V1 tokens and V1 veNFTs from the convertor.

2. The SinkManager will lock the V1 tokens and merge the V1 veNFTs into a single veNFT.

3. The SinkManager will use this veNFT to vote in perpetuity for a dummy pool created with tokens owned exclusively by the same contract.

4. The SinkManager will capture 100% of the emissions directed at the dummy pool and continue locking them into its veNFT.

By locking converted tokens and capturing all emissions controlled by its veNFT, the SinkManager's share of voting power will trend towards 100%, ensuring that V1 token emissions remain contained within the contract.

Once live, protocols will direct voting rewards (bribes) to V2 gauges, which will incentivize V1 token and lock holders to migrate their positions to V2 as early as possible.

V2 emissions

The V2 minter contract will follow the same schedule as the V1 minter, with a theoretical start of 15M tokens in the first epoch and decaying at a rate of 1% per epoch. In other words, V2 tokens will be emitted at the same rate of V1 tokens.

However, the first week emissions for V2 will be slightly higher, since the lock rate will be close, but not identical to the one registered in V1.

This is an expected outcome, and was accepted by our audit partners. It will also serve as a minor incentive for users and partners migrating early to V2.

Next steps

This is probably the most technical part about the way Velodrome V2 works and the efforts the whole team took in order to make it still one of the most accessible DeFi protocols, despite the complexity.

If you're a partner, we will be reaching out to you to help with the development challenges or any support guidance.

If you're a user or a protocol, please keep an eye on the official migration announcements. The new app will provide a step-by-step walkthrough for migrating your tokens and liquidity positions.

For more questions, please reach out to our dev team on Discord, we'll be happy to answer any questions.

LP delegation would give owners of tokens in liquidity pools (LPs) the ability to vote to delegate their votepower to participate in governance for their relevant protocols. This feature would be particularly relevant to Optimism, where governance plays a large role in the ecosystem’s developments, including grants for emerging protocols.

The LP delegation idea came to us after reflecting on our Governance Fund 1st Phase Proposal, one of the toughest secured grant by any project on Optimism so far.

Velodrome faced a contentious debate, leading to over one hundred replies and thousands of views back in November. The discussion thread went through multiple lockups due to the heated arguments it hosted. We even deployed and minted NFTs to major OP holders to encourage participation.

While we won the grant through voting, enabling our Tour de OP program, we became sharply aware of the importance of governance when participating in a voter-led system.

LP delegation would unlock voting power for tens of millions of OP in liquidity pools across DEXs on Optimism. However, due to current limitations, and still an early development stage of alternative solutions, we have postponed any implementation until an optimal solution is available.

We’re happy to share our findings: why LP delegation matters, its shortcomings, and its potential implementation details.

How Delegation works

The basic ERC20 token delegation, which was introduced by Compound and popularized by OpenZeppelin, gives voting power to each token holder, where 1 unit of a token equals 1 unit of voting power. The full voting power of one address can be delegated to another address of choice. The voting power is then used to create, vote, and pass proposals for the relevant protocol.

Why do we need token delegation

Staying up to date with developments and governance proposals in a fast-growing ecosystem such as Optimism is a tall ask. Delegation allows token holders to grant their voting power to representatives committed to staying engaged, while maintaining the ownership of their tokens.

Imagine you have a trusted friend called Jack who happens to work with the Optimism Foundation as well as the largest protocol on Optimism. You know Jack is active in the Optimism Governance and that he will use your voting power in the best interest of the ecosystem. By delegating your OP token voting power to Jack you are indirectly contributing to the good of Optimism!

Delegation for Liquidity Providers

Liquidity providers are at the core of Velodrome and they are handling large amounts of tokens supporting delegation. Once they deposit these tokens into our smart contracts (eg. OP tokens and VELO tokens into the vAMM-OP/VELO liquidity pool), the tokens are moved from the wallet into the smart contract and any previously delegated amounts will also reflect this change, where the smart contract address will reflect the sum of all deposited tokens voting power!

You can easily identify when the delegation changes take place in your account, by reviewing the events of a transaction. Just lookup for the DelegateVotesChanged events in the Logs tab on Etherscan.

The smart contracts handling the liquidity pools do not provide any means to delegate the deposited voting power. Currently, millions of OP and other governance tokens deposited in Velodrome, or any other DEXes, sit unused.

To delegate or not to delegate

Currently, as a liquidity provider interested in participating in governance, you have the following sub-optimal options:

1. Keep your tokens in the wallet without providing liquidity:

   • miss out on passive revenue from liquidity incentives and fees when applicable

   • vote directly in governance decisions, which may have an influence on the value of your tokens

   • delegate voting power and thus still play a passive role in governance

   • potentially avoid taxable events until selling the tokens.

2. Deposit tokens into liquidity pools, but withdraw before governance snapshots:

   • earn passive revenue, most of the time

   • can vote on governance decisions

   • are potentially subject to taxable events from the transfer of the tokens

   • are subject to the time & cost of extra transactions for every deposit and withdrawal

   • are subject to pricing fluctuations and impermanent loss

   • must remain highly engaged because voting snapshot times are very precise and take place often

3. Deposit tokens into liquidity pools:

   • earn passive revenue

   • forego participation in governance voting

   • potentially avoid taxable events from token transfers

No single option is perfect for users, while protocols effectively force token holders to take one of the two sides:

1. Actively engage in protocol governance

2. Provide liquidity to benefit from incentives and support DeFi needs

LP delegation could solve this!

Introducing LP Delegation

The ideal LP delegation model would enable liquidity pool smart contracts to automatically delegate the deposited token voting power to a chosen representative or token owner.

Unfortunately, none of the currently available technical solutions are optimal to meet our criteria.

1. Generic delegation support for liquidity pools

Given how OpenZeppelin’s ERC20Votes work, we’d only be able to delegate the full balance of the liquidity in a pool.

This would require a governor implementation or some other trusted party to then call Pair::delegate(address delegatee) to delegate the underlying token amounts.

2. Partial sub-delegation

To overcome the limitations of the ERC20Votes, we would need an additional solution that splits the delegated amount based on the
share of the pooled tokens of every liquidity provider. In which case, our smart contracts would still delegate the full available balance to the partial delegation smart contract and let it handle the actual distribution to sub-delegates.

We found this partial delegation implemented in the liquid-delegator, a joint project announced by WINTΞR and supported by multiple organizations.

WINTΞR 💙💛

@w1nt3r_eth

Agora is looking for a Solidity wizard who wants to build the next version of protocols powering the largest DAOs.

You'll be working with ENS, Uniswap, Optimism, Nouns, and a bunch of other communities with $$B in TVL. And also with me :)

RT plz

w1nt3r.mirror.xyz

Zero to Governance

One day, cleaning up your garage, you discover an old hard drive. You plug it into your fancy new MacBook and start looking through the files. One of them makes your heart rate go up — it's an...

82

9:44 PM • Feb 15, 2023

Challenges & Limitations

Our team went back-and-forth documenting the outcome of either of the proposed solutions and the limitations these bring.

1. Generic delegation support for liquidity pools

With the generic delegation and all the liquidity pool voting power being delegated to one voter, we faced some challenging questions to answer:

• Who determines the voter for the tokens? In an ideal scenario, the pool providers would be able to vote to determine the voter. We have not found a straightforward answer nor a technical solution to this.

• Should the Velodrome Emergency Council determine this delegated voter? We were not convinced the interests of the council are aligned with those of the liquidity providers.

• How do we align the interests of the liquidity providers and the beneficiary voter?

• How do we generally limit the risk of liquidity providers withdrawing their tokens from our pools because of delegation concerns?

• Finally, how do we convince partner protocols there’s no risk of having a too strong influence on protocol proposals (especially in the case of a security matter)?

2. Partial sub-delegation

• Partial delegation is not yet audited nor officially in use, representing a security risk.

• Sub-delegation for major custodians (eg. Coinbase Custody) is still an open question.

• As a sub-delegate, the voter needs to vote through the liquid-delegator. This requires custom integrations into governance tools (technically speaking, using the current implementation, you need the path of vote delegation for each sub-delegation, eg. [pool address => pool provider address => sub-delegate address]). This could also become gas-intensive for a sub-delegate who receives delegations from many users.

• Finally, the limitations on the final delegated amount will be heavily influenced by the way liquidity pools balance the claimable tokens for an LP due to volatility.

Conclusion

As great as LP delegation would be in giving value to our protocol participants and partners, Velodrome V2 will not support it out-of-the-box because of the challenges and the limitations we found.

But with Velodrome V2, we are introducing the flexibility to deploy new types of liquidity pools (we recently announced the concentrated liquidity pools that will benefit from this flexible protocol design). This means that we can continue our research on LP delegation and present a release once we are happy with our and our partners’ progress in this direction.

In the meantime, if you want to support existing work or learn more about LP delegation or just share your concerns, join us on our Discord. Special thanks to our Carter Carlson for helping with this research, and to Charlie Feng for all the feedback!

One of our top goals for V2 is to move the protocol entirely on-chain. To do so, we're taking important steps to make it possible to run it as a fully decentralized public good. We'll be covering our approach in the upcoming weeks.

In this first publication, we'll start with one of the planned features that didn't make it into Velodrome V2 due to technical limitations. This is a deep-dive into the Ethereum Name Service (ENS) , how it works, and why its current implementation on a Layer 2 network like Optimism didn't align with our objectives.

We aim to cover this topic and engage with enthusiasts and partners to help build and support the efforts to improve the services available on Optimism. We will also be working with ENS and our partners to see how we can help make it happen in the near future.

Let's name our contracts!

Among our key planned features was assigning ENS names to all our contracts to make them human-readable and overall safer to interact with (e.g., router-v1.optimism.velodrome.eth instead of the unwieldy 0x9c12939390052919aF3155f41Bf4160Fd3666A6f).

Intelligible contract names allow:

• users to quickly verify a smart contract by reading its name

• security researchers and developers to search for any contract by a name

• development teams to transparently release and communicate new contracts versions to all partners

ENS is for Ethereum addresses what DNS is for the Internet: instead of typing ping 8.8.8.8 to reach out to another computer on internet, you can just do ping dns.google, which is easier to remember and maintain.

Most readers will be familiar with the significantly improved user experience of interacting with a <YOUR NAME>.eth name directly instead of an error-prone raw address.

However, we couldn't find any of the available services for intelligible contract names on Optimism to offer the technical support we need to meet our core goals.

Contracts claiming their own ENS

Technically, assigning an ENS name requires two steps:

• assign a name to an address

• claim the assigned name from an address

The second step is actually what makes it possible to resolve an address to a name.

Since an address can have multiple names, and anybody can assign a name to a contract, claiming is required to resolve which name is attached to an address.

Based on these rules, we established the following list of requirements for our factory (the PairFactory.sol) to give names to all the contracts it deploys:

1. First we give the factory a sub-domain it will operate, eg. pairs.optimism.velodrome.eth, which would use the Registry::setSubnodeRecord()

2. Have the factory create a new name and assign it to the new pair address using the same pair symbol

   • store the Factory reverse-registrar (which also comes with the registry) address and have a function to allow updating it in a permissioned way

   • dynamically reverse-resolve the sub-domain provided in the first step

   • use the same Registry::setSubnodeRecord() with the stored registry address and the operating sub-domain to assign newly deployed contracts new sub-domains (eg., vAMM-VELO-OP.pairs.optimism.velodrome.eth)

3. Add a permissioned function that will let the pair claim the newly assigned name by resolving the reverse of its own address, this would use ReverseRegistrar::setName()

Note, the first step is also easily done via the ENS app and allows us to keep the main name velodrome.eth safely in our multisig.

The challenges with ENS integration

While ENS on Optimism offers functions to register and transfer the names, we didn't find the on-chain support for resolving names or reverse-resolve addresses to names.

Since we are on a Layer 2 network, the ENS support for Optimism is the next thing we started looking into. At the end, our research led us to the following list of blockers:

• ENS documentation confirms that Layer 2 support is at best a prototype at the moment. OptiNames or a similar deployment to support the Layer 2, at the moment requires an off-chain service (which would go against our initial design goal of striving to build a decentralized protocol).

• ENS node hashes and generally the support for direct and reverse address lookups needs an official implementation

Sadly, the work we estimated to get all these external features done, would seriously divert the time and resources from our core goals. This motivated us to share all the details in this article with the community.

Conclusion

We found that ENS on Optimism serves limited use-cases at its current stage, and we hope to see the ENS Foundation will consider any of the following feedback:

1. The lack of on-chain support for resolving addresses is something crucial to help the developers adopt and develop on top of the service. We believe this will increase the adoption of ENS for critical to the community products like Etherscan and Metamask. We need an official smart-contract implementation to support the developer's needs.

2. The Layer 2 support, while still being a work-in-progress, is an absolute requirement to help test and experiment with the new product development and adoption of ENS across the Ethereum eco-system and other Layer 1 networks. Especially now, where OP Stack and cross-chain apps are leading the narrative.

Despite the unsuccessful journey, we look forward to a future where on-chain addresses will have names!

We believe in a future where users don't have to pay/use external services to simulate a transaction at a potential cost of their privacy, and instead trust the ENS names as we trust DNS when connecting to another computer today. We want to send funds by typing our friends' names into the wallets, and where Etherscan doesn't label the contracts based on what other Web2 services have to say.

If you're interested in learning how you can help, come ping our team in our Discord, or directly Zoomer on Twitter and Stas on Farcaster.

with the release of the Velodrome V2, we would like to start sharing all kind of development updates, R&D and ideas that made it and didn't make it into the upcoming release.

The publication will be focused on engineering topics, but we will do our best to make it interesting and accessible for anybody curious to learn more about how Velodrome Finance is being designed and built.

Some of the upcoming topics we will be writing about include: governance, voting power delegation, L2 ENS, RPC performance, dApp integrations and optimizations and building a fully on-chain protocol.

Until soon 🚴💨✨