Delegation for AMM liquidity pools, or simply the LP delegation, is the second planned feature that didn’t make it into Velodrome V2.

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!