Onboard CbBTC on Mainnet and Base
01Summary
Proposal to onboard Coinbase's cbBTC (wrapped Bitcoin) to Aave v3 protocol on Ethereum Mainnet and Base network. cbBTC will be enabled as a borrowable collateral asset with 73% LTV, supply caps of 450 cbBTC on Ethereum and 200 on Base, and configured risk parameters matching standard practices for wrapped Bitcoin assets.
- Type
- protocol addition
Key changes
- Add cbBTC as borrowable collateral asset on Ethereum Mainnet with supply cap of 450 cbBTC and borrow cap of 45 cbBTC(high)
- Add cbBTC as borrowable collateral asset on Base with supply cap of 200 cbBTC and borrow cap of 20 cbBTC(high)
- Configure cbBTC with 73% LTV, 78% liquidation threshold, 7.5% liquidation bonus, and 20% reserve factor on both networks(high)
- Enable flash loan functionality for cbBTC on both networks(medium)
- Disable stable borrowing and siloed borrowing for cbBTC(medium)
Notable concerns
- No debt ceiling configured (USD 0), allowing unlimited isolation mode exposure if parameters change
- Relatively high variable slope 2 (300%) creates steep borrowing costs at high utilization
Generated by Kvorum
02Description
Simple Summary
The proposal aims to onboard Coinbase’s cbBTC, to the Aave v3 protocol on Mainnet main instance & Base.
Motivation
cbBTC, a new Bitcoin wrapper offering from Coinbase, is marking Coinbase’s entry into the wrapped Bitcoin market with cbBTC brings a unique value proposition to the Aave ecosystem.
This new asset will diversify the options available for Bitcoin holders looking to participate in DeFi activities on Aave v3.
Furthermore, cbBTC’s integration aligns with Aave’s commitment to offering a wide range of high-quality assets. It will enable users to tap into Coinbase’s liquidity and reputation while benefiting from Aave’s established lending and borrowing functionalities. This synergy between a major centralized exchange and a leading DeFi protocol could attract more mainstream users to Aave, contributing to the overall growth and adoption of the platform.
Specification
The table below illustrates the configured risk parameters for cbBTC on Ethereum main pool and Base pool:
| Parameter | Ethereum Main Pool | Base Pool |
|---|---|---|
| Isolation Mode | false | false |
| Borrowable | ENABLED | ENABLED |
| Collateral Enabled | true | true |
| Supply Cap (cbBTC) | 450 | 200 |
| Borrow Cap (cbBTC) | 45 | 20 |
| Debt Ceiling | USD 0 | USD 0 |
| LTV | 73 % | 73 % |
| LT | 78 % | 78 % |
| Liquidation Bonus | 7.5 % | 7.5 % |
| Liquidation Protocol Fee | 10 % | 10 % |
| Reserve Factor | 20 % | 20 % |
| Base Variable Borrow Rate | 0 % | 0 % |
| Variable Slope 1 | 4 % | 4 % |
| Variable Slope 2 | 300 % | 300 % |
| Uoptimal | 45 % | 45 % |
| Stable Borrowing | DISABLED | DISABLED |
| Flashloanable | ENABLED | ENABLED |
| Siloed Borrowing | DISABLED | DISABLED |
| Borrowable in Isolation | DISABLED | DISABLED |
| Oracle | 0xF4030086522a5bEEa4988F8cA5B36dbC97BeE88c | 0x64c911996D3c6aC71f9b455B1E8E7266BcbD848F |
References
- Implementation: AaveV3Ethereum, AaveV3Base
- Tests: AaveV3Ethereum, AaveV3Base
- Snapshot
- Discussion
Copyright
Copyright and related rights waived via CC0.
03Mismatch analysis
The proposal description provides a detailed specification for onboarding cbBTC on both Aave v3 Ethereum and Base pools, including numeric risk parameters and oracle addresses. However, the decoded on-chain action set contains only a single generic execute() (fallback) call to a payload contract on Ethereum, with no decoded arguments. This is the standard pattern for Aave governance proposals, where a dedicated payload contract encapsulates the actual listing logic (including any cross-chain calls to Base), so the absence of visible parameters in the calldata is expected and not inherently suspicious. However, because the calldata is opaque, I cannot verify that the specific numeric parameters (LTV, LT, caps, oracle addresses, etc.) in the description match what the payload contract actually sets. There is no evidence of a target mismatch, value mismatch, or extra/omitted action beyond this inherent opacity. Given the well-known convention of Aave governance execute() payloads and no visible red flags, I assess the proposal as consistent, but with low confidence since the calldata does not expose enough detail to fully corroborate the description's specific figures.
Discrepancies
- lowomitted in description
The decoded action list only shows a single execute() call on an Ethereum-based payload contract, with no visible parameters or a separate action targeting Base. Since Aave's governance payload pattern typically encapsulates all listing logic (including cross-chain calls to Base) inside the target contract's bytecode, this is not necessarily a real discrepancy, but it means the specific risk parameters (LTV, caps, oracle addresses, etc.) claimed in the description cannot be independently verified from the decoded calldata alone — the execute() call has no decoded arguments to compare against.
Generated by Kvorum
04Actions
- Target
- 0x9eda…af21
- 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 tBTC to Aave v3 on Base83%
- aaveexecutedOnboard BTC.b to Aave V3 Core Instance83%
- aaveexecutedCore & Base - BTC Correlated Asset Update83%
- aaveexecutedOnboard Tbtc82%
- aaveexecutedAdd cbETH to Aave V3 Ethereum81%
- aaveexecutedAddition of cbBTC/Stablecoin E-Mode to Aave V3 Base Instance81%
- aaveexecutedAdd FBTC to Aave v3 Main Market on Ethereum80%
- aaveexecutedOnboard eBTC and Add eBTC/WBTC E-Mode79%
- aaveexecutedOnboard LBTC & Enable LBTC/WBTC liquid E-Mode on Aave v3 Core Instance79%
- aavecanceledOnboard eBTC and Add eBTC/WBTC E-Mode78%