Overview of Fathom's FXD Stablecoin Smart Contracts

The Fathom stablecoin smart contracts form the technical backbone of the Fathom stablecoin (FXD), a crucial component of the Fathom Protocol. These contracts are engineered to provide a secure, efficient, and transparent mechanism for stablecoin operations, aligning with the broader goals of the Fathom Protocol to enhance liquidity and stability within the DeFi ecosystem.

Key Technical Aspects

1. Smart Contract Architecture: The Fathom stablecoin smart contracts are built on a modular architecture, ensuring scalability, upgradability, and maintainability. This architecture comprises several interlinked contracts, each handling specific aspects of the stablecoin's lifecycle, including minting, burning, and transaction processing.

2. Minting and Burning Mechanisms with LTV Ratio: At the heart of the smart contracts are the mechanisms for minting and burning FXD. Minting occurs when users collateralize their position, with the amount of FXD minted governed by the Loan-to-Value (LTV) ratio. This ensures a balanced issuance of FXD, aligning with the value of the collateral. Conversely, burning happens when FXD is returned to the protocol, particularly during position closures or liquidation events, to maintain the supply in line with market dynamics and collateral value.

3. Soft-Pegging to the US Dollar: The smart contracts implement a soft-pegging mechanism that ties the value of FXD to the US dollar. This is achieved through the StableSwapModule, which creates arbitrage opportunities that incentivize price pegging towards $1. As a result, the stablecoin’s value remains consistently close to the pegged asset.

4. Advanced Fixed-Spread Liquidation (AFSL): A liquidator can repay a fraction of the borrower's debt and acquire its collateral at a discount. Additionally, to the basic model of AFSL, FXD implements batch liquidation processing as part of the migration to .

What is the Fathom Protocol?

The Fathom Protocol is a pioneering decentralized finance platform. Its primary aim is to bolster the liquidity by positioning FXD, an over-collateralized and soft-pegged stablecoin. The other parts of the Fathom ecosystem are built around FXD: Vaults, Lending, DEX and Oracles. Fathom is operated in the DAO framework..

Key Highlights of the Fathom Protocol

1. Fathom's FXD: The Over-Collateralized, Soft-Pegged Stablecoin: FXD stands as a cornerstone of the Fathom Protocol, being soft-pegged to the US dollar. This approach provides a stable and reliable digital currency, aiming to minimize cryptocurrency's inherent volatility.

2. Fathom's Vaults: Platform designed for astute investors seeking to enhance their digital asset portfolio. Vaults offer a secure and dynamic way to grow cryptocurrency investments through robust yield strategies.

3. Fathom's Lending: Decentralized non-custodial liquidity market where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market to earn a passive income, while borrowers can borrow in an over-collateralized (perpetually) or under-collateralized (one-block liquidity) fashion.

4. Fathom's Decentralized Exchange (DEX): As the central trading hub within the Fathom ecosystem, the DEX enhances the liquidity of both XDC and FXD. It's a key platform for facilitating secure and efficient trading activities.

5. Fathom's Oracles: Decentralized oracle network powered by Fathom's FXD with high availability, reliability, and data accuracy.

6. Governance through Fathom DAO: The Fathom protocol is driven by the Decentralized Autonomous Organization (DAO), which integrates the FTHM token, governance, and staking. This framework empowers FTHM token holders with voting rights and a say in the protocol's governance and future direction.

Vision for DeFi Evolution: The Fathom Protocol is uniquely positioned to contribute significantly to the evolution of DeFi. Its focus on providing a stable digital currency and a fluid trading environment underscores its commitment to advancing decentralized finance.

Minting Mechanism with LTV Ratio Consideration

1. Collateralization and LTV Ratio: In the Fathom Protocol, users provide collateral to borrow FXD. The Loan-to-Value (LTV) ratio determines the maximum loan amount. This ratio specifies the maximum proportion of the borrowed value relative to the collateral's value.

2. Example of LTV-Based Minting: For instance, if a user collateralizes $100 worth of collateral asset and the LTV ratio is 65%, the user can borrow up to $65 worth of FXD. This system ensures that the minting of FXD is always in alignment with the value of the collateral based on the predetermined LTV ratio.

The complete explanation of the Fixed Spread Liquidation Strategy can be found in .

Described in https://docs.fathom.fi/whitepaper/version-1.0#id-5-fathom-sources-of-revenue.

The StabilityFeeCollector is a contract responsible for collecting stability fees from various collateral pools within a FXD system. These fees are used to manage the stability of FXD by compensating for volatility in the collateral's value and ensuring the system's solvency. The contract provides functionality to calculate and accrue stability fees over time, ensuring they are consistently applied and collected.

Storage Variables

Fathom Vaults is a cutting-edge financial platform that leverages blockchain technology to offer optimized asset management solutions. Built on a robust and secure framework, Fathom Vaults allows users to participate in a variety of investment strategies that not only include traditional DeFi protocols but also extend into Real-World Assets (RWA) and Trade Finance. Central to the ecosystem is the , a stable digital currency that provides a stable medium of exchange and a store of value across various investment strategies.

Fathom Lending is an advanced decentralized lending protocol that allows users to lend and borrow assets seamlessly. Designed to be robust, secure, and user-friendly, Fathom Lending offers a comprehensive suite of features to facilitate decentralized finance (DeFi) operations.

Key Features

• Decentralized and Trustless: Operates without a central authority, ensuring that all transactions are transparent and trustless.

• Variety of Supported Assets: Supports a wide range of assets, allowing users to diversify their portfolios and manage risk effectively.

• Dynamic Interest Rates: Utilizes advanced algorithms to provide competitive and dynamic interest rates for both lenders and borrowers.

• Secure Collateral Management: Implements rigorous security protocols for collateral management, ensuring the safety of user funds.

• Efficient Liquidation Mechanisms: Employs efficient liquidation processes to manage under-collateralized positions and protect the protocol's integrity.

• Interoperability: Designed to integrate with other Fathom products and 3-rd party DeFi platforms and services, enhancing its utility and user experience.

Multi-sig Treasury Operations

The Fathom DAO treasury is managed through multi-signature wallets. These wallets require multiple authorized signatures to execute transactions, ensuring security and decentralization. This mechanism prevents unilateral control and enhances trust within the community.

Use of Treasury Funds

Treasury funds are utilized for various purposes including development, marketing, ecosystem growth, and other operational expenses. The strategic allocation of these funds aims to support the long-term sustainability and growth of the Fathom ecosystem.

Funding Proposals and Distributions

Members of the DAO can submit proposals for funding from the treasury. These proposals are reviewed and voted on by the community. Upon approval, funds are distributed according to the proposal's specifications. This process ensures transparent and democratic management of the DAO’s resources.

How to Stake FTHM

To stake FTHM, users need to deposit their FTHM tokens into the staking contract via the Fathom platform. This process locks the tokens in the contract, allowing users to earn staking rewards and participate in governance.

Lock Positions and Unlocking

Staked FTHM tokens are locked for a predefined period, during which they cannot be withdrawn. After the lock period, users can unlock their tokens by initiating an unlock request, which may have an additional delay before tokens are fully accessible.

Rewards and Incentives

Stakers earn rewards based on the amount of FTHM staked and the duration of the stake. Rewards can include additional FTHM tokens and governance privileges. The incentive structure encourages long-term participation and alignment with the protocol’s success.

How to Become Involved

To become involved in Fathom DAO, start by joining the community channels, such as the official Telegram and X(Twitter). Participate in discussions, stay updated on the latest proposals, and contribute your ideas. You can also acquire FTHM tokens to participate in governance and staking activities.

Community Roles and Responsibilities

Members can take on various roles, including:

• Contributors: Propose and develop new features or improvements.

• Voters: Participate in the governance process by voting on proposals.

• Stakers: Stake FTHM tokens to support the network and earn rewards.

• Moderators: Help manage community discussions and enforce guidelines.

Each role comes with responsibilities, ensuring the smooth operation and growth of the DAO through active and constructive participation.

Proposal Submission

Any FTHM holder can submit a proposal to the DAO. Proposals can include protocol upgrades, new feature implementations, or changes in governance rules. Proposals must be well-documented and include clear objectives and potential impacts on the ecosystem.

Voting Process

Once a proposal is submitted, it goes through a voting period where vFTHM holders cast their votes. Each vFTHM represents one vote. The proposal requires a certain quorum to be reached and, if approved by a majority, it is implemented.

Role of vFTHM in Governance

vFTHM tokens are crucial in the governance process. Only holders of vFTHM can vote on proposals, ensuring that those who have staked FTHM and have a vested interest in the protocol's success are making the decisions. This system aligns the incentives of active participants with the long-term health and stability of the Fathom DAO.

Addresses on XDC mainnet

• Factory: 0x9fAb572F75008A42c6aF80b36Ab20C76a38ABc4B

• Router: 0x7e5b4c238A904329596c4094877D48868d739963

• Multicall 0xeDA95e2B6BA4196A428Dc824B4fBd8f6dd39E518

Addresses on Apothem testnet

• Router: 0x546F62f88cECefF9a0035156d8D456AfeEEcDe8a

For the complete explanation refer to the DAO section in Whitepaper.

The Fathom DAO (Decentralized Autonomous Organization) plays a crucial role in the governance of the Fathom Protocol. It is designed to empower the community by allowing token holders to participate directly in decision-making processes. This decentralized governance structure ensures that the development and operational aspects of the Fathom Protocol align with the interests and inputs of the community. Through the Fathom DAO, stakeholders can propose, vote on, and implement changes within the protocol, influencing everything from technical adjustments to financial strategies. This engagement helps ensure the protocol remains secure, innovative, and responsive to the needs of its users.

Oversight and Emergency Measures

Fathom DAO employs continuous oversight through dedicated committees to monitor and manage risks. In case of emergencies, predefined protocols allow for quick and effective responses, including temporary pauses in operations and activating security measures to protect the protocol and its assets.

Updating and Upgrading Governance Protocols

Governance protocols are regularly reviewed and updated to adapt to new challenges and opportunities. This includes implementing security patches, enhancing smart contract functionality, and ensuring compliance with industry best practices. Community members are involved in the decision-making process through proposals and votes, maintaining transparency and collective responsibility.

The liquidation process in the Fathom protocol involves several key components and steps outlined in detail in the LiquidationEngine and FixedSpreadLiquidationStrategy contracts. The liquidation mechanism maintains the system's stability by handling under-collateralized positions. Here is an overview of the process:

Components Involved:

1. Liquidation Engine (LiquidationEngine): Manages the overall liquidation process.

2. Fixed Spread Liquidation Strategy (FixedSpreadLiquidationStrategy): Implements a specific strategy for liquidation.

3. Collateral Pool Config (CollateralPoolConfig): Provides configuration for collateral pools, including parameters like liquidation ratio, close factor, and liquidator incentives.

4. BookKeeper (BookKeeper): Records positions, stablecoin balances and collateral.

5. System Debt Engine (SystemDebtEngine): Manages the system's overall debt and surpluses, including systemBadDebt and systemSurpluses.

6. Price Oracle (PriceOracle): Provides price feeds for collateral assets.

Liquidation Process:

1. Triggering Liquidation:

• A position becomes eligible for liquidation when its collateral value falls below a predefined threshold (defined by the liquidation ratio in CollateralPoolConfig). The liquidation Ratio is the same as ( 1 / Loan to Value Ratio).

• The PriceOracle plays a crucial role in determining the health of positions by providing the latest available prices for collateral assets.

1. Liquidation Execution:

• The liquidation process is initiated by a liquidator (which, at the moment, is a role only available to whitelisted addresses) who identifies an under-collateralized position and calls the liquidate function in LiquidationEngine.

• The liquidate function checks various conditions, such as the liquidator's whitelist status, the system's operational status (live), and the health of the price feed.

• If the conditions are met, LiquidationEngine interacts with the FixedSpreadLiquidationStrategy

1. Fixed Spread Liquidation Strategy:

• This strategy determines the specifics of the liquidation, such as the amount of debt to be repaid and the amount of collateral to be seized.

• It calculates the required parameters based on current prices, debt accumulated rates, and other factors defined in CollateralPoolConfig.

1. Financial Adjustments:

• Upon successful liquidation, the BookKeeper updates the financial state of the system, including adjusting the debt and collateral amounts for the liquidated position.

• The SystemDebtEngine may also handle any resultant bad debt from the liquidation process.

1. Distribution of Assets:

• The liquidator typically receives a portion of the seized collateral as an incentive, with the rest used to repay the debt.

• Parameters like liquidator incentives and treasury fees govern the distribution of assets.

1. Edge Cases and Safeguards:

• The system includes various safeguards and checks to prevent unauthorized access and ensure the integrity of the liquidation process.

• For instance, roles and permissions are enforced using access control mechanisms.

The following subsection guides you through the liquidation process in detail.

Fathom Protocol Smart Contract Architecture

The structure comprises distinct modules, each responsible for a set of defined operations.

Core Components

1. Proxy Module: Interfaces for the core contracts of the protocol.

   • ProxyWallet: Calls functions within the FathomProxyActions contract for user interactions.

   • ProxyActionsStorage: Stores the address of the FathomProxyActions contract.

   • ProxyWalletRegistry: Oversees the creation of proxy wallets owned by users.

2. Position Module: Handles the creation and tracking of user positions.

   • PositionManager: Initiates user positions and maintains a record of them.

3. Stablecoin Core Module: Central to the management of the FXD stablecoin's lifecycle.

   • BookKeeper: Monitors and manages each position's locked collateral and debt share.

   • CollateralPoolConfig: Manages configurations for collateral pools.

4. StableSwapModule: Supports the provision of liquidity and the execution of FXD<->xUSDT 1:1 swaps.

   • StableSwapModuleWrapper: Integrates and administers the protocol's liquidity pools.

5. Price Module: Delivers accurate price information for assets.

   • PriceFeed: Gathers price data from price source and feeds it into the protocol.

   • PriceOracle: Transforms raw price from PriceFeed to include a safety margin, using the LTV ratio.

6. Liquidation Module: Maintains the protocol's financial health by managing under-collateralized positions.

   • LiquidationEngine: Carries out the liquidation process according to predefined rules.

   • FixedSpreadLiquidationStrategy: Directs liquidation activities, ensuring consistency through a fixed spread.

7. Emergency Module: Pause or Terminate the protocol.

   • ShowStopper: Stops and terminates the whole protocol and executes the emergency shutdown process to return collateral

   • AdminControls: Pauses the protocol at once.

To open an FXD position, follow the steps below:

• Go to Fathom DApp.

• Connect your Web3 wallet (such as MetaMask) and make sure your network is set to the intended chain (i.e., XDC).

• Select your desired collateral pool in "Available Pools".

• Click "Open Position"

• Enter the amount you would like to provide as collateral.

• Enter the amount of FXD you would like to borrow.

  • You can also click "Safe Max" to borrow the maximum amount of FXD that can be considered relatively safe at the current moment.

  • Note that when you take out an FXD loan, during market volatility for your collateral assets, you should monitor the Safety Buffer because if it drops to 0 and lower, your position may be liquidated.

The images below depict the functional flows for opening and closing positions.

The FathomStablecoinProxyActions contract enables complex operations such as opening, managing, and interacting with positions (vaults) that hold collateral and issue stablecoins. It handles tasks like depositing collateral, drawing stablecoins against it, paying back debt, and unlocking collateral.

The address for this interface should be the address of the particular ProxyWallet.

Functions:

Admin Functions:

Fathom Vaults are designed to be straightforward and accessible to anyone with a vision for creating effective investment strategies. Unlike traditional systems that may centralize management, Fathom democratizes the ability to deploy, manage, and derive earnings from personalized vault configurations.

Deployment

Each vault version comes with its own Factory deployed for easy and secure vault deployment. To deploy a vault, interact with the factory using the deployVault method, which clones a pre-existing vault setup, ensuring consistency and reliability.

Setup

Post-deployment, you can customize your vault's settings:

• Roles: Define roles for different operational aspects of your vault. You can assign roles like strategy addition, debt management, and profit reporting.

Fathom DEX is a decentralized exchange that provides a seamless and efficient platform for swapping digital assets. Designed to operate in a permissionless and trustless environment, Fathom DEX empowers users by offering decentralized liquidity pools and automated market-making functionalities. Here are some key features and benefits of Fathom DEX:

Key Features

1. Decentralized Liquidity Pools

Liquidation Risks

Risk:

Your position is at risk of liquidation if the market value of your collateral falls, causing your Safety Buffer to deplete entirely (Debt Ratio equals the Collateral Factor).

You can use the Manage Position functionality to Top Up Position. This may be done to manage the position risk, or to borrow more FXD.

• Go to Fathom .

• Connect your Web3 wallet (such as ) and make sure your network is set to the intended chain (i.e., ).

• Opened positions are shown in "

Overview

The ProxyWallet serves as a flexible, owner-controlled wallet that can execute arbitrary transactions. It uses a ProxyActionsStorage to manage state and actions and leverages comprehensive access control via FathomAuth.

The SystemDebtEngine contract is responsible for managing the system's surplus and bad debt. It acts as the central financial manager within a FXD system, specifically designed to handle scenarios where debts become unmanageable or when excess funds are accumulated beyond what is required for the system's stability.

Storage Variables

• bookKeeper

How pegging works

When the price of FXD on some market (DEX or CEX) is less than $1, the arbitrageurs are looking for an incentive to arbitrage it with the market, which has a price closer to or more than $1. The below images show how the FXD price is pegged from time 0 to time 2.

When the market price of FXD is greater than $1, it provides an incentive to sell FXD in the market. The below images show how the FXD price is pegged from time 0 to time 2.

StableSwapModule (SSM) is the special mechanism developed by the Fathom team to provide an additional incentive for arbitrageurs.

Understanding Fathom Lending

Fathom Lending allows users to lend and borrow cryptocurrencies. By providing liquidity to the protocol, lenders earn interest on their deposits, while borrowers can access these funds by providing collateral. The platform operates without intermediaries, leveraging smart contracts to automate and secure transactions.

Key Terminologies

• Lender: A user who deposits assets into the Fathom Lending platform to earn interest.

• Dynamic Investment Strategies: Engage in multiple investment strategies spanning decentralized finance, real-world assets, and trade finance. These strategies are designed to cater to different risk appetites and investment goals.

• Stablecoin Integration: Utilize the FXD stablecoin within the platform, the stable asset, to gain yields in on-chain native way.

• Decentralized Governance: Fathom Vaults operates under a community-driven Fathom governance model, allowing FXD holders to vote on key decisions, including strategy approvals and fee adjustments.

To make the proposal in Governance, follow the steps below:

• Go to Fathom .

• Connect your Web3 wallet (such as ) and make sure your network is set to the intended chain (i.e., ).

• Click "Create a proposal

Fathom Vaults have Protocol Fees, and Performance Fees. These fees are taken each time a vault or strategy reports gains, effectively ensuring that the ecosystem is sustainable and that the developers, as well as the infrastructure maintainers, are compensated for their contributions.

Control and Customization

The Fathom governance model empowers vault and strategy managers with autonomy over the fee mechanisms. They can determine the extent of fees charged, which provides an incentive structure aligned with the success of their strategies. At the same time, it offers rewards to the Fathom platform for providing the foundational infrastructure utilized by these financial instruments.

Governance and Fee Settings

The protocol fees are governed and adjustable through Fathom Governance, with the possible range set from 0% to 50%. This wide range allows for significant flexibility in adjusting to market conditions and strategy performance. Additionally, Fathom Governance possesses the capability to specify custom fee settings for individual vaults and strategies, enabling a tailored approach to fee imposition based on specific needs and circumstances.

Fee Distribution Example

To illustrate, consider a scenario where a strategy yields a profit of 100 FXD:

Fathom Vaults are designed to streamline and enhance the experience for both users (investors), vault and strategy managers. Here's an overview of the typical workflows for each type of participant:

User (Investor) Workflow

1. Account Setup: Users begin by connecting their wallet to the Fathom interface. This setup involves ensuring that they hold FXD, the native stablecoin of the Fathom ecosystem, which is used for transactions within the vaults.

2. Vault Selection: Users navigate through the available vaults, each tailored to different risk preferences and investment strategies. The vaults are transparently described regarding their strategies, historical performance, and risk levels.

To deposit and then withdraw your FXD in the Vault, follow the steps below:

• Go to Fathom .

• Connect your Web3 wallet (such as ) and make sure your network is set to the intended chain (i.e., ).

• Check your desired Vault by clicking the arrow icon at the right.

For a position to be considered safe, below should hold true.

where

When RawPrice is the price of collateral from PriceFeed and LTV is Loan To Ratio.

In other words

And debtAccumulatedRate is calculated as

since debtAccumulatedRate is a second pounding interestRate.

The RewardsCalculator contract, a component of the Fathom DAO Staking, is designed to handle and calculate rewards distribution for staking activities. It leverages a detailed schedule system to determine rewards over different time frames, ensuring flexibility and accuracy in reward calculations. It also includes functionality to handle errors related to inputs and state conditions rigorously, thus maintaining the integrity and robustness of the rewards distribution mechanism.

Storage Variables

Fathom DEX relies on a robust and secure smart contract architecture to facilitate its decentralized exchange functionalities.

These smart contracts are the . They are battle-tested on various networks and are considered safe.

Overview of Smart Contract Architecture

The CentralizedOraclePriceFeed contract utilizes a centralized oracle source to fetch the latest prices of assets. It introduces a delay in price updates to mitigate the risks associated with price manipulation and flash loan attacks. The delayed price update ensures that fetched prices do not immediately affect the system, providing a buffer to detect and react to potential price anomalies.

CentralizedOraclePriceFeed is named centralized because it utilizes Oracle data that can be fetched from off-chain centralized sources (like Chainlink, Supra, and other oracles), not from pure onchain (DEX) data. Oracles themselves can be decentralized, and CentralizedOraclePriceFeed isn't responsible for the quality of the data.

You can use the Manage Position functionality to Repay and Close Position. This may be done to manage the position risk.

• Go to Fathom .

• Connect your Web3 wallet (such as ) and make sure your network is set to the intended chain (i.e., ).

• Opened positions are shown in "

The FmToken is an interest-bearing token used within the Fathom protocol. It represents the user's stake in the underlying assets supplied to the protocol. This document provides details on the storage, functions, and events related to the FmToken contract.

Functions

Addresses on XDC mainnet

• FTHMToken: 0x3279dBEfABF3C6ac29d7ff24A6c46645f3F4403c

• vFTHM: 0xB27c3FD774B1a1FbBc17b9E2b62846499Db08A05

Governance Token (FTHM)

The FTHM token serves as the primary utility token within the Fathom DAO. It is used for both governance and staking purposes, enabling holders to participate actively in the protocol's decisions. The distribution of FTHM tokens is aligned with the protocol's goal to encourage long-term engagement and participation.

Vault

Specialized smart contract on the blockchain that manages pooled user funds. Each vault can be connected to various investment strategies, automated by the corresponding strategy contracts. Vaults are compliant to ERC-4626.

Strategy

A strategy within Fathom Vaults is a self-contained smart contract designed to maximize returns from assets held within a vault. Strategy allows seamlessly manage the vault's assets by deploying them into optimized yield-generating opportunities.

Tokenized Strategy

In the Fathom Vaults ecosystem, a Tokenized Strategy is a specialized form of a strategy that doubles as an independent vault. Compliant with the ERC-4626 standard, this setup not only facilitates yield generation but also allows users to directly invest in the strategy. Upon investment, individuals receive shares that represent their stake, enabling a straightforward way to participate in specific investment strategies without intermediaries.

Factory

The Vaults Factory is a core component deployed to streamline the creation of Allocator Vaults under Fathom Governance. This factory ensures that new vaults are deployed in a standardized, efficient, and secure manner, adhering to the latest protocols and specifications set forth by the governance. This setup promotes trust and consistency across all deployments, significantly simplifying the process of launching new investment vehicles on the platform.

Debt

Funds sent from a vault to a strategy intended to generate returns.

Report

A function where a vault accounts for the performance of its strategies, applying any relevant fees, and managing profit distribution.

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.

Liquidity Pools

Liquidity pools are at the heart of Fathom DEX, enabling users to provide liquidity and facilitate token swaps. A liquidity pool is a smart contract that holds pairs of tokens. Users can contribute to these pools by depositing equal values of two tokens, earning a share of the trading fees generated by the pool.

Key Points:

• Liquidity Providers: Users who add tokens to a liquidity pool are known as liquidity providers (LPs). In return for their contribution, they receive LP tokens, which represent their share of the pool.

• Earning Fees: LPs earn fees from trades that occur in their pool. These fees are proportional to their share of the total pool liquidity.

• Impermanent Loss: LPs should be aware of impermanent loss, a temporary loss in value that can occur when the price of deposited tokens changes relative to each other.

Token Swaps

Token swaps are the primary function of Fathom DEX, allowing users to exchange one token for another directly from their wallets. The platform uses an Automated Market Maker (AMM) model to facilitate these swaps without the need for an order book.

Key Points:

• Automated Market Maker: The AMM algorithm uses a constant product formula (x * y = k) to determine the price of tokens in a pool. This ensures continuous liquidity and efficient price discovery.

• Slippage: Swaps may incur slippage, which is the difference between the expected price of a trade and the actual price. Slippage occurs due to changes in the pool’s token ratio during the swap.

• Transaction Fees: Each swap incurs a small transaction fee, which is distributed to the liquidity providers of the respective pool.

Fees and Rewards

Fathom DEX operates on a fee structure designed to incentivize liquidity provision and ensure a sustainable ecosystem.

Key Points:

• Trading Fees: A percentage of each trade executed on the platform is collected as a fee. This fee is distributed among the liquidity providers of the pool where the trade occurred.

• LP Rewards: In addition to trading fees, liquidity providers may earn rewards in the form of native tokens or other incentives, depending on the platform’s reward programs.

• Staking and Farming Rewards: Users can participate in staking and yield farming programs to earn additional rewards. These programs encourage long-term participation and enhance overall liquidity.

The LiquidationEngine contract manages all liquidations within the protocol, providing interfaces for liquidators to initiate the liquidation process for positions that are under-collateralized.

Functions

• liquidate(bytes32 _collateralPoolId, address _positionAddress, uint256 _debtShareToBeLiquidated, uint256 _maxDebtShareToBeLiquidated, address _collateralRecipient, bytes calldata _data): Allows a whitelisted liquidator to initiate the liquidation of a position. It requires the ID of the collateral pool, the address of the position, the amount of debt to be liquidated, a maximum allowable debt amount for liquidation to manage slippage, the recipient of the collateral, and additional data for the liquidation process.

• batchLiquidate(bytes32[] calldata _collateralPoolIds, address[] calldata _positionAddresses, uint256[] calldata _debtShareToBeLiquidateds, uint256[] calldata _maxDebtShareToBeLiquidateds, address[] calldata _collateralRecipients, bytes[] calldata datas): Facilitates the batch liquidation of multiple positions in a single transaction. This method enhances efficiency in handling liquidations at scale.

Events

• LiquidationFail(bytes32 _collateralPoolId, address _positionAddress, address _liquidator, string reason): Emitted when a liquidation attempt fails. It provides details about the failed operation, including the collateral pool ID, position address, liquidator, and reason for failure.

The FlashMintModule contract facilitates the issuance of flash loans within the protocol. This contract allows borrowing a specified amount of stablecoins, executing arbitrary operations, and repaying the loan within a single transaction. It adheres to the ERC-3156 standard for flash loans.

Storage Variables

• bookKeeper (IBookKeeper):

  • This variable stores the address of the BookKeeper contract, which is used for managing accounting and collateral within the system. It interacts with the bookkeeping functionalities to record transactions related to flash loans.

• stablecoinAdapter (IStablecoinAdapter):

  • This variable holds the address of the StablecoinAdapter contract. The adapter is used to interact with the stablecoin in a manner consistent with the internal accounting system, such as depositing or withdrawing stablecoin for flash loans.

• stablecoin (IStablecoin):

  • This variable represents the ERC20 stablecoin used for flash loans. It facilitates operations such as minting, transferring, and burning the stablecoin.

• systemDebtEngine (address):

  • A crucial contract address for managing the system’s overall debt and fee accrual. It is used primarily to settle fees or bad debt that accrues through flash loan operations.

• max (uint256):

  • This variable sets the maximum amount of stablecoin that can be borrowed through a single flash loan. It is important for managing liquidity and risk.

• feeRate (uint256):

  • The fee rate charged for taking out a flash loan. It is expressed as a percentage and calculated over the amount of the loan to generate revenue from flash loan operations.

• locked (uint256):

  • A reentrancy guard used to prevent reentry into critical functions such as flash loan issuance. This helps protect against certain types of exploits where recursive calls can lead to unintended consequences.

• flashMintWhitelist (mapping(address => bool)):

  • A whitelist of addresses that are permitted to initiate flash loans. This control mechanism ensures that only approved contracts or addresses can utilize flash loan functionality, which can be essential for maintaining system security.

• isDecentralizedState (bool):

  • Indicates whether the contract is operating in a decentralized mode. In a decentralized state, the contract might allow a broader set of interactions than when it is in a more controlled state.

Flash Loan Functions

• flashLoan(IERC3156FlashBorrower _receiver, address _token, uint256 _amount, bytes calldata _data): Executes a flash loan. The _receiver must implement the IERC3156FlashBorrower interface. This function checks the token type, enforces the maximum loan amount, calculates the fee, mints the required stablecoin, sends it to the receiver, and expects repayment within the same transaction.

• bookKeeperFlashLoan(IBookKeeperFlashBorrower _receiver, uint256 _amount, bytes calldata _data): Similar to flashLoan but interacts with receivers that handle bookkeeping entries directly. It is meant for more integrated system operations, managing loans in terms of the bookkeeping system's RAD units.

Administrative Functions

• setMax(uint256 _data) and setFeeRate(uint256 _data): Set the maximum loanable amount and the fee rate for loans. The maximum is set in stablecoin units, and the fee rate is a percentage that applies to the borrowed amount.

• setDecentralizedStatesStatus(bool _status): Toggle the operational mode between a more decentralized setting (where whitelist control might be relaxed) and a more controlled setting.

Utility Functions

• convert() and accrue(): Handle internal conversions and accounting adjustments. convert() can be used to convert balance discrepancies into the bookkeeping system, while accrue() moves accrued fees to the system debt engine.

• refreshApproval(): Refresh the approval of the stablecoin to the maximum value for the stablecoin adapter, ensuring that the contract can always interact with the stablecoin as expected.

Events

• LogSetMax(uint256 _data), LogSetFeeRate(uint256 _data), and LogFlashLoan(address indexed _receiver, address indexed _token, uint256 _amount, uint256 _fee): Log significant actions and state changes within the contract, providing transparency over flash loan parameters and administrative adjustments.

• LogDecentralizedStateStatus(bool _oldDecentralizedStateStatus, bool _newDecentralizedStateStatus): Tracks changes in the operational mode of the contract, signaling shifts between centralized and decentralized control.

The UniswapV2Factory contract is a core component of the Fathom DEX. It is responsible for creating and managing pairs (liquidity pools) for token exchanges.

State Variables

feeTo

• Type: address

• Description: Address to which protocol fees are sent.

feeToSetter

• Type: address

• Description: Address with the permission to update the feeTo address.

getPair

• Type: mapping(address => mapping(address => address))

• Description: Mapping from two token addresses to the address of their liquidity pool.

allPairs

• Type: address[]

• Description: Array of all created pair addresses.

Set Functions

createPair

• Parameters:

  • address tokenA: The first token of the pair.

  • address tokenB: The second token of the pair.

setFeeTo

• Parameters:

  • address _feeTo: The address to set as the fee recipient.

• Description: Sets the address to which protocol fees are sent. Can only be called by the feeToSetter.

setFeeToSetter

• Parameters:

  • address _feeToSetter: The address to set as the new feeToSetter.

• Description: Sets the address that can update the fee recipient. Can only be called by the current feeToSetter.

Read Functions

allPairsLength

• Parameters: None

• Returns:

  • uint: The length of the allPairs array.

getInitHash

• Parameters: None

• Returns:

  • bytes32: The keccak256 hash of the UniswapV2Pair creation code.

• Description:

Events

PairCreated

• Parameters:

  • address indexed token0: The first token of the pair.

  • address indexed token1: The second token of the pair.

The TokenizedStrategy contract serves as a proxy-style implementation that centralizes logic, storage, and management for strategies inheriting from BaseStrategy. It facilitates the creation of ERC4626 compliant vaults by handling interactions and state transitions through delegated calls to this contract.

Contract Storage

• StrategyData: This struct consolidates all storage variables needed for a strategy, optimizing for gas efficiency by reducing the frequency of storage slot loading during function execution. Key elements include:

  • initialDomainSeparator and initialChainId: Utilized for EIP-712 compliance across different chains.

  • totalSupply, totalIdle, and totalDebt: Track the total shares issued, the idle assets, and the assets actively deployed, respectively.

Core Functionalities

• Initialization and Strategy Setup: On the deployment of a new strategy, essential parameters like asset type, strategy name, and roles are established.

• Asset Management: Functions to deploy funds (deployFunds), free funds (freeFunds), and report the strategy's performance (report) encapsulate core investment strategy operations.

• Fee Management: The contract facilitates setting and adjusting performance fees, which are calculated on the profits generated by the strategy.

Access Control Modifiers

• onlyManagement: Ensures that only the designated management address can perform certain administrative tasks.

• onlyKeepers: Restricts sensitive operations such as reporting to either the designated keeper or management addresses.

• onlyEmergencyAuthorized: Allows for emergency actions, such as strategy shutdown, to be executed by authorized emergency administrators.

Events

• Management Events: Such as UpdateManagement, signal changes in management roles or parameters.

• Operational Events: Including Deposit and Withdraw, provide transactional transparency for assets moving in and out of the strategy.

• Performance Reporting: The Reported

Strategy Interaction Functions

• deposit/mint: For adding assets to the strategy in exchange for shares.

• withdraw/redeem: For removing assets from the strategy, optionally handling losses within specified bounds.

Configuration and Maintenance

• setPerformanceFee, setKeeper, setEmergencyAdmin: Functions to adjust operational parameters and roles to respond to evolving strategy needs or external conditions.

• shutdownStrategy: A critical function used to cease all investment activities, allowing the strategy to only handle withdrawals and necessary maintenance.

Utility and Helper Functions

• convertToShares/convertToAssets: Convert between the underlying asset and shares based on the current state of the strategy, aiding in calculations for deposits and withdrawals.

• _updateBalances: Ensures internal accounting reflects the actual state of assets within the strategy, crucial after any interaction that alters the balance of deployed or idle assets.

The ShowStopper contract manages the emergency shutdown of a system. It allows authorized users to trigger a shutdown to stop all essential financial operations, calculate and settle debts, and enable the redemption of collateral by users. The shutdown process ensures that the system can be gracefully wound down while protecting user assets.

Storage Variables

• bookKeeper: Reference to the IBookKeeper contract which handles all accounting-related operations.

• liquidationEngine: Reference to the ILiquidationEngine contract, responsible for handling the liquidation process during normal operations.

• systemDebtEngine: Reference to the ISystemDebtEngine, which manages the system's debts and surpluses.

• priceOracle: Reference to the IPriceOracle contract, providing updated asset prices.

• live: Boolean flag indicating if the system is active (1) or in shutdown mode (0).

• cagedTimestamp: Timestamp when the emergency shutdown was triggered.

• cageCoolDown: Cool-down period post-shutdown during which operations remain paused.

• debt: Total system debt recorded post-shutdown.

• cagePrice: Mapping of collateral types to their fixed prices set at the time of shutdown.

• badDebtAccumulator: Mapping tracking accumulated bad debts per collateral type.

• totalDebtShare: Mapping of total debt per collateral type.

• finalCashPrice: Final settled cash price per collateral type for redeeming stablecoins.

• stablecoinAccumulator: Tracks the total stablecoins deposited by users post-shutdown for later collateral redemption.

• redeemedStablecoinAmount: Mapping of redeemed stablecoin amounts per user per collateral type.

Functions

• cage(uint256 _cageCoolDown): Triggers the emergency shutdown and sets the cool-down period.

• cagePool(bytes32 _collateralPoolId): Locks the price of a specific collateral type at the time of shutdown.

• accumulateBadDebt(bytes32 _collateralPoolId, address _positionAddress): Calculates and accumulates bad debt for a given collateral type and position.

Events

• LogCage(uint256 _cageCoolDown): Emitted when the emergency shutdown is triggered.

• LogCageCollateralPool(bytes32 indexed collateralPoolId): Emitted when a collateral pool is locked at its cage price.

• LogAccumulateBadDebt(bytes32 indexed collateralPoolId, address indexed positionAddress, uint256 amount, uint256 debtShare): Emitted when bad debt is accumulated for a position.

Fathom Lending's contract architecture is facilitating seamless interactions between various components of the protocol. The architecture consists of several core smart contracts that handle different aspects of the lending and borrowing process. This modular approach ensures that each contract has a well-defined role, enhancing maintainability and scalability.

These smart contracts are the AAVE V3 direct fork. They are battle-tested on various networks and are considered safe.

Key Contracts and Their Roles

1. LendingPool: The central contract that manages deposits, withdrawals, borrowing, and repayments. It interacts with other contracts to execute these operations and maintain the protocol's state.

2. LendingPoolCore: Stores the protocol's internal data, such as user balances, reserve configurations, and interest rate models. It serves as the data layer for the LendingPool contract.

3. LendingPoolConfigurator: Allows authorized entities to configure the protocol's parameters, such as interest rate models, collateral factors, and reserve assets. It ensures that the protocol can be updated and optimized as needed.

4. InterestRateStrategy: Determines the interest rates for borrowing and lending based on the utilization rates of the asset pools. Multiple strategies can be implemented to accommodate different assets and market conditions.

5. CollateralManager: Manages collateral for borrowers, ensuring that loans are properly collateralized and initiating the liquidation process when necessary.

6. PriceOracle: Provides real-time price data for assets, enabling accurate calculation of collateral values and ensuring that loans remain adequately collateralized.

Contract Interactions and Data Flow

The interaction between contracts in Fathom Lending follows a well-defined flow to ensure efficiency and security. Here’s how these interactions typically occur:

1. User Interaction: Users interact with the LendingPool contract to deposit assets, borrow funds, repay loans, and withdraw assets.

2. Data Access: The LendingPool contract interacts with the LendingPoolCore contract to access and update user balances, reserve configurations, and other protocol data.

3. Interest Calculation: When users deposit or borrow assets, the LendingPool contract calls the InterestRateStrategy contract to determine the applicable interest rates based on current utilization rates.

Addresses on XDC mainnet

• VaultPackage: 0xdC988aBC044e764C7b507F89A1755f7427a1CCb2

• FactoryPackage: 0xF8E56b3578a274e4a1dF0FF9664f668F5728dCD8

• Factory: 0x0c6e3fd64D5f33eac0DCCDd887A8c7512bCDB7D6

• TokenizedStrategy: 0x21B5a34F8ae0387f247E9b01bA1B5c5B8A48971F

• Accountant: 0x427Fd46B341C5a3E1eA19BE11D36E5c526A885d4

Fathom Vaults

• Educational: 0x3C8e9896933B374E638f9a5C309535409129aaA2. Strategies:

  • Educational: 0xE2DEa7e0c272dE04e8708674dAE73ebd6E5c1455

• DeFi: 0x4dd9C4Cd9A8f24a8e4D51E07ae36d6Af4c4CB71B.

  Strategies:

Addresses on Apothem testnet

Core

• VaultPackage: 0xDBC692763f66c951EA9B0fb7f35a42E53893D709

• FactoryPackage: 0xf300303bB87370E04aD1f7E183965e34314e4283

• Factory: 0xE3E22410ea34661F2b7d5c13EDf7b0c069BD4153

Fathom Vaults

• Educational: 0xFEd8e57d02af00cAbBb9418F9C5e1928b4d14f01. Strategies:

  • Educational: 0xDF19A9B23d9292Af9e8675263C00C0e2AB980a6D

The VariableDebtToken contract is part of the Fathom lending protocol. It tracks users' borrowing positions at variable interest rates. This token is non-transferable and can only be minted or burned by the lending pool.

Storage Variables

• DEBT_TOKEN_REVISION: Version of the debt token.

• _underlyingAsset: The address of the underlying asset.

• POOL: Reference to the main Pool contract.

• _incentivesController: Incentives controller for the token.

Set Functions:

• approveDelegation: Delegates borrowing power to a user.

• delegationWithSig: Delegates borrowing power via signature.

• setIncentivesController: Sets the incentives controller.

Get Functions:

• balanceOf: Returns the debt balance of a user.

• totalSupply: Returns the total supply of the debt token.

• borrowAllowance: Returns the borrow allowance for a user.

Mint/Burn Functions:

• mint: Mints debt tokens to a user.

• burn: Burns debt tokens from a user.

Disabled ERC20 Functions

The following standard ERC20 functions are disabled as this is a non-transferable token:

• transfer

• allowance

• approve

• transferFrom

These functions revert with an OPERATION_NOT_SUPPORTED error if called.

Events

• Mint: Emitted when tokens are minted.

• Burn: Emitted when tokens are burned.

• BorrowAllowanceDelegated: Emitted when borrow allowance is delegated.

Where is a position's collateral recorded?

Each position's collateral amount and debt are recorded in the BookKeeper contract. In the BookKeeper contract, positions are the double mapping that keeps track of each position's lockedCollateral and debtShare.

mapping has the value as Position struct, and the struct's first member, lockedCollateral keeps track of the collateral.

How is a position's collateral recorded?

position.lockedCollateral represents the amount of collateral locked in a specific position. It serves as the primary reference to determine the amount of collateral a particular position holds. The value of position.lockedCollateral increases when a position is opened and decreases when it is closed. During the position opening flow, the value of variable , and later gets transferred to position.lockedCollateral.

Similarly, the position value.lockedCollateral is temporarily transferred to the CollateralToken variable during the position closing flow. Then, when the collateral gets withdrawn from CollateralTokenAdapter, the temporarily increased number on decreases as much as .

Three functions are directly involved in lockedCollateral accounting.

in BookKeeper.

in BookKeeper.

in CollateralTokenAdapter.

in CollateralTokenAdapter.

Interest Rate Models

Fathom Lending employs a dynamic interest rate model that adjusts based on the utilization rate of each asset pool. This model ensures that interest rates are fair and responsive to market conditions, balancing supply and demand for each asset. The key components of the interest rate model are:

• Base Rate: The minimum interest rate applied when utilization is low.

• Slope 1: The rate of increase in interest rates as utilization rises from 0% to the optimal utilization point.

• Optimal Utilization Rate: The target utilization level where the interest rate curve changes its slope.

• Slope 2: The rate of increase in interest rates as utilization rises above the optimal utilization point.

This tiered model incentivizes both lending and borrowing, ensuring sufficient liquidity and stable interest rates.

Collateral Management

Collateral management is a crucial aspect of the Fathom Lending protocol, ensuring that loans are secure and the system remains stable. Key components of collateral management include:

• Collateralization Ratio: The required ratio of collateral value to borrowed amount. This ratio ensures that loans are over-collateralized to protect against market volatility.

• Health Factor: A measure of the safety of a borrower's loan, calculated as the ratio of the value of the collateral to the value of the borrowed assets. A higher health factor indicates a safer loan.

• Collateral Types: Fathom Lending supports various types of collateral, each with its own collateralization ratio based on its risk profile.

Borrowers must maintain their collateral above the required ratio to avoid liquidation. The protocol continuously monitors the value of the collateral and the borrowed amount to ensure compliance.

Liquidation Process

The liquidation process in Fathom Lending ensures that the protocol remains solvent and that lenders' funds are protected. The key steps in the liquidation process are:

1. Triggering Liquidation: When a borrower's health factor falls below 1 (i.e., the value of their collateral is insufficient to cover their debt), the liquidation process is triggered.

2. Liquidation: Liquidators can liquidate the under-collateralized loans at a discount. The system incentivizes liquidators to repay the loan and sell the collateral, restoring the protocol's balance.

3. Repayment and Collateral Sale: The liquidator repays the borrower's loan and receives the collateral at a discount. This process ensures that the protocol remains solvent and that the liquidator is incentivized to participate.

Liquidations help maintain the stability and solvency of the Fathom Lending protocol, ensuring that lenders' funds are always protected.

Risk Parameters

Fathom Lending employs several risk parameters to ensure the stability and security of the protocol. These parameters are designed to manage risk and protect users from market volatility. Key risk parameters include:

• Loan-to-Value (LTV) Ratio: The maximum amount a user can borrow relative to the value of their collateral. A lower LTV ratio indicates a more conservative borrowing limit, reducing the risk of liquidation.

• Liquidation Threshold: The collateral value at which a loan becomes eligible for liquidation. This threshold is set to ensure that loans are adequately collateralized and to protect against sudden market downturns.

• Liquidation Bonus: An additional incentive for liquidators, provided as a percentage of the collateral value. This bonus ensures that liquidators are adequately rewarded for their efforts in maintaining the protocol's stability.

At the core of Fathom Vaults' architecture are the smart contracts that handle vault operations, strategy implementation, and interactions with the FXD stablecoin. Here is a simplified view of the system:

1. User Interface (UI): Web3 compatible interfaces that allow users to interact with vaults, deposit and withdraw funds, and participate in governance.

2. Smart Contracts:

   • Vault Contracts: Manage the deposits, withdrawals, and allocation of funds to various strategies.

   • Strategy Contracts: Execute specific investment protocols, manage performance, and handle rewards distribution.

   • Governance Contracts: Facilitate voting and administrative functions driven by community governance.

3. Off-Chain Data Storage: Utilizes Graph Node and Subgraphs for indexing and querying blockchain data efficiently, enhancing the responsiveness and scalability of the platform.

4. Off-Chain Services: The Reports Processor automates the report processing for vault strategies. Monitoring & Risk Management AI Agents and Monitoring Systems bring more reliability and capital efficiency to the vaults and strategies.

5. API Gateway: Offers a seamless connection between the frontend and smart contracts, facilitating data flow and transaction execution across the platform.

6. FXD Stablecoin: FXD is the backbone of the Fathom Vaults ecosystem, designed to mitigate price volatility and provide a reliable medium of exchange. Vaults allow FXD holders to invest in various on-chain and off-chain products leveraging their portfolio.

7. AI Agents: They work for users and vault managers. On the user side, they allow users to structure the vaults' portfolio. For vault managers, they offer help structuring the strategies' allocations.

The ProxyWalletRegistry manages the creation and administration of proxy wallets. This contract serves as a registry to associate owners with their respective proxy wallets and includes features to manage access and operational states.

Events

The AdminControls contract provides management capabilities for the Fathom FXD Protocol. It is designed to configure and control core components of the system, allowing administrative actions such as pausing and unpausing protocol operations, setting key contract addresses, and managing permissions.

Administrative role can be assigned to the Governance or Multisig account.

State Variables:

is proxy, and its implementation is .

The VaultPackage contract manages the operations and state related to supported tokens and their deposits within the vault. It handles the addition and removal of tokens, depositing of tokens for rewards, and managing migration of tokens to a new vault package.

State Variables:

To deposit and then withdraw your FXD in the Vault, follow the steps below:

• Go to Fathom .

• Connect your Web3 wallet (such as ) and make sure your network is set to the intended chain (i.e., ).

• Enter the amount of FTHM you would like to deposit and lock period. During lock period you can't withdraw tokens without a significant penalty, but you will be receiving more rewards and voting power.

The PoolAddressesProvider contract is the main registry of addresses that are part of or connected to the Fathom protocol, including permissioned roles. It acts as a factory of proxies and an admin of those proxies, with the right to change their implementations. The contract is owned by the Fathom Governance.

Storage Variables

To cover the most important flows: supply, borrow, repay and withdraw an asset, follow the steps below.

Supply Asset

• Go to Fathom .

To swap assets, follow the steps below.

Adding liquidity

• Go to Fathom .

• Connect your Web3 wallet (such as