Reward Amounts

Critical

• 1,000,000 maximum payout in USDC
• Maximum Reward amount is 10% of the funds directly affected up to a maximum of 1,000,000 USDC (1 read important note)
• Minimum reward to discourage security researchers from withholding a bug report is 100,000

Severity Criteria

Critical Definition

• Definite and significant loss of funds without limitations of external conditions
• Definite and significant freezing of funds for >1 year without limitations of external conditions (1 important note) Calculate "funds affected" based on the circuit breaker's maximum withdrawal limit. However, if the bug bypasses the circuit breaker, "funds affected" equals the system's Total Value Locked (TVL).

Payout Tier critical 100,000 -> 1,000,000 (*see critical section above for details) high 50,000->100,000 medium 5,000

General Notes

• Sherlock's Criteria for Issue Validity guide (used in Sherlock audit contests) can be a helpful resource for more context on out-of-scope issues, etc. but nothing in the guide should overrule the definitions above
• A coded Proof of Concept (POC) with instructions to run the POC is required
• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage

Platform Rules

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Previous Audits

known issues/risks accepted from past audits: [description of issue]: [risk accepted by FT description]

• rounding issues for low decimal tokens for low amounts of FT (0.01 FT): When divesting and withdrawing, the protocol now reverts if collateralFromFT() returns 0. This limits the harm to both the user and the protocol to half the amount. Additionally, the precision of ftPerUSD has been increased to 10^-8. The example computation becomes (with ftPerUSD = 1e9) collateralFromFt = ftAmount * (1e8*1e8*1e8)/(1e13*1e9*1e18) = ftAmount * 1e24/1e40. This does not change the threshold of 0.01 FT. The two code changes above still allow some dust to be accrued/not divested when the amount is not a multiple of the threshold. Finally, amountRemaining is now zeroed when burning, but no additional funds are transfered.
• losses not handle: Operational mitigation and disclosures; wrapper enforces exact withdrawals and defensive selection, but protocol-level loss handling and backstops are out-of-scope for this codebase
• short delays on timelock changes: In this repo, short delays are intentional for testing. In production, we configure non-zero timelocks for role/strategy updates as part of deployment process and governance policy.
• malicious strategy manager cannot be removed: Two-step role rotation is retained; emergency procedures (pause/rotation by multisig, MEV-bundled atomic updates) are documented for production ops.
• yield claimer must be responsive in order to recover funds: Description of changes: Maintain primary + subYieldClaimer, operational SLOs/monitoring, and governance intervention procedures. Code remains non-reentrant and exact-withdrawal hardened
• AaveStrategy.availableToWithdraw does not check reserves: Description of changes: Defensive try/catch on liquidity views and exact withdraws reduce exposure. Pool pause is handled operationally via monitoring and wrapper selection.
• Caps updates can be front-run: Apply caps during paused windows or with pre-announced enforcement; optional use of pause during configuration changes.
• Non empty strategy can be removed: mitigated by ops off chain monitoring, can be added back and yield claimed.
• Missing slippage protection in PutManager.invest() - mitigated by ops and using mostly stable assets during sale and oracle bounded ranges

Additional Context

Chains in scope

Ethereum, base, BSC (binance chain), Avalanche, sonic

Expected tokens

ftPUT whitelists tokens, for any specific network it may used the following:

-native wrapped token e.g sonic-> wrapped sonic or wETH, wBNB (all networks) -USDC (all networks, except BSC) -USDT (Ethereum, Avalanche) -USDS (Ethereum) -USDTB (Ethereum) -USDE (Ethereum)

NOTE: under script/config/deployments.toml has a list of each network specific tokens used in current production setup plan. The lists of tokens inside deployment.toml will be referred to during judging.

Also the FT token itself is an OFT token based on the LayerZero network 0x5DD1A7A369e8273371d2DBf9d83356057088082c to enable multichain capabilities, this is also in Scope for this bounty

Trusted protocol roles

The privileged roles like msig admin are fully trusted, msig can upgrade implementation of putManager and pFT.

The other roles are partially trusted to specific actions.

The roles and privileges are detailed here: https://docs.flyingtulip.com/risks/multisigs/

The msig addresses are listed here: https://docs.flyingtulip.com/risks/multisigs/

The roles are considered trusted when completing their tasks and roles and won't harm the users and/or the protocol. If any privileged role can harm the protocol or the users in any way, it's considered informational, and they're fully trusted not to do so.

Offchain mechanisms and procedures

N/A

Protocol Resources

https://docs.flyingtulip.com/

https://flyingtulip.com/