Cube (Bitcoin L2 smart-contract VM) — compact bitdevs discussion gist

cube-bitdevs-gist.md

Cube — bitdevs gist

Source: Introducing Cube · repo: cube-btc/cube

TL;DR

A Bitcoin L2 VM for trustless smart contracts — no soft fork, no bridge, no federation. Pitch: Ark-style virtual ownership + BitVM disprovable computation, glued together so contracts can hold BTC and run general logic, with unilateral exit to L1. Marketed as "trustless custody + generalized programmability."

Core idea: ZKTLC

Zero-Knowledge Time-Locked Contract = a timeout-tree virtual output carrying a zero-knowledge computation assertion enforceable via BitVM disproval. Two ingredients:

• Timeout trees (Ark-style) → scalable virtual ownership + unilateral redemption.
• BitVM (Groth16 disproval) → state transitions are asserted off-chain, then challengeable on-chain via interactive disproval; fraud yields a disproval secret → punitive path.

Pieces worth naming at the meetup

• CubeVM — fork of Bitcoin Script + global state, 256-bit math, EC ops, contract calls.
• Shadowing opcodes — the actual novelty. Maps a contract's pooled BTC into per-participant "shadow balances" tied to unilateral-exit timeout trees. Invariant: Contract Balance ≥ Σ Shadow Allocations (full collateralization at every state). This is the bridge from Bitcoin's key-native custody to logic-native custody.
• Projector — MuSig2 variant binding the agg key to value commitments (KeyProjectorAgg(pk…, val…)) for lightweight covenant emulation (no CTV/CSFS needed). Run by always-online Hosted Boxes doing minimal deterministic checks.
• Airly Payload Encoding (APE) — bit-level DA compression. Claimed: AMM swap ≈10.7 B/tx (~3.1× denser than zkEVM, ~10.5× vs EVM), transfer ≈9.7 B.
• Lifting / exit — on-chain UTXO → virtual output via (User + Engine) or (User after 3 months). Unilateral exit via tx::exit-ladder + fork attestation (Connector outpoint) so the Engine can't validate a fork that omitted your exit.

Trust model

• The Engine is a coordinator, never a custodian. Funds sit in cooperative 2-of-2 (participant + Engine); participant keeps unilateral control via MuSig2-emulated covenants enforced by Script.
• Claim: "Engine cannot steal — protocol structure prevents it." Shadow allocations always fully collateralized; if coordination dies, exit via timeout path.
• Per-participant setup ceremony with the Engine (scopes trust to your own proving params) — pitched as avoiding the BitVM 1-of-n honest-operator assumption.

vs. prior art (one-liners)

• Lightning: channels + HTLCs only → Cube = general VM w/ global state.
• Liquid: federation custody → Cube = 2-of-2 + L1 exit.
• Ark: ownership virtualization only → Cube adds programmable compute (BitVM + shadowing).
• zkEVM rollups: external bridge, weak CR → Cube settles natively, BTC is final layer.
• BitVM2: key-native custody only → shadowing maps custody → logic + unilateral redeem.

Discussion / skeptic flags

• Dated 2026-05-26; whitepaper/research stage. No team, funding, audit, or testnet disclosed.
• "Trustless" vs. liveness: can't steal, but Engine/Hosted-Box liveness is assumed; backstop is long timeouts (~3-month exit windows). Griefing / timing / replay attack surface unaddressed in the post.
• BitVM-on-Bitcoin reality check: Groth16 disproval is huge, multi-tx, capital-locked, and largely unproven in production — does the per-participant ceremony actually dodge the 1-of-n trust, or just relocate it?
• Custom Script fork (CubeVM): implementation/consensus risk vs. battle-tested alternatives.
• DA still bounded by L1 blockspace — APE pushes density, doesn't remove the ceiling.
• Big efficiency claims (vs zkEVM/EVM) are self-reported, no benchmark methodology shown.

One-sentence frame: "Ark + BitVM + a shadow-balance covenant trick to get a fully-collateralized, unilaterally-exitable smart-contract VM on Bitcoin with no soft fork — strong story, but rests on BitVM disproval being practical and an always-online coordinator."