Smart Contract Audit for EagleFi

Management Summary

EagleFi contacted Sayfer to perform a security audit on smart contracts associated with their platform, EagleFi, in March 2025.

This report documents the research carried out by Sayfer targeting the selected resources defined under the research scope. Particularly, this report displays the security posture review for the EagleFi smart contracts.

Over the research period of 3 weeks, we discovered 11 vulnerabilities in the contract.

Several fixes should be implemented following the report, to ensure the system’s security posture is competent.

After a review by the Sayfer team, we certify that all the security issues mentioned in this report have been addressed by the EagleFi team.

Risk Methodology

At Sayfer, we are committed to delivering the highest quality smart contract audits to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the contract and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their smart contracts.

Risk is defined as follows:

Protocol Overview

Protocol Introduction

EagleFi is a highly configurable decentralized exchange (DEX) built on the innovative Massa blockchain. As the Front Page of the Massa Ecosystem, EagleFi is committed to breaking barriers in global DeFi adoption by offering an unparalleled trading and data-driven experience.

With a focus on functionality and convenience, EagleFi provides crypto enthusiasts with a user-friendly platform that consolidates key project data to simplify their DeFi journey. It continues to deliver cutting-edge features while staying true to its mission of breaking DeFi barriers.

Security Assessment Findings

Missing Minimum Liquidity Lock Mechanism

Description

_getAddLiquidityData( ) lacks the minimum liquidity protection mechanism that other AMMs like Uniswap V2 implement.

• basicPool.ts:1506-1515

let fnalAmountA = amountA;
let fnalAmountB = amountB;
let liquidity: u256;
if (reserveA u256.Zero reserveB u256.Zero) {
Initial liquidity: liquidity = sqrt(amountA * amountB)
const product = SafeMath256.mul(amountA, amountB);
liquidity = sqrt(product)
liquidity = SafeMath256.sqrt(product);
}

Unlike Uniswap V2, which permanently locks a minimum amount of liquidity tokens
(MINIMUM_LIQUIDITY) by sending them to address(0), EagleFi allows the first
depositor to receive all of the initial LP tokens with no minimum requirement.
This creates a significant economic vulnerability where an attacker can manipulate
the pool’s exchange rate to extract value from subsequent liquidity providers:

1. The attacker adds minimal liquidity (e.g., 1 token A and 1 token B) and receives 1 LP token representing 100% ownership of the pool
2. They bypass the addLiquidity function and directly transfer a large amount of tokens (e.g., 1,000,000 of each token) to the pool contract
3. The pool now contains 1,000,001 of each token, but only 1 LP token exists in circulation
4. When legitimate users add liquidity, they receive dramatically fewer LP tokens than they should because the pool ratio is skewed.
5. The attacker can then remove their liquidity with a much higher share of the pool than their actual contribution

Mitigation

Implement a minimum liquidity lock mechanism similar to Uniswap V2. When the
first liquidity is provided, mint a small fixed amount of LP tokens (e.g., 1000) and
send them to a burn address (address(0)). This ensures a minimum liquidity
baseline that cannot be manipulated by the first depositor.

Missing K-Value Invariant Check When Swapping

Description

swap(StaticArray) currently verifies that the contract’s balance for the incoming token is sufficient by ensuring that it is not less than the sum of the previous reserve and the deposit amount. However, this measure solely confirms the adequacy of token transfer and does not assess whether the product of both token reserves—critical for maintaining pool balance—is preserved after the swap.

• basicPool.ts:461-465

// Ensure that the balance of the smart contract of tokenIn is greater
than or equal to the reserveIn + amountIn
assert(
contractInBalance SafeMath256.add(reserveIn, amountIn),
'SWAP INSUFFICIENT_IN_SEND',
);

As a result, any slight deviations caused by rounding errors or imprecise fee handling are not caught, leaving the protocol open to cumulative economic attacks that can subtly reduce the pool’s value over time. This differs from the implementation of flash loans in flashLoan(StaticArray), where K value is explicitly checked.

• basicPool.ts:931-932

// Ensure that the new pool K value is greater than or equal to the
old pool K value
assert(newPoolK poolK, 'FLASH_ERROR INVALID_POOL_K_VALUE'); 

Mitigation

Add a final invariant check at the end of the swap process to validate that the fee-adjusted product of the reserves is maintained or increased. Extensive testing under extreme conditions is advised to ensure the invariant holds in all scenarios.

Missing Decimal Normalization

Description

EagleFi does not implement explicit normalization for tokens with different decimal places throughout its pool operations. When performing critical calculations such as determining LP token shares, swap amounts, and price updates, the protocol operates directly on the raw token amounts without adjusting for decimal differences.

When tokens with significantly different decimals (e.g., USDC with 6 and WMAS with 18) are added to a pool, their relative contribution appears unbalanced. For example, 1 USDC (10 6 base units) paired with 1 WMAS (10 18 base units) would create a pool that values WMAS at a much higher price than USDC, requiring arbitrage to correct.

While token.ts properly stores decimal information during construction, this information is never utilized when tokens interact in a pool.

• token.ts:62, 84

const decimals = args.nextU8().expect('Invalid decimals');
[...]
Storage.set(DECIMALS_KEY, [decimals]);

It is also worth mentioning that a comment in basicPool.ts claims that _addLiquidity( ) normalizes decimals, which it does not actually do.

• basicPool.ts:1116

* - Normalizes the token amounts to default decimals.  

Mitigation

The protocol should implement proper decimal normalization throughout its codebase to ensure accurate economic representation:

1. During pool creation, record the decimal places of both tokens as part of the pool’s configuration.
2. Create utility functions that adjust token amounts to a common decimal base before performing calculations.
3. Modify key functions like addLiquidity( ), swap( ), getAmountOut( ), and price oracle updates to normalize token amounts before performing calculations.
4. Implement validation during pool creation to prevent pairing tokens with extreme decimal differences (e.g., more than 12 decimal places apart) which could lead to precision issues.
5. Clearly document how the protocol handles tokens with different decimal places to ensure users and integrators understand the behavior.

Single-Step Ownership Transfer

Description

transferOwnership(StaticArray<u8>) implements a single-step transfer without confirmation from the new owner.

• utils/ownership.ts:22-33

export function transferOwnership(binaryArgs: StaticArray): void {
const args = new Args(binaryArgs);
const newOwner = args.nextString().expect('Invalid new owner');
_onlyOwner();

assert(validateAddress(newOwner), 'INVALID_OWNER_ADDRESS');

// Set the new owner
_setOwner(newOwner);
}

Mitigation

Implement a two-step ownership transfer process where the new owner must accept ownership through a separate transaction, mitigating the risk of accidental transfers to invalid addresses.

Unbounded Swap Route in swapRouter.ts

Description

swapRouter’s swap(StaticArray) allows execution of multi-hop routes without a maximum limit.

• swapRouter.ts:71-93

if (swapRouteLength > 1) {
// Add support for multiple swaps
for (let i = 0; i < swapRouteLength; i ) {
const swapPath = swapPathArray[i];
[...]
}
}

Without an upper bound on swapRouteLength, excessively long routes could consume excessive gas, potentially causing reverts.

Mitigation

Implement a reasonable maximum route length (e.g., 3-4 hops) to prevent excessive gas consumption and potential out-of-gas reverts.

Restrictive Syncing Permissions

Description

syncReserves() can only be called by the registry contract’s owner.

• basicPool.ts:734

export function syncReserves(): void {
[...]
// only owner of registery contract can call this function
_onlyOwner();
[...]
}

This differs from Uniswap’s approach. While both mechanisms update oracles, EagleFi’s approach is more centralized because syncReserves() is restricted to the owner. This creates greater risk during emergencies where prices need correction but the owner is unavailable. A similar vulnerability was identified in other protocols where centralized oracle controls led to exploitable delays in price updates.

Mitigation

Consider making syncReserves() permissionless to allow anyone to synchronize the contract’s state with actual token balances, improving the system’s reliability.

Pool Construction Allows Duplicates

Description

buildPoolKey( ) constructs pool keys using token addresses and fee rates.

• utils/index.ts:21-39

export function _buildPoolKey(
tokenA: string,
tokenB: string,
inputFeeRate: u64,
wmasAddress: string,
): string {
// sort the addresses to ensure that the key of the pool is always
the same
// Ensure WMAS if exists, it is always tokenB
const sortedTokens = sortPoolTokenAddresses(tokenA, tokenB,
wmasAddress);
const sortedTokenA = sortedTokens[0];
const sortedTokenB = sortedTokens[1];
const key =
`${sortedTokenA}-${sortedTokenB}-${inputFeeRate.toString()}`;
generateEvent(`Built pool key: ${key}`);
return key;
}

This implementation allows creation of multiple pools with nearly identical fee rates (e.g., 3000 vs 3001), fragmenting liquidity and potentially confusing users, since these would represent effectively the same trading tier.

Mitigation

Implement a fee tier system with predefined values (like Uniswap V3’s 0.05%, 0.3%, 1% tiers) rather than allowing arbitrary fee values, or add governance controls to restrict fee values.

Documentation-Implementation Mismatches

Description

Case 1:

A comment in registry.ts indicates that flashLoanFee should be a value between 0 and 1.

• registry.ts:51

 Storage key containning the flash loan fee value of the pool. value is between 0 and 1 

However, the actual check is if the value is between 0 and 10%:

• registry.ts:86-89

assert(
isBetweenZeroAndTenPercent(flashLoanFeeInput),
'Fash loan fee must be between 0 and 10%',
);

Case 2:

The documentation for the constructor in basicPool.ts does not match the actual implementation. The JSDoc comment lists parameters but omits flashLoanFeeInput which is used in the function. The same applies to the init function defined in IBasicPool.ts.

Case 3:

The comments for wrapMasToWMAS(u256, address) and _wrapMasToWMAS(u256), in utils/index.ts and contracts/basicPool.ts respectively, incorrectly describe how these functions behave.

• index.ts:162-166 & basicPool.ts:1299-1303

//Ensure bAmount is equal to MAS coins transferred
assert(
u256.fromU64(transferredCoins) amountToWrap,
'INSUFFICIENT MAS COINS TRANSFERRED',
);

The comment states that the assertion ensures that the values are equal, but the code actually checks if transferredCoins is greater than or equal to amountToWrap, allowing excess tokens to be transferred without warning

Mitigation

Update either the documentation or the implementation to match the other side of the equation.

Unused Code

Description

• The NATIVE_MAS_COIN_ADDRESS is imported in basicPool.ts but never used.
• getAmountIn(u256, u256, u256) defined in lib/basicPoolmath.ts is never used.

Mitigation

Review the unused code and consider removing it if no justification for its continued presence in the codebase can be found.

Magic numbers in tokenDeployer

Description

tokenDeployer.ts uses unexplained “magic numbers” for default gas costs without clear documentation.

• tokenDeployer.ts:87

coinsToUseOnDeploy = u64(5 * 10 7); 

The value 5 * 10 ** 7 lacks context explaining how it was determined or what it represents, making future maintenance difficult.

Mitigation

Define this value as a named constant with clear documentation explaining its purpose and calculation, improving code readability and maintainability.

Typos

Description

• At swapPath.ts:11; isTranferFrom -> isTransferFrom
• At the specifed locations in basicPool.ts and registry.ts;
  containning -> containing

Mitigation

Correct the specified typos.