tBTC on Base — Trust Assumptions Beyond the Code
Axiom Security Base3 min read·Just now--
We scanned tBTC’s Base deployment and found no critical bugs. But what we found instead might be more important: a set of trust assumptions that determine the protocol’s security far more than any line of code.
BACKGROUND
tBTC is one of the most important Bitcoin bridges in DeFi. It allows Bitcoin holders to use their BTC on Ethereum and L2 chains like Base without selling — you deposit BTC on the Bitcoin network, and a corresponding tBTC token is minted on Ethereum or Base.
The protocol is operated by the Threshold Network, which uses a decentralized signer group to custody the bridged Bitcoin. This is a fundamentally different trust model than centralized bridges (like WBTC, which is custodied by BitGo). The security of tBTC depends not on one company, but on the economic incentives and honesty of its signer group.
The Base deployment we scanned is the token contract itself — an upgradeable ERC20 built on OpenZeppelin’s standard libraries. The bridge logic, signer management, and minting/redemption mechanisms live in other contracts that weren’t part of this specific deployment.
THE FINDINGS
Our scanner produced extensive results:
- **Slither**: 67 findings, the vast majority informational — dead code in upgradeable base contracts (by design), floating pragma, assembly usage in standard libraries (intentional optimization), unindexed event parameters
- **Aderyn**: 2 HIGH severity findings — both about upgrade authority concentration
- **Mythril**: Failed due to Solc parser error
The 2 HIGH findings from Aderyn are notable because they’re not code bugs. They’re structural observations: the upgrade authority for the proxy contract is concentrated in a single point. This is true of nearly all upgradeable contracts, but it’s worth flagging because it means the contract’s behavior can be changed post-deployment.
Coverage was limited to 15.4% of source (15,502 of 100,683 characters) — primarily the OpenZeppelin base contracts were analyzed. The core tBTC business logic (Bitcoin bridge implementation, signer management, minting/redemption) was not available for review.
TECHNICAL DEEP DIVE
The contract uses OpenZeppelin’s `TransparentUpgradeableProxy` pattern:
```solidity
// The proxy delegates all calls to an implementation contract
// The admin can change the implementation at any time
// This means ALL contract logic can be swapped post-deployment
```
This is standard practice for bridge tokens that need to be upgradeable. But it creates a critical trust dependency: whoever controls the proxy admin key controls the contract entirely. They could:
- Change the minting logic to mint unlimited tokens
- Modify the redemption logic to prevent withdrawals
- Add a blacklist function
- Alter transfer mechanics
Our scanner flagged several uncertain findings (AXM-011, AXM-012) that we couldn’t verify without the full implementation contract:
- Whether `_disableInitializers()` was called in the implementation constructor (prevents reinitialization attacks)
- Whether the storage layout has collisions across the full inheritance chain
LESSONS LEARNED
1. **Trust assumptions matter more than code quality for bridges.** The tBTC token contract is well-written. The OpenZeppelin libraries are battle-tested. But the protocol’s security depends on: honest signers, accurate bridge relay, sound upgrade governance, and responsible pause guardians. No automated tool can verify these.
2. **Upgradeable contracts need continuous monitoring.** A bridge token that’s safe today can be changed tomorrow if the upgrade keys are compromised. Regular screening after every upgrade is essential — not just once at deployment.
3. **Limited coverage doesn’t mean limited value.** We analyzed 15.4% of the source, yet identified the most critical structural risk: upgrade authority concentration. Sometimes the most important findings are architectural, not in the code details.
4. **Automated screening and manual audit serve different purposes.** Automated tools catch structural patterns — access control, upgrade risks, common vulnerabilities. Manual audits verify bridge-specific logic — signer incentives, redemption mechanics, cross-chain communication. Both are needed.
Regular screening after every upgrade. Full report at axiom-security.vercel.app.
