Flare is the blockchain for data. It is a layer-1, EVM smart contract platform designed to expand the utility of blockchain by delivering data certainty for dApp builders.
FAssets is a trustless, over-collateralized bridge built on Flare that connects non smart contract networks to Flare/Songbird. It enables the creation of wrapped tokens (FAssets) for assets like BTC, DOGE and XRP.
At the core of FAssets v1.1 is a new architecture component called the Core Vault, designed to improve system liquidity, scalability, and capital efficiency.
Evaluating
Triaged by Immunefi
Step-by-step PoC Required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Build Commands, Test Commands, and How to Run Them
- Instructions on how to start the project: https://github.com/flare-foundation/fassets?tab=readme-ov-file#getting-started
- The easiest way is to add code in unit tests because the functionality on which the project relates is mocked.
- You can look at https://github.com/flare-foundation/fassets/blob/main/test/integration/fasset-simulation/AttackScenarios.ts where researchers have submitted their reports.
- Information and some guides you can also find on Flare Dev Hub: https://dev.flare.network/fassets/overview
Where might Security Researchers confuse out-of-scope code to be in-scope?
The FAssets system is able to support wrapped tokens for XRP, BTC and DOGE. However, the initial v1.1 deployment will only have XRP (FXRP) enabled and that will be the sole scope of this audit competition. Any attacks related to FBTC, FDOGE, or UTXO-based logic in general, are out of scope.
Is this an upgrade of an existing system? If so, which? And what are the main differences?
As a result of the Main Audit Competition, here are the changes:
- Removed trailing fees
- Removed handshake
- Removed collateral pool topup functionality
- Simplified enter/exit logic in collateral pool, so that FAsset fees are transfered separately by payFAssetFeeDebt and withdrawPoolFees
- Each main operation in collateral pool now emits own event
- Removed special support for WNat as vault collateral
- All NAT transfers from asset manager (e.g. paying executor) are WNat deposits to avoid reenetrancy and DOS issues (the exception is returning overpaid fee to msg.sender, but that is strictly done at the end of methods)
- Removed token tracking in agent vault; instead tokens can be withdrawn from agent vault after destroy
- Bulk of the external code has been moved to the facets (previously the facets just delegated to the library methods). The libraries now only contain internal reusable code.
- Removed FTSOv1 support.
- Removed minUnderlyingBackingBIPS, now the backing must always be 100%.
- Removed waiting time for underlying withdrawal confirmation (it was supposed to solve an issue that was better solved with withdrawal id randomization)
- Instead of deleting storage structures at the end of lifetime, just mark them as deleted (for agents, collateral reservations, redemption requests)
- Removed EOA ownership proofs - they were obsoleted by EIP-7702 and we officially don't support smart contract chains now.
- Removed terminate and agent buyback functionality - replaced by allowing agents to transfer all their backing to the core vault when the FAsset is winding down.
- Refactored Agents library into several libraries.
- To keep the storage compatible with the deployed contracts on Songbird (to enable upgrade by diamond cut), the variables not needed anymore have remained, but we have prefixed them with __.
- ##Code organization
- Use custom errors in reverts instead of error strings.
- Major contracts grouped with related files in their own directories.
- No more '*' imports.
Where do you suspect there may be bugs and/or what attack vectors are you most concerned about?
Those interacting with new Core Vault features.
What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported?
We use only ERC20 for our FAsset implementation
What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?
governance, core vault multisig
What addresses would you consider any bug report requiring their involvement be out of scope, even if they exceed the privileges attributed to them?
governance (hard to exceed the privileges, as they can update the contracts)
Which chains and/or networks will the code in scope be deployed to?
Coston (testnet), Coston2 (testnet), Songbird, Flare
What external dependencies are there?
FDC (Flare Data Connector), FTSO-V2 (Flare Time Series Oracle)
What are the most valuable educational resources already available? (Ie. Documentation, Explainer videos or articles, etc)
- For concept-level understanding, visit the Flare Developer Hub https://dev.flare.network/fassets/overview
- For technical details:
- Refer to the inline code documentation directly in the repository.
- As an example, you can explore the Redemption function implementation in RedemptionRequestsFacet.sol https://github.com/flare-labs-ltd/fassets/blob/main/contracts/assetManager/facets/RedemptionRequestsFacet.sol#L33
Previous Audits
- Flare Network’s completed audit reports can be found at https://dev.flare.network/support/audits/. Unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
- Flare FAssets Mainnet Audit Competition Reports are available at https://reports.immunefi.com/flare-fassets
Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
Protocol insolvency
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Theft of unclaimed yield
Theft of unclaimed royalties
Permanent freezing of unclaimed yield
Permanent freezing of unclaimed royalties
Temporary freezing of funds
Temporary freezing of funds for at least 24 hour
Smart contract unable to operate due to lack of token funds
Block stuffing
Out of scope
Smart Contract specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
All categories
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers