Onboard BTC.b to Aave V3 Core Instance
01Summary
Proposal to onboard BTC.b (a liquid bridged Bitcoin token) to Aave V3 on the Core Instance following successful deployment on Avalanche. BTC.b will be enabled as collateral with a 73% LTV and 600 unit supply cap, but borrowing is disabled. No funding allocation is involved.
- Type
- protocol addition
Key changes
- BTC.b token onboarded to Aave V3 Core Instance as collateral asset(high)
- BTC.b collateral enabled with 73% LTV and 78% liquidation threshold(high)
- Supply cap set at 600 BTC.b units to manage risk exposure(medium)
- Borrowing disabled (0% base borrow rate, borrow cap of 1)(high)
- Flashloan functionality enabled for BTC.b(medium)
- 50% reserve factor configured for protocol revenue(medium)
Notable concerns
- Borrowing is functionally disabled despite technical configuration allowing it (borrow cap of 1)
- Migration of BTC.b from Ava Labs to Lombard infrastructure represents a dependency shift
- Risk parameters adjusted from Avalanche deployment for market conditions, specific adjustments not detailed
Generated by Kvorum
02Description
Simple Summary
This proposal seeks to onboard BTC.b to the Aave V3 deployment on the Core Instance.
As the onboarding of BTC.b has already been approved and executed on the Avalanche Aave V3 instance, this proposal follows the Direct-to-AIP path to extend BTC.b support to the Core instance.
Motivation
BTC.b is a liquid bridged Bitcoin token originally established by Ava Labs and recently transitioned to Lombard’s technical infrastructure, offering users access to native BTC liquidity while maintaining DeFi composability. The migration to Lombard’s architecture preserves token addresses, ensures full continuity for existing integrations and users, and enhances scalability and security. Its integration on Aave V3 Avalanche has proven successful in terms of risk profile and utility.
Given that BTC.b has already passed governance and risk assessments for the Avalanche Instance, and Lombard’s technical infrastructure has also been approved through onboarding of LBTC on the Core Instance, this proposal aims to onboard BTC.b to the V3 Core Instance under the same configuration parameters used for Avalanche, adjusted for market conditions where appropriate.
Specification
The table below illustrates the configured risk parameters for BTCb
| Parameter | Value |
|---|---|
| Isolation Mode | false |
| Borrowable | DISABLED |
| Collateral Enabled | true |
| Supply Cap (BTCb) | 600 |
| Borrow Cap (BTCb) | 1 |
| Debt Ceiling | USD 0 |
| LTV | 73 % |
| LT | 78 % |
| Liquidation Bonus | 7.5 % |
| Liquidation Protocol Fee | 10 % |
| Reserve Factor | 50 % |
| Base Variable Borrow Rate | 0 % |
| Variable Slope 1 | 10 % |
| Variable Slope 2 | 300 % |
| Uoptimal | 45 % |
| Flashloanable | ENABLED |
| Siloed Borrowing | DISABLED |
| Borrowable in Isolation | DISABLED |
Oracle
Additionally 0xac140648435d03f784879cd789130F22Ef588Fcd has been set as the emission admin for BTCb and the corresponding aToken.
References
- Implementation: AaveV3Ethereum
- Tests: AaveV3Ethereum
- Snapshot: Direct-to-AIP
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal follows Aave's standard 'short payload' governance pattern: the on-chain action is a single execute() call (fallback) to a payload contract address, with no decoded arguments. This is normal for Aave V3 listing proposals — the granular logic (asset listing, risk parameters, oracle configuration, emission admin assignment) is implemented inside the Solidity payload contract referenced in the 'Implementation' link, not exposed as discrete decoded calldata parameters. Because the calldata itself carries no visible parameters (LTV, caps, oracle address, emission admin address, etc.), it is not possible to directly verify each numeric or address claim in the description against the decoded action. This is a structural limitation of how Aave AIPs are decoded, not evidence of a mismatch. Given the proposal type, target contract, and function pattern are all consistent with a legitimate Aave asset-onboarding AIP, and there is nothing in the decoded data that contradicts the description, I find no basis to flag a discrepancy. However, since the calldata does not expose enough detail to confirm each specific parameter claimed in the description, confidence in this comparison is low rather than high, per guidance not to guess when granular verification isn't possible.
Generated by Kvorum
04Actions
- Target
- 0xa0c9…8a57
- Value
- 0 wei
- Function
- fallback()
- Arguments
{}- Calldata
05Tally
Summed from votes
06Voters
No votes recorded yet.
07Forum
No forum thread is confidently linked to this proposal.
08Similar proposals
- aaveexecutedOnboard Tbtc84%
- aaveexecutedOnboard CbBTC on Mainnet and Base83%
- aaveexecutedOnboard LBTC & Enable LBTC/WBTC liquid E-Mode on Aave v3 Core Instance82%
- aaveexecutedOnboard tBTC to Aave v3 on Base82%
- aaveexecutedCore & Base - BTC Correlated Asset Update81%
- aaveexecutedOnboard tBTC to Aave v3 on Arbitrum81%
- aaveexecutedOnboard eBTC and Add eBTC/WBTC E-Mode80%
- aavecanceledOnboard eBTC and Add eBTC/WBTC E-Mode79%
- aaveexecutedAdd FBTC to Aave v3 Main Market on Ethereum77%
- aaveexecutedOnboard tETH to Aave v3 Prime Instance75%