← All proposals

Status

Final. This LP is normative. Any future schema ID, TypeKind byte,

ShapeKind byte, or precompile slot allocation MUST be added here first;

the consuming LP MUST reference (not duplicate) the assignment.

Activated at the genesis of the new final Lux network:

2025-12-25 16:20 Pacific (unix 1766708400). LP-300 itself is a

meta-registry — it ships no wire change, only authoritative

documentation. Final from genesis.

Abstract

The LP corpus allocates schema IDs, TypeKind bytes, ShapeKind bytes,

and EVM precompile slots in fragments. LP-186 claims 0xC0..0xCB for

the 12 chains-VMs. LP-201 claims 0xD0..0xDF for the 16 P2P stream

types. LP-208 originally claimed 0xF0..0xFF for DAG mempool, then

honestly reclaimed 0xE0..0xE1 after the LP-218 rollup range

appeared. LP-211 claims 0xE2..0xE7 for cross-shard 2PC. LP-218

shipped Draft claiming 0xE0..0xEF for rollup envelopes — which

overlaps LP-208 *and* LP-211. LP-214 light client claims 0xF0..0xF2.

LP-219 reuses LP-211's 0xE2..0xE7 at the rollup tier. LP-0120 owns

the PQ precompile range 0x012201..0x012208 and LP-218/LP-220 attach

P3Q wrappers at three of those slots. LP-078 owns the broad EVM

precompile suite (0x0100, 0x0200..xxx, 0x0300..xx, 0x0500..xx,

0x0700, 0x0800..xx, 0x0900..xx, 0x9010..0x9080 DEX, 0x9200..04

privacy, 0xB002 KZG). LP-0011 owns federation registry slots

0x011001 and 0x011002.

This LP collapses every allocation into one master table. The

allocation namespaces are orthogonal: a TypeKind byte does not collide

with a precompile slot because they live in different address spaces;

the master table is partitioned by namespace. Conflicts inside a

namespace are resolved here — LP-300 wins over any consuming LP that

disagrees. The single most consequential conflict (LP-208 vs LP-211

vs LP-218 all claiming bytes inside 0xE0..0xEF) is resolved per the

LP-214 canonical handoff: LP-208 takes 0xE0..0xE1, LP-211 takes

0xE2..0xE7, LP-218 takes 0xE8..0xEF (shifted), LP-214 takes

0xF0..0xF2.

Allocation namespaces

Four orthogonal allocation namespaces. Each row of the master table

lives in exactly one namespace; cross-namespace collisions are

impossible by construction.

LP-300 is normative for namespaces 1, 2, and 3. Namespace 4 is owned

by the genesis / numbering LPs and is referenced here only to disclaim

overlap.

The terms "schema ID" and "TypeKind byte" are used interchangeably

throughout the LP corpus; they name the same byte. "Kind" alone is

ambiguous and avoided in LP-300.

Master Table

One row per allocation. The "Status" column reflects the consuming

LP's status; LP-300 itself is Final and pins the assignment.

Namespace 1 — TypeKind byte (ZAP schema ID)

Namespace 2 — ShapeKind byte (TxKind, per TypeKind)

The ShapeKind byte is the discriminator at byte 1 of the envelope,

namespaced under each TypeKind. LP-300 records only the cross-LP

ShapeKinds that are visible at the consensus/wire boundary. Per-VM

TxKind tables (e.g., dexvm OrderTx / CancelTx / SwapTx) are

internal to the owning chains-VM and are documented in LP-186 plus

the per-VM wire files; they are NOT re-listed here.

ShapeKind values under TypeKinds 0xC0..0xCB (chains-VM) are

delegated to LP-186 and the owning chains-VM. ShapeKind values under

TypeKinds 0xD0..0xDF (P2P) are degenerate — each P2P TypeKind has

exactly one shape — so no separate ShapeKind table is needed there.

Namespace 3 — EVM Precompile slot

EVM precompiles live in three disjoint address bands:

• 0x000B..0x0FFF — Ethereum-compatible / Lux core (LP-078 owns this band)
• 0x011xxx — Federation / governance slots (LP-0011 owns this band)
• 0x012xxx — Post-quantum cryptography slots (LP-0120 owns this band)
• 0x02xxxxxx... — Lux EVM-style stateful precompile range (LP-3520 / LP-078)
• 0x6010..0x9FFF — Application-layer precompiles (DEX, AI, etc.)
• 0xB000..0xBFFF — Blob / KZG precompiles
• 0x020000+ — Reserved for future precompile blocks

LP-300 catalogs every currently-allocated slot below.

Classical EVM core + Ethereum-compat (LP-078 band)

Federation registry (LP-0011 band)

Post-quantum precompile registry (LP-0120 band)

This is the canonical PQ precompile registry. LP-218 / LP-220 attach

the unified P3Q verifier family at the single slot 0x012205

(kind-byte dispatch: 0x01 Pulsar, 0x02 Corona, 0x03 Magnetar).

The raw primitive slots 0x012204, 0x012206, 0x012207 remain LP-0120

property for non-rollup-batch use. LP-221 owns the STARK-FRI verifier

at 0x012220.

Lux EVM-style stateful precompile range (LP-078 / LP-3520 band)

Reserved future precompile blocks

Conflict resolution policy

LP-300 is the single source of truth. The following policy governs all

future allocations and resolves all existing conflicts.

Adding a new allocation

1. The proposer opens a PR against LP-300 listing the requested

slot(s), the consuming LP number, and a one-line purpose.

2. The PR is merged BEFORE the consuming LP can be promoted past

"Draft" status. A consuming LP at "Final" without a matching

LP-300 row is itself in violation.

3. The consuming LP's "Wire schemas" or "Precompile slot" section

references LP-300 by row; it does not re-state the allocation.

Resolving overlap

If two LPs claim overlapping ranges:

1. The LP-300 maintainer arbitrates. The default rule: the

chronologically earlier "Final" claim wins; the later claim

relocates to the next free range.

2. The losing LP is amended to point at its new range, and an

"Activation marker" note is added to LP-300 stating "Was

<old range>; moved to <new range> per LP-300 §<section>".

3. Pre-activation (before unix 1766708400), reshuffles are free

because no production wire bytes have shipped. Post-activation,

reshuffles require a network upgrade.

Existing conflicts resolved by LP-300

LP-300 resolves three pre-existing conflicts in the 0xE0..0xFF

band. All three resolutions land via the canonical handoff

recorded in LP-214 §"Wire schemas".

Cooldown for deprecation

When an allocation is marked Deprecated, the slot is NOT immediately

reusable. A one-year cooldown applies before re-allocation, to give

node operators and indexers time to drop the old code paths.

The currently-deprecated rows (LP-078 ECIES 0x9201, AES 0x9210,

ChaCha20-Poly1305 0x9211; LP-3520 stateful ML-DSA 0x0200..0006

and SLH-DSA 0x0200..0007 and Corona 0x0200..000B) entered

deprecation on 2026-05-18 per AUDIT-2026-05-18.md and become

re-allocatable on 2027-05-18.

Cross-referencing pattern

Every consuming LP's "Wire schemas" / "Schema IDs" / "Precompile

slot" section is now informative-only. The canonical form is:

This LP allocates the following schema IDs (registered in LP-300):
- 0xD0 ConsensusVote
- 0xD1 ConsensusProposal
- ...
For the master allocation map see LP-300 §Master Table.

LPs MUST NOT duplicate the master table; they reference it. A

consuming LP that adds a new ID MUST amend LP-300 in the same PR.

Reserved / future ranges

These ranges are deliberately held aside. Allocate only via an

LP-300 amendment.

TypeKind reservations

• 0x00 — null/illegal envelope; never allocate
• 0x0E..0x0F — consensus-wire extensions (LP-182's reserve)
• 0x10..0xBF — broad protocol-level future use; the largest open

block in the TypeKind space. Likely landing zones: future

chain-internal schemas analogous to LP-182, future P2P transport

primitives analogous to LP-201, future signed-tx envelope

variants.

• 0xCC..0xCF — chains-VM growth (LP-186's reserve)
• 0xED..0xEF — rollup-VM growth (LP-218's reserve)
• 0xF3..0xFF — framing future

Precompile reservations

• 0x0010..0x00FF — Ethereum precompile expansion (held by Ethereum, do not allocate)
• 0x012209..0x0122FF — PQ growth
• 0x013000..0x01FFFF — future PQ extensions
• 0x020000..0x02FFFF — future stateful precompile blocks (per-VM clusters)

Cross-references — LPs that allocate in this registry

Each consuming LP gets a one-line summary. The full allocation lives

in §Master Table.

Out of scope (Namespace 4 — genesis assetID / chainID)

LP-300 does NOT normalize:

• Primary network IDs (1 mainnet, 2 testnet, 3 local, 1337 dev) — owned by LP-019 / LP-099
• EVM chain IDs (Lux mainnet C-Chain 96369, Hanzo EVM 36963, Zoo EVM 200200, Pars EVM 494949, SPC EVM 36911, etc.) — owned by LP-134 plus per-brand chain.yaml
• AssetID hashes (Lux X-chain UTXO asset, per-L1 sovereign asset IDs) — derived from genesis; owned by LP-019

These live in their own LPs because they are content-addressed

(derived from genesis blobs), not statically allocated. A future

LP-301 could collapse them into a sibling registry if a single

source of truth becomes useful; today the per-LP ownership is

correct.

Activation marker

LP-300 itself is Final from genesis (unix 1766708400,

2025-12-25T16:20:00-08:00) because it is a meta-registry, not a wire

change. The first time the consuming LPs (LP-208, LP-211, LP-214,

LP-218, LP-219, LP-220) cross activation in production, LP-300 is

the binding map. Any disagreement between this LP and a consuming LP

is resolved in favour of LP-300; the consuming LP must be amended in

a follow-up PR.

Reference Implementation

• ~/work/lux/standard/schemaregistry/ — Go package; registry.Validate() is the runtime conflict check.

References

• LP-022 — ZAP wire protocol (the underlying framing)
• LP-200 — ZAP Stack 10-layer model (where the TypeKind/ShapeKind

bytes live in the layering)

• LP-078 — Broad EVM precompile suite
• LP-0011 — Onchain federation registry
• LP-0120 — Quasar mainnet defaults (PQ precompile registry)
• LP-182, LP-184, LP-185, LP-186 — Wire schemas (consensus, X-chain,

EVM-internal, chains-VM)

• LP-201, LP-208, LP-209, LP-210, LP-211, LP-214, LP-218, LP-219 —

Cross-LP TypeKind allocations

• LP-073, LP-181, LP-220 — PQ precompile wrappers
• LP-217 — Cert profile modes (consumer of the precompile registry)
• AUDIT-2026-05-18.md — Deprecation ledger for the 2026-05-18

precompile sweep