Summary

Velodrome Finance is a next-generation AMM that combines the best of Curve, Convex and Uniswap, designed to serve as the liquidity hub for the Superchain. Velodrome NFTs vote on token emissions and receive incentives and fees generated by the protocol.

Ratings

## Chain

Velodrome is deployed on the Optimism chain, an Ethereum L2 in Stage 1 according to L2BEAT.

Chain score: Medium

Upgradeability

To a large part the protocol is immutable. In particular, no permissions with a potential impact on user funds have been identified.

The remaining permissions are related to the protocol's rewards system and periphery contracts. These permissions are controlled by a number of multisigs including an undeclared multisig.

Among these, the undeclared multisig has control over a whitelist of special voters with the ability to change the rewards distributed to LPs. Specifically, "regular" veNFT holders compete in weekly voting rounds to distribute a fixed amount of rewards, paid in the protocol's native token, VELO. Regular voters are able to signal their support for a specific gauge which, after the conclusion of a voting round, receives and distributes rewards among the LPs of the linked pool. This public voting period is followed by a "private" voting window of 1 hour during which only the whitelisted veNFT holders are able to participate. As a result, these whitelisted veNFT holders, and by extension the undeclared multisig, are able to control the final vote outcome. The impact of this is classified as a potential material change of the expected performance including the loss of accrued yield (if public votes are overwritten by the whitelisted veNFTs).

The undeclared multisig further is the owner of various contracts, and the associated permissions, including the FactoryRegistry. This contract allows the undeclared multisig to (un-) approve factory contracts within the protocol. User's swaps are routed through the pools created from the approved factories. Users are protected from malicious factories (and pools) through a user defined slippage tolerance which is enforced on all swaps on the router contract. On the other hand, only pools created from the default factory are enabled for LP provisioning functions effectively protecting LPs in the protocol.

Another noteworthy permission in the protocol is the ability to kill and revive gauges and thereby stop, or enable, a gauge to receive and distribute rewards to LPs and voters. However, killing a gauge does not affect the rewards already distributed to LPs or voters and also does not affect the rewards, or any other aspect, of other gauges. This permission hence can not materially affect the protocol's expected performance.

Upgradeability score: Medium

Autonomy

Velodrome does not have external dependencies 🎉

Autonomy score: Low

Exit Window

Existing permissions have a Medium risk score and are not protected by an Exit Window. Users are not able to withdraw funds in case of an unwanted update.

Exit Window score: Medium

Accessibility

Velodrome provides several access points to the protocol, both decentralized and centralized. Decentralized links include velo.drome.eth, velo.drome.eth.limo, and velo.drome.eth.link, while centralized options include velodrome.finance and alt.velodrome.finance. This diversity of user interfaces offers redundancy and reduces risks associated with access issues.

Accessibility score: Low

Conclusion

The Velodrome protocol achieves Medium centralization risk scores for its Upgradeability and Exit Window dimensions. It thus ranks Stage 1.

The protocol could reach Stage 2 by transferring the permissions to an onchain governance with 30 days Exit Window.

Overall score: Stage 1

Reviewer notes

There were no particular discoveries made during the analysis of this protocol.

Protocol Analysis

Killing of a gauge

After each period, VELO tokens from the Minter contract flow into the Voter contract via calling updatePeriod(). Once the tokens are in the Voter contract, they flow according to the voting weight to each Gauge through calling distribute() on the Voter contract. Once the VELO tokens ended up in the different Gauge contracts, the users can claim their reward no matter of the living status of the Gauge. It's the function call distribute() that sends the tokens to the Gauge which reverts if the Gauge is killed. For rewards to be claimable for users the function calls updatePeriod() and distribute() need to occur in succession and the killing of the Gauge before either one of them results in yield not being available to the user. But, since both functions are public everyone, can call them. And thus during the first block of each period where updatePeriod() is callable, the permission owner that kills the Gauge needs to frontrun the transactions which are calling updatePeriod() and distribute(). This centralisation vector is thus not definitive and only probabilistic.

On the other hand, Voters earn a claim on yield proportional to their allocated votes when calling the vote() for a gauge on the Voter contract. Function vote() will revert if the respective gauge is killed, thus not crediting a claim on yield for the killed gauge. However, previous votes and the credited yield claims, before the gauge is killed, are not affected by this. Voters will thus still be able to claim their accumulated yield.

Dependencies

No external dependency has been found.

Governance

Security Council

Info sourced from here: https://velodrome.finance/security#contracts.

Exit Window

No timelocks have been found protecting the various permissioned functions in the protocol. All updates take effect immediately.

Contracts & Permissions

Contracts

All Permission Owners

Permissions