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

[ACI]

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

author: @ACI

created: 2024-11-25

---

Risk Parameters have been provided by Risk Services Providers and ARFC has been updated with that feedback 2024-12-03

Summary

The proposal aims to onboard Ignition’s FBTC, to the Aave v3 protocol Main Market on Ethereum.

Motivation

FBTC is a cross-chain BTC protocol that uses the Threshold Signature Scheme network to enable secure, decentralized Bitcoin scalability across multiple blockchains. By leveraging multi-party computation, FBTC strengthens bridge security, safeguarding user assets and ensuring robust cross-chain interoperability. This setup also integrates a cross-chain hub, allowing seamless BTC transfers while reducing issues linked to Bitcoin L2 growth.

This new asset will broaden opportunities for Bitcoin holders aiming to participate in DeFi on Aave v3. The introduction of FBTC offers users more flexibility in leveraging their Bitcoin, enhancing liquidity and driving increased engagement within the Aave protocol.

With $480M in total value locked (TVL), FBTC is emerging as a compelling solution in Bitcoin bridging, supported by its upcoming Chainlink Oracle integration to accelerate growth across EVM networks.

Aave is positioned to benefit from a material increase in AUM resulting from FBTC deposits. This capital is being sourced by from within the Ignition team’s network. Several sophisticated investors are looking to user Aave at size and some teams have built products specifical for investors in anticipationg of the Aave listing. The Ignition team is expected to provide incentives supporting Aave users directly and also strategy providers built on top of Aave. @TokenLogic has been coordinating with various prospective users to ensure there is adequate demand ahead of the listing.

Benefits of listing FBTC

With the evolving landscape surrounding wBTC, having alternative wrapped BTC tokens available for use on Aave is crucial. With Antalpha and Mantle serving as core contributors, Ignition strong reputations position this initiative as a credible alternative to wBTC. This collaborative effort has already garnered over $850 million in TVL.

The cbBTC listing has demonstrated how impactful an Aave integration can be for both parties involved. Aave successfully captured 74% of the cbBTC supply, showcasing the significant growth potential and mutual benefits such integrations can bring.

Liquidity commitments

FBTC current points campaign is focused on maximizing user engagement and incentivizing interactions within the DeFi ecosystem. As part of this initiative, they aim to highlight Aave by listing it in the featured section, providing prominent exposure to its offerings. Additionally, they plan to create a new DeFi lending category, with Aave being the inaugural protocol, further showcasing its significance in this space.

To enhance user participation, they will introduce boosted points under the Sparks program, with Aave receiving 2x-4x sparks by default; double the rewards compared to other protocols, which offer 1x-2x.

For a limited period, it will further amplify rewards by offering a 4x-8x sparks boost on Aave V3 instance, driving even greater engagement and usage.

Specification

Ticker: FBTC

Contract address on mainnet: 0xC96dE26018A54D51c097160568752c4E3BD6C364

Chainlink oracle: 0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c

Project: https://fbtc.com/

Reserves addresses: Bitcoin Reserve Address | FBTC

Proof of Assets dashboard: FBTC proof of assets dashboard

GitHub: GitHub - fbtc-xyz/fbtc-contract

Docs: https://docs.fbtc.com/

Audit: fbtc-contract/audits at main · fbtc-xyz/fbtc-contract · GitHub

Twitter: x.com

Parameter	Value
Network	Ethereum
Isolation Mode	No
Borrowable	Yes
Collateral Enabled	Yes
Supply Cap	200
Borrow Cap	100
Debt Ceiling	-
LTV	73.00%
LT	78.00%
Liquidation Bonus	7.50%
Liquidation Protocol Fee	10%
Variable Base	0.0%
Variable Slope1	4.0%
Variable Slope2	300%
Uoptimal	45%
Reserve Factor	50%
Stable Borrowing	Disabled
Flashloanable	Yes
Siloed Borrowing	No
Borrowable in Isolation	No
E-Mode Category	N/A

Risk Parameters have been provided by Risk Services Providers and ARFC has been updated with that feedback 2024-12-03

Disclosure

The ACI is not directly affiliated with Ignition and did not receive compensation for creation this proposal.

Next Steps

1. If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.
2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.

Copyright

Copyright and related rights waived via CC0.

[LlamaRisk]

Summary

LlamaRisk supports onboarding FBTC as collateral on Aave Core Instance. We welcome diversity in wrapped Bitcoin offerings and believe Aave should remain protocol-agnostic, which aligns with recent tBTC and cbBTC integrations. The asset, launched <6 months ago, exists in locked and unlocked variants, with the locked version showing strong growth (6.6K BTC TVL vs ±350 BTC for unlocked). This integration would unlock new utility and growth potential for FBTC0 (non-yield bearing).

Primary risks center on liquidity concentrated in a single Uniswap LP (likely Ignition-affiliated) and restrictions limiting minting, burning, and transfers to “qualified users.” Governance operates through a 5/8 multisig with significant permissions and no timelock, with many signers being known, competent, and value-add ecosystem partners. The asset is entirely governed and custodied by a security council that has yet to be fully created, introducing risks from uncertainty and dependence on current contributors’ continued engagement. Custody risk is also to be considered, given that BTC on Bitcoin is held by a security council consisting of Cobo, Mantle, and Antalpha Prime.

The system architecture is well-designed, with planned improvements, including expanding qualified users to KYC’d CEX users and a liquidity incentives program, which should help with diversification. The multisig is controlled by reputable ecosystem partners, and an ImmuneFi bug bounty ($100K) is expected in mid-December.

Expand to reveal our full Collateral Risk Assessment

Collateral Risk Assessment

1. Asset Fundamental Characteristics

1.1 Asset

FBTC is a bitcoin wrapper developed by Ignition. It initially launched in May of this year on Mantle and Mainnet. It is designed to increase BTC usage within DeFi across various networks. Utilizing different strategies such as lending or liquidity provision, this asset offers additional use cases (yield) to a traditionally underutilized coin (in DeFi).

Source: Ignition Proof of Assets Dashboard, 25 November 2024

The asset complies with the ERC20 standard and has 379 FBTC on mainnet and 292 FBTC on Mantle. There is also 47 FBTC on BNB Chain. It is 1:1 backed by BTC on the Bitcoin chain held in addresses with various security measures, including Threshold Signature Schemes and Multi-Party Computation (MPC) wallets.

The asset is a custodied offchain by a security council (more in Section 4) and can be brought on / off EVM chains through “Qualified Users”, who pass stringent KYB / AML checks. Smart contract permissions enforce this on EVM chains and MPC wallets enforce this on Bitcoin Chain.

The asset has two forms: FBTC0 (liquid) and FBTC1 (locked). This ARFC onboards FBTC0. FBTC1 is the locked, yieldbearing version of FBTC0 with a segregated, programmatic delineation between the two. FBTC1 is used in onchain DeFi strategies, and FBTC0 is held “naked”.

Most FBTC1 is held on Mainnet (see image above).

Source: GoPlus $FBTC Token Security Page, 25 November 2024

This asset is heavily concentrated at this time, with >80% of this asset being held by four addresses.

1.2 Architecture

FBTC operates through two primary components: a Bitcoin Chain deposit address and a mainnet minter, with access restricted to qualified users (entities that meet Ignition’s KYB requirements, including AML analysis, documentation, and industry-standard compliance, as verified by LlamaRisk’s General Counsel under NDA). The system employs three core workflows:

Minting Process:

• Qualified users deposit BTC and initiate a mint request
• Bridge Monitor verifies deposit and forwards to TSS gateway
• Multiple TSS nodes validate requests through risk controls
• FBTC minted upon validation

Burning Process:

• User initiates burn request through Bridge contract
• Bridge Monitor detects burn and sends a withdrawal request
• TSS nodes validate and process BTC withdrawal
• Bridge contract confirms completion

Cross-chain Transfer:

• User initiates bridge contract request
• FBTC burned on the origin chain
• TSS gateway validates and confirms the transfer
• FBTC minted on the destination chain

The system uses Chainlink’s Proof of Reserves to ensure 1:1 BTC backing. While the architecture is conceptually sound and prevents double counting, the qualified user requirement could impact arbitrage efficiency and DEX liquidity.

1.3 Tokenomics

FBTC’s tokenomics are straightforward. The number of FBTC in circulation is directly managed programmatically to ensure that the number of EVM FBTC is always backed 1:1 with BTC Chain BTC. No additional tokenomic considerations are at play with this asset.

2. Market Risk

2.1 Liquidity

Source: CoW Swap, 25 November 2024

Liquidity for this asset is good, with 7% slippage at a 620 FBTC / $55M trade size.

Source: Revert.Finance, 25 November 2024

The Uniswap V3 liquidity provision is staggered, preparing the asset for some potential depeg. All Uniswap liquidity is provided by one address that offers significant FBTC liquidity across many chains. This address was deployed by a Mantle address. Given Mantle addresses sit on the FBTC Security Council; it is unlikely that this liquidity will disappear as it would restrict product growth. Nevertheless, this high LP concentration presents significant risk as it may be immediately withdrawn, leaving liquidators unable to purchase and exchange FBTC collateralized in the protocol profitably.

This makes liquidity risk manageable in the short term but considerable if it does not improve in the future.

2.2 Volatility

Source: FBTC/WBTC via Coingecko Terminal , 25 November 2024

This asset has kept a tight peg on the value of underlying collateral.

2.3 Exchanges

Source: Coingecko FBTC, 25 November 2024

This asset is available on various decentralized exchanges, especially on Mantle. The majority of liquidity on Mainnet is paired to WBTC and held in one pool. This presents some degree of concentration risk in a black swan event. Liquidators may struggle to profitably buy collateral and swap it if the WBTC/FBTC pool goes out of range of the configured LP tick. Notably, no centralized exchanges are trading FBTC.

2.4 Growth

Source: FBTC/WBTC via Coingecko Terminal, 25 November 2024

FBTC has enjoyed limited growth when denominated in BTC prices. 2 BTC have been added to its market cap, an increase of 0.2% in BTC terms. Nevertheless, in USD terms, the asset has grown by ±$23,000,000.

3. Technological Risk

3.1 Smart Contract Risk

This asset has been audited three times. Neither BlockSec, MixBytes, nor Secure3 found any high or critical issues. This indicates a team with robust development practices, reducing smart contract risk.

No bug bounty is currently active. The Ignition team is working to have one running through ImmuneFi by mid-December. It will, on launch, be $100K for critical smart contract findings and Ignition reports. This is likely to increase as FBTC grows in adoption.

3.2 Price Feed Risk

An FBTC/BTC exchange rate Chainlink Feed is available. This robust oracle posts the exchange rate of BTC to FBTC onchain for smart contracts. Given its onchain, verifiable, programmatic data source, it is more robust than any web2-based pricing solution.

Chainlink Proof of Reserves verify that the asset is more than 1:1 backed, but this does little to price the asset in dollar terms. It is not enforced at minting. It functions through Blocksec, an onchain security firm that counts the amount of BTC held in FBTC contracts. This is shared to Chainlink via an API, with 10 nodes then posting this data to an aggregator contract. It introduces a dependency on Blocksec attesting the correct ratio of Bitcoin.

Given that all mainnet liquidity is paired with WBTC in a Uniswap pool, this is not a suitable oracle. An exchange rate oracle may be used in line with other wrapped Bitcoin assets on Aave. This presents some friction for liquidations should “qualified users” not be able to redeem / mint the asset and, therefore, risk.

3.3 Dependency Risk

This system has a variety of dependencies:

• Architectural
  Significant technological dependencies exist in this system architecture, including Threshold Signature Schemes, Bridge Monitors, and Bridge Contracts. The system may function in an unintended way if any of them fail.
• Custodian
  This Bitcoin is custodied on Bitcoin chain. This introduces custodian risk.
• MPC
  EVM chain contracts are managed by Cobo MPC wallet. This introduces a dependency on the continued operation of this wallet. Many assets use this MPC solution.
• PoR
  FBTC benefits from the continued operation of the Chainlink PoR. Our eyes believe its continued operation is necessary for this asset’s maintenance.
• Qualified users
  “Qualified users” are a significant dependency in this system. Given the difficult nature of becoming one, few will achieve this status. This results in a concentration of those able to mint / burn / transfer the asset, potentially reducing FBTC velocity. The FBTC system is dependent on these qualified users.

While these dependencies present risk, they are not so great that we cannot recommend onboarding the asset.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

This asset has no onchain governance. Ignition has yet to make plans to decentralize asset management. Should these change, Ignition has indicated that they will inform LlamaRisk (who will monitor this matter).

Instead, the asset is entirely managed by Ignition. This team is largely based in Singapore and Hong Kong. Singapore, which is known for being one of the more forward-thinking cryptocurrency regulatory regimes, has no existing DeFi specific laws. Nonetheless, Singapore’s Monetary Authority (MAS) is paying more attention to decentralized finance—uncertainty stemming from limited clarity results in risk.

Hong Kong is likewise similarly unclear on Decentralized Finance legislation. While not the most hostile jurisdiction to cryptocurrency activity, limited clarity on this issue in Hong Kong once more introduces regulatory risk.

A security council consisting of Cobo, Mantle, and Antalpha Prime currently runs TSS nodes and is responsible for Bitcoin custody MPC utilizing contracts. This introduces additional counterparty risk. It is worth mentioning that Cobo and Mantle are established DeFi actors with a long history of good faith contributions. Antalpha Prime appears to be in part owned by BITMAIN and ANTPOOL, both Chinese cryptocurrency mining entities collectively responsible for >25% of Bitcoin’s hash rate. This introduces risk driven by these entities’ obscurity, mitigated by the clear council power limits detailed in protocol documentation. This security council is expected to grow in membership, presenting further uncertainty risk.

4.2 Access Control Risk

The FBTC system employs a 5/8 GnosisSafeProxy ownership model across its core contracts with significant permissions:

FBTC Contract Powers:

• Pause functionality
• Qualified user management
• Ownership transfer
• FBTC rescue capabilities
• Fee structure modifications
• Parameter adjustments

Bridge Contract Powers:

• Qualified user management
• Contract pausing
• Fee parameter control
• Ownership transfer
• Self-upgrade capability

Minter Contract Powers:

• Role management
• Mint request confirmation
• Ownership transfer
• Bridge address modification
• Self-upgrade capability

The Safe signers include several addresses associated with the Mantle deployer and ecosystem partners. While the system clearly documents roles and permissions, it lacks timelocks and concentrates significant control in a single Gnosis Safe.

This introduces centralization risk - a compromise of sufficient signer addresses could affect the entire system. While the 5/8 threshold provides some security, the concentration of critical permissions in one Safe presents notable risks. Therefore, the access control risk is high but actively managed through multi-signature requirements.

Note: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V3. This framework is continuously updated and available here.

Aave V3 Specific Parameters

We will present joint parameters recommendations with @ChaosLabs. LlamaRisk suggests parameters aligned with other, growing wrapped BTC assets, with some LT/LTV premium accounting for the centralized and developmental ownership.

Price feed

Like tBTC and cbBTC, we propose using the BTC/USD Chainlink feed as a price oracle. This is the most reliable, decentralized solution available, and that will provide accurate pricing in times of stress.

Disclaimer

This review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.

The information provided should not be construed as legal, financial, tax, or professional advice.

[TokenLogic]

@TokenLogic supports the proposed integration of FBTC into the Core instance of Aave v3. After spending some time discussing the near term roadmap for FBTC with Ignition, we present some other considerations complimentary to the risk analysis provided by LlamaRisk and Chaos Labs.

We expect the following from onboarding FBTC:

• Over 300M stablecoin debt at competitive market rates;
• Incentives for users who deposit FBTC;
• Enhance liquidity upon ByBit listing; and,
• Ignition Aave deployment with stablecoin supply.

Provided reasonable borrowing conditions exist, we expect strong FBTC adoption on the Core Market.

There exists considerable upside via deploying a dedicated instance of Aave that has both stablecoin liquidity and FBTC commitments being progressed. Further details are to emerge when the TEMP CHECK is submitted for governance consideration.

Click me

Stablecoin Demand

Based upon feedback from various FBTC holders, we anticipate FBTC to generate over $300M in stablecoin demand across USDC, USDT, USDS and GHO. This is subject to Aave Protocol being able to offer liquidity at competitive borrow rates.

Engaging with some players in the mining industry has highlighted the potential for Aave’s deployment to foster significant adoption within the mining community. These entities often have a consistent demand for borrowing USD to cover operational expenses, presenting an opportunity for Aave to cater to a substantial and reliable source of borrowing activity. This alignment between Aave’s offerings and the financial needs of the mining sector positions it as a valuable tool for miners, potentially driving broader retail adoption.

Note: The continued success of sUSDe may lead to short term elevated borrowing rates that dampen the immediate upside of FBTC. sUSDe is expected to be a strong catalyt for higher borrow rates in the forseeable future.

Roadmap and Strategic Integration

ByBit is expected to onboard FTBC as early as Q1, 2025. This integration will ensure seamless minting and burning operations via deposit and withdrawals. The integrations mirrors Coinbase’s approach for DeFi liquidity. We expect FBTC’s liquidity to benefit greatly from this integration.

Users depositing FBTC on ByBit will immediately burn FBTC in exchange for BTC, while withdrawals will automatically mint FBTC to their wallets. This streamlined process significantly enhances liquidity and enhances the pegged nature of FBTC.

In the meantime, we are expecting additional liquidity to be deployed on-chain to support the Aave listing. This is most likely via Maverick v2 or ECLPs on Balancer v2 via Gyroscope.

FBTC Deposit Demand

Ignition has committed to providing incentives on FBTC deposits. Aave Protocol users are to receive a premium relative to other DeFi integrations. With additional incentives and liquidity, this combination is expected to deepen engagement with institutional participants. This arrangement grants Aave a commanding position in the lending vertical as the cornerstone for FBTC activity.

FBTC Borrowing Demand

A catalyst for FBTC borrowing demand is the ability for Babylon to receive FBTC deposits. Any previous challenges relating to custody of the underlying has been resolved and the integration is progressing. This use case has the potential to drive meaningful demand for FBTC and is expected to support the business case for deploying an instance of Aave protocol with Prime market like growth prospects.

Future Considerations

A dedicated instance of Aave Protocol to facilitate:

• Stablecoin liquidity sourced by Ignition;
• Ignition aligned LRT borrow demand; and,
• Pendle PTs benefiting from points and LRT derived yield.

Note: The liquidity sourced from Ignitions partner(s) is conditional upon exclusively being back by FBTC collateral. This is a barrier preventing stablecoin from being deposited in the Core market to support FBTC collateral holders.

Engagements with the BTC mining community highlight a significant opportunity to align Aave’s offerings with their financial needs, leveraging consistent demand for liquidity to drive sustained value and foster a mutually beneficial relationship.

[EzR3aL]

Given the information from @TokenLogic there seems to be a chance for the DAO to capture some good revenue with fBTC and maybe a dedicated market for Ignition.
Although the DAO is currently voting on having a 3 instance based system, if there are good reasons to create a market outside of this I would be fine. As long as the rationale behind it is good enough to justify it towards the DAO.

[ChaosLabs]

Overview

Chaos Labs supports listing FBTC on Aave V3’s Ethereum Main instance. Below is our analysis and initial risk parameter recommendations.

Technical overview

FBTC is a BTC wrapper by Ignition that allows holders to participate in DeFi activities. As described in its documentation, the token is minted by users depositing native BTC to a custodial address (each “qualified user” is assigned their own) and initiating a mint request with the Bridge contract; the Bridge Monitor then detects the minting request and sends the request to the TSS Gateway, which initiates a contract to confirm minting, after which, TSS Nodes (using independent risk control systems) co-sign using the MPC algorithm to create a transaction signature. Following these procedures, the FBTC token is minted. Redemptions work in a similar, reversed flow, as shown below.

Overview | FBTC

The FBTC protocol employs custodial addresses, managed through Multi-Party Computation (MPC) and Multi-Signatures, to maintain the security of the assets backing FBTC. The protocol also utilizes Chainlink’s Proof of Reserves (its total native BTC backing, including FBTC1), which can be found here for Ethereum. This aims to provide real-time verification of reserve assets.

FBTC employs a different fee structure based on the type of operation. Minting FBTC incurs no fee (0%), with an average request completion time of approximately 4 hours. In contrast, burning FBTC is subject to a variable fee structure that starts at 0.2% and decreases for larger amounts, alongside a flat fee of 0.01 FBTC. Burn requests typically take significantly longer to process compared to minting, making arbitrages of a downside deviation impractical. For cross-chain transfers between EVM-compatible networks, a fixed fee of 0.0001 FBTC is applied, enabling cost-efficient arbitrage opportunities across chains.

The token contract on Ethereum is currently controlled by a 5-of-8 Gnosis Safe multisig. Since September, the multisig has only completed one transaction, adding destination chains to the FireBridge contract, which also maintains the qualified users’ list.

FBTC Backing Exposure

There are two forms of the asset: FBTC0 and FBTC1; the two assets represent circulating and deposited assets, respectively. FBTC0 is the standard, fully liquid FBTC token backed 1:1 by BTC in Ignition’s custody. Conversely, FBTC1 represents FBTC that has been deposited into a protocol, effectively transferring custody of the underlying BTC to the protocol’s strategy address. This conversion occurs when a user deposits FBTC into a protocol (e.g., Avalon, Pump, Solv), which withdraws the corresponding Bitcoin from the FBTC contract to its strategy. FBTC1, therefore, is not “locked” in the traditional sense; rather, it serves as a representation of the protocol’s BTC owed to the FBTC ecosystem. When users withdraw their FBTC from the protocol, the underlying Bitcoin must be returned to the FBTC contract, converting FBTC1 back to FBTC0. This design makes FBTC1 a dynamic measure of FBTC utilized in DeFi protocols, indirectly reflecting protocol adoption and TVL.

Thanks to the dynamic mint and burn flow of FBTC1, the risks stemming from the partners’ contracts are isolated from the FBTC0 token. During a hack of a partner protocol, if the underlying BTC is stolen, the partner protocol is unable to convert the FBTC1 back to FBTC0, hence not inflating the FBTC supply relative to the backing. Meanwhile, if the partner’s Ethereum contracts get hacked, the FBTC1 is likely to be the asset stolen, which cannot be redeemed to FBTC0 without having control of the underlying BTC assets in the partner’s strategy address.

On the other side, this dual-token system offers significant benefits to FBTC, ensuring that the supply deposited into partners’ vaults, such as restaking, does not get redeemed and converted to a different wrapped BTC asset prior to the redemption from the users.

This ARFC is intended to onboard FBTC0, and currently, the plurality of FBTC0 are on Ethereum, followed by Mantle. While FBTC1 is deposited into DeFi protocols, it still represents accessible TAM for the Aave protocol.

Market Cap and Liquidity

FBTC’s market cap has grown consistently on Ethereum since September 2024. While the FBTC0 supply on the chain has remained stable, fluctuating between 1200 and 385, the FBTC deposited into DeFi protocols (FBTC1) has shown strong growth, reaching a peak of 8100 FBTC.

The entirety of the asset’s liquidity is concentrated within 2 WBTC/FBTC Pools on Uniswap V3. Both pools are recognized by Odos, although the 0.01% WBTC/FBTC pool is the largest and facilitates the vast majority of volume.

Simulated 150 FBTC for USDC swap; Odos.

This 0.01% pool is currently skewed, with 100.76 WBTC and 27.67 FBTC, indicating sufficient liquidity for FBTC. The 0.3% pool, on the other hand, has just 0.99 WBTC and 87.66 FBTC.

Overall, the asset maintains a total TVL of $20M between the two pools, of which $10M is in WBTC buy-side liquidity. The DEX liquidity of FBTC is increasing steadily, even though the asset’s liquidity is provided by a singular entity that we were able to identify as Ignitia. Its average daily trading volume across all venues over the last 180 days was $26.7M.

Volatility

Relative to BTC, FBTC has a 30-day annualized volatility of 7.96%, down from 12.14% over the past 180 days.

This is slightly high for a pegged asset, though the decreasing volatility is a positive sign that the asset’s pricing is improving even as BTC volatility has increased. FBTC has displayed no persistent discounts relative to WBTC in its primary Uniswap pool.

LTV, Liquidation Threshold, and Liquidation Bonus

Given the volatility relative to BTC, we recommend a Liquidation Bonus of 7.5%, an LTV of 73%, and an LT of 78%, aligned with other BTC wrappers like cbBTC on Base.

Supply and Borrow Cap

Chaos Labs’ typical approach to setting initial supply caps involves setting the supply cap to 2x the liquidity available under the Liquidation Bonus. This leads us to a recommendation of 200 FBTC, more than 50% of supply on Ethereum. While we normally would not recommend setting it higher than 50%, the fact that FBTC1 can be burned into FBTC0 means that the asset’s “true” on-chain supply is significantly higher than the 390 FBTC figure.

Thanks to its prolific utilization within restaking protocols, FBTC represents a prime asset for borrow demand to be utilized within the DeFi ecosystem. Hence, we recommend setting a borrow cap of 50% of the proposed supply cap.

Interest Rate Curve

Given the current absence of BTC LRTs on Aave, we anticipate limited initial demand for FBTC. As such, we recommend setting the UOptimal at 45% to reflect expected utilization rates, with plans to increase this value following the listing of additional BTC assets.

Additionally, we suggest aligning the Interest Rate Curve for FBTC with that of WBTC, as the two assets are expected to exhibit comparable demand dynamics.

Oracle Configuration/Pricing

Below is a chart of the FBTC/BTC Chainlink exchange rate, showing numerous surges in the exchange rate likely derived from minting and burning delays in which FBTC’s reserves exceed its supply. The spikes make this exchange rate infeasible to use, as users borrowing the asset could be liquidated in the event of an exchange rate spike that is not indicative of the asset’s value changing.

Given all the risks outlined previously in this post and the unfeasibility of using the FBTC/BTC Chainlink exchange rate, it is preferable to price the asset using the BTC/USD market oracle.

Specification

Following the above analyses, we have aligned with @LlamaRisk on the following parameter recommendations:

Parameter	Value
Network	Ethereum
Isolation Mode	No
Borrowable	Yes
Collateral Enabled	Yes
Supply Cap	200
Borrow Cap	100
Debt Ceiling	-
LTV	73.00%
LT	78.00%
Liquidation Bonus	7.50%
Liquidation Protocol Fee	10%
Variable Base	0.0%
Variable Slope1	4.0%
Variable Slope2	300%
Uoptimal	45%
Reserve Factor	50%
Stable Borrowing	Disabled
Flashloanable	Yes
Siloed Borrowing	No
Borrowable in Isolation	No
E-Mode Category	N/A

Disclaimer

Chaos Labs has not been compensated by any third party for publishing this ARFC.

Copyright

Copyright and related rights waived via CC0

[ACI]

Thank you @LlamaRisk and @ChaosLabs .

We have escalated the proposal to ARFC Snapshot.

Vote will start tomorrow, we encourage everyone to participate.

[ACI]

After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching both Quorum and YAE as winning option, with 383K votes.

Therefore, the [ARFC] Add FBTC to Aave v3 Main Market on Ethereum has PASSED.

Next step will be the publication of an AIP for final enforcement and confirmation of the proposal.

[TokenLogic]

The Ignition team has communicated an initial x4 points reward will be offered to Aave users and has asked for the fBTC and wBTC eMode to be created facilitating the migration of capital from other lending protocol(s) onto Aave.

Can the following eMode be reviewed by @ChaosLabs for inclusion within the onboarding AIP submission being prepared by @ACI.

Parameters	Value	Value
Asset	fBTC	wBTC
Collateral	Yes	No
Borrowable	No	Yes
Max LTV	84%	-
Liquidation Threshold	86%	-
Liquidation Bonus	3.00%	-

Based upon initial feedback, we expect the proposed Supply Cap to be filled early on and will requiring increasing soon after fBTC has been onboarded.

Edited: 23/04/2025

[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.

[artk42]

@bgdlabs

Miscellaneous

• The BTC custody through MPC is secured by a security council composed of Antalpha Prime, Mantle, and Cobo entities.

The entire BTC treasury backing the asset is unilaterally controlled by “Antalpha Prime, Mantle, and Cobo entities”. A few words on how this control is structured and protected from failures and conflicts of interests might be useful.

[bgdlabs]

Hello @artk42.
Antalpha Prime, Mantle, and Cobo are participants in the MPC (MultiParty-Computation) TSS (Threshold Signature Scheme) off-chain mechanism that handles the bridging Bitcoin ↔ Ethereum (exact description here).
Additionally, aside from their participation in TSS itself, Cobo’s MPC wallet technology is used (more details here).

Regarding structuring/conflict of interest, we defer to the description on that side by @LlamaRisk previously on this thread, and would recommend asking them if any extra information is required.