Asset Risk Assessment - PWRD
A look into various risks associated with GRO Protocol's yield-bearing PWRD stablecoin.
Useful links:
Abstract
PWRD is a yield bearing, rebasing stablecoin offered by the Gro Protocol. The Gro Protocol has signalled an interest in acquiring a gauge for their PWRD-3CRV gauge to boost users to their platform. They have previously requested for a gauge proposal, leading to an on-chain vote, which ended up against their favor. In anticipation of a second attempt, this article highlights risks associated with PWRD to Curve liquidity providers, and provides guidance should the on-chain vote be put forth once again.
A quick TL;DR of the findings:
Gro Protocol offers yield on a user’s stablecoins via their Powered Savings product (PWRD; also the stablecoin in question) and leveraged yield product (Gro Vault Token).
PWRD is composed of DAI, USDC and USDT, and is insured by GVT liquidity providers: risk is transferred to GVT for lower yields (but lower risk as well).
A Curve Gauge would boost the demand and TVL for PWRD and offer a higher utilisation of Gro Protocol’s products. The gauge proposal is hence treated as a business proposal between Gro and Curve DAO.
Gro Protocol is backed by VCs like Three Arrows Capital, Galaxy Digital, etc.
The protocol is audited by three independent auditors and has an Immunefi bug bounty program. Peckshield and Kurt Barry are some of the best when it comes to auditing DeFi protocols.
There is no obvious possibility of infinite mints that might rug PWRD-3CRV liquidity providers.
The protocol aims at reducing long-tail risk due to Curve depeg events or protocol over-exposure to one strategy over the other. This results in safe handling of user funds. There are a few risks that are detailed in this article.
Protocol documentation caters to novice level users and not to power users that need more information about how the protocol manages risk. A recommendation to Gro Protocol is to improve lower level protocol docs.
The PWRD-3CRV pool is 100+ days old and has observed price instability in its history. Currently it sits at a 65-35 token distribution.
The cumulative volume on Curve is approximately 2.5 million USD, bringing in approximately 750 USD in fees. This is a low amount of value being returned to veCRV holders for directing CRV inflation to the PWRD-3CRV gauge.
The reviewers of this (and future) gauge proposals for PWRD recommend allowing the pool to mature and generate volume before directing incentives, or propose that Gro Protocol participate in gauge-incentivisation (either via GRO incentives or via voter-incentives) such that veCRV holders are compensated for directing inflation to PWRD-3CRV.
The Gro Protocol - Introduction
The Gro Protocol is a stablecoin yield aggregator that offers risk-tranched yield products with their user’s stablecoins. The smart contracts used to generate these yields are forks of Yearn’s v2 vaults and strategies, some of the most audited contracts in current day DeFi.
There are two products offered:
the yield-bearing stablecoin product PWRD (Powered Savings), and
their leveraged yield product GVT (Gro Vault Token).
These are two different products that cater to clientele with differing risk profiles. The risk distribution is done in the following manner:
Higher yield-seeking users can choose the vault token and incur protocol and smart contract risk to earn more yield.
The risk-off user may opt for PWRD, settling for lower but protected yields.
The total value of user-funds locked (TVL) is (currently) at 45 million USD, a decrease from its all-time highs in October 2021.
The spike in the protocol’s TVL coincides with their liquidity bootstrapping event for the GRO governance token, which occurred on the 28th of September, 2021.
Where do the yields come from?
The protocol deposits its liquidity in several blue-chip DeFi protocols and CREAM Finance (which has observed several large economic attacks in its history).
The protocol only dabbles with stablecoins hence, remains collateralised against market downturns. The risk involved here is in the various strategies that generate yield for their users. The strategies employed are transparent to their users.
Not all of the user’s liquidity is invested into strategies immediately: the liquidity is first stored in the vault undeployed, and gets mobilised if and only if the amount deposited exceeds target reserve (fixed by strategists and amended by governance). The reserves for DAI/USDC/USDT and 3CRV are stored in their respective VaultAdapter contracts:
The protocol charges 5% performance fees for PWRD and Vault investors and a 10% performance fee for their experimental Labs product, an experimental leveraged yield farming strategy that uses the Alpha Homora V2 protocol on Avalanche. There exists a 0.5% withdrawal fee for getting out of the strategies.
For large PWRD → 3CRV coin swaps (USDC/USDT/DAI), the user will incur the Curve 3CRV swap fee as well as the PWRD exit fee.
An exciting feature of the Gro Protocol is its Argent Wallet integration, allowing users to deposit into Gro Protocol strategies via the zkSync bridge. This results in a low barrier of entry into the protocol, as this integration ensures very low gas fees into Layer-1 strategies. The bridging of GVT between Ethereum and zkSync is done via their GroGvtBridgeSwapper contract.
Having stated the higher level details of the Gro Protocol, the article will now delve into lower level details and highlight potential risks.
PWRD as an asset
Useful links
Collateralisation of PWRD
PWRD is backed by collateral in the GVT vault. The PnL contract in the Gro Protocol takes note of the latest assets in the GVT and PWRD strategies:
Historically, Gro protocol has observed a decline in its collateralisation ratio:
This is likely due to the decrease in assets that are within the leveraged yield strategies primarily in the end of October 2021, whereas assets in PWRD have remained stable over time.
Potential de-collateralisation risk: The GVT vault acts as the insurer to PWRD, and this has seen a decline over time. This means that PWRD’s growth is quite dependent on GVT’s growth. Even with incentivisation, the protocol still needs to increase GVT liquidity in order to ensure a healthy collateralisation/insurance of PWRD.
PWRD Price Stability/Protocol Insurance mechanism
PWRD has observed quite a bit of price volatility in its history (based on CoinGecko data):
Currently, most of PWRD liquidity has about 14.74 million USD in its Curve Factory 44 metapool. The pool’s inception was on the 28th of September 2021, and has observed significant price deviations from its peg. It currently has a lopsided distribution, and a pool amplification factor of 200: this might be too high, considering PWRD’s historical price instability. Something in the order of A = 100 might be safer for PWRD, affording arbitrageurs a higher re-pegging velocity.
Historically, PWRD has done quite low amounts of volume on Curve pools, with a cumulative volume of 2.5 million over 4 months, and almost no volume since the past 3 months, bringing in total fees of approximately 750 USD (quite low). This might be a deterrent to veCRV holders, since the CRV inflation would be used for bootstrapping a pool that does brings in little to no volume to the Curve DAO.
Risk rebalancing mechanism
Useful links
Oracles
Oracles are the key components that ensure the safety of Gro Protocol’s strategies. The oracles used in Gro Protocol track the underlying tokens in 3CRV. The logic for this is encapsulated in the Buoy3pool contract, which uses a custom oracle and external oracles for tracking 3CRV prices. The tracked prices check for deviations between Curve and Chainlink prices, comparing the price ratios of assets in the Curve pool versus their respective Chainlink price ratios. An additional check is done in order to ensure that 3pool has sufficient liquidity depth for Gro’s strategies. Updates to the various health parameters in these sanity checks (cached Curve ratios for instance) is only done when bots run harvest.
To execute these sanity checks, Buoy3pool contract uses two methods: safetyCheck (for asset ratios) and healthCheck (for asset depths):
These sanity checks are performed each time a user deposits or withdraws liquidity to and from the protocol. Should the safetyCheck fail, the protocol disables withdrawals (in their WithdrawHandler.sol contract):
Depositing into PWRD and GVT strategies are disabled if safetyCheck returns False:
Potential user fund risk: If safetyCheck is False, users may not be able to withdraw their liquidity. This has implications if the protocol is in an emergency state.
Potential oracle risk: The calls for curve and chainlink prices are for just one token (it uses getDecimal method to get number of input tokens to calculate ratios on), whereas the more safer approach might be to use a larger swap size (say total amount that needs to be swapped). This is because a pool depeg event impacts larger swap sizes before it affects smaller swap sizes.
Protocol rebalancing mechanism
The LifeGuard3Pool.sol contract is used to rebalance strategies into more favorable allocation ratios. The decision to rebalance is dictated by the protocol’s definition of risk, governed by a rebalanceThreshold parameter. This is achieved in the isExposed method in Exposure.sol:
The protocol is said to be exposed to risk if there is an over-allocation into a strategy. Should the protocol be exposed, the method rebalanceTrigger in Insurance.sol returns True. This is monitored by bots running on the cloud.
Strategy rebalancing can occur due to user-interactions. In case of severe unbalanced states, rebalancing must be done by the protocol itself (likely by a multisig).
Centralisation vector: Protocol risk is managed by bots run by the protocol. These query emergency states and rebalance triggers and react to over-exposure or protocol emergency states. Generally, this is a centralisation vector which could be instead offloaded to keeper bots, for instance.
Protocol Emergency State
The LifeGuard3Pool contract is called by the core contract withdrawHandler.sol, which has four public methods: withdrawAllBalanced, withdrawAllSingle, withdrawByLPToken, and withdrawByStablecoin, accessible to any user to withdraw liquidity for general use or in the case of emergency (contracts in bold can only be called if the core controller contract has emergencyState set to True). In the case of a protocol emergency state, the protocol then uses Chainlink oracles instead of curve oracles: the emergency state assumes that something has gone wrong with curve and pricing and swapping logic doesn’t work as intended.
Emergency state is determined using off-chain logic: once the logic is fulfilled, a whitelisted address can then trigger an emergency state using Controller.sol:
In the emergency mechanism has the following workings:
A pause state is triggered. This stops users from depositing to the protocol, but does not stop withdrawals. As discussed earlier, emergency states can trigger False safety checks, which would in principal revert withdrawals as well. This constitutes as a long-tail risk to user funds.
Within the emergency state, the protocol stops interacting with Curve entirely, as 3pool could then be arbed into a full depeg.
Only the DAO can trigger a recovery from an emergency state, thus re-allowing deposits into the protocol. The execution is done via the multisig (more on that later).
Currently, there are no multisig timelocks in the case of emergency state. This is done in order to react quicker to changing market/risk conditions. The multisig can then alter utilisation ratios and ensure that PWRD depositors (the insured) can withdraw their liquidity before GVT liquidity providers (the insurers) front-run the insured in cases where losses are anticipated but not realised. The potential risk here is that the multisig must act quickly to ensure that GVT liquidity providers cannot cause losses to PWRD liquidity providers.
Potential risk to PWRD: Rebalances due to emergency states are not automagically done by bots, and are handled by humans after an assessment of the emergency state. This means that there is a potential to front-run PWRD users and withdraw liquidity before the human can react to the emergency state: but this is isolated to long-tail risk events.
A short note on multisigs in the Gro Protocol
The multisig used by the Gro Protocol is a Timelock Multisig requiring 3/5 signers. The multisig includes participants outside the protocol, with a timelock of 25 hours. Migration, strategy selections, DAO actions and emergency handling is then conducted with this multisig.
The multisig has the ability to migrate user funds under certain conditions. Because the multisig can also choose strategies to invest in, malicious strategies could be used to steal user funds as well. These steps would result in an immediate de-legitimisation of the protocol. Considering the protocol has doxxed founders and prominent investors, the threat of legal action might ameliorate trust assumptions: but this is up to the user.
Potential Curve DAO participation recommendation: Considering that Gro’s yields and insurance are tied in quite closely with Curve, it might be prudent for the Gro Protocol DAO to be active participants in Curve parameter change proposals: for example, should the Curve DAO wish to change the amplification factor of 3pool, it is then within Gro Protocol’s best interests to asses risk impact to their users following the passing of such a Curve DAO proposal. Currently, Gro does not participate in Curve DAO beyond proposing for a PWRD-3CRV gauge.
Discussion and Conclusions
Gro Protocol emphasises heavily on risk mitigation. They are at a nascent stage, with several planned upgrades towards decentralisation in their roadmap. Adding a Curve gauge would attract more users to their protocol.
The concern here is that the PWRD-3CRV pool does not do enough volume for it to be incentivised: a lopsided distribution of 65% PWRD to 35% 3CRV and almost no volume in the past 3 months indicates a low return for veCRV holders from the PWRD-3CRV pool. Adding a gauge would result in over incentivisation of a pool that adds tremendous value to the Gro Protocol but no value to the Curve DAO.
Does the asset meet minimum requirements?
Is it possible for a single entity to rug its users? Yes, the multisig has the ability to rug its users. Since the protocol founders are doxxed, a trust assumption might be sufficient to ameliorate this risk.
If the team vanishes, can the project continue? Considering that Gro is still in its nascent stage, and that several strategies are run by bots hosted on the cloud, the project cannot continue without the team.
Do audits reveal any concerning signs? The audits do not reveal any concerning signs.
Recommendation: Considering there is currently little benefit to veCRV holders, we propose that the DAO wait till the PWRD-3CRV gauge does sufficient volume and the pool matures into a more active pool. The Gro DAO may choose to compensate veCRV holders for directing CRV incentives to the pool by participating in voter-incentivisation, or directly provide GRO rewards to the curve pool to bootstrap it further. If they wish to compensate veCRV holders with GRO incentives, insufficient pool volume becomes a non-factor.