[ARFC] Add FBTC to Aave v3 Main Market on Ethereum

[bgdlabs]

fBTC (Ethereum) technical analysis

Summary

This is a technical analysis of all the smart contracts of the asset and its main dependencies.

Disclosure: This is not an exhaustive security review of the asset like the ones done by the Ignition Team, but an analysis from an Aave technical service provider on different aspects we consider critical to review before a new type of listing. Consequently, like with any security review, this is not an absolute statement that the asset is flawless, only that, in our opinion, we don’t see significant problems with its integration with Aave, apart from different trust points.

Analysis

FBTC is a wrapped version of Bitcoin on EVM chains. The system is based on the TSS Network (Threshold Signature Scheme), where different nodes coordinate the BTC custody through multi-party wallets, enhancing decentralization. Users can become “qualified users” (aka FBTC minter) by fulfilling KYC/KYB requirements. When onboarded, qualified users can request FBTC through the bridge after sending their BTC to the custodian wallets.

For the context of this analysis, our focus has been on the following aspects, critical for the correct and secure integration with Aave:

• A recommendation of pricing strategy to be used in the integration asset <> Aave.
• Any miscellaneous aspect of the code we can consider of importance.
• Analysis of the access control (ownerships, admin roles) and the nature of the entities involved in the system. Regarding the table permissions’ holders and their criticality/risk, it is done following these guidelines:

Criticality	Description
CRITICAL	Usually super-admin functionality: it can compromise the system by completely changing its fundamentals, leading to loss of funds if misused or exploited. E.g. proxy admin, default admin
HIGH	It can control several parts of the system with some risk of losing funds. E.g., general owners or admin roles involved in the flow of funds
MEDIUM	It can cause malfunction and/or minor financial losses if misused or exploited. E.g., fee setter, fee recipient addresses
LOW	It can cause system malfunctions but on non-critical parts without meaningful/direct financial losses. E.g., updating descriptions or certain non-critical parameters.

Risk	Description
	The role is controlled via a mechanism we consider safe, such as on-chain governance, a timelock contract, or setups involving multi-sigs under certain circumstances.
	The role is controlled in a way that could expose the system and users to some risk depending on the actions it can control.
	The role is controlled via a clearly non-secure method, representing risks for the system and users.

General points

• The upgradeability admin of the FBTC system is the Gnosis Safe 5-of-8, which is the governance multisig.
• For proxies, it uses the OZ UUPS pattern.
• Part of the FBTC system comprises off-chain modules responsible for monitoring, validating, and signing BTC transactions through MPC wallets where the BTC backing FBTC is kept.
• The FBTC off-chain module is composed of a so-called Bridge Monitor, which is responsible for monitoring the on-chain EVM events and BTC transactions, a TSS Gateway, which connects the Bridge Monitor <> TSS Nodes by requesting signed transactions from the node and broadcasts them to the EVM contracts. The TSS Nodes generate TSS PK shares used to sign transaction requests and manage independent Risk Control Modules, which receive and validate information from blockchain nodes, allowing only those requests that meet the FBTC rules for deposits/withdrawals. The Blockchain Nodes provide the most up-to-date data for the Bridge Monitor and the Risk Control Modules, acting on the BTC and EVM blockchains.
  
  
  
  

Contracts

The following is a non-exhaustive overview of the main smart contracts involved with FBTC.

FToken - FBTC0

It’s the FBTC token that represents 1:1 BTC in the Ethereum ecosystem. The contract is an ERC20 non-upgradable contract. The FBTC0 is the asset to be onboard on Aave.

Permission owner	functions	Criticality	Risk
general owner: governance multisig	lockUser, unlockUser, setBridge, transferOwnership	HIGH
minter: FireBridge	mint	HIGH

• Access Control
  • Access control for the critical functions in the FBTC contract is split between the governance multisig (owner) and the bridge.
  • The owner can blacklist addresses via the lockUser(address) function and remove them via the unlockUser(address) function.
  • The owner can set a new bridge address by calling the setBridge(address) function.
  • The system presents a 2-step transfer owner process where the owner initiates by calling the transferOwnership(to) function, and the pending owner finalizes the transfer by calling the acceptOwnership() function.
• Minting/Burning
  • The bridge is the only address to mint and burn FBTC tokens via the mint() and burn() functions.
  • A payFee(amount) function is invoked during the minting/burning/cross-chain actions that send an amount to the feeRecipient address (Gnosis Safe 2-of-3). It’s only callable by the bridge.
    
    

FireBridge

It’s the core contract of the system, managing allowed users for FBTC minting requests, overseeing cross-chain operations, and facilitating redemption through burning FBTC. It presents a shared access control where the governance controls the most critical functions, and other mint-related functions are split between the minter contract and allowed users. The FireBridge is a UUPS proxy upgradeable by the governance.

Permission owner	functions	Criticality	Risk
proxyAdmin → governance multisig	upgradeToAndCall	CRITICAL
general owner: governance multisig	addQualifiedUser, editQualifiedUser, removeQualifiedUser, lockQualifiedUser, unlockQualifiedUser, setToken, setMinter, setFeeModel, setFeeRecipient, addDstChains, removeDstChains, blockDepositTx	HIGH

• Access Control
  • The owner (governance multisig) manages allowed users who can initiate a request for minting FBTC via the addQualifiedUser(address), editQualifiedUser(address), removeQualifiedUser(address), lockQualifiedUser(address), and unlockQualifiedUser(address) functions. Through these functions, the owner can change the qualified user’s deposit and withdrawal addresses and lock or remove the user.
  • The owner can change different core addresses like the FBTC address via the setToken(address) function, the minter address via the setMinter(address) function, the feeModel contract via the setFeeModel(address), and its fee recipient address calling the setFeeRecipient(address) function.
  • The owner manages chains that users can send/receive FBTC via the addDstChains(chains[]) and removeDstChains(chains[]) functions.
  • The owner can also define invalid transactions to request possible minting requests via the blockDepositTx(txId) function.
• Minting/Burning
  • Allowed users can initiate a minting request via the addMintRequest(amount, txId) function, providing the amount to mint and the BTC txId deposit to the MPC address controlled by the custodians. The Bridge Monitor verifies if the request event is valid by checking the BTC deposit tx. If so, multiple TSS Nodes co-sign through the MPC, and the TSS Gateway initiates the confirmation of the minting by calling the confirmMintRequest(hash) via the FBTCMinter contract, which mints the tokens to the user address.
  • Allowed users can initiate a BTC redemption by calling the addBurnRequest(amount) function, which pays a fee and burns the amount of the user’s tokens. The off-chain Bridge Monitor verifies the burn request event and sends a withdrawal request to the TSS Gateway. The TSS Nodes co-sign a transfer through the MPC, and the TSS Gateway initiates the transfer to the pre-registered user BTC address. With the BTC transaction finalized, the TSS Gateway calls the confirmBurnRequest(txId) with the withdrawal txId.
• Cross-chain management
  • Users bridge FBTC tokens to registered L1/L2s via the addCrosschainRequest(chain) or the addEVMCrosschainRequest(chain) functions. Internally, these functions check if the chain is registered. If so, it pays a fee and burns the user’s tokens. Then, the off-chain Bridge Monitor verifies the cross-chain event in the source chain and initiates a cross-chain request to the TSS Gateway. The TSS Nodes co-sign the confirmation, and the TSS Gateway confirms the cross-chain transaction by calling the confirmCrosschainRequest(request) function in the destination chain.
    
    

FBTCMinter

The FBTCMinter contract controls the minting, burning, and cross-chain confirmations across the FBTC system. The role-based access control ensures that only specific addresses can do certain actions within the contract.

Permission owner	functions	Criticality	Risk
general owner: governance multisig	grantRole, revokeRole, setBridge	HIGH
MINT_ROLE: EOA 0x53Fe…31F3	confirmMintRequest	HIGH
BURN_ROLE: EOA 0x42C4…25F9	confirmBurnRequest	HIGH
CROSSCHAIN_ROLE: EOA 0x3160…C35D	confirmCrosschainRequest	HIGH

• Access Control
  • The roles are divided into MINT_ROLE, BURN_ROLE, and CROSSCHAIN_ROLE, where each role is assigned by the owner (governance multisig) for specific operators.
  • The owner can also change the bridge address by calling the setBridge(address) function.
• Addresses assigned with the MINT_ROLE (EOA 0x53Fe…31F3)can finalize mint requests by calling the confirmMintRequest(hash) function by passing the specific hash of the request. Then, internally, it calls the bridge.confirmMintRequest(hash) function.
• Addresses assigned with the BURN_ROLE (EOA 0x42C4…25F9) can finalize burn requests via the confirmBurnRequest(hash, txId) function by passing the hash of the request and the txId of the BTC withdrawal. This function internally calls the bridge.confirmBurnRequest(hash, txId) function.
• The CROSSCHAIN_ROLE (EOA 0x3160…C35D)operators can finalize a cross-chain transfer on the destination chain by calling the confirmCrosschainRequest() or multiple requests via the batchConfirmCrosschainRequest() function, which internally calls the bridge.confirmCrosschainRequest() function.
  
  

FeeModel

The FeeModel contract controls and calculates the fee cost of operations like redemptions and cross-chain bridges. Each operation configured has a FeeConfig containing a max and min fee and the fee tiers. It’s a non-upgradeable contract.

Permission owner	functions	Criticality	Risk
general owner: governance multisig	setDefaultFeeConfig, setCrosschainFeeConfig, setUserBurnFeeConfig	MEDIUM

• The owner (governance multisig) can define a default fee for different operations by calling setDefaultFeeConfig(operation, FeeConfig).
• The owner can set a cross-chain fee for different chains by calling the setCrosschainFeeConfig(chain, FeeConfig). Currently there is a default fee of 0.0001 FBTC for cross-chain.
• The owner can set a burn fee for allowed users via the setUserBurnFeeConfig(user, FeeConfig). The redemption fees start at 0.2% with a max fee of 0.01 FBTC.
  
  

FBTC1

It’s a yield-bearing version of FBTC0, used across other DeFi applications - e.g., staked platforms like pumpBTC, Ether.fi, and Bedrock. The FBTC1 address is different for each DeFi platform it’s connected to, and each instance receives a different BTC custody wallet. This is not the FBTC being onboarded into Aave, but we’re mentioning it because part of the FBTC0 liquidity is held by FBTC1.

• The FBTC0 users can deposit into the FBTC1 vault of their choice, and the vault partner will request the FBTC0 to be burned through the bridge via addBurnRequest, and the TSS nodes will send the BTC to a new custody address.
• A similar process happens when a user wants to redeem their FBTC0: the user requests an FBTC0 withdrawal, the partner requests the FBTC0 mint through the bridge via addMintRequest and sends back the BTC to the main BTC custody address.
  
  

Miscellaneous

• The system has three security reviews by Blocksec, Secure3, and MixBytes.
• The BTC custody through MPC is secured by a security council composed of Antalpha Prime, Mantle, and Cobo entities. Also, the entire system is controlled by the 5-of-8 multisig, without the setup of a Timelock, for example, the upgradeability. The DAO should be aware of the risks associated with trust assumptions.
• The FBTC has a Chainlink’s Proof of Reserve that can be verified here. The FBTC website also presents the distribution across EVM chains here.
• The reserves can also be checked via the FireBridge contract by querying the getQualifiedUsers(), which returns a list of qualified FBTC users’ addresses, and by calling the getQualifiedUserInfo(address), passing one of those addresses, it returns the BTC wallet in which the BTC was deposited.
  
  

Asset pricing

Similar to tBTC (well detailed here), we suggest pricing FBTC using the core BTC/USD price feed, which seems the most reasonable form of pricing given the characteristics of the asset.

Conclusion

We think FBTC doesn’t have any problem in terms of integration with Aave, and there is no major technical blocker for listing.

Following our discussion with the Ignition Team, we suggested time-locking the upgradeable admin of FireBridge and other sensitive methods within the FBTC Minter. They agreed and will proceed with the changes in the short term.

However, as the listing will proceed before the suggestions are addressed, we initially recommend conservative caps until the team makes all those changes for security reasons.