Layer 1 gap analysis: Arrekta core vs. the major chains

2026-10-18. The question: is the current core everything the base layer needs, so later layers can be built on it without reworking layer 1?

Short answer: the core covers what an asset-settlement chain needs today. Three things the big chains rely on are missing, and all three are much harder to add after mainnet:

1. a soft-fork upgrade path;
2. timelocks and hashlocks in spending conditions;
3. light-client support (filter commitments).

Fix 1 and 2 before mainnet. Item 3 can follow, but its commitment format should be reserved now.

Status (2026-10-18): all three are implemented in the Python reference and the Rust node. Each has spec text (PROTOCOL.md v1.1, §4.2–4.3, §5–6, §9.1, §9.4–9.5, §12.5, §15), shared vectors (core/vectors/base_layer.json, plus filter commitments in the chain and reorg vectors) and tests. Light-client filters shipped in full, not only as a reserved commitment. The ✗ marks below are kept as the original baseline. See §4 for what was built.

1. What the core has, compared with the major chains

2. Gaps, ordered by how hard they are to add later

P0. Soft-fork upgrade path (missing; cheap now, a hard fork after mainnet)

The bug in our reasoning. PROTOCOL.md §4 says new lock kinds are added "by soft fork (unknown kinds are invalid today, so adding one can only tighten rules)". That is backwards. Turning something invalid into something valid loosens the rules, which is a hard fork: every old node rejects the first block that uses the new kind.

How Bitcoin does it. Undefined witness versions (1–16) are anyone-can-spend, so a later soft fork can add rules to them; Taproot shipped this way as witness version 1. Activation is signalled with header version bits (BIP 9, and BIP 8 with height-based windows).

Today in Arrekta:

• transaction version MUST be 1;
• block version MUST be 1;
• unknown lock kinds fail to decode;
• there is no activation signalling.

So relative timelocks, a new lock kind, confidential outputs or a new transaction field would each require every node to upgrade at once.

Recommendation (consensus change, free before mainnet):

• Upgradeable lock-kind range. Kinds 0–2 stay as they are, and a reserved range (say 16–127) is valid to create. Spending such an output requires only a non-empty witness, until a soft fork defines rules for that kind. Mempool policy keeps it non-standard, so nobody uses it by accident (Bitcoin's model).
• Versions. Accept any transaction version ≥ 1, treated with v1 semantics. Block headers carry version bits: top bits fixed, the low bits used for signalling.
• Activation. Height-based BIP 8-style deployments (start and timeout heights, lock-in threshold, optional lock-in-on-timeout), recorded per network like the scheme schedules. The same mechanism can also sunset weakened signature schemes.

P0. Timelocks and hashlocks in spending conditions (missing)

Lightning-style channels need multisig, absolute timelocks, relative timelocks, hashlocks and a malleability fix. We have the first and the last.

Beyond L2, these are what issuers and wallets need for:

• on-chain vesting (holder cannot spend before a height);
• escrow with a refund path;
• cross-chain atomic swaps (HTLC);
• Liana-style inheritance and recovery (a backup key after N blocks of inactivity);
• offers that expire.

Recommendation: rather than one ad-hoc lock kind per feature, add one policy lock kind that commits to a small, audited spending policy. It follows the Miniscript idea, with no script VM:

policy := key(pk) | multi(m, pk…) | after(height) | older(blocks) | sha3(hash)
        | and(p, q) | or(p, q) | thresh(k, p…)
lock    = kind POLICY ‖ scheme_mask ‖ TH("policy", canonical_policy)
witness = [policy, satisfaction…]      (keys, signatures and preimages in a fixed order)

• older(n) uses the input's sequence field, which already exists and is unused; this is relative-timelock semantics as in BIP 68/112.
• after(h) checks against the spending height.
• Spending is non-interactive and deterministic, so wallets, the PST format and hardware signers can show exactly what a policy allows.
• One kind covers vesting, escrow, HTLC swaps, recovery paths and channel constructions.

Transaction expiry: add an optional valid_until height. Stellar, Algorand and Cardano all have validity intervals. It stops stale PSTs, swap offers and issuer distributions from landing much later than intended. It's cheapest to add with the transaction-version change above (version 2 adds the field).

P1. Light-client support (can follow mainnet if the commitment is reserved now)

What Bitcoin does. BIP 157/158: nodes build a compact filter per block (all output and spent scripts), and clients download filters and fetch only matching blocks. It's private (the server doesn't learn which addresses the client watches), unlike BIP 37 bloom filters, which leaked addresses.

For Arrekta: mobile and browser wallets, issuers' holders and IoT devices shouldn't have to run a full node.

Recommendation:

• Now: reserve a header or coinbase commitment slot for a filter-header chain, so filters can later be checked against proof of work rather than trusting the serving peer. Bitcoin never committed its filters, a known weakness.
• Later: filters cover locks and asset ids (so "watch asset X" works), served over P2P and the gateway.

UTXO-set commitment (for fast bootstrapping in the style of assumeutxo): optional, P2, and also something to reserve a commitment slot for now.

P1. Throughput under post-quantum signatures (watch item)

The problem. Research and industry reports agree that signature size, not consensus, is the PQ bottleneck:

• BNB Chain measured ML-DSA-44 transactions at about 2.5 KB and 40–50% lower throughput;
• Falcon-512 cuts throughput by roughly 77% against ECDSA;
• Ethereum researchers call aggregation the real blocker.

A Arrekta payment with ML-DSA-65 is about 5.4 KB per input.

What we already have: crypto-agility lets us add a smaller scheme (FN-DSA / Falcon) or a hash-based backup (SLH-DSA) by schedule, without a redesign.

Recommendation:

• Keep ML-DSA-65 as the default, and treat FN-DSA as the first candidate second scheme once FIPS 206 is final.
• Note that policy locks and multisig keep their witness cost proportional to the signatures actually used.
• Revisit STARK-based aggregation as a later soft-fork lock kind, which the upgradeable range makes possible.

P2. Policy-level features (no consensus change, add any time)

• Fee bumping:
  • replace-by-fee with full-RBF rules;
  • child-pays-for-parent with package relay.
• A dust threshold per asset output, like Cardano's minimum-UTXO rule. It's policy-only here, because outputs must already carry value.
• Address-reuse and asset-trust warnings in wallets.

Deliberately not in layer 1

• General smart contracts / VM. The positioning is settlement for issued assets. Issuer controls are consensus rules, and policy locks cover the common conditional-spend needs. A VM would bring back the contract-bug class that ERC-1400/3643 audits worry about. If ever needed, it can arrive as a soft-fork lock kind or a separate execution layer.
• Native order-book DEX (Stellar/XRPL style). Atomic swaps through PST already give trust-minimised exchange. An order book is an application, not a base-layer rule.
• Confidential amounts (Liquid CT). Useful, but it conflicts with the issuer-transparency positioning. Possible later as an upgradeable lock kind.

3. Recommended order

1. Upgrade path: upgradeable lock-kind range, version bits, height-based activation, and transaction version ≥ 1. Spec, both implementations and vectors.
2. Policy locks: key / multi / after / older / sha3 / and / or / thresh, plus valid_until. Spec, both implementations, vectors, PST and wallet support, issuer vesting on chain.
3. Reserved commitments for filter headers and the UTXO set (empty for now).
4. Then the deferred 7-day soak, and after it light-client filters and policy-level fee bumping.

Steps 1–3 are done (see §4). Policy-level fee bumping and a UTXO-set commitment remain open.

Steps 1–3 are consensus changes. They are free before mainnet: devnets and testnet restart from a new genesis. After mainnet each would be a coordinated hard fork.

4. What was built (2026-10-18)

Sources

• BIP 141 witness versions (Lightspark) · witness program extension (bitcoin-dev) · SegWit (Spark)
• BIP 9 · BIP 8
• Layer 2 is not a magic incantation (Bitcoin Magazine) · CSV (Lightspark) · Bitcoin timelocks (Spark)
• Compact block filters (Spark) · BIP 158 · BIP 37
• How Liquid works · Liquid (River)
• XRP Ledger overview (Dune) · Stellar overview (Dune) · How the XRP Ledger works
• Cardano native assets · Cardano multi-asset scenarios
• PQ attackers SoK (arXiv 2512.13333) · BNB Chain PQC migration report · PQ Ethereum aggregation (Ethereum Magicians) · Emerging PQ schemes (Project Eleven) · Falcon proposal (bitcoindev)