Formal Verification Audit | Fathom | Halborn Audit Reports

Summary

100% of all REPORTED Findings have been addressed

About this report

Assessment Type

Assurance Assessment

Date of Engagement

March 10th, 2026 - March 12th, 2026

Source Code

fathom-lending-platform-smart-contracts

Assessed Commit ID

91574f4

Severity Breakdown

0Risk Accepted
3Acknowledged
3Solved
6All Findings

Critical0
High0
Medium0
Low0
Informational6
- 3Ack.
- 3Solved

INTRODUCTION#

Fathom engaged Halborn to conduct a security assessment on their smart contracts beginning on March 10th, 2026 and ending on March 12th, 2026. The security assessment was scoped to the smart contracts provided in the Fathom-Fi/fathom-lending-platform-smart-contracts Github repository, provided to the Halborn team. Commit hash and further details can be found in the Scope section of this report.

The review is an equivalence attestation assessing whether Fathom smart contracts are functionally identical to Aave v3.0.2 reference implementation, except for documented and intentional deviations. Additionally, the assessment covers whether the deployed on-chain bytecode matches the audited source, and whether known Aave v3.0.2 limitations apply to the Fathom deployment.

ASSESSMENT SUMMARY#

Halborn was provided with 3 days for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possess deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.

The objective of this assessment is to:

Confirm that Fathom's smart contracts are equivalent to Aave v3.0.2 reference implementation, except for documented deviations.
Assess the security implications of all identified deviations from Aave v3.0.2.
Verify that deployed on-chain bytecode matches the audited source code.

Fathom is substantially equivalent to Aave v3.0.2 with a small set of intentional, low-risk deviations. Two known Aave v3.0.2 limitations were assessed for applicability. Bytecode verification was performed for all deployed contracts, with several contracts found to be unverified on XDCScan and discrepancies identified between SPDX license identifiers in the XDCScan-submitted source and the audited repository.

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were partially addressed by the Fathom team. The main ones were the following:

Restrict future reserve listings to low-risk decimal/price combinations and monitor Aave v3.5 for the upstream rounding vulnerability fix.
Document or remediate the behavior of the inherited eMode liquidation limitation.
Document or remediate the supported asset decimal ranges to prevent future misconfigurations that could expose the protocol to share inflation attacks.
Submit source code for all unverified contracts to XDCScan.
Resubmit source for affected contracts with the correct SPDX license identifier matching the audited commit.
Confirm XDC feed provider heartbeat guarantees and implement off-chain monitoring for oracle staleness equivalent to Aave's approach.

CAVEATS#

This assessment is scoped exclusively to the equivalence between Fathom smart contracts at commit 91574f41 and Aave v3.0.2 reference implementation. It is not a full-scope security audit of the Fathom codebase. All protocol components that are identical to Aave v3.0.2 are treated as inheriting the security properties of that reference implementation, and are not re-audited as part of this engagement.

The equivalence assessment covers: identified deviations between Fathom and Aave v3.0.2, the security implications of those deviations and deployed bytecode verification. Interactions between unchanged components, broader business logic, and off-chain systems are outside the scope of this assessment.

TEST APPROACH AND METHODOLOGY#

Halborn performed a combination of manual diff analysis, code review, and bytecode verification to assess the equivalence of Fathom against Aave v3.0.2 reference implementation.

The following phases were undertaken throughout the assessment:

Research into Aave v3.0.2 architecture and Fathom 's intended deviations from it.
Automated diff analysis between Fathom repository and Aave v3.0.2 reference codebase to systematically identify all deviations across in-scope contracts.
Manual code review of all identified deviations to assess functional equivalence and security implications.
Bytecode verification of all deployed contracts against on-chain records via XDCScan.

The following contracts were verified on XDC Mainnet as part of the bytecode verification phase. Contracts marked as "Exact Match" were confirmed via XDCScan source verification. Contracts marked as "Unverified" were not source-verified on XDCScan and were instead verified by Halborn via local compilation and bytecode comparison against the audited source at commit 91574f41, with observed differences limited to expected deployment-time artifacts. Note that for several contracts, the SPDX license identifier in the XDCScan-submitted source differs from the audited repository, see findings for details.

Pool-Proxy: 0x70d8005E3c8C7e383FE35Fa40156042F3393449F, Exact Match.

Pool-Implementation: 0x5c756ACD4Cb26a9cA6De7abF9765cE84B5Be9322, Exact Match*.

PoolConfigurator-Proxy: 0x56f3A75C71C207a77c3b8c77a34FC89cF1a6DB66, Exact Match.

PoolConfigurator-Implementation: 0xE6525d46ADc3Cd5AF2CfA322504A7C17F8445c8D, Unverified.

PoolAddressesProvider: 0x37ab83e6a9B99DA3eAF00D1afdC45f50ee7625E5, Exact Match*.

ProtocolDataProvider: 0x7fa488a5C88E9E35B0B86127Ec76B0c1F0933191, Exact Match*.

FathomOracle: 0x54348d953Abc4f167cbdeDe648095c1aF7DE355A, Exact Match*.

ACLManager: 0xf73e7d6309A2DaDE5B698eD33dA929d2F2281526, Exact Match*.

SupplyLogic: 0xA8f477530036cF1391E5A76A723635be7b28Eff3, Exact Match*.

BorrowLogic: 0x602d170366C4c14c855BAa051A35Ee318564343A, Exact Match*.

LiquidationLogic: 0xdf816BB3a1415B4b88365D6Ecb5Fcc52A7ee7729, Exact Match*.

EModeLogic: 0x1240f345449Ee3293FEAE9E3e3FbcCe1589e9160, Unverified.

FlashLoanLogic: 0x57023484830D90027E33e37Abc301A89e1318B30, Unverified.

BridgeLogic: 0x00C1B7ce7703beD7e115833a6c2DbcFeD887a4f1, Unverified.

ConfiguratorLogic: 0x373E40f30e7a2CcFfe22fA1926bD71284332a2B9, Unverified.

PoolLogic: 0x8c2cf73fB553d9a8a8Dc34A6B5e6078FC023c34F, Unverified.

FmToken: 0x5271D2bC5F2deCbF7124DA2349cc88E6Aa039364, Unverified.

StableDebtToken: 0x80e2eA68DB630660eFCa18780F24587967F3071B, Unverified.

VariableDebtToken: 0xfaA128B457FC7cBF9763A7Be66bF89662d9777FF, Unverified.

PoolAddressesProviderRegistry: 0xDAb3B99eb3569466750c436d6F4c99d57850Cc89, Unverified.

DelegationAwareFmToken: 0x479025c4a038E4028cED41178DC737377Df55278, Unverified.

ReservesSetupHelper: 0xF3A4c44D7aEF5e0648DAFd1448dFAe9933aF8F4d, Unverified.
EmissionManager: 0x049F146A33a16e454f3BE28bb0bc18c12C96a894, Unverified.

WrappedTokenGatewayV3: 0x57Ba8bAA7c3Ff6606751859f1CED9f68819C2f41, Exact Match.

WalletBalanceProvider: 0x7C724DEaD5012Eb4C9e2d1529cF0353e767C82Cd, Exact Match.

UiIncentiveDataProviderV3: 0xA69c5468Aa4ab263a250fD9dA4322e58370F2bB2, Unverified.

UiPoolDataProviderV3: 0x5f7001B6Dc957dC5B2F78f0BC3aFbFc1fE628A18, Exact Match.

*Exact Match on XDCScan but SPDX license identifier in submitted source differs from audited repository.

Risk Methodology#

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

5.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A)	1
Attack Origin (AO)	Specific (AO:S)	0.2
Attack Cost (AC)	Low (AC:L)	1
	Medium (AC:M)	0.67
	High (AC:H)	0.33
Attack Complexity (AX)	Low (AX:L)	1
	Medium (AX:M)	0.67
	High (AX:H)	0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

5.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N)	0
	Low (C:L)	0.25
	Medium (C:M)	0.5
	High (C:H)	0.75
	Critical (C:C)	1
Integrity (I)	None (I:N)	0
	Low (I:L)	0.25
	Medium (I:M)	0.5
	High (I:H)	0.75
	Critical (I:C)	1
Availability (A)	None (A:N)	0
	Low (A:L)	0.25
	Medium (A:M)	0.5
	High (A:H)	0.75
	Critical (A:C)	1
Deposit (D)	None (D:N)	0
	Low (D:L)	0.25
	Medium (D:M)	0.5
	High (D:H)	0.75
	Critical (D:C)	1
Yield (Y)	None (Y:N)	0
	Low (Y:L)	0.25
	Medium (Y:M)	0.5
	High (Y:H)	0.75
	Critical (Y:C)	1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

5.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N)	1
	Partial (R:P)	0.5
	Full (R:F)	0.25
Scope ( $s$ )	Changed (S:C)	1.25
Scope ( $s$ )	Unchanged (S:U)	1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Critical	High	Medium	Low	Informational
9 - 10	7 - 8.9	4.5 - 6.9	2 - 4.4	0 - 1.9

Scope#

(a) Repository:fathom-lending-platform-smart-contracts

(b) Assessed Commit ID:91574f41435cbfdfdb9357e7d774165ab4c622c5

138 files

contracts

138 files

dependencies

26 files

fathomoracle

1 file

AggregatorInterface.sol

solidity

gnosis / contracts

1 file

GPv2SafeERC20.sol

solidity

openzeppelin

23 files

contracts

14 files

AccessControl.sol

solidity

Address.sol

solidity

Context.sol

solidity

ERC165.sol

solidity

contracts138 files

dependencies26 files

fathomoracle1 file

AggregatorInterface.solsolidity

gnosis1 file

contracts1 file

GPv2SafeERC20.solsolidity

openzeppelin23 files

contracts14 files

AccessControl.solsolidity

Address.solsolidity

Context.solsolidity

ERC165.solsolidity

ERC20.solsolidity

IAccessControl.solsolidity

IERC165.solsolidity

IERC20.solsolidity

IERC20Detailed.solsolidity

Ownable.solsolidity

SafeCast.solsolidity

SafeERC20.solsolidity

SafeMath.solsolidity

Strings.solsolidity

upgradeability8 files

AdminUpgradeabilityProxy.solsolidity

BaseAdminUpgradeabilityProxy.solsolidity

BaseUpgradeabilityProxy.solsolidity

Initializable.solsolidity

InitializableAdminUpgradeabilityProxy.solsolidity

InitializableUpgradeabilityProxy.solsolidity

Proxy.solsolidity

UpgradeabilityProxy.solsolidity

ReentrancyGuard.solsolidity

weth1 file

WXDC9.solsolidity

deployments1 file

ReservesSetupHelper.solsolidity

flashloan4 files

base2 files

FlashLoanReceiverBase.solsolidity

FlashLoanSimpleReceiverBase.solsolidity

interfaces2 files

IFlashLoanReceiver.solsolidity

IFlashLoanSimpleReceiver.solsolidity

interfaces24 files

IACLManager.solsolidity

ICreditDelegationToken.solsolidity

IDefaultInterestRateStrategy.solsolidity

IDelegationToken.solsolidity

IERC20WithPermit.solsolidity

IFathomIncentivesController.solsolidity

IFathomOracle.solsolidity

IFmToken.solsolidity

IInitializableDebtToken.solsolidity

IInitializableFmToken.solsolidity

IL2Pool.solsolidity

IPool.solsolidity

IPoolAddressesProvider.solsolidity

IPoolAddressesProviderRegistry.solsolidity

IPoolConfigurator.solsolidity

IPoolDataProvider.solsolidity

IPriceOracle.solsolidity

IPriceOracleGetter.solsolidity

IPriceOracleSentinel.solsolidity

IReserveInterestRateStrategy.solsolidity

IScaledBalanceToken.solsolidity

ISequencerOracle.solsolidity

IStableDebtToken.solsolidity

IVariableDebtToken.solsolidity

misc5 files

interfaces1 file

IWXDC.solsolidity

FathomOracle.solsolidity

L2Encoder.solsolidity

ProtocolDataProvider.solsolidity

ZeroReserveInterestRateStrategy.solsolidity

periphery35 files

libraries1 file

DataTypesHelper.solsolidity

misc10 files

interfaces6 files

IEACAggregatorProxy.solsolidity

IERC20DetailedBytes.solsolidity

IUiIncentiveDataProviderV3.solsolidity

IUiPoolDataProviderV3.solsolidity

IWrappedTokenGatewayV3.solsolidity

IWXDC.solsolidity

UiIncentiveDataProviderV3.solsolidity

UiPoolDataProviderV3.solsolidity

WalletBalanceProvider.solsolidity

WrappedTokenGatewayV3.solsolidity

rewards14 files

interfaces7 files

IEmissionManager.solsolidity

IPullRewardsTransferStrategy.solsolidity

IRewardsController.solsolidity

IRewardsDistributor.solsolidity

IStakedToken.solsolidity

IStakedTokenTransferStrategy.solsolidity

ITransferStrategyBase.solsolidity

libraries1 file

RewardsDataTypes.solsolidity

transfer-strategies3 files

PullRewardsTransferStrategy.solsolidity

StakedTokenTransferStrategy.solsolidity

TransferStrategyBase.solsolidity

EmissionManager.solsolidity

RewardsController.solsolidity

RewardsDistributor.solsolidity

treasury10 files

interfaces4 files

IAdminControlledEcosystemReserve.solsolidity

ICollector.solsolidity

IEcosystemReserveController.solsolidity

IStreamable.solsolidity

libs1 file

VersionedInitializable.solsolidity

AdminControlledEcosystemReserve.solsolidity

Collector.solsolidity

CollectorController.solsolidity

EcosystemReserveController.solsolidity

EcosystemReserveV2.solsolidity

protocol43 files

configuration4 files

ACLManager.solsolidity

PoolAddressesProvider.solsolidity

PoolAddressesProviderRegistry.solsolidity

PriceOracleSentinel.solsolidity

libraries25 files

configuration2 files

ReserveConfiguration.solsolidity

UserConfiguration.solsolidity

helpers2 files

Errors.solsolidity

Helpers.solsolidity

logic13 files

BorrowLogic.solsolidity

BridgeLogic.solsolidity

CalldataLogic.solsolidity

ConfiguratorLogic.solsolidity

EModeLogic.solsolidity

FlashLoanLogic.solsolidity

GenericLogic.solsolidity

IsolationModeLogic.solsolidity

LiquidationLogic.solsolidity

PoolLogic.solsolidity

ReserveLogic.solsolidity

SupplyLogic.solsolidity

ValidationLogic.solsolidity

math3 files

MathUtils.solsolidity

PercentageMath.solsolidity

WadRayMath.solsolidity

types2 files

ConfiguratorInputTypes.solsolidity

DataTypes.solsolidity

upgradeability3 files

BaseImmutableAdminUpgradeabilityProxy.solsolidity

InitializableImmutableAdminUpgradeabilityProxy.solsolidity

VersionedInitializable.solsolidity

pool5 files

DefaultReserveInterestRateStrategy.solsolidity

L2Pool.solsolidity

Pool.solsolidity

PoolConfigurator.solsolidity

PoolStorage.solsolidity

tokenization9 files

base5 files

DebtTokenBase.solsolidity

EIP712Base.solsolidity

IncentivizedERC20.solsolidity

MintableIncentivizedERC20.solsolidity

ScaledBalanceTokenBase.solsolidity

DelegationAwareFmToken.solsolidity

FmToken.solsolidity

StableDebtToken.solsolidity

VariableDebtToken.solsolidity

Out-of-Scope:Third party dependencies and economic attacks. Furthermore, this assessment was limited to the differential changes between Fathom at commit 91574f41 and Aave V3.0.2 . Components outside of the reviewed diff, pre-existing logic not modified by the changes, system-wide interactions not directly surfaced in the diff context, and external assumptions regarding input validation, business rules, and access controls were explicitly out of scope.

507226544dff65ef9e562428b0f7a0908937106ehttps://xdcscan.com/dccbb1f0285eb4a58ec65b5f31e79282a7ddbdc6

Out-of-Scope: New features/implementations after the remediation commit IDs.

Assessment Summary & Findings Overview#

#	Title	Severity	Score	Status
HAL-01	Rounding vulnerability in supply/withdraw cycles allows extraction of underlying tokens from low-decimal high-value reserves	Informational	1.0	Acknowledged03/14/2026
HAL-02	Inherited eMode liquidation uses wrong debt price source when debt asset is removed from eMode category	Informational	0.0	Acknowledged03/14/2026
HAL-03	Absence of documentation on supported asset decimal ranges	Informational	0.0	Solved03/14/2026
HAL-04	Several contracts are not source-verified on XDCScan	Informational	0.0	Solved03/22/2026
HAL-05	SPDX license identifier mismatch between deployed and audited source	Informational	0.0	Solved03/14/2026
HAL-06	Oracle staleness protection relies on feed provider guarantees and Off-Chain monitoring	Informational	0.0	Acknowledged03/14/2026

Findings & Tech Details#

HAL-01Acknowledged

Rounding vulnerability in supply/withdraw cycles allows extraction of underlying tokens from low-decimal high-value reserves

Informational

1.0AO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:M/Y:NAO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:M/Y:N

Description

Recommendation

Remediation Comment

HAL-02Acknowledged

Inherited eMode liquidation uses wrong debt price source when debt asset is removed from eMode category

Informational

0.0AO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:NAO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:N

Description

Recommendation

Remediation Comment

HAL-03Solved

Absence of documentation on supported asset decimal ranges

Informational

0.0AO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:NAO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

507226544dff65ef9e562428b0f7a0908937106e

HAL-04Solved

Several contracts are not source-verified on XDCScan

Informational

0.0AO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:NAO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

https://xdcscan.com/

HAL-05Solved

SPDX license identifier mismatch between deployed and audited source

Informational

0.0AO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:NAO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

dccbb1f0285eb4a58ec65b5f31e79282a7ddbdc6

HAL-06Acknowledged

Oracle staleness protection relies on feed provider guarantees and Off-Chain monitoring

Informational

0.0AO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:NAO:S/AC:L/AX:L/R:N/S:U/C:N/A:N/I:N/D:N/Y:N

Description

Recommendation

Remediation Comment

Disclaimer#

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.