Yield Bearing Token Adapter

The Yield Bearing Token Adapter is a library that provides a standardized interface for interacting with different types of yield-bearing tokens. This abstraction layer allows YieldShield to work seamlessly with various DeFi protocols and token standards.

Overview

Different DeFi protocols use different standards and mechanisms for yield-bearing tokens. The Adapter library abstracts these differences, allowing the Split Risk Pool to calculate yields and asset values consistently regardless of the underlying token type.

Purpose

The Adapter serves several key purposes:

  • Unified Interface: Provides a single function (previewRedeem) that works across different token types
  • Yield Calculation: Calculates how many assets would be redeemed for a given amount of yield-bearing tokens
  • Time-Based Yields: Supports time-based yield calculations for tokens that accrue yield over time
  • Protocol Abstraction: Hides the complexity of different DeFi protocol integrations

Supported Token Types

The Adapter currently supports three token types:

Type 0: Mock Tokens

Mock tokens used for testing and development:

  • Uses previewRedeem(uint256, uint64) function signature
  • Accepts a timeElapsed parameter (in days) for time-based yield calculation
  • Allows simulation of yield accrual over time

Type 1: ERC4626 Tokens

Standard ERC4626 vault tokens:

  • Uses standard previewRedeem(uint256) function
  • Yield is calculated based on current vault share price
  • No time parameter needed (yield is implicit in share price)

Type 2: Aave Tokens

Aave protocol tokens (aTokens):

  • Uses getReserveNormalizedIncome(address) from the Aave pool contract
  • Requires a vault/pool address (passed as vault parameter)
  • Returns the normalized income index for yield calculation

previewRedeem Function

The core function of the Adapter is previewRedeem, which calculates how many underlying assets would be received for a given amount of yield-bearing tokens.

Function Signature

function previewRedeem(
    address token,
    uint256 assets,
    uint64 timeElapsed,
    uint16 tokenType,
    address vault
) internal view returns (uint256)

Parameters

  • token: Address of the yield-bearing token
  • assets: Amount of yield-bearing tokens to preview
  • timeElapsed: Time elapsed since deposit (in days, used for Type 0)
  • tokenType: Type identifier (0, 1, or 2)
  • vault: Vault/pool address (required for Type 2, can be address(0) for others)

Return Value

Returns the amount of underlying assets that would be redeemed, accounting for accrued yield.

Integration with Split Risk Pool

The Adapter is used by Split Risk Pool in several key operations:

Yield Calculation

When calculating fees and commissions, the pool uses the Adapter to:

  • Calculate current asset value based on original deposit
  • Determine yield earned over time
  • Account for different token types seamlessly

Deposit Tracking

The pool stores assetsInVault for each insured deposit, which represents the base assets at deposit time. When calculating yield, the Adapter is used to determine the current value of these assets.

Cross-Asset Operations

For cross-asset withdrawals and valuations, the Adapter ensures consistent calculations regardless of the token type being used.

Error Handling

The Adapter includes error handling for:

  • Unsupported token types
  • Missing vault addresses (for Aave tokens)
  • Failed static calls to token contracts
  • Invalid return data

Future Extensibility

The Adapter is designed to be extensible. Additional token types can be added by:

  • Adding new type identifiers
  • Implementing the appropriate static call logic
  • Updating the previewRedeem function to handle the new type

This allows YieldShield to integrate with new DeFi protocols as they emerge without requiring changes to the core pool logic.

Design Benefits

  • Separation of Concerns: Token-specific logic is isolated in the adapter
  • Gas Efficiency: Uses static calls (view functions) for calculations
  • Type Safety: Token type is explicitly specified, preventing errors
  • Maintainability: Changes to protocol integrations don't affect pool logic