Fluton Confidential DeFi Security Review

Description

Location • Contract: Diamond • File: contracts/confidentiality-adapters/aave/Diamond.sol – onUnwrap(), L68-L82 • File: contracts/confidentiality-adapters/aave/libraries/LibAdapterStorage.sol – RequestType enum, L12-L17

Root Cause The RequestType enum defines SUPPLY = 0 as its first member: // LibAdapterStorage .sol -- L12 -L17 enum RequestType { SUPPLY , // = 0 WITHDRAW , // = 1 BORROW , // = 2 REPAY // = 3 } In onUnwrap(), the backward loop reads requestIdToRequestData[i].requestType and compares it against SUPPLY or REPAY: Vulnerable Code // Diamond.sol -- L73 -L78 for (uint256 i = requestId - 1; i > 0; i--) { LibAdapterStorage .RequestType rt = s. requestIdToRequestData [i]. requestType; if (rt == LibAdapterStorage .RequestType.SUPPLY || rt == LibAdapterStorage . RequestType.REPAY) { s. requestIdToUnwrapRequestId [i] = requestId; break; } } In Solidity, reading a mapping key that has never been written returns the default value for the type. For a struct containing a RequestType enum, the default is 0, which is RequestType.SUPPLY. Therefore, any requestIdToRequestData[i] where i was never assigned – including IDs for deleted requests and IDs that never corresponded to any request – will return RequestType.SUPPLY and satisfy the condition.

Impact

The loop will almost always match the very first requestId - 1 entry that it reads, regardless of whether a real SUPPLY or REPAY request ever existed at that ID. This links the unwrap amount to the wrong request ID. Finalization of the actual SUPPLY/REPAY request will then either read a stale or incorrect unwrap amount, or find no linked unwrap at all, causing an AmountIsZero revert.

Recommendation

Add a NONE = 0 sentinel value as the first enum member so that uninitialized storage does not collide with valid request types: enum RequestType { NONE , // = 0, sentinel for uninitialized SUPPLY , // = 1 WITHDRAW , // = 2 BORROW , // = 3 REPAY // = 4 } Update the onUnwrap check to exclude NONE.

Description

The Diamond’s supply finalization converts user deposits from cToken units into Aave-scaled units using a multiplier derived from the Aave liquidity index. The resulting scaledBalance is stored as the user’s position. However, the withdrawal path converts scaledBalance back to an ERC20 amount using only a decimal difference adjustment, never reversing the Aave liquidity index scaling. This causes the withdrawal amount passed to aavePool.withdraw() to be denominated in Aave-scaled units rather than underlying units – resulting in the user receiving less than they deposited. On any Aave market where the liquidity index exceeds 1.0 (which is every active market on mainnet), every depositor through the Diamond suffers immediate, permanent principal loss proportional to 1 - (1 / liquidityIndex). At mainnet USDC’s current liquidity index of ~1.06, this equates to a 5.66% loss per deposit. Vulnerability Detail Supply Path: Deposits Are Scaled Down In LibSupplyRequest.finalizeSupplyRequests (contracts/confidentialityadapters/aave/libraries/LibSupplyRequest.sol#L141-L148), the Diamond supplies the decrypted batch total to Aave and computes a multiplier from the Aave scaled balance delta: uint256 beforeScaledBalance = IScaledBalanceToken (aToken).scaledBalanceOf (address( this)); s.aavePool.supply(asset , amount , address(this), requests [0]. referralCode); uint256 afterScaledBalance = IScaledBalanceToken (aToken).scaledBalanceOf (address(this )); uint256 difference = afterScaledBalance - beforeScaledBalance ; uint256 multiplier = difference / (amount / (10 ** 6)); // <- incorporates liquidityIndex In Aave V3, scaledBalanceOf returns balance / liquidityIndex. So when liquidityIndex > 1.0, the difference is smaller than amount, producing a multiplier < 10^6. Each user’s scaledBalance is then updated in _processStateUpdates

(contracts/confidentiality-adapters/aave/libraries/LibSupplyRequest.sol#L172- L176): euint64 newBalance = TFHE.add( s.scaledBalances[sender ][ asset], TFHE.div(TFHE.mul(amount , uint64(multiplier)), 1e6) // <- produces value LESS than deposit ); Example at liquidityIndex = 1.05: • User deposits 1000 USDC (= 109 in 6-decimal) • Aave scaled delta = 109 / 1.05 = 952,380,952 • multiplier = 952,380,952 / (109 / 106) = 952,380 • scaledBalance = 109 x 952,380 / 106 = 952,380,000 The user deposited 109 but their scaledBalance records only 952,380,000 – a 4.76% reduction. Withdraw Path: Scaling Is Never Reversed In LibWithdrawRequest.callbackWithdrawRequest (contracts/confidentialityadapters/aave/libraries/LibWithdrawRequest.sol#L119-L122), the decrypted withdrawal amount (which is capped by the user’s scaledBalance) is converted to an ERC20 amount using only the decimal difference: uint256 amountToWithdraw = amount * (10 ** (IERC20Metadata(asset).decimals () - cToken .decimals ())); s.aavePool.withdraw(asset , amountToWithdraw , address(this)); For USDC (6/6 decimals), decimals_diff = 0, so amountToWithdraw = amount – the raw scaledBalance value is passed directly to Aave’s withdraw(). Aave’s pool.withdraw(asset, amount, to) interprets the amount parameter as an underlying token amount (not a scaled amount). It returns exactly amount underlying tokens and burns amount / currentLiquidityIndex scaled aTokens. Continuing the example: • User requests withdrawal of their full scaledBalance = 952,380,000 • amountToWithdraw = 952,380,000 x 100 = 952,380,000 • aavePool.withdraw(USDC, 952,380,000, Diamond) -> returns 952.38 USDC The user deposited 1000 USDC but receives only 952.38 USDC. 47.62 USDC of principal is permanently lost. The User Cannot Withdraw Their Full Deposit

Even if the user requests their original deposit amount (109), the withdrawRequest (contracts/confidentialityadapters/aave/libraries/LibWithdrawRequest.sol#L21-L25) check prevents it: euint64 withdrawableScaledBalance = TFHE.sub(suppliedScaledBalance , debtScaledBalance ); euint64 safeAmount = TFHE.select( TFHE.le(amount , withdrawableScaledBalance ), // 10^9 <= 952 ,380 ,000? -> FALSE amount , TFHE.asEuint64 (0) // -> safeAmount = 0 ); The user’s scaledBalance (952,380,000) is less than their deposit (109), so requesting the full deposit amount results in safeAmount = 0 – the withdrawal is silently zeroed out. The Missing Conversion The correct withdrawal conversion should multiply the scaled balance by the current liquidity index to obtain the actual underlying value: actualUnderlying = scaledBalance x currentLiquidityIndex / RAY But the code only applies a decimal adjustment: amountToWithdraw = scaledBalance x 10^( decimals_diff) This means the Aave scaling applied during supply is never reversed during withdrawal. Impact Scales With Market Maturity The principal loss percentage equals 1 - (1 / liquidityIndex): | Aave Market | Approx. liquidityIndex | Principal Loss Per Deposit | | --------------------------- | ---------------------- | -------------------------- | | Fresh pool (no borrows yet) | 1.000 | 0% | | WETH (mainnet) | ~1.03 | ~2.9% | | USDT (mainnet) | ~1.05 | ~4.8% | | USDC (mainnet) | ~1.06 | **~5.7%** | | Mature market (years) | ~1.20 | **~16.7%** | | Extreme (very old market) | ~2.00 | **~50%** | The liquidity index only increases over time. Every deposit through the Diamond on any production Aave market suffers this loss.

Impact

Every user who deposits through the Diamond on any Aave market with liquidityIndex > 1.0 permanently loses a percentage of their principal. On

mainnet Aave USDC (the most common asset), this is approximately 5.66% per deposit at current market conditions. The loss is: • Immediate: Occurs at the moment of supply finalization, not over time. • Permanent: No mechanism exists to reclaim the lost principal. • Invisible: The user cannot see their encrypted scaledBalance to detect the shortfall. • Compounding: Repeat deposits compound the loss (each deposit loses another ~5.66%). Additionally, Aave yield accrual is never reflected in users’ scaledBalance values. Even the earliest depositors (who avoid principal loss because liquidityIndex ~ 1.0 at pool inception) never receive interest – yield accumulates in the Diamond’s aggregate Aave position permanently. There is no distribution, sweep, harvest, or claim function anywhere in the codebase. Code Snippet Supply multiplier calculation – incorporates liquidityIndex, shrinking scaledBalance: https://github.com/example/contracts/confidentiality-adapters/aave/libraries/LibSupplyRequest. sol#L141-L176 uint256 beforeScaledBalance = IScaledBalanceToken (aToken).scaledBalanceOf (address( this)); s.aavePool.supply(asset , amount , address(this), requests [0]. referralCode); uint256 afterScaledBalance = IScaledBalanceToken (aToken).scaledBalanceOf (address(this )); uint256 difference = afterScaledBalance - beforeScaledBalance ; uint256 multiplier = difference / (amount / (10 ** 6)); // User ’s balance update: euint64 newBalance = TFHE.add( s.scaledBalances[sender ][ asset], TFHE.div(TFHE.mul(amount , uint64(multiplier)), 1e6) // scaledBalance < depositAmount ); Withdrawal callback – only applies decimal adjustment, never reverses Aave scaling: https://github.com/example/contracts/confidentiality-adapters/aave/libraries/LibWithdrawRequest. sol#L119-L122 uint256 amountToWithdraw = amount * (10 ** ( IERC20Metadata(asset).decimals () - ConfidentialERC20Wrapped (cToken). decimals ())); s.aavePool.withdraw(asset , amountToWithdraw , address(this)); // amountToWithdraw is in Aave -scaled units , but Aave treats it as underlying -> principal loss

Recommendation

The withdrawal callback must reverse the Aave scaling by multiplying the decrypted amount by the current liquidity index before passing it to aavePool.withdraw(): function callbackWithdrawRequest (uint256 requestId , uint64 amount) internal { // ... - uint256 amountToWithdraw = amount * - (10 ** (IERC20Metadata (asset).decimals () - ConfidentialERC20Wrapped (cToken) .decimals ())); + // Reverse the Aave scaling: convert from scaled units back to underlying + uint256 liquidityIndex = s.aavePool. getReserveNormalizedIncome (asset); + uint256 scaledAsUnderlying = (uint256(amount) * liquidityIndex ) / 1e27; + uint256 amountToWithdraw = scaledAsUnderlying * + (10 ** (IERC20Metadata(asset).decimals () - ConfidentialERC20Wrapped (cToken) .decimals ())); s.aavePool.withdraw(asset , amountToWithdraw , address(this)); - IERC20(asset).approve(cToken , amount); - ConfidentialERC20Wrapped (cToken).wrap(amount); + // Wrap the actual withdrawn amount (in cToken -scale) + uint256 cTokenAmount = amountToWithdraw / + (10 ** (IERC20Metadata(asset).decimals () - ConfidentialERC20Wrapped (cToken) .decimals ())); + IERC20(asset).approve(cToken , cTokenAmount); + ConfidentialERC20Wrapped (cToken).wrap(cTokenAmount); // ... } The same fix should be applied to the borrow and repay callbacks that perform similar decimal-only conversions. For yield distribution, the protocol should implement one of: 1. Periodic rebase: A keeper function that reads aavePool.getReserveNormalizedIncome(asset) and proportionally updates all users’ scaledBalances via FHE operations. 2. Withdrawal-time yield capture: Compute the actual underlying value at withdrawal time (as shown in the fix above) so users automatically receive their share of accrued interest. 3. Admin sweep: At minimum, add an owner-only function to extract trapped yield from the Diamond’s Aave position for manual distribution. Option 2 (the fix above) is the simplest and most correct approach – it ensures each user’s withdrawal reflects the current liquidity index, naturally including any accrued yield.

Description

The borrow cap check in LibBorrowRequest.borrowRequest() validates that the requested borrow amount does not exceed maxBorrowable, which is computed as scaledBalance * ltv / 10000. This formula represents the user’s total borrowing capacity but never subtracts the user’s existing scaledDebts. As a result, maxBorrowable remains constant regardless of how much debt the user has already accumulated, allowing unlimited repeat borrowing against the same collateral. An attacker can drain the Diamond’s entire Aave borrowing capacity, stealing other users’ collateral through the pooled aggregate position. Vulnerability Detail The Borrow Cap Check When a user submits a borrow request, the only guard is at LibBorrowRequest.sol##L26-27 (contracts/confidentialityadapters/aave/libraries/LibBorrowRequest.sol#L26-L27): euint64 maxBorrowable = s. userMaxBorrowablePerAsset [msg.sender ][ asset ]; euint64 safeAmount = TFHE.select(TFHE.le(amount , maxBorrowable), amount , TFHE. asEuint64 (0)); If amount <= maxBorrowable, the full requested amount is queued. Otherwise, 0 is silently queued (the FHE select clamps it). How maxBorrowable Is Computed maxBorrowable is set by _setMaxBorrowables(), which is called after every supply, borrow, withdraw, and repay finalization. The implementation is identical across all four libraries (LibBorrowRequest.sol##L220-234 (contracts/confidentialityadapters/aave/libraries/LibBorrowRequest.sol#L220-L234)): function _setMaxBorrowables (euint64 currentBalance , address sender) internal { LibAdapterStorage .Storage storage s = LibAdapterStorage .getStorage (); address [] memory aaveAssets = s.aaveAssets; for (uint256 i = 0; i < aaveAssets.length; i++) { address asset = aaveAssets[i]; (, uint256 ltv , , , , , , , , ) = s. aaveDataProvider . getReserveConfigurationData (asset); s. userMaxBorrowablePerAsset [sender ][ asset] = TFHE.div( TFHE.mul(currentBalance , uint64(ltv)), uint64 (10000) );

} } The formula is: maxBorrowable = scaledBalance x ltv / 10000 There is no subtraction of scaledDebts[user][asset] anywhere. The function does not read, reference, or account for existing user debt. Why maxBorrowable Never Decreases After Borrowing After a borrow finalizes, the state update in _processStateUpdates (contracts/confidentiality-adapters/aave/libraries/LibBorrowRequest.sol#L191- L218) is: // L202 -206: Debt increases s.scaledDebts[user ][ asset] = TFHE.add(s.scaledDebts[user ][ asset], borrowedScaledAmount ); // L211: Read the SUPPLY balance (not modified by borrowing) euint64 scaledBalance = s. scaledBalances[user ][ asset ]; // L213: Recalculate maxBorrowable from unchanged supply balance _setMaxBorrowables (scaledBalance , user); Borrowing increases scaledDebts but does not modify scaledBalances. Since _setMaxBorrowables only reads scaledBalances (via the currentBalance parameter), it recomputes the exact same maxBorrowable value as before the borrow. The newly increased debt is invisible to the cap. Step-by-Step Attack Assume a single asset (USDC) with 75% LTV, REQUEST_THRESHOLD = 3, and the Diamond has a healthy aggregate Aave position from other users’ deposits. Setup: Attacker supplies 1000 cUSDC to the Diamond. After supply finalization: • scaledBalances[attacker][USDC] = enc(1000) • scaledDebts[attacker][USDC] = enc(0) • maxBorrowable[attacker][USDC] = enc(750) (1000 x 75%) Borrow #1: Attacker submits borrowRequest(USDC, enc(750)). • Check: TFHE.le(enc(750), enc(750)) -> enc(true) -> safeAmount = enc(750) [OK] • Batch accumulates to threshold, processes, decrypts sum, finalizes.

• Post-finalize state: • scaledDebts[attacker][USDC] = enc(~750) • scaledBalances[attacker][USDC] = enc(1000) <- unchanged • _setMaxBorrowables(enc(1000), attacker) -> maxBorrowable = enc(750) <- unchanged • Attacker receives 750 cUSDC from Diamond. Borrow #2: Attacker submits borrowRequest(USDC, enc(750)) again. • Check: TFHE.le(enc(750), enc(750)) -> enc(true) -> safeAmount = enc(750) [OK] passes again • scaledDebts (currently enc(750)) is never consulted in the check. • Batch processes, finalizes. Attacker receives another 750 cUSDC. • Post-finalize: • scaledDebts[attacker][USDC] = enc(~1500) • maxBorrowable[attacker][USDC] = enc(750) <- still unchanged Borrow #N: The same check passes every time. The attacker can repeat indefinitely as long as the Diamond’s aggregate Aave position (backed by other users’ collateral) remains healthy enough for Aave to allow the borrow. Withdrawal: After accumulating sufficient debt, the attacker can also withdraw their original supply: • Withdraw check: withdrawable = TFHE.sub(scaledBalance=enc(1000), scaledDebt=enc(1500)) • In Zama’s TFHE, euint64 subtraction wraps modularly: 1000 - 1500 -> 2^64 - 500 (a huge value) • TFHE.le(enc(1000), enc(2^64-500)) -> enc(true) -> withdrawal passes • Attacker retrieves their 1000 cUSDC supply on top of the borrowed amounts. Final tally: Attacker deposited 1000, extracted 1000 (withdrawal) + Nx750 (borrows). Net theft = Nx750, sourced from other users’ share of the Diamond’s pooled Aave position. Why Aave Itself Doesn’t Prevent This The Diamond contract is a single Aave user. Aave sees one aggregated position: • Total collateral = sum of all users’ supplies

• Total debt = sum of all users’ borrows As long as the aggregate health factor (totalCollateral x avgLTV) / totalDebt > 1, Aave allows new borrows. With sufficient collateral from innocent users, the attacker’s repeated borrows don’t push the aggregate health factor below 1 until the damage is already catastrophic. The per-user accounting inside the Diamond (encrypted scaledBalances / scaledDebts / maxBorrowable) is the only mechanism protecting individual users from each other. This mechanism is broken.

Impact

An attacker can borrow an unlimited amount against a fixed collateral position by repeatedly calling borrowRequest(). Each borrow passes the cap check because maxBorrowable never decreases – the formula scaledBalance x ltv / 10000 ignores existing debt entirely. The borrowed funds are sourced from the Diamond’s aggregate Aave position, which is backed by all users’ collateral. This constitutes direct theft from other depositors. Additionally, the TFHE.sub underflow in the withdraw path (when scaledDebts > scaledBalances) wraps to a huge value, allowing the attacker to also withdraw their original supply. The attack requires only: 1. A supply position in the Diamond. 2. Enough other users’ deposits to keep the Diamond’s aggregate Aave health factor > 1. 3. Patience to wait for REQUEST_THRESHOLD borrow requests to accumulate per batch (the attacker can use multiple addresses or wait for organic traffic). Code Snippet The borrow cap check – no debt subtraction: https://github.com/example/contracts/confidentiality-adapters/aave/libraries/LibBorrowRequest. sol#L25-L27 // check if user has enough supply euint64 maxBorrowable = s. userMaxBorrowablePerAsset [msg.sender ][ asset ]; euint64 safeAmount = TFHE.select(TFHE.le(amount , maxBorrowable), amount , TFHE. asEuint64 (0)); The _setMaxBorrowables function – debt never subtracted: https://github.com/example/contracts/confidentiality-adapters/aave/libraries/LibBorrowRequest. sol#L220-L234

function _setMaxBorrowables (euint64 currentBalance , address sender) internal { // ... s. userMaxBorrowablePerAsset [sender ][ asset] = TFHE.div( TFHE.mul(currentBalance , uint64(ltv)), uint64 (10000) ); // scaledDebts[sender ][ asset] is never referenced } Post-borrow state update – scaledBalances unchanged, maxBorrowable unchanged: https://github.com/example/contracts/confidentiality-adapters/aave/libraries/LibBorrowRequest. sol#L211-L213 euint64 scaledBalance = s. scaledBalances[user ][ asset ]; // not modified by borrow _setMaxBorrowables (scaledBalance , user); // recomputes same value

Recommendation

Subtract existing encrypted debt from maxBorrowable in _setMaxBorrowables, and use the net remaining capacity in the borrow check: function _setMaxBorrowables (euint64 currentBalance , address sender) internal { LibAdapterStorage .Storage storage s = LibAdapterStorage .getStorage (); address [] memory aaveAssets = s.aaveAssets; for (uint256 i = 0; i < aaveAssets.length; i++) { address asset = aaveAssets[i]; (, uint256 ltv , , , , , , , , ) = s. aaveDataProvider . getReserveConfigurationData (asset); - s. userMaxBorrowablePerAsset [sender ][ asset] = TFHE.div( - TFHE.mul(currentBalance , uint64(ltv)), uint64 (10000) - ); + euint64 totalCapacity = TFHE.div( + TFHE.mul(currentBalance , uint64(ltv)), uint64 (10000) + ); + euint64 existingDebt = s.scaledDebts[sender ][ asset ]; + ebool hasCapacity = TFHE.gt(totalCapacity , existingDebt); + s. userMaxBorrowablePerAsset [sender ][ asset] = TFHE.select( + hasCapacity , + TFHE.sub(totalCapacity , existingDebt), + TFHE.asEuint64 (0) + ); } } This ensures maxBorrowable represents the remaining borrowing capacity after existing debt, and uses TFHE.select to clamp at 0 instead of underflowing when debt exceeds capacity. Additionally, consider re-validating caps at finalization time (not just at request time) to mitigate the secondary staleness concern where concurrent requests of different types can bypass each other’s effects during the async decryption window.

Description

Within the Aave confidentiality adapter, scaledBalances and scaledDebts are the protocol’s internal Aave-index-scaled accounting values, stored in the adapter’s 6-decimal confidential token denomination. The codebase itself shows this model on the supply, borrow, and repay paths: • LibSupplyRequest.finalizeSupplyRequests() measures the Diamond’s Aave scaledBalanceOf(...) delta and converts it back into the adapter’s confidential accounting before writing s.scaledBalances. • LibBorrowRequest.finalizeBorrowRequests() does the same with Aave variable debt deltas before writing s.scaledDebts. • LibRepayRequest.repayRequest() then acknowledges that s.scaledDebts is not a real balance by first converting it into realDebt with getReserveNormalizedVariableDebt(asset) before comparing it to the user’s requested repay amount. The withdraw path does not follow that same unit discipline. In LibWithdrawRequest.withdrawRequest(), the protocol computes: euint64 suppliedScaledBalance = s.scaledBalances[msg.sender ][ asset ]; euint64 debtScaledBalance = s.scaledDebts[msg.sender ][ asset ]; euint64 withdrawableScaledBalance = TFHE.sub(suppliedScaledBalance , debtScaledBalance ); euint64 safeAmount = TFHE.select(TFHE.le(amount , withdrawableScaledBalance ), amount , TFHE.asEuint64 (0)); This compares a user-requested withdraw amount against an unnormalized subtraction of two scaled values. That is inconsistent with the repay flow, where the protocol first normalizes scaled debt into realDebt before doing the clamp: uint256 reserveNormalizedDebt = s.aavePool. getReserveNormalizedVariableDebt (asset); euint256 realDebt = TFHE.div(TFHE.mul(TFHE.asEuint256(scaledDebt), reserveNormalizedDebt ), 1e27); euint64 safeAmount = TFHE.select(TFHE.le(amount , TFHE.asEuint64(realDebt)), amount , TFHE.asEuint64(realDebt)); In protocol context, this matters because the requested withdraw amount is later treated as a real withdraw amount: callbackWithdrawRequest() converts it into underlying ERC20 units and calls aavePool.withdraw(...). The stored scaledBalances value is therefore being used as if it’s already normalised, even

though the code elsewhere treats analogous scaled debt as requiring normalization first. The same conceptual mismatch appears in GetterFacet.getSuppliedBalance(), whose NatSpec says it returns the user’s "real supplied balance (encrypted) including interest accrual" while the implementation simply returns s.scaledBalances[user][asset] without applying getReserveNormalizedIncome(asset).

Root Cause The withdraw path mixes scaled accounting and real accounting in the same comparison.

Impact

The protocol can understate a user’s real withdrawable balance and reject or truncate otherwise valid withdraw requests, especially after interest accrual has increased the real collateral value above the stored scaled value.

Recommendation

Normalize the supply side before clamping withdraw requests, just as the repay flow normalizes debt before clamping repay requests. Specifically: • compute realSupply = scaledBalances * reserveNormalizedIncome / 1e27 • compute realDebt = scaledDebts * reserveNormalizedVariableDebt / 1e27 • compare the requested withdraw amount against realWithdrawable = min(realSupply - realDebt, amount) instead of against scaledBalances - scaledDebts • during withdraw finalization, update s.scaledBalances using the actual scaled delta from Aave, for example by measuring scaledBalanceOf(address(this)) before and after the withdraw, or by converting the withdrawn real amount back into scaled units with the current normalized income • fix GetterFacet.getSuppliedBalance() so it either returns the normalized real supplied balance or is renamed/documented clearly as a scaled balance getter

Description

In withdrawRequest, the protocol computes a user’s withdrawable balance using: withdrawableScaledBalance = suppliedScaledBalance - debtScaledBalance ; where suppliedScaledBalance corresponds to aToken (collateral) scaled balance and debtScaledBalance corresponds to variable debt token scaled balance This subtraction is fundamentally incorrect because aTokens and debt tokens represent different accounting systems. They are not directly comparable or subtractable quantities. By mixing these two independent token domains, the protocol produces an invalid withdrawable amount that does not reflect real borrowing health or liquidation constraints.

Root Cause Incorrect assumption that collateral - debt = withdrawable liquidity is valid in scaled token space. The contract does not normalizes of the balances into a common value domain (e.g., colalteral token) with accrued interest

Impact

users can withdraw unsafe amounts or be unfairly restricted. Scaled token arithmetic does not represent real economic value

Description

In _processStateUpdates of LibWithdrawRequest, the protocol directly subtracts requests[i].amount (a confidential token amount) from scaledBalances: s.scaledBalances[user ][ asset] = TFHE.sub( s.scaledBalances[user ][ asset], requests[i]. amount ); This is fundamentally incorrect because: • scaledBalances represents Aave aToken scaled units • requests[i].amount represents confidential token units (cToken) • These two values are in different token systems with different precision and scaling rules Despite this, the protocol treats them as directly subtractable quantities, effectively mixing interest-accruing Aave internal accounting units with encrypted wrapped ERC20 representation units This leads to incorrect balance updates and permanent accounting drift.

Root Cause The scaled balance is not normalized using liquidity index before being subtracted by requests[i].amount.

Impact

collateral state diverges from actual Aave positions. Users may lose more collateral than intended due to incorrect subtraction.

Description

The protocol does not implement any mechanism to handle Aave liquidations. Over time, Aave positions can get close to liquidation due to interest accrual on debt (variable debt growth). Users can borrow any asset against a collateral. The aToken is held by the protocol. With time interest will accrue. The protocol has no way to enforce users to pay back. As a result when liquidation happens, the aToken and debt token held by the protocol will be burned. Since aToken and debt token balance changes after liquidation, that new balance will not reflect to all the user’s scaled supplied and debt balances stored in storage. This leads to a critical mismatch between: • what the protocol believes is borrowed and supplied • what it actually holds

Root Cause No liquidation handling causing mismatch between stored scaled balance and actual balance

Impact

Some users won’t be able to withdraw as those aTokens were burned during liquidation. And some users won’t be able to repay because a part of debt tokens were burned and repaid during liquidation

Description

The TFHE Gateway calls back into Diamond with a decrypted plaintext amount after each batch decryption. These callbacks are supposed to be restricted to the Gateway contract. None of them are. Any external caller can invoke them directly with an arbitrary amount, triggering real Aave operations on Diamond’s account. Diamond inherits GatewayCaller, which provides an onlyGateway modifier. But the callback functions live in separate facet contracts executed through Diamond’s fallback() via delegatecall. The modifier is defined on Diamond and is never referenced in any facet or library. Diamond’s fallback routes any matching selector to the registered facet with no caller check of its own.

Root Cause SupplyFacet.sol:13, WithdrawFacet.sol:13, BorrowFacet.sol:20, RepayFacet.sol:19 - no modifier on any: function callbackSupplyRequest (uint256 requestId , uint64 amount) external { ... } function callbackWithdrawRequest (uint256 requestId , uint64 amount) external { ... } function callbackBorrowRequest (uint256 requestId , uint64 amount) external { ... } function callbackRepayRequest (uint256 requestId , uint64 amount) external { ... } Diamond.sol:36-62 - fallback makes no distinction on caller: fallback () external payable { address facet = ds. selectorToFacetAndPosition [msg.sig]. facetAddress; require(facet != address (0), "Diamond: Function does not exist"); assembly { calldatacopy (0, 0, calldatasize ()) let result := delegatecall(gas(), facet , 0, calldatasize (), 0, 0) // ... } } Attack Path Active request IDs are observable on-chain from EventDecryption events emitted by GatewayContract when a batch is submitted. An attacker monitors these and acts before the Gateway responds. The most direct path is through the withdraw callback. LibWithdrawRequest.sol:119-122:

uint256 amountToWithdraw = amount * (10 ** ( IERC20Metadata(asset).decimals () - ConfidentialERC20Wrapped (cToken). decimals ())); s.aavePool.withdraw(asset , amountToWithdraw , address(this)); 1. A batch of withdraw requests reaches the threshold and a decryption request is sent to the Gateway. 2. Attacker sees the EventDecryption event and the request ID on-chain. 3. Attacker calls Diamond.callbackWithdrawRequest(requestId, 1e6) directly. 4. Fallback routes to WithdrawFacet via delegatecall. No caller check anywhere in the path. 5. amountToWithdraw = 1e6 * 1e12 = 1e18 for an 18-decimal asset like WETH. Diamond withdraws 1 WETH from Aave to itself. 6. Attacker repeats for other pending request IDs, draining all of Diamond’s Aave supply. The borrow callback is similarly exploitable: callbackBorrowRequest stores the attacker-supplied amount in s.requestIdToAmount[requestId], which finalizeBorrowRequests then uses as the Aave borrow amount, creating unbacked debt on Diamond’s account. Front-running the legitimate Gateway response also permanently bricks the affected batch, since the real callback will either double-execute or revert on corrupted state.

Impact

callbackWithdrawRequest is direct, immediate theft - a single call drains Diamond’s entire Aave supply for any asset with a pending withdraw batch. callbackBorrowRequest creates unbacked Aave debt against Diamond. callbackSupplyRequest and callbackRepayRequest burn Diamond’s cToken holdings with an attacker-chosen amount. Any pending batch on any operation type is vulnerable. The only precondition is a valid request ID, which is public.