Hashi Tests with 25 Institutions: 'BTC Stays on Mainnet' - Where Should Programmability Be Written? TBC Offers Another Answer

The market is shifting from 'Should it be programmable?' to 'Where should it be programmable?'.

Written by: utxo_compiler

The Hashi testnet on Sui has launched, with over 25 institutions participating in stress testing. The goal is to allow BTC to participate in DeFi without leaving the Bitcoin network. This is not just another wrapped bridge. It marks the industry's first large-scale acknowledgment that wrapping BTC onto other chains for DeFi is no longer the preferred answer for institutions. However, the question has shifted from 'Should it be programmable?' to 'Where should programmability actually be written?'.

1. Trillions of Dormant BTC and Trust Gaps

Bitcoin's market cap exceeds $1 trillion. Spot ETFs and vault strategies have boosted institutional holdings, but the vast majority of BTC remains 'dormant'. It's not that institutions don't want to use it; they just haven't found a safe way to do so.

wBTC and cbBTC have solved the 'can be used' issue, but at the cost of bridge and custody risks. Users exchange BTC for wrapped assets, trusting a centralized custodian, and the assets leave the Bitcoin mainnet. This is not native Bitcoin finance; it's 'finance on another chain borrowing Bitcoin's name'.

Hashi's advancement lies in that when users deposit BTC, the funds enter a 2-of-2 multi-signature Bitcoin address generated for that account, ensuring that the underlying BTC does not leave the Bitcoin network. The Hashi Validator Committee (MPC) and the Guardian Layer each hold one signature, preventing any single party from moving the BTC. The Guardian Layer can also be configured for protection, allowing large or suspicious collateral movements to be delayed or intercepted.

This addresses the 'asset security' issue. But what about programmability? The assets are in Bitcoin multi-signatures, while the programmable logic is executed on Sui. This means users must trust two systems simultaneously: the security of Bitcoin multi-signatures and the execution environment of Sui. The trust and coordination costs of a dual system create a new trust gap.

A set of data illustrates the issue: the launch date of the Hashi mainnet has not yet been announced; it is currently in the stress testing phase. Meanwhile, there are over 75 L2 projects in the market attempting to answer the same question—how to turn idle BTC into a programmable financial base. However, most solutions separate assets and programmability across two chains.

2. The Real Bottleneck Is Not Speed Claims, But Whether Assets and Contracts Are Isomorphic to UTXO

Projects moving SVM onto Bitcoin L2 are claiming 'sub-second speeds'. Stacks' PoX-5 promotes 'self-custody, BTC-based yields'. Each of these directions has its value, but they all face the same structural issue: assets are in the UTXO model, while smart contracts are in the account model.

This is not a technical detail; it is a fundamental architectural divergence.

The advantage of the UTXO model lies in its parallelism and decentralization. Each transaction is independent and does not rely on global state, naturally supporting high concurrency. However, the cost is that traditional UTXO scripts have limited expressive power and cannot implement complex business logic.

The account model (EVM) has the advantage of expressive power for smart contracts. Developers can easily implement DeFi, NFTs, and lending protocols. However, the cost is that global state competition slows down transaction speeds, and gas fees soar during peak times.

Most projects choose to 'bridge' the two worlds: assets remain on the UTXO chain while contracts run on the account model chain. This creates new problems:

• Bridge risk: Assets crossing chains require trust in the bridge's verification mechanism.
• Execution risk: Contract execution results need to be fed back to the chain where the assets reside.
• Coordination costs: Consensus, confirmation times, and rollback mechanisms differ between the two chains.

Hashi keeps assets in Bitcoin multi-signatures while placing contracts on Sui. SVM L2 bridges assets into L2, with contracts on the Solana virtual machine. Stacks uses PoX to stake BTC on the Stacks chain. Each path focuses on 'wrapping' or 'bridging', with no one addressing the UTXO model itself.

3. TBC's Path: Writing Turing Completeness Directly into UTXO

TuringBitChain (TBC) has chosen a different path: not separating assets and contracts, but writing Turing-complete smart contracts directly into the UTXO model.

This is not an L2. It is a Layer-1 implementation of UTXO Turing-complete smart contracts based on Bitcoin's original protocol. The core differences lie in three components:

• OP_PUSH_META allows scripts to 'see' themselves for the first time. Scripts can read internal transaction metadata—version numbers, lock times, input/output quantities, and hash fingerprints of upstream and downstream transactions. This means scripts can answer 'Where do I come from, and where am I going?'.

• OP_PARTIAL_HASH enables scripts to 'verify' themselves. Scripts can recompute hashes segment by segment on any length of data flow within a constrained stack space. It’s not 'I trust the hash is real', but 'I have computed it segment by segment myself'.

• Layered TXID ensures that self-reflection and self-proof costs remain constant across generations. Each generation only needs to inherit the parent TXID, a 32-byte fingerprint, regardless of data carrying volume or depth. This is a 'genetic contract' under the UTXO model.

These three components collectively solve the problem of achieving EVM-level contract expressiveness without relying on global state.

Performance data supports the feasibility of this path: TBC's mainnet TPS has exceeded 13,000, with an initial block limit of 4GB, and fees decrease as user numbers grow. This contrasts with the traditional blockchain dilemma where 'the more users, the higher the fees'.

Of course, this path also has its costs. The TBC ecosystem's application scale is still in its early stages. Hashi has announced a list of over 25 institutional partners, including BitGo, Cumberland, OCC-licensed bank Erebor, and SEC-registered advisor Wave Digital Assets—these compliant products and institutional toolchains are at a maturity level that TBC currently cannot match. The learning curve for UTXO developers is real, and developers accustomed to EVM need to adapt to a new contract paradigm. As the competition heats up, TBC needs to quickly address its ecological and application layer shortcomings.

4. When 'Not Leaving the Bitcoin Network' Becomes Consensus, What’s Next?

The launch of Hashi is a signal: the market is shifting from 'Should it be programmable?' to 'Where should it be programmable?'. Institutions are no longer satisfied with wrapping assets for DeFi; they want the security anchor of native BTC while also having programmability flexibility.

TBC's assertion is that asset and contract logic should not be separated into two chains. Writing Turing completeness directly into UTXO allows transactions themselves to become carriers of state, with state transmitted along the UTXO lineage. This is not about technical showmanship; it is about solving a practical problem: when BTC becomes collateral for DeFi, every loan, liquidation, and staking contract execution should occur within the same security model as the assets.

In the future, if BTC truly becomes the underlying layer for programmable finance, the market will question: where is your programmability written? Is it written on an external VM, or is it written in the UTXO itself?

The 25 institutions are testing the feasibility of 'not leaving the Bitcoin network'. TBC is testing the programmability of 'not leaving the UTXO model'. Both paths are answering the same question, but the depth of the answers differs.

The 25 institutions are stress testing asset security. The real test is: when contract logic and asset security need to be completed on the same chain, whose path will succeed?