The Code Does Not Lie: Why 'Bitcoin Layer 2' Project X Is Just a Rebranded Ethereum Sidechain

The code does not lie; only the founders do.

Yesterday, I spent four hours decompiling the bridging contract of "Project X," a heavily marketed "Bitcoin Layer 2" that raised $12 million in a private round last month. The git commit history is pristine. The documentation is glossy. The Twitter timeline is full of "BTC scalability" and "ordinals compatibility."

Then I found the constructor. The contract deploys a standard ERC-20 token, uses a Merkle proof that mirrors Optimism’s old fraud proof scheme, and writes to a state root that has no on-chain verification against the Bitcoin main chain.

Zero.

Not a single SPV proof. Not a single bit of script.

I don’t trust the audit; I trust the gas fees.

Context — The industry is hungry for a narrative. After the Ordinals explosion in 2023, every VC portfolio manager started asking "where is the Bitcoin DeFi play?" The answer, predictably, came from Ethereum developers who just changed the name of their smart contract from "L2Bridge.sol" to "BTCBridge.sol" and swapped the chain ID in their Hardhat config. Project X is the poster child: a team of three former Solidity devs, no Bitcoin core experience, and a roadmap that promises "trustless BTC peg" by Q3 2025.

The hype is deafening. Over the past 7 days, a protocol lost 40% of its LPs on Ethereum, but Project X’s TVL jumped to $240 million, almost entirely from a single whale deposit of a wrapped asset. My forensic rule: if the TVL graph looks like a hockey stick with a single node, you are looking at a rug prepped or a custodial honeypot.

Core — Systematic teardown of the bridge contract.

1. No on-chain verification. The contract stores a bytes32 currentRoot variable. The only function that updates it is setRoot(bytes32 _newRoot), callable by a single EOA address labeled "admin." There is no challenge period. No watchtower. No Bitcoin script verification. The admin can set any root at any time. This is a multi-sig with a single key.

1. Peg-in mechanism. Users send BTC to a custodial address controlled by the team — there is no on-chain lock. The contract then mints an ERC-20 token called "xBTC" with a 1:1 ratio. The mint function has a onlyAdmin modifier. The team can mint unlimited tokens at any time.

1. Peg-out mechanism. Users burn xBTC on the contract. The event WithdrawalInitiated is emitted. Then the admin must manually release BTC from the custodial address. There is no automated path. The contract does not even check that the BTC has been sent.

1. Reentrancy? Yes. The withdraw function calls safeTransfer to the user before decrementing the balance. The balance never checks for a valid BTC destination address. An attacker can reenter and drain the minted supply. I tested this on a local fork. It works.

Based on my audit experience in 2018, when I found a reentrancy in a token sale contract that allowed draining 40 ETH, this exact pattern was considered a rookie mistake. Today, it is either negligence or malice. I do not distinguish.

1. Incentive structure. The team earns a 0.5% fee on every peg-in. They earn nothing on peg-out. This is a one-way bet: the longer BTC stays locked in their custodial wallet, the more they earn. Why would they ever allow peg-out?

The rug was pulled before the mint even finished.

Contrarian — What the bulls got right.

I am not a nihilist. The user experience is smooth. The frontend is polished. The bridging process takes less than 30 seconds. The TVL is real — the whale deposited actual BTC into the custodial wallet. The team also implements a "rate limiter" that caps daily withdrawals at $500,000. This is a smart social engineering trick: it creates a false sense of security and limits the initial run.

But let’s be clear: a custodial bridge with a single admin key and no verification is not a Layer 2. It is a payment processor with a smart contract wrapper. The bulls are betting that the team will eventually decentralize. The code says otherwise.

Takeaway — The Bitcoin community does not acknowledge these projects. The real Bitcoin Layer 2s — like the Lightning Network or RSK — are built on different primitives: time locks, taproot, and merge mining. Project X uses none of these.

I have seen this before. In DeFi Summer, I stress-tested Compound’s interest rate model and found a rounding error that could cause insolvency. The devs ignored it to focus on liquidity mining. The same trade-off is happening here: speed and hype over security.

Reentrancy is not a bug; it is a feature of trust.

If you hold xBTC, sell it. If you are considering investing, read the contract yourself. The code does not lie. Only the founders do.

Gas fees don’t lie.