Status

Draft. No backwards compatibility. No flag day.

Activated at the genesis of the new final Lux network: **2025-12-25

16:20 Pacific (unix 1766708400)**. The pre-Quasar Edition Lux network

(2020–2025) is a separate network and is out of scope.

Abstract

LP-204 organises state into Tier-2 chain-VMs running on a parent L1

(Tier-1). When a tx group's state touches multiple chain-VMs, the wave

commits at each shard are independent under LP-209/210 — there is no

intrinsic atomicity across shards. LP-211 supplies that atomicity.

The mechanism is cross-shard 2PC via a parent-L1 QuasarCert. A

coordinator (one of the parent L1's validators, selected deterministically

per cross-shard tx group) dispatches per-shard portions to shard

executors, collects prepare-acks (LP-210 Phase 4 staged-prepare), and

when all shards have prepared, submits a cross-shard commit tx to the

parent L1. The parent L1's next wave (LP-209) includes that commit tx;

the wave's LP-217 cert is the cross-shard cert. Once the parent L1's

cert finalises, every shard's prepared overlay is committed atomically.

If any shard refuses to prepare (coordinator timeout, validity failure,

slashable equivocation), the coordinator submits a cross-shard abort tx

instead; every prepared shard unwinds its staged overlay via LP-202

txn.Discard(). ALL shards commit OR NONE — the LP-202 atomic-unwind

contract makes this O(1) at each shard.

The latency dividend: per-shard waves continue at the LP-209 cadence

(~100 ms LAN); the cross-shard cert adds one parent-L1 wave (~100 ms

LAN) plus the LP-217 cert mode timing (~5 ms at PQ-strict). Total

cross-shard latency: ~200 ms at LAN scale at PQ-strict. The throughput

dividend: each shard's waves run independently except for the cross

-shard txs, which by construction are a minority of the workload (in

securities-chain traffic: ~5%). The 95% intra-shard waves commit at the

LP-210 single-shard rate; the 5% cross-shard waves pay the 2PC tax.

Why PQ-heavy cert, not a sidechain mechanism

A naive cross-shard atomicity mechanism uses a sidechain or a relay

validator set. LP-211 instead uses the **parent L1's existing

QuasarCert** as the atomic-commit anchor. The parent L1 already has a

validator set; LP-204's chain-VMs inherit the parent's security

automatically. The parent L1's cert at LP-217's chosen mode is the

strongest cryptographic statement available on the network — using it

for cross-shard commit means cross-shard finality is exactly as strong

as the parent L1's finality at that mode.

No new validator set. No new bridge contract. No new dispute window. The

cert that the parent L1 already publishes per wave serves as the

cross-shard commit anchor. The shards prepare; the parent L1 commits;

the cert covers the commit.

This is the canonical pattern from LP-204 §Cross-tier primitives, row 2

("Cross-VM atomic memory") elevated to a wave-scale formal protocol.

Algorithm

Step 0 — coordinator selection

A cross-shard tx group T = {T_1, ..., T_K} where each T_j is the

per-shard portion targeting shard s_j. The coordinator is a parent-L1

validator selected deterministically:

coordinator(T) = parent_L1.validators[ hash(T.id) mod N ]

where T.id = sha256(canonical_bytes(T)). The selection is a pure

function of the tx group; every shard executor agrees on the

coordinator without coordination.

Step 1 — dispatch

The coordinator gossips T via the parent L1's LP-201 DHT, schema 0xE3

(CrossShardDispatch — see Wire schemas below). Each shard s_j whose

NodeID is subscribed to the parent L1 receives T and dispatches T_j

into its local mempool.

Step 2 — per-shard prepare

Each shard s_j executes T_j under LP-209/210 normally:

1. T_j enters the shard's LP-208 DAG mempool.

2. The shard's LP-209 wave commits a wave containing T_j.

3. LP-210 Phase 4 detects that T_j is cross-shard (`T_j.txEnvelope.kind

== cross_shard`) and stages the overlay instead of committing.

4. The shard publishes a prepare-ack: schema 0xE4 (CrossShardPrepareAck)

containing (T.id, s_j, T_j.state_diff_hash, shard_wave_cert).

The shard_wave_cert is the per-shard LP-217 cert at the shard's

configured mode — proof that the shard committed to executing T_j at

the shard's per-wave consensus. The cert leg presence/absence per LP-217

governs the strength.

Step 3 — coordinator collect

The coordinator subscribes to prepare-acks on the parent L1's gossip

layer. It collects acks until either:

• All K acks arrive within prepare_timeout_ms → emit cross-shard

commit tx (Step 4).

• Any shard times out or refuses (returns refuse-ack schema 0xE5)

→ emit cross-shard abort tx (Step 4').

prepare_timeout_ms defaults to 5× the slowest shard's wave cadence

(typical: 500 ms LAN, 2000 ms WAN). The timeout is conservative — under

healthy operation, all acks arrive within 1× wave cadence.

Step 4 — cross-shard commit tx at parent L1

The coordinator submits to the parent L1's LP-208 mempool:

CrossShardCommit {
    group_id:     [32]byte  T.id
    shards:       []ShardCommit  // per-shard: (chain_id, state_diff_hash, wave_cert)
    coordinator:  NodeID
    coord_sig:    []byte  // BLS or PQ per parent L1 cert mode
}

The parent L1's next LP-209 wave includes this tx. The wave's LP-217

cert covers the cross-shard commit. Once the parent L1's cert

finalises:

1. Each shard observes the parent L1's cert (gossip schema 0xE6

CrossShardCommitNotify from any parent-L1 validator).

2. Each shard verifies the cert covers T.id and that the cert's leg

composition satisfies the shard's cert-mode policy.

3. Each shard applies its staged overlay via LP-202 atomic commit. Done.

Step 4' — cross-shard abort tx at parent L1

If any shard refused or timed out, the coordinator submits:

CrossShardAbort {
    group_id:     [32]byte  T.id
    reason:       enum {timeout, shard_refused, coordinator_replaced}
    coordinator:  NodeID
    coord_sig:    []byte
}

The parent L1's next wave includes this tx; the cert covers the abort;

each shard observes via gossip and unwinds its staged overlay via LP-202

txn.Discard(). The cross-shard tx group is dropped; per-shard waves

move forward independently from the next round.

Step 5 — atomicity invariant

The cross-shard commit/abort cert is the single point at which all

shards observe the same outcome. Before the parent-L1 cert: each shard

holds a staged overlay; no observable state change. After the parent-L1

cert: every shard has either committed (commit path) or unwound (abort

path); no half-state.

Concretely: any external observer (light client, indexer, bridge)

queries the parent L1 first to learn T.id's outcome. If the parent L1

has finalised a CrossShardCommit(T.id) cert, every shard MUST present

the committed state for T_j to the observer (or the shard is byzantine

and slashed at the parent L1). If the parent L1 has finalised a

CrossShardAbort(T.id) cert, every shard MUST present pre-T_j state.

Wire schemas

LP-211 introduces five new ZAP wire schemas, allocated in the LP-208

extension range (0xE0–0xE7 = LP-208/209/210/211 cluster):

(Schemas 0xE0–0xE1 are reserved for LP-208 DAG header/parent-list wire

formats per LP-208's schema allocation.)

Latency

LAN, PQ-strict mode at every layer, 40-validator parent L1 with 4-shard

fan-out:

End-to-end cross-shard finality at PQ-strict LAN: ~260 ms.

WAN, PQ-strict mode: ~600–800 ms (RTT-dominated; LP-209 latency triples

under WAN).

PQ-heavy mode: add ~150 ms to each cert step (LP-217 PQ-heavy floor

latency); total ~400 ms LAN, ~1000 ms WAN.

The dominant cost is the two sequential LP-209 wave commits —

per-shard prepare wave plus parent-L1 commit wave. Optimisations:

• Speculative commit at PQ-fast. If the shard cert is PQ-fast and

the parent-L1 cert is also PQ-fast, both certs land within 5 ms LAN;

total cross-shard latency drops to ~150 ms.

• Pipelined cross-shard groups. Multiple in-flight cross-shard

groups overlap their wave commits via LP-205 pipelining; aggregate

cross-shard throughput remains at the parent-L1 wave rate

(~10 waves/sec × ~100 cross-shard txs/wave = 1000 cross-shard

txs/sec floor).

Atomicity proof sketch

The atomicity claim is: for any cross-shard tx group T, after the

parent-L1 cert decisively covers either CrossShardCommit(T.id) or

CrossShardAbort(T.id), every shard s_j ∈ T's shards has either

committed T_j or unwound T_j, and these outcomes match.

Argument:

1. Each shard's LP-210 Phase 4 staging is local — the staged overlay

exists only in the shard's runtime, content-addressed by the

per-shard wave cert.

2. The shard's wave cert (Step 2 ack) commits the shard to executing

T_j at the shard's per-wave finality. If the shard later refuses

to apply the staged overlay on Step 4 commit-notify, the shard is

byzantine and slashable on the parent L1 (Step 4 commit-notify is

the cryptographic instruction; refusal contradicts the shard's own

wave cert).

3. The parent-L1 cert is either commit or abort, never both — wave

ordering at the parent L1 is total (LP-209), so the

CrossShardCommit(T.id) or CrossShardAbort(T.id) tx commits at

exactly one parent-L1 wave height with a single cert.

4. Therefore: the parent-L1 cert is the unique decision oracle. Every

shard's local outcome is a deterministic function of the parent-L1

cert (commit → apply staged overlay; abort → LP-202 unwind). A

shard that diverges is byzantine and slashable.

The atomicity is eventually-cryptographic: there is a transient

window between Step 2 prepare and Step 4 commit during which a shard's

staged overlay exists but is not yet committed. During that window, the

shard's external API MUST NOT expose the staged state — queries return

pre-T_j state. This is the standard 2PC invisibility property; LP-210's

Phase 4 staging guarantees it by construction.

Composition with LP-202 cert tier degradation

LP-202 §"Cert leg degradation tiers" allows a QuasarCert to be observable

at a lower mode than the chain's configured target, when slower legs

fail to aggregate within the timeout. The cert is monotone: once a leg

arrives, the cert is observable at the higher tier; legs never retract.

Cross-shard interaction: the parent-L1 cross-shard commit cert is

observable at progressively higher modes as its legs arrive. A relying

party (a shard executor watching for commit-notify) applies its own

cert-mode policy against the parent-L1 cert. The shard does not need to

wait for the parent L1 to reach the parent L1's configured target mode;

it only needs to wait for its own configured mode.

Worked example: parent L1 configured PQ-heavy, shards A and B

configured PQ-strict.

The shards commit at PQ-strict observability (their configured mode),

not at the parent L1's target PQ-heavy. The parent L1 still waits for

Magnetar before finalising at its target — but the shards do not.

Monotonic upgrade across shards. Different shards may be configured

at different modes. The parent-L1 cert observability is monotonic per

LP-202; therefore the order of cross-shard commit observations across

shards is a function only of each shard's individual mode threshold —

not of any cross-shard coordination. A shard at PQ-fast acts at ~105

ms; a shard at PQ-strict acts at ~110 ms; a shard at PQ-heavy acts at

~155 ms. All three are committing the same cross-shard tx group; they

just realise it at the time their own mode is satisfied.

**Architectural decision: shards may commit early at their individual

mode without waiting for the parent L1's target mode.** This follows

from LP-202's monotonic-upgrade invariant — the parent-L1 cert is the

same struct at every observation point; only the leg-set membership

grows. A shard acting on an early observation cannot be wrong, because

the cert at the lower mode is a strict subset of the cert at the higher

mode. If shard A acts at PQ-strict observability and the parent L1

ultimately fails to reach its target PQ-heavy (some leg fails to

aggregate within its timeout), the shard's commit is still valid — the

cert at PQ-strict is a valid cert at PQ-strict. The parent L1 has not

retracted anything.

This means: **the cross-shard 2PC commit point is the

minimum-mode-observability of the parent-L1 cert across all

participating shards**, not the parent L1's configured target. Latency

is bounded by the slowest-configured shard, not by the parent L1's

configured target.

Composition with LP-210

LP-210 Phase 4 has two modes (local-commit / staged-prepare). LP-211

formalises the staged-prepare mode:

The same wave can contain a mix of intra-shard and cross-shard txs. The

intra-shard txs commit immediately under local-commit; the cross-shard

portions stage and wait. This is the canonical Block-STM × 2PC

composition — no special tx-type at the LP-210 layer beyond the

cross_shard envelope kind.

Composition with LP-205 pipelining

LP-205 pipelines block production (wave production) across rounds.

LP-211 cross-shard cert pipelining is the same pattern at the parent-L1

wave layer:

Three cross-shard tx groups, three overlapping parent-L1 wave commits.

Aggregate cross-shard throughput at LAN scale ≈ parent-L1 wave rate ×

(parent-L1 wave capacity / CrossShardCommit tx size) — ~1000 cross

-shard groups/sec at PQ-strict, ~500 at PQ-heavy.

Failure modes

Activation marker

activates: 2025-12-25T16:20:00-08:00
activates-unix: 1766708400

Applies to cross-shard tx group atomicity from the genesis block of the

new final Lux network onward. The pre-Quasar Edition Lux network has no

cross-shard primitive and is out of scope.

Cross-references

• LP-079 — Q-Chain finality blocks (where cross-shard commits

ultimately land)

• LP-182 — Consensus wire / QuasarCert (the cert that anchors the

cross-shard commit)

• LP-201 — ZAP P2P (DHT layer that dispatches large tx groups)
• LP-202 — ZAP Pipelining and Atomic Unwind (the atomic-commit and

monotonic cert-tier-upgrade contracts cross-shard 2PC depends on)

• LP-204 — Network of blockchains (Tier-2 chain-VMs are the shards)
• LP-205 — Pipelined block production (parent-L1 wave pipelining

for concurrent cross-shard groups)

• LP-208 — DAG mempool / header DAG (per-shard mempool that receives

the cross-shard parts; equivocation gate)

• LP-209 — Mysticeti-style total-order on DAG (per-shard and

parent-L1 wave commits)

• LP-210 — Block-STM optimistic parallel execution (per-shard

staged-prepare in Phase 4)

• LP-217 — Cert Profile Modes (per-shard and parent-L1 cert modes)