A system that would allow smart contracts to be executed on Bitcoin without the user handing over custody of their funds to any operator was proposed on May 27 by Burak Keceli, the developer known in the bitcoin community for having exposed critical vulnerabilities in the Lightning Network (LN) in 2022 that forced an emergency update. The new project is called Cube and aims to bring programmable finance to Bitcoin so that when a user deposits their funds in a smart contract they do not temporarily lose the ability to withdraw them on their own. Keceli describes Cube as a platform on which broker-free asset exchanges, collateralized lending systems, and bitcoin (BTC)-backed stablecoins, among other financial applications, could be built.
Cube promises to integrate smart contracts into Bitcoin without giving up self-custody of funds. Source: GitHub. While many current L2s require some degree of trust in operators or committees (such as Keceli’s own Ark L2 Service Providers or the multisig federation on Blockstream’s Liquid Network), Cube promises that the user will never lose the ability to unilaterally withdraw their funds at the base layer of Bitcoin. On the other hand, Cube would require a technical layer called Engine, which would act as your internal coordinator. Its role would be to order user transactions, periodically record system status in Bitcoin, and coordinate off-network execution. In that sense, Keceli maintains that the Engine «is never the custodian»since, according to the developer, the funds would remain under an agreement between the user and the Engine that requires the signature of both to move (multisig 2 of 2). In addition, Keceli explains, the user could force its exit without the collaboration of the Engine if it acted maliciously or stopped working. While users retain the theoretical option of unilateral exit should the Engine stop working or act maliciously, this makes the Engine a potential point of operational friction, even if it does not compromise the custody of funds. While Keceli does not delve into how the Engine could fail, an error in this structure could potentially be due to a technical failure of the system or deliberate action, including the possibility of the Engine being compromised by a third party.
How would Cube work on Bitcoin? Three pieces combined
Cube would combine three mechanisms to achieve smart contracts with unilateral output:
Timeout trees
The first is the timeout trees, which are the structure that organizes and records the funds of all users within Cube. They work like a tree of pre-signed transactions: each branch corresponds to a user and has, from the beginning, recorded the right of that user to claim their funds directly in Bitcoin if something goes wrong. The entire tree shares a single periodic registration point in the base network. That architecture allows two modes of operation. As long as the Engine works correctly, transactions between users occur within Cube without the need to write each movement in Bitcoin, which would reduce time and costs. But if the Engine stopped operating or tried to withhold funds, the user would not need its authorization to exit: they could activate their branch of the tree directly in Bitcoin and recover theirs autonomously, once the predefined period that was recorded when you deposited. That term is the only condition; There is no intermediary that can block it. This technology comes from the Ark protocol.
BitVM3
The second mechanism is BitVM3, the most recent version of BitVM (Bitcoin Virtual Machine), a proposal by developer Robin Linus. BitVM3, which is not yet operational, aims to solve in Cube how a user could prove that the Engine functioned incorrectly, if all execution occurs outside of Bitcoin. Cube’s answer is that each Engine operation is accompanied by a verifiable statement about its result. If the user detects that this statement is false, they can present proof of the error directly in Bitcoin. Bitcoin evaluates it and, if it confirms the fraud, it would activate a penalty against the Engine, which would release the funds blocked as collateral exposed to a dispute resolved in favor of the user. The mechanism seeks to ensure that the cost of acting incorrectly is greater than any possible benefit.
CubeVM
The third is CubeVM, a virtual machine (program execution environment) built as an extension of Bitcoin Script, Bitcoin’s native programming language. CubeVM would add support for complex smart contractswhich are programs that could execute advanced financial logic, such as asset exchanges or collateralized stablecoins, something that native Bitcoin Script does not allow.
AI generated image illustrating the potential operation of Cube on Bitcoin. Source: BitcoinDynamic.
The problem Cube wants to solve in Bitcoin
Using smart contracts in Bitcoin implies that when a user deposits their funds into a contract, These funds become under the control of the program logicnot the user’s private key. In that intermediate state, Bitcoin has no native way of recognizing that those funds belong to the user, since the protocol understands keys, not program logic. The user is, in practice, dependent on the system you are using working correctly to recover yours.
The mechanism that Keceli proposes to solve this is called Shadowing. This tool would maintain at all times an internal record of how much BTC would correspond to each user within each contract. This registry (called shadow space) would not represent the direct custody of the funds, but rather the debt that the contract would have with each participant. This debt would be continuously reflected in the timeout trees, so that the user would always have available an exit to the Bitcoin network equivalent to the amount that the contract owes them, even while their funds are under the control of the program. For the mechanism to work correctly, Keceli describes an internal rule of the Cube virtual machine: the sum of all amounts recorded in the shadow space could never exceed the Bitcoin that the contract effectively custody. If that condition is violated, the operation you make in Cube would be automatically rejected. This would seek to ensure that there are always real funds backing every possible unilateral exit. In this context, while the debate on Bitcoin L2s with programmability oscillates between systems that achieve complex contracts by giving up some degree of custody, and those that preserve user sovereignty but with limited functionality, Cube, one of the most recent of these proposals, tries not to give in on either front. However, whether the design withstands technical scrutiny and is implemented is still an open question.
