Polymodum v1.0 Implementation Status§
Point-in-time evidence companion — 15 August 2026
This document reports the highest claim supported by the current source, local qualification evidence, and read-only observation of the Raspberry Pi deployment. It is not a protocol specification, release approval, operator-independence attestation, channel authorization, or payment authorization.
1. Relationship to the frozen protocol paper§
The frozen Polymodum v0.9 working paper remains the byte-stable description of the
polymodum/0.9 wire profile preserved by software version 1.0.0. Its protocol
invariants still apply: authorization precedes a protected effect, capabilities are
bounded and single-use, results are signed, and verification never proves more than
the disclosed evidence and trust assumptions.
This companion records implementation progress that occurred after that frozen paper. It does not alter or silently relabel the v0.9 source. The separately reviewed v1.0 RC2 paper remains a release-candidate input until its exact bytes and the v0.9/v1.0 compatibility statement are included in a signed release closure.
2. Status vocabulary§
- Defined — a canonical contract or schema exists.
- Implemented — source code exists and passes focused static checks.
- Tested locally — project-authored tests or a controlled qualification passed.
- Staged — locked artifacts are present on a target host but are not executing.
- Live observed — a read-only observation saw a running service at one point in time.
- Independently qualified — a separately controlled operator reproduced the required flow and retained verifiable evidence.
Passing one level never implies a higher level. In particular, distinct processes, containers, hosts, keys, or node IDs under one controller do not establish independent operators.
3. Evidence matrix§
| Area | Highest defensible status | Current boundary |
|---|---|---|
| Frozen Core | Implemented and tested locally | Canonical policy, pre-effect decision, one-use capability, controlled adapter, signed receipt, and offline verification are locally reproducible. External reproduction remains separate. |
| Bitcoin and Lightning regtest | Locally qualified; test-only | A two-node Core Lightning regtest payment and Bitcoin Core regtest confirmation were verified. Regtest sats have no monetary value and prove no mainnet readiness. |
| Raspberry Pi services | Live observed; single-controller | The API, Explorer, PostgreSQL, Kubo, Bitcoin regtest, mainnet wallet node, Bob pilot, and mobile witness services were observed healthy in Docker. This does not prove independent operation. |
| Incus channel boundary | Implemented, staged, and unarmed | Incus 6.0.4, a restricted project/profile, local storage, pinned ARM64 images, and five immutable phase bundles exist on the Pi. There are zero active phase instances. Revised sealed-input bundles have not executed a live channel phase. |
| Incus host hardening | Partially available | Workers are designed as unprivileged, idmap-isolated, sequential, no-NIC containers with phase-specific mounts and RPC gates. AppArmor is unavailable on the current Pi kernel, so no claim depends on AppArmor confinement. |
| Mainnet deposit | Read-only observed | One confirmed, unreserved 49,600-sat output is documented. Observation grants no channel, fee, withdrawal, broadcast, invoice, or payment authority. |
| Mainnet channel and payment safeguards | Implemented and tested locally; not live | Exact 20,000-sat private-channel contracts, fee/reserve gates, durable no-retry journals, phase-specific Rune evidence, one-shot payment permits, reconciliation, and server-side Rune revocation exist. No mainnet channel or real Lightning payment has occurred. |
| External operator | Bootstrap published; runtime not qualified | The public v0.3 kit creates a fresh Bitcoin-backed Core Lightning identity and encrypted operator keys. It deliberately creates no peer connection, channel, Rune, invoice, or payment. |
| Independent operator | Not qualified | The independently verified operator count is 0. A separate caller-host admission test does not establish different organizational control, custody, or infrastructure. |
| Public operator runtime | Implemented in parts; not production-qualified | The public contract and client are locally tested, but the combined production coordinator, ingress, private lanes, and end-to-end mainnet flow have not passed one target-host qualification. |
| Release and document closure | Required | Software identifies as the v1.0 Genesis Release Candidate while preserving the frozen v0.9 wire profile. Maintained publisher, rollback, supply-chain, and exact document-closure evidence remain incomplete. |
4. Incus claim boundary§
Incus is not a replacement for protocol authorization, exact Rune restrictions, durable
replay fences, Bitcoin transaction validation, or independent operator consent. It is a
defence-in-depth boundary for five sequential channel phases: stage, prepare,
dispatch, observe, and recovery.
The Pi currently contains the locked project resources and immutable runtime bundles, but no phase worker is active. The ordinary Polymodum and Lightning services continue to run in Docker. A future live phase must use newly sealed inputs, exact phase credentials, the reviewed launcher, and post-run revocation evidence; an earlier unarmed smoke does not authorize reuse.
5. Mainnet settlement gate§
The intended economic qualification remains one private 20,000-sat channel and one payment of exactly 1,000 msat. It may proceed only after all of the following verify:
- a genuinely external operator controls the accepted agent and Core Lightning keys;
- the exact peer, funding input, reserve, maximum opening fee, and recovery package are signed before the offer becomes active;
- the channel transaction is finalized and accepted by the bounded Bitcoin preflight before its single broadcast;
- the active channel and receiving capacity are freshly observed;
- the private invoice is for exactly 1,000 msat and is bound to the accepted peer and workflow;
- each least-authority Rune is created just in time, used at most once, and proven blacklisted before terminal evidence is published; and
- ambiguous outcomes reconcile from durable wallet evidence without another payment attempt.
At this snapshot, those live gates are not all satisfied. No channel broadcast or payment is inferred from source code, tests, staged Incus bundles, a confirmed deposit, or prior user intent.
6. Current public label§
The defensible label is Polymodum 1.0 Genesis Release Candidate: a locally tested Core with regtest evidence, a live single-controller Pi read model, staged Incus and mainnet safeguards, and a published non-spending operator bootstrap.
It is not yet a completed Genesis Release, production-funds system, independently operated network, or decentralized Genesis Network.
7. Evidence sources and update rule§
The authoritative repository evidence for this snapshot is recorded in
CURRENT_STATE.md, docs/v1-completion-audit.md, docs/v1-launch-authority.md, and
infra/incus/channel-v02/README.md. Live observations are point-in-time operator
evidence and must not be treated as continuing availability.
This document must be replaced by a new immutable build when a claim changes. Previous bytes remain historical evidence; they are never rewritten to make an earlier status appear stronger.