This repository is research proof-of-concept code. It is not production-ready and does not provide an official Zenon or x402 security guarantee.

The command-line tools ship one exact, internally pinned historical testnet profile. It is disabled unless the operator selects its full immutable name and supplies both the existing testnet-only acknowledgement and a separate acknowledgement that the anchor does not authenticate the connected node. No profile JSON, chain identifier, genesis value, trust-artifact URL, default, or floating alias is accepted from the environment. The separately configured RPC URL remains part of the operator trust boundary.

The profile is an unsigned historical observation from a pinned zenon-network/znn-wiki source revision. The owned SDK session requires the node's height-2 version, height, chain identifier, Momentum hash, and predecessor to match that observation exactly, and requires the height query's reported total not to be below the previously observed frontier height. This detects honest mismatches or resets that alter the pinned height-2 identity tuple. Forks after that tuple and disconnected or malicious RPC views are not detected. A match remains a node self-report; it does not authenticate the endpoint, establish canonical remote-chain identity, or verify linkage to the observed frontier. The distinct operatorTrustedChainPolicy path returns explicit non-authenticating evidence and cannot populate the authenticated-profile result.

Do not use mainnet, real funds, or a valuable wallet. Use only a disposable, minimally funded testnet wallet for any separately approved operational run. The acknowledgements, historical comparison, and SDK network-ID check are defense-in-depth guards, not proof of connected-chain identity.

The optional local four-node devnet profile remains separate from the public-testnet policy and Gate-B runner defaults. Ordinary buyer and server CLIs can select the local family only through the closed, default-off selector with the exact local lane, a genuine canonical artifact, the exact local acknowledgement, and a canonical loopback WebSocket RPC input; aliases, partial selector families, and fallback are rejected. Valid local selection permits ordinary runtime construction, requirement construction, server setup, and direct readiness wiring, but the owned live SDK session rejects the local policy before SDK effects. The local lane therefore cannot complete payment or evidence execution or close Issue #45. The artifact is limited to 16 KiB and rejects duplicate keys, unknown or missing fields, noncanonical encoding, an unexpected chain identifier, and mutable or absent runtime provenance. Provenance requires the exact external-generator repository and immutable revision, an independently named node-source revision, and a sha256 image digest; a floating image tag is not representable.

Artifact parsing validates syntax, shape, relationships, and immutable-identifier encoding only. The dedicated observation check compares the declared chain identifier, genesis predecessor, exact height-two Momentum, reported count, and frontier height, but all values remain operator supplied. It does not authenticate the generator, node source, image contents, RPC view, chain identity, or frontier lineage. Its fixed nonclaims deny public-testnet evidence, authenticated identity or provenance, byte-for-byte private-network reproduction, Issue #45 completion, production readiness, release, and activation.

"Four-node" names the intended external operator workflow only; the artifact does not verify node count, roles, topology, or a topology digest. fourNodeTopologyVerified is therefore required and false; no topology inference may be made from the lane name.

Only a genuinely parsed artifact can create the branded local-devnet policy. A closed dispatcher pairs every genuine public or local policy with evidence from the same family; it exports no generic evidence predicate or mutable registry. The exported direct local observer and dispatcher consume the local family, while direct assertZenonNodeReady is the only payment-readiness integration that accepts it. Direct readiness also requires the exact current observer result after an injected read before accessing evidence fields. Its SDK adapter rejects proxies, accessors, ambiguous shapes, conversion hooks, unsafe counts, malformed fixed-length hash bytes, cross-family substitution, and frontier mutation across the single height-two query. Policies and evidence, together with their copied profile, provenance, height-two, and nonclaim fields, are detached and deeply frozen; observation validation uses detached normalized copied snapshots. The SDK frontier object is returned unchanged by readiness and is not claimed to be detached or frozen. Adapter-controlled Promise handling uses captured intrinsics, but it cannot undo thenable assimilation or other behavior already performed inside an injected SDK method before that method returns a genuine native Promise. All evidence remains non-authenticating and never contains authenticatedProfile.

The artifact allowlist has no wallet, credential, node-key, endpoint, filesystem-location, transaction, or signature field. Private material generated by an external operator tool must never enter the repository or evidence artifact. This repository neither copies nor vendors code from 0x3639/testnet; using it remains a separate operator action. Only reproducible equivalent behavior may be claimed because network timestamps and private random material differ between generations. No local-devnet result can close Issue #45 or replace the later public-testnet gate.

This bridge remains offline-tested, runtime-unregistered readiness plumbing for owned live SDK sessions. Import and policy construction are side-effect-free and offline; direct policy observation and direct readiness invocation perform only the explicitly injected node reads. The ordinary CLI selector can construct the local policy, and the client and facilitator constructors accept only its exact pairing with the validated loopback RPC input. The owned live-session path, role probe, and Gate-B runner remain public-testnet-only, so local selection does not provide successful payment or evidence execution. There is no local-specific package script or default activation; the generic buyer and server scripts expose the ordinary explicit selector, and the default payment mode remains mock. Ordinary valid public-testnet selection and payment semantics remain unchanged, and SDK network-ID handling is unchanged. The bridge retains the non-enumerable readiness-result assimilation shield and earlier hostile-input rejection. Any future local payment/evidence runner must separately establish the descriptive network label, SDK network-ID binding, local acknowledgement, loopback transport, the external tool's seed-plus-four-pillar/five-service workflow description, immutable image provenance, protected operator material, isolated journal/evidence state, and evidence classification. It must retain fourNodeTopologyVerified: false unless topology is independently authenticated. Wallets, credentials, node keys, transactions, signatures, Docker outputs, and generated packages remain out of scope.

The separate local-devnet readiness runner and CLI are explicit opt-in, offline-tested, runtime-unregistered tools. They remain separate from the closed ordinary CLI policy selector and are not added to any public runner, environment alias, package script, or default. Import and parent preflight perform no network I/O. Run mode accepts only the genuine local artifact and acknowledgement, one restrictive current-directory artifact file, and exactly ws://127.0.0.1:<non-default-port>/ or ws://[::1]:<non-default-port>/. The canonical decimal port must be explicit and cannot be 80, and the trailing slash is mandatory. Hostnames and DNS, wss, credentials, implicit or default ports, alternate encodings, extra paths, queries, fragments, percent encoding, whitespace, and other noncanonical variants fail before Worker creation. A run creates a single-use Worker with empty arguments and environment, captures and discards bounded standard output and error, instantiates a fresh SDK client without singleton or SDK NetworkID/ChainID mutation, disables reconnects and redirects, makes one connection and exactly four ordered readiness reads, and closes once. Success is a primitive result exposed only after Worker exit and both output-pipe close barriers are proven; ambiguous teardown fails closed and poisons later parent use if destruction cannot be proven.

The Worker protocol and operator output are fixed, primitive, bounded, and cause-free. The tool does not contain wallet, funding, signing, block-construction, publication, facilitator, buyer/server HTTP, protected-resource delivery, journal, live-evidence capture or bundle, proof, or payment surfaces. The local artifact, provenance, observed chain view, and intended four-node label remain operator-trusted and non-authenticating, and topology remains unverified. Adapter-side captured intrinsics cannot undo thenable assimilation or other behavior already performed inside the pinned SDK producer before a genuine native Promise is returned. This readiness result is not authenticated chain identity or topology, public Gate-B evidence, release, activation, or production readiness, and it cannot close Issue #45.

Ordinary live CLI output does not print the requirement, settlement object, payer, transaction identifier, listening URL, or protected response body. Any future public evidence bundle requires a separate allowlisted capture and review path.

Never commit .env, a mnemonic, keyfile, private key, token, or RPC credential. The facilitator must never receive buyer key material. Credential-bearing RPC URLs are rejected because the SDK may log the complete URL.

The selected requirement commits an exact versioned chain profile:

{
  "version": 1,
  "chainIdentifier": "<canonical-nonzero-decimal-string>",
  "genesisMomentumHash": "<64-lowercase-hex>"
}

The experimental zenon:testnet label is descriptive only. It neither identifies nor authenticates a chain. A future authenticated policy must establish the exact chain identifier and genesis identity and verify their linkage to the observed frontier during the exclusively owned SDK session.

Both live entry points use one strict offline preflight before any RPC. It binds the signed UserSend block to the exact x402 version, resource, requirement, chain profile, recipient, concrete ZTS and canonical positive amount. The facilitator reconstructs the hash, verifies Ed25519 with strict ZIP-215 behavior disabled, and binds the public key to the payer address.

The maximum payment amount is 2^255 - 1 atomic units, matching canonical go-zenon account-block validation. Zero and non-canonical decimal forms are rejected by this exact-payment scheme.

The TypeScript SDK uses mutable process-global connection and chain configuration. One FIFO owner serializes the complete live SDK lifecycle across every buyer and facilitator instance:

acquire global owner
configure and connect
perform live RPC / prepare / confirmation work
clear the connection
release global owner

Settlement acquires the canonical per-payer queue before the global SDK owner. No path acquires those locks in reverse order.

SDK RPC calls cannot be reliably cancelled. If a bounded read or publication wait expires, the code marks the process-local live runtime poisoned before cleanup or ownership release. The underlying request is not claimed to be cancelled. All queued and later live operations fail with live_runtime_poisoned_restart_required; restart the Node.js process before attempting any further live use.

An unexpected SDK connection-cleanup failure is handled the same way for future-use purposes: the runtime is poisoned before ownership is released, so uncertain singleton state is not reused.

prepareBlock() is composite and may perform several RPC calls and PoW. It is intentionally not wrapped in Promise.race; ownership remains held until it settles.

Publication results are classified by evidence:

• VALIDATED — offline validation succeeded; after node-dependent checks, the exact signed block and authorization identity are journaled before any publication attempt;
• SUBMISSION_ACKNOWLEDGED — publication returned or the exact block was observed without Momentum inclusion details;
• SUBMISSION_OUTCOME_UNKNOWN — publication returned its asynchronous request promise, that promise rejected, and reconciliation did not observe the exact block; every such rejection remains uncertain, not only a timeout or transport failure;
• MOMENTUM_INCLUDED — the queried node returned the exact block with confirmationDetail;
• DELIVERY_PENDING — an exclusive delivery claim was durably recorded; protected-resource execution may have begun;
• DELIVERED — the response was durably cached.

The implementation does not use FINAL. MOMENTUM_INCLUDED does not prove irreversible finality, independent canonicality, or the recipient's receive block. Merchant receipt remains separate.

An uncertain publication produces a distinct HTTP 409 recovery result. Clients must reuse and reconcile the same signed payment and must not automatically create a replacement payment. The resource is not released while the payment outcome is uncertain.

Live requirement construction may set ZENON_MINIMUM_MOMENTUM_CONFIRMATIONS. Missing, empty, and canonical string 1 all preserve the default: the signed wire field is absent and the effective value is one. Only canonical strings 2 through 30 emit numeric extra.minimumMomentumConfirmations; every other environment representation fails before downstream effects. Mock construction neither reads the variable nor accepts the field. A received live wire field must be a numeric integer from 2 through 30; numeric 1 is invalid rather than an alternate encoding of absence.

This is an operator policy over one operator-trusted node's confirmationDetail.numConfirmations, not protocol finality, canonicality or reorganization safety, authenticated chain identity, independent attestation, recipient receive, or spendability. Delivery is eligible only when that observed count is at least the signed threshold. maxTimeoutSeconds still bounds only first inclusion. The first exact inclusion is persisted immediately. Below the threshold, delivery remains NONE and only an exactly authenticated result becomes the same-payment HTTP 409 payment_reconciliation_required / reuse_and_reconcile_same_payment lane with PAYMENT-RESPONSE and without PAYMENT-REQUIRED. Malformed or spoofed candidates remain private and cannot authorize delivery.

Each later identical request performs at most one fresh exact-hash lookup after readiness and never re-signs, replaces, or republishes the payment. Only a higher count for the identical inclusion hash, height, and timestamp tuple strengthens the durable record. Equal, lower, drifting, absent, or unavailable observations retain the strongest durable evidence and release nothing. SUBMISSION_ACKNOWLEDGED and SUBMISSION_OUTCOME_UNKNOWN never republish; only VALIDATED retains the existing exact-block idempotent publication path. Generic clients may not implement the PoC-specific 409, so a non-default threshold requires the matching PoC reconciliation client.

Under the journal writer lock, every delivery claim reauthenticates the complete accepted requirement against the persisted payment-intent preimage before any early return. The policy changes no journal schema, record, checksum, or tombstone shape; schema v2 and default-one compatibility remain unchanged. Configuration rotation is deliberately fail-closed: an unresolved payment created under another threshold is unavailable until its original configuration returns. Rollback to an older reader is unsupported while unresolved threshold-bearing records exist because that reader cannot enforce the signed policy.

Evidence version 1 remains default-one-only. Every evidence-v1 runner rejects an explicit minimumMomentumConfirmations before filesystem, runtime, SDK, RPC, wallet, signing, payment, or publication effects. Supporting non-default-threshold capture requires a separate evidence design and version. This locally tested tranche executed no new live payment and establishes no new evidence, release, activation, finality, or production readiness. Issue #81's different-operator verification remains separate, deferred, and nonblocking; Phase 2C remains deferred.

Optional reconciliation retention is local abandonment policy, not chain evidence. It is disabled by default and accepts only explicit constructor values from 3,600,000 through 2,592,000,000 milliseconds. Expiration uses persisted createdAt, never updatedAt, and is evaluated only by an explicit bounded maintenance call that examines at most 64 entries. There is no environment activation, scheduler, startup/request hook, background worker, CLI, or enforced cadence. A backward clock move delays expiration; an undetectable forward jump can terminalize early.

Maintenance uses exact transaction-hash lookup only. Included and unconfirmed observations strengthen active evidence, unavailable lookup retains it, and only exact absence after age can create a tombstone. It acquires the per-payer queue before the global live-SDK owner and retains both through the final journal compare-and-replace. This is a same-process boundary only; it does not coordinate other processes or publishers. Existing tombstones are explicitly rechecked, and late inclusion is retained as operator-visible evidence without automatically delivering, refunding, crediting, retrying, or authorizing replacement.

Live resource URLs must use HTTPS. Paid submissions use manual redirect handling so the signed unpublished block is not forwarded to a redirect target. Missing, malformed or mismatched settlement evidence after submission is treated as uncertain and preserves the same payment for reconciliation. Every /paid response uses Cache-Control: private, no-store and Vary: PAYMENT-SIGNATURE to prevent shared-cache authorization bypass.

Live attempts are stored in a versioned file under the ignored .runtime/ directory. After node-dependent pre-publication checks, the journal persists the exact signed block before publication and uses a same-directory temporary file, file sync, atomic rename, and directory sync where supported. Malformed, inconsistent, oversized or corrupt state fails closed. An initialization marker detects a missing journal file after the first successful write; deleting both files is outside this single-host trust model.

The journal deliberately stores no mnemonic, private key, seed, token or RPC credential. Cached protected responses are plaintext JSON, are limited to 64 KiB, and may themselves be sensitive; filesystem access to .runtime/ is therefore part of the PoC trust boundary. Its default active-record capacity is 256. Tombstones use a fixed separate capacity of 4096, remain within maxFileBytes, participate permanently in online replay and uniqueness checks, and are never evicted or archived automatically. Capacity failure preserves the full active record and fails closed.

Schema v1 remains readable and is not upgraded to v2 by reads, ordinary updates, or disabled retention. The first successful tombstone conversion removes the full record and writes schema v2 atomically in one journal revision; the checksum then covers active records and tombstones. A terminal response is not available until the tombstone durably reloads. Rollback to a v1-only reader is unsupported after v2 appears.

An exact retained tombstone is represented over the local HTTP boundary as response-only 402 with fixed payment_reconciliation_terminal evidence and no recovery owner. This means local retention abandonment only. It is not proof of inclusion, finality, supersession, payer remedy, or safe replacement. The server converts malformed internal terminal candidates to private 500; the buyer converts malformed, mismatched, additional, accessor-backed, or dual-header terminal candidates to same-payment outcome unknown. The legacy payment_settlement_failed dual-header 402 and recovery 409 lanes remain separate. Official parser acceptance is characterized compatibility, not an upstream standard or activation claim.

This is a single-writer, single-process, single-host recovery mechanism. It supplies neither distributed locking nor durable exactly-once execution. In particular, an arbitrary resource callback can perform an external side effect and the process can crash before DELIVERED is recorded. Operators must reconcile DELIVERY_PENDING manually rather than assume whether delivery occurred.

The current CLI has one profile generation and one shared journal namespace. Profile rotation and rollback are unsupported. A future profile generation must isolate its journal state and add cross-profile maintenance, recovery, and rollback tests before activation.

The authenticated future transport requirement remains mandatory for every non-synthetic or consequential credential use; the narrow local plaintext exception in this section does not weaken redaction.

The prepaid-credit modules are separate from the active live-settlement journal. The default-inactive activation adapter is invoked only by the isolated mock demo and captures one constructor-fixed trusted mock verifier, authority profile and version, authority-record digest, store, and clock. It accepts only the synthetic zenon:mock chain profile with exact / upfront funding, one exact payer-signed transaction, first-use MOMENTUM_INCLUDED evidence, and deliveryState: "NONE". Caller-supplied verified flags, per-request authority callbacks, transaction-hash-only assertions, the operator-trusted live record, partial evidence, and holder/payer mismatch cannot authorize credit. This is a mock verification boundary, not authoritative live settlement authentication.

The payer-signed payment resource contains a fixed tag plus two exact halves of a domain-separated grant-funding commitment. The commitment binds verifier-policy identifiers, immutable funding/cost-policy identifiers and versions, provider, service, resource and resource binding, offer version, payer/holder, one-way capability commitment, exact total units and expiry, scheme, flow, mock network and chain profile, asset, amount, and payee. The adapter independently recomputes the payment-resource digest, exact selected-requirement digest, payment-intent digest over the complete one-offer resource-and-requirement envelope, signed transaction-data binding, authorization key, source-settlement identity, and canonical transaction reference. Description text is not an authority signal.

activateGrantFromTrustedRecord is privileged model/store composition, not an untrusted-input verifier. Any code holding the raw model or store handle has grant-minting and administration authority; the method name does not make it cryptographically inaccessible. Never expose that handle or operation through HTTP, to a client, or to client-controlled callback code. The standalone HTTP source does not reference the operation and can use only grants in its validated construction-time snapshot. The mock activation adapter remains the only implemented adapter that directly verifies a settlement in this repository.

The separate src/service-credit-zenon-funding-evidence.js module is a default-inactive consumer contract for a future authenticated Zenon verifier. Its constructor captures exactly one synchronous provider funding-policy function, one verifier function, and one immutable authority, SDK-safe chain profile, confirmation policy, store, and clock. A per-activation caller can select only the stored offer/version, holder, capability commitment, and bound resource URL; it cannot replace either privileged function or propose authoritative units, expiry, payee, asset, amount, or requirement. The fixed provider policy alone derives those complete terms from the immutable offer and holder/capability binding. Its declared policy identity/version must equal the offer. Before returning a payable challenge, the adapter applies the same downstream activation-term grammar used during activation and requires the absolute expiry to be later than a valid captured clock reading. Activation deterministically re-derives and byte-compares the result, then retains separate pre-verifier and post-verifier expiry checks before privileged store mutation.

After a trusted composition/ingress layer has enforced serialized/body and materialized-object size ceilings, an opaque candidate is descriptor-safely detached under cumulative node, member, key-byte, string-byte and canonical-byte budgets, with bounded depth and rejection of cycles or shared references, before the fixed verifier receives it. Arrays and strings receive O(1) length/code-unit rejection before enumeration or byte scanning. Reflect.ownKeys cannot prebound the cardinality of an already materialized plain object, so these traversal budgets are not a substitute for the upstream ingress limit. Only the verifier's complete exact evidence-version-1 record may proceed, and the adapter independently cross-binds its authority identity, payer/holder, provider policy and derived terms, selected requirement, payment resource, offer, capability commitment, chain profile, transaction identity, payment intent, inclusion tuple, confirmation threshold, and funding commitment. Boolean assertions, transaction-only or partial records, extra fields, self-consistent caller-selected economics, and operator-trusted Gate-B records fail before privileged store mutation.

The verifier must report a safe-integer observation count at or above the fixed threshold. That mutable observation count is validated but never persisted or hashed into activation identity. The stable inclusion authorization instead binds MOMENTUM_INCLUDED, the exact transaction hash, Momentum height and hash, and the configured threshold. Re-verification at higher confirmation counts converges to the same activation without a write; a valid height or Momentum-hash change for the same transaction conflicts before mutation.

The fixed provider policy and verifier are privileged trusted composition code, not proof of authentication. The provider policy must return exact plain data synchronously and deterministically for its declared identity/version; Promise and thenable results are invalid. Changing semantics requires a new policy identity or version and a new offer version, causing old challenges to fail closed. Its output is descriptor-safely snapshotted and cannot be replaced per request. The verifier must return an exact extensible native Promise, either initially unmodified or carrying only the adapter-pinned exact constructor descriptor during replay. Unsafe Promise and thenable shapes reject, but violating either trusted return contract can have process-level effects, including an unhandled rejection; no claim is made that every hostile rejected Promise can be safely observed.

This repository does not yet contain a concrete authenticated node/evidence producer, endpoint-authentication mechanism, canonical-chain or reorganization policy, provider funding policy, or operational signer and deployment boundary. The default-inactive pinned-attestation/store bridge below supplies a concrete verifier only for its exact committed artifact. Configuring the consumer with a producer that merely relabels operator-trusted or caller-supplied data would violate this boundary. The module is absent from active HTTP, wallet, RPC, live-evidence, server, buyer, facilitator, demo, benchmark, CLI, and package-default paths and creates no I/O or live effect. Its captured intrinsic references cover its own descriptor snapshots and supported Promise boundary but do not make imported validators or the process a hostile-code sandbox. Its additive model record persists only reviewed identifiers, provider-derived terms, and domain-separated commitments; it does not persist the candidate, raw verifier output, live observation count, signed block, signature, or proof material.

Existing synthetic mock activations remain activation-record version 1 with their exact prior shape. Authenticated Zenon activations use distinct activation-record version 2 and persist evidence version 1 plus the stable inclusion-authorization commitment. The outer domain state schema number remains 2, but its accepted nested grammar has expanded. Before any Zenon version-2 record is committed, rollback to the previous reader remains possible. Afterwards that reader is unsupported and fails closed; retain the database with compatible code, and never delete, downgrade, clear, or reinterpret the activation as rollback.

The separate src/service-credit-zenon-funding-observer-state.js module is a pure, synchronous, default-inactive injected-data validator. One immutable state namespace binds one observer-policy version, authority-generation identity, SDK-safe chain profile, confirmation threshold, complete target economics/resource/funding commitments, and transaction identity. It owns no source. It accepts no authentication flag or source-supplied confirmation count, emits no authenticated evidence, and never imports or calls the funding-evidence consumer, service-credit store, model, HTTP path, wallet, RPC, SDK, or live runtime. Its only projected candidate is explicitly non-authorizing and structurally incompatible with the evidence consumer.

Only a bounded, ordered, unique, parent-linked Momentum page can advance the last fully linked checkpoint. Its receipt keeps only every applied Momentum's exact { height, hash, previousHash } tuple and optional target membership, not unrelated transaction membership. Hydration revalidates the complete lineage and recomputes the page digest from this retained projection. Once such a page links the target, both planning and direct page application preserve that receipt until the separate exact observation transition consumes it. The observer derives confirmations as checkpoint.height - inclusionHeight + 1; equality is idempotent and a later contiguous tip can strengthen the same inclusion. The first threshold record is the actual end cursor and derived count of the first applied page or observation transition that reaches the minimum, so its count may exceed that minimum. This cursor must be strictly after the page start and exactly equal the independently revalidated retained lineage receipt's end and threshold checkpoints. It remains immutable and keeps candidate projection byte-stable. Reproduced-cursor mismatch, inclusion movement or disappearance, chain/profile/authority/target drift, gap skipping, and lineage conflict enter terminal quarantine. Timeout, unavailability, and a source behind the checkpoint do not mutate or rewind state. Quarantine cannot be cleared automatically in state schema v1.

Exact schemas, descriptor-safe snapshots, cycle/shared-reference rejection, cumulative traversal/canonical byte bounds, detached deeply frozen values, revision checks, and domain-separated commitments limit accidental ambiguity after trusted ingress. A party that controls the injected canonical data can recompute unkeyed commitments, so these internal cross-field checks are not cryptographic authentication. They also cannot prebound the memory already consumed by an enormous materialized object; a future ingress owner must impose serialized/body and materialized-object ceilings first. The observer proves no endpoint identity, canonical chain, freshness, finality, recipient receipt, spendability, or reorganization policy. It has no source transport, signer custody, fencing, worker cancellation, reconnect scheduler, live producer, grant authority, deployment, release, or production support. Post-grant reorganization economics and authenticated checkpoint governance remain open. It neither satisfies nor closes Issue #81. The SQLite owner below imports this module, so that dependent slice must be removed first or both slices must roll back together. Once no dependent remains, removal of this module, test, and related documentation rolls back the pure slice without migrating any existing schema or state.

The separate src/service-credit-zenon-funding-provider-attestation.js module is default-inactive and synchronous. It accepts one exact canonical authority record provisioned through an independently reviewed local channel, validates one exact raw Ed25519 public key, and binds the provider authority, key generation, network, SDK-safe chain and genesis identity, observer and confirmation policies, bootstrap checkpoint, source-policy commitment, and fixed size/time limits into domain-separated commitments. It emits deterministic signing bytes for an exact request and verifies an exact envelope, but returns only the attestation identity and envelope digest. It owns no private key, signing callback, observer-state derivation, source, transport, clock, filesystem, store, consumer, or grant authority.

The security claim is intentionally narrow: a valid envelope is a provider-authenticated assertion that the pinned key signed the bound request. It is not evidence that the signer was truthful and proves no endpoint/node provenance, canonical chain, consensus finality, recipient receive, spendability, or protection from a later reorganization. The pure parser/verifier is non-authorizing; it cannot derive a signing request or #104 evidence from caller-supplied observer state. Only the bound store below may construct a request from its committed history and later match the exact committed READY artifact. Plain WS, Gate-B/operator-trusted observations, raw #105 candidates, transaction-only records, and caller-supplied authenticated flags are ineligible.

The authority public key is configuration data, not a secret, but authority provisioning and signer custody remain privileged operational boundaries. Rotation or revocation is never in place: use a new independently reviewed authority record, generation, key, and store namespace. This version supplies no revocation distribution, key-custody mechanism, anti-rollback protection against a same-identity database controller, or cross-provider equivocation detection. Input traversal bounds assume an upstream serialized and already-materialized object ceiling. These limits and signature verification do not make arbitrary same-process code hostile-safe.

The separate src/service-credit-zenon-funding-observer-sqlite-store.js module is an explicitly invoked, default-inactive domain owner for exactly one pure observer state and pinned authority. Schema v2 binds its record key to the observer identity, target-binding digest, and authority-record digest, and persists the canonical authority record, immutable creation bootstrap, observer state, and exact outbox in one checksummed envelope. Create accepts only the canonical pristine #105 state at the authority bootstrap: revision zero, AWAITING_INCLUSION, and null receipt, inclusion, threshold, and quarantine. A valid state built from untrusted pre-bootstrap history is rejected even if it ends at that bootstrap. Explicit open requires the expected external authority anchor and record key. The checksum detects accidental corruption but is unkeyed; a same-identity controller with database-write access can recompute it and remains trusted.

Every mutating operation uses BEGIN IMMEDIATE, rereads and fully validates committed state, enforces its exact expected revision, invokes only the existing pure transition, and writes at most one replacement envelope. An exact no-op performs no update. Ordinary planning remains a read snapshot, except that a definitive pure-state cursor conflict persists terminal quarantine under these same transaction rules before returning. Only after commit, file-identity revalidation, and exact committed-byte reread may a detached frozen result return. Definite failure before commit attempt rolls back. Failure at or after commit attempt is conservatively ZENON_FUNDING_OBSERVER_STORE_COMMIT_OUTCOME_UNKNOWN, closes the handle, returns no state or candidate, and permits no automatic retry. Explicit reopen reveals exactly an old or new valid state; normal replay and stale-revision handling then converge. Two cooperating handles or processes sharing the supported file serialize writers; this is not distributed ownership.

The owner enforces absolute canonical database paths under one exact private allowed root, private current-user directory and file modes, regular-file and link-count checks, inode continuity, exact supported rollback-journal sidecars, synchronous = FULL, fixed application and user versions, an exact schema and row grammar, canonical byte ceilings, and corruption checks. Exclusive create rejects every pre-existing matching sidecar without deleting it. Explicit open may recover only an exact safe rollback journal. Replacement, unexpected sidecars, unsafe modes or links, corruption, schema drift, and commit ambiguity latch the handle closed. These checks assume a reliable local POSIX filesystem and cannot protect against the host kernel, privileged or arbitrary same-identity code, unsupported network/cloud-synchronized storage, or already materialized oversized objects before trusted ingress bounds them. Test-only fault hooks are trusted construction inputs and grant no state-bypass path.

The first threshold-eligible observer transition and its exact PREPARED signing request commit together. commitAuthenticatedEnvelope revalidates the committed state, authority, request, time window, and pinned Ed25519 signature inside BEGIN IMMEDIATE, then stores immutable READY before returning an opaque digest reference. Exact replay converges. A second distinct valid assertion enters EQUIVOCATED; invalid input never causes that durable denial state. A later committed observer conflict changes PREPARED or READY to INVALIDATED. Both terminal statuses suppress the legacy observation candidate and authenticated-evidence projection. This cannot revoke or claw back an entitlement already activated in #104.

peekPreparedAttestation() is the only signing-request read. projectCommittedFundingEvidence() returns no signature or raw envelope, and matchReadyFundingEvidence() rereads and verifies the exact committed authority, state, request, envelope, digest reference, and signature before returning the complete #104 record. The existing load() API remains a privileged internal full-observer-state read and therefore includes the established target and transaction bindings, but its outbox view contains only version, revision, and status and it exposes no authority public key, request, envelope, signature, or raw database text. Never log load() or return it through HTTP/public responses. Separate observer and service-credit databases do not provide cross-database atomicity or exactly-once activation.

Commit-attempt ambiguity for either state/PREPARED or READY latches the handle and returns no tentative candidate, request, artifact, evidence, or success. Reopen exposes the exact old or new committed status so recovery must reuse the same request and envelope. The module still owns no source callback, RPC, TLS, SDK session, timer, worker, environment, wallet, signer, private key, payment, service-credit mutation, HTTP route, startup import, deployment, release, or production support. Plain WS remains operator-trusted and cannot be promoted here. It authenticates no endpoint, node, canonical chain, freshness, finality, recipient receipt, spendability, or reorganization policy and does not close Issue #81.

Schema v2 has no migration, repair, downgrade, deletion, or v1 reinterpretation. Existing v1 databases are rejected without modification. Before any v2 database exists, rollback removes the two new attestation paths and reverts the five modified paths in this slice. Once v2 PREPARED or READY state exists, compatible code and data must be retained, or the database may be discarded only after proving no unresolved outbox state remains; it must never be opened as v1. The offline READY-to-durable-grant owner below fulfills the bounded local composition milestone. The remaining gates are an independently provisioned authenticated producer, signer, and key-lifecycle boundary plus explicit bounded runtime and HTTP wiring. No additional generic infrastructure tranche is scheduled first.

The default-inactive src/service-credit-zenon-funding-composition.js owner accepts only exact unadorned observer/outbox and service-credit SQLite store instances plus one canonical pinned authority record, one constructor-fixed deterministic provider policy, and one clock. It exercises captured read-only methods during construction to prove both stores' private brands, captures the required prototype operations, recomputes the authority-bound observer record key, and constructs the authenticated-Zenon consumer behind a private store facade. Before provider-policy evaluation and again immediately before returning a payable challenge, it rereads committed observer state and revalidates the authority, record key, and every captured immutable observer binding. Only open, non-quarantined NONE, PREPARED, or READY state may reconstruct a challenge; INVALIDATED, EQUIVOCATED, corrupt, closed, replaced, or drifted state returns none. The challenge's complete economic, resource, intent, chain, confirmation, and funding binding must still match the immutable observer target. Activation obtains the opaque artifact only through the captured observer projection and matches it again against committed READY state; no caller can inject an artifact, authority, key, verifier, state, matcher, store, outbox, or grant function. Invalidation or valid provider equivocation between projection and matching prevents grant mutation.

The owner permits at most one in-flight activation and does not queue a different request. Exact concurrent and completed replay converge through the service-credit activation identity. A service-credit commit-outcome ambiguity returns no success and permanently latches that owner instance. Recovery is explicit close, reopen of both databases, reconstruction with the same bindings, and exact replay. The immutable observer READY record is not marked consumed. These stores have independent transactions, so this boundary makes no cross-database exactly-once, atomicity, consumption, or anti-rollback claim.

The accepted record proves only that the pinned provider key signed the exact committed assertion. It remains a provider-authenticated historical assertion rather than proof of signer truthfulness, endpoint or node provenance, canonical chain, consensus finality, recipient receipt, spendability, or reorganization immunity. Plain WS, Gate-B, raw observer candidates, and caller authentication flags remain operator-trusted or unauthenticated and cannot satisfy this lane. The module owns no private key, signer, network client, RPC, WebSocket, wallet, payment, listener, route, environment switch, deployment, or live-runtime import. Its direct durable-session tests are offline and listener-free. An independently reviewed authenticated producer/signer and explicit bounded runtime wiring remain separate authorization and activation gates. Issue #81 remains open and unrelated.

This slice adds no database migration. Code rollback does not remove committed READY data or revoke an activated grant. Resolve any ambiguous activation through reopen and exact replay before rollback, and retain compatible readers until the operator has separately established that both databases and any unresolved state can be discarded safely.

The separately imported src/service-credit-zenon-durable-http-composition.js owner requires exact already-open observer and service-credit SQLite instances, a committed READY outbox, one pinned authority, one fixed deterministic provider policy and clock, one exact durable-execution configuration, and fixed application/deadline callbacks. Construction performs bounded committed-state inspection only. It neither creates an artifact nor activates credit and has no listener, source, signer, private key, wallet, payment, RPC, WebSocket, network, environment, or active-runtime path.

One explicit start validates its configuration with the existing pure execution contract, then initializes or exactly reuses an empty/open durable-execution generation before grant activation. The preinitialization is the exact store-owned capacity check, is deterministic and non-authorizing, and may remain after a later definite activation rejection without exposing service. Startup then privately activates or replays the exact committed assertion, constructs the existing listener-free durable session, and exposes admission only after all boundaries succeed. Exact concurrent startup shares one native Promise; different input is rejected without a queue. All non-active states allocate the same fixed private unavailable HTTP response independently and cannot call application code. Definite pre-activation failure enters PRE_ACTIVATION_UNAVAILABLE without claiming a grant. Activation or initialization commit ambiguity enters RECOVERY_REQUIRED, while a definite failure after completed grant activation enters ACTIVATED_UNAVAILABLE; none returns tentative success or a handler.

Close gates new admission immediately, waits for startup and admitted durable work where their outcome is controllable, then closes the session, observer store, and service-credit store in fixed order. A callback-context close attempt fails with one fixed private code so an external owner can retry after settlement. Startup RECOVERY_REQUIRED or ACTIVATED_UNAVAILABLE is never erased by concurrent or later close: safe closure still returns the stable terminal error instead of CLOSED. An ambiguous or failed close likewise never reports clean closure. This is a cooperating same-process custody contract, not protection against trusted code that retained the raw borrowed handles. A future listener must stop external ingress first.

Upstream composition must bound serialized and already-materialized inputs before calling this internal owner. The owner's traversal ceilings bound post-ingress validation and copying, but JavaScript cannot prebound Reflect.ownKeys over an object that has already been materialized with an arbitrarily large key set.

The READY record remains only a pinned-provider historical assertion and is never marked consumed. Independent databases add no atomicity, exactly-once, or anti-rollback guarantee. Invalidation after activation cannot claw back issued or spent credit. Plain WS remains operator-trusted and ineligible. The module proves no public-chain canonicality, finality, receipt, spendability, reorganization safety, deployment, release, or live readiness, and Issue #81 remains open and separate. Remaining gates are authenticated producer and signer provisioning with key custody/lifecycle, authenticated transport and listener ownership, chain/finality/reorganization/loss policy, and operational recovery.

Rollback before use removes this six-path slice. After use, first stop admission and prove clean session/owner closure, reconcile any ambiguous activation by reopening both stores and exact replay, and preserve compatible READY, activation, execution, and journal records. Code removal does not revoke, reconcile, or downgrade persisted state.

The deriveCost callback and constructor-fixed funding-policy implementation are trusted server code. Their semantics are not authenticated; the model binds only declared immutable identifiers, versions, provider-derived terms, and resulting commitments. Semantic changes require new policy identifiers or versions and a new offer version. Reuse of an old identity for changed implementation code cannot be detected. Exact provider-derived funding totalUnits, absolute expiry, and payment requirement become payer-signed through the constructed payment challenge, and each service request separately signs its maxCostUnits ceiling.

The capability module derives a domain-separated commitment from one canonical raw Ed25519 public key and verifies proof of possession over a separately domain-separated request message. The signed fields include the model version, grant and request identifiers, method, route, canonical body digest, selected content type, and the holder's positive maxCostUnits ceiling. The model rejects a server-derived cost above that signed ceiling before reservation. The module accepts no private key or raw bearer preimage, exports no signing function, and does not establish human, wallet, settlement, or chain identity. Exact signed-proof replay remains possible and is contained by the durable request identifier and identity-conflict rules.

The isolated createServiceCreditAuthorization client serializer accepts only one exact plain-data grant, request, and already-signed proof tuple. It captures those objects once, invokes the capability verifier, rechecks the complete returned binding, and emits only the canonical unpadded ServiceCredit authorization string. Successful serialization proves only cryptographic consistency among the supplied grant, request, and proof. The header payload contains only the six-field proof; it does not encode the method, route, body digest, or content type and does not guarantee admission by a particular handler. It must accompany the identical out-of-band request context. The legacy handler and opt-in durable session enforce the same exact POST, route service-credit.execute.v1, empty-body digest, and application/json context through the shared non-authorizing createServiceCreditHttpAdmission({ store }) boundary. That helper returns only frozen normalized admission decisions and no execution or response authority. A broader shared client-and-handler wire module is a possible later refactor; the current helper remains server-side admission only. The serializer accepts no signer, private key, key generator, path, transport, or persistence capability. The authorization and its embedded proof, signature, public key, grant identifier, and request identifier are bearer-like single-request credential material: redact them from logs, diagnostics, snapshots, and general persistence. Outside the disposable synthetic-only local test and demo boundary, carry them only over authenticated transport. The service-credit ledger's existing privacy-reviewed grant and request identifiers remain documented accounting keys; it does not persist the authorization, proof, signature, or public key. Temporary encoding buffers are cleared where practical, but JavaScript strings cannot be reliably erased and process memory cannot be reliably zeroized.

Request cost is derived by trusted synchronous server policy and pinned on first reservation. Exact accounting preserves totalUnits = availableUnits + heldUnits + consumedUnits. Only the first durably committed RESERVED -> EXECUTING transition on an active grant authorizes execution. Failure before execution may release the reservation; ambiguity after execution remains OUTCOME_UNKNOWN with units held until privileged reconciliation based on authoritative external evidence. That reconciliation method must never be exposed to a capability holder or unauthenticated client.

The SQLite reference uses BEGIN IMMEDIATE, synchronous = FULL, rollback-journal mode, a canonical checksummed envelope, bounded state, and restrictive current-user filesystem checks. Activation and its ACTIVE grant are written in one transaction; the activation is the consumption marker. Exact replay returns the same activation and grant without a revision change, while changed settlement, transaction, capability, or grant bindings conflict before mutation. It coordinates competing writers only on one reliable local filesystem. Network mounts, cloud-synchronized storage, cross-store and multi-host operation, hostile same-UID code, the host kernel, distributed transactions, and external-effect atomicity remain outside its guarantee.

Expiry is checked before the captured verifier runs and again after positive evidence inside the store transaction. An expired intent is rejected before verification. Positive settlement followed by expiry or a definite pre-commit failure returns SERVICE_CREDIT_ACTIVATION_SETTLED_NOT_GRANTED, which grants no replacement-payment authority. Once commit is attempted, any thrown or ambiguous result returns SERVICE_CREDIT_ACTIVATION_OUTCOME_UNKNOWN, quarantines the store, claims neither success nor rollback, and is never automatically retried. Only reopen plus explicit exact re-verification can recover.

The standalone HTTP slice accepts exactly POST /service-credit/v1/execute with empty framing and one canonical ServiceCredit authorization proof. It returns fixed private, non-cacheable JSON responses and supports only a successful { "ok": true, "resultCode": "..." } shape. Construction loads and fully validates one durable state snapshot, then freezes a bounded admission index of grant identifiers and capability commitments. Grants activated later are unavailable until the handler is reconstructed. Live grant lifecycle, expiry, revocation, cost, available units, and replay state are still enforced transactionally by the store.

Each handler accepts at most 64 request starts in one second and permits at most eight active executions. Excess work receives a fixed unavailable response; there is no queue. These limits do not coordinate across handlers, processes, hosts, or restarts. The application callback has no timeout, so one active slot remains occupied while it is pending. The handler durably reserves and begins before callback execution, returns a cached fixed result for success, and preserves conservative EXECUTING or OUTCOME_UNKNOWN behavior after ambiguity. It provides no distributed exactly-once guarantee.

The current schema-v2 model/store lane also applies a schema-neutral unresolved-state admission guard over the complete ledger. Exact existing-request replay and conflict validation take precedence. While any request is EXECUTING or OUTCOME_UNKNOWN, genuinely new reservations and distinct transitions from RESERVED to EXECUTING fail before clock, pricing, accounting, revision, or callback effects. The same pre-effect boundary enforces the existing 100,000-request hydration ceiling before a new record can reserve units; at capacity, existing replay and conflict semantics remain available. The unchanged HTTP error boundary maps that internal refusal to its fixed private 503 response; an exact unresolved replay retains its existing non-authorizing response, and cached durable success remains readable. BEGIN IMMEDIATE makes the decision coherent only for processes sharing the same supported SQLite ledger. The resulting effective distinct-callback concurrency is one per ledger, while eight remains a separate generic handler upper bound. A stuck or legacy unresolved record can intentionally deny service indefinitely.

This is a current-state admission brake, not a persisted execution generation or completion of the future contract below. It adds no deadline, signal, invocation fence, generation seal, canonical evidence, successor activation, distributed ownership, or automatic recovery. The current raw privileged reconcileRequest may terminalize its one OUTCOME_UNKNOWN record under the existing external-evidence trust assumption and thereby remove that current-state blocker; it does not authenticate the actor or evidence and is not the future private reconciliation boundary. Rollback requires stopped ingress and proof that no EXECUTING or OUTCOME_UNKNOWN record remains in the ledger. Removing the guard does not reconcile an external effect.

The standalone src/service-credit-execution-contract.js module is a pure, inactive reference core. Only the opt-in SQLite store imports it directly. The current model, HTTP handler, composition owner, pre-existing demos, ordinary package commands, and active paths neither call its API nor initialize durable mode; only the separately named durable loopback demo opts into the store surface, and every demo loads the pure core only transitively. It accepts only explicit plain data: a non-secret ledger identity, one immutable versioned policy, a bounded capacity, complete request identity, caller-selected duration, caller-supplied wall-clock samples, and canonical SHA-256 commitments. It reads no clock, chooses no randomness, invokes no callback, and owns no timer, signal, environment, filesystem, SQLite, transport, or reconciliation authority. The policy supplies no default timeout; every positive selected duration must be within its positive safe-integer bound. A 600,000-millisecond policy is only a possible later operational evaluation, not a constant or product decision here.

The core deterministically creates one initial generation and separates PREPARED from MAY_HAVE_STARTED. Preparation never authorizes invocation. A fence result contains only explicitly named candidate state and execution data and never grants permission to invoke. Repeated evaluation of the same stale prepared snapshot merely reproduces the same candidate. The optional store integration rereads durable state and conditionally persists a recomputed candidate under SQLite serialization. Even its freshly acknowledged APPLIED fence receipt is only durable-transition evidence; only the separately reviewed owner below may consume that one event as an ephemeral process-control decision. Success and uncertainty produce immutable winner candidates, and the store CAS selects one durable winner under contention. For a live fenced execution, the pure completion operation now requires an explicit wall-clock sample: a sample before the persisted start or at or beyond the deadline selects sealed uncertainty, while only the half-open interval from start through just before the deadline can select success. Terminal replay remains clock-free. Success first cannot be downgraded or seal the generation; uncertainty first marks that execution unknown, seals the generation against new prepare or fence transitions, and treats late success as non-mutating. Restart recovery classifies unfenced preparation as definitely not invoked, maps fenced nonterminal work to unknown and sealing without invocation, preserves terminal records, treats exact deadline equality as expired, and fails closed on backward wall-clock movement.

Every input and hydrated snapshot has an exact bounded own-data shape, and every returned snapshot is detached and deeply frozen. Identities are deterministic and domain separated. The module captures the specific security-relevant built-ins it dispatches through; isolated tests verify deterministic identity, execution selection, replay and conflict precedence, sealing, and fixed errors after post-import poisoning of those exercised intrinsics and inherited setters. This targeted hardening does not resist pre-import poisoning, module replacement, arbitrary trusted same-process code, workers, or operating-system observation. Capacity saturation, invalid shape, unsafe arithmetic, and conflicting request, policy, result, or seal data fail with fixed cause-free errors before mutation. The core persists no arbitrary callback result, diagnostic, evidence, credential, or secret, and provides no reconciliation, seal-clear, successor, migration, or downgrade surface.

The pure module itself does not change schema v2, HTTP behavior, callback execution, or unit accounting. Its store integration below performs the ledger release associated with a proven no-invocation classification in the same compound transaction, without persisting an intermediate unknown state. Active completion captures one trusted wall-clock sample only after the writer lock, reread, expected-revision check, and live-fence validation, then atomically persists either success or sealed uncertainty across ledger and execution state. Structural hydration and deterministic hashes do not authenticate serialized state. The separate opt-in owner below supplies bounded in-process scheduling and advisory abort, but these layers remain short of authenticated reconciliation, successor-generation, worker/process isolation, active HTTP/composition mounting, authenticated transport, or production/live readiness.

The standalone createDurableServiceCreditExecutionOwner({ store, execute, deadlineRuntime }) factory captures one exact already-initialized durable SQLite store handle, one trusted callback, and one exact trusted monotonic runtime with monotonicNowNs, schedule, and cancel; schedule returns an opaque handle and cancel must consume it and return exactly undefined. It returns only deeply frozen run and close operations. Import and construction perform no store, callback, clock, timer, listener, signal, process, filesystem, or network operation. The owner neither initializes nor closes the store and never calls restart recovery, raw reconciliation, migration, generation clearing, or successor activation.

run accepts only the exact existing reservation shape plus one selected duration. It obtains the current revision internally, invokes atomic preparation once, and proceeds only from its own fresh APPLIED PREPARED receipt. It persists the fence once and invokes the callback only when that same operation returns a fresh APPLIED MAY_HAVE_STARTED execution. This ephemeral process-control decision is consumed immediately and never crosses the returned surface. STALE, replayed or UNCHANGED preparation and fencing, reopened nonterminal work, and sealed or unknown state never invoke, refresh, or retry. An exact terminal replay returns a detached cached result without callback execution. A pre-invocation prepare or fence commit ambiguity also starts no callback. Terminal-persistence ambiguity can occur after callback execution; it reports no success, latches the owner, and never retries.

The transactional store wall clock is the durable completion adjudicator. The owner captures monotonic time immediately before the fence and, only for a fresh applied live fence, derives a monotonic target from the remaining wall-clock duration without comparing timestamps from the two clock domains. A chunked injected timer handles early wakes and treats equality as expiry; the monotonic clock only schedules and does not survive restart. The store may still select uncertainty on completion after a forward wall-clock jump, suspension, delayed event-loop control, or regression. A timer win, callback loss, monotonic regression, or timer-control fault makes one conservative durable unknown attempt without retry. Only an applied or read-back-proven durable unknown result dispatches the callback's advisory AbortSignal; it proves neither cancellation nor rollback. There is no Promise.race or hard-real-time guarantee.

An unknown classification may return before the callback settles, but active accounting and quarantine remain until late fulfillment or rejection is observed and drained. Late settlement performs no completion, retry, release, reconciliation, or reopening. If a competing durable success or unknown transition has already won, the owner reports only that terminal classification; if terminal state cannot be proven after callback control was lost, it latches fail-closed and reports no success. Result commitments remain integrity and cross-link checks, not authentication or external-effect evidence.

One owner admits only one run at a time and never coalesces duplicates. Callback-context run and close, including calls into another owner in the same async context, reject before lifecycle or store effects. Different handles and processes coordinate only through the same supported SQLite ledger. Exactly one fresh fence may win and therefore at most one cooperating owner callback may start, but process death, hostile same-user code, or an external side effect outside SQLite prevents any exactly-once claim.

close stops new owner admission and waits for every owner-started callback, its terminal persistence attempt, late callback observation, and proven timer cleanup. It is wait-only: shutdown itself does not abort, time out, release, complete, or mark unknown. The normal deadline timer remains active. It does not recover, reconcile, or close the borrowed store. A never-settling callback that ignores abort can keep close pending and retain durable capacity indefinitely. Commit or timer-cleanup ambiguity permanently latches the owner; close may resolve only after local callback work settles and does not imply durable availability. This owner remains opt-in, unreleased, and unactivated. Its only HTTP consumer is the unmounted synthetic session below; that session is constructed by the separately named durable loopback demo and exercised twice by the bounded pilot below, while all remain absent from the current /paid server, mounted handler and composition owner, benchmark, wallet, RPC, settlement, and live paths.

Rollback requires stopping admission and obtaining a clean resolved close. A database containing active, unknown, sealed, ambiguous, or otherwise unresolved durable state must be retained with compatible durable-execution code. Clearing, releasing, downgrading, deleting, or interpreting code removal as reconciliation is prohibited. Explicit operator restart recovery remains outside the owner and is deterministic store recovery, not authenticated canonical reconciliation. Active HTTP/composition mounting, authenticated transport and reconciliation, successor generations, worker/process isolation, and broader measured load and capacity testing remain later milestones.

createServiceCreditHttpAdmission({ store }) is the shared non-authorizing parser and admission boundary for the legacy handler and the separate durable session. It returns only frozen normalized decisions and exposes no execution or response authority. createDurableServiceCreditHttpSession({ store, execute, deadlineRuntime, selectedDurationMs }) privately constructs the reviewed durable owner over one already initialized borrowed store and returns only frozen handle and close operations. It owns no listener or store, does not mount itself, and never initializes, recovers, reconciles, retries, or closes the store. The server fixes the positive duration at construction within the persisted policy; a client cannot select it.

Synthetic funding and activation, followed by explicit durable initialization, must finish before construction. Funding and administrative writers must remain quiesced while the session serves because an unrelated global compound-revision change makes the owner fail closed and can retain unresolved execution state. The supported shutdown sequence is to stop and close transport admission, await session close, and only then close the borrowed store. Closing the store underneath a live session is prohibited.

The admission boundary retains the fixed private 400, 401, 404, and 405 responses. Request-identity conflict and terminal NOT_INVOKED map to fixed private 409; busy, stale, recovery-required, unknown, closed, quarantined, ambiguous, and unclassified results map to fixed private 503. A 200 is serialized only from a strictly validated durable SUCCEEDED result or matching exact CACHED_SUCCESS. Every response remains fixed private, no-store JSON with no internal diagnostic or retry instruction. Exact replay returns the same cached response without callback execution, debit, or revision change.

Identical concurrent requests are not coalesced. A losing overlap receives 503; after the durable winner completes, a later exact replay may return the cached 200. A disconnect stops neither callback nor durable ownership, proves no outcome, and grants no authority to replace or retry work. Session close is wait-only. Callback-context close rejects promptly even while an external close is pending; accepted external close waits for owned callback work and terminal persistence and may remain pending forever if trusted work never settles.

Deterministic tests use plaintext numeric loopback and disposable synthetic bearer-like credentials only. Outside that boundary authenticated transport is required. SQLite coordination applies only to cooperating processes using one supported local ledger; it provides no distributed ownership or exactly-once external-effect guarantee. The session performs no automatic recovery or reconciliation, successor activation, live x402, L1 settlement or finality, release, activation, or production operation. Rollback requires stopped admission, ordered transport/session/store closure, and proof that no active, unknown, sealed, ambiguous, or otherwise unresolved execution remains. Otherwise the database and compatible code must be retained; clearing, releasing, downgrading, deleting, or reinterpreting unresolved state is not rollback.

The separately named npm run --silent demo:service-credit-durable-loopback command is an opt-in, unreleased, unactivated, unmounted synthetic-only scenario. It directly composes the existing mock settlement-to-activation verifier, explicit durable-store initialization, durable HTTP session, and bounded numeric IPv4 loopback transport; it neither calls the privileged direct-grant method nor enters the active /paid, composition, wallet, RPC, settlement, or live paths. The server-selected execution duration is fixed in code. Funding and administrative mutation remain quiescent while either session phase serves.

Phase one handles A, exact replay A, and B, then closes transport, session, and the borrowed store in that order. Only after that closure and an exact directory/database identity check does a clean terminal-state reopen create a new store, session, and listener. Cached A and B do not invoke, debit, or revise; C produces the third callback and durable success. The final validated ledger therefore records one mock settlement and activation, three callbacks and successful executions, six units consumed, zero held, and one available. Fixed private 400, 401, 404, 405, 409, and 503 outcomes carry no authority; 200 remains restricted to validated durable success or matching cached success.

The client makes one fresh connection per sequential request, follows no redirect, coalesces nothing, and performs no automatic retry or replacement. Disconnect and transport timeout do not cancel callback work. Deadline unknown, commit ambiguity, response uncertainty, validation failure, or close uncertainty cannot authorize another callback, debit, settlement, request, or cleanup. The demo performs no automatic restart recovery or reconciliation. Its reopen is permitted only after fully terminal phase-one state and proven orderly closure; every uncertain path retains the database and compatible code for explicit adjudication.

The runner captures the exercised store and mock settlement/activation lifecycle methods at import and uses those references for its own dispatches. It validates the admission layer's live store-load seam and the facilitator constructor's live verifier seam before they can run. This is narrow post-import prototype-replacement hardening, not resistance to pre-import poisoning, module replacement, or arbitrary trusted same-process code.

The temporary boundary assumes a reliable POSIX local filesystem and trusted kernel. It records the process user, canonical parent, directory, and database identities, requires private modes, a regular single-link file, and one exact directory entry, and checks those facts immediately before reopen and deletion. Cleanup is non-recursive and success-only. Detected replacement, symlink, hard link, sidecar, identity drift, or failed close/inspection prevents deletion. If protected synthetic credential bytes are detected only during final inspection of otherwise terminal identity-verified state, the runner deletes that exact owned file and empty directory but still returns its fixed failure. Same-UID hostile mutation outside the synchronous checks is not solved, and abrupt termination may leave a plaintext synthetic ledger.

The public result is a deeply frozen fixed aggregate and the CLI emits only a fixed success or failure line. Neither includes credentials, identifiers, route metadata, database content, raw responses, timestamps, durations, or diagnostics. A short descriptor write may have emitted a fixed partial prefix; all streams from a nonzero run are invalid and must be discarded. The demo uses plaintext loopback only with disposable synthetic bearer-like material. Authenticated transport remains mandatory for consequential credentials when same-host observers are not trusted. It makes no exactly-once external effects, distributed ownership, live x402, L1 settlement or finality, benchmark, performance, release, activation, or production-readiness claim.

The separately named npm run --silent pilot:service-credit-durable-local-load command is opt-in, unreleased, unactivated, unmounted, and synthetic-only. Its zero-argument runner starts exactly two same-process asynchronous calls to the import-captured durable loopback demo before awaiting either. Those children own two independent durable ledgers, stores, sessions, listeners, mock settlements, and activations. There is no shared-ledger capacity test, worker, child process, active import, schema or dependency change, timing threshold, or new execution authority.

One loaded module admits one pilot run at a time. Immediately after both fixed launch attempts, every accepted native lane Promise receives an exact immutable own constructor pin and then a module-intrinsic await observer before the post-launch integrity decision and any permanent quarantine. If either safely observed lane fails, the runner still drains every safely observed lane, performs no retry, replacement, cancellation, recovery, reconciliation, or successor action, and returns only a fixed cause-free failure. Failed pinning, broken scheduling integrity, an unobservable possibly started lane, or a never-settling lane keeps the operation and module-local latch pending. The pilot validates each child as the exact deeply frozen durable-demo summary using captured descriptor-safe dispatch. This covers the exercised post-import substitutions only; it does not resist pre-import module replacement, arbitrary trusted same-process code, or operating-system observation.

The fixed aggregate reports two mock funding settlements and activations, six application callbacks and durable successes, 12 units consumed, zero held, two available, stable exact replay and clean terminal reopen, and verified child cleanup. It records no timing and is not a benchmark. It establishes no throughput, latency, TPS, capacity, scalability, same-ledger concurrency, distributed ownership, exactly-once external effect, authenticated transport, live x402, L1 finality, release, activation, or production property. Authenticated transport, active mounting, restart recovery, and reconciliation remain separately reviewed gates.

The pilot does not delete or retain filesystem state itself: each child durable demo owns its identity checks, success-only exact cleanup, and fail-closed quarantine. A failed or never-settling child cannot produce aggregate success. Plaintext numeric loopback and disposable synthetic bearer-like material retain the existing same-host observation and denial-of-service boundary. Rollback is exactly eight paths: remove the pilot source, CLI, and focused test; remove its package command; remove this milestone's text from the three documents; and revert only its closed package/import assertions in the loopback-server test. Operators must stop new admission and await every started lane. Any unresolved child ledger remains with compatible code.

The current mounted handler has no application-callback deadline, no AbortSignal contract, no durable execution owner wiring, and no restart-time deadline control. Its transport receive, inactivity, request, and shutdown bounds do not cancel callback work or establish its outcome. The active path still uses only the legacy durable RESERVED -> EXECUTING transition before callback invocation. The opt-in session above connects shared HTTP admission to the durable owner only when explicitly constructed. The separately named durable loopback demo constructs it through its explicit package command, but no composition owner, /paid server, or active runtime mounts it.

The implemented opt-in owner uses atomic store preparation to bind the execution identity, initial generation, exact policy, selected duration, restart-reconstructable wall-clock deadline, and ledger EXECUTING state before invocation. It then requires one freshly acknowledged APPLIED PREPARED -> MAY_HAVE_STARTED transition before calling user code; neither the pure candidate nor an UNCHANGED or STALE receipt authorizes invocation. The volatile monotonic schedule cannot reconstruct or adjudicate a deadline after restart; only the transactional wall-clock sample can select the durable completion winner. Restart recovery therefore remains explicit and outside the owner.

A failure proved to occur before any invocation-fence commit attempt may follow an explicitly safe pre-invocation recovery path. Once that commit is attempted, acknowledged, or ambiguous, crash or reopen must assume invocation may have begun: it must quarantine and must never automatically re-invoke the callback or release its value. Crash and commit-acknowledgement loss must be tested at every boundary around the execution transition, the fence, and invocation.

Callback completion and deadline, disconnect, abort, shutdown, or lost-control uncertainty use conditional durable transitions with one transactional winner in the opt-in store and owner. A SUCCEEDED result durably committed before an uncertainty transition remains success; later response-delivery loss, disconnect, or acknowledgement loss neither downgrades the request nor quarantines its owner/store generation, and may affect only response recovery under existing semantics. An OUTCOME_UNKNOWN or quarantine durably committed first blocks late completion, release, retry, and ordinary admission or reopen. If ordering or acknowledgement of either commit is ambiguous, the implementation preserves the last proven durable state, stops admission, requires reopen and readback, and fails closed. Reopen distinguishes EXECUTING, OUTCOME_UNKNOWN, and SUCCEEDED. Explicit deterministic store recovery classifies a reopened fenced EXECUTING request as unknown and sealed without re-invocation or release; it is operator-invoked outside the owner and is not authenticated reconciliation authority.

A post-fence deadline, disconnect, abort, shutdown, or loss of callback control quarantines the affected request, its reservation and grant value, and the entire current owner/store generation only when its uncertainty transition wins before any proven terminal success, or when ordering or commit acknowledgement is ambiguous. A durably proven earlier SUCCEEDED result follows the response-recovery rule above instead. Once sealed, the persisted gate stops all new callbacks, reservations, and reauthorizations for the generation, including unrelated requests, while tracking every callback already fenced or in flight in that generation. The opt-in SQLite store enforces this gate across cooperating handles and processes that share its one supported local ledger. It does not provide distributed or multi-host ownership. A timed-out, ignored, or never-settling callback retains its active-execution and shutdown/close accounting slot until its promise settles. Returning an unknown result to the caller does not free capacity. The strict global latch prevents further accumulation beyond the configured ceiling, and normal service does not resume automatically if the callback never settles. A successfully persisted unknown and uncertainty while persisting it both stop admission; the latter requires reopen and readback before the durable state can even be classified.

Reconciliation of one request must not reopen a sealed generation while any other fenced request is live, EXECUTING, OUTCOME_UNKNOWN, commit-ambiguous, or otherwise lacks a proven terminal reconciliation. The old generation remains sealed until every fenced request has a proven terminal classification and every associated callback has settled, or terminal evidence proves that callback cannot create any later effect. Clearing the gate and creating or activating a successor generation must be one durable conditional transition. Partial, stale, conflicting, or concurrently losing reconciliation leaves the old generation quarantined.

An AbortSignal is advisory cooperation only. The owner supplies one fixed, input-independent string reason after durable unknown is proven; it carries no stack, cause, request data, credential, path, or callback result. Signal observation, callback rejection, a timeout wrapper settling first, or process termination cannot prove that external effects were canceled or undone. Late fulfillment or rejection is observed and drained without another durable transition, retry, release, or reopening; any later evidence-based reclassification belongs to the future bounded reconciliation boundary. The captured execute callback, deadlineRuntime, and abort listeners are trusted same-process code. They are not process-isolated by this owner, and an exception thrown from an abort listener follows platform event-dispatch behavior rather than becoming a guaranteed sanitized owner error. Untrusted callback or listener code requires a separately reviewed worker/process boundary.

Idempotency capability alone is insufficient to release value or reopen service. Reconciliation requires terminal evidence either that the effect occurred and further execution with the same identity can only converge without an additional effect, or that no effect occurred and no still-live callback can create one later. Otherwise quarantine persists. Reconciliation must use a separate future private, privileged boundary rather than the current raw-model reconcileRequest API. A canonical bounded evidence record must be durably bound to the affected request, execution generation, deadline basis, invocation fence, decision, evidence type and digest, and versioned authority policy, without committing to final schema names here. Exact replay must converge, changed evidence or decision must conflict, concurrent attempts must have one durable winner, and no arbitrary callback result, diagnostic text, bearer material, credential, or secret may be persisted. Authentication, trust anchors, and key lifecycle for this authority remain separate design work, so this boundary is not production-ready.

Shutdown ordering remains ingress stop and listener close before session and store close. Callback-control or listener-close uncertainty retains the SQLite ledger and fails closed; it does not prove process-wide cancellation. Focused pure, store, owner, admission, session, and integration tests cover deterministic preparation, fencing, transactional deadline equality and clock movement, both terminal winner orders, injected timer behavior, advisory abort ordering, late settlement drain, restart classification, commit ambiguity, contention, capacity accounting, synthetic funding-to-session construction, replay across reopen, socket disconnect, ordered shutdown, and duplicate convergence. Remaining future integration tests must cover active composition and authenticated transport, authenticated reconciliation evidence, multiple reconciled callbacks, generation clearing and successor activation, worker/process isolation, and distributed ownership. They must continue to prove no double callback, effect, credit, refund, release, or hidden ledger deletion.

Worker or process isolation, kill semantics, distributed coordination, authenticated transport, production settings, final production schema review, and production client-key provisioning, recovery, rotation, revocation, and custody remain separate later milestones with their own threat models. Killing a process cannot prove an external effect stopped. This opt-in deadline runtime does not solve those boundaries or establish production readiness. The active runtime remains unchanged, and the separately tracked different-operator external-evidence work remains unrelated and unchanged by this isolated milestone.

The unreleased createServiceCreditLoopbackServer({ handler }) transport is an explicitly imported local synthetic interoperability boundary. A trusted caller is expected to supply the stable composition owner.handle, although JavaScript cannot prove that provenance. The factory is inert and exposes only frozen zero-argument start and close operations. Passing an argument to either operation returns fixed cause-free SERVICE_CREDIT_LOOPBACK_INVALID_INVOCATION and leaves lifecycle state unchanged. One start binds exact numeric IPv4 127.0.0.1 on an ephemeral port with a backlog of eight, at most eight connections, one request per socket, at most eight headers and 2,048 header bytes, bounded header/request-receive/socket-inactivity timeouts, and Connection: close. Startup has a fixed two-second deadline. A silent listen, bind fault, or invalid bound address returns fixed cause-free SERVICE_CREDIT_LOOPBACK_START_FAILED, aborts and unreferences the owned partial server, destroys only owned sockets, and leaves the transport permanently quarantined and non-restartable. Closing during startup cancels that deadline and immediately begins the same one-shot shutdown instead of waiting for a listen callback or error. It rejects parser faults, excessive headers, expectations, upgrades, CONNECT, and additional pipelined requests before widening handler authority. These are per-process availability bounds, not distributed controls.

Loopback HTTP is plaintext and unauthenticated. This exception is permitted only for disposable synthetic authorization material inside the local test and demo trust boundary. Any real, durable, funded, or otherwise consequential bearer material requires authenticated transport even on loopback whenever same-user processes, privileged local software, host inspection facilities, or other same-host observers are not trusted. The returned origin and path are routing metadata, not authentication, and confer no authority. The generic handler API cannot enforce credential provenance; the caller owns that policy. The module does not log or persist routing or credential data, but it cannot prevent observation outside its process. It is unsuitable for non-loopback transport without a separately authenticated design.

Closing synchronously blocks new work, stops acceptance, closes idle connections, and waits tracked handler invocations only for one fixed short grace. Socket timeout, disconnect, and destruction terminate transport only; they do not cancel synchronous or asynchronous application work, roll back a debit, or establish an execution outcome. A hung synchronous handler can block the event loop, and no callback deadline is added by this layer. The caller must successfully await server.close() before closing the store. If handler work outlives the grace or transport shutdown cannot be proven, close rejects with fixed SERVICE_CREDIT_LOOPBACK_CLOSE_UNCERTAIN, the server remains quarantined and non-restartable, and higher-level store/recovery state must be preserved until explicit adjudication. Late handler settlement remains observed. Abrupt process termination has no cleanup guarantee.

The isolated composition owner captures one exact raw ServiceCreditSqliteStore, one exact descriptor-safe activationOptions object containing only the verifier, authority profile, and clock, and one application callback. It rejects Proxy, accessor-backed, expanded, poison-key, and incompatible configuration shapes, captures callable behavior once, internally constructs and owns the exact mock adapter with that store, and exposes only deeply frozen createFundingResource, activateFunding, and stable-identity handle operations. Every constructed HTTP handler receives a frozen five-method store facade containing only load, reserveRequest, beginExecution, completeExecution, and markOutcomeUnknown; it never receives activation, revocation, release, reconciliation, metadata, close, raw state, or raw store authority. The application callback receives only the existing frozen execution identifier.

After structural store and callback validation, the factory reserves the exact store object synchronously before internal adapter or initial-handler construction. That object can belong to only one owner in the loaded module instance and remains consumed there after construction failure or an owner latch. Duplicate capture fails cause-free with SERVICE_CREDIT_COMPOSITION_DEPENDENCY_OWNED. Safe recovery closes the old store and uses a newly opened exact store object and a new owner, which constructs its own adapter. This prevents only same-module-instance reuse of the same store object; it is not a lock across separately opened handles to the same SQLite file, workers, separately loaded module copies, processes, or hosts.

Outside activation calls are serialized by a private index-based FIFO whose single intrinsic async drain awaits one activation at a time. Queue scheduling and fixed rejections use capabilities from the module-captured native Promise constructor; they do not invoke user-observable Promise continuation methods or consult Promise species. The exact adapter requires its trusted verifier to return a genuine Promise and rejects a non-Promise thenable without invoking then; native assimilation already inherent inside that trusted adapter/Promise boundary remains part of the trust boundary. Ownership, Object.freeze/hasOwn/isFrozen, Set.has, activation-error prototype identity, and asynchronous-context operations used by the authority/latch boundary are captured at module evaluation. This is targeted fail-closed hardening, not a general same-process hostile-code sandbox. Same-owner or cross-owner activateFunding reentry from any activation lineage fails promptly and cause-free with SERVICE_CREDIT_COMPOSITION_REENTRANT_ACTIVATION, without a nested store, adapter, or verifier call. Calls made outside every composition activation context remain eligible for ordinary serialization.

The active handler is sampled when a request starts, so an activation race remains on the prior admission snapshot. A new handler becomes current only after the exact mock adapter reports success, the replacement handler validates a fresh store snapshot, the returned activation canonically matches the activation embedded in that persisted grant, and immutable grant identity and binding fields match. The fresh validated snapshot is authoritative for mutable lifecycle and available/held/consumed counters; concurrent admitted execution cannot cause a false mismatch latch. Exact replay of an active, revoked, or durably expired grant may invoke the trusted verifier again, but existing idempotent adapter/store semantics prevent another activation record, grant, or store revision; an inactive grant is not authorized by reconstruction. Definite pre-commit rejection neither changes admission nor initiates a retry and must not be interpreted as replacement-payment authorization.

An activation SERVICE_CREDIT_ACTIVATION_OUTCOME_UNKNOWN latches the entire owner instance before queued or later funding/activation work can call a dependency. A known committed activation followed by replacement-handler failure latches the distinct fixed SERVICE_CREDIT_COMPOSITION_ACTIVATED_UNAVAILABLE outcome. Neither path resettles, rolls back, or creates replacement-payment authority. Later stable-handle calls bypass stale authorizing handlers and application execution and emit only the existing private, non-cacheable 503 {"error":"service_unavailable"} response. A request whose application callback already began before the latch is not cancelable by the owner; it may finish and its original handler applies the existing durable-completion rules. If the outcome-unknown activation quarantined the store, completion is uncertain and the in-flight response is the fixed private 503. An explicit close/reopen with new dependency objects and a new owner is the only same-process recovery boundary; startup then uses ordinary store and admission validation. The owner adds no background recovery, cancellation, scheduler, listener, CLI, environment activation, network, wallet, RPC, live record, or response persistence.

The activation, capability, client-serialization, HTTP, composition, durable-session, and loopback modules remain standalone. The isolated mock demo imports the offline lane, while the separately invoked basic and durable synthetic loopback demos are the only package entry points that compose the loopback transport with that lane. They remain absent from the active /paid route, buyer, facilitator, wallet, RPC, live-evidence code, and ordinary server and buyer CLIs. The HTTP handler exposes no funding-settlement verification, grant activation, key generation or recovery, administration, privileged reconciliation, refund, or arbitrary-response route. Any future non-loopback exposure must use authenticated transport and must redact the authorization proof, public key, signature, grant and request identifiers, operation identifiers, and store diagnostics from logs.

The listener-free opt-in package entry point is npm run --silent demo:service-credit. It executes one synthetic mock funding settlement followed by three unique signed provider-local service uses and one exact replay in process. The replay cannot debit or invoke the application callback twice. Provider-local uses are not additional Zenon transfers or x402 settlements. The demo constructs only HTTP-shaped in-memory request and response objects; it opens no listener, socket, wallet, RPC, blockchain, or live x402 path. It never retries activation or constructs replacement funding after ambiguity. That deterministic demo remains unchanged and listener-free.

This is not a benchmark. It records no duration, latency, throughput, concurrency, Momentum, finality, scalability, or production-readiness result. The CLI emits only fixed aggregate counters and fixed cause-free failure output. Separate ephemeral mock-payment and capability keys are generated in memory, capability signing-byte buffers are cleared immediately after use, and no key, proof, authorization, transaction, identifier, raw response, path, or database state is returned or printed. Production client-key generation, recovery, and lifecycle remain not implemented.

Each invocation creates one uniquely owned mode-0700 temporary directory and a mode-0600 plaintext SQLite ledger. Normal cleanup closes the store, revalidates the canonical parent, directory and database identities, unlinks only the exact database, removes only the now-empty directory, and verifies absence. Cleanup never recursively deletes the runtime directory. A swapped, tampered, or unexpectedly populated target is quarantined and the run fails. Abrupt termination and cleanup failure can leave a plaintext synthetic ledger; no crash-time cleanup guarantee is claimed. The filesystem boundary requires a POSIX reliable local filesystem; user-ID, mode, link-count, canonical-path, and inode checks fail closed when unavailable or inconsistent.

The separate opt-in npm run --silent demo:service-credit-loopback command is an unreleased synthetic interoperability demonstration. It prepares the store, one mock settlement and seven-unit grant, owner, and three signed authorizations before explicitly starting numeric IPv4 loopback. It then sends request A, one byte-identical replay of A, request B, and request C sequentially through the existing codec, transport, handler, and composition owner. Exactly three application executions consume six units; the replay adds no debit, execution, settlement, or revision, leaving zero held and one available. Provider-local requests are not additional Zenon transfers or x402 settlements.

The demo disables connection reuse, follows no redirects, and performs no retry or replacement request, grant, credit, or settlement after timeout, disconnect, malformed response, or ambiguous completion. The request deadline is a safety bound only and is never reported as timing evidence. Its deeply frozen runner result and fixed CLI line expose no origin, port, path, authorization, proof, public key, signature, identifier, response, ledger data, timestamp, duration, or diagnostic. Plaintext unauthenticated loopback is allowed only for these disposable synthetic credentials. Any real, durable, funded, externally supplied, or otherwise consequential credential requires authenticated transport when same-host observers are not trusted.

Successful cleanup awaits loopback close before store close, validates exact ownership and filesystem identity, unlinks only the allowlisted ledger, and removes only the verified empty directory without recursive deletion. SERVICE_CREDIT_LOOPBACK_CLOSE_UNCERTAIN preserves and quarantines the higher-level store and ledger; it does not claim callback cancellation, accounting rollback, or cleanup. Abrupt termination may also leave a plaintext synthetic ledger. This is not a benchmark and records no duration, latency, throughput, concurrency, percentile, Momentum, finality, scalability, production-readiness, release, or activation result. It performs no wallet, RPC, blockchain, live settlement, or live x402 operation.

The separate npm run --silent benchmark:service-credit-local entry point is an opt-in local synthetic scenario benchmark and is never invoked by the standard test suite or an active runtime. It runs 35 paired rounds for the listener-free and basic loopback demos, not the durable loopback demo, in one warm Node.js 24 process; it discards the first 5 warmups per lane, retains 30 measured samples per lane, alternates which lane runs first, and keeps concurrency at one. A synchronous module-local latch rejects concurrent or reentrant use of one loaded benchmark module instance and is released after success or failure; it provides no cross-worker, cross-process, or global exclusion. A sample covers one whole demo invocation, including normal cleanup, and excludes benchmark-side result validation. The benchmark has no threshold, performs no retry or replacement, does not persist or upload results, and aborts on the first runtime, clock, runner, summary, conversion, serialization, or output failure.

The listener-free and loopback lanes are structurally different scenarios; their difference is not isolated loopback overhead and must not be presented as a universal comparison. Results are host-, filesystem-, and runtime-specific descriptive observations. SQLite runs on the current invocation's POSIX local temporary filesystem with the demos' synchronous durability policy. Median and p95 are the only variable timing measurements. Fixed allowlisted schema metadata also reports the Node major, clock identity, measurement target, warmup and measured counts, concurrency, order, duration unit, rounding method, and percentile method. Output excludes detailed host and process identifiers, environment values, paths, ports, origins, credential identifiers, bearer material, proofs, signatures, keys, and raw samples. Aggregate timing can still characterize host performance, so results require deliberate disclosure handling. The command does not persist or commit results automatically. It does not upload results.

Before clock or runner use, the runtime gate verifies only Node major 24, an empty live execArgv, and empty or absent NODE_OPTIONS, NODE_V8_COVERAGE, NODE_DEBUG, and NODE_DEBUG_NATIVE. Run it in an operator-controlled fresh process. The gate cannot attest the absence of external instrumentation, trusted same-process mutation or module replacement, workers, or operating-system observation.

Interruption, underlying cleanup failure or quarantine, and loopback-close uncertainty inherit the demos' documented possibility of a residual plaintext synthetic ledger. The CLI attempts exactly one synchronous stdout write only after complete success and one fixed stderr write after failure. A failed or short descriptor write may already have emitted an allowlisted partial prefix; stdout and stderr from every nonzero run are invalid and must be discarded. The runner adds no general deadline and uses no Promise.race; a timeout without separately designed cancellation could leave a scenario running after the caller observes failure. This is not a production, per-request latency, TPS, throughput, concurrency-capacity, network or payment latency, L1-capacity, Momentum, finality, live-payment, release, scalability, or production-readiness measurement. Disposable synthetic loopback credentials retain the narrow local exception; all consequential credential use still requires authenticated transport.

The database is not encrypted and does not detect secrets or personal information. Identifier fields, transaction references, payment-intent identifiers, request metadata, and result codes are persisted in plaintext. Store only privacy-reviewed identifiers and one-way capability commitments. Never store a raw bearer capability or preimage, private key, wallet material, credential, personal data, protected response body, or recovery secret.

Durable service-credit domain state schema version 2 embeds one immutable activation record in each grant. Hydration recomputes activation and grant identifiers and rejects corrupt, duplicate, orphaned, or inconsistent activation, offer, settlement, transaction, capability, and grant indexes. Domain state schema v1 remains unsupported. The independently versioned SQLite physical format and user_version remain version 2. The unchanged strict one-row table stores one canonical compound envelope containing physicalVersion, revision, ledgerState, nullable executionState, and checksum. New and migrated databases begin with executionState: null; an explicit one-way durable initialization may replace null with one exact hydrated execution-contract-v1 snapshot. The v2 checksum is explicitly domain separated and commits to every compound field. The physical envelope has a separate fixed overhead bound in addition to the configured ledger-state byte and record bounds, so configured record ceilings are defensive maxima and may not all be reachable.

Existing load() and getMetadata() results intentionally remain the exact public schema-v1 ledger-envelope projection, including its legacy checksum over domain state v2. That compatibility projection is not the physical row. Because both states share one compound revision, an execution-only write advances the projection revision and checksum even when ledger state is unchanged. Null-to-state initialization and every later durable mutation run under BEGIN IMMEDIATE, reread and validate the complete envelope, compare the expected revision, recompute the pure transition, enforce ledger/execution cross-links, and persist both states beneath one new revision and checksum. No caller-supplied transition candidate or result commitment is accepted. Fixed detached receipts classify only APPLIED, UNCHANGED, or STALE; none exposes or names invocation permission.

The new store-local durable snapshot and cross-link helpers use import-captured String and Set references. This scoped defense does not harden pre-existing transitive model dispatch or arbitrary trusted same-process mutation, and it makes no pre-import or module-integrity claim.

The durable surface is explicit and inactive: snapshot, initialization, atomic request preparation, fence persistence, normalized-result completion, unknown-outcome marking, and restart recovery. Null-to-state initialization is a clean cutover and rejects every legacy RESERVED, EXECUTING, or OUTCOME_UNKNOWN request without mutation. Preparation creates exactly one new reservation, advances it to ledger EXECUTING, and creates the matching pure PREPARED execution in one transaction; it never adopts a legacy reservation. PREPARED and MAY_HAVE_STARTED correspond to ledger EXECUTING; NOT_INVOKED to FAILED_RELEASED; SUCCEEDED to ledger SUCCEEDED plus a recomputed cached-result commitment; and execution OUTCOME_UNKNOWN to ledger OUTCOME_UNKNOWN. Durable state rejects any unlinked RESERVED request. Every execution must have one matching ledger request, every EXECUTING or OUTCOME_UNKNOWN ledger request in durable mode must have one execution, current policy permits at most one nonterminal execution, and configured capacity cannot exceed the ledger record ceiling.

Stale preparation and exact replay or conflict are resolved before new-duration checks. For genuinely new work, a duration above the persisted policy maximum fails before the trusted clock; unsafe deadline addition fails after exactly one clock sample but before pricing. Fence and restart operations capture the configured trusted wall clock exactly once after the revision check while holding the writer transaction. A proven unfenced recovery privately drives only the existing in-memory model through its conservative release sequence and persists only final FAILED_RELEASED; it creates no public reconciliation authority and writes no intermediate durable unknown. A fenced recovery becomes unknown and seals the generation. Completion derives a domain-separated execution commitment from the exact normalized cached result rather than accepting one from its caller. Stale revisions and exact replays do not retry or mutate. Commit-attempt or acknowledgement ambiguity returns no disposition, closes and quarantines the handle, and requires explicit reopen.

After initialization, the legacy reserveRequest, beginExecution, releaseBeforeExecution, completeExecution, markOutcomeUnknown, and reconcileRequest methods fail closed before clock, pricing, accounting, revision, or state effects. Reads remain available; offer and grant administration writes preserve and revalidate exact execution state beneath the compound commitment. A sealed generation blocks new preparation and fencing and supplies no public reconciliation or successor-generation escape. The current HTTP handler, composition owner, pre-existing demos, benchmark, ordinary package commands, and active runtime neither initialize nor call this durable surface, so their legacy behavior remains unchanged; only the separately named durable loopback demo explicitly opts into it.

Ordinary openExisting accepts only physical v2 and never migrates. Physical v1 can be upgraded only through the explicit migration entry point, which holds BEGIN IMMEDIATE while validating the exact file, SQLite schema, canonical legacy envelope, checksum, domain model, and configured capacity. Eligibility requires domain state v2 and no EXECUTING or OUTCOME_UNKNOWN request. Operators must stop and quiesce every legacy process and handle that can use the physical-v1 store before migration. Success preserves the revision and public projection, writes executionState: null, atomically changes the row and user_version, and returns a usable v2 handle only after known commit success. A pre-commit failure preserves the physical-v1 envelope and version. Commit-attempt or acknowledgement ambiguity closes and quarantines the attempted handle; recovery is an explicit reopen of the same file, never an automatic retry. Concurrent migration attempts serialize, and only one can observe and rewrite v1. That serialization prevents partial or duplicate migration but does not coordinate or preserve availability for a legacy process racing the cutover; a pre-existing v1 handle fails closed after the transition.

Physical v2 is rejected by the migrator, and incompatible, corrupt, noncanonical, capacity-violating, or unresolved v1 state is rejected without upgrade. There is no downgrade, deletion, repair, compaction, retention, or tombstone path. Old physical-v1 code cannot open a successfully migrated v2 file. Rollback means stopping users of the store and retaining the v2 database for code that explicitly supports it, not converting it back to v1. Once durable mode has replaced null execution state, reverting to the earlier null-only physical-v2 implementation also fails closed and is not a downgrade path. The checksum is accidental-corruption detection, not authentication against hostile same-UID code, the host kernel, or storage replacement outside the existing identity checks. This milestone can be rolled back without changing an active runtime because no active path activates durable mode, but every retained database with non-null execution state must remain with a compatible reader.

The operator-trusted live session passes sequential readiness checks, exact pinned-observation and chain-profile comparison, token metadata validation, frontier validation and complete bounded unconfirmed-block inspection. Unconfirmed pagination reads every page implied by Count up to 200 entries and fails closed on malformed counts, incomplete pages, excessive counts and RPC failures. It rechecks page zero to detect some concurrent changes; the node view is not an atomic snapshot or authenticated chain proof.

settle() applies a payer-balance filter only to a node-owned first attempt when neither durable recovery state nor the exact transaction is present. It runs after chain and asset validation and the first exact-hash lookup, but before frontier inspection, subscription, any settlement-record write, publication, or delivery. Every successfully returned account observation is followed by a second exact-hash lookup before the balance is interpreted. An exact transaction or concurrent durable record discards the balance conclusion and retains the existing reconciliation behavior. Direct verify(), durable retries, tombstones, and already-observed transactions bypass the filter.

The account information is one node's process-local, TOCTOU-prone observation. It is not a reservation, authenticated chain state, proof of ability to pay, or protection against another process, independent publication, a stale view, or a dishonest node. Only a fully validated, height-aligned requested-ZTS balance below the signed amount is a definite pre-publication rejection. Lookup failure or malformed, mismatched, accessor-backed, proxied, height-inconsistent, token-inconsistent, or non-bigint balance data remains same-payment recovery. The check does not establish Plasma or PoW sufficiency and this offline slice claims no live payment or real-node evidence.

These checks remain observations of one node and cannot eliminate external frontier races. Process-local per-payer ordering does not coordinate client-side preparation, other processes, other facilitators or independent publication.

The Issue #45 evidence contract is a pure offline format and verifier. It does not contact a node, load a wallet, read a journal, start the server or buyer, capture an exchange, sign, publish, or deliver. Its file-only CLI accepts explicit regular files, reads each input once under a fixed limit, refuses symlink inputs and explicitly symlinked output parents, and creates a new restrictive output without overwriting an existing entry. Every success and failure signal is fixed and cause-free.

Version 1 permits only the following deliberately public evidence after separate Gate-B publication authority and human review for a disposable, minimally funded, single-use testnet wallet:

• the exact one-off challenge and sole selected offer, including full ResourceInfo optional-member presence and ordered duplicate tags;
• the complete public signed account block and captured Momentum confirmation;
• decoded initial and paid HTTP observations, the fixed protected body bytes, and the allowlisted response metadata;
• one asserted final journal record and its source schema, revision and counts;
• allowlisted timing events, role-local monotonic durations and UTC correlation assertions;
• repository/profile provenance assertions and exact false nonclaims.

The Gate-B package must publish the complete exact six-field default protected response body, not only a digest, and the absolute UTC timestamps used for correlation, not relative-only timing. These disclosures are intentional and linkable even though the wallet is single-use.

Raw encoded payment headers, same-payment recovery material, wallet material, credentials, private or RPC endpoint details, and arbitrary protected bodies are structurally excluded. The public resource location and optional public icon location are deliberately included; both must be bounded absolute public HTTP(S) locations without credentials, query or fragment delimiters, and the protected resource itself requires HTTPS. The complete challenge and signed block can still reconstruct linkable payment material, so excluding the raw payment is data minimization rather than replay prevention. Automated validation cannot prove that secrets are absent: a human Gate-A review of every public string remains mandatory before publication.

The parser rejects duplicate decoded keys, unknown or missing fields, accessors, proxies, custom prototypes, cycles, sparse arrays, symbols, unsafe numbers, negative zero, unpaired surrogates and all configured size/depth/count excesses. Canonical JSON sorts decoded object keys without Unicode normalization, preserves array order and duplicates, uses ordinary JSON primitive escaping and safe-integer number spelling, and excludes the single serialization newline from digests. SHA-256 is fixed in code. Each content section and the final bundle use distinct version-1 domain prefixes. These unkeyed digests provide only internal consistency and alteration detection, not authenticity or authorship.

The exact false version-1 nonclaim keys are authoritativeCurrentNetworkRelease, signedTrustArtifact, authenticatedRpcEndpoint, canonicalRemoteChainIdentity, verifiedFrontierLineage, authenticatedChainIdentity, canonicalNetworkIdentity, irreversibleFinality, facilitatorAuthorship, productionReadiness, phase2C, hardwareWallet, crossProcessExactlyOnce, replayPreventionProvided, resourceAuthorizationProvided, bundleOriginAuthenticated, bundleIntegrityAuthenticated, chainObservationIndependentlyAttested, httpExchangeIndependentlyAttested, facilitatorPublicationProven, buyerReceiptCryptographicallyProven, recipientReceiveObserved, and secretAbsenceProven. Every key must be present and false. In particular, recipientReceiveObserved means that receipt by the recipient was not observed; it is not a balance assertion. These keys also state exactly that there is no authoritative current release, signed trust artifact, authenticated RPC endpoint, canonical remote-chain identity, verified frontier lineage, release, or activation claim.

A valid bundle therefore establishes none of those claims. Timing is descriptive: monotonic values are compared only within one role-scoped clock domain, while UTC fields provide operator-supplied cross-domain ordering assertions rather than remote-clock proof. Plasma/PoW classification is derived from signed fields but does not prove PoW validity or Plasma sufficiency.

The Issue #45 operational runner is default-off preparation and is tested only with local doubles. This PR B implementation and its test validation performed no live RPC, wallet, faucet, signing, publication, payment, capture, or evidence release; run mode remains separately authorized. The effectful runtime's three logical roles use two processes: the coordinator retains the buyer's module-local WeakMap recovery owner, and a separate facilitator child owns the facilitator SDK runtime, loopback server, schema-v1 journal, and fixed six-field delivery adapter. The exceptional CLI adds a non-effectful fixed-output supervisor parent. Child requests and replies have exact bounded schemas and monotonic request identifiers; protocol faults, output excess, timeouts, or coordinator disconnect terminate the child. A replacement is forbidden until operating-system exit is confirmed.

The public configuration contains only allowlisted execution assertions. Buyer RPC, buyer wallet, and facilitator RPC inputs remain separate owner-only regular files in one private workspace. Component-wise checks reject symlinks, hard links, aliases, escapes, unsafe modes, ownership mismatch, oversized data, generation changes, and output collisions. The coordinator never reads facilitator credentials, the facilitator never receives buyer credentials, and neither secrets nor recovery ownership are transferred through arguments, environment, operator-visible output, artifacts, or IPC. Internal IPC does carry bounded allowlisted protocol data; fixed operator-visible output and errors expose none of its paths or identifiers. Lifecycle observations are payload-free and free-form-metadata-free. Public HTTPS readiness resolves only public addresses under a deadline and pins that resolution to the actual health, challenge, paid, and reconciliation requests; redirects and URL drift fail closed. DNS, health, unsigned challenge, and unrelated requests retain the configured base deadline. Only an exact signed payment and same-payment reconciliation use the validated inclusion window plus twice the validated RPC timeout. Selection requires prior exact challenge equality and a bounded decoded PaymentPayload that passes local preflight against the immutable expected resource, requirement, intent and transaction identity. The first successful cryptographic preflight privately binds the exact encoded header bytes; concurrent first use poisons the capability, and reconciliation permits only byte-identical reuse without a second asynchronous preflight. Arithmetic is overflow-safe with no fallback and a hard 420-second schema-derived maximum; current Gate-B values produce 120 seconds. The operator must provision the external HTTPS ingress.

The current-testnet Gate-B path is a distinct closed WSS one-shot family. It accepts only the canonical wss://rpc.testnet.zenon.info/ endpoint and retains the existing operator-trusted Chain-73404 profile, quick-tunnel HTTPS resource ingress, one-payment controller, source attestation, private capture, and independent-publication gate. It uses coordinator/bootstrap, review, and Phase-3 schema version 2; endpoint-source version 2; RPC secret version 3; execution mode current-testnet-wss-once-v1; runner version 3; authorization version 3; independent-review result version 2; and configuration-digest domain zenon-x402-current-testnet-wss-once-config-v1. These generations and the endpoint, quick-tunnel binding, revision, run, profile, payment intent, and acknowledgements are checked as one family. Old, mixed, partial, replayed, and cross-family artifacts are rejected without fallback.

The old numeric-public-WS one-shot family and historical generic-WSS runner remain unchanged. The new WSS family removes only the plaintext-transport acknowledgement; it retains the testnet and operator-trust acknowledgements, WSS one-payment acknowledgement, publication hold, quick-tunnel telemetry acknowledgement, and final exactly-one-payment/no-recovery acknowledgement. Both current-testnet one-shot families share the same durable consumed marker. A run therefore requires a fresh workspace, and a consumed, old-family, mixed, or quarantined workspace cannot be reused, resumed, migrated, or upgraded in place.

TLS provides transport encryption and authenticates the RPC server name under the local trust store. It does not authenticate canonical chain identity, operator claims, frontier lineage, finality, recipient receipt or spendability, or node-binary provenance. Public genesis, configuration, and node-plan files are mutable operator-published snapshots rather than signed immutable anchors. Pending WSS capture uses publication-ineligible candidate-v2 metadata: confidentiality in transit and TLS server-name authentication are true, while authenticated chain identity remains false, operator trust and independent verification remain required, and the endpoint remains undisclosed. Quick-tunnel startup now permits only bounded expected no-listener or exact not-ready transients while retaining one observed tunnel identity, then requires three stable ready observations. Later checks tolerate only bounded same-identity absence or canonical 503/zero readiness and emit CHECKED only after fresh ready state; malformed, drifting, regressing, late, or timed-out readiness remains fail-closed. This source and its offline tests alone are not a live payment, settlement, resource-delivery, release, or activation claim. The retained evidence-version-1 bundle remains publication-ineligible. Issue #45's narrower Path-B acceptance boundary may instead be met by a distinctly labeled operator-trusted record after human disclosure review and merge.

One invocation using a freshly generated, dedicated, disposable testnet wallet recorded one x402 v2 exact upfront payment for one atomic unit of ZNN under the descriptive zenon:testnet label and operator-trusted Chain 73404 profile. Its signed block selected PoW with fusedPlasma 0 and difficulty 34,764,000. The retained timing assertions report 24,375 ms from 402 to 200, including 6,887 ms in prepareBlock(), 8,566 ms holding the buyer SDK owner after a 0 ms wait, a publish-RPC acknowledgement interval of 238 ms, an 11,973 ms inclusion wait, 29 ms delivery, and 15,611 ms holding the facilitator SDK owner after a 0 ms wait.

The private journal is schema 1, revision 5, with one active record in MOMENTUM_INCLUDED / DELIVERED; the exact six-field response body remains in the private capture and is projected only into the separate operator-trusted record rather than reproduced here. The five retained fragments came from the uninterrupted, non-recovery inner runner path and were assembled and verified in memory. A separately implemented post-run read-only comparison against the same operator-trusted route observed one account-height advance, the exact one-atomic-unit debit, exact signed-block identity and payment-intent/resource bindings, and a later Momentum. This was not protocol reconciliation and granted no retry, resubmission, or replacement-payment authority. It is useful corroboration of the retained local record, but it is not the required independent operator-route verification for evidence-version-1 publication.

The non-recovery inner runner reached private PENDING_INDEPENDENT_VERIFICATION before the outer operator front end reported GATE_B_CONTROLLER_FAILED_WORKSPACE_QUARANTINED. The failure is confined to the post-delivery closure-proof boundary: later read-only inspection found no matching process or listener residue, but the fixed output cannot identify which clean-closure predicate failed. That absence check was a point-in-time out-of-band observation, is not part of evidence version 1, and does not retroactively prove clean closure. Payment and delivery observations are retained; clean shutdown is not claimed. The consumed workspace remains quarantined and cannot be reused, resumed, retried, or upgraded in place.

No protocol finality, authenticated chain identity, recipient receive or spendability, facilitator authorship, independently attested HTTP exchange, clean shutdown, release, activation, or production readiness follows from this run. No independent operator-route verification or public evidence-version-1 bundle exists yet. The unchanged evidence-version-1 workflow requires a human-approved different-operator-route observation and an accepted strict independent-review assertion record before the retained fragments are supplied to the network-free assembler and verifier. Evidence-version-1 bundle publication still requires that observation, the accepted assertion record, successful retained-fragment assembly and offline verification, separate publication authorization, and an explicit cleanup-quarantine addendum kept outside the version-1 JSON bundle.

The separate docs/evidence/gate-b-operator-trusted-observation-2026-09-04.json record is explicitly not evidence version 1. It contains five allowlisted projections made directly from the retained manifest, chain, HTTP, journal, and timing fragments. Its operator-trusted, same-route, and not independently verified labels are publication classification, not fragment-derived measurements. The JSON omits the separate post-run comparison, outer-controller closure and quarantine, transport-authentication, and explorer-route assertions because the five retained fragments do not mechanically supply them. Tests recompute the payment-intent/block-data binding, cross-fragment transaction and chain relationships, decoded HTTP result, journal relationships, and every duration from retained timing events. The public transaction linkage, exact resource and payment requirement, complete six-field response body, and absolute times are deliberate low-but-nonzero linkability disclosures. The initial HTTP projection contains only status and observation time and therefore does not prove the exact 402 body or header bytes. The record does not contain the raw payment header, recovery material, RPC endpoint, wallet material, credentials, local paths, or diagnostics. The original run-time publication hold continues to cover the five private fragments and evidence-version-1 bundle; this narrower derived record requires a later explicit post-run disclosure decision and human review rather than a retroactive reinterpretation of run authority. After human disclosure review and merge, it can satisfy Issue #45's bounded operator-trusted Path-B acceptance criteria while the independent evidence-version-1 gate remains open. Issue #45 remains open until then. Clean controller closure is not an Issue #45 acceptance criterion. A fresh successful run is required only if the project separately wants to demonstrate clean end-to-end controller closure.

The dedicated offline self-consistency verifier does not enlarge that claim. Its success token means only that one bounded supplied record has exact allowlisted syntax and mutually consistent retained values. A coordinated forgery can pass. The verifier checks canonical resource and selected-offer intent digests, Base64 intent data, retained partial-block and journal copies, amount/asset/payee/payer/network/chain-profile links, equality of the supplied transaction label and confirmation tuple, positive confirmation and journal counts, confirmation height after the acknowledged height, the shared final HTTP/cache status, content type and exact six-field body, final journal state, all 21 declared events, role-local monotonic ordering, declared UTC ordering, all twelve durations, and the HTTP/confirmation/journal time anchors. It parses nested bodyText with the same duplicate-aware, depth/node/member/string-bounded parser. Key order and whitespace are not provenance, array order remains significant, and no Unicode normalization occurs.

The verifier deliberately cannot prove committed-byte provenance, secret absence, a full block or its hash, signature or payer-key binding, PoW, Plasma, transaction existence, authenticated or canonical chain identity, frontier lineage, finality, recipient receipt or spendability, facilitator authorship or publication, complete HTTP-response equality, buyer receipt, clock truth, cross-domain attestation, clean shutdown, evidence version 1, release, activation, or production readiness. Omitted block, signature, authorization-key, Momentum-hash, work, and lineage fields are not reconstructed or inferred. The record's transaction linkage is intentionally public, while fixed CLI output never repeats it, any other record data, the input path, or failure details. The CLI opens only one explicitly named regular single-link file through a symlink-free component chain, requires no-follow support, uses nonblocking and close-on-exec flags when available, pins device/inode/mode/link-count/size/modification/change metadata across path, open, read, and post-read checks, and performs no write or network action. Issue #81 remains deferred and is neither blocked nor closed by this verifier.

The optional macOS local buyer-wallet helper remains a separate operator provisioning action, not runner authority. Its fixed-output parent imports no SDK or secret implementation and accepts only a direct child of the current user's canonical macOS Application Support root: either the preserved zenon-x402-gate-b-wallet legacy directory or one generated sibling whose name appends exactly 32 lowercase hexadecimal characters. Its CLI grammar remains exactly create --workspace <absolute-private-workspace> with no environment, default, alias or normalization fallback. It retains the returned child before validating the process handoff, invokes the absolute fixed module without a shell or PATH lookup, uses empty arguments and a requested empty environment, makes the exact workspace the child's current directory, ignores standard streams, and limits control IPC to fixed request-correlated enums. The child independently validates the supplied path against its actual current directory and the canonical Application Support root before filesystem or entropy effects. The bounded bootstrap pipe and cwd carry only the already-selected workspace path, never wallet material. Malformed or ambiguous children are closed and reaped where the returned interface permits; success requires the one expected terminal enum plus clean exit and close. The first terminal settlement synchronously disables protocol actions and detaches only supervisor-owned protocol listeners before reaping, so late control messages cannot start generation. Failure destroys the bootstrap before one bounded TERM/KILL reap. If close remains absent, the supervisor disconnects and unreferences every supported IPC and child handle, clears its timers and listeners, and returns only generic quarantine failure. Abandonment is never success and proves neither termination of hostile same-UID or root code nor termination of a kernel-unreapable process. Synchronous fixed-descriptor CLI output contains closed-pipe failures without surfacing raw errors or stacks.

The child imports the existing shared private-workspace capability and does not reimplement filesystem security. Before any reservation, SDK load or entropy, the dedicated workspace must be canonical, empty, current-user owned, mode 0700, ACL-free, non-symlinked, outside all Git-bearing ancestry, and identical through retained pathname and cwd descriptors. The capability exclusively reserves exactly buyer-wallet.json and buyer-address.json with no-follow creation, validates distinct regular single-link mode-0600 zero-length inodes, and syncs both retained directory descriptors before returning control. Only then may the child load the pinned SDK and request 32 bytes from its injected cryptographically secure production entropy source; it uses the SDK's Zenon-compatible entropy constructor and derives account index zero only. Writes loop safely through retained handles, each artifact is synced and revalidated, both directory descriptors receive a final sync, and path, cwd, inode, generation, mode, link and ACL checks repeat before success. These barriers do not provide all-or-nothing file-content atomicity.

Only a conclusively pre-effect first-open failure may be retried: both fixed leaves are rechecked absent through retained pathname and current-directory descriptors, all workspace identity, generation, ownership, mode and ACL checks remain valid, and neither SDK loading nor entropy was invoked. This classification is internal and exposes only the same generic failure result. The first reserved inode, an ambiguous or failed absence proof, SDK loading or possible entropy, and every later failure permanently consume and quarantine the whole workspace. The capability closes all retained handles but never unlinks, truncates, retries or overwrites any artifact; retained restrictive residue may be partial or complete, may contain a valid mnemonic, and forces subsequent attempts to fail before SDK loading or entropy. No marker or third artifact records an ambiguous failure that leaves no residue, so the operator must quarantine the workspace and must not retry after that generic failure. buyer-address.json is cryptographically public but operationally private and linkable, and therefore remains a separate mode-0600 artifact until deliberate disclosure or funding. Fixed pathname ACL inspection is identity-bracketed but is not atomic; hostile same-UID code is inside this namespace trust boundary. No protection is claimed against hostile same-UID code, root, or external backup and synchronization services. Clearing reachable entropy buffers, SDK fields and key objects is best effort, not reliable JavaScript heap or process-memory zeroization. The child is not an OS network sandbox, but this chain-neutral generation path invokes no RPC, network selection, funding, signing, payment, publication or Git action.

The distinct macOS testnet faucet-receive helper is a one-shot source-only operational primitive, not Gate-B payment authority. Empty arguments preserve its legacy workspace lane; the only generated-workspace form is exactly --workspace <absolute-generated-workspace>, and an explicit legacy path is rejected. Generated selection has no environment, default, alias or normalization fallback. The parent validates the generated path as a direct canonical Application Support child with the wallet helper's exact generation suffix before fork, passes selection only as the child's current directory, and keeps bootstrap and control IPC path-free. The child independently reparses that current directory and derives the matching generation-isolated state sibling before protected wallet access. The fixed parent reads one bounded canonical frame only from descriptor 3, validates the exact two-send acknowledgement and one credential-free canonical numeric public ws:// endpoint, and starts one fixed isolated child with empty arguments/environment and ignored standard streams. The acknowledgement accepts an operator source-class assertion; it does not identify or authenticate a faucet or sender. Control IPC is primitive-only: one exact execution mode, indexed publication boundaries, and one mode-matched terminal. The parent latches publication risk on any exact indexed publication boundary before validating mode or order. It retains the raw child before structural validation, applies bounded cleanup through only proven callable handles, and disconnects, closes and unreferences supported resources. Success requires the terminal protocol, child exit and resource-reaping close. After publication risk is latched, timeout, rejection, malformed terminal data, exit/close ambiguity or an unreaped child is always OUTCOME_UNKNOWN and never generic failure. Endpoint, wallet data, block identifiers and diagnostics never enter arguments, environment, control IPC or operator output.

The child requires the current operator-trusted testnet profile and wallet-free readiness before opening the protected wallet capability. It checks existing recovery state first without opening that wallet capability. A fresh attempt then requires two stable complete pending snapshots containing exactly one positive native ZNN send and one positive native QSR send to the stored account-zero address, plus zero conflicting unconfirmed blocks. These checks are one node's unauthenticated view. The exact acknowledgement asserts that the operator recognizes those two sends; neither their sender nor faucet provenance is authenticated. After durable one-shot arming, the child derives only account zero and uses the pinned SDK's built-in PoW to prepare unfused receive blocks. It durably records each exact signed receive before one publication, requires exact block lookup and Momentum inclusion before proceeding, and never constructs an outgoing block or invokes fusion.

The sibling state workspace must remain canonical, current-user-owned, mode 0700, ACL-free and stable through a retained no-follow directory descriptor. Every marker, temporary, recovery and second-receive attempt record is a current-user mode-0600 regular single-link file; retained file descriptors and pathname generations bracket reads, exclusive creation, rename, directory fsync and post-write validation. ACL inspection is similarly identity-bracketed. Hostile same-UID code remains inside this namespace trust boundary, and no protection is claimed against it, root, or external backup and synchronization services. For RPC-observed receive blocks only, the released SDK's canonical ASCII-base64 byte representation of publicKey and signature is normalized to the same exact fixed-length binary meaning; both fields must share one representation and canonical decoding and re-encoding must agree. Every other SDK-decoded semantic field must equal its persisted value, but the validator does not claim to reject every noncanonical raw RPC JSON spelling before SDK deserialization. Prepared and signed local blocks retain their stricter binary-only validation.

A one-record recovery is restricted to the disposable fresh account: receive zero must be height one with the protocol empty predecessor and the current account frontier must be exactly that persisted, semantically equal, Momentum-included receive. It remains wallet-free while obtaining two stable single-pending snapshots and two zero-unconfirmed observations. It strictly looks up both sends, recomputes both content hashes, requires confirmed positive native sends to the persisted receiver, requires exactly one ZNN and one QSR source, and requires the remaining source's inclusion no later than receive zero's acknowledged Momentum. The second original source hash was not persisted before interruption, so this stable selection remains an explicit operator-trusted recovery identity boundary rather than authenticated sender provenance.

Every transition from included index zero toward index-one preparation must first win the same mode-0600, single-link, no-follow, canonical and durably synced exclusive second-receive attempt record. It is never removed and binds receive zero to the selected second source's canonical core metadata and declared hash; recovery separately recomputes that hash from the looked-up source content. Fresh execution commits its stable original source-one snapshot; recovery first completes its stronger historical checks, competes for the same record, and re-fetches the committed source before wallet access. A pre-existing record with no durably persisted index one makes every later or concurrent run OUTCOME_UNKNOWN without reopening or re-signing. The partial index-one block must be the direct height-and-predecessor successor of persisted receive zero. Once index one is durably persisted, recovery is observation-only. Index zero is never re-signed, republished or replaced. Any unresolved or changed frontier, source, confirmation, pending set, commitment, publication or lifecycle fact remains OUTCOME_UNKNOWN with no automatic retry. Fixed COMPLETE after partial recovery means the two-receive operation completed with only index one published by that invocation. Two-record zero-exit recovery remains read-only and requires semantically equal, Momentum-included lookup of both receives. Neither success authenticates chain identity or funding provenance, authorizes the later x402 payment, establishes evidence eligibility, publishes evidence, or closes Issue #45.

The one-shot input controller is default-off and owns one immutable tunnel bootstrap and one frozen fieldless lease. Its fixed order is endpoint provisioning, tunnel launch, one fresh readiness check, one PREPARE, and a mandatory human-review pause. Review supplies one independently obtained family-specific configuration digest. Schema v1 additionally requires the plaintext-transport, payment, and publication acknowledgements; schema v2 requires the WSS-payment and publication acknowledgements and rejects the plaintext exception. Review cannot replace the run name captured from the initial schema. Only then may the same lease receive one second fresh readiness check, one AUTHORIZE, and the filesystem-only family preflight. Preflight performs no readiness check, network operation or wallet-content read. The distinct Phase-3 transition irreversibly consumes one exact run acknowledgement, performs one third fresh readiness check, and delegates once to the matching isolated one-shot runner. Every injected asynchronous dependency must return an unmodified native Promise; hostile thenables are rejected before assimilation. Cancellation, duplication, malformed authority or ambiguity prevents later actions, closes the retained tunnel, and yields quarantine with no replacement run.

The source-only operator front-end is the only defined human entrypoint for that controller. Its fixed direct command uses /usr/bin/env -i, the absolute current runtime and the audited front-end module, with no arguments, an empty environment, no shell and no PATH lookup. It synchronously rejects an ineligible non-TTY before spawning. The outer then exclusively binds and verifies the fixed origin listener before directly starting and capturing a detached watchdog, detached origin guard and detached reaper, in that order. It sends only the captured watchdog PID on separate fixed private target pipes to the guard and reaper and privately transfers the same retained listener to both. No process or group identity is accepted from IPC or placed in arguments, environment, files, standard streams or status. Each payload-free holder READY covers only the child-observable exact target frame and EOF, adopted listener, denial handler and liveness handling. The outer separately joins both holder READY frames with both target-write callbacks and both handle-transfer callbacks before it sends the watchdog's dedicated private fieldless START and returns the setup capability. Before START the watchdog is inert and does not read bootstrap bytes, start descendants or emit an operational milestone.

Before any operational descendant can start, the outer owns exactly 127.0.0.1:41000 as an exclusive IPv4 listener and verifies the actual bound address. It duplicates that same kernel listening socket, not three independent binds, to the reaper and origin guard while retaining its own copy. All three holders actively accept and return only the same fixed raw-TCP HTTP 503 denial with a zero-length body, Connection: close, Cache-Control: no-store, and no Date, Server, request-derived bytes, logging or application data. Every accepted connection is ended with the fixed denial; idle, failed or over-limit sockets are destroyed. This is an intentional pre-RUN loopback network effect; it does not read request bodies or protected records and has no wallet, payment or RUN authority.

Only after setup may the trusted controlling TTY accept exactly three paste-only canonical JSON lines with raw-mode echo suppression during entry. The first two bootstrap and review phases and their deadlines remain unchanged. Only after preflight may the third 120-second phase open; its frame contains only the fixed acknowledgement authorizing exactly one live testnet RUN now. The attempt latch is set before Phase-3 parsing. One-shot private OPEN acknowledgements precede each canonical write. Editing controls and early, surplus, duplicate, stale, malformed or phase-confused input or barriers fail closed. The front-end never echoes, logs or persists payload data. All three exact canonical schemas are documented in the README without embedding machine-local values.

The retained coordinator starts one fixed non-detached reviewer only after frame two. The reviewer has 30 seconds, opens exactly seven protected leaves and never the wallet, proves authorization absent, reuses the private-workspace file-identity/mode/link/ACL boundary, checks every cross-file semantic, independently validates and domain-separates the configuration digest, and brackets final record verification with clean-source-revision attestation. Its only data-bearing output is one bounded private result frame. The merged controller recomputes and compares that digest before authorization. This is independent implementation validation, not proof of a second human review or of human comprehension; the three acknowledgements remain operator assertions.

The same coordinator retains the controller capability and lease through one prepare, review, authorization, filesystem-only preflight and Phase-3 decision. The detached watchdog is the group leader for the coordinator, non-detached reviewer, controller-only PROVISION/PREPARE/AUTHORIZE children, tunnel supervisor and tunnel runtime. The watchdog, guard and reaper are three detached siblings. Each has a distinct exclusive outer-liveness descriptor not inherited by either other sibling or any operational descendant. The guard and reaper additionally hold opposite ends of one private peer-liveness channel. Inner inherited-mode cleanup never signals or probes a negative process group; ordinary public-input and quick-tunnel APIs remain detached and preserve their existing whole-group policies. Same-process module imports are trusted plumbing, not an unforgeable JavaScript authorization boundary. GATE_B_CONTROLLER_PREFLIGHT_VALID_RUN_NOT_AUTHORIZED is explicitly not run authority; only the distinct exact third frame can attempt RUN. Controller stop and wait each occur exactly once.

The outer continuously monitors all three captured child handles. Once reaper READY is armed, the outer never concurrently signals the watchdog group. It requests reaper cleanup and accepts payload-free ABSENT only after an independent probe agrees that the captured watchdog group is gone. On reaper loss, timeout, false ABSENT or contradiction, the outer first terminates, waits for and proves absence of the captured reaper group, then probes and if necessary takes over TERM, 500-millisecond grace, KILL and ESRCH proof for the captured watchdog group while the outer and guard retain listener custody. Guard loss poisons the attempt while the outer and reaper retain their copies. If the outer and reaper are both gone, the guard is the sole cleanup authority and proves watchdog absence before releasing its copy; ambiguity leaves protective residue. Normal clean closure proves the watchdog/tunnel group absent before any listener release, joins guard and reaper exit, closes the outer copy, and repeatedly proves the watchdog, reaper and guard groups absent. Leader exit alone is insufficient and no claim covers arbitrary descendants.

After the outer has joined both holder READY frames with both target-write and handle-transfer callbacks, any surviving holder preserves fixed-denial port custody across any one- or two-holder loss before Phase 3. Outer hard death with a live but hung reaper may leave that reaper, the guard and the watchdog in protective quarantine indefinitely; the last listener is not released on ambiguous watchdog absence. Failure, timeout, malformed or duplicate protocol, post-review mutation, closure uncertainty or residue yields fixed quarantine only and forbids retry, replacement, unlink, overwrite, restart and resume.

Phase 3 is a bounded testnet-only close/rebind exception for exactly one disposable, minimally funded run; it is not the production listener-handoff design. After one fresh retained-lease check, exact request-correlated control IPC makes the guard and reaper close and acknowledge their listener copies, then the outer closes its copy once. There is no retry or reversal. Only after the existing facilitator exclusively binds the exact loopback port, public-route health succeeds, and the exact expected 402 is observed may lazy wallet opening, signing and the one payment proceed. A competing bind, a holder-release timeout, or a facilitator bind timeout quarantines before wallet access. If delivery of ORIGIN_RELEASED is ambiguous, the one-use latch remains burned and the sender quarantines with no retry or replacement, but the watchdog may already have consumed the message and downstream effects, including the exact payment, may already have occurred. Subsequent reconciliation is limited to that exact attempt and payment. The trusted host kernel, root and same-UID processes remain inside the security boundary; this deliberate availability gap removes guard fallback during the run, so crash recovery cannot preserve the earlier fixed-denial listener. A production design still must inherit or broker the same kernel listener with no close/rebind gap, coordinate and retire every active fixed-denial acceptor, and retain the guard as the 503 fallback on server loss. This exception is default-off, non-production, never publishes, and does not close Issue #45. Module imports and offline validation remain inert and invoke no live tunnel, external endpoint, RPC, wallet, funding, signing, payment, publication or RUN effect.

Terminal echo suppression does not protect against the terminal emulator, screen recording, host compromise, root or same-UID observation. Owned byte buffers are cleared and references dropped best-effort; immutable JavaScript strings, including the operator-selected executable pin, cannot be zeroized. The synthetic front-end fixture is test-only and is absent from all production imports.

Terminal recovery is limited to the captured Node isRaw Boolean on normal completion, handled failure, SIGINT, SIGTERM, process disconnect, and raw-mode control-byte rejection or cancellation; uncertainty quarantines. It provides no guarantee for SIGKILL or SIGSTOP and claims no SIGHUP, SIGQUIT, or SIGTSTP handler outside raw-input control-byte rejection. The PTY test proves no echo and captured Boolean raw-state recovery, not complete termios equivalence.

The public-input CLI is the leader of one detached process group, while its supervisor worker is explicitly non-detached. Only a trap-safely captured own-data PGID is ever signalled, through negative-PGID TERM/KILL; it is retained before the remaining spawn-return shape is inspected, so a malformed later field still triggers reconciliation of only that exact group. Clean leader output is insufficient until exact group absence is proved, and an unusable identity is never guessed. Supervisor terminal settlement disables protocol actions before resolving or rejecting, detaches only owned listeners, destroys the private pipe, clears timers, and disconnects, closes or unreferences supported owned IPC and child handles without directly signalling that worker. The outer launcher alone owns bounded exact-group TERM/KILL reconciliation. Equivalent quick-tunnel launcher cleanup does not replace or weaken its independent whole-group proof. Duplicate, reentrant, malformed, cancelled, late, closure-faulted or partially reserved controller paths stop once and await that proof. Only proved absence with no active-stage uncertainty can produce GATE_B_CONTROLLER_CLOSED_RUN_NOT_EXECUTED; active-stage uncertainty, group uncertainty or possible protected-workspace residue produces GATE_B_CONTROLLER_FAILED_WORKSPACE_QUARANTINED as the first and only terminal result. Neither outcome permits retry, unlink, truncation, replacement resources or backward transition. These controls are lifecycle guards, not confinement, production security, release, activation, a live payment, evidence publication or Issue #45 completion.

The repository-canonical quick-tunnel manifest admits only the evidenced 2026.8.2 macOS arm64 tuple, exact official archive asset and archive digest, fixed executable basename cloudflared, independently reproduced extracted-executable digest, native format, and exact bounded version-output grammar. All other platforms, architectures, versions, floating releases, basenames, or byte identities fail closed. The executable leaf must be current-user-owned mode 0500. The verifier retains no-follow descriptors for a root-to-leaf canonical symlink-free parent chain: every directory must be root- or current-user-owned, ACL-free, and not group- or other-writable; a current-user mode-0700 anchor is mandatory, and every descendant directory is current-user-owned mode 0700. ACL absence is proved once for at most sixteen parents plus the executable, with a 200-millisecond per-call cap and four-second aggregate deadline, then bracketed by fresh path and descriptor generations; later pre-spawn, post-spawn, and CHECK guard checks are stat-only. This code provides no download, update, or fallback path. The runtime verifier proves byte identity, not acquisition history. The accepted identity is an official-release-derived byte identity, not proof of vendor signing, notarization, vendor authentication, a reproducible upstream build, malware absence, or release immutability. The synchronous version probe's two-second timeout targets only the trusted direct leader; it is not an OS sandbox and does not prove arbitrary descendant absence. Outer whole-group lifecycle cleanup and the hard lifetime provide the eventual bound.

The supervisor alone owns a launch-bound opaque attestation token in private WeakMap state. It can resolve exactly once only after the exact captured non-detached runtime child is bracketed by equal immediate pre- and post-spawn path, generation, digest, and version checks. One-time binding resolution moves the token from POST_SPAWN to CONSUMED; only a verified durable source write and exact reread moves it from CONSUMED to SOURCE_WRITTEN. Each retained readiness check repeats artifact attestation. Copied or frozen lookalikes, pre-spawn-only, cross-launch, stale, duplicate, replacement, restart, and drift cases fail closed. Retirement immediately deletes private token records after clearing child, path, pin, generation, identity, and token links. Persisted records contain none of those process or filesystem identities. Same-process module plumbing remains trusted and is not an unforgeable JavaScript authorization boundary.

The complete path-free block is copied unchanged from hostname source v2 into preserved plaintext runnerVersion 2 or current-testnet WSS runnerVersion 3, independently validated and covered by its family-specific review digest, then copied into the matching authorizationVersion 2 or 3. AUTHORIZE and the filesystem-only preflight reopen and cross-compare the complete source, configuration, digest, and authorization chain. No authorization or PREFLIGHT_VALID result exists without one exact unmixed chain. One telemetry mode accepts possible error telemetry; the other is only an operator assertion of external Sentry egress control. The implementation cannot verify firewall truth or telemetry disablement. Runtime policy records only the common observable topology, a non-detached runtime child of the retained supervisor, and never claims outer watchdog ownership. Temporary runtime storage is cleanup-or-quarantine, while the protected hostname source persists with its one-shot workspace beyond lease closure. Same-lease continuity is a validity invariant, not a file-retention bound, and no zero-persistence claim is made.

This binding is a strict cutover: hostname source v1, exceptional runner v1, authorization v1, and every old, mixed, missing, or partial tuple are rejected with no migration or in-place workspace upgrade. Replacement, restart, re-attestation drift, or rollback requires a fresh one-shot workspace while the affected workspace remains quarantined. A v1 reader must not open a v2 workspace. GATE_B_CONTROLLER_PREFLIGHT_VALID_RUN_NOT_AUTHORIZED remains non-RUN terminal status. The slice changes exactly fourteen paths and adds no new RUN entry point, invocation, authority, effect transition, selector, or execution behavior. It tightens the existing exceptional RUN/preflight validation so only the bound v2 chain is accepted; it adds no controller, launcher, watchdog, reaper, wallet, payment, or publication authority.

The dedicated public-WS one-shot lane is a narrow testnet risk exception, not a transport-policy downgrade. Ordinary inputs and workers remain WSS-only. Exceptional RPC role files use a distinct schema version and accept only canonical credential-free numeric public-IP ws:// locations with an explicit non-default port and root path. The exact current-testnet profile, explicit switch, source revision, run name, payment-intent digest, value-equal buyer/facilitator endpoint, canonical quick-tunnel block, and risk acknowledgements are cross-bound through the protected hostname source, configuration, and authorization v2 chain. The version-2 configuration digest covers that complete parsed configuration. The fixed SDK testnet NetworkID remains separate from the chain identifier. The current profile pins the height-2 hash and its previous hash after two identical fresh reads from the same operator-trusted plaintext source. That is same-source reproducibility, not independent authentication or public-genesis derivation.

The operator-visible exceptional CLI is a supervisor with no runner or SDK import. It forks one fixed execution module with empty arguments and environment, ignores the child's standard streams, and accepts a terminal result only after exact enum-only request-correlated control IPC plus clean process close. A dedicated one-use bounded option pipe carries exactly six local paths, the run name, and the transport-exception token; the parent enforces structural limits and the child performs semantic validation. It carries no RPC endpoint or wallet contents, while control IPC carries no paths. Handled faults escalate termination and are reported only after child close. A supervisor IPC disconnect handled by the execution child's event loop triggers fail-closed exit, but this is not OS-enforced parent-death protection. Crashes, signals, nonzero exits, duplicate/extra messages, malformed options, and teardown ambiguity map only to the fixed failure result. This prevents dependency console and direct standard-stream output from reaching the operator. It does not sandbox the dependency or protect against hostile same-UID code.

Before any worker, RPC, wallet, signing, or publication effect, the exceptional run exclusively creates, syncs, and permanently preserves one workspace-root consumed marker. Existing or partial marker state means consumed. It retains open workspace and run-directory handles and compares handle and pathname device/inode identity, type, owner, and mode before and after every effect or pathname state boundary. Namespace drift fails closed. This supplies one-attempt safety only inside an unchanged owner-controlled workspace. Without portable openat-style creation, a same-UID actor can still race between checks and can already replace the protected wallet inputs; no global one-shot or hostile same-UID confinement is claimed.

The run directory is preserved on every later failure. Recovery attempts and delay are exactly zero; unknown or acknowledged submission, timeout, disconnect, restart, crash, observer fault, or repeated phase hard-stops without reconciliation, replacement payment, new challenge, wallet reopen, or new signature. A clean local flow retains SUBMISSION_ARMED, the schema-v1 settlement journal and its initialization marker, and private PENDING_INDEPENDENT_VERIFICATION metadata plus the exact five typed capture fragments. It remains publicationEligible: false and creates no candidate-bundle.json, COMPLETE, evidence directory, or version-1 public bundle.

Plaintext RPC permits traffic observation, IP/address/timing linkage, denial, replay or early publication of the exact signed block, and fabrication of frontier, readiness, or inclusion responses. A disposable minimally funded testnet wallet bounds financial consequence but does not authenticate evidence or protect the host from a dependency vulnerability. Publication of the five retained private fragments or any evidence-version-1 bundle therefore requires manual confirmation of the exact block, payment-intent binding, and Momentum inclusion through a different independently operated WSS/HTTPS node or explorer. The same endpoint or operator route is not independent. Until that gate passes, neither those private fragments nor an evidence-version-1 bundle may be published. The runner itself publishes nothing. The separate operator-trusted same-route projection is an explicitly authorized, human-reviewed post-run publication artifact; it remains not evidence version 1 and not independently verified. Issue #45 remains open.

A publishable version-1 candidate requires a clean first attempt with all 21 phases exactly once. Observer clocks are invoked synchronously without a receiver, payload, or free-form metadata and are never awaited. Thrown or invalid results are contained and terminal for evidence eligibility without rejecting or otherwise changing settlement; an operator-supplied synchronous clock can still consume local execution time. A coordinator fault detected before payment construction aborts the operational attempt; any later fault leaves the settlement and journal path unchanged while permanently disqualifying the run. Inclusion UTC is captured once at the first validated inclusion and is reused for the lifecycle assertion and journal evidence; observer clocks cannot select durable journal data.

For the historical WSS runner, recovery is a safety lane, not evidence capture. It uses only the linear in-memory successor of the existing same-payment owner, has one absolute elapsed deadline plus an attempt bound, and never requests a new challenge, reads the wallet again, signs, constructs a second payment, or persists a replay capsule. A poisoned facilitator can restart in a fresh process over the one allowable journal record after confirmed old-process exit. Both current-testnet one-shot families invoke no recovery or restart path and only quarantine ambiguous state for manual independent resolution. Coordinator loss after submission is armed leaves the protected journal and incomplete marker in place and permanently forbids a version-1 bundle. Every recovery, restart, repeated phase, cached delivery, ambiguous acknowledgement, observer loss, or crash is nonpublishable.

Clean capture begins with a fresh schema-v1 revision-zero empty journal and disables retention maintenance. After loopback server closure and quiescence, one final load() supplies the single coherent record snapshot; list() is not used. The uninterrupted path requires final revision five and one MOMENTUM_INCLUDED/DELIVERED record whose cached response matches the HTTP result. Schema v2, reused or multiple-record journals, nonquiescence, cache mismatch, or unexpected retained-tree entries fail closed. The five typed fragments are assembled into a candidate and verified in memory, then only the fragments are atomically retained in the private pending directory. After a separately supplied independent-verification record is accepted, those fragments are sufficient for the existing evidence assembler and verifier. The pending run itself never persists a bundle or completion marker.

Gate B remains separately authorized. Human review must approve a disposable, minimally funded, single-use wallet and the deliberate publication of its linkable payer/payee, amount, asset, signed block, confirmation, complete exact six-field protected response body, and absolute UTC timestamps. Gate B does not require Phase 2C or hardware-wallet support. The runner does not prove authenticated RPC or chain identity, canonical lineage, finality, facilitator authorship, HTTP delivery, buyer receipt, secret absence, replay prevention, resource authorization, Phase 2C, hardware-wallet safety, release, activation, or production readiness. Merging PR B does not release or activate the operational runner. Issue #45 remains open until the live run and public evidence are separately completed and reviewed.

Automation must stop before creating or populating private role files, provisioning live ingress, or accessing or funding the disposable wallet. An identified human operator must supply and approve those inputs. Only after that operator-authorized provisioning may preflight validate protected input-file identity, metadata, generation, public configuration, RPC syntax, and output noncollision. Historical WSS preflight opens every protected role file, reads only the public config and buyer-RPC input, and does not read buyer-wallet or facilitator-RPC contents. Current-testnet one-shot preflight opens six protected files, including the fixed hostname source, and reads the public config, both RPC role files, authorization, and hostname source, but never reads wallet contents. Neither preflight performs network activity.

Preparing and offline-testing the helper source does not cross this stop rule. Invoking the helper creates real private wallet material and therefore remains the identified operator action at this boundary; helper success does not authorize funding, preflight, run, or publication.

The fixed failure line does not prove that no wallet was created. After any invocation failure, do not retry or remove either fixed target automatically; treat every existing target as sensitive residue until the identified operator completes local inspection and recovery.

A successful preflight is not run authority. Stop again before invoking run; a separate explicit human authorization permits exactly one payment. Preflight and run do not themselves authorize evidence publication.

For the historical WSS runner, if publication becomes SUBMISSION_OUTCOME_UNKNOWN or SUBMISSION_ACKNOWLEDGED, or a process crashes after submission is armed, reconcile only the byte-identical payment and never construct or publish a replacement payment. Both current-testnet one-shot families perform no automatic reconciliation; quarantine their payer and journal for manual independent resolution. Recovery, ambiguity, or crash remains nonpublishable, and Issue #45 remains open.

• no authenticated genesis/checkpoint implementation or SPV verification;
• no audited domain-separated binary payment-intent encoding;
• no formal CAIP-2 Zenon namespace is asserted;
• no integrated distributed settlement or entitlement database; the SQLite service-credit store, mock activation adapter, capability verifier, HTTP handler, composition owner, and optional local loopback transport remain isolated references outside every active path;
• no complete local verification of consensus or Plasma/PoW rules;
• live integration is not exercised against a node by the automated tests;
• RPC polling is authoritative and subscriptions are wake-up hints only;
• mock mode cannot establish live consensus, frontier, singleton or confirmation correctness;
• key-pair clear() is defense in depth and cannot guarantee JavaScript memory zeroization.

The facilitator must never gain the ability to move more value, redirect value, choose another asset, or authorize another resource than the payer explicitly signed. Any future delegated-authorization design must preserve that property.