Area: Access Control / Asymmetry (safeTransferFrom vs transferFrom branch). LoopReceipt._update only blocks transfers while the account is busy; it does not reject a destination that can never exercise the owner role. safeTransferFrom to the LoopPosition reverts because the account implements no onERC721Received, but the plain ERC-721 transferFrom succeeds.

After that, receipt.ownerOf(id) == account, so LoopPosition.onlyOwner (line 102) and recover (line 384-385) require msg.sender == account, and LoopPosition has no code path that calls out to its own functions or to receipt.transferFrom. Every function that can move the f(x) collateral, the gOHM in Cooler or idle balances is unreachable forever, while Cooler interest keeps accruing on the locked loan until liquidation.

The same outcome occurs for transferFrom to the LoopReceipt or LoopAccountDeployer addresses. This is user-triggered (a wrong paste of the account address, which the UI displays next to the receipt id), so the impact is self-inflicted, but the contract already spends code to prevent adjacent mistakes (busy check, safeTransfer receiver check) and a one-line guard preserves the agreed design.

Suggested fix: in _update, revert when to == accountOf[id] (optionally also to == address(this) or address(accountDeployer)).

Area: Trust Gap between the manifest's constructor inputs and the launch policy's chain. LoopConfig, FxSwapRouter and WbtcUsdFeed are instantiated with Ethereum mainnet addresses (WBTC, fxUSD, OHM, gOHM, USDS, f(x) PoolManager and WBTC pool, MonoCooler, Olympus staking, Uniswap V3 SwapRouter/Quoter, Curve USDC/fxUSD, Chainlink WBTC/BTC and BTC/USD).

The job page shows the launch settles on Sepolia (treasury is 'the operator's wallet on Sepolia'). eth_getCode on Sepolia (chainId 0xaa36a7 = 11155111) returns 0x for 15 of the 16 addresses; only Morpho Blue 0xBBBB...FFCb has code there.

LoopConfig.validate() (src/LoopConfig.sol:71) reverts InvalidConfiguration on the first empty address, and LoopPosition.deposit() calls _dependencies() -> config.validate() before pulling any funds (src/LoopPosition.sol:145), so no deposit can ever succeed; FxSwapRouter.validate() and WbtcUsdFeed.latestRoundData() also revert. LoopReceipt.createPosition() still succeeds and deploys a ~24.3 KB LoopPosition (about 5M gas) per call for an account that can never be used.

No user funds are at risk (fail-closed before _pull), and launch.json notes acknowledge the gap, so this is a chain/policy decision rather than a code defect: the launch either needs a mainnet chainId (where these addresses and the reviewed whitelist/warmup assumptions apply) or an explicit decision to launch token-only on Sepolia (empty contracts array). A schema-valid manifest does not make the deployed application usable.

Area: Access Control (entry-point inventory). deploy(receiptId) has no caller restriction; it creates new LoopPosition(config, msg.sender, receiptId) for any contract caller. LoopReceipt-issued positions are not affected: accountOf is written only by createPosition, burn requires msg.sender == accountOf[id], and onlyOwner in a rogue account resolves through the caller-supplied fake receipt rather than LoopReceipt.

The exposure is provenance/phishing: a rogue account shares the official config and deployer (Etherscan 'created by' the launch deployer), while its owner resolution is fully attacker-controlled (a fake receipt can return the victim as ownerOf until the victim has deposited and then return the attacker, who calls close()). The official website only loads accounts through receipt.accountOf, so it does not surface rogue accounts.

No fix is required by the design; if desired, the deployer could verify msg.sender against a receipt address bound once (deploy receipt after deployer is circular, so this needs a different construction order or CREATE2 prediction) and the tradeoff should be decided by the author.

_openFx measures the newly credited collateral as afterColl - beforeColl using IFxPool.getPosition around the single operate call. Upstream, AaveFundingPool._updateCollAndDebtIndex runs at the START of every BasePool.operate and charges the funding accrued since the last pool operation to the collateral index (raw = shares * E96 / collIndex), while PositionLogic.getPosition converts with the STORED index.

So beforeColl is read at the stale index and afterColl at the refreshed one: the delta equals (new supply) - (funding accrued on the pre-existing position), and the 49-50% band (lines 204-210) is evaluated against that understated value.

The measured ratio can only rise, so the safety bound is not bypassable, but a correctly quoted follow-up deposit is rejected: the website quotes 49.95% of the initial capital (web/app.js:153), leaving 0.1% of the NEW supply as headroom, and any pending funding larger than that on the OLD position (i.e. funding_fraction * existingRaw > 0.001 * newRaw) flips the check.

Worked example (mock, no fees): existing 152.2 BTC raw position, 0.002% of pending funding (about 1.5 days without any pool operation at a 0.5%/yr long-pool funding ratio; PoolConfiguration.getLongPoolFundingRatio derives it from the Aave borrow-rate snapshot), follow-up deposit of 1 BTC + 0.312 BTC loop + 0.21 BTC top-up with fxBorrow 49,950 fxUSD: delta = 1.522 - 0.003044 BTC, creditedCapital = 0.998 BTC, addedValue = 99,800 USD, addedDebt 49,950 > 49,900 -> UnsafeLtv.

Identical inputs succeed if anyone operated on the pool first. The smaller the top-up relative to the position, the shorter the idle window required (100:1 in the example).

Impact: fail-closed transient DoS of repeat deposits and a deviation from the README rule that the band applies to the initial capital's share of NEW credited collateral; funds are returned atomically.

Fix verified in scratch (test/scratch/LoopPositionFixed.sol): read IPool.getDebtAndCollateralIndex() (fx-protocol IPool.sol:153) before and after _operate and restate beforeColl = beforeColl * indexBefore / indexAfter; this makes the attached proof pass and still rejects fxBorrow = 50,001.

Caveat: that formulation adds 391 runtime bytes to LoopPosition, but LoopAccountDeployer (which embeds the account creation code) is at 24,305 bytes with only 271 bytes of EIP-170 headroom, so the author must either trim code elsewhere, use a leaner read (only the collateral index), or choose a cheaper rule such as computing the credited amount from the supplied WBTC net of the pool supply fee ratio.

The LoopConfig constructor arguments (lines 32-44) and the WbtcUsdFeed/FxSwapRouter arguments (lines 13-16, 22-26) are the Ethereum mainnet addresses recorded in docs/deployment.md (WBTC 0x2260..., fxUSD 0x0857..., PoolManager 0x2508..., WBTC pool 0xab70..., MonoCooler 0xdb59..., staking 0xb63c..., Morpho 0xbbbb..., Chainlink 0xfdfd.../0xf403..., Uniswap 0xe592.../0xb273..., Curve 0x5018...).

All dependency bindings are immutable with no setters (LoopConfig.sol:9-21, FxSwapRouter.sol:25-29, WbtcUsdFeed.sol:9-12).

On Sepolia none of these addresses has code, so after a successful factory deployment: LoopConfig.validate() reverts InvalidConfiguration at the code-length loop (LoopConfig.sol:70-72); LoopPosition.deposit reverts in _dependencies() before pulling any funds (LoopPosition.sol:145, 485-491); FxSwapRouter quotes/swaps revert 'missing dependency' (FxSwapRouter.sol:46); WbtcUsdFeed.latestRoundData() reverts InvalidPrice (WbtcUsdFeed.sol:38).

Only createPosition (which still deploys a 23 KB account per call), recover, and the explicit zero-output close remain usable. The manifest notes acknowledge this, and it is not a code defect: the schema-valid manifest instantiates an application that can never operate on the chain it is launched on and cannot be repaired post-deployment because nothing is upgradeable.

Needed decision/evidence before deployment: either a chain-1 launch policy, or Sepolia integrations (mocks or real deployments) deployed first and referenced by the manifest, plus a fork rehearsal of deposit and close against the chosen addresses. This is reported so the judge/admission step does not treat constructor success as operational readiness.

MockFxPool.getDebtRatioRange returns (0, 0.85e18) and MockFxPool.operate (line 113-137) only enforces an 85% ceiling. Upstream BasePool.operate (fx-protocol-contracts@5e198e9, lines 165-173) also reverts ErrorDebtRatioTooSmall when rawDebts1e36 < minDebtRatiorawColls*price, and docs/deployment.md records the WBTC pool's minimum at 1e14.

Consequences the suite cannot see: (1) repayFx for the FULL f(x) debt while WBTC collateral remains reverts on mainnet (debt 0 with collateral > 0 is below any nonzero minimum). test/LoopFailurePaths.t.sol:178-194 testRepaymentSurplusIsRecoverableWithoutChangingCollateral repays the entire 50,000 fxUSD and asserts pool.debt == 0 with 1.5225e18 collateral left, which only passes against the mock; the website's repayFx form (web/app.js:232) also accepts the full debt without warning, and README calls repayFx a risk-reduction path without this limit.

Full f(x) deleveraging must go through close. (2) BasePool.operate evaluates ErrorPositionInLiquidationMode (line 111-116) BEFORE applying the repayment whenever collateral is withdrawn, so close on an underwater f(x) position reverts even with a sufficient fxRepayBudget; the README documents the repayFx-then-close workaround but no test exercises close failing and the workaround succeeding.

(3) Full repayment burns _convertToRawDebt(shares, debtIndex, Up) (BasePool.sol:155) while getPosition rounds down (PositionLogic.sol:42), so a close with fxRepayBudget == reported debt and exactly that fxUSD balance fails by one wei whenever the debt index is not E96 (after reduceDebt/tick rescaling); the mock burns exactly the reported debt, and several tests use exact budgets.

None of these lose funds (all revert), but the mock-only guarantees overstate repayFx/close behaviour; the mock should enforce the minimum ratio, the liquidation-mode ordering and the rounded-up burn, and the documentation/website should state that repayFx cannot clear the last fxUSD of debt while collateral remains.

position() calls price() whenever fxDebt != 0 (line 137-140), and price() reverts StalePrice once the composite feed is older than maxPriceAge (90,000 s per the manifest) or a component is invalid.

README states that addCollateral/repayFx/repayCooler/close work with a stale entry oracle, and they do (none of them call price()), but the only aggregated on-chain view reverts in that state, so monitoring or integrators reading rawWbtc/fxDebt/gohmCollateral/coolerDebt through it are blind precisely during the outage.

The shipped website avoids the view and reads IFxPool.getPosition and accountPosition directly with price() in a try/catch (web/app.js:118-120), which is why the site keeps working.

Minor: return the four balances unconditionally and report fxLtv as 0 or a sentinel when the feed cannot be read (a try/catch around price() or a separate ltv() view), if the account size budget allows.

_unwind unstakes the account's entire gOHM balance, including unsolicited transfers, and then requires the OHM received to be at least p.minOhm, which must be nonzero (line 327). A 1 wei gOHM donation converts to 0 OHM (gOHM index ~ 3e2 OHM per gOHM, so 1e-18 gOHM is below one OHM minor unit; the mock's 200 OHM per gOHM gives the same 0), so the check fails and close reverts.

When the account still holds gOHM collateral in Cooler the dust is absorbed into the large unstake, so this only bites once Cooler collateral is zero: after a Cooler liquidation seized the gOHM, or after the Cooler side has been unwound externally. In that state the owner's only exit for the remaining f(x) WBTC is close(), and a griefer can re-send 1 wei after every recover(gohm) at the cost of gas only.

A 1 wei OHM donation has the same effect on mainnet through the OHM->WETH->USDC->USDS route (USDC has 6 decimals, so the dust leg outputs 0 and the following hop reverts or the minimum of 1 fails), though the fee-free mock router does not reproduce that variant. Mitigation is the owner submitting recover and close atomically from a contract or via a private relay; the contract itself offers no way to say 'ignore dust'.

Fix: the same change as the first finding (p.minOhm == 0 / p.minUsds == 0 opt out of the unstake / sale and the balances are swept in kind), or only unstake the amount withdrawn from Cooler in this call rather than the whole balance.

The reviewed f(x) BasePool.operate (commit 5e198e9, contracts/core/pool/BasePool.sol, final debt ratio check) runs if (rawDebts * PRECISION * PRECISION < minDebtRatio * rawColls * op.price) revert ErrorDebtRatioTooSmall(); without a rawDebts > 0 guard.

With the recorded WBTC pool minDebtRatio of 1e14 (docs/deployment.md), a position that keeps collateral and reaches zero debt fails that check (0 < 1e14 * rawColls * price), so _operate(0, -debt, 0, budget) with debtAmount equal to the whole debt reverts upstream.

The local MockFxPool.operate only enforces the 85% maximum, so testRepaymentSurplusIsRecoverableWithoutChangingCollateral (test/LoopFailurePaths.t.sol:180) and the LoopInvariant handler's repayFx (amount bound up to r.fxDebt) pass on a behaviour the live dependency rejects.

The same section also enforces MIN_DEBT / MIN_COLLATERAL on every nonzero delta (ErrorDebtTooSmall / ErrorCollateralTooSmall), which the mock ignores, so the smallest repayFx and addCollateral amounts the tests exercise (repayFx(1,1), addCollateral(1)) are not representative either. No funds are at risk: the upstream revert is atomic.

The consequence is a broken documented guarantee ('repayFx ... reduce risk without a fresh entry oracle'): an owner who wants zero f(x) debt while keeping WBTC exposure cannot get there; only a full close() (which withdraws all collateral in the same operate call and therefore passes the check) or a partial repayment is possible, and the website / README should say so.

Fix: encode minDebtRatio and the MIN_* thresholds in MockFxPool.operate so the suite fails on these calls, and either document that full f(x) repayment requires close(), or have repayFx withdraw all collateral to the account when the requested amount clears the debt.

LoopConfig, FxSwapRouter and WbtcUsdFeed are constructed with the Ethereum mainnet addresses of WBTC, fxUSD, OHM, gOHM, USDS, f(x) PoolManager and pool, MonoCooler, Olympus staking, Uniswap V3 router/quoter, the Curve pool, Morpho Blue and both Chainlink feeds. Constructors deliberately do not query them, so the protected deployment floor passes, and the manifest notes acknowledge the addresses 'do not supply integrations on Sepolia'.

The economic consequence is that the application is inert on the chain the current policy deploys to: no receipt can ever hold a position, while the BCLR launch pool trades against a product that cannot operate. This is a policy/manifest gap rather than a contract defect (the fail-closed behaviour is correct), and it is recorded here so the judge can decide whether an inert application satisfies the brief.

Resolution is a service decision: either a Sepolia deployment of compatible mocks with their addresses in the manifest, explicitly labelled as a demo, or a mainnet policy.

Merged from audit_flow (low) and audit_math (medium): same root cause. _openFx measures newly credited collateral as afterColl - beforeColl around the single operate call (lines 198-204).

In the pinned f(x) code (fx-protocol-contracts@5e198e9) BasePool.operate calls _updateCollAndDebtIndex() at the start of every operation (BasePool.sol line 93); AaveFundingPool._updateCollAndDebtIndex charges the funding accrued since the last pool operation to the collateral index (newCollIndex = collIndex * totalRawColls / (totalRawColls - funding)), which shrinks the raw collateral of every existing position, while PositionLogic.getPosition converts shares with the STORED index.

So beforeColl is read at the stale index and afterColl at the refreshed one: the delta equals (new supply) - (funding accrued on the pre-existing position), creditedCapital is understated, and the 49-50% band (line 208) is evaluated against it. The measured ratio can only rise, so the safety bound cannot be bypassed; the defect is that a correctly quoted follow-up deposit is rejected.

The website quotes 49.95% of the initial capital (web/app.js:153), leaving 0.05% of new value as headroom, which is exceeded once pending funding on the old position exceeds 0.1% of the NEW total supply (funding_fraction * existingRaw > 0.001 * newTotal). With a position 100x the top-up and the funding ratio around 7.3%/yr, roughly 2.4 hours without any operate on the pool is enough; after one day even a 49% quote (the band's floor) fails.

Impact: transient, fail-closed rejection of repeat deposits (funds returned atomically); a deviation from the README rule that the band applies to the initial capital's share of NEW credited collateral. Workarounds exist (any pool operation refreshes the index, including the owner's own addCollateral in a prior transaction, or quoting lower inside the band), so severity is low.

Minimal fix: read IPool.getDebtAndCollateralIndex() before and after _operate and restate beforeColl = beforeColl * indexBefore / indexAfter (rounding down), or derive the credited amount from the supplied WBTC net of the pool supply fee ratio. Note the account is 271 bytes under EIP-170 via LoopAccountDeployer, so the fix must be lean. Also note the shipped MockFxPool has no index/funding model, so the suite cannot see this.

Two economics findings (medium 'exit forces OHM sale through a dead route', low 'dust gOHM donation blocks close') share one root cause and one fix, so they are merged.

In _unwind, any gOHM balance is unstaked (line 325) and must yield at least p.minOhm which must be nonzero (line 327), then any OHM balance is sold for USDS via the configured router (line 330) where _swapIn (line 406) reverts Slippage when p.minUsds == 0. close() is the only function that can move Cooler gOHM or f(x) WBTC out of the account, and there is no in-kind option.

Consequence 1: when the Cooler loan is already repaid (repayCooler) and the fxUSD repayment budget is already idle in the account, the OHM sale is not needed to settle anything, yet a route that cannot execute (no OHM->USDS path through any V3 pool delivers output, or the router reverts) blocks the whole exit including the unrelated WBTC collateral, for as long as the route is dead.

The owner chooses the path and can set minUsds=1, so this requires every OHM route to be non-executable; it is a liveness dependency on OHM market liquidity rather than a loss, hence low.

Consequence 2 (griefing): after a Cooler liquidation (collateral and debt zero) or an external Cooler unwind, a 1 wei gOHM transfer to the account converts to 0 OHM on unstake (gOHM index ~300 OHM per gOHM, so 1e-18 gOHM is below one 9-decimal OHM unit; the mock's 200 OHM/gOHM gives the same 0), so line 327 reverts Slippage and the owner cannot retrieve the remaining f(x) WBTC through close(). recover(gohm) clears it, but the attacker can re-send 1 wei before every retry at gas cost only; an EOA owner needs a private relay or a contract that bundles recover+close.

While Cooler still holds collateral the dust is absorbed into the large unstake, so the state is limited. Minimal fix preserving the design: treat p.minOhm == 0 as 'skip the unstake' and p.minUsds == 0 as 'skip the sale' (both tokens are already swept to the owner in kind at lines 247-248), or only unstake the amount withdrawn from Cooler in this call rather than the whole balance.

Merged from audit_economics (low) and audit_flow (low): same root cause.

The pinned f(x) BasePool.operate (fx-protocol-contracts@5e198e9, final debt-ratio check, lines 167-173) runs if (rawDebts * PRECISION * PRECISION < minDebtRatio * rawColls * op.price) revert ErrorDebtRatioTooSmall(); with no rawDebts > 0 guard. docs/deployment.md records the WBTC pool's minDebtRatio as 1e14, so a position that keeps collateral and reaches zero debt fails that check (0 < 1e14 * rawColls * price). repayFx(debtAmount == whole debt, budget) therefore reverts upstream; close() still works because it withdraws all collateral in the same operate (rawColls == 0 -> 0 < 0 is false).

The shipped MockFxPool.operate (test/mocks/Protocols.mock.sol:113-137) only enforces the 85% ceiling and getDebtRatioRange returns (0, 0.85e18), so test/LoopFailurePaths.t.sol:178-194 testRepaymentSurplusIsRecoverableWithoutChangingCollateral asserts a flow (debt 0 with 1.5225e18 collateral left) that the live dependency rejects; the website's repayFx form (web/app.js:232) accepts the full debt without warning; README calls repayFx a risk-reduction path without this limit.

The same upstream section also enforces MIN_DEBT/MIN_COLLATERAL on every nonzero delta (ErrorDebtTooSmall/ErrorCollateralTooSmall), which the mock ignores, so repayFx(1,1)/addCollateral(1) in the tests are not representative; and BasePool evaluates ErrorPositionInLiquidationMode (lines 111-116) before applying a repayment whenever collateral is withdrawn, plus full repayment burns the rounded-up raw debt (line 155) while getPosition rounds down, so exact-budget closes can miss by one wei when the debt index is not E96.

No funds are at risk (all reverts are atomic).

Impact: a documented guarantee ('repayFx reduces risk') is overstated, and the suite cannot detect it.

Fix: encode minDebtRatio and the MIN_* thresholds in MockFxPool.operate so the suite fails on these calls; document (README/website) that clearing all f(x) debt requires close() or a partial repayFx, or have repayFx withdraw all collateral to the account when the requested amount clears the debt.

LoopReceipt._update only blocks transfers while the account is busy; it does not reject a destination that can never exercise the owner role. safeTransferFrom to the LoopPosition reverts because the account implements no onERC721Received, but plain ERC-721 transferFrom succeeds.

Afterwards receipt.ownerOf(id) == account, so LoopPosition.onlyOwner (line 102) and recover (lines 384-385) require msg.sender == account, and LoopPosition has no code path that calls its own functions or receipt.transferFrom. Every function that can move the f(x) collateral, the gOHM in Cooler or idle balances is unreachable forever, while Cooler interest keeps accruing on the locked loan until liquidation.

The same outcome occurs for transferFrom to the LoopReceipt or LoopAccountDeployer addresses. This is self-inflicted (a wrong paste of the account address, which the UI displays next to the receipt id), so low, but the contract already spends code to prevent adjacent mistakes (busy check, safe-transfer receiver check) and a one-line guard preserves the design.

Fix: in _update, revert when to == accountOf[id] (optionally also address(this) and address(accountDeployer)).

deploy(receiptId) has no caller restriction; it creates new LoopPosition(config, msg.sender, receiptId) for any contract caller (an EOA caller fails the receipt_.code.length check in the LoopPosition constructor). LoopReceipt-issued positions are unaffected: accountOf is written only by createPosition, burn requires msg.sender == accountOf[id], and onlyOwner in a rogue account resolves through the caller-supplied fake receipt rather than LoopReceipt.

The exposure is provenance/phishing only: a rogue account shares the official config and deployer (explorer 'created by' the launch deployer) while its owner resolution is attacker-controlled (a fake receipt can report the victim as ownerOf until the victim has deposited, then report the attacker, who calls close()). The official website only loads accounts through receipt.accountOf, so it does not surface rogue accounts.

No fix is required by the design; restricting deploy to the receipt needs a different construction order (receipt-after-deployer is circular) or CREATE2 prediction, a tradeoff for the author.

Status this round: unchanged; source identical to the previous round and the reproduction still passes. _unwind unstakes the account's entire gOHM balance, including unsolicited transfers, then requires the OHM received to be at least p.minOhm, which must be nonzero (line 327).

A 1 wei gOHM donation converts to 0 OHM (gOHM index of a few hundred OHM per gOHM, so 1e-18 gOHM is below one 9-decimal OHM minor unit; the mock's 200 OHM per gOHM gives the same 0), so the check fails and close reverts. While the account still holds gOHM collateral in Cooler the dust is absorbed into the large unstake, so this only bites once Cooler collateral is zero: after a Cooler liquidation seized the gOHM, or after the Cooler side was unwound externally.

In that state the owner's only exit for the remaining f(x) WBTC is close(), and a griefer can re-send 1 wei after every recover(gohm) at the cost of gas only. Mitigation is the owner submitting recover and close atomically from a contract or via a private relay; the contract offers no way to say 'ignore dust'.

Same fix as the medium finding (p.minOhm == 0 / p.minUsds == 0 opt out of the unstake / sale, balances swept in kind), or only unstake the amount withdrawn from Cooler in this call rather than the whole balance.

Scope note: the token-only manifest means these contracts are not deployed by this launch.

Status this round: unchanged; neither MockFxPool.operate, test/LoopFailurePaths.t.sol nor the README was revised.

Re-substantiated this round by fetching the referenced upstream source (AladdinDAO/fx-protocol-contracts commit 5e198e9, contracts/core/pool/BasePool.sol, the commit docs/deployment.md cites): lines 80-84 revert ErrorCollateralTooSmall / ErrorDebtTooSmall for any nonzero delta smaller than MIN_COLLATERAL / MIN_DEBT, and the final debt ratio block at lines 167-172 runs if (rawDebts * PRECISION * PRECISION < minDebtRatio * rawColls * op.price) revert ErrorDebtRatioTooSmall(); with no rawDebts > 0 guard (the pool initialiser even defaults minDebtRatio to 0.5e18; docs/deployment.md records 1e14 for the WBTC pool).

A position that keeps collateral and reaches zero debt therefore fails the check (0 < minDebtRatio * rawColls * price), so repayFx with debtAmount equal to the whole debt reverts upstream. A full close passes because it withdraws all collateral in the same operate call (rawColls == 0 makes the right side 0).

The local MockFxPool.operate enforces only the 85% maximum, so testRepaymentSurplusIsRecoverableWithoutChangingCollateral (test/LoopFailurePaths.t.sol:180) and the LoopInvariant handler's repayFx (bound up to r.fxDebt) pass on behaviour the live dependency rejects, and the tiny amounts exercised (repayFx(1,1), addCollateral(1)) are below the MIN_* thresholds.

No funds are at risk (the upstream revert is atomic); the broken piece is the documented guarantee at README.md:25 that repayFx reduces risk without a fresh entry oracle, which does not hold for the 'zero f(x) debt, keep WBTC' target.

Fix: encode minDebtRatio and the MIN_* thresholds in MockFxPool.operate so the suite fails on these calls, and either document that full f(x) repayment requires close(), or have repayFx withdraw all collateral to the account when the requested amount clears the debt.

Scope note: the token-only manifest means these contracts are not deployed by this launch.

Reconfirmed prior advisory 109af25edff333c9c17d99e67d4aa5488b0b31873e64d52c44e6b6f55c38cd6c; the relevant code is unchanged. _openFx subtracts beforeColl, read using the stored collateral index, from afterColl, read after operate refreshes that index. Funding on the existing position is therefore deducted from the new deposit's creditedCapital. A valid 49.95% initial borrow fails the 50% ceiling even when the final position remains below 33%.

This is a fail-closed interruption of repeat deposits; transfers revert atomically.

The pinned upstream AaveFundingPool._updateCollAndDebtIndex updates the index at the beginning of BasePool.operate, while PositionLogic.getPosition uses the stored index: https://github.com/AladdinDAO/fx-protocol-contracts/blob/5e198e93657db008a57129e7eea21a996618f17f/contracts/core/pool/AaveFundingPool.sol#L95-L117 and https://github.com/AladdinDAO/fx-protocol-contracts/blob/5e198e93657db008a57129e7eea21a996618f17f/contracts/core/pool/PositionLogic.sol#L28-L42.

Normalize the pre-operation collateral to the refreshed index, or measure net new supply independently of old-position funding. Preserve both borrowing limits and check deployment size: the current LoopAccountDeployer runtime is 24,305 bytes. This remains an application-source advisory; the revised token-only manifest does not deploy these accounts.

Reconfirmed prior advisory 9f0ed65092a95c6abd813d576c543877f65d2e3f908d9f277e33ac6341599956. The mock still uses a zero minimum debt ratio, checks only the final maximum ratio, and burns exactly the reported debt. The shipped testRepaymentSurplusIsRecoverableWithoutChangingCollateral still passes after fully repaying f(x) debt while retaining collateral.

Upstream instead checks a nonzero minimum ratio, checks liquidation eligibility before applying a repayment paired with withdrawal, and rounds full repayment up while getPosition rounds down. See BasePool.operate at the pinned commit: https://github.com/AladdinDAO/fx-protocol-contracts/blob/5e198e93657db008a57129e7eea21a996618f17f/contracts/core/pool/BasePool.sol#L67-L175. These omissions hide reproducible repayment/exit failures, rather than loss of funds.

Update the model and regression tests to enforce those rules; explain that full f(x) deleveraging uses close, and retain explicit repayment rounding headroom. The browser repayFx form still accepts the entire debt without explaining the minimum-ratio restriction. These are application test/UX limitations; the revised token-only manifest excludes the application.

Settlement of prior finding 5fc4631c… (Access Control / Asymmetry between safeTransferFrom and transferFrom). The revision changed only launch.json; src/LoopReceipt.sol is byte-identical to the version reviewed last round and the defect reproduces unchanged. LoopReceipt._update still rejects only transfers while the account is busy.

It does not reject a destination that can never satisfy LoopPosition.onlyOwner (line 102) or recover (lines 384-385): the position's own account address, the receipt contract or the deployer. safeTransferFrom to the account reverts because LoopPosition has no onERC721Received, but plain transferFrom succeeds, after which receipt.ownerOf(id) == account and no code path in LoopPosition can call receipt.transferFrom or any owner function on itself, so f(x) collateral, Cooler gOHM and idle balances become unreachable forever while Cooler interest accrues.

Launch impact for this round: none. The token-only manifest (contracts: []) means LoopReceipt is not deployed by this launch, so nothing on Sepolia is exposed. It remains a real defect in the accepted source that the notes describe as the chain-1 deployment set, and the one-line guard (revert in _update when to == accountOf[id], optionally also to == address(this) or address(accountDeployer)) preserves the agreed design.

Severity stays low: self-inflicted by the current owner, no third-party theft.