Cube is a virtual machine designed to enable trusless smart contract execution natively on Bitcoin. Providing a fully trustless execution environment with unilateral exit, Cube ensures users retain complete control over their funds. By combining BitVM with timeout trees and leveraging Bitcoin DA, Cube integrates BTC directly into a virtual machine with global-state. This approach unites Bitcoin’s foundational design with a Turing-complete smart contract execution model without introducing a counterparty risk, offering a novel framework for extending Bitcoin’s functionality.

Holy Grail

Bitcoin is the most secure and battle-tested cryptocurrency, yet its scripting limitations and scalability challenges restrict its ability to support complex financial transactions outside of peer-to-peer payments. These are not flaws. They are deliberate constraints that preserve the properties that make Bitcoin valuable: censorship resistance, self-custody, and adversarial robustness. The consequence, however, is that Bitcoin cannot natively support the programmability, throughput, or financial complexity that a global monetary layer demands. Smart contracts, decentralized finance, and high-frequency settlement require an execution environment that Bitcoin was never designed to provide at its base layer.

The solution is not to change Bitcoin. It is to build on top of it. An effective Layer 2 must extend Bitcoin’s capabilities without compromising its core properties. It must enable programmable smart contracts while preserving the self-custody guarantee that no intermediary can seize or freeze a user’s funds. And it must accomplish this without requiring Bitcoin protocol changes, without introducing trusted intermediaries who can steal, and without forcing users to trust ceremonies, committees, or bridge operators they have never met.

Many proposed scaling solutions extend Bitcoin’s functionality at the expense of its trust model. Many designs rely on a 1-of-n trust assumption, where system security depends on at least one honest party. Such designs compromise Bitcoin’s core ethos of decentralization and trustlessness; it will not be the long term scaling solution for Bitcoin.

CUBE

Cube introduces a fundamentally unique approach to Bitcoin programmability: a native Layer 2 designed to bring fully trustless smart-contract execution directly onto Bitcoin without bridges, federations, external consensus systems, or Bitcoin protocol modifications. Rather than moving Bitcoin into an alternative trust domain in exchange for programmability, Cube extends Bitcoin’s native self-custody and settlement model into a programmable execution environment while remaining fundamentally anchored to Bitcoin itself.

The central objective of Cube is to achieve what has historically been considered contradictory within Bitcoin systems: trustless custody together with generalized programmability. Conventional smart-contract environments achieve programmability by abstracting away Bitcoin’s ownership and settlement model behind external validators, bridges, multisigs, or federated custody assumptions. Cube instead preserves Bitcoin-native ownership directly beneath the execution layer itself, allowing programmable smart contracts to operate without sacrificing unilateral exit, self-custody, or Bitcoin-enforced redemption guarantees.

Cube utilizes Bitcoin itself as the underlying settlement, dispute-resolution, and final ownership layer beneath the execution environment. Smart-contract execution occurs optimistically off-chain, while settlement guarantees, unilateral exits, and challenge-response enforcement ultimately resolve back onto Bitcoin through native Bitcoin primitives.

At the center of Cube’s architecture is the Engine, the coordination layer responsible for receiving transaction entries from participants, ordering them into Batches, and producing the settlement transactions anchored to Bitcoin. Under normal operation, the Engine advances state transitions optimistically, coordinating execution without requiring immediate on-chain settlement. Critically, the Engine acts purely as a coordinator, never as a custodian.

Cube’s primary design objective is trustless programmability without sacrificing Bitcoin-native self-custody. Every participant retains unilateral control over their funds at all times through MuSig2 covenant emulation enforced directly by Bitcoin Script. Funds remain continuously locked within cooperative 2-of-2 constructions between the participant and the Engine, forming the foundational ownership primitive governing the Cube execution environment.

Because Cube never directly possesses participant funds, the Engine cannot independently move assets, seize balances, or prevent eventual withdrawal. Participants retain the ability to unilaterally enforce their exit conditions directly on Bitcoin through timeout-tree settlement paths and challenge-response escalation mechanisms.

As a result, Cube remains fully trustless at the custody layer while simultaneously enabling generalized smart-contract programmability directly on top of Bitcoin itself. Participants do not rely on operators, committees, federations, or external validators to honestly safeguard funds. Instead, ownership guarantees are enforced directly by Bitcoin Script, unilateral exit paths, and cryptographic challenge-response constructions themselves. The Engine cannot steal because the protocol structure itself prevents it, while participants retain continuous sovereignty over funds through direct key ownership and Bitcoin-enforced redemption guarantees.

Virtualized Computation Ownership

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.

ZKTLCs

ZKTLCs extend the VTXO model employed in Ark-style timeout-tree systems with programmable computation and challenge-response semantics. 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. The virtual output therefore becomes not only a claim over value, but also a claim over correctness of the Engine’s asserted state transition.

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.

Cube’s execution environment follows a BitVM3-style execution model in which asserted Groth16 verifier computations are transformed into garbled-circuit verifier environments enforceable through Bitcoin-native challenge-response disproval. The asserted computation corresponds to validity of the Engine’s committed state transition. More specifically, the Engine proves that the proposed transition executed correctly according to (1) Bitcoin and (2) CubeVM consensus rules, and that no invalid state transition occurred relative to the previously committed state.

Rather than executing arbitrary computation directly on Bitcoin, Cube executes compact verifier assertions whose correctness may later be challenged through the BitVM3 disproval environment. The underlying verifier circuit therefore represents the validity rules of the CubeVM state-transition system itself, including execution semantics, contract constraints, balance invariants, state-transition validity conditions, and relevant Bitcoin consensus rules governing settlement correctness.

The asserted computation is represented through committed garbled tables, wire-label commitments, challenge transcripts, and revealing-secret structures corresponding to the verifier circuit. Under cooperative execution, the dispute environment remains dormant while the Engine advances state transitions optimistically. Under adversarial conditions, participants may force disclosure of evaluatable verifier inputs through the assertion witness itself, reconstruct the committed garbled Groth16 verifier locally, and independently evaluate the asserted transition. If evaluation yields an invalid result, the garbled verifier derives the disproval secret corresponding to the failing output-wire label, allowing the participant to trigger the associated punitive settlement path through the committed Bitcoin hashlock condition.

Participants therefore control virtualized ownership objects containing both unilateral redemption rights and cryptographically enforceable disproval rights over the Engine’s asserted execution state.

Unlike conventional zero-knowledge systems relying on ecosystem-wide trusted ceremonies or MPC committees, Cube scopes the proving environment independently per participant. During account initialization, each participant performs an individual setup ceremony directly together with the Engine, generates participant-scoped proving parameters, participates in toxic-waste generation, and controls destruction of their own toxic-waste material.

As a result, the setup itself becomes trustless from the participant’s perspective. Trust is not inherited from external MPC committees, trusted coordinators, or shared proving environments, but remains cryptographically localized to the participant’s own ZKTLC environment.

Timeout Trees

Cube utilizes timeout trees as the underlying ownership and unilateral-exit architecture beneath the execution environment.

A timeout tree is a pre-signed transaction tree structure allowing large quantities of virtualized ownership objects to share a common settlement structure while preserving unilateral redemption guarantees for individual participants. Rather than requiring every intermediate ownership transition to immediately settle onto Bitcoin, participants transact optimistically over virtualized outputs embedded inside a shared transaction tree.

Under cooperative execution, the timeout tree remains dormant while ownership transitions occur off-chain. If coordination fails or the Engine becomes dishonest, participants may independently materialize and redeem the corresponding timeout-tree branches directly on Bitcoin after the associated timeout conditions mature.

Cube adopts timeout trees as the foundational settlement and ownership primitive beneath ZKTLC execution. Every participant balance within the system ultimately resolves back into a timeout-tree redemption path enforceable directly through Bitcoin Script.

Conceptually, timeout trees provide Cube with ownership virtualization, while ZKTLCs extend those ownership objects with programmable computation and challenge-response semantics. In this sense, Cube’s execution architecture can be understood as the composition of Ark-style virtualized ownership and BitVM-style disprovable computation anchored directly to Bitcoin settlement guarantees.

CubeVM

Cube introduces a custom-built virtual machine called CubeVM, implemented as an extended fork of Bitcoin Script designed for trustless smart-contract execution on Bitcoin. Rather than replacing Bitcoin’s execution philosophy, CubeVM expands Bitcoin Script’s stack-based execution model into a programmable global-state environment optimized for unilateral exit and disprovable computation.

CubeVM extends Bitcoin Script with additional opcodes required for generalized smart-contract computation. The VM introduces native support for global state management, persistent contract storage, segmented execution environments, advanced memory management, 256-bit arithmetic, elliptic-curve operations, stack-element manipulation, contract-call semantics, and Shadowing opcodes designed to work directly with Bitcoin as the underlying asset.

Unlike account-native virtual machines such as the EVM, CubeVM is designed from first principles to bring programmable execution into Bitcoin-native self-custody. Smart-contract state transitions therefore remain continuously compatible with Cube’s timeout-tree settlement architecture and disproval model.

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

Programmable smart-contract systems such as Ethereum operate on an ownership model that is fundamentally different from Bitcoin’s native design. In Bitcoin, funds are controlled by public keys. Ownership is expressed through the ability to produce a valid digital signature, and coins are ultimately governed by accounts exercising discretionary signing authority. Smart contracts, on the other hand, operate differently. A smart contract does not possess discretionary authority or will in the account-native sense. Funds held by a contract are governed exclusively according to deterministic program logic and state transitions. In practice, the contract logic itself becomes the custodian of value. This distinction creates a fundamental incompatibility between Bitcoin-native ownership and programmable smart-contract semantics.

BitVM and garbled-circuits fundamentally operate in a key-native environment. Their primitives revolve around public keys, signatures, challenge-response protocols, and provable computation associated with individual entities. While BitVM may verify arbitrary computation, the underlying ownership model remains unchanged: Bitcoin still understands keys, not logic. Executable logic itself cannot directly possess Bitcoin in UTXO terms. Consequently, two different semantic domains emerge. Bitcoin speaks the language of keys, while smart contracts speak the language of logic. These systems are not naturally interoperable because Bitcoin possesses no native abstraction for logic-held value. To bridge this incompatibility, this work introduces an intermediary abstraction referred to as shadowing.

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.

Typically within programmable smart-contract systems such as Ethereum, coins move through a recurring custody lifecycle in which they begin under direct account ownership, temporarily enter contract-controlled logical custody, and eventually return back to direct account ownership upon withdrawal or settlement. A participant initially controls coins through a native key-controlled account balance. The participant may then deposit those coins into a smart contract — such as a Bitcoin-backed stablecoin contract, an AMM liquidity pool, or another programmable financial primitive — at which point the funds are no longer directly possessed by the participant’s signing authority and instead become governed exclusively by the contract’s execution logic and state-transition rules. Eventually, upon collateral redemption, liquidity withdrawal, or contract settlement, the coins once again return to direct participant custody under public-key control. The problematic phase is therefore the intermediary state during which funds are no longer directly controlled by participant keys, yet simultaneously cannot be represented as key-owned balances because they exist under logical custody. This intermediary logic-possessed state is precisely where Bitcoin-native ownership semantics and smart-contract-native execution semantics cease to naturally align.

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. This projected representation — the shadow state — becomes expressible through Bitcoin-native structures despite the underlying custody remaining governed entirely by executable logic. Through this mechanism, contract-governed coins may be continuously mapped onto unilateral-exit timeout trees associated with participant public keys. As a result, although the underlying Bitcoin remains under logical custody, participants retain continuously redeemable claims corresponding to the exact quantity owed to them at every state transition. In this sense, shadowing functions as a semantic bridge between BitVM’s key-native challenge framework and smart-contract-style logical custody. Executable logic governs the funds, while the shadow of those funds remains continuously redeemable through Bitcoin-native public-key structures.

Shadow Space

In implementation terms, the shadowing abstraction materializes as a dedicated contract-managed allocation space referred to as the shadow space. Every smart contract deployed on Cube is assigned its own shadow space, which acts as the accounting layer responsible for managing participant-attributable shadow balances. Conceptually, the shadow space functions as a contract-local allocation database consisting of:
account_key→shadow_balance
mappings, where each entry represents the quantity of Bitcoin economically attributable, or “owed”, to a given participant account while the underlying coins remain under contract custody. The shadow space therefore does not represent direct ownership of coins in UTXO terms. Rather, it represents the projected redemption state of contract-held liquidity in a form compatible with BitVM’s key-native challenge and unilateral-exit framework. Shadow allocations are created and managed through a dedicated set of shadowing opcodes, allowing contracts to initialize, increase, decrease, or proportionally rebalance participant-attributable balances over time as contract state evolves.

For any participant account, the sum of:

1. the account’s native balance,
2. all shadow allocations attributed to that account across all contracts,

defines the participant’s effective unilateral-exit redeemable balance across the timeout trees at any given state transition.

Importantly, a contract’s total shadow allocation is strictly bounded by the actual balance held by the contract itself. The sum of all shadow balances within a contract’s shadow space may never exceed the quantity of Bitcoin currently controlled by that contract: Contract Balance ≥ ∑Shadow Allocations

Any operation resulting in shadow allocations exceeding the contract’s actual Bitcoin balance is considered invalid and rejected at the VM level. This constraint guarantees that all projected shadow balances remain fully collateralized by contract-held liquidity at all times, ensuring that sufficient unilateral-exit liquidity always exists for all participant-attributable balances.

Shadowing Opcodes

CubeVM introduces a dedicated family of opcodes for managing a contract’s shadow space:

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.

For example, 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.

In addition to per-account allocation operations, CubeVM also introduces proportional rebalance operations through OP_SHADOW_UP_ALL and OP_SHADOW_DOWN_ALL. Unlike OP_SHADOW_UP and OP_SHADOW_DOWN, which operate on individual participant balances, the _ALL variants proportionally increase or decrease the entire shadow space across all participant allocations according to their current relative weights. These operations 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 may proportionally rebalance all liquidity-provider shadow allocations in a single opcode execution rather than iterating through participants individually within contract logic. This significantly simplifies implementation complexity for pooled financial primitives while preserving fully collateralized unilateral-exit guarantees for all participants.

Projector

Cube utilizes a modified MuSig2 aggregation construction as a lightweight covenant-emulation mechanism in the absence of native covenant opcodes within Bitcoin. Rather than relying on protocol-level covenant primitives, Cube emulates covenant behavior through value-bound aggregate signing structures referred to as Projectors.

Unlike traditional MuSig2 aggregation, Projector binds aggregate covenant keys not only to signer identities but also to explicit value commitments. This allows covenant scriptpubkeys to become cryptographically tied to their intended value state.

The primary objective of Projector is to enable lightweight covenant execution environments capable of safely participating in covenant-signing sessions without requiring full semantic awareness of contract execution state or transaction intent. Rather than reasoning about arbitrary covenant logic, Projector participants may safely operate using minimal deterministic verification rules while remaining resistant to replay, rebinding, or malicious double-signing attempts.

At a high level, Projector transforms covenant signing into a constrained projection problem: executable contract state is projected into value-bound public-key structures compatible with BitVM’s native key-oriented challenge model.

Projector extends the original MuSig2 aggregation procedure through a preprocessing projection phase executed prior to the standard KeyAgg(pk_1 … pk_u) step defined in BIP-327.

Instead of directly supplying participant public keys into KeyAgg, Cube introduces a value-bound deterministic projection function:

KeyProjectorAgg(pk1​…pku​, val1​…valu​)

where:

• pk i ​ represents participant public keys,
• val i ​ represents satoshi-denominated value commitments associated with each participant.

For each participant index i, a projection tweak is computed as:

ti ​= H CubeProjector​(vali ​∥ i)

where H CubeProjector ​ denotes a tagged hash using the tag “CubeProjector”. Each public key is then projected as:

pki′​=pki​+ti​⋅G

The resulting projected key set:

(pk1′​,pk2′​,…,pku′​)

is then supplied into the original MuSig2 aggregation procedure:

KeyAgg(pk1′​…pku′​)

without otherwise modifying the remaining MuSig2 signing flow. For signing correctness, each participant correspondingly projects its secret key using the identical tweak value:

ski′​=ski​+ti​

The projected secret keys are then used throughout the remaining MuSig2 nonce generation and partial-signature procedures exactly as defined in the original protocol. The resulting aggregate key — referred to as the Projector Key — therefore becomes cryptographically bound both to signer identities and to explicit value commitments.

This value-binding property is critical for lightweight covenant emulation. In standard MuSig2 constructions, aggregation commits only to signer public keys. Consequently, a malicious coordinator may attempt to obtain multiple valid signatures across alternative covenant states if a lightweight signer does not fully understand what it is signing.

Under Projector, this class of attack becomes substantially constrained because the aggregate covenant key itself changes whenever the committed value configuration changes. Since the covenant script public key is derived from the projected aggregate key, signing authority becomes intrinsically bound to a specific value state. As a result, lightweight signing environments may safely participate in covenant execution while performing only minimal deterministic verification logic.

Hosted Box Projection

Hosted Box Projection refers to lightweight covenant-signing environments operating with limited contextual awareness of the broader covenant execution graph. A Hosted Box is essentially a lightweight always-online covenant-emulation service running on a user-controlled device, similarly to how a router, relay, or node software operates continuously in the background. The device may be self-hosted by the participant or deployed within external hosting infrastructure, but its role remains intentionally narrow: to participate in Projector signing sessions when requested by the Engine.

Rather than operating as a full smart-contract execution environment, a Hosted Box functions as a constrained covenant-emulation node responsible only for participating in value-bound Projector signing flows. The Hosted Box does not need to fully understand contract semantics, transaction flows, or execution intent. Instead, it safely participates in Projector signing sessions by verifying only minimal deterministic properties, such as:

• whether its own public key participates within the aggregation set, and
• whether the requested value-bound projection parameters are valid.

Once these checks succeed, the Hosted Box may safely participate in the remaining MuSig2 signing flow and produce a partial signature for the projected aggregate key.

The safety of this model derives from value-bound aggregation itself. Since the covenant script public key is cryptographically tied to explicit value commitments, malicious attempts to reuse signing authority across alternative covenant states result in entirely different aggregate keys and therefore entirely different covenant script public keys. As a result, Hosted Boxes may safely operate as lightweight covenant-emulation engines without requiring full covenant execution awareness, making them suitable for persistent low-resource deployment environments.

Black Box Projection

Projector additionally enables a broader future-research direction referred to as Black Box Projection. In this model, covenant-signing environments behave as constrained input/output systems that expose minimal internal state, signing logic, or execution semantics while still safely participating in value-bound covenant execution.

Because projection commitments are value-bound at the covenant level itself, Black Box Projection potentially enables non-interactive covenant participation in which the signing environment no longer needs to fully interpret or validate the surrounding execution context beyond minimal structural checks. This significantly streamlines covenant emulation flow, reduces interaction complexity, and opens the possibility for highly scalable lightweight covenant-signing environments operating as constrained cryptographic projection devices rather than fully stateful execution participants.

Virtual Black Box

One possible direction involves isolated virtual covenant-signing environments operating as IO black boxes. Such systems may safely participate in Projector signing sessions while performing only minimal deterministic verification logic, such as verifying signer inclusion and validating expected value-bound projection parameters. Because Projector covenant keys are value-bound, replay or malicious double-signing attempts across alternative covenant states become substantially constrained. This allows highly simplified signing environments capable of safely participating in covenant execution without requiring full smart-contract execution awareness.

Physical Black Box

A more speculative direction involves physical black-box covenant devices. Such systems would ideally allow a signing device to be physically delivered to a counterparty while remaining fundamentally incapable of exposing its internal secret material under inspection or tampering.

One hypothetical architecture may involve storing signing secrets within continuously sustained electromagnetic or vacuum-isolated containment environments. Under such a model, any attempt to physically probe, open, or interfere with the device would collapse the containment environment and irreversibly destroy the protected secret material. Although highly theoretical, such systems illustrate a possible long-term direction in covenant-signing infrastructure: physically constrained signing environments capable of safely participating in Projector covenant execution while preserving strong cryptographic isolation guarantees.

Lifting

Lifting is the process through which native on-chain Bitcoin UTXOs are atomically transformed into Cube-native virtual outputs. Conceptually, lifting “moves” Bitcoin from direct on-chain ownership into Cube’s virtualized execution environment, where the funds may then participate in vanilla transfers, and smart-contract calls.

Bitcoin must first be lifted before it can circulate within the Cube system. As a result, lifting serves as the canonical onboarding mechanism through which external on-chain liquidity enters the Cube execution environment, while retaining the custody in every step of the way.

Lift Outputs

A Lift is a specialized onboarding transaction output used for converting bare on-chain Bitcoin into Cube-native virtual outputs. When a Lift output is funded, the participant and the Engine cooperatively exchange the Lift output for a corresponding 1:1 VTXO through the lifting procedure. In effect, the Lift output is elevated into a virtualized timeout-tree ownership object. A Lift output carries the following spending conditions (Self + Engine) or (Self after 3 months):

• Lift Path: The participant and the Engine cooperatively sign through the User + Engine spending path. In exchange, the participant receives a corresponding 1:1 VTXO representation inside the Cube system.
• Exit Path: If the Engine becomes non-collaborative or refuses to process the lift operation, the participant may reclaim the underlying Bitcoin through the timeout recovery path after the specified timeout period.

Exit Ladder & Fork Attestation

In the non-collaborative case, where the Engine refuses to cooperatively process a participant withdrawal or contract exit, Cube provides a unilateral exit mechanism through a metadata-carrying transaction type referred to as tx::exit-ladder.

A participant may invoke the unilateral exit path for both:

1. direct balance withdrawals, such as unresolved Swapout entries, and
2. contract-controlled shadow balances exited through the Call -> Swapout execution route.

Under normal operation, these exits are processed collaboratively by the Engine within a Batch. If the Engine refuses to include or execute the requested exit, the participant may instead force execution by broadcasting a tx::exit-ladder transaction on-chain.

The tx::exit-ladder transaction contains metadata encoding the pending exit operation that the Engine refused to process collaboratively. Specifically, the transaction carries the APE-encoded Entry Kind corresponding to the Batch operation intended for execution. The unilateral exit therefore acts as an on-chain escalation path for an otherwise virtualized off-chain state transition.

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

This Connector exists to address a fundamental fork-selection problem present in many BitVM-based bridge and dispute architectures: namely, the inability for challengers or provers to reliably attest to the canonical chain in which a disputed state transition actually occurred.

Without such attestation, a malicious operator may attempt to mine or relay an alternative non-honest fork in which the unilateral exit transaction does not exist, thereby attempting to avoid challenge activation or ZKTLC punishment flows.

Cube prevents this class of attack through explicit outpoint attestation.

The Connector outpoint from the tx::exit-ladder transaction becomes required input material for the corresponding tx::fork-attest transaction. Since the Connector must originate from the unilateral exit transaction itself, the Engine cannot construct a valid fork-attestation path on a conflicting chain where the exit-ladder transaction was absent.

As a result, the existence of the unilateral exit transaction becomes cryptographically coupled to the challengeable dispute environment itself. The Engine therefore cannot evade challenge activation by selectively acknowledging alternative forks lacking the unilateral exit request.

The tx::fork-attest transaction is presigned through a 2-of-2 construction using SIGHASH_ALL | ANYONECANPAY, while additionally embedding a SIGHASH_ALL CHECKSIG validation path enforcing inclusion of the Connector outpoint originating from the tx::exit-ladder transaction.

Consequently, the unilateral exit path becomes chain-attestable through explicit outpoint linkage. This allows challengers and participants to reliably prove the canonical dispute chain under which the unilateral exit escalation occurred, preventing fork-selection ambiguity attacks against the ZKTLC challenge-response mechanism.

DA Encoding

Cube utilizes a custom transaction encoding scheme referred to as Airly Payload Encoding (APE), designed specifically to optimize data-availability efficiency for Cube.

The primary objective of APE is to maximize transactional density within Bitcoin block space by minimizing per-transaction encoding overhead. Through aggressive payload compression, compact indexing, and aggregation-oriented encoding strategies, Cube is able to pack substantially more state transitions into a Bitcoin block than conventional EVM or zkEVM architectures.

Unlike general-purpose encoding schemes such as RLP, which prioritize flexibility and recursive structure representation, APE is purpose-built for deterministic rollup execution and compact state-transition encoding. The encoding model assumes a constrained execution environment with predefined type systems, deterministic calldata layouts, and protocol-level indexing guarantees, allowing Cube to eliminate substantial categories of metadata overhead traditionally required in EVM-compatible systems.

Airly Payload Encoding consists of several complementary compression and encoding techniques.

1. Bit-level Encoding

Cube utilizes bit-level encoding for transaction fields and value types rather than the conventional byte-oriented encoding schemes used by EVM and zkEVM systems.

Traditional encodings such as RLP operate at byte granularity, meaning values are expanded into byte-aligned representations even when the actual entropy of the value requires far fewer bits. Across large transaction payloads, this introduces substantial cumulative overhead.

APE removes this byte-alignment assumption and instead encodes values directly at the bit level according to their effective entropy rather than their nominal type width.

For example, conventional systems serialize:

• u32 values using 4 bytes,
• u64 values using 8 bytes,

regardless of the actual represented range. In practice, however, many transaction fields — such as indices, flags, selectors, counters, and compact value types — rarely require their full representable width.

APE therefore dynamically compresses these fields into smaller bit representations, commonly saving:

• approximately 1–3 bytes for u32,
• approximately 1–7 bytes for u64,

while introducing only one or two bits overhead.

This approach becomes especially effective because Cube operates within a deterministic protocol-constrained execution environment where calldata layouts and type structures are already known ahead of time. As a result, Cube can aggressively minimize serialization overhead without requiring recursive self-describing metadata structures such as RLP.

See Valtypes.

2. Rank-based Indexing

Cube indexes Accounts and Contracts according to transaction frequency rather than registration order.

Each time an Account initiates a transaction or a Contract is called, its rank score is incremented by one. Frequently accessed Accounts and Contracts therefore migrate toward smaller index representations over time.

This allows heavily used system primitives — such as AMM pools, stablecoin contracts, or major liquidity hubs — to eventually compress into extremely small index representations, often approaching single-byte addressing.

The ranking and index resolution system is maintained at the memory and execution layer, allowing Cube to avoid repeatedly transmitting large static identifiers such as 20-byte EVM addresses or fixed-width contract identifiers.

See Registery Manager.

3. Non-prefixed Calldata

Cube maps calldata elements directly onto predefined type layouts with deterministic lengths.

As a result, calldata items do not require explicit recursive length-prefix encoding as used in RLP. Because the decoder already knows the expected structure and field widths of the calldata layout, additional prefix metadata becomes unnecessary.

This removes the prefix overhead traditionally associated with EVM calldata serialization while simplifying deterministic payload parsing.

See Calldata Elements.

4. Common Value Lookup

Cube utilizes a lookup-based encoding mechanism for commonly occurring transaction values.

Frequently used values — such as common transfer amounts, liquidity quantities, or contract interaction denominations — are represented through compact lookup indices rather than repeatedly serialized in full-width form.

This optimization is particularly effective for financial primitives where repeated denomination patterns occur frequently across large transaction sets. By encoding recurring value patterns through compact lookup references, Cube substantially reduces repetitive payload overhead at scale.

See CommonVal.

5. Compact Call Method

Cube encodes contract call methods through a compact varying-bit-size primitive referred to as AtomicVal.

Instead of using 4-byte function selectors as in the EVM, Cube dynamically allocates only the minimum number of bits necessary to represent callable methods within a contract.

For example, a contract exposing four callable methods requires only 2 bits for method selection.

This substantially reduces per-call overhead across aggregate payload volume and becomes increasingly beneficial at high transaction throughput.

See AtomicVal.

6. Signature Aggregation

Cube maps account Schnorr keys into BLS-compatible aggregation space and performs non-interactive signature aggregation across transactions.

As a result, multiple transaction signatures may compress into a single constant-size aggregated signature rather than requiring individual per-transaction signatures or large zero-knowledge validity proofs.

This significantly reduces signature-related data-availability overhead while preserving compact block-level verification semantics.

See BLS.

7. Minimal Target Encoding

Cube replaces conventional nonce-based ordering with a compact replay-protection field referred to as Target.

Instead of carrying monotonically increasing account nonces, each Entry carries a minimally encoded Target indicating the intended Batch height at which the Entry is expected to execute. The Target mechanism supports the current Batch together with a bounded rollback window extending up to five Batch depths.

This prevents delayed-broadcast replay behavior in which a malicious Engine attempts to withhold and later rebroadcast previously signed Entries at future state transitions. Entries become valid only within their intended execution window, rendering later rebroadcast attempts invalid.

Because the overwhelming majority of Entries target the current Batch height, the encoding overhead becomes extremely small in practice. A single bit is sufficient to indicate current-height execution, while additional rollback depths require only two additional bits.

As a result, Cube replaces conventional fixed-width nonce fields — commonly 8 bytes in traditional systems — with a replay-protection mechanism typically consuming only a handful of bits.See Entry.

See Target.

8. Minimal Ops Fields

Cube replaces conventional gas accounting fields with compact operation-oriented execution fields referred to as Ops Price and Ops Budget.

Rather than repeatedly encoding large fixed-width gas parameters for every Entry, Cube assumes protocol-defined defaults and encodes only deviations from those defaults.

The Ops Price field indicates whether the Entry uses the protocol base execution price or specifies an additional execution premium. In the common case, a single bit is sufficient to indicate usage of the default base price. If an additional premium is requested, only the excess gap above the baseline is compactly encoded.

Similarly, the Ops Budget field indicates whether the Entry specifies a custom execution budget. A single bit determines whether an explicit budget exists. If present, additional bits encode only the requested budget amount.

Because most Entries operate under default execution assumptions, both fields typically consume only minimal bit overhead in practice while still supporting variable execution pricing and bounded execution control when necessary.

See Ops Price and Ops Budget.

9. Assertations

Cube operates under an asserted execution model in which only valid transactions are permitted to enter finalized batches.

Failed state transitions are excluded from finalized payloads and therefore never consume permanent data-availability space. In contrast, EVM and zkEVM systems permit failed transactions to become permanently recorded on-chain despite producing invalid or reverted execution outcomes.

By eliminating permanently recorded failed execution attempts, Cube achieves additional historical block-space efficiency while maintaining a cleaner execution state model.

TPS Projections

The following projections estimate Cube’s theoretical transaction throughput under typical transaction patterns using Airly Payload Encoding (APE). The estimates focus primarily on raw data-availability efficiency and compare Cube against both zkEVM-style rollups and conventional EVM transaction formats.

Because Cube aggressively minimizes serialization overhead through bit-level encoding, compact indexing, nonceless targeting, minimal Ops fields, compact calldata layouts, and lightweight call-method encoding, average transaction payload sizes become substantially smaller than conventional smart-contract systems.

AMM Swap

Taking an average AMM swap as an example, Cube consumes approximately ~10.7 bytes (~2.67 vBytes) of block space per transaction.

In comparison:

• a comparable zkEVM transaction consumes approximately 33 bytes,
• while a conventional EVM transaction consumes approximately 110 bytes.

As a result, Cube is projected to support:

• approximately 3.1× more AMM swaps than a zkEVM-equivalent system on Bitcoin,
• and approximately 10.5× more AMM swaps than a standard EVM environment.

Token Transfer

Taking a standard token transfer as an example, Cube consumes approximately ~9.7 bytes (~2.42 vBytes) of block space per transaction.

In comparison:

• a comparable zkEVM transaction consumes approximately 33 bytes,
• while a conventional EVM transaction consumes approximately 126 bytes.

As a result, Cube is projected to support:

• approximately 3.5× more token transfers than a zkEVM-equivalent system on Bitcoin,
• and approximately 13.2× more token transfers than a standard EVM environment.

Have questions ? Join CUBE Telegram Community Channel

Introducing Cube was originally published in Cube on Medium, where people are continuing the conversation by highlighting and responding to this story.

Prophet Muhammad set the table, placed the four, and left..

The Magician

Muhammad is not one of the four elements. He is the one who arranges them. One hand raised to heaven, one pointing to earth, the channel between worlds. He is the quintessence, the one who holds the other four in place without being any of them. He summoned the four, gave them to the world, and departed. What he left behind was a complete living system, the Ummah, a single Kabbalistic organism built from four elements.

Earth King: Ali

Earth is the grounding element. Roots. Endurance. The element that holds its shape under all pressure and does not move. It is the foundation upon which everything living stands. On the Magician’s table, Earth is represented by the Pentacle.

His nickname was Abu Turab, Father of Soil. You don’t get more Earthly than that.

Ali was the Prophet’s cousin, raised inside his household from childhood, the first male to enter Islam, and later his son-in-law. His father was Abu-Talib, a pagan, and Ali carries that paganic root in his bones. He is a paganic deity in the truest sense: the human-embodied version of the Earth itself, descended from a line that knew the sacred before Islam named it differently. The Earth was already holy. Ali was already its King.

He was physically extraordinary, famous for tearing the iron gate of Khaybar (a Jewish castle) from its hinges alone and using it as a shield, for defeating the warrior Merhab who no man had beaten before him. Strength that stems from the legs, the legs being the root of the human body, the connection to ground, as Earth is the root of all elements. The same pattern repeats across ages: David and Goliath, Ali and Merhab. Each era has its Earth King. For this era, in this framework, we call Him Ali.

Earth does not rush. Earth does not flinch. Earth simply is.

After the Prophet’s death, Ali was passed over for leadership three consecutive times. He waited with the patience of stone, then ruled as the fourth caliph, his reign consumed by civil war, ended by an assassin’s poisoned blade at morning prayer. Even the Earth King is eventually buried. But burial is not defeat. The Earth receives and returns.

Shia belief has inherited the concept of deities from its paganic roots, weaving it into a monotheistic framework where God remains one, absolute, untouchable. Deities in this sense are not partners to God but intermediaries, bridges, the ones through whom a human being reaches upward toward the divine. This is the core of how Shia Islam differs from Sunni: the belief that the sacred is not approached alone, but through those who embody it. Ali is the ultimate intermediary of the Earth, the only and supreme ruler of the terrestrial plane, the living Pentacle, the human pole around which divine authority organizes itself here below. To reach the Earth element, you go through Ali. There is no other gate.

Water Queen: Fatima

Water is the vitality element. Life itself. The element that fills every vessel and gives it meaning. Without Water the form exists but does not live. It is the blood of the world. On the Magician’s table, Water is represented by the Cup.

When enemies mocked the Prophet, your sons keep dying, your line is finished, you will be forgotten, God answered with three lines. The shortest surah in the Quran:

We have given you Kawthar (The Water Queen).

So pray to your Lord and give sacrifice.

Indeed your enemy is the one who is cut off.

— Surah Al-Kawthar 1–3

Fatima is symbolized as Kawthar, this heavenly pool in paradise, the abundance God granted when the world said the line was finished. That is our heavenly Water Queen deity.

She is not merely a historical figure. She is the Water element made flesh: the vitality-giver, the life-source, the cup that overflows. In the esoteric table, the Cup represents Water, and Fatima is the Cup. She is referred to as Kawthar directly in the Quran, and granted when the world said the line was finished.

She was the Prophet’s daughter, the only child whose descendants survived. Every person who carries prophetic lineage today traces through her and no one else. The entirety of the Imams, the Sayyids, the living sacred tree, all of it flows from her. The Water Queen whose waters never ran dry even as her own life was poured out completely.

She married Ali. Water meets Earth. The heavenly Queen meets the earthly King. Vitality (water) poured into form (earth). She holds another title: Umm Abiha, Mother of Her Father. The Water that nourishes even the source it came from. The Cup that refills the hand that first filled it.

She died within months of her father, young, in grief, her claimed inheritance stripped from her by the new political order. The heavenly Water Queen who gave the lineage its vitality and was herself poured out completely.

Air Lord: Hasan

Air is the mental plane. The unseen force. Strategy, stillness, mental alchemy. It does not strike directly, it moves through things, around things, ahead of things. It is chill. Patient. Already three steps forward before anyone noticed it moved. On the Magician’s table, Air is represented by the Wand.

Hasan is the one people in the Shia world often overlook. Firstborn of Ali and Fatima, eldest grandson of the Prophet, and almost invisible in popular memory because all the light, all the grief, all the devotion goes to his younger brother.

But Hasan was playing a different game entirely. He was the grand strategist. He tried to beat his enemy, Muawiyah, not through force but through mental alchemy. The unseen move made before the opponent even knew the game had started. Where others saw a man who stepped back, who signed a treaty, who did not fight, Hasan was operating on a plane Muawiyah could not read. The Wand does not strike. It thinks. It waits. It moves through the mind of the enemy before the enemy moves at all. That is Air. That is the Wand.

He was eventually poisoned, dying without spectacle. Of course he was. Air is never seen. Only felt, after it has already moved.

(On the esoteric reassignment: traditional Western occultism maps the Wand to Fire and the Sword to Air. This framework reverses that, and the lives of Hasan and Husayn are the proof. The Wand is the instrument of unseen, strategic, mental force. The Sword is the instrument of immediate, visible, literal action. Hasan carried the Wand. Husayn drew the Sword.)

Fire Lord: Husayn

Fire is the element of action. The seen force. It does not calculate from a distance, it moves and the world changes immediately and visibly. It is the element of action, war, and literal alchemy. It burns and it is seen burning. On the Magician’s table, Fire is represented by the Sword.

Husayn did not try to beat his enemy through strategy. He did not negotiate, did not step back, did not play the long game. He rode into Karbala with 72 believers against an army of thousands, and he beat his enemy the only way he knew: through force, through the Sword, through visible and immediate action that is Fire.

One by one his companions fell. His half-brother Abbas was killed at the riverbank trying to bring water for the children. His infant son Ali Asghar was struck by an arrow in his arms. Husayn fought until he could not stand, and was killed and beheaded on the field as a sacrifice for our El-magick. The camp was burned after.

The event did not stay in the past. It never does with Fire. Karbala became the burning center of Shia Islam, mourned every year on Ashura across the world, in every language, because the wound does not close. Fire does not become ash and stop. It keeps burning.

In the logic of Surah Al-Kawthar, God gave the Water and asked for a sacrifice. Husayn is the answer. The Fire lord, offered completely and consciously, so that the heavenly given element could endure. What the Ummah had in abundance, the Fire, the force, the visible action, it gave. What it was in danger of losing, the vitality, the lineage, the Water, it preserved. The exchange was made at Karbala. That is the alchemy. Magic needs sacrifice.

From Husayn’s lineage came the Twelve Imams of Shia Islam. The sixth of them, Imam Jafar al-Sadiq, was the master of Jabir ibn Hayyan, the father of chemistry. Fire is the element of literal alchemy, of chemistry, of transforming and bending the outer world through seen action. That the man who founded chemistry learned at the feet of a direct descendant of the Fire Lord is not coincidence. It is the element expressing itself through the lineage.

The Embodying Elements: (1) Earth & (2) Water

Humans are made from Earth:

We created you from Earth, and will return you to Earth, and from it We will bring you back again.

— Surah Taha 55

And from Water:

Indeed, We created humans from a mix of Water, and We made them hear and see to test them.

— Surah Al-Insan 2

(1) Earth and (2) Water are the embodying elements. They make a being that has (1) shape and (2) is alive. Without them there is nothing, no form, no vitality, no vessel for anything else to inhabit. Ali and Fatima are not merely two members of a family. They are the two cosmic principles without which no living being comes into existence. The Earth King and the Water Queen are the foundation. Everything else stands on top of them.

The Instrumental Elements: (3) Air & (4) Fire

(3) Air and (4) Fire are are the instrumental elements. They are not needed to form, but to function.

An organism of (1) Earth and (2) Water is grounded and alive. But until it picks up its instruments it can only be acted upon, never act.

The Wand, Air, is the instrument of the unseen: the mental reach, the strategy, the force that moves before anyone sees it move.

The Sword, Fire, is the instrument of the seen: the strike, the war, the action that bends the outer world immediately and directly in the alchemical sense.

One in each hand; the Wand in one, the Sword in the other. Only then is the organism whole: (1) structured, (2) alive, (3) reasoning, and (4) capable of bending the outer world. Only then can it meet another organism on the field.

The Magician set the table. The House is the table.

The four elements are in place. Sacrifices are made. The organism is complete. The table is set.

Now it moves.

The House: Our Four Elemental Framework was originally published in The Occult Islam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Rome had arenas where warriors competed. Strength decided rank and fame. Egypt had arenas too, but there, magicians competed. Magic and craftsmanship and determined status.

One day, Pharaoh invited the best magicians from across the land and threw the grand Magicians’ Contest.

God told Moses to attend the contest. “Do not be afraid. Indeed, you will be the one who prevails.” (Qur’an 20:68)

Moses steps into the arena, and God commanded: “Throw what is in your right hand. It will swallow up what those magicians have crafted.” (20:69)

Moses threw his staff, and it became the divine-purple Ekans, devouring everything the magicians had played.

“What they crafted was only a magician’s trick. And a magician can never succeed.” (20:69)

The magicians then fell in prostration: “We submit to the Lord of Aaron and Moses.” (20:70)

The Magicians Contest was originally published in The Occult Islam on Medium, where people are continuing the conversation by highlighting and responding to this story.

Breathing in and out is like playing ping pong on a socket connection to life. Each inhale and exhale is a packet of existence sent and received, a constant exchange keeping us in sync with life. Yet, just as every connection eventually times out and all clients disconnect, every organism must face its death. This cycle of breath is a quiet commitment to life, much like the ongoing engagement required to maintain your Bitcoin.

In Bitcoin, the dilemma between relying on custodians vs. embracing self-custody mirrors a struggle for balance. Self-custody offers full control but risks losing everything with one mistake, while custodianship, on the other hand, comes with its own set of fears.

Custody Is Scary!

Entrusting your coins to a custodian, such as a crypto exchange or a custodial wallet, creates a single point of failure. History is full of collapses, fraud, and hacks that have wiped out users’ funds overnight. No matter the security measures, the risk remains: if you don’t hold your money, someone else does, and that trust is often misplaced. Custodianship is a ticking time bomb, as disasters like Mt. Gox have proven.

Self-Custody Is As Scary!

Self-custody, often hailed as the ultimate solution to financial sovereignty, comes with its own terrifying risks. Losing access to one’s seed phrase is a complete disaster, leading to irreversible loss of funds and life savings. There’s no customer service, no recovery process. Just total failure.

Countless stories exist of people losing access due to misplaced backups, forgotten passwords, or tragic “boating accidents.” The burden of security is entirely on the individual, and for many, that’s a risk just as daunting as trusting a custodian. Bitcoiners are not prepared to be their own bank. Human error is a given.

Enter Ping Pong Custody

Ping Pong Custody strikes the ideal balance between self-custody and custodians, allowing users to maintain full control for a set duration while making periodic commitments to sustain it.

Custody exists on a spectrum: self-custody on one end, offering maximum control but high responsibility, and custodial solutions on the other, providing convenience but requiring trust in a third party. Ping Pong Custody sits in the middle, blending autonomy with periodic engagement. Users retain control but must actively confirm their ownership at intervals, preventing passive loss while avoiding full dependence on a custodian.

This model reflects real-world dynamics, such as renewing a lease or maintaining an active subscription. Instead of a single irreversible custody choice, users remain fluid, adapting their level of engagement over time.

The periodic “pong” back to the system ensures users remain aware and in control, while the structured renewal process protects against permanent loss.

Virtual UTXOs

Brollup, as a variant of Ark, builds on the concept of virtual UTXOs — short-lived, expiring Bitcoin notes that can be redeemed on-chain.

Rollup operators, in addition to ordering transactions and producing rollup blocks, also act as Ark service providers (ASPs), managing the lifecycle of virtual UTXOs within the system. Users must actively engage with these operators to maintain control over their funds.

This engagement functions like a continuous game of ping pong between users and the ASP, where users periodically renew their virtual UTXOs (VTXOs) to reset the expiration timer. This renewal process ensures their funds remain accessible and fully under their control.

On Brollup, virtual UTXOs expire after 90 days. A refresh period begins on the 60th day, during which users can renew their VTXOs without incurring any liquidity fees. If a user fails to refresh within the 90-day window, the timer expires, and custody transitions to a trusted social recovery mechanism. Rather than being permanently lost, funds enter a recovery process that shifts control away from the user but ensures accessibility through designated recovery methods.

To maintain sovereignty, users must continually refresh their coins. However, this process is fully automated and seamlessly managed by the client software, removing the need for manual intervention. Brollup’s Ping Pong Custody guarantees that users retain control of their funds as long as they remain engaged. This design creates a dynamic and participatory form of self-custody, one that balances resilience, autonomy, and recoverability within a streamlined and user-friendly system.

Much Like Breathing

Renewal is essential, much like breathing, as continuous engagement keeps the system active. Many aspects of life require ongoing participation. Showing up to church reaffirms faith, learning deepens knowledge, and engagement sustains self-custody.

With a fully automated renewal process, users stay in control without constant oversight. Ping Pong Custody ensures that as long as they remain engaged, their sovereignty is never compromised.

Ark’s design principles make self-custody both secure and convenient. By abstracting complexity and aligning with natural renewal cycles, it enables a resilient, user-friendly approach to digital ownership.

The Social Graph

Brollup employs an account-based model for its underlying design and uses Nostr keys for identification (x-only keys following the npub format).

This approach allows users to tap into the existing network effect of Nostr’s open ecosystem. While Brollup itself does not integrate with Nostr beyond its key format, users are encouraged to engage with Nostr for social interactions.

One account standard for social and financial. npubs are the new 0x!

Identity is more than just a private key. It’s built on relationships, reputation, and the ability to interact freely across networks. The social graph isn’t just a contact list; it’s a framework of trust and connectivity. Instead of depending on centralized institutions, users can rely on their own network for authentication, reputation, and recovery.

By using Nostr keys, Brollup embraces this approach, creating a seamless identity layer that connects financial transactions with social interactions. This strengthens resilience, enhances security, and enables a recovery design rooted in human connections rather than intermediaries.

Social Recovery

In the event a user loses access to their private key, recovery isn’t left entirely to chance. Instead, Brollup offers a safeguard through trusted contacts, allowing users to request a refund from the ASP (Brollup operators).

Operators automatically sweep expired VTXOs, and the social graph plays a pivotal role in guiding the recovery process. While the social graph helps coordinate the steps, it’s the foundational mechanics of VTXOs that ultimately make recovery possible.

Our design empowers users to rely on their personal network of trusted friends, family, or contacts in times of need, rather than relying on centralized authorities. By giving individuals the ability to recover their assets through a decentralized social structure.

Unlike traditional self-custody, where the loss of a private key often means losing access forever, Brollup introduces a new dynamic. It allows users to keep their funds secure under normal conditions, but offers a clear path for recovery when life’s uncertainties arise. This makes it a compelling choice for those who want to maintain control over their assets, but also desire a safety net in case of emergencies.

By merging financial independence with social trust, the design principles of Ark creates a harmonious balance between security and recoverability. It reimagines self-custody in a way that acknowledges the importance of community and relationships, allowing users to stay in control without sacrificing peace of mind.

WoT Courts

The scope extends far beyond just lost keys — it touches on deeper issues like inheritance and long-term asset management. As we look to the future, it’s easy to imagine Web of Trust (WoT) courts emerging as decentralized arbitration systems, resolving inheritance disputes based on the social graph and its associated trust dynamics. In such a scenario, Ark Service Providers (ASPs) wouldn’t just facilitate recoveries but could also act as executors, carrying out court rulings in a way that aligns with pre-established social agreements. This could redefine how digital assets are passed down across generations, blending cryptographic security with social consensus.

Would this work on-chain?

Not quite. While similar refreshing policies can be implemented with Miniscript for bare UTXOs, periodically refreshing UTXOs on-chain doesn’t scale. This is more of an Ark primitive, designed to refresh coins off-chain rather than on-chain, making the process efficient at scale. As a result, this recovery mechanism is more suited to Ark/Brollup and doesn’t translate as well to on-chain setups.

How often do I need to be active to maintain control?

A VTXO refresh period begins on the 60th day, during which users can renew their VTXOs without incurring any liquidity fees. This means the user needs to check their wallet at least once every 30 days. The refreshing process is automated and abstracted by the client software, which notifies the user in case of inactivity to ensure they don’t lose access.

We know though girls check their Instagram every minute, and men check Bitcoin Twitter every hour.

What if the ASP misbehaves?

Brollup operators aren’t a single server like in the regular Ark setting; they operate as a distributed MPC network with a built-in trustless DKG, removing single points of control and reducing the risk of misbehavior.

Even if some operators act maliciously, social recovery remains trust-minimized, relying on a decentralized process rather than any single entity. This distributed design strengthens security and resilience, ensuring recovery isn’t undermined by any single failure.

How about non-Bitcoin assets?

On Brollup, Bitcoin resides in VTXOs, which are off-chain verifiable and on-chain claimable expired notes. Non-Bitcoin assets such as stablecoins, however, exist solely within the virtual machine, meaning recovery for these assets isn’t possible in the same way as for Bitcoin.

Many token issuers, like Tether, implement issuer actions such as freezing or locking funds. In such cases, these actions need to be managed at the issuer level, not through the core recovery process.

Have further questions? Join our Telegram Community Channel.

Play Ping Pong or NGMI was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.

FROST can be nested inside MuSig, and MuSig can likewise be nested inside FROST. Each of these schemes operates on the fundamental principle of aggregating individual cryptographic keys while preserving security guarantees and maintaining the ability to generate valid signatures.

MuSig functions by combining multiple public keys into a single aggregate key, ensuring that all participants collaboratively sign messages without exposing their individual private keys. Each participant contributes their key to the aggregation process, forming an aggregate key that appears indistinguishable from a standard public key to external verifiers. This enables multi-party signing schemes while minimizing the overhead associated with traditional multi-signature schemes.

Our MuSig-nested-NOIST scheme extends this approach by allowing a NOIST quorum — composed of multiple signatories — to act as a single entity within a MuSig signing process. Essentially, instead of requiring every participant to be an individual keyholder in MuSig, we enable a subset of participants, structured as a NOIST quorum, to collectively contribute a single aggregated key to the MuSig operation. This design allows for covenant emulation involving not only individual entities but also a distributed quorum of rollup operators.

The NOIST quorum itself consists of multiple participants who each hold a distinct FROST share, and their contributions are combined to produce an aggregate NOIST signature. The NOIST quorum is then treated as an individual entity within the larger MuSig setup.

Our MuSig-nested-NOIST protocol facilitates seamless integration between these schemes, ensuring that FROST-derived shares within a NOIST quorum can be combined with independently held public keys in MuSig to generate aggregate signatures.

Check out the demo:

Have further questions? Join our Telegram Community Channel.

Covenant Emulation with Musig-nested-NOIST was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Brollup emulates covenants through a Musig-nested-NOIST protocol, relying on pre-signed signatures produced during highly interactive signing sessions.

A major drawback of interactive signing sessions is the vulnerability to denial of service (DoS) attacks. Protocols like Coinjoins, Ark, and Brollup (as an Ark variant) require participants to commit to signing transactions. If a participant fails to uphold their commitment, they are blacklisted, and the entire signing session must be restarted.

In on-chain Coinjoins, the barrier to launching a DoS attack is relatively low. To initiate an attack, an attacker only needs a UTXO, which is a fungible cost to hold. However, in off-chain protocols like Ark, the barrier is even lower, enabling attackers to own small VTXOs and disrupt rounds; every time a round is disrupted, the ASP must redo the entire process, including generating new digital signatures (e.g., to sign the tree). To address this, the dynamics surrounding connector outputs need to be reworked, possibly using something like MATT.

The situation is worsened by the compounding effect of external DoS vectors (from users) and internal DoS vectors (from malicious signatories), creating a perfect storm of disruptions. Each layer amplifies the other, making the system highly vulnerable.

Here’s a breakdown of the problem in different setups:

1. Single-server ASP:
   When the ASP is a single server, the system is a complete utter single point of failure. Entrusting 10+ figures to such a vulnerable setup is a non-starter.
2. FROST Quorum ASP:
   In a FROST quorum, generating a joint signature with a setup involving 999 signatories could take up to a minute under non-optimal conditions. If external DoS attacks are affecting rounds, this introduces significant delays. If both internal and external DoS attacks are in play, a single round could take several minutes to complete.
3. ROAST Quorum ASP:
   While a ROAST quorum is faster, producing a joint signature could still take up to 5–10 seconds under non-optimal conditions. Even a slight 2–3 second delay per round due to external DoS attacks makes this setup impractical for end-users. If both internal and external DoS attacks are in play, a round could take up to a minute, which is unacceptable.

NOIST to the Rescue

We have been working tirelessly to address the critical issues of DoS vulnerabilities and inefficiencies in interactive signing protocols. After extensive research and testing, we developed NOIST to overcome these challenges.

NOIST is designed to provide fast, secure, and reliable joint signatures, even in large-scale setups. By mitigating the impact of internal attacks with nonce preprocessing, NOIST ensures robust performance and scalability. It effectively neutralizes the impact of internal DoS attacks and guarantees to produce a valid joint signature in constant time, well under a second.

Here’s a demo of NOIST in production with 999 signatories, generating a valid BIP-340 aggregate signature in just one tenth of a second:

How About External Attacks?

Brollup (as an Ark variant) outperforms regular Ark in handling external DoS attacks (from users) due to its use of an account model, though this comes at the cost of privacy. Ark, being a privacy-focused protocol, relies on coin mixing to enhance the anonymity set. In Ark, VTXOs are unlinked and treated as independent entities, which allows them to be blacklisted one by one.

In contrast, Brollup operates without coins, relying solely on accounts for user identification and blacklisting. While Ark blacklists individual coins, Brollup blacklists accounts as a whole. This difference means that, on Ark, an attacker can disrupt rounds by owning small-value coins and blacklisting them one by one. However, on Brollup, the attacker can only disrupt using a single account.

With Brollup, we effectively trade off privacy for greater DoS resilience, while enabling smart contract utility.

Have further questions? Join our Telegram Community Channel.

Brollup: Built for DoS Resilience was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.

NOIST is a non-interactive, single-round t-of-n threshold signing scheme.

NOIST allows multiple untrusted entities to come together and jointly produce a group key and generate signatures in constant time, where a disruptive signer cannot force a re-do of the entire round. The resulting signature is a single 64-byte BIP-340 compatible Schnorr signature.

NOIST is specifically designed for Brollup to aggregate liquidity under a unified framework. Brollup operators operate through an internal consensus mechanism to; (1.) jointly control the liquidity, (2) co-sign vTXOs & virtual channels, and (3) advance the rollup state. To outsiders, they appear as a single entity with a well-known public key, resembling a single-sig server.

Key-features

1. Non-interactive
   FROST and ROAST signatories are required to run an uptime software instance (i.e., on a server) to participate in the signing rounds. NOIST, on the other hand, allows signatories to produce a partial signature using any software, with timing not being a concern. This is because partial signatures are guaranteed to produce a valid full signature at some point in the future.
2. Single-round
   FROST and ROAST require multiple rounds to produce a valid signature. In contrast, NOIST guarantees to produce valid signature in a single round, as long as at least t participants collaborate. A disruptive signer from the subset n-t cannot force a re-do of the entire round.
3. Mutability
   FROST and ROAST quorums are immutable once the shares are distributed. In contrast, NOIST allows signatories to add or remove participants or change setup parameters such as the threshold, as long as at least t participants collaborate. This keeps the group key unchanged while distributing new shares to the added members.

Watch the full video to learn more

Introducing NOIST: a non-interactive, single-round t-of-n threshold signing protocol was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Brollup allows us to introduce payable types and enables smart contracts to accept Bitcoin payments. Unlike Ethereum, however, smart contracts in the Brollup context do not hold custody of Bitcoin; instead, they facilitate atomic trades between two parties using introspective assertion logic.

Our payable construction enables non-Bitcoin asset types, such as collectibles, stablecoins, or even financial derivatives, to be atomically exchanged for Bitcoin. As outlined in the earlier announcement, this covers over 90% of DeFi use cases, whether it’s building an NFT marketplace, where the buyer pays with Bitcoin upon execution, or creating a decentralized order book, where the filler pays with Bitcoin upon execution.

And you may have been wondering whether it is also possible to build an AMM. The answer is yes!

First of all, it is certainly possible to build liquidity pools for token-to-token pairs, since this type of construction does not involve a Bitcoin payment; it involves swapping a non-Bitcoin asset for another non-Bitcoin asset.

Suppose we have a $PEPE token issued on Brollup, and our Italian overlords have also issued $USDT. We can deploy an AMM contract as follows:

With this contract, we can swap between $PEPE and $USDT or add/remove liquidity in a CPMM fashion. However, we can’t swap between $BTC and $PEPE because this contract does not support a payable construction.

To facilitate swaps involving the $BTC pair, we can create another contract designed for swapping $BTC and $USDT in an orderbook fashion, then route through the AMM contract to execute the $USDT -> $PEPE swap.

We can deploy a $BTC<>$USDT orderbook as follows:

With this contract, we can swap between $BTC and $USDT in an orderbook fashion. Due to $BTC <> $USDT being a primary trading pair, this contract is anticipated to be highly liquid.

Given that contracts can call each other, we can initiate the swap by first converting $BTC to $USDT through the orderbook contract, then route through the AMM contract to execute the $USDT -> $PEPE swap.

This setup allows us to execute the $BTC -> $USDT -> $PEPE route when swapping $BTC for $PEPE, or the $PEPE -> $USDT -> $BTC route when swapping $PEPE for $BTC. Either both contracts succeed, or the transaction terminates due to an asserted failure.

Can AMMs Be Built on Brollup? was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last week, I introduced Brollup, a Bitcoin-native rollup design that works with a native Bitcoin peg and does not require any changes to the Bitcoin protocol. The design, however, generally relied on a trusted setup, requiring at least one member to act honestly.

With some clever design adjustments, I’ve found a way to eliminate the need for the trusted setup. And now, presenting the v2 design!

Brollup v2 introduces a new state channel design and eliminates the need for a trusted setup by making the global state statechannel-aware. The core idea is to execute payable conditions based on state updates rather than creating new VTXOs. This decouples finality from block production and ties it directly to state updates.

This is similar to the Lightning Network; however, Lightning operates in a 2-of-2 setting, where only the involved parties are aware of the channel’s state. The channel state remains private, with outsiders gaining limited information only in the event of a force closure.

The strategy involves making channel states publicly accessible to everyone at all times. By publicly exposing channel content and ensuring accessibility at the DA layer, the global state becomes aware of individual channel states. Implementing this for all channels enables our Bitcoin Virtual Machine to verify payments between specific channels and execute payable conditions accordingly.

While one might expect storing channel content in the DA to consume a significant number of bytes, this isn’t the case! Brollup v2 employs an efficient approach where the only overhead comes from an 8 vByte signature commitment s by the operator. All other channel content can be derived from the calldata field outlined in my earlier announcement.

We can already determine the sender (msg.sender) and receiver (as asserted in the contract logic), along with their respective channel locations. Our channel design also avoids non-deterministic variables like in-flight HTLCs or PTLCs, allowing the entire channel content to be derived from the calldata alone. The only additional overhead is the 8 vByte signature commitment s from the operator, given that the signature nonce R chosen by the operator is also deterministic. This is all there is!

Covenant

Before delving into the channel specifics, let’s review the changes in the covenant setup.

In contrast to the design described in my earlier announcement, Brollup v2 removes kdc.signers (top 64k accounts) from enforcing the covenant, thereby reducing interactivity. Now, only msg.senders and the operator enforce the covenant, and the tree expires in 90 days instead of one week.

As the covenant expires in 90 days, accounts must refresh their VTXOs by sending coins to themselves every 90 days; otherwise, their coins can be taken, in theory, by the operator.

When accounts refresh their coins, they send coins to themselves, thereby participating in the same covenant setup that they enforce. In this case, the covenant cannot be violated. It is entirely sufficient for msg.senders to enforce the covenant themselves; breaking a covenant involving their own coins would be self-defeating for an owner.

When an account initially onboards, they receive their VTXOs within an onboarding tree that expires in 10 days. In this case, the covenant enforcing these coins is bound by another sender. Therefore, the account must refresh these coins into the default tree, which they own and control.

Brollup v2 makes it possible to establish a virtual channel from the VTXO. To enable this, a virtual UTXO is provided with two spending paths:

1. The Channel path
   This is a 2-of-2 path used by both the operator and the owner to establish a virtual channel.
2. The Claim path
   If the operator is uncooperative in setting up a channel, the owner can access coins from this path after the timeout.

Channel Design

Brollup channels are easy to reason about;

• No revocation: Each new channel state overwrites the previous one with higher precedence.
• No basepoints: It’s always the same key for to_self and to_operator. Keys are re-used without involving any point tweaking.
• No assymetry: Channel state is symmetric, reproducible, and always descend from the channel root.
• No middle-stages: No in-flight HTLCs or PTLCs. It is always about to_self and to_operator. Payments are linked through connectors.

Brollup channels operate as a 2-of-2 between to_self, which refers to the Brollup account itself, and to_operator. Both parties collaboratively sign state updates from the channel path to advance the channel state.

Unlike Lightning, Brollup channels do not use a revocation mechanism. Instead, each new channel state overwrites the previous one with higher precedence, rather than revoking it. This is similar to Eltoo; however, while Eltoo chains Bitcoin transactions together, we do not. A new channel state always descend from the channel root.

Brollup v2 utilizes a degrading relative timelock scheme to ensure that each new channel state has higher precedence than the previous one. By default, we use 64 degrading periods. The virtual channel output (channel:root) is a taptree with 64 leaves, where each tapleaf corresponds to a degrading period. Each period is a 2-of-2 between to_self and to_operator with a relative timelock, where the duration starts at 64 days and degrades by one with each subsequent period.

A user might choose to opt-in to more than 64 leaves, allowing the channel to accommodate more state updates throughout its lifetime. This comes with the tradeoff of increased waiting time in the event of unilateral closure, however, multiple layers of timelocks also serve as a means to provide everyone with a fair guarantee of unilateral exit in a mass-exit scenario, so this isn’t quite really a tradeoff. As for the on-chain footprint, the number of leaves scales logarithmically well for the control block.

A channel completes its lifetime either when 90 days have elapsed or 64 state transitions have occurred. The account then refreshes the virtual channel into a fresh, new tree. In the case where a channel has expired and not been refreshed, or the channel does not have enough liquidity, the account receives payments in the form of new VTXOs (within the onboarding tree).

Brollup v2 incorporates two type of payments:

1. P2VTXO (Pay-to-vtxo)
   For making payments from a channel to a brand-new VTXO.
2. P2SCOM (Pay-to-s-commitment)
   For making payments from a channel to another channel.

P2VTXO (Pay-to-vtxo)

P2VTXO (Pay-to-VTXO) involves making a payment from a channel to a VTXO. The sender swaps out their channel liquidity for a fresh new VTXO. The recipient receives a new VTXO within the onboarding tree, bound by the msg.sender. This occurs when the intended recipient is not yet onboarded or lacks sufficient inbound liquidity in their channels.

P2VTXO is a straightforward process:

1. The operator creates a round transaction by allocating 0.1 BTC to the recipient and adding a connector output to the msg.sender’s channel.
2. The msg.sender (to_self) and the operator (to_operator) sign a state update from the channel, pushing 0.1 BTC to the operator’s side in exchange for the atomic payment in the round transaction.

The connector output provided by the operator also commits to the calldata, ensuring the authenticity and atomicity of the contract execution.

P2SCOM (Pay-to-s-commitment)

P2SCOM (Pay-to-s-commitment) involves making a payment from a channel to another channel. The recipient receives their payment directly into their channel, rather than as a brand-new VTXO. This occurs when the intended recipient is already a user and has sufficient inbound liquidity in their channels.

In contrast to Lightning, the recipient can receive payments without needing to be online. The operator simply signs a channel update in favor of the recipient, pushing the value to the recipient’s side, and provides their version of the s commitment in the witness.

The operator, however, does not disclose the s value outright. Instead, the operator initially commits to the s value using a hashlock in the witness, proves with a zero-knowledge proof that the hashlock commitment is valid, and promises to reveal the actual s value afterward. This precaution is necessary to prevent the sender and recipient from colluding to steal funds from the operator by refusing to sign the channel update after obtaining the s value. Once the sender forfeits their channel liquidity by signing a state update, the operator reveals the s value directly in the witness.

As outlined in my earlier announcement, the calldata output is utilized as the change output for the operator, revealing the payload and now the s values in the subsequent transaction. With the new calldata output structure, the operator must now reveal the s values (in pushdata chunks) to access their change funds; otherwise, the output can be taken by the msg.senders :

Witness Elements:

1. <operator signature>
2. <s values in single chunk>
3. <0x01> // True

--------------------------------------------------------------------

Witness Script:

OP_IF

// Operator must reveal the s values to access their change

OP_HASH160
<s values commitment>
OP_EQUALVERIFY

<operator key>
OP_CHECKSIG

OP_ELSE

// Or otherwise this change becomes spendable by msg.senders[]

<24 hours>
OP_CHECKSEQUENCEVERIFY

<msg.senders[] aggregate key> // msg.senders pre-sign from this key
OP_CHECKSIG

OP_ENDIF

// Calldata is revealed regardless

OP_FALSE 
OP_IF 

<calldata> 

OP_ENDIF 

Nonce Selection

Picking signature nonces deterministically from a well-known basepoint is not safe, as it can lead to private key recovery. However, using different keys for the same nonce is safe against private key recovery, as long as the nonce remains secret and keys are unlinked.

Brollup v2 employs a unique approach to save 32 bytes for the signature nonce R by pre-selecting 64,000 nonces hardcoded in the client software, and re-assigning the to_operator key from a random entropy in every state transition. This approach involves using identical nonces with varying keys, rather than using identical keys with varying nonces.

The pool of 64,000 hardcoded nonces (that is 2MB!) effectively supports the potential creation of up to 1,000 new virtual channels, with each capable of accommodating a maximum of 64 state updates in each state transition.

What’s changed in v2?

1. ✅ No trusted setup
   State channel design eliminates the need for trusted setup.
2. ✅ Efficient liquidity
   State channel design leads to a more efficient use of liquidity.
3. ✅ Interactivity cut significantly
   Reduced interactivity due to the removal of kdc.signers from the set.
4. ✅ Longer liveness
   Our use of state channel enables a longer expiration period of 90 days.
5. ✅ Immediate finality
   Finality for payable executions no longer tied to block-production.
6. ❌ 8 vByte overhead
   Reduced TPS for payable executions due to an 8 vByte overhead.

New TPS Projections

Due to the 8 vByte overhead in payable executions, TPS projections for token order place & fill and nft auction list & sell have been reduced to 147 and 148, respectively. TPS projections for non-payable transaction types such as token transfers and nft transfers remain unchanged.

Conclusion

Brollup v2 is a net improvement over the earlier design. It makes liquidity more efficient, increases liveness, enables higher liquidity velocity, and most importantly, removes the need for a trusted setup — all without requiring a protocol change to Bitcoin.

Brollup provides an order of magnitude better user experience than Ethereum, operating natively on Bitcoin with BTC as the native gas asset.

Interested in learning more? Join our TG community channel!

State Channel Design was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Brollup is a rollup designed for scalable, Bitcoin-native smart contracts. A ‘true’ layer two with unilateral exit, Brollup ensures users retain full custody of their funds while rollup operators solely provide the service. No trusted setup. No 1-of-n trust assumption.

Brollup utilizes Bitcoin block space for data availability and incorporates a state channel model with global state. Operating in a layer-two setting, Brollup supports unilateral exit and does not rely on any trust assumptions.

Brollup is in a category of their own, neither optimistic, ZKP, nor sovereign. Brollup is deeply baked into Bitcoin and work natively with Bitcoin as a payable construct.

Brollup is operated by a quorum of operators. Operators provide liquidity to the protocol and advance the rollup state by chaining Bitcoin transactions at regular intervals.

Brollup uses the Bitcoin blockchain as the data availability layer, and run transactions on a virtual machine with a global state.

Brollup is build upon the concept of virtual UTXOs (VTXOs); simply enabling their use in smart contracts as payable constructs.

Brollup is, in short, coinswaps between VTXOs and calldatas.

Like how Ark Network swaps VTXOs for new VTXOs, Brollup swaps VTXOs for calldata (plus new VTXOs).

VTXOs are verifiable off-chain, and enforceable on-chain. Calldata, on the other hand, undergoes client-side validation; Bitcoin clients only see it as bytes, while Brollup clients read and interpret the bytes.

Since calldata is evaluated within the client-side validated context, and VTXOs are verifiable off-chain, a VTXO can be swapped for calldata that executes a payable condition in the smart contract.

Brollup combines calldata with VTXOs to execute payable contract conditions, where, for example, the contract can grant tokens to the msg.sender in exchange for paid Bitcoin, with the location of the payment VTXO derived from the calldata.

This covers >90% of DeFi use-cases, whether it’s listing an NFT for sale in exchange for Bitcoin, where the buyer pays with Bitcoin upon execution, or placing a token sell order on a decentralized exchange, where the filler pays with Bitcoin upon execution. All atomically executed, verifiable, scalable, and enforcable on Bitcoin.

Simply put, Brollup extends upon VTXOs and utilize them as payables.

TPS Projections

Brollup scales exceptionally well in terms of transactions executed per second (TPS). This efficiency is attributed to the effective use of data availability, which can be categorized into three key areas:

1. Compact DA Encoding
   Brollup employs a compact DA encoding structure with bit-level commitments to efficiently store transactions.
2. Signature Aggregation
   Brollup aggregates signatures by summing the nonces and commitments, rather than aggregating signatures using ZKPs.
3. Virtual UTXOs
   Brollup works with virtual UTXOs instead of bare UTXOs. This means Brollup consume almost no on-chain footprint for payable referencing.

Brollup vs. PSBTs

An on-chain Ordinals PSBT trade consumes roughly ∼330 vBytes, whereas the entire process of trading an NFT on a Brollup marketplace, from listing to selling, consumes only 3.25 vBytes. This means that trading NFTs on Brollup is 100x times more scalable than trading with PSBTs.

Brollup vs. Omni

An on-chain Omni Layer token transfer consumes roughly ∼250 vBytes, whereas transferring tokens on Brollup consumes only 2.21 vBytes. This means transferring tokens on Brollup is 110x times more scalable than transferring on Omni Layer.

Contract Example— NFT Marketplace

This is an example NFT marketplace contract that can be run on the Bitcoin Virtual Machine, containing three callable methods:

1. nft_auction_list
   msg.sender (Alice) calls this method to list her piece for sale, providing two arguments: her NFT contract address (Contract) and price tag (u32).
2. nft_auction_buy
   msg.sender (Bob) calls this method to buy Alice’s piece, providing an argument and a payment: Alice’s NFT contract address (Contract) and the Bitcoin payment (Payable).
3. nft_auction_cancel
   msg.sender (Alice) calls this method to cancel her listing if no one is interested in buying her piece, providing one argument: her NFT contract address.

The Covenant

Brollup uses Musig-nested-NOIST to emulate covenants. The two involved parties in the covenant setup are:

1. Operator Key
   The Brollup operator is a NOIST quorum of thousands of signatories. The quorum members jointly sign with their FROST shares to contribute to the broader Musig-nested covenant.
2. msg.senders[] Aggregate Key
   Accounts that transact on the Brollup (msg.senders) each sign with their key to constrain virtual UTXOs. All individual msg.sender keys are aggregated into a single key in coordination with the operator.

Forfeiting

To call a payable smart contract and pay transaction fees on Brollup, msg.senders atomically swap their VTXOs for new VTXOs through a process known as forfeiting.

To forfeit a VTXO, the owner (msg.sender) signs the VTXO outpoint together with the connector provided by the operator. The outpoint reference of the provided connector commits to three areas:

1. Calldata
   Forfeited VTXOs commit to calldata, encoded in the witness of the calldata output (the payload). This ensures the atomicity of the committed data whether its a contract call or a contract deployment.
2. Payable VTXOs
   Forfeited VTXOs commit to new VTXOs, similar to vanilla Ark payments. In the Brollup context, however, these VTXOs serve as payable constructs in smart contracts, as they are verifiable off-chain without additional DA overhead (the location is derived from calldata).
3. Transaction fees
   Forfeited VTXOs commit to transaction fees that are distributed among miners, the operator, and kdc.signers, in accordance with feeconomics.

Calldata outputs are utilized as the change output for the operator, revealing the payload they contain in the subsequent transaction. The calldata output contains the following script:

// Store calldata in the witness
OP_FALSE
OP_IF

OP_PUSHDATA
<CALLDATA>

OP_ENDIF

OP_IF

// The operator uses this as the change output for the next round.
<operator key>
OP_CHECKSIG

OP_ELSE

// The otherwise this becomes anyone-can-spend. 
// This encourages the operator to keep its operations running without interruption.
<24 hours>
OP_CHECKSEQUENCEVERIFY

OP_ENDIF

Account Model

Brollup operates on an account-based model, where Nostr public keys function as the designated accounts. Much like Ethereum addresses, Nostr keys serve as the dedicated identifiers through which users interact and transact on the network.

To facilitate efficient transactions and minimize blockspace usage, accounts are indexed and identified by their index numbers, similar to the data encoding scheme used in optimistic rollups.

Initially, a large list of existing Nostr keys will be indexed and hardcoded into the npub directory of Brollup clients. This allows Brollup clients to access and reference accounts using their compact index numbers.

As new users transact, their accounts are automatically appended to the npub directory for efficient referencing later. This efficient referencing occurs during the bit-encoding process of the payload.

Compact Payload Encoding (CPE)

Transactions on Brollup are referred to as entries. An entry either calls a smart contract or deploys a new contract.

Brollup employs a compact payload encoding structure with bit-level commitments to efficiently store entries. Entries are sequentially encoded within the payload, followed by the aggregate signature.

Brollup aggregates signatures by summing the signature nonces and commitments, similar to how ZK rollups aggregate signatures using ZKPs. This aggregation occurs during the entry signing session in coordination with the operator.

The payload is split into 520-byte chunks and stored directly in the witness;

OP_FALSE
OP_IF

OP_PUSHDATA
<chunk_1>

OP_PUSHDATA
<chunk_2>

...

OP_PUSHDATA
<chunk_n>

OP_ENDIF

Entries contain the following fields in the payload encoding:

1. account index
2. contact index
3. method call
4. calldata

Account Index

Accounts are indexed by their rank, which is determined by how frequently they transact. First two bits of the account index maps to four different index tiers;

00 -> this an unregistered account, followed by the 256-bits x-only npub.
01 -> this a registered frequent account, top-65025 on the rank. followed by the 16 bits index number.
10 -> this a registered non-frequent account, between 65025–16646400 on the rank. followed by the 24 bits index locator number.
11 -> this a registered non-frequent account, between 16646400–4244897025 on the rank. followed by the 32 bits index locator number.

account index is followed by the contract index;

Contract Index

Contracts are indexed by their rank, which is determined by how frequently they are called. First two bits of the contract index maps to four different index tiers;

00 -> this is a contract deployment, followed by the contract bytecode starting with the varint prefix.
01 -> this is a frequent contract, top-64 on the rank. followed by the 6-bit index number.
10 -> this is a non-frequent contract, between 64–65089 on the rank. followed by the 16 bits index locator number.
11 -> this is a non-frequent contract, between 65089–1061208000 on the rank. followed by the 30 bits index locator number.

contract index is followed by the method call, if it is not 0b00.

Method Call

Method calls are indexed based on their written order when the IDE compiles the contract into bytecode. First bit of the method call maps to two different index tiers;

0 -> index of the called method is #4 or less, followed by the 2-bit index number.
1 -> index of the called method is between #4 — #20, followed by the 4-bit index locator number.

method call is followed by the calldata.

Sessions

A Brollup state transition involves four subsequent sessions;

1. Entry Signing Session;
   This session sums individual signatures from msg.senders of the round and results in an aggregate signature to authorize the payload.
2. KDC Session
   This session sums individual signatures from the top 16,384 accounts by their rank and results in an aggregate signature to constrain payable VTXOs to the shared output.
3. Covenant Signing Session
   This session sums individual signatures from msg.senders of the round and results in an aggregate signature to constrain payable VTXOs to the shared output.
4. Forfeiting Session
   This session forfeits VTXOs from msg.senders of the round to cover transaction fees and payable VTXOs.

Entry Signing Session

Accounts that are initiating calls or deploying contracts initially participate in this session to aggregate their signatures in coordination with the operator. This session employs a straightforward, single-round aggregation scheme where each msg.sender signs their own version, with the signature committing to H(m) rather than H(R || P || m). This allows the operator to simply sum all signatures in a single round. The resulting signature is a 64-byte Schnorr signature, which is batch-verified within the Brollup context.

  +--------------+                                      +--------------+
  |              |--(1)---       entryCtx         ----->|              |
  |              |<-(2)---       entryAck         ------|              |
  |              |                                      |              |
  |  msg.sender  |     // wait until the operator       |   operator   |
  |              |     // aggregates all entries        |              |
  |              |                                      |              |
  |              |<-(3)---      payloadCtx        ------|              |
  +--------------+                                      +--------------+

(1) msg.sender creates a entryCtx, and requests to join the round;

let entryCtx = (prevHash, npub, entry, sig), where;

• prevHash is the hash of previous Brollup state
• nsec is secret key of the msg.sender
• npub is the public key of the msg.sender; nsec • G
• entry is the non-compact bytecode of the entry that msg.sender intends to transact;

account id (32 bytes) || contract id (32 bytes) || method call (1 byte) || calldata (varsize)

• let message = TaggedHash(bytes(prevHash || entry), “SighashEntry”)
• let nonce = TaggedHash(bytes(message || nsec), “DeterministicNonce”)
• let sig = (nonce • G, (nonce + message • nsec) mod n)

(2) operator responds with an acknowledge message, entryAck.

(3) The operator gathers all entries, sums the signatures, and responds with payloadCtx;

• let aggpub = nsec1 • G + nsec2 • G .. nsecN • G
• let aggmsg = m1 + m2 .. mN
• let aggnonce = 𝑘1 • G + 𝑘2 • G .. 𝑘N • G
• let aggcmt = (𝑘1 + m1 • nsec1) + (𝑘2 + m2 • nsec2) … (𝑘N + mN • nsecN)
• let aggsig = (aggnonce, aggcmt)
• let payloadCtx = (prevHash, npubs[], entries[], fee, aggsig)

At the end of the round, based on the list of entries[] and the fee provided, msg.senders can deterministically see the outcome of their execution and determine the precise amount they need to pay for the execution.

If the outcome of the execution results in an asserted failure in the contract logic, the msg.sender is removed from the round. This prevents failed transactions from being included in blocks, thereby saving space and fees.

KDC Session

A Key-Deletion-Covenant session, or KDC session for short, gathers signatures from the top 16,384 accounts by their rank and results in an aggregate signature to constrain payable VTXOs to the shared output. If at least one of the 16,384 accounts is honest, the covenant holds true. The information about which of the top 16,384 accounts participated in the KDC session is encoded in a compact field called bitmap.

Bitmap

Bitmap is a compact 16,384-bit-long bitstring that maps to the participants of the KDC session. Each bit indicates whether the nth account by rank participated in the session. Bitmap is stored in the annex of the first prevout, consuming a discounted space of 256 vBytes in each state transition.

1st bit: 0 -> Account #1 by rank did not participate in the KDC
2nd bit: 1 -> Account #2 by rank did participate in the KDC
3rd bit: 1 -> Account #3 by rank did participate in the KDC
4th bit: 0 -> Account #4 by rank did not participate in the KDC
5th bit: 1 -> Account #5 by rank did participate in the KDC
.
.
.
16,384th bit: 1 -> Account #16384 by rank did participate in the KDC

It is possible to map from bitmap to an array of signers kdc.signers[] using a function bitmapToSigners();

• let bitmapToSigners(bitmap) => kdc.signers[]
  For each bit in the bitmap, output the array of signers kdc.signers[];
  1 -> kdc.signers.push( npub_directory[ iterator++ ] )
  0 -> iterator++

It is possible to compute aggregate KDC key aggkey by summing the npubs of kdc.signers[];

• let keyaggCtx = KeyAgg( kdc.signers[] ) => (Q, gacc, tacc)
• Let (aggkey, _, _) = keyaggCtx

  +--------------+                                      +--------------+
  |              |--(1)---     covenantCtx        ----->|              |
  |              |<-(2)---      pubnonce          ------|              |
  |              |                                      |              |
  |              |     // wait until the operator       |              |
  |              |     // aggregates all pubnonces      |              |
  |              |                                      |              |
  |   operator   |--(3)---       kdcCtx           ----->|  kdc.signer  |
  |              |<-(4)---     partialsig         ------|              |
  |              |                                      |              |
  |              |    // wait until all signers         |              |
  |              |    // respond with partial sigs      |              |
  |              |                                      |              |
  |              |--(5)---       aggsig           ----->|              |
  +--------------+                                      +--------------+

(1) operator prepares and responds with covenantCtx;

let covenantCtx = (outpoint_self, spks[], values[]), where;

• outpoint_self is the prevout that contains the aggregate key, from which msg.senders aim to produce an aggregate signature.
• spks[] is an array of scriptPubKeys containing the payable VTXOs
• values[] is an array nValues containing the payable VTXO amounts.

(2) kdc.signer prepares and responds with pubnonce;

• let (secnonce, pubnonce) = NonceGen(nsec, npub)

(3) operator responds with kdcCtx, containing the aggregate nonce aggnonce and compact list of signers bitmap;

• let kdcCtx = (aggnonce, bitmap)
• let aggnonce = NonceAgg(pubnonce1 .. pubnonceN) => aggnonce

(4) kdc.signer signs and responds with partial signature partialsig;

• let kdc.signers[] = bitmapToSigners(bitmap) -> kdc.signers[]
• let sighash = ReturnSighashCov(covenantCtx)
• let sessionCtx = (aggnonce, kdc.signers[], sighash)
• let partialsig = Sign(secnonce, nsec, sessionCtx) => partialsig

(5) operator responds with aggregate signature aggsig;

• let aggsig = PartialSigAgg(psig1 .. psigN, sessionCtx) => aggsig

Covenant Signing Session

Accounts that pass the entry signing session move into this session to constrain payable VTXOs to the shared output. This session employs a Musig2-based two-round aggregation scheme, where msg.senders aim to produce an aggregate signature from the aggregate key. The resulting signature is a 64-byte valid BIP-340 Schnorr signature.

  +--------------+                                      +--------------+
  |              |--(1)---      signerCtx         ----->|              |
  |              |<-(2)---     covenantCtx        ------|              |
  |              |--(3)---      pubnonce          ----->|              |
  |              |                                      |              |
  |              |     // wait until the operator       |              |
  |              |     // aggregates all pubnonces      |              |
  |  msg.sender  |                                      |   operator   |
  |              |<-(4)---      aggnonce          ------|              |
  |              |--(5)---     partialsig         ----->|              |
  |              |                                      |              |
  |              |    // wait until all signers         |              |
  |              |    // respond with partial sigs      |              |
  |              |                                      |              |
  |              |<-(6)---       aggsig           ------|              |
  +--------------+                                      +--------------+

(0) Given payloadCtx from the earlier session, msg.sender computes the aggregate key aggkey;

• let (prevHash, msg.senders[], _, _, _) = payloadCtx
• let keyaggCtx = KeyAgg(msg.senders[]) => (Q, gacc, tacc)
• Let (aggkey, _, _) = keyaggCtx

(1) msg.sender joins the round with signerCtx;

• let signerCtx = (prevHash, npub)

(2) operator returns covenantCtx;

let covenantCtx = (outpoint_self, spks[], values[]), where;

• outpoint_self is the prevout that contains the aggregate key, from which msg.senders aim to produce an aggregate signature.
• spks[] is an array of scriptPubKeys containing the payable VTXOs
• values[] is an array nValues containing the payable VTXO amounts.

(3) msg.sender prepares and responds with pubnonce;

• let (secnonce, pubnonce) = NonceGen(nsec, npub)

(4) operator aggregares pubnonces, and responds with aggnonce;
NonceAgg(pubnonce1 .. pubnonceN) => aggnonce

(5) msg.sender signs and responds with partial signature partialsig;

• let sighash = ReturnSighashCov(covenantCtx)
• let sessionCtx = (aggnonce, aggkey, sighash)
• let partialsig = Sign(secnonce, nsec, sessionCtx) => partialsig

(6) operator responds with aggregate signature aggsig;

• let aggsig = PartialSigAgg(psig1 .. psigN, sessionCtx) => aggsig

Design Considerations

Determinism

The Bitcoin Virtual Machine (BVM) aligns more heavily on p2p use-cases such as atomic trades between two parties. Smart contracts in this context act as facilitators of these interactions.

While it’s also feasible to construct more complex contracts such as AMMs for token-to-token swaps that operate out-of-band and aren’t atomic, BVM transactions are deterministic, meaning the transaction outcome is determined upon creation. In contrast, EVM transactions rely on their ordering, which exposes them to risks like MEV.

Even Brollup operators themselves cannot modify transaction ordering through additional fees; Brollup is designed with a rank-based ordering system where higher-ranked accounts are given priority. Every entry in a payload pays an equal fee for the same execution.

Although higher-ranked accounts are prioritized in the ordering, front-running is not feasible for them either, since there is no mempool to track transactions; operators gather and aggregate transactions themselves.

Gas & Failures

Given the deterministic nature of transaction outcomes, the msg.sender knows in advance whether the transaction will succeed or fail before entering the forfeiting session where fees are paid. Likewise, the msg.sender is aware in advance of the exact amount of transaction fees to be paid.

Internal State

Given the inherent design of operators chaining Bitcoin transactions together, each state-transition is interconnected. A msg.sender knows in advance the specific Brollup payload height at which their transaction will be included, eliminating the need for tracking internal state. Consequently, a nonce field is not required in the entry encoding.

DoS, Blaming & Blacklists

• A kdc.signer can interrupt a KDC signing session. This leads to a redo of the earlier Entry signing session. kdc.senders, however, are each part of a well-known list of top accounts by their rank. Their behaviors can be further analyzed, and they can be temporarily or permanently blacklisted by the operator.
• A msg.sender can interrupt a covenant signing session or a forfeiting session, resulting in a redo of the affected sessions. Their behaviors can be further analyzed, and they may be temporarily or permanently blacklisted by the operator. A blacklisted account might be required by the operator to place a refundable collateral bond in advance of participating in further sessions. The required bond amount varies according to the rank of the account.
• A permanently blacklisted account can still transact without needing permission from the operator. This is because an account does not require an operator to transact on the Brollup; they can execute transactions by incorporating their own version of the on-chain transaction and placing calldata in the respective fields. A Brollup operator acts solely as an aggregator and liquidity provider, facilitating efficient transactions at scale.

Conclusion

Brollup is a Bitcoin-native rollup design that operates with a native Bitcoin peg and does not require protocol changes to Bitcoin. Brollup brings over 90% of DeFi use cases natively to Bitcoin and further scale Bitcoin usage.

Brollup is currently under development, and the project is not associated with any issued tokens.

Interested in learning more or contributing? You should definitely join our TG community channel! Alternatively, you can reach out me on X or Nostr.

Introducing Brollup was originally published in Brollup on Medium, where people are continuing the conversation by highlighting and responding to this story.