Mempool-less by design: how DSPE removes ordering discretion

In most chains, whoever builds the block decides the order of transactions. Cubane replaces that decision with a function: admission is order-blind, the pool freezes at each tick, and the canonical order is computed, never chosen.

The problem with a choice

In most blockchains, a transaction does not go straight from your wallet into a block. It waits in a mempool, a shared buffer of pending transactions, until a block producer picks it up. The producer then decides which transactions to include and in what order. That decision has economic value. Whoever controls ordering can place their own transaction ahead of yours, behind yours, or on both sides of it.

The industry has responded in several ways: private relays, order-flow auctions, encrypted mempools, proposer-builder separation. Each of these manages the value of the ordering decision. None of them removes the decision itself. Somebody, somewhere, still chooses.

Cubane takes a different position. Ordering is not a decision that any participant makes. It is the output of a deterministic function whose inputs are fixed before anyone can act on them. This article explains how that works, layer by layer, and what it means for the people who submit transactions and the validators who agree on them.

Three authorities that never overlap

The Cubane transaction pipeline is split across three layers, and each one holds exactly one kind of authority. L0, handled by JetRay, owns admission: it decides whether a transaction is allowed in. L1, handled by DSPE, owns serialisation and execution: it decides the order and computes the resulting state. L2, handled by CCCM, owns validation and finality: it checks proofs and makes the result permanent.

The important part is not what each layer does, but what each layer is forbidden to do. JetRay never orders. DSPE never influences who votes. CCCM never modifies execution output and never reorders serialised transactions. Tick boundaries are set by consensus, not by execution. These are written as mandatory invariants, not guidelines, and no single entity controls ingress, ordering, validation and finality together.

Separating authority this way closes the gaps that ordering games usually exploit. A validator who can admit, order and finalise has every lever needed to extract value from users. A validator who can only check a proof has none.Three authorities, no overlap

L0

JetRay: admission onlyValidates signatures, fees and rate limits. Never orders.

L1

DSPE: serialisation and executionSole ordering authority; executes and produces proofs. Never selects validators or moves tick boundaries.

L2

CCCM: validation and finalityVerifies proofs, votes and finalises. Never modifies output or reorders.The pipeline, end to end

01

Intake (L0, JetRay)Signature, fee, nonce and rate-limit checks. Accept or reject. No ordering decisions.

02

Tick freezeAdmission closes. The pool is frozen and hashed independently of arrival order.

03

Canonical order (L1, DSPE)A four-key deterministic sort produces the order and the serialisation hash.

04

Parallel execution (L1, DSPE)Conflict-free transactions run in parallel lanes; effects commit in canonical order.

05

State Transition UnitAn immutable artefact with 13 bound fields, including roots and proof.

06

Cube validation (L2, CCCM)Eight-node cubes verify the proof and vote. They cannot change the result.

07

Finality (L2, CCCM)Cube commits are aggregated into a tick root and finalised.

Admission is order-blind

JetRay is the front door. When a transaction arrives, it checks the signature, the fee, the nonce and the replay window, and applies rate limits at the global, per-sender and per-route level. It then either accepts the transaction into the current tick’s admission pool or rejects it with a typed error.

JetRay also assigns transactions to admission lanes, such as priority, fast and standard. It is worth being precise about what a lane does. Under congestion, a lane changes the probability that a transaction is admitted. It does not change where that transaction will sit in the final order. The admission pool that JetRay produces is unordered by design.

There is no global mempool behind this. Admission pools are scoped to a single tick, and nothing survives past the tick boundary in a hidden buffer. A transaction that is not admitted waits at the door; it does not wait in a queue that someone else can inspect and front-run.

The freeze

At each tick boundary, admission closes and the pool is frozen. The frozen pool is identified by a hash computed over the tick identifier and the sorted hashes of every transaction in it.

The sort is bytewise and happens before hashing. That detail carries real weight. Two nodes that received the same transactions in different orders, because of network latency or deliberate manipulation, will compute the same pool hash. Arrival order, the raw material of most front-running, is erased at this step.Arrival order is erased

01Node A receivestx3, tx1, tx2 in that order

02Node B receivestx2, tx3, tx1 in that order

03Bytewise sortBoth sort hashes before hashing the pool

04Same pool hashIdentical commitment on every honest nodeTick freeze

pool_hash = H(tick_id || sort_bytewise(all_tx_hashes))

// identical tx sets, any arrival order
// -> identical pool_hash on every honest node

The canonical order is computed

Once the pool is frozen, DSPE sorts it with four keys applied in a fixed order of precedence. The first key is the SLA lane, from the highest declared and bonded tier to the lowest. The second is HTLC maturity, oldest commitment first, so that time-sensitive contracts are not starved. The third is the effective fee after normalisation. The fourth is a tie-break derived from the epoch’s verifiable random function, which no participant can predict or bias.

The result is hashed together with the tick identifier and the previous state root to produce the serialisation hash. That hash identifies the order uniquely. If any node, cube or leader presents a different order for the same tick, the difference is detectable immediately.

Note what the function does not accept as input: a proposer’s preference. There is no parameter through which a leader can express one. The leader’s role in a cube is to coordinate vote collection, and the leader is required to apply the canonical ordering function exactly.Canonical order

ordered = sort(frozen_pool, keys in precedence:
  1. sla_lane        // descending, declared and bonded tier
  2. htlc_maturity   // ascending, oldest commitment first
  3. effective_fee   // descending, normalised
  4. vrf_tiebreak    // epoch VRF output
)

serialization_hash = H(tick_id || ordered || previous_state_root)

State as a pure function

The single most important invariant in the pipeline is this: the new state root is a pure function of exactly two inputs, the previous state root and the serialisation hash. Given the same two inputs, every honest node produces the same output. There is no wall-clock dependency, no floating-point reduction and no non-deterministic system call anywhere on the path.

This makes the whole chain replayable from genesis. It also gives a clear definition of misbehaviour. If a node’s result differs from the function’s output, the node is wrong, and the difference can be shown.

Ordering is a function, not a choice. No proposer input exists in its signature.

Read and write sets come first

Before a transaction executes, DSPE needs to know which state it will read and which it will write. These read and write sets are either declared by the developer (through the workload descriptor and compiler) or inferred deterministically from the state addresses involved. Either way, they are fixed before execution begins.

This rule has two consequences. The first is safety: a write to state the transaction has not declared or cannot be shown to own is rejected, not quietly allowed. Branching that changes write targets based on state at runtime is disallowed. That closes off a class of reentrancy and ownership problems at the source.

The second is liveness for ordinary users. A retail wallet that declares nothing still works. Every missing declaration falls back to a conservative derivation that may serialise more than strictly necessary, but never rejects a transaction for being silent. Developers who declare precise sets gain concurrency; users who declare nothing keep compatibility.

Parallelism inside the function

With the order and the read and write sets fixed, DSPE builds a conflict graph. Two transactions conflict when one writes state the other reads or writes. Transactions with no conflicts between them are placed on the same level of the graph and can run at the same time.

Execution proceeds level by level across bounded parallel lanes, eight by default. Each level ends at a barrier. Within a level, results are committed strictly in canonical order, regardless of which lane finished first. A slow lane can delay its own level; it cannot change the outcome.

This is why parallel execution is treated as an optimisation inside the function rather than an input to it. Removing every lane and running serially must produce the same post-state. Lane count is a throughput hint, never a semantic input, and the determinism discipline tests exactly that.Level schedule

Level 0:  [tx1] [tx2] [tx3] [tx4]   // run in parallel
          barrier, commit in canonical order
Level 1:  [tx5] [tx6]
          barrier, commit in canonical order
Level 2:  [tx7] [tx8] [tx9]

What validators actually do

Once execution completes, DSPE packages the result into a State Transition Unit. The STU binds 13 fields together, including the chain, namespace, shard, cube and tick identifiers, the prior and new state roots, the root of the ordered transactions, the execution hash, the zero-knowledge proof, the approved circuit hash and the data-availability commitment. Every proof is bound to its context, so a proof from one chain or tick cannot be replayed on another.

The STU enters an eight-node cube. Member nodes and transaction inspector nodes verify the proof and the state-root consistency, then sign. A cube commits when at least six of eight votes are cast, including at least three from member nodes. The leader coordinates and aggregates signatures but does not vote. Cube commits are then aggregated across shards into a tick root and finalised.

At no point in this sequence can a validator alter the order or the state. Validators verify proofs of correct execution; they do not re-decide it.Who holds which authority

Actor	Admit	Order	Execute	Vote	Finalise
JetRay	Yes	No	No	No	No
DSPE	No	Sole authority	Yes	No	No
Cube leader	No	Applies the function	Yes	No, aggregates	No
Member node	No	No	Yes	Stake-weighted	No
Inspector node	No	No	Validates proof	Yes	No
CCCM	No	No	No	Validates	Yes

Reordering and censorship become evidence

Because the frozen pool and the canonical order are both committed by hash, deviations leave a trail. If a transaction was admitted and frozen but is missing from the ordered set, that is recorded as a censorship violation, with the pool hash as proof. If an ordering differs from the function’s output, that is a reorder violation. Both feed directly into slashing.

In other words, the system does not rely on validators choosing to behave. It removes the choices that misbehaviour would need, and turns any remaining attempt into verifiable evidence.

What the design does and does not claim

This design removes ordering discretion. It does not remove every form of advantage. A participant who pays a higher fee still gains priority through the fee key, and a participant on a declared, bonded SLA tier is canonically earlier than one on a standard lane. Those advantages are explicit, priced and visible in the function, rather than negotiated privately with a block producer.

For builders, the practical takeaway is simple. Declare your read and write sets precisely and you get more parallelism. Choose your lane deliberately, because that is the only lever over position. Everything else about ordering is computed, the same way, on every node.