Asset Risk Assessment - Paladin / Warden

A risk assessment on the Paladin ecosystem for Curve veCRV holders and Pal LPs

LlamaRisk

and

evmknows

Nov 22, 2022

This research was spearheaded by @evmknows.

Abstract

With the introduction of lendable governance power, Paladin fills a yet unfilled niche within governance voting markets. In the first part of this review, we will cover Paladin and assess the relevant risks for its users including LPs. Lastly, we will assess the Warden products, which were designed for veTokens due to their fundamental differences from classic governance tokens, i.e. no possibility to lend generalized governance power.

Paladin Protocol Overview

The Paladin protocol allows users to non-custodially lend the governance power of various protocols. The way it operates resembles that of a lending protocol. When a user deposits their tokens into a pool, they are released for borrowing. When a user borrows the governance rights, the PalPool creates a PalLoan (ERC-721) which represents the borrowing position. The borrowing fees are paid in advance by the user, after which the governance rights are delegated to the borrower.

At any time, the borrower can change the recipient of their borrowed governance rights, extend or close the borrowing position. All unused fees will be returned to the borrower should they close their position earlier than initially desired. Conversely, the borrowing position is automatically closed if all fees (that were prepaid and held in custody) are used up.

Pools as a Faster Means of Exiting Staked Gov. Power

Since not every protocol allows users to unstake their governance tokens without a delay, it is possible (e.g. in the case of PalStkAave) to exit a gov. lending position via a pool. This pool is incentivized by Paladin and serves to improve the user experience of their protocol.

Risk Summary:

For LPs:

Significant depegs (e.g. PalStkAave/Aave) do not pose too much risk for liquidity providers, since in the case of a lopsided pool balance the LP can rebalance the pool within 10 days. This can be achieved at no cost by withdrawing PalStkAave, unwrapping, unstaking Aave, and redepositing back into the pool. Ideally, this rebalancing should occur before the pool enters a lopsided state to provide sufficient depth (which translates into volume & fees) at all times.

Further risks for LPs arise from individual protocol-related risks for which the liquidity is provided. For example, in the case of StkAave, should there be any shortfall event, Aave will slash up to 30% of StkAave to cover the deficit, which in turn would cause PalStkAave (like any other StkAave derivative) to depeg.

For lenders/borrowers:

The Paladin protocol has been audited by Pessimistic on 1st Oct 2021, whereby no critical issues were found. However, users should be aware of the elevated multisig rights (as per the audit):

In the PaladinController contract, an admin can:
Withdraw all tokens from the reserve using removeReserve() function.
Block pool transactions by providing an incorrect controller address in setPoolsNewController() function or by removing the pool with removePool() function call.
In the AddressRegistry contract, an admin can front-run users' transactions and change the address of the pool using _setPool() function.
In the PalPool contract, an admin can modify interestModule, minBorrowLength, and killerRatio variables that affect the operation of the whole system.
In the current implementation, the system depends heavily on the admin role.

Because the multisig controlling the admin role is composed of doxxed core developers, a trust assumption might be sufficient to lessen this risk.

Multisig members (3 of 5):
Figue - Paladin
0xKoga - Paladin
tomo - Paladin
Greenfield One
afromac - Index Coop

In the future, the Paladin DAO intends to transfer the control over to the DAO once governance processes are refined and deployed on-chain.

The Warden protocol

While the idea of lendable governance power introduces improvements to more trivially designed governance models, the opposite is the case for the vote-escrowed model. Given a high degree of (or absolute) permissionlessness within DAOs, the veModel acts as a protection mechanism against malicious governance behavior. By linking governance power to the duration of the lock period, an effort is made to align the long-term incentives between the DAO and the governance participants. An essential component to maintain the integrity of this mechanism is a whitelist that only allows contracts selected by the DAO to lock CRV. Accordingly, it is intended that the locking mechanism cannot be circumvented, e.g. through tradable veCRV derivatives.

This is a significant difference from other governance models, which was also the reason why separate products labeled “Warden” were developed to specifically cater to veCRV and other veTokens.

Warden boost

The first product in the Warden line is based on the ability to delegate the veBoost to another address, enabling the aggregation of boosted Liquidity Gauge rewards at a single address. The veBoost represents a second non-transferrable token that correlates 1:1 with the locked veCRV position. This veBoost determines (depending on other participants' share of veBoost) the individual share of CRV rewards distributed by the Liquidity Gauge. The more veCRV a user has locked, the more veBoost he is able to utilize during liquidity provision to earn a higher share of the liquidity incentives. Accordingly, through veBoost delegation, Warden boost allows this boosting element of veCRV to be rented/leased independently of the underlying voting rights (see docs for more details). As can be seen from the image below, the lease offer can be configured very precisely.

Thus, the risks associated with a lease can be limited in advance.

Warden quest

The Warden quest product offers a solution that allows protocols to set a budget, duration, the desired amount of votes, and a fixed price per veCRV for gauge vote weights. This distinguishes it from other protocols (e.g. Votium or Andre’s bribe.crv.finance/yBribe) where an arbitrary amount can be deposited as an incentive to influence voters. In case the budget remains unused throughout several voting periods, the protocol can withdraw its incentives or adjust the conditions at any time.

For more information on how to create a quest or claim rewards see the documentation.

The audit for Warden quest was carried out by Spearbit whereby all except one issue were resolved. This is due to the fact that Paladin wanted to give its users the possibility to accumulate their earnings over several voting periods. Because the gauge contract does not store information about the past votes of a user, additional work is required to keep track of the votes. For that to happen, a manual (off-chain) process is required to create the Merkle Trees, which are needed for operational gas efficiency. Thus, there exists a high reliance on an accurate Merkle Tree generation.

Conclusion

As far as the Warden products are concerned, no noteworthy risks could be identified. Both products do not represent a veCRV derivative, rather contracts that manage only the functional aspects of veCRV. This non-custodial property limits even worst-case hypothetical risks (e.g. the inability to claim bribe rewards due to faulty Merkle Trees) to a minimum.

As for the risks regarding Paladin, these are mainly confined within the powers of the multisig. Since trust assumptions can be made by virtue of the reputation and public disclosure of the multisig participants (doxxed to the fund), the risk can likewise be considered minimal in this case.

In summary, the Paladin protocol primarily targets the pain point of governance scalability within DAOs that can be effectively solved through delegation. Thus, it can be said that the Paladin protocol contributes a positive value add to governance within the DeFi ecosystem.