Reserved conflict capacity v1

Experimental opt-in implementation · 5 September 2026

Result and boundary

The candidate preserves unrelated existing sponsored receipts when foreign conflict evidence fills its registry. It can still quarantine locally accepted slots using reserved state. The default control retains blanket sponsorship suspension. Neither policy guarantees newcomer admission or semantic retention.

Twenty-four deterministic matched cases cover capacities 1, 2, 4, and 8 with F=N, honest-first, attack-first, and alternating arrivals, clean reopen, exact replay, reversed/duplicate evidence, invalid same-claim accusations, and local conflicts after foreign saturation. All pass the independently specified expected outputs. Attack-first schedules still reject new sponsored arrivals in both policies.

A separate native accounting microbenchmark used one correlated issuer and beneficiary, N=1,024, 512 locally accepted allocations, and 1,024 foreign proofs:

• Control: zero unrelated receipts usable after the flood; no further local conflict records accepted once the registry filled.
• Reserved: all 512 unrelated receipts usable, then all 512 correctly quarantined when valid local conflict evidence arrived. None remained usable after reopen.
• Requested live heap was approximately 327,462 bytes for each policy. This excludes prepared inputs and caller receipts, allocator metadata, and process RSS.
• Final journals were 339,980 bytes (control) and 453,156 bytes (reserved). The additional records preserve local quarantine that the saturated control refused.
• Single-run reopen measurements were about 1.1 ms and 4.0 ms respectively; these are local filesystem observations, not production latency guarantees.

Both modes share the current slot representation, including its quarantine flag; this is not a memory comparison against an older compiled binary. The benchmark reuses a descriptor across many allocations and establishes no discovery diversity.

API and persisted policy

Ledger::create and Ledger::open remain control-only. Explicitly select ConflictMode::Reserved { foreign_capacity: F } through create_with_mode and open_with_mode. Require 1 ≤ F ≤ N ≤ 100,000. The mode is immutable within a ledger; epoch advance keeps it and validates F against the next policy's capacity.

Control journals retain SkeinAdmissionJournal/v1 plus NUL and the original header bytes. Reserved journals use SkeinAdmissionJournal/v2 plus NUL. Their checksummed JSON header adds foreign_capacity; open requires an exact mode, capacity, and policy match. Control readers reject v2. There is no automatic migration or in-place downgrade: use a separately initialized candidate ledger for experiments.

Records remain 221 bytes, including the chained checksum. Tag 2 identifies a quarantine record. Replay infers local versus foreign from previously committed allocations; a local quarantine uses its slot's existing flag. Foreign tombstones cannot later become accepted allocations. Neither kind is evicted within an epoch. The candidate permits at most N receipt records, N local quarantines, and F foreign quarantines. Worst-case record storage is 221(2N+F) bytes, plus the bounded header; this is up to 50% more records than the control's 2N bound when F=N.

In-memory maps remain O(N+F); lookup and updates are O(log(N+F)). Local quarantine adds no persistent map allocation. Duplicate evidence adds no record. Cryptographic work is bounded per valid fixed-size proof but input queues and arrival rates are not yet bounded by a production ingress policy.

Durability evidence

Tests reject mode/capacity mismatches, preserve the foreign-full gate across restart, accept local quarantine after saturation, and retain mode through epoch rollover. Every incomplete length of a 221-byte final local-quarantine append is removed on reopen; a complete record survives. Real write failures poison the handle, return no permission, and leave no in-memory quarantine committed early. These tests do not emulate arbitrary hardware or inject every possible fsync error.

Reproduce and next gate

outputs/conformance-env/bin/python conformance/generate_capacity_vectors.py
cargo build --locked --offline --features peer-recovery --example core_conformance
python3 conformance/run.py --suite conformance/capacity-v1.json \
  --output docs/results/reserved-capacity-v1.json \
  target/debug/examples/core_conformance
cargo test --locked --offline --features peer-recovery --test admission_wire
cargo test --locked --offline --features peer-recovery --lib admission_wire::durable
cargo run --release --locked --offline --features peer-recovery,allocation-profile \
  --example reserved_capacity

Fixture generation uses Python 3.12, cryptography 46.0.3, and public test seeds. Results and source/environment hashes are retained under docs/results/. The candidate remains experimental. Next: independent transition review, larger heterogeneous-issuer schedules, verification queue bounds, and explicit fsync-error injection before network exposure. Retention and honest/newcomer recall require a separate integration experiment. No public admission, migration, or deployment is enabled.

Follow-up evidence

Multi-issuer and bounded-queue work is recorded in docs/ADMISSION_QUEUE_V1.md; fsync-error injection is recorded in docs/ADMISSION_FSYNC_V1.md. The next driver experiment is specified in spec/core/INGRESS_PIPELINE.md. These additions do not promote the candidate to the default or establish end-to-end availability.