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

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

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:
ftPUT/PRIVILEGES.md in the contest repo

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.

ftPUT integrates the AAVE oracle on each of the networks and adds price bounds to the read values to protect from extreme values out of range for sale purposes

ftPUT/contracts/FlyingTulipOracle.sol

not comply specifically, but there is an ERC-7265 inspired implementation of a circuit breaker pattern as the production phase is rolled out this works like a guarded launch to ensure complete withdrawal of TVL is not possible. EIP-violations are not considered valid issues as contracts are not intended to comply with any specific EIP.

ftPUT/contracts/cb/CircuitBreaker.sol

N/A

The documented invariants can be found
ftPUT/test/invariants/INVARIANTS.md

The FT token is an OFT token with multichain support via the LayerZero stack support.

Regarding the circuitbreaker (CB) it covers all the inflows/outflows of the yieldWrappers to keep track of the rate limits configured per token asset, since the CB was added late stage in development cycle to keep the change as low impact as possible the only value transfer it could not cover was the "putManager.withdrawFT()" function, by design choice to lower impact on CB integration changes, if an issue is found on this flow the putManager can be upgraded so that the CB can cover that flow as well (if any issue related to this flow can lead to Medium/High impact, it can be considered a valid issue).

There are several caps on all operations that can be added/removed to manage risk on TVL as well as whitelisting specific strategies and tokens. The system is intended to use low-risk yield options for the capital managed. The protocol will invest in strategies that cannot suffer a loss, and the strategies will be low-risk yield.

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.

https://docs.flyingtulip.com/

https://flyingtulip.com/

Something that needs further validation are the in/out flows in regards to the integration with circuit breaker since this was added post audit as an additional security layer, assumptions and design choices stated above apply, regarding withdrawFT not being covered as design choice.