Fuji Finance

Introduction

Fuji Finance is an on-chain loan aggregator that dynamically routes borrow requests to the lowest-rate money-market across multiple EVM chains. By batching refinancing and bridging through partners such as Connext, Fuji lets a user post collateral on Chain A and receive stablecoin liquidity on Chain B—all inside one transaction.

Why Did They Need an Audit?

Fuji’s routers, vaults, flash-loan helpers, and cross-chain handlers collectively custody user collateral while hopping between chains and liquidity venues. A single logic error in beneficiary handling, flash-loan accounting, or cross-domain messaging could snowball into stolen collateral or bad debt. Fuji engaged Three Sigma for a focused 6-person-week review ahead of its v2 launch.

Scope of the Engagement

Results and Findings

Key Critical Issue

Beneficiary overwrite enables fund theft during flash-loan bundles

• Description: In BaseRouter.flashloan the beneficiary field is overwritten without verifying it matches the original beneficiary of the bundle. An attacker could sandwich a victim’s permitted withdrawal (see M10) with a flash-loan step that silently rewrites the beneficiary to themselves, siphoning assets on repayment.
• Resolution: Added an explicit checkBeneficiary() guard that reverts on any change; merged via Fujicracy/fuji-v2#615.

Notable High-Severity Issues

Provider rotation can strand collateral

• Description: Changing the active liquidity provider in BorrowingVault / YieldVault recalculates totalAssets() and totalDebt() only on the new set. Assets or debt left on the old provider disappear from accounting, letting attackers exploit skewed share prices.
• Resolution: Removal of a provider now requires zero debt and forces an atomic asset migration when balances are non-zero.

Rebalancer fee loop drains vault

• Description: REBALANCER_ROLE could iteratively ping-pong debt between providers, stacking a 0.1 % fee each hop and draining the vault at bounded gas cost.
• Resolution: Role restricted to a timelocked RebalancerManager; future refactor will add non-reentrancy and hard per-block fee caps.

Re-entrancy in cross-chain failure handler

• Description: ConnextHandler.executeFailedWithUpdatedArgs() allowed the privileged allowedCaller to call the function again inside the same TX and sweep all tokens.
• Resolution: State now flipped to executed = true before the external call; non-reentrant modifier added (#621).

In conclusion

Three Sigma’s 6-week assessment of Fuji Finance covered routers, vaults, flashers, swappers, and Connext integration logic. The review surfaced two critical beneficiary- and accounting-level flaws, seven high-impact privilege and economic issues, and a series of medium logic and gas optimizations. All critical items and most high/medium findings are now patched in fuji-v2, with remaining acknowledgements scheduled across Q3–Q4 2023 refactors. Fuji launches v2 with tightened beneficiary checks, safer provider migration, and hardened cross-chain recovery paths—fortifying its promise of frictionless, lowest-rate lending across chains.