- Uses a port of the EVM for its contract runtime
- Does not have a native gas currency
keccak256(bitcoin_pkscript).slice(-40), which creates addresses that have no corresponding private keys. These addresses look like standard Ethereum addresses but cannot produce signatures verifiable by ecrecover. This affects:
- Multisig wallets and contract-based accounts
- Meta-transactions and gasless transaction patterns
- EIP-712 typed signatures (used throughout DeFi)
- Account abstraction schemes (ERC-4337)
- Standard
permit()functions on tokens
0xfe, but this requires rewriting any contract that performs signature verification. Existing Ethereum contracts, including widely-used protocols like Uniswap, Aave, and Safe, therefore need substantial modification to work in BRC2.0. The pattern of using ecrecover to verify signatures must be replaced with calls to the custom precompile. This means the benefit of leveraging existing Ethereum codebases is difficult to realize. Wallet integration also requires different infrastructure. Users cannot use MetaMask or standard Web3 wallets; they need Bitcoin wallets supporting BIP-322 signing, but this standard has very limited support.
Beyond the compatibility issues, the EVM’s 256-bit stack-based architecture and Solidity’s design choices create different trade-offs than WebAssembly-based systems. The EVM was designed for Ethereum’s specific constraints in 2015, while WebAssembly emerged only later as a portable compilation target for broader industry adoption.