Cube Introduction

Author: Buark

Source: https://medium.com/cube-bitcoin/introducing-cube-8b3702e470a5

" Cube " is a virtual machine specifically designed to enable trustless smart contract execution in a manner native to Bitcoin. It provides a trustless execution environment with one-way exit capabilities, ensuring users retain complete control over their funds. By combining BitVM with a "timeout tree" and utilizing the Bitcoin blockchain as a "data availability (DA)" layer, Cube directly embeds BTC into a virtual machine with a "global state." This approach combines Bitcoin's fundamental design with a Turing-complete smart contract execution model without introducing counterparty risk, thus providing a completely new framework for extending Bitcoin's functionality.

Holy Grail

Bitcoin is the most secure and time-tested cryptocurrency, but its limitations in scripting and scalability restrict its ability to support complex financial transactions beyond peer-to-peer payments. These are not flaws. They are constraints intentionally designed to protect the properties that give Bitcoin its value—censorship resistance, self-custody, and resilience. However, the result is that Bitcoin cannot natively support the programmability, throughput, and financial complexity required for a global monetary layer. Smart contracts, decentralized finance, and high-frequency settlement all require an execution environment that Bitcoin was never intentionally designed to provide at its base layer.

The solution is not to change Bitcoin, but to build upon it. A meaningful layer 2 network must extend Bitcoin's capabilities without sacrificing its core properties. It must bring programmable smart contracts while maintaining self-custody : no intermediary can freeze or confiscate users' funds. It must achieve all this without requiring changes to the Bitcoin protocol, introducing trusted intermediaries that can be stolen, and forcing users to trust launch ceremonies, committees, and bridge operators whose backgrounds they don't know.

While many proposed scaling solutions have expanded Bitcoin's functionality, they have sacrificed its trustless nature. Many designs rely on the 1-of-n trust assumption, meaning security depends on at least one operator being honest. These designs compromise Bitcoin's core ethics: decentralization and trustlessness; they are not sustainable long-term scaling solutions for Bitcoin.

CUBE

Cube brings a completely different approach to Bitcoin's programmability: a native layer 2 specifically designed for executing completely trustless smart contracts directly on Bitcoin, without bridging contracts, operator consortia, external consensus systems, or even modifying the Bitcoin protocol. Instead of moving Bitcoin to an alternative domain of trust in exchange for programmability, Cube extends Bitcoin's native self-custody and settlement model into a programmable execution environment while maintaining its anchor to the Bitcoin network.

Cube's core objective was once considered contradictory within the Bitcoin system: trustless custody and universal programmability. Traditional smart contract environments achieve programmability by abstracting away Bitcoin's ownership and settlement model, replacing them with external validators, bridging contracts, multi-signature, or consortium escrow assumptions. Cube does not do this. Beneath Cube's execution layer lies Bitcoin's native ownership model, allowing programmable smart contracts to run without sacrificing unilateral exit capabilities (self-custody, or Bitcoin's enforced redemption guarantee).

Cube leverages Bitcoin itself as the settlement, dispute resolution, and ultimate ownership layer within the execution environment. The smart contract environment operates off-chain in an optimistic mode, while settlement guarantees, one-way exits, and the enforcement of challenge-response mechanisms all return to Bitcoin itself through primitives native to Bitcoin.

Cube's architecture revolves around the "Engine," a coordination layer responsible for receiving transaction entries from participants, sorting them into batches, and generating settlement transactions pegged to the Bitcoin network. In normal operations, the Engine optimistically facilitates state transitions and coordinates execution, without requiring immediate on-chain settlement. Crucially, the Engine is purely a coordinator, not a custodian.

Cube's primary design goal is trustless programmability without sacrificing Bitcoin's native self-custody characteristics. Each participant retains unilateral control over their funds at all times, through restrictions emulated by MuSig2 multisignatures and enforced directly by the Bitcoin script. Funds are locked in a cooperative 2-of-2 multisignature construct (one-to-one between participant and Engine), forming the ownership primitive basis governing the Cube execution environment.

Because Cube never directly handles participants' funds, Engine cannot move assets, forfeit balances, or prevent unilateral withdrawals on its own. Participants retain the ability to enforce unilateral exit terms directly on the Bitcoin network via the "timeout tree" settlement path and challenge-response mechanism.

As a result, Cube retains complete trustlessness at the custody level while bringing general smart contract programmability directly to Bitcoin. Participants do not rely on the integrity of operators, committees, consortia, or external validators to safeguard their funds. Ownership guarantees are directly enforced by the Bitcoin script, one-way exit paths, and cryptographic challenge-response constructions. The Engine cannot be stolen because the protocol structure itself does not allow it; with the keys and Bitcoin-enforced redemption guarantees, participants' control over their funds is uninterrupted.

Virtualized computing ownership

Cube’s execution architecture is a combination of two primitives native to Bitcoin: (1) Ark-style timeout tree ownership virtualization; and (2) BitVM-style disprovable computation.

The Timeout Tree provides scalable virtualized ownership and a one-way redemption guarantee, allowing participants to exchange virtual outputs off-chain while maintaining the ability to independently exit back into the Bitcoin chain. BitVM complements this model by extending virtualized ownership to virtualized computation, allowing Bitcoin's native falsifiability computation to challenge and enforce asserted state transitions.

Cube combines these two fundamental primitives into a unified execution primitive called " Zero-Knowledge Time-Locked Contracts (ZKLTC) ".

Conceptually, (1) the timeout tree solves the problem of ownership virtualization; while (2) BitVM solves the problem of enforced computation. Cube combines the two, so programmable state transitions can occur optimistically off-chain, while always maintaining the ability to redeem and challenge through Bitcoin itself.

(Translator's note: "Optimistic" here means that the proposed state change is valid unless someone else objects.)

In short, ZKTLC is a timeout tree virtual output carrying a zero-knowledge computational assertion that can be enforced through the BitVM challenge mechanism.

ZKTLCs

ZKTLCs extend the VTXO model used in Ark-style timeout tree systems by adding programmable computation and challenge-response semantics. While traditional VTXOs primarily represent a unilateral redemption claim for value, ZKTLC additionally represent a challengeable computational assertion between the user and the Engine. Therefore, the output is not only a claim for value but also a claim to the correctness of the state transition asserted by the Engine.

Abstractly speaking, the relationships can be likened to existing two-party contracts in Bitcoin. In the Lightning Network, a channel is mostly a one-to-one relationship between a user and a Lightning Network Service Provider (LSP). In the Ark-style system, a virtual output represents a one-to-one relationship between a user and the Ark service provider within that system. And in the Cube, a ZKTLC represents a one-to-one BitVM challenge-response relationship between a user and the Engine.

The execution environment of Cube follows the execution model of the BitVM3 paradigm: in which the asserted Groth16 validator computations are transformed into a garbled-circuit validator environment that can be executed through Bitcoin's native challenge-response mechanism. These asserted computations correspond to the state transitions promised by the Engine. More specifically, the Engine must prove that the proposed state transitions are correctly executed according to the consensus rules of (1) Bitcoin and (2) CubeVM, and that no invalid state transitions have occurred relative to previously promised states.

Instead of performing arbitrary computations directly on Bitcoin merchants, Cube executes compact validator assertions, the correctness of which can be challenged later in the BitVM3 falsification environment. Therefore, the underlying validator circuitry represents the validity rules of the CubeVM state transition system itself, including execution semantics, contract constraints, balance invariants, state transition validity conditions, and the relevant Bitcoin consensus rules governing settlement correctness.

The asserted computation is represented by garbled tables, wire-label commitments, challenge records, and a secret value reveal structure corresponding to the validator circuit. In cooperative execution, the adjudicating environment remains dormant, and the Engine optimistically advances state transitions. In adversarial conditions, a participant can force the disclosure of verifiable inputs that can be evaluated (by witnessing the assertion itself), locally reconstruct a garbled Groth16 validator to obtain the commitment, and then evaluate the asserted state transition themselves. If the evaluation produces an invalid result, the garbled validator generates a disproving secret value corresponding to the erroneous output wire-label, allowing the participant to trigger a punitive settlement path associated with the already committed Bitcoin hash lock conditions.

Therefore, the participants control virtualized ownership objects that include both unilateral redemption rights and the right to enforceable execution status asserted by the cryptographically proven Engine.

Traditional zero-knowledge proof systems rely on a trusted initiation ceremony (or multi-party secure computation committee) involving the entire ecosystem. Cube differs by restricting the proof environment to an independent environment for each participant. During account initialization, each participant directly works with the Engine to perform a separate initiation ceremony, generate unique proof parameters, participate in the generation of toxic waste, and control the destruction of their own toxic waste. (Translator's note: Here, "toxic waste" refers to data that could leak information related to the initiation ceremony.)

As a result, the activation device itself is programmed to be trustless for the participant. Trust is not directed to an external MPC committee, coordinator, or shared proof environment, but is confined to the participant's own ZKTLC environment.

Timeout Tree

Cube utilizes a timeout tree as the underlying ownership and unilateral exit architecture, which is at a lower level than the execution environment.

A timeout tree is a tree of pre-signed transactions that allows a large number of virtualized ownership objects to share a common settlement structure while protecting each participant's unilateral redemption guarantee. Instead of having every intermediate transfer of ownership immediately settled within the Bitcoin blockchain, participants optimistically trade on the virtualized output embedded in a shared transaction tree.

During cooperative execution, the timeout tree remains dormant, and ownership transfer occurs off-chain. If coordination fails, or the Engine becomes dishonest, participants can independently materialize and redeem the corresponding timeout tree branch within the Bitcoin chain once the relevant timeout conditions are met.

Cube employs a timeout tree as the fundamental settlement and ownership primitive under ZKTLC execution mechanism. The balance of each participant in the system can ultimately be resolved into a timeout tree redemption path that can be enforced via a Bitcoin script.

Conceptually, the timeout tree structure provides Cube with ownership virtualization capabilities, while ZKTLCs enrich these ownership objects with programmable computation and challenge-response semantics. In this sense, Cube's execution architecture can be understood as a combination of Ark's virtual ownership and BitVM's provable computation, both directly anchored to Bitcoin's settlement guarantees.

CubeVM

Cube introduces a custom virtual machine called "CubeVM," which is an extension and replica of Bitcoin Script (a programming language) specifically designed for executing trustless smart contracts on Bitcoin. CubeVM does not replace Bitcoin's script execution philosophy; instead, it extends Bitcoin Script's stack-based execution environment into a programmable global state environment optimized for one-way exits and falsification computation.

CubeVM extends Bitcoin Script with additional opcodes required for generalized smart contract computation. This virtual machine natively supports global state management, persistent contract storage, isolated execution environments, enhanced memory management, 256-bit arithmetic, elliptic curve operations, stack element operations, contract call semantics, and projection opcodes that directly manipulate the underlying asset, Bitcoin.

Unlike account-native virtual machines (such as the Ethereum Virtual Machine (EVM)), CubeVM is designed from first principles (bringing programmable execution to Bitcoin's native self-storage mechanism). Therefore, smart contract state transitions are always compatible with Cube's timeout tree settlement structure and falsification mode.

CubeVM's defining architectural primitive is its native support for " projection ," which allows the logical balance controlled by a contract to be continuously projected into unilateral exit objects belonging to the participants. The projection operation serves as a semantic bridge between programmable smart contract execution and Bitcoin's key-based ownership model. Through this mechanism, CubeVM enables programmable smart contracts to operate directly on Bitcoin while maintaining a fully guaranteed unilateral redemption and self-custody characteristics during contract execution.

projection

Programmable smart contract systems, such as Ethereum, operate on an ownership model fundamentally different from Bitcoin's native design. In Bitcoin, funds are controlled by public keys. Ownership is represented by the ability to create valid digital signatures, and the account that freely exercises the right to sign ultimately governs the coins. Smart contracts are entirely different. A smart contract does not possess the discretionary power or free will inherent in an account. It is governed by the contract's own funds, entirely by deterministic procedural logic and state transitions. In particular, the contract logic itself becomes the custodian of value. This difference makes Bitcoin's native ownership and the semantics of programmable smart contracts fundamentally incompatible.

BitVM and obfuscated circuits essentially operate within the context of key-native environments. Their primitives revolve around public keys, signatures, challenge-response protocols, and provable computations associated with individual entities. While BitVM can verify arbitrary computations, its underlying ownership model remains unchanged: Bitcoin still understands keys, not logic. Executable logic itself cannot directly hold Bitcoin in the form of UTXOs. As a result, two distinct semantic domains emerge. Bitcoin speaks the language of public keys, while smart contracts speak the language of logic. These systems are not naturally interoperable because Bitcoin lacks a native abstraction that allows logic to hold value. To bridge this incompatibility, our work introduces an intermediate abstraction: "projection."

Projection is a translation layer that lies between the native custody model of the logic and the native holding semantics of Bitcoin. Instead of making the executable logic itself an entity holding Bitcoin, it allows a balance controlled by a contract to be projected as a set of balances associated with public keys belonging to each participant. The core observation behind projection is that although funds may temporarily reside in the custody of the contract logic, these funds, economically speaking, still belong to the individual participants throughout the contract's lifecycle.

Typically, in programmable smart contract systems like Ethereum, funds move through a recurring custody cycle: initially under direct ownership of an account, then temporarily under logical custody controlled by the contract, and finally, due to withdrawals or settlements, back to direct account ownership. A participant might initially control the funds through an account balance controlled by their native key. Then, this participant might deposit these funds into a smart contract—such as a Bitcoin-backed stablecoin contract, an Automated Market Maker (AMM) liquidity pool, or another programmable financial primitive—at which point the funds are no longer directly held by the participant's signing permissions, but are entirely governed by the contract's execution logic and state transition rules. Ultimately, when collateral is redeemed, liquidity is withdrawn, or the contract settles, the funds return to the participant's public key control. Therefore, the problem with this process is that, in the intermediate state, the funds are no longer directly controlled by the participant's public key and therefore cannot be represented as a balance held by the public key because they are under logical custody. This intermediate state, the state held by logic, is precisely where Bitcoin's native ownership semantics and smart contract's native execution semantics cannot be naturally aligned.

(Translator's note: In fact, on protocols like Ethereum, only the native Ethereum currency ETH can be held directly using a public key; other currencies can only be manipulated by public keys under the execution logic of their issuance contracts, meaning that logical custody is the primary function.)

Projection resolves this incompatibility by representing the contract's obligations to participants rather than its custody itself. The contract's balance is continuously projected onto a set of balances corresponding to the specific amount held by a participant's public key in any given contract state (in an economic sense). This projected representation—the shadow state—can be expressed using Bitcoin's native structure, although its underlying custody is still entirely governed by executable logic. Through this mechanism, funds governed by the contract can be continuously projected onto a timeout tree associated with the participant's public key, allowing for unilateral withdrawal. As a result, while the underlying Bitcoin remains logically custodied, participants always retain the redeemable right to their specific amount in any given state. Therefore, projection serves as a semantic bridge between BitVM's native key challenge framework and smart contract-based logical custody. Executable logic governs the funds, but the shadow of these funds can always be redeemed through Bitcoin's native public key structure.

Projection space

From an implementation perspective, the projection abstraction mechanism creates a dedicated and properly managed allocation space called the " projection space ." Each smart contract deployed on the Cube is assigned its own projection space, which is the ledger layer responsible for managing the shadow balances belonging to participants. Conceptually, the projection space is a database allocated by the contract itself, consisting of a mapping from账户公钥-> 影子余额; each entry represents the amount of Bitcoin economically belonging to (or "owed") a participant's account, even though the underlying currency is held in escrow by the contract. Therefore, the projection space does not represent ownership of the currency in the form of UTXOs; instead, it represents the planned redemption state of liquidity held by the contract, its form compatible with BitVM's native key framework and unilateral exit framework. The allocation of shadows is created and managed by a dedicated set of projection opcodes, allowing contracts to initialize, increase, decrease, and proportionally adjust the balances belonging to participants during state changes.

For any participant account, the sum of the following two items:

1. The account's original balance;
2. Shadow allocations that belong to this account across all contracts;

Defines the participant's actual redeemable balance on the timeout tree in any given state.

Importantly, the total amount of shadow allocations for a contract is strictly constrained by the actual balance held by that contract. The sum of all shadow balances within a contract's projection space can never exceed the amount of Bitcoin currently held by that contract: Contract Balance ≥ ∑Shadow Allocations

Any operation that results in shadow allocations exceeding the contract's actual Bitcoin balance is considered invalid and rejected at the virtual machine level. This constraint ensures that all projected shadow balances are always fully guaranteed by the liquidity held by the contract, thus guaranteeing sufficient unilateral exit liquidity for all balances belonging to participants.

Projection opcode

CubeVM incorporates a set of proprietary opcodes to manage the projection space of a contract:

- Projection Operation Code -

These opcodes provide the state transition primitives needed to manage the shadow balances attributable to participants during contract execution. OP_SHADOW_ALLOC initializes a new shadow allocation entry for a participant account within a contract's projection space, with an initial balance of 0. After allocation, OP_SHADOW_UP and OP_SHADOW_DOWN can be used to increase or decrease the shadow allocation associated with this participant.

For example, consider a stablecoin contract backed by Bitcoin. When a participant deposits Bitcoin into this contract as collateral, the deposited funds are governed by the contract's internal execution logic, no longer by the participant's signing authority. After testing, the contract calls OP_SHADOW_UP to increase the participant's shadow allocation by the corresponding amount of collateral. Although the deposited Bitcoin is technically under the contract's logical custody, an equivalent amount of the participant's balance is projected into a timeout tree that allows for unilateral withdrawal through projection space. This ensures sufficient unilateral withdrawal liquidity, allowing participants to always redeem their funds, even if the underlying currency remains virtualized and locked within the contract. This is the core mechanism of BitVM's key-native redemption model and smart contract-based logical custody.

In addition to account-based opcodes, CubeVM also includes proportionally skewed opcodes, including OP_SHADOW_UP_ALL and OP_SHADOW_DOWN_ALL . Unlike OP_SHADOW_UP and OP_SHADOW_DOWN , which only change the balance of a single participant, these opcodes proportionally increase or decrease the shadow allocation of all participants within a projection space (based on their current relative weights). These opcodes are particularly useful for pooled liquidity systems such as AMMs. When pooled Bitcoin liquidity increases or decreases due to swaps, fees, or liquidity events, the contract needs to proportionally balance the shadow allocation of all liquidity providers in the execution of a single opcode, rather than adjusting the shadow allocation of each liquidity provider individually. This significantly simplifies the implementation complexity of pooled finance primitives while maintaining a fully guaranteed one-way exit for all participants.

Projector

Cube uses a modified MuSig2 aggregate construct as a lightweight constraint imitation mechanism (because Bitcoin currently lacks native constraint opcodes). Instead of relying on protocol-level constraint primitives, Cube uses an aggregate signature structure bound to value to simulate constraints; this aggregate signature structure is called a "projector".

Unlike traditional MuSig2 aggregate signatures, the projector binds the aggregated constraint term public key not only to the signer's identity but also to an explicit numerical commitment. This cryptographically binds the constraint term script public key to the intended value state.

The primary goal of the projector is to enable a lightweight constraint execution environment, allowing participants to securely engage in constraint signing sessions without requiring full semantic awareness of the contract execution state or the transaction content. Projector participants do not need to analyze an infinite number of constraint logic possibilities; they can operate securely using as little deterministic verification as possible, while still resisting replay, rebinding, and malicious duplicate signing attempts.

Abstractly speaking, the projector transforms the signing of restricted terms into a constrained projection problem: the executable contract state is projected into a public key structure bound to a value, compatible with BitVM's native challenge mode for public keys.

The projector extends the original MuSig2 aggregation process through a preprocessing planning phase: this planning phase is executed before the standard KeyAgg(pk_1 … pk_u) steps (defined by BIP-327 ).

Cube introduces a deterministic projection function that binds value (instead of directly feeding the participant's public key into the KeyAgg function):

 KeyProjectorAgg(pk_1...pk_u, val_1...val_u)

in:

• pk_i is the participant's public key;
• val_i represents the value commitment in satoshis, which is associated with each participant.

For each participant (distinguished by number i ), a projection adjustment term is calculated as follows:

 t_i = H CubeProjector(val_i // i)

Here, H CubeProjector represents a labeled hash function, using the label "CubeProjector".

Then, each public key is projected as:

 pk_i'= pk_i + t_i.G

The final set of projected public keys is:

 (pk_1', pk_2', ... , pk_u')

Then, they are passed into the original MuSig2 aggregation process:

 KeyAgg(pk_1', pk_2', ... , pk_u')

The remaining MuSig2 signing process requires no further modification. Regarding the correctness of the signature, each participant can use the same adjustments to project their private key:

 sk_i' = sk_i + t_i

The projected private key will be used in the remaining MuSig2 nonce generation and fragment signature generation, just like in the original protocol. The final aggregate public key—called the "projector public key"—is simultaneously bound to the signer's identity and the explicit value commitment.

This value-binding property is crucial for lightweight restriction clause simulation. In the standard MuSig2 construct, the aggregate only commits the signer's public key. As a result, a malicious coordinator can attempt to sign multiple restriction clause states that are valid, as long as the signer is not fully aware of what they are signing.

In the projector, this attack is substantially constrained because the aggregated restriction term public key itself changes whenever the promised value changes. Since the restriction term script public key is derived from the projected aggregated public key, signing authority is intrinsically bound to a specific value state. Therefore, even an incompletely verified signing environment can securely participate in restriction term execution by running only a minimal amount of deterministic verification logic.

Main unit box projection

"Hosted Box Projection" refers to a lightweight restrictive clause signing environment with limited contextual awareness of the broader restrictive clause enforcement graph. Essentially, a host box is a lightweight, always-on restrictive clause simulation service running on a user-controlled device, similar to a router, repeater, or node software that operates in the background. This device may be run by the participant or deployed on external hosted infrastructure, but its role is intentionally defined: participating in the projector signing session upon Engine request.

The host box is not a complete smart contract runtime environment, but a limited, restricted simulated node solely responsible for participating in the projector signing process for bound value. The host box does not need to fully understand the contract semantics, transaction flow, or even the execution content. It only needs to securely participate in the projector signing session, a process that requires verifying only a few deterministic properties, such as:

• Whether your public key is in the aggregate set, and
• Is the requested value-bound projector parameter valid?

Once these checks pass, the host box can safely participate in the remaining MuSig2 signature process to create a fragment signature for the projected aggregate public key.

The security of this model stems from the aggregation of the bound value itself. Because the restrictive clause script public key is cryptographically bound to the explicit value commitment, malicious attempts to reuse signature permissions in an alternative restrictive clause state will only yield a different projector aggregate public key and a completely different restrictive clause script public key. Therefore, the host unit can securely function as a lightweight restrictive clause emulation engine without needing full knowledge of the restrictive clause execution; thus, it is also suitable for placement in perpetually running, low-power devices.

Black box projection

Projectors also open up a broad area for future research called "Black Box Projection." In this model, the restrictive clause signing environment is a restricted input/output system that exposes as little internal state, signing logic, and execution semantics as possible, while still being able to safely participate in the execution of restrictive clauses bound to value.

Because projected commitments bind value at the constraint level, black-box projection may enable non-interactive constraint participation: the signing runtime environment no longer needs to fully interpret or verify the relevant execution context, but only needs to perform the simplest structural checks. This would make the constraint simulation process much smoother, reduce the complexity of interactions, and open up the possibility of a highly scalable, lightweight constraint signing runtime environment as a constrained cryptographic projection device (rather than a fully stateful execution participant).

Virtual black box

One possible direction is an isolated virtual constraint signing environment, acting as an input/output black box. Such a system can securely participate in the projector signing session by performing as little deterministic verification logic as possible, such as verifying the signer team and verifying that the value-bound projector parameters conform to them. Because the projector aggregate public key is value-bound, replaying across multiple constraint states or malicious double-signing attempts are already limited. This allows a highly simplified signing environment to securely participate in constraint execution without requiring full knowledge of smart contract execution.

Physical black box

A more uncertain direction is the use of physically black-box restrictive devices. Ideally, such a system would allow the actual transfer of a signing device to an adversary without ever exposing its internal private key material, whether for inspection or tampering.

One hypothetical architecture might involve storing the signing private key in a stable, sustainable electromagnetic field or in a vacuum-isolated, sealed environment. In this mode, any physical detection, dismantling, or interference with the device would destroy this sealed environment, inevitably destroying the private key within. While somewhat far-fetched, such a system represents a possible long-term direction for restrictive clause signing infrastructure: a physically constrained signing environment capable of securely participating in projector restrictive clause enforcement while maintaining strong cryptographic isolation.

jump

"Lifting" is the process by which an in-chain Bitcoin UTXO is atomically transformed into a Cube native virtual output. Conceptually, a jump "transfers" Bitcoin from direct in-chain ownership to the Cube virtualization execution environment, where funds can then participate in ordinary transfers and smart contract calls.

Bitcoin must first jump before it can circulate within the Cube system. Therefore, jumping is the formal entry mechanism through which external on-chain liquidity enters the Cube execution environment, maintaining custody at every step of the process.

- Jump -

Jump output

A Lift is a dedicated introductory transaction output used to convert raw on-chain Bitcoin into Cube's native virtual output. Once a Lift output is funded, participants and their Engine exchange it for a 1:1 corresponding VTXO during the jump. In effect, Lift Lift is promoted to a timeout tree virtual ownership object. Lift outputs carry the following spending conditions: (Self + Engine) or (Self after 3 months) :

• Jump Path : Participants and their Engines collaboratively sign via the Self + Engine path. In exchange, participants receive a 1:1 corresponding VTXO within the Cube system.
• Exit Path : If the Engine does not cooperate or refuses to process the jump operation, the participant can retrieve their Bitcoin independently through the timeout recovery path after the defined timeout period ends.

Step-by-step exit and fork witness

- Unilateral Exit Path -

In the case of non-cooperation, that is, when the Engine refuses to cooperate in processing participant withdrawals or contract exits, Cube provides a unilateral exit mechanism, which is a transaction type carrying metadata called tx::exit-ladder .

Participants may invoke a unilateral exit path for either of these funding forms:

1. Withdraw the balance directly, such as unresolved swapout entries, and
2. Exit the shadow balance controlled by the contract via Call -> Swapout execution path.

Under normal circumstances, these exit activities are processed collaboratively by their respective Engines in a "batch". If the Engine refuses to include or execute an exit activity requested by a participant, the participant can instead force it by broadcasting tx::exit-ladder transaction within the chain.

tx::exit-ladder transaction contains metadata that encodes a pending exit operation for which the Engine refuses cooperative processing. Specifically, this transaction carries an APE-encoded "Entry Kind" corresponding to the batch operation intended to be performed. Therefore, this unilateral exit transaction is an in-chain appeal path (otherwise, the relevant state transition would remain virtualized off-chain).

In addition to the exit metadata itself, tx::exit-ladder transaction also carries a "Connector" output point for "fork attestation".

This connector exists to solve a fundamental "fork-selection problem" in many BitVM-based bridging contracts and dispute resolution architectures: neither the challenger nor the prover can reliably attest to the orthodox chain on which the disputed state transition actually occurred.

Without such witnesses, malicious operators could attempt to dig up or forward an alternative, dishonest fork, unilaterally exiting the transaction on a fork that does not exist, thereby evading the activation challenge mechanism or ZKTLC 's penalty process.

Cube prevents this attack by explicitly outputting point witnesses.

The connector input from tx::exit-ladder transaction becomes the input to the corresponding tx::fork-attest transaction. Because the connector must originate from the unilateral exit transaction itself, the Engine cannot construct a valid fork witness path on a conflict chain where this `exit-ladder` transaction does not exist.

Therefore, the existence of unilateral exit transactions is cryptographically linked to the challengeable dispute environment itself. Engine cannot evade the activation challenge mechanism by selectively confirming another fork chain that has not made a unilateral exit request.

tx::fork-attest transaction is constructed using a 2-of-2 architecture, pre-signed with SIGHASH_ALL | ANYONECANPAY tag, and additionally embeds a SIGHASH_ALL CHECKSIG verification path to ensure that the transaction includes the connector output point from tx::exit-ladder transaction.

Ultimately, the unilateral exit path, linked by explicit output points, bears witness to the chain in which it belongs. This allows challengers and participants to reliably prove the disputed chain that led to the unilateral exit appeal, preventing ambiguous fork-choice attacks against ZKTLC challenge-response mechanism.

Data availability coding

- Comparison of Encoding Methods -

Cube uses a custom transaction encoding format called " Airly Payload Encoding (APE) ," which is specifically designed to optimize Cube's data availability efficiency.

The primary goal of APE is to maximize transaction density within the Bitcoin block space by minimizing the coding overhead of each transaction. Through aggressive payload compression, compact indexing, and aggregation-based coding strategies, Cube reliably accommodates more state transitions within a single Bitcoin block (compared to traditional EVM or zkEVM architectures).

General coding methods, such as RLP, prioritize flexibility and recursive structure representation, but APE is specifically designed for deterministic rollup execution and compact state transition coding. This coding method assumes a constrained execution environment with a predefined type system, deterministic calldata format, and hidden guarantees from the protocol layer, allowing Cube to eliminate much of the metadata overhead required by traditional EVM-compatible systems.

APE consists of several complementary compression and encoding techniques.

1. Bit-level encoding

Cube uses bit-level encoding for transaction fields and numeric types, instead of the traditional byte-based encoding scheme used by EVM and zkEVM systems.

Traditional encoding schemes, such as RLP , operate at the byte level, meaning that values ​​are expanded into byte-aligned representations, even when the actual entropy of the value requires far fewer bits to represent. In large transaction payloads, this can lead to substantial cumulative overhead.

APE eliminates this byte alignment assumption and encodes values ​​directly in bits, based on their actual entropy rather than their nominal type width.

For example, traditional systems would:

• Use 4 bytes to serialize a u32 (unsigned 32-bit integer) value;
• Use 8 bytes to serialize a u64 value;

Regardless of the actual range of representation. However, in practice, many transaction fields, such as index numbers, tags, selectors, counters, and compact numeric types, rarely use up all the space.

Therefore, APE dynamically compresses these fields into smaller byte representations, typically:

• This saves approximately 1 to 3 bytes for a single u32 value.
• This saves approximately 1 to 7 bytes for a single u64 value.

It will only incur an additional 1 to 2 bits of overhead.

Because Cube operates only in a deterministic, protocol-constrained execution environment, and the format and type structure of the invoked data are known, this approach becomes highly efficient. Therefore, Cube can aggressively reduce serialization overhead without requiring a recursive, self-describing metadata structure like RLP .

See: Numeric Types .

2. Rank-based indexes

Cube indexes accounts and contracts based on transaction frequency rather than the order in which they are registered.

Each time an account initiates a transaction or a contract is invoked, its score increases by 1. Over time, frequently accessed accounts and contracts will receive smaller index representations.

This allows heavily used system primitives—such as AMM pools, stablecoin contracts, and major liquidity centers—to eventually be compressed into very small index representations, typically enabling single-byte addressing.

This ranking and indexing system is maintained in memory and at the execution layer, so Cube can avoid repeatedly transmitting large static identifiers, such as 20-byte EVM addresses or fixed-length contract identifiers.

See: Registration Manager .

3. Unprefixed call data

Cube maps data elements directly to predefined type formats, each with a deterministic length.

As a result, calldata elements do not require explicit recursive encoding methods that prefix the data with the numerical length (such as those in RLP). Because the decoder already knows the expected structure and the field width of the calldata format, the additional prefix metadata becomes unnecessary.

This eliminates the prefix overhead that has always been associated with EVM calldata serialization, while simplifying deterministic payload parsing.

See the Calldata element for details.

4. Common Numerical Lookup Tables

Cube uses a lookup-based encoding mechanism for frequently occurring transaction values.

Frequently used values, such as common transfer amounts, liquidity quantities, and even contract interaction amounts, are represented by compact lookup table indexes instead of being repeatedly serialized into full-width formats.

This optimization is particularly useful for financial primitives whose denomination patterns recur in large transaction sets. By encoding recurring numerical patterns into compact lookup table indexes, Cube substantially reduces a significant amount of repetitive load overhead.

See: Common Values .

5. Compact method calls

Cube also encodes contract calling methods using a compact variable-length primitive called AtomicVal .

EVM uses a 4-byte function selector, while Cube dynamically allocates as few bits as possible to represent a method that can be called within a contract.

For example, a contract that exposes four callable methods can select a method using only 2 bits.

This significantly reduces the overhead of each call, and becomes even more beneficial as transaction throughput increases.

See: AtomicVal .

6. Signature Aggregation

Cube maps an account’s Schnorr public key to a BLS-compatible aggregation space and performs non-interactive signature aggregation between transactions.

The result is that signatures for multiple transactions can be compressed into a fixed-length aggregate signature, instead of requiring a signature for each transaction or a large volume of zero-knowledge validity evidence.

This significantly reduces the overhead of data availability related to signatures, while maintaining compact block-level verification semantics.

See BLS for details.

7. Minimized target encoding

Cube also replaces the traditional nonce-based transaction sorting with a compact, replay-resistant field called Target .

In the Cube, entries do not carry monotonically increasing account nonces, but rather a minimally encoded target indicating that the entry is intended to be executed at a certain batch height. This target mechanism supports the current batching mechanism, as well as a restricted backtracking window (up to 5 batches).

This prevents rebroadcast lines from being delayed (a malicious engine might try to hold back an entry it wants to execute, or wait for a future state transition before broadcasting a previously signed entry). An entry is valid only within its intended execution window, so future rebroadcast attempts are invalid.

In practice, the vast majority of entries target the current batch height, making the encoding overhead very small. One bit is sufficient to represent execution at the current height, and additional backtracking depth requires only two more bits.

As a result, Cube replaced the traditional fixed-width nonce field—typically 8 bytes—with a replay-resistant mechanism that typically requires several bits. See Entry for details.

See Target for details.

8. Minimize the economic field

Cube replaces the traditional statistical gas fields with compact, operation-based fields called Ops Price and Ops Budget .

Instead of repeatedly encoding a large, fixed-width gas parameter for each entry, Cube assumes the default values ​​defined by the protocol and only encodes deviations from those default values.

Ops Price field indicates whether this entry should use the protocol's base execution price or specify an additional execution premium. In common cases, one bit is sufficient to indicate the use of the default base price. If a premium is required, simply encode the difference from the base price concisely.

Similarly, the Ops Budget field indicates whether a custom execution budget should be specified for this entry. One bit is sufficient to determine whether an explicit budget exists. If so, the additional bits simply encode the requested budget amount.

In reality, most entries operate under the default execution assumptions, and the two fields typically consume very few bits; yet they can still support variable execution prices and constrained execution control (when necessary).

See Ops Price and Ops Budget for details.

9. Assertion

Cube operates in an assertion-based execution mode, in which only valid transactions are allowed into valuable batches.

Failed state transitions are excluded from the final payload, thus never consuming permanent data availability space. In contrast, both the EVM and zkEVM systems allow failed transactions to be permanently recorded on the blockchain, even if they produce invalid (or reversed) execution results.

By eliminating the mechanism of permanently recording failed executions, Cube achieves additional historical block space efficiency and forms a clearer execution state pattern.

TPS forecast

The following section estimates the theoretical transaction throughput of Cube, assuming the use of the standard APE transaction paradigm. This estimate primarily focuses on raw data availability efficiency and compares Cube with zkEVM-style rollups and traditional EVM transaction formats.

Because Cube radically reduces the serialization overhead of transactions through bit-level encoding, compact indexing, nonce-free mechanism, minimizing economic fields, compact calldata format, and situational call method encoding, the average transaction payload size is much smaller than that of traditional smart contract systems.

AMM Swap

- Automated Market Maker Swap - TPS Forecast -

Taking a typical automated market maker swap operation as an example, each Cube transaction only requires approximately 10.7 bytes (approximately 2.67 vBytes) of block space.

In comparison:

• A zkEVM transaction of the same level consumes approximately 33 bytes;
• A traditional EVM transaction consumes approximately 110 bytes.

Therefore, Cube is expected to support:

• Approximately 3.1 times the number of AMM swaps (compared to the equivalent zkEVM system on Bitcoin).
• Approximately 10.5 times more AMM interchanges (compared to a standard EVM environment).

Token transfer

- Token Transfer - TPS Estimation -

Taking a standard token transfer as an example, each Cube transaction only requires approximately 9.7 bytes (approximately 2.42 vBytes) of block space.

In comparison:

• A zkEVM transaction of the same level consumes approximately 33 bytes;
• A traditional EVM transaction consumes approximately 126 bytes.

Therefore, Cube is expected to support:

• Approximately 3.1 times the number of token transfers (compared to the equivalent zkEVM system on Bitcoin);
• Approximately 10.5 times the number of token transfers (compared to a standard EVM environment).

(over)