Cove RFC

Cove pairs off-chain intelligence with on-chain automation to deliver curated 1-click DeFi vaults that earn higher, risk-adjusted yield 24/7.

​

Background

Traditional automated market makers (AMMs) are not well suited for portfolio or index construction because they suffer from loss-versus-rebalancing (LVR) due to toxic order flow (i.e. all trades execute at worse-than-market prices).

“We found that for the 17 pools we analyzed, covering 43% of TVL and chosen by size, composite tokens and data availability, total fees earned since inception until the cut-off date was $199.3m. We also found that the total IL suffered by LPs during this period was USD 260.1m, meaning that in aggregate those LPs would have been better off by USD 60.8m had they simply HODLd.” Stefan Loesch, Nate Hindman, Mark B Richardson, Nicholas Welch: “Impermanent Loss in Uniswap v3”, 2021; arXiv:2111.09192.

“Thus, providing liquidity has become a game reserved for sophisticated players with the introduction of Uniswap V3, where retail traders do not stand a chance.” Lioba Heimbach, Eric Schertenleib, Roger Wattenhofer: “Risks and Returns of Uniswap V3 Liquidity Providers”, 2022; arXiv:2205.08904. DOI: 10.1145/3558535.3559772.

We propose an alternative solution that eliminates LVR and guarantees general intent level execution as a lower bound (e.g. CoW Swap). This document introduces the BasketManager contract, which handles protocol deposits/withdrawals/LP tokens, custodying user assets, and managing the rebalance lifecycle. Storing user assets in one contract provides two major advantages from economies of scale: optimized/cheaper rebalancing (at the protocol level vs. for each basket) and increased value capture from matching trades internally.

​

Summary

Cove functions as an intent aggregator for liquidity providers (LPs). Users express their intent by choosing a weight strategy and a combination of ERC-20/4626 tokens (represented as an LP token). These choices form a basket, such as Gauntlet-optimized yield strategy with sDAI/sFRAX, a market cap weighted index strategy with stETH/sfrxETH/yETH, or custom weights. This approach limits the number of options while allowing the protocol to aggregate deposits efficiently. The weight strategy determines the weights of each token in a basket. When the protocol rebalances, there is the potential for coincidence of wants (CoW) to exist between baskets, like ring trades in CoW Swap’s batch auctions. Approximately maximizing the volume of CoWs given the current/target protocol level allocations is solvable off-chain with linear programming. When there are matches, trades execute without leaking value (i.e. no price impact/slippage/fees/MEV from accessing exogenous liquidity). External trades are routed through CoW Swap, which now supports programmatic orders including TWAP via their Programatic Order Framework, to ensure the best execution and capture positive slippage. The protocol includes configurable/switchable fees for management and internal trades. To ensure safe rebalancing, BasketManager follows a sequence of proposing, executing, and finalizing a rebalance while temporarily pausing deposits and withdrawals for the affected baskets. As BasketManager pools assets for all Baskets, the rebalancing process considers each Basket’s asset preferences and weight strategy. For example, when a new deposit arrives for a Basket with a limited token selection and a market cap weighted strategy, BasketManager deploys funds according to the respective weights, crediting the Basket for the new deposit without impacting other Baskets. Once the rebalance is complete, the tracked balances within BM are updated to reflect any changes resulting from swaps since the previous rebalance.

​

Terminology

📄 Contract 👮 Permissioned Actor 🧑 Permissionless Actor

• Smart Contract - BasketManager 📄
  • The BasketManager contract is the core component of the Cove protocol, responsible for managing user deposits, withdrawals, and LP tokens. It also handles the rebalancing process, custody of user assets, and execution of trades. By pooling assets from all baskets, BasketManager enables efficient rebalancing and increased value capture through internal trade matching.
• Smart Contract - BasketToken 📄
  • Token representing BasketManager’s user deposits. Each BasketToken is defined and created with immutable selection of assets that will be considered for allocating and a weight strategy which determines the weights of the selected assets. The maximum number of selected assets will be capped and configurable (e.g. start at 4 with a maximum of 8).
• Smart Contract - WeightStrategy 📄
  • Contract that each Basket is linked to for determining asset weights. Each weight strategy contract is associated with a single weight proposer who controls weight updates. Weights define the proportions of assets within a basket. Multiple baskets with varying asset selections can use the same WeightStrategy, provided the WeightStrategy supports all assets chosen by each basket.
  • When a Basket is created, an WeightStrategy address must be supplied.
• Smart Contract - SwapAdapter 📄
  • Adapters are modular contracts that are written to execute trades (e.g. via an aggregator or auction). BM can support both intent based aggregators and on-chain execution aggregators as long as their parameters/states are verifiable by BM.
  • Intent based aggregators that support smart contract signing via ERC-1271 are supported, such as CoW Swap.
  • A generic dutch auction adapter with a flash loan-like mechanism could be implemented such that any on-chain user-executable aggregator is compatible. This also allows for easy deployment to other chains or L2s.
  • Another adapter could be used to swap more efficiently between 4626 tokens with the same underlying assets, or for lossless conversions between assets like USDC<>DAI using MakerDAO’s PSM.
• Actor - Weight Proposer 👮/📄
  • Actors responsible for updating their associated WeightStrategy contracts with the new weights for all baskets subscribed to it.
• Actor - Rebalance Proposer 👮/📄
  • Role that initiates the rebalance lifecycle.
• Actor - TokenSwap Proposer 👮
  • Calculates an optimized set of internal and external trades to execute in this rebalance and submits them to BasketManager.
• Actor - TokenSwap Executor 👮
  • Role that submits the calldata required to execute the submitted external trades.
  • If the Basket’s AggregatorAdapter is synchronous, TokenSwapProposer also executes the swaps.
• Actor - Rebalance Executor 🧑
  • Permissionless role that completes an ongoing rebalance and advances the epoch. Checks on the progress of the current rebalance are made.

​

External Assumptions

• Dependent oracles do not report incorrect prices.
• BasketManager does not have on-chain access to live quotes from aggregators.
  • We assume the confidence intervals given by Pyth Oracles are sufficient to use. An oracle registry will be managed by the DAO and individual Oracle wrappers can be deployed to support additional operations (aggregating, applying 4626’s price per share, etc).
• TokenSwapProposer uses the ideal exchange rates derived from on-chain oracles instead of live quotes when generating the list of internal and external trades.
• RebalanceProposer will submit a set of internal and external trades that describes the changes in ALL baskets.
• Assets in BM are high quality (e.g. USDT, USDC, sDAI, sFRAX, stETH, cbETH) - liquid with low volatility and minimal instances of depegging.
• BasketManager is designed for standard ERC-20/4626 tokens, and is not concerned with the potential effects of rebasing or non-standard ERC-20/4626 implementations such as fee-on-transfer tokens.

​

Entity–relationship model

​

Rebalance lifecycle flowchart

​

User actions flowchart

​

Overview of the rebalancing sequence

1. Each Weight Proposer asynchronously updates any WeightStrategy instances that they manage.
   • Updates can be proposed until the rebalance starts. For resolvers that have not been updated since the last rebalance, the prior target weights will be reused.
   • If a Weight Strategy’s methodology is difficult to prove or implement on-chain, the Weight Proposer for the strategy should be permissioned.

Details (Click to expand)

2. Rebalance Proposer (DAO) calls BasketManager.proposeRebalance().
   • Calculate the new total target token amounts based on each basket’s target weight.

Details (Click to expand)

3. TokenSwap Proposer (DAO) calculates the optimal swap pairs to reach the target amounts of each basket and calls BasketManager.proposeTokenSwap(Trade[] internalTrades, Trade[] externalTrades) to submit all necessary swap amounts and the associated basket and target weight information. BasketManager performs minimal on-chain validation to ensure the inputs align with each basket’s target weights. If more advanced validation is needed, the role can be assigned to a separate contract using Axiom, transforming the process from a variable to a fixed cost.

Details (Click to expand)

4. TokenSwap Executor uses quotes from the relevant API and then calls BasketManager.executeTokenSwap(externalTrades, bytes data) where the data is optional information required for the current token swap adapter.

Details (Click to expand)

5. If required, TokenSwap Executor submits orders to the off-chain API for execution (e.g. CoW Swap API).
   • Responsible for reading the stored orders from BM and submit them using off-chain API.
     • CoW Swap orders have unique IDs so once a trade is executed it can no longer be filled so replays or duplicate submissions are not problematic.

Details (Click to expand)

6. Rebalance Executors calls BasketManager.completeRebalance , executing any checks and validations needed to complete the rebalance and advance the epoch.
   • Responsible for completing rebalances and advancing the epoch.

Details (Click to expand)

​

Window timings and retries

After each step, the 15-minute window is reset. If the proposer role doesn’t call within the window, then anyone can call completeRebalance to exit the rebalance process.

• proposeRebalance
  • Charges management fee and processes deposits for rebalancing baskets.
  • Determines target weights.
  • Opens a 15-minute window for proposeTokenSwap.
  • If proposer role doesn’t call within the window, anyone can call completeRebalance.
• proposeTokenSwap
  • Settles internal trades and checks minimum amounts for external trades against on-chain oracle values.
  • Prolongs the ongoing rebalance window by an additional 15 minutes to allow sufficient time for swap execution.
  • If not called within the window, anyone can call completeRebalance.
• executeTokenSwap
  • Executes token swap with extra data if necessary.
  • After 15 minutes, anyone can call completeRebalance.
• completeRebalance
  • Checks if the current basket weights are within a specified tolerance of the target weights.
    • If not, retries up to 3 times, resetting the state as if proposeRebalance was just called.
  • If pending redemptions can’t be fulfilled (not enough base asset), basket tokens are notified of the failed rebalance and users must claim shares back.

​

Sequence diagrams

​

CoW Swap adapter

​

Generic dutch auction adapter

​

Basket actions

​

Creating a new Basket

Baskets are specified by their:

1. Combination of assets to be considered in the allocation.
2. Address of the weight strategy contract

The Basket is then deployed using keccak256(uint256 selectionBitFlag, address weightStrategy) as the salt, preventing duplicate deployments of the same config. Creation of new basket is permissioned.

​

Deposit/Mint

Deposits will be asynchronous and will be fulfilled at the start of each rebalance. Users can claim their shares after the next rebalance is finished.

• Users call requestDeposit
  • This transfers the base asset to the BasketManager contract.
• Protocol processes deposits at the next rebalance proposal, which transfers the base asset into the BasketManager, and credits the user’s basket token contract with the corresponding shares.
• After the rebalance is finished, users who requested deposit can now claim their shares by calling deposit or mint functions.

​

Redeem

Redeem will also be asynchronous if the user desires to receive the base asset only. Alternatively, we offer users to the ability to redeem basket tokens at any time for the their pro-rata allocation of the underlying tokens.

1. Synchronously
   • Users call proRataRedeem
     • Burn basket token from the user.
     • Transfer the currently allocated assets of the basket the user calculated pro-rata.
     • $q_{i} = BT_{burn} \times \frac{q_{i,total}}{B}$
     • where $q_{i,total}$ is the total quantity of the i-th token in the basket, and $B$ is the total supply of basket tokens.
   • Users receive a set of tokens instead of the base asset.
2. Asynchronously
   • Users initiate the process by calling requestRedeem, which transfers their basket token shares and requests these shares to be burned in exchange for the base asset.
   • Redeems are processed at the conclusion of the next rebalance. If the basket manager successfully acquires sufficient base assets, it transfers the corresponding base asset to each basket token contract and burns the requested basket token shares.
     • If the rebalance fails, after its completion, the users can call claimFallbackShares to retrieve their previously requested basket token shares.
   • Users who previously called requestRedeem can then call redeem or withdraw on the respective basket token contract to claim the underlying assets.

​

Update bitFlag

The BasketManager contract allows the bitFlag of an existing basket to be updated through the updateBitFlag function. This function is restricted to only be callable by the _TIMELOCK_ROLE. To update a basket’s bitFlag:

1. Call updateBitFlag(address basket, uint256 bitFlag) with the following parameters:
   • basket: The address of the basket token to update.
   • bitFlag: The new bitFlag value. It must be a superset of the current bitFlag.
2. The function will perform the following checks:
   • The basket must exist and be registered in basketTokenToIndexPlusOne.
   • The new bitFlag must be different from the current one.
   • The new bitFlag must be a superset of the current bitFlag, meaning it includes all the bits set in the current bitFlag.
   • The basket’s strategy must support the new bitFlag.
   • The new basketId (hash of bitFlag and strategy) must not already exist to prevent duplicate baskets.
3. If all checks pass:
   • The old basketId mapping is removed and the new one is added to basketIdToAddress.
   • The basketAssets for the basket are updated based on the new bitFlag.
   • The BasketBitFlagUpdated event is emitted with the old and new bitFlag values and IDs.
   • The bitFlag is updated in the BasketToken contract.

This process allows baskets to evolve over time by adding new assets while ensuring compatibility with the strategy and preventing duplicate baskets from being created.

​

LP tokens

Cove will use the ERC-7540 standard for LP tokens. Since this is an ERC20, Uniswap’s Permit2 will be compatible with the contract.

​

Pricing LP tokens

​

Problems

Pricing the tokens of each Basket in terms of a single token is challenging because:

1. Each Basket can hold a diverse portfolio of assets.
2. The specific combination and quantities of assets held by a Basket can vary from one epoch to another due to rebalancing. This dynamic nature of a Basket’s composition makes it difficult to determine a straightforward price for its tokens at any given point in time.

​

Solutions

• Use oracle prices of base asset combined with 4626’s price per share: $${BP}_{i}= \frac{\sum_{j=1}^{n} (q_{j} \cdot O_{j} \cdot P_{j})}{S_{i}}$$
  • $n$ = Number of different ERC-4626 tokens in the basket
  • $q_j$ = Quantity of the j*-*th ERC-4626 token in the basket
  • $O_j$ = Oracle price of the underlying asset of the j*-*th ERC-4626 token
  • $P_j$ = Price per share of the j*-*th ERC-4626 token in terms of the underlying asset
  • $S_{i}$ = Total supply of basket i
  • Does not reflect real value of basket tokens unless withdrawn pro-rata.

​

Risks

• This pricing will not account for execution costs for acquiring the assets thus relying on this could penalize depositors.
• This value is generated at the time user views the call.

​

Rebalancing optimization with linear programming

​

Problem

As number of baskets and available assets grows, it becomes not trivial to match intents. We will use linear programming to maximize the volume of internal trades. This minimizes losses (price impact/slippage) from accessing exogenous liquidity.

​

Variables

Let:

• $B = \{b_1, b_2, \ldots, b_n\}$ be the set of baskets
• $A = \{a_1, a_2, \ldots, a_m\}$ be the set of assets
  • $a_{U}$ be USDT
• $IT = \{ (b_i, b_l, a_j, a_k) \mid b_i, b_l \in B, b_i \neq b_l, a_j, a_k \in A, a_j \neq a_k \}$ be the set of all possible internal trades between two different baskets
• $ET = \{ (b_i, a_j, a_k) \mid b_i \in B, a_j, a_k \in A, a_j \neq a_k \}$ be the set of all possible external trades
• $x_{ij}$ be the current holdings of asset $a_j$ in basket $b_i$
• $x_{ij}^*$ be the ideal target holdings of asset $a_j$ in basket $b_i$
• $T_{ijkl}$ be the internal trade variable representing the amount of asset $a_j$ to trade from basket $b_i$ for asset $a_k$ from basket $b_l$
• $E_{ijk}$ be the external trade variable representing the amount of asset $a_j$ to trade from basket $b_i$ to an external party for asset $a_k$

​

Determining Current Holdings

This would be the balances of each asset including USDT that each basket is currently holding. The amount of USDT is the new user deposits that have accrued since the last rebalance process.

​

Determining Target Holdings

In order to determine the target holdings of assets, we need to account for users’ deposit requests and redeem requests. First we calculate how much ideal amount of USDT will be withdrawn from the basket. (Note that this is only an estimation and would not account for fees/slippage. The real amounts we end up with will vary based on slippage of each trade pairs). Since we know the total supply of the basket token and the amount of basket tokens submitted by the users for redeeming, the below formulae would be used for the target holding amounts.

• Let $V_i = \sum_{j=1}^{n}x_{ij} \cdot O_j \cdot P_j$
  • USD value of basket i before rebalancing, including the pending USDT deposit.

For the USDT target amount: $x_{iU}^* = \left( \frac{BT_{i}^{redeeming}}{\text{S}_i} \right) \times \dfrac{V_i - x_{iU}\cdot O_U}{O_U}$ For other assets’ target amounts: ${x}_{ij}^* = \left( V_i - x_{iU}^* \cdot O_{U} \right) \times \frac{\text{target weight}_j}{1} / (O_j \cdot P_j)$ Then after the rebalancing is successful, the resulting balance of USDT will be claimable by redeem requesters.

​

Objective Function

The objective function balances the cost of internal and external trades, heavily penalizing the latter to encourage internal matches when possible. We aim to minimize the volume of external trades with a higher penalty: $$\min Z = \alpha \sum_{(b_i, a_j, a_k) \in ET} E_{ijk} + \sum_{(b_i, b_l, a_j, a_k) \in IT} T_{ijkl}$$ where $\alpha$ is a large penalty constant for external trades (e.g., $\alpha = 1000000$).

​

Constraints

1. No Negative Holdings After Internal Trades: For each basket $b_i$ and each asset $a_j$: $x_{ij} + \sum_{l=1, l \neq i}^{n} \sum_{k=1, k \neq j}^{m} (T_{ljik} - T_{ijkl}) \geq 0$ This ensures that no basket ends up with a negative quantity of any asset due to internal trades.
2. External Trades Limited by Post-Internal Trade Balances: For each basket $b_i$ and each asset $a_j$ : $\sum_{k=1, k \neq j}^{m} E_{ijk} \leq x_{ij} + \sum_{l=1, l \neq i}^{n} \sum_{k=1, k \neq j}^{m} (T_{ljik} - T_{ijkl})$ This ensures that any external trades are limited by the available balance of the asset in the basket after accounting for internal trades.
3. Target Holdings Met After All Trades: For each basket $b_i$ and each asset $a_j$ $x_{ij} + \sum_{l=1, l \neq i}^{n} \sum_{k=1, k \neq j}^{m} (T_{ljik} - T_{ijkl}) + \sum_{k=1, k \neq j}^{m} (E_{ijk} - E_{ikj}) \ge x_{ij}^*$ $x_{ij} + \sum_{l=1, l \neq i}^{n} \sum_{k=1, k \neq j}^{m} (T_{ljik} - T_{ijkl}) + \sum_{k=1, k \neq j}^{m} (E_{ijk} - E_{ikj}) \le (1 + \epsilon )\cdot x_{ij}^*$ This requires that the final holdings in each basket must match the target holdings after all trades have been completed.
4. Trade Variables Non-Negative: For all $T_{ijkl}$ and $E_{ijk}$: $T_{ijkl} \geq 0, \quad E_{ijk} \geq 0$ This ensures that all trade variables are non-negative, which is a standard requirement in trade optimization problems to prevent nonsensical negative trades.

​

Verifiable Computation with Trusted Execution Environments (TEEs)

The off-chain determination of optimal internal and external trades via linear programming introduces an element of trust. Participants in the Cove protocol rely on the TokenSwap Proposer to execute this complex computation faithfully and submit a genuinely optimized set of trades. While DAO governance provides a layer of oversight, the computational process itself remains opaque to external verifiers. Trusted Execution Environments (TEEs) offer a compelling solution to enhance the verifiability and integrity of this critical step. A TEE, such as Intel SGX or AMD SEV, provides a hardware-isolated environment within a processor where code and data can be protected against observation or tampering by the host system, including the operating system or hypervisor. Benefits for Cove’s Rebalancing Optimization:

1. Remote Attestation & Integrity: The linear programming solver can be executed within a TEE. Crucially, TEEs support remote attestation, a process where the TEE cryptographically proves to a remote party (e.g., the BasketManager contract or users) that a specific, audited piece of software (the solver) was loaded and executed correctly within the secure enclave, and that the output (the proposed trades) is the genuine result of this computation. This provides strong integrity guarantees for the optimization process, ensuring the proposed trades haven’t been manipulated. [ZTEE]
2. Reduced Trust Assumptions: By leveraging TEEs, the protocol can significantly reduce the trust placed in the TokenSwap Proposer’s operational security. Instead, trust shifts to the well-defined security properties of the TEE hardware and the attestation mechanism. This aligns with the broader DeFi ethos of minimizing reliance on trusted intermediaries.
3. Confidentiality (Potential Future Enhancement): While the primary benefit here is verifiable execution, TEEs also offer confidentiality. If parts of the input data for the linear programming (e.g., very specific trading intentions beyond basket weights) were deemed highly sensitive in future iterations, TEEs could protect this data even from the host running the computation.
4. Enhanced Transparency: While the computation inside the TEE is a “black box” to the host, the remote attestation process makes the choice of code and the integrity of its execution transparent and verifiable. This is a step towards what the Flashbots article terms “Zero Trust Execution Environments,” aiming to minimize trust dependencies. [ZTEE]

Considerations: Implementing TEE-based verifiable computation involves its own set of challenges, including the complexity of TEE application development, potential performance overheads (though likely acceptable for this off-chain process), and the inherent trust in the TEE hardware manufacturer and the key provisioning process. However, the substantial increase in verifiability and the reduction of trust in off-chain computation make TEEs a promising avenue for bolstering the security and trustworthiness of Cove’s rebalancing mechanism. [ZTEE] Flashbots. (2024-10-11). Zero Trust Execution Environments. https://writings.flashbots.net/ZTEE

​

Calculating deposits and redeems

• Let $V_i = \sum_{j=1}^{n}x_{ij} \cdot O_j \cdot P_j$
  • USD value of basket i before rebalancing, including the pending USDT deposit.
• Let $V_i^{*} = \sum_{j=1}^{n}x_{ij}^{*} \cdot O_j \cdot P_j$
  • Ideal USD value of basket i, using ideal target balances for each token.
• Let $V_i^{final} = \sum_{j=1}^{n}x_{ij}^{final} \cdot O_j \cdot P_j$
  • Actual USD value of basket i after all trades are successfully executed. This will be less then the ideal target balances due to slippage/costs.

First, the USDT that should be allocated for the requested redeems is calculated using the ideal exchange rate of the assets. Then we attempt to satisfy that the ideal USDT amount that should leave the basket. Then after the swaps are executed, for each basket, the amount to mint for deposits are determined by measuring the change of value of the basket

• $BT_{i}^{minted} = (V_i^{final} - x_{i,USDT}^{final}\cdot O_{USDT}) - (V_i - x_{i, USDT} \cdot O_{USDT})$
  • In case any of the trades associated with redemption fails, we replace the withdrawn value with the sum of value of the assets that will be withdrawn via proRataRedeem method.

During a rebalance period where there are new deposits, the slippage associated with rebalancing will be paid by the depositors not the existing basket users. In the ideal scenario, the prices at the end of the rebalance will not deviate greatly from the the beginning of the rebalance. In the case that it does, we use the latest oracle price to determine the depositors value.

​

Fees

The protocol incorporates two types of fees: a configurable management fee for each basket and a global swap fee for internal trades. Both fees are measured in basis points (BPS) with a precision of 1e4.

​

Management Fee

The management fee is calculated based on the time elapsed since its last computation, which occurs at the start of every rebalance cycle and when users exit via pro-rata redemption. The fee is determined using the following formula: $fee = totalSupply \times managementFeeBps \times \frac{timeSinceLastHarvest}{(1e4 - managementFeeBps) \times 365 days}$ Where:

• totalSupply is the current total supply of the basket token, excluding shares held by the fee collector or pending redemption.
• managementFeeBps is the management fee in BPS for the specific basket.
• timeSinceLastHarvest is the time elapsed since the last fee harvest.

The calculated fee is minted as new shares to the fee collector contract. The FeeCollector contract then divides the fee between the protocol treasury and the strategy sponsor according to the configured split percentage for each basket.

Details (Click to expand)

​

Swap Fee

The swap fee is a global fee applied to all internal token swaps during rebalancing. It is charged on both the buy and sell tokens of each trade. The fee is calculated as follows: $feeOnSell = sellAmount \times \frac{swapFeeBps}{2e4}$ $feeOnBuy = buyAmount \times \frac{swapFeeBps}{2e4}$ Where:

• sellAmount is the amount of the sell token being traded.
• buyAmount is the amount of the buy token being received (before fee deduction).
• swapFeeBps is the global swap fee in BPS.

The swap fees are accumulated in the BasketManager contract for each token and can be claimed by the protocol admin, which transfers the collected fees to the protocol treasury. The swap fee is not further divided and goes entirely to the treasury.

​

Maximum Fees

The protocol enforces maximum values for both the management fee and swap fee to prevent excessive fees from being set. The maximum fees are as follows:

Fee Type	Maximum Value (BPS)
Management Fee	3,000 (30%)
Swap Fee	500 (5%)

Note that while the maximum values are set to 100%, it is expected that realistic fee values will be significantly lower to ensure the competitiveness and sustainability of the protocol. The management fee for each basket can be set individually by the protocol admin via the setManagementFee function in the BasketManager contract. The global swap fee can be set by the admin using the setSwapFee function in the same contract. Both functions enforce the respective maximum fee limits and can only be called by the protocol admin role.

​

Oracles

Cove employs oracles to value baskets and settle internal trades. The protocol is designed to support pluggable oracle implementations using euler-price-oracle.

​

Oracle Adapter Types

Cove defines the following oracle adapter types:

• ERC-4626 Oracle: Converts between an ERC-4626 vault’s shares and its underlying asset using convertToAssets and convertToShares. This adapter is intended for use when no direct oracle exists for the vault token.
• Chained ERC-4626 Oracle: Extends the ERC-4626 Oracle functionality to a chain of vaults (maximum depth of 10) until a target asset is reached, performing sequential conversions along the chain.
• Curve EMA Oracle (Underlying): Reads the Exponential Moving Average (EMA)-based pricing exposed by Curve Stable-Swap-NG pools. Configuration flags determine whether the pool’s price is expressed in vault shares or underlying assets.

​

Anchored Oracle Behaviour

The AnchoredOracle implementation includes the following behaviors:

• Automatic rescaling of the input amount if the primary quote is less than 1 WAD (i.e., 1e18) to preserve precision.
• Explicit ScalingOverflow revert on extreme input values.
• The maxDivergence parameter is bounded between 0.1% and 50%; the constructor will revert if values outside this range are provided.

​

Interface and Registration

• Cove oracle adapters must conform to the EIP-7726 (IPriceOracle) interface.
• Oracle registration is managed via an OracleRouter contract, which is referenced by the BasketManager. Deployment scripts are responsible for the on-chain registration of each adapter. If an AnchoredOracle instance is used, its corresponding (primary, anchor) oracle pair must also be registered.

The primary oracle implementation utilized is AnchoredOracle. This smart contract implements the IPriceOracle interface by retrieving quotes from a primary oracle and validating them against an anchor oracle. The primary quote must be within a specified divergence range from the anchor quote before the price is returned. This mechanism provides an additional layer of security against stale or manipulated oracle prices. For assets that cannot be priced directly in USD, a CrossAdapter is utilized with the base asset.

​

Risks

• Managers of each WeightStrategy’s gas payment increases as the number of baskets grow.
• Incorrect price calculation of a single asset could lead to incorrect accounting of the baskets.
• If Cove is unable to complete swaps to facilitate withdrawals users will be required to withdraw their assets in-kind.

​

Potential Griefing Attack via Pending Deposits/Redeems

When users call requestDeposit or requestRedeem, the system ensures that the controller does not have any pending or claimable deposits or redeems from the controller’s lastDepositRequestId. This behavior allows for a potential griefing attack: an attacker can call requestDeposit or requestRedeem with a minimal dust amount and specify the target controller address. As a result, the target controller would then be unable to make legitimate requestDeposit or requestRedeem requests until they first claim the pending request. Recommendation for Integrators: When integrating the BasketToken into other contracts, always check for any pending or claimable tokens before requesting a deposit or redeem. This ensures that any pending deposits or redeems are resolved, preventing such griefing attacks.

​

Monitoring and Emergency Functionality

Cove includes several features to monitor the system and respond to emergencies:

​

Protocol and Asset Level Pausing

The protocol allows for pausing at both the protocol and asset level. When paused, all baskets that contain the paused asset will be affected, but pro-rata withdrawals are still allowed. This functionality is implemented in the BasketManager contract.

​

Off-Chain Keepers for Oracle Price Monitoring

Off-chain keepers, such as OpenZeppelin Defender, will be used to monitor oracle prices in real-time. For example, if the price of USDT falls below 0.99, the keeper can automatically pause the protocol to prevent further issues.

​

Real-Time Anomaly Detection Protocols/Services

Cove plans to integrate with real-time anomaly detection protocols and services, such as Forta, which can help identify and respond to potential threats or unusual activity within the protocol. These services can monitor for a wide range of issues, including:

• Unexpected changes in asset prices
• Large or suspicious transactions
• Unauthorized access attempts
• Smart contract vulnerabilities

By leveraging these monitoring and emergency response features, Cove can quickly identify and mitigate potential risks, ensuring the safety and security of users’ funds.

​

Alternatives considered

• Rebalancing methods
  • Auctions
    • The problem with auction mechanisms for frequent rebalancing is as follows (from Aera V1 Weight Update):
      • Auctions are overly sensitive to current market price,
      • Auctions restrict participation to larger pools of capital and infrastructure to identify and participate in the auction.
    • The main advantage from using an auction mechanism like Kuiper is removing the oracle dependency. However, that dependency is already implicit since oracles are used to value basket tokens. In theory, CoW Swap should offer better execution due to ring trades, and by outsourcing this functionality we can reduce the complexity of the protocol and tap into CoW Swap’s existing network of solvers. Cove will also support using dutch auctions to rebalance via an adapter as a fallback.
    • Existing work
      • Kuiper (oracle-less) - https://kuiper.gitbook.io/kuiper-docs/protocol/rebalancing-auctions
      • Set (uses MakerDAO price feeds) - https://help.tokensets.com/en/articles/3399436-how-to-participate-in-set-protocol-rebalance-auctions
  • Balancer’s Managed Pools (Aera V1)
    • While it retains some benefits of TWAP’ing, still suffers from loss-versus-rebalancing.
• Omitting contract events and using shadow events for gas optimization (Shadow)
  • Seems like a premature optimization given how much tooling relies on events.

​

Related work

• Kuiper
• Tokemak’s Autopilot v2
• Gauntlet’s Aera v2
• Definitive
• Set
• Sandclock
• SUClave
• Indexed Finance

​

Acknowledgements

Special thanks to Joey Santoro (Variant), Tarun Chitra (Gauntlet), Ken Deeter (Electric), Saneel Srini (Accomplice), Peteris Erins (Auditless/Aera), Elliot Friedman (Solidity Labs), Storm Slivkoff (Paradigm), and Will Price for their feedback after reviewing drafts.