Fathom Protocol
  • Introduction
  • FXD Stablecoin
    • FXD Smart Contract Architecture
    • Minting and Burning Mechanisms with LTV Ratio
    • Soft-Pegging to the US Dollar
    • Opening and closing position flows
    • BookKeeping mechanism
      • Stablecoin Accounting
      • Collateral Accounting
    • Liquidation
      • Fixed Spread Liquidation Strategy
      • Liquidation process walk through
    • Emergency Shutdown
    • Maths for position safety
    • Fee structure
    • Risk Management
    • Interfaces
      • ProxyWalletRegistry
      • ProxyWallet
        • FathomStablecoinProxyActions
      • CollateralPoolConfig
      • BookKeeper
      • FXD
      • LiquidationEngine
      • FlashMintModule
      • PriceFeed
      • ShowStopper
      • StabilityFeeCollector
      • SystemDebtEngine
      • AdminControls
    • Deployments
      • XDC Network
    • User Guides
      • Open FXD position
      • Top Up FXD Position
      • Repay and close FXD position
    • Fathom Stablecoin Smart Contracts
    • Fathom Stablecoin Subgraph
  • Vaults
    • Key Features
    • Definitions
    • Architecture
    • Fees
    • Workflows
    • Vault Management
    • Strategy Creation
    • Interfaces
      • Factory
      • Vault
      • BaseStrategy
      • TokenizedStrategy
    • Deployments
      • XDC Network
    • User Guides
      • Deposit and Withdraw in Vault
    • Fathom Vaults Smart Contracts
    • Fathom Vaults Subgraph
  • Lending
    • Core Concepts
    • Protocol Mechanics
    • Architecture
    • Interfaces
      • FmToken
      • VariableDebtToken
      • StableDebtToken
      • L2Pool
      • PoolAddressesProvider
    • User Guides
      • Supply, Borrow, Repay and Withdraw Asset
    • Deployments
      • XDC Network
    • Fathom Lending Smart Contracts
    • Fathom Lending Subgraph
  • DEX
    • Core Concepts
    • Architecture
    • Interfaces
      • Factory
      • Pair
      • Router
    • User Guides
      • Providing Liquidity
      • Swapping Assets
    • Deployments
      • XDC Network
    • Fathom DEX Smart Contracts
    • Fathom DEX Subgraph
  • DAO
    • DAO Structure
    • Governance Process
    • Staking Process
    • Treasury Management
    • Risk Management and Security Measures
    • Contributing to Fathom DAO
    • Interfaces
      • FTHM
      • Staking
        • Vault
        • RewardsCalculator
        • vFTHM
      • Governance
        • TimelockController
    • Deployments
      • XDC Network
    • User Guides
      • Staking
      • Proposing
      • Voting
    • Fathom DAO Smart Contracts
    • Fathom DAO Subgraph
  • Whitepaper
    • Version 1.0
  • Resources
  • FXD Deployments
  • FTHM Deployments
  • Privacy Policy
  • Terms of Service
Powered by GitBook

Copyright© Fathom App 2024.

On this page
  • Modifiers
  • Immutable Variables
  • Functions to Override
  • Optional Functions to Override
  • TokenizedStrategy Integration
  • Strategy Management and Maintenance
  • Security and Delegation Features

Was this helpful?

Export as PDF
  1. Vaults
  2. Interfaces

BaseStrategy

https://github.com/Into-the-Fathom/fathom-vaults-smart-contracts/blob/master/contracts/strategy/BaseStrategy.sol

The BaseStrategy provides a foundation for creating ERC-4626 compliant vaults, which integrate seamlessly with a TokenizedStrategy implementation contract. This structure allows for ease in developing customizable strategies while maintaining a consistent interface and functionality through delegation.

Modifiers

  • onlySelf: Ensures that the function is called internally by the strategy itself, typically to confirm actions are a result of delegate calls from the strategy to the TokenizedStrategy.

  • onlyManagement: Verifies that the caller is authorized under the strategy’s management role, controlling strategy operational parameters.

  • onlyKeepers: Restricts function access to authorized keepers or management, facilitating routine maintenance and operational tasks.

  • onlyEmergencyAuthorized: Limits access to emergency functions to addresses with emergency authorization, enhancing security and control in crisis situations.

Immutable Variables

  • tokenizedStrategyAddress: Address of the TokenizedStrategy implementation used across all strategies for handling logic and storage.

  • TokenizedStrategy: A reference to the TokenizedStrategy instance, treating the strategy as if it’s a library for internal function calls.

  • asset: The ERC20 token that the strategy operates on, used for yield-generating activities.

Functions to Override

  • _deployFunds(uint256 _amount): Handles the deployment of specified amounts of the asset into yield-generating positions.

  • _freeFunds(uint256 _amount): Designed to release funds from investment positions, adjusting the strategy’s asset allocation.

  • _harvestAndReport(): Gathers yield and rebalances the strategy’s assets to reflect the actual holdings accurately.

Optional Functions to Override

  • _tend(uint256 _totalIdle): Manages the strategy’s assets between reporting periods, optimizing yield generation and position management.

  • _tendTrigger(): Indicates whether the _tend function should be invoked, based on specific strategy conditions or thresholds.

TokenizedStrategy Integration

  • deployFunds(uint256 _amount): Delegates fund deployment to the TokenizedStrategy, allowing it to handle the specifics of asset investment.

  • freeFunds(uint256 _amount): Delegates the release of funds to the TokenizedStrategy, ensuring that withdrawal requests are honored efficiently.

  • harvestAndReport(): Provides an accurate and updated accounting of the strategy’s total assets, delegating reporting to the TokenizedStrategy.

Strategy Management and Maintenance

  • tendThis(uint256 _totalIdle): Facilitates the active management of the strategy’s resources, optimizing asset allocation and performance.

  • shutdownWithdraw(uint256 _amount): Allows for the strategic withdrawal of funds in emergency scenarios, managed through the TokenizedStrategy to ensure consistency and reliability.

Security and Delegation Features

  • _delegateCall(bytes memory _calldata): Facilitates direct interactions with the TokenizedStrategy by forwarding calls and handling returned data or errors.

  • fallback(): Ensures all unspecified calls or data sent to the strategy are forwarded to the TokenizedStrategy, leveraging its logic and storage capabilities.

PreviousVaultNextTokenizedStrategy

Last updated 11 months ago

Was this helpful?