[ARFC] Deploy Aave V3 to MegaETH

Governance New Market
34

MegaETH BTC.b Asset Review

Summary

LlamaRisk supports onboarding BTC.b to the MegaETH instance with conservative initial parameters and a monitoring posture until liquidity and organic market depth mature. BTC.b is presented as a 1:1 BTC-backed bridged BTC representation with publicly described PoR monitoring, and the bridging architecture is built around a separation of concerns between the user-facing token contract and the cross-chain issuance stack. The audit review reported no critical or high-severity findings, and all identified issues were resolved, while Lombard also maintains an active Immunefi bug bounty. Governance and access control are clearly defined and operationally constrained via an AdminProxy multisig (3/5) and a 24-hour on-chain timelock for administrative actions on MegaETH. The Lombard team plans to seed approximately $2–3M in initial liquidity at launch and subsequently scale this up to around $10M.

The post will be amended with the regulatory and legal screening section once Lombard completes the clarification request posed internally.

Collateral Risk Assessment

1. Asset Fundamental Characteristics

1.1 Asset

BTC.b is Lombard’s bridged Bitcoin asset designed for multi-chain DeFi use. It is positioned as a permissionless BTC-onchain bridge, where users can mint by depositing BTC on Bitcoin, after which BTC.b is issued on supported EVM chains, with each BTC.b being 1:1 backed by native BTC and the backing published on-chain using Chainlink Proof of Reserve, with an additional verification component via Cubist Bascule.

1.2 Architecture

Lombard positions BTC.b as a 1:1 BTC-backed bridged Bitcoin asset that is always redeemable for BTC, with reserve verification presented through its Proof-of-Reserve framework and product feeds; the PoR page states a verified reserves ratio of 1 BTC.b to 1 BTC. Lombard’s product page highlights a fixed-fee model with a zero minting fee and a redemption fee of 0.0001 BTC. The minimum minting amount is 0.0002 BTC with no maximum.

image
image1345×727 60.8 KB

Source: Lombard, January 26, 2026

Key smart contracts:

  • BTC.b: ERC-20 representing BTC exposure on MegaETH.
  • AssetRouter: Handles deposit/redemption orchestration and fee accounting.
  • BridgeV2: Bridge execution contract for burn-and-mint transfers.
  • LombardTimelock: OpenZeppelin 24 hours TimelockController.
  • LombardTokenPoolV2: Chainlink CCIP TokenPool integration that acts as the CCIP-facing gateway into BridgeV2.

BTC.b on MegaETH follows a layered design where the BTC.b token is the user-facing ERC-20 representation, while cross-chain issuance is handled by the bridging stack. AssetRouter acts as the canonical entry point to initiate deposits/redemptions and route payloads, BridgeV2 enforces the core burn-and-mint bridging logic and finalizes mints only upon accepted inbound messages, and LombardTokenPoolV2 provides the CCIP-facing transport adapter on Ethereum that translates CCIP lock/burn and release/mint flows into BridgeV2-compatible deposit/finalization operations.

Lombard’s architecture is split across five components: the Lombard Ledger (a CometBFT-based chain) operated by a Security Consortium is the system-of-record for deposits, mints, redemptions, and cross-chain transfers, and actions require approval from two-thirds of consortium members; BTC deposits are considered valid after 6 confirmations. Cubist CubeSigner provides HSM-backed signing where key material is not exposed to operators and signing is constrained by policy. Cubist Bascule Drawbridge performs independent verification: it verifies BTC deposits prior to mint authorization and, for withdrawals, verifies that tokens were burned before authorizing BTC payout (reverse verification).

image
image1920×1080 136 KB

Source: Lombard, January 27, 2026

Onchain, BTC.b contracts implement minting/redemption and Chainlink CCIP integration for cross-chain transfers, with administrative safety controls (e.g., pause and timelocked two-step upgrades). A Trustless Relayer automates monitoring and execution steps but is limited to operational roles.

1.3 Tokenomics

Given the closed private mainnet deployment of BTC.b on MegaETH, the current on-chain circulation remains limited, with total supply presently around 0.002 BTC.b.

1.3.1 Token Holder Concentration

image
image1544×775 75.3 KB

Source: BTC.b token holders, January 27, 2026

2. Market Risk

2.1 Liquidity

DEX liquidity for BTC.b on MegaETH has not yet been established. The Lombard team plans to seed approximately $2–3M in initial liquidity into USDm/BTC.b pools at launch. The DEX venues that BTC.b will initially be deployed are to be confirmed.

3. Technological Risk

3.1 Smart Contract Risk

The bridge codebase (BridgeV2, BTC.b contracts, and associated CCIP pool components) was reviewed by OpenZeppelin on October 24, 2025, including the adapter layer used for non-standard assets. During the audit process, 16 issues in total were found (all resolved)—0 critical, 0 high, 4 medium, 5 low, and 7 informational.

Medium findings (core risk themes): TokenPool deployment may fail if a token does not implement decimals(); destination-token configuration is not cross-checked between Pool contracts and Bridge mappings (mismatch risk); an unnecessary infinite approval increases potential blast radius; and limited deposit input validation can lead to transfers that cannot finalize on the destination chain (stuck finalization).

Low and informational items: additional validation gaps, inconsistencies in route introspection, and documentation/maintainability cleanup (docstrings, redundant mappings, unused imports, interface signaling, security contact metadata).

3.2 Bug Bounty Program

Lombard has a public bug bounty run via Immunefi. The Immunefi listing shows rewards up to $250,000 (critical bugs are described as 10% of funds affected up to $250k, with a $50k minimum for critical).

3.3 Price Feed Risk

We recommend pricing BTC.b using the Chainlink BTC/USD market price feed.

3.4 Dependency Risk

BTC.b depends on the Bitcoin network for deposit finality and redemption settlement (including confirmation assumptions and congestion-driven delays) and also relies on Lombard’s off-chain coordination layer (the Lombard Ledger/Security Consortium and relayer operations) to correctly sequence deposit verification, mint authorization, and withdrawal processing, creating liveness and governance/operations risk if the consortium cannot reach the threshold or if relayer automation fails.

CubeSigner from Cubist

Consistent with our prior LBTC analysis, Cubist CubeSigner remains a key dependency risk for BTC.b, as it is used for remote key management and transaction signing within Lombard’s operational stack. Because CubeSigner is an offchain, SaaS-based signing system, the effective security posture depends on Cubist-managed HSM infrastructure and internal policy controls that are not fully transparent onchain; this introduces a centralization and operational availability risk relative to fully onchain controls and makes incident response and liveness partially dependent on a third-party service provider.

4. Counterparty Risk

4.1 Governance and Regulatory Risk

This section is to be completed once Lombard completes the clarification request posed internally. We will provide the legal section as a separate update in the same forum thread.

4.2 Access Control Risk

4.2.1 Contract Modification Options

The BTC.b smart contract is deployed as an upgradeable OpenZeppelin TransparentUpgradeableProxy with NativeLBTC as the implementation contract, where NativeLBTC represents BTC exposure on the EVM.

The update process, as proposed/implemented by Lombard, is that upgrades are executed through the proxy admin path of the transparent proxy pattern (i.e., the admin triggers upgradeToAndCall via the ProxyAdmin mechanism rather than upgrading in-place).

4.2.2 Timelock Duration and Function

On MegaETH, Lombard gates BTC.b administrative changes behind a 24-hour on-chain timelock. The timelock contract is implemented as an OpenZeppelin TimelockController with minDelay = 86400 seconds.

4.2.3 Multisig Threshold / Signer identity

Access control on MegaETH is centralized via a 3/5 AdminProxy for BTC.b, AssetRouter, and BridgeV2, with all sensible actions executed through this admin entity. The AdminProxy is controlled by the following signers:

LombardTokenPoolV2 is governed separately via an Ethereum mainnet 3/5 Safe admin multisig. The multisig is controlled by the following signers:

All listed signer keys are controlled by Lombard Finance team members acting in an operational/admin capacity.

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

Parameters have been agreed jointly with @ChaosLabs.

Disclaimer

This review was independently prepared by LlamaRisk, a DeFi risk service provider 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.

LlamaRisk - Monthly Community Update