Manual Off-Ramping of Incentive Tokens via OAVs
Strategies used when deploying Yield.xyz Allocator Vaults may generate additional rewards in the form of incentive tokens provided by underlying protocols. These rewards do not accrue directly in the position and do not compound, but instead accrue as additional positions that users need to claim, manage, offramp into the deposit token and reinvest back into the strategy. This means that the stated APY provided by DeFi protocols paying parts of the rewards in incentive tokens is incorrect since they don’t account for gas cost, slippage, and price volatility of the incentive tokens.
To fully abstract the downsides and complexity of incentive token based payouts, Yield.xyz Allocator Vaults take care of claiming additional incentive tokens, swapping them for the underlying deposit token and depositing the underlying back into the vault.This ensures that the vault’s earnings compound at an increased rate and that users earn pure yield — in the asset they deposited.
Off-ramping and redeposit transactions need to be signed, which can be done self-custodially or custodially. Below we provide details on both options:
Manual Claiming & Reinvesting Process Example
Step-by-Step Flow:
- Claim Rewards
- A Yield.xyz wallet with
ADMIN_ROLEexecutes theclaimAdditionalRewardsfunction. Claimed tokens (e.g. MORPHO) transfer to the designated wallet.
- A Yield.xyz wallet with
- Swap Tokens via DEX (e.g. Aerodrome)
- MORPHO tokens swapped to the deposit token (e.g. USDC)
- Deposit into Underlying Strategy
- Deposit USDC into underlying strategy (e.g. Seamless USDC Vault):
- Receive yield-bearing receipt token (e.g. smUSDC) in the wallet with
ADMIN_ROLE
- Deposit Receipt Tokens into Yield.xyz Vault
- Transfer yield-bearing receipt token (smEURC) from multi-sig to Yield.xyz vault. This increases the total assets within the vault without creating new shares.
Approval & Signing Process
Each step above requires individual approvals of involved parties to ensure security, transparency, and alignment between Yield.xyz, the client, and optionally, the custodian.
To perform these actions, Yield.xyz clients may choose custodial or self-custodial options to co-sign each transaction, or leave it completely under control of Yield.xyz and a preferred custodian partner.
Custodial Flow
Yield.xyz deployed allocator vaults will claim all earned incentive tokens based on an ideal claiming and reinvestment analysis. Each compounding cycle will require multiple transactions to be signed (claim rewards function call, token swap, deposit into the underlying vault, transfer to the Yield.xyz vault).
Transactions are constructed by Yield.xyz and require approval from custodial partners such as CorpaTrust. This custodial integration allows automated signing via custodian’s API ensuring that transactions are processed without any delay but with full custodial approval.
Self-Custodial Flow
A similar approach may be taken without involvement of custodians. In such a case, Yield.xyz utilizes a multi-sig wallet (e.g., Safe) with multiple stakeholders acting as signers. Following the initiation of an individual transaction, the transactions execute automatically once the predefined signing threshold is achieved.
Transaction Construction:
StakeKit API initiates the process by constructing each individual transaction that is required to complete the cycle. The transaction is programmatically generated, specifying the exact amounts, the receiving addresses, and any relevant parameters required by the vault or protocol.
Multi-Sig Signing:
The constructed transaction is presented to the multi-sig wallet, where each stakeholder independently reviews the transaction. Signatures are verifiable, providing transparent and immutable transaction histories.
The multi-sig wallet continuously monitors signatures, automatically executing the transaction when the minimum required signatures (the predefined threshold) are met.
Custodian Approval (Optional):
If additional custodial oversight is required, a custodian can sign transactions using Fireblocks, providing an extra validation layer. This significantly enhances security by introducing an independent approval step, reducing operational risks such as signatory collusion or unauthorized transactions.
In this setup, a Safe multi-sig wallet is utilized, with Fireblocks account acting as one of the signers. The transaction is created in Safe and submitted via the Fireblocks API for signing. After receiving Fireblocks' signature, additional signatures are gathered from the remaining signers before executing the transaction.
Step-by-step Process:
- Transaction is constructed via StakeKit API to claim incentive tokens and proposed to multisig
- All signers signs
- (Optional): Custodian signs via Fireblocks
- Transaction is constructed via StakeKit API to swap incentive tokens to underlying token via DEX
- All signers signs
- (Optional): Custodian signs via Fireblocks
- Transaction is constructed via StakeKit API to deposit into underlying strategy
- All signers signs
- (Optional): Custodian signs via Fireblocks
- Transaction is constructed via StakeKit API to send the strategy token into the Vault
- All signers signs
- (Optional): Custodian signs via Fireblocks
Updated about 9 hours ago
