Today in new adventures in UTXO-sharing, Burak (@brqgoo - the guy who made the transaction that broke LND #79930 and who came up with Ark #192040) has announced a new idea: Cube.

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

Timeout trees provide scalable virtualized ownership and unilateral redemption guarantees, allowing participants to transact over off-chain virtual outputs while preserving the ability to independently exit onto Bitcoin. BitVM complements this by extending virtualized ownership into virtualized computation, enabling asserted state transitions to become challengeable and enforceable through Bitcoin-native interactive disproval.

Cube composes these two foundational primitives into a unified execution primitive referred to as a Zero-Knowledge Time-Locked Contract (ZKTLC).

Conceptually, (1) timeout trees solve the ownership virtualization problem, while (2) BitVM solves the computation enforcement problem. Cube combines the two together such that programmable state transitions may occur optimistically off-chain while remaining continuously redeemable and challengeable through Bitcoin itself.

At its core, a ZKTLC is a timeout-tree virtual output carrying a zero-knowledge computation assertion enforceable through BitVM disproval.

It sounds like he is using a lot of the same ideas he used in Ark, but combining them with zk proofs?

Where a conventional VTXO primarily represents a unilateral redemption claim over value, a ZKTLC additionally represents a challengeable computation assertion between the user and the Engine.

Unfortunately, I don't think it's going to come close to solving the walled garden problem of Ark (where LIghtning is a p2p network of channels, Ark is a centralized network where users interact with a service provider):

At a high level, the relationship is analogous to existing two-party Bitcoin constructions. In Lightning, a channel is most commonly a 2-of-2 relationship between a user and a Lightning service provider. In Ark-style systems, virtual outputs operate as 2-of-2 relationships between the user and the Ark service provider. In Cube, a ZKTLC operates as a 2-of-2 BitVM challenge-response relationship between the user and the Engine.

I'll admit that it gets a little beyond my understanding when he mentions "garbled tables, wire-label commitments, challenge transcripts, and revealing-secret structures corresponding to the verifier circuit." But I suspect that this may be a cool way to add functionality on top of bitcoin -- as long as you don't mind the more trustodial setups we've been seeing with things like Ark and Spark.

Burak introduces an idea called shadowing:

The defining architectural primitive of CubeVM is its native support for Shadowing, allowing contract-controlled logical balances to be continuously projected into participant-attributable unilateral-exit objects. Shadowing acts as the semantic bridge between programmable smart-contract execution and Bitcoin’s fundamentally key-oriented ownership model. Through this mechanism, CubeVM enables programmable smart contracts to operate directly on Bitcoin while preserving fully collateralized unilateral redemption guarantees and continuous self-custody throughout contract execution.

Shadowing acts as a translation layer between logic-native custody and Bitcoin-native possession semantics. Rather than attempting to make executable logic itself a Bitcoin-owning entity, Shadowing allows a contract-governed balance to be projected into a set of participant-attributable balances associated with public keys. The central observation underlying shadowing is that, although funds may temporarily exist under the custody of contract logic, such funds remain economically attributable to individual participants throughout the lifecycle of the contract.

Shadowing resolves this incompatibility by representing not the contract’s custody itself, but rather the contract’s obligations toward participants. The contract-held balance is continuously projected into a set of balances corresponding to the exact quantities economically owed to participant keys at any given contract state.

Burak proposes a set of opcodes that would work in his CubeVM to allow actions while maintaining the shadow balances.

These opcodes provide the primitive state-transition operations required for maintaining participant-attributable shadow balances throughout contract execution. OP_SHADOW_ALLOC initializes a new shadow allocation entry for a participant account within a contract’s shadow space with an initial balance of zero. Once allocated, OP_SHADOW_UP and OP_SHADOW_DOWN may be used to increase or decrease the shadow allocation associated with that participant.

Burak proposes an example that helps to illustrate how this might work:

consider a Bitcoin-collateralized stablecoin contract. When a participant deposits Bitcoin into the contract as collateral, the deposited coins become governed by the contract’s internal execution logic rather than by the participant’s signing authority. At this point, the contract invokes OP_SHADOW_UP to increase the participant’s shadow** allocation by the corresponding collateral amount. Although the deposited Bitcoin is now technically under logical custody of the contract itself, the equivalent participant-attributable balance becomes projected onto the unilateral-exit timeout trees through the shadow space. This guarantees that sufficient unilateral-exit liquidity remains continuously redeemable by the participant despite the underlying coins remaining virtually locked within the contract. This is the core mechanism through which shadowing bridges BitVM’s key-native redemption model with smart-contract-style logical custody.

It may be my optimistic nature, but I'm always hopeful that people will come up with new ways of combining the primitives maintained by Bitcoin to do some cool stuff. I can't quite tell if this is that, but it seems worth spending some time thinking about.