Working draft for public review. Not a stable standard, IETF adoption, certification or production recommendation. Experimental profiles require explicit opt-in.

Amoy Pilot 0.1 — Experimental Publication Profile

WD-01 · Profile xcim-evm-amoy-pilot-0.1 · Testnet only

1. Scope and trust

This profile describes the frozen public snapshot and verification mechanisms exercised on Polygon Amoy, chain ID 80002 (eip155:80002). It is not a mainnet profile, an accredited issuer list or a production availability claim. Core wire objects remain version 0.1, and the exercised public receipt path is OIDC-01, not EVP-01.

The receiver MUST explicitly provision the accepted chain/contract, issuer URN and HTTPS URI, separate receipt/batch public-key pins, authorized chain signer and finality policy. Downloading a genesis document or seeing an issuer's name in a report MUST NOT establish those pins. No contract address, brand or RPC endpoint is a universal XCIM trust root.

2. Closed objects and commitments

The additional publication objects are an anchor_genesis, a six-field proof core and a proof_bundle_set. Their schemas are separate from the established closed core proof bundle; adding arbitrary publication metadata to an old bundle is not supported.

For each row below, hash the UTF-8 domain including one terminal NUL byte followed by the specified bytes, using SHA-256:

The proof core contains exactly receipt_id, permission_id, receipt, receipt_event, event_inclusion_proof and state_proof. It MUST NOT embed its own batch or anchor. This prevents a circular commitment when the batch itself commits to the proof set. The state proof at this stage has no anchor_reference; the completed core bundle adds the accepted anchor reference without changing the committed prepared core.

Each proof-set entry contains receipt/permission IDs, a domain-separated core_commitment encoded as unpadded base64url and core_content_sha256, the ordinary SHA-256 of the canonical core bytes encoded as 64 lowercase hexadecimal characters without 0x. Those are different hashes and encodings. Entries MUST be unique by receipt/permission and resolve to exactly the committed core. The set includes issuer, batch sequence, creation time, roots, genesis, previous anchor and an explicit count of unrelated historical receipts excluded by current semantic checks.

The first batch's previous_anchor_hash is the genesis commitment. A successor uses the prior accepted anchor-record commitment. proof_bundle_set_hash is the set commitment, including its genesis/previous-anchor fields. An outer storage hash is not a replacement for these domain-separated commitments.

3. Genesis and key roles

Genesis fixes the issuer URI/URN, Amoy chain, contract, deployment transaction/block/hash, creation/runtime code hashes, authorized signer and separate Ed25519 receipt/batch JWK pins. The receiver MUST compare these to its independently accepted configuration and verify code/deployment provenance under its chain policy. Self-consistency of a downloaded genesis is necessary but not trust establishment.

Historical state may be pruned at public RPC providers. A verifier MAY corroborate canonical deployment/creation and current finalized code/owner using independently operated sources when that is sufficient for its pinned policy. It MUST NOT skip provenance verification just because an archive query fails.

4. Atomic snapshots and publication

Batch preparation MUST freeze event history, permission projection, exact timestamps and proof cores consistently. A concurrent authority/state change MUST either be included consistently or abort preparation. Sealed historical objects MUST NOT be reconstructed from mutable current state.

Prepared material with stage awaiting_chain_anchor is not a completed proof or send authorization. Publication of a completed bundle MUST wait until the actual transaction receipt and matching event authenticate the expected batch. Retrying preparation/publication MUST use the same frozen content or fail; it MUST NOT silently refresh the old snapshot.

Historical objects SHOULD use immutable content-addressed storage and conditional creation. A storage retry succeeds only for identical bytes. Authenticated pointer changes require compare-and-swap or equivalent protection against lost updates. Operational input-hub administration is implementation-specific and does not establish the receiver's trust policy.

5. Independent anchor checks

The receiver MUST check chain ID, pinned contract/signing authority, successful canonical transaction receipt, matching anchor event and exact sequence, roots, batch commitment, previous anchor, event delta and block hash. Event-count fields MUST be interpreted as the contract specifies; the 0.1 manifest separately provides cumulative tree_size and new batch_event_count.

The exercised contract event signature is AnchorSubmitted(bytes32,uint64,bytes32,bytes32,bytes32,bytes32,bytes32,uint64,address). Its topic zero is 0x75e82d6b90f3e95f9f1ddc313ac6c1488e2180a48b2aa6f7ec7b730eeaccd42b. Indexed topics one, two and three contain the issuer commitment, batch sequence and anchor ID. The six ABI data words contain event root, state root, batch-manifest hash, previous-anchor hash, event delta and signer, in that order. A successful transaction without this matching event is insufficient.

The anchor ID is keccak256(abi.encode(issuerCommitment, batchSequence, eventRoot, stateRoot, batchManifestHash, previousAnchorHash, eventCount)) using the exact static ABI types above. A verifier MUST preserve the full 32-byte values, validate the uint64/address encodings and check same-sequence variants through anchorVariantCount(bytes32,uint64). Multiple conflicting variants do not become acceptable by selecting the first response. The first accepted sequence is one; successors advance by one. Protocol hashes expressed as base64url and ABI bytes32 hex are the same bytes, not a second hash.

Finality MUST be established from the accepted chain view, not inferred from the number printed in issuer JSON. Conflicting anchors/forks and unexpected replacement variants MUST fail the policy. This pilot uses two independently operated RPC sources; their agreement is a bounded corroboration measure, not proof equivalent to a locally verified consensus/light client.

RPC 403/429, timeout, disagreement, missing/pruned data and deadline exhaustion MUST result in unavailable verification, never a relaxed PASS. Retry pacing MAY accommodate rate limits but MUST preserve total deadlines, pins, finality and fork checks. Waiting longer must not make the underlying signed status window longer.

6. Freshness and expiry

For this profile, this_update MUST equal the authenticated batch's created_at. next_update MUST be later than this_update and no later than five minutes after it. The receiver MUST validate those relationships, and an attacker changing either unsigned proof timestamp MUST NOT extend acceptance. A local policy may impose a shorter interval.

The effective positive deadline is the earliest applicable bound from state, receipt, signing-key authority, app/domain bindings and trust policy. At the bound, a cached, exported or asynchronously computed positive result MUST cease to establish current permission. generated_at, time of download and UI job completion do not renew the authenticated snapshot.

A new zero-event checkpoint may renew the current-state observation only after validating a new consistent snapshot, signing a new manifest and satisfying the selected anchor policy. It MUST retain the original receipt/event chronology. A new manifest is not evidence of another recipient or grant.

7. Historical evidence and limits

The informative first-batch report records 19 issuer events and four published MuMaps proofs on 14 October 2026: three active control receipts for the same identity and one revoked control. Its five-minute signed window has expired. The transaction remains evidence of historical commitments, not a current permission assertion.

Separate receiver/Python checks observed PASS and REVOKED within the window, rejection of an altered path, bounded cached acceptance and stale/indeterminate outcomes at or after expiry. The cache-unavailability scenario was injected in a receiver; it was not a production-outage drill. This result is not independently operated sender/receiver interoperability, an EVP test, issuer accreditation, mainnet deployment or continuous service evidence.

Fresh CSV/ZIP public-status evaluation, ongoing snapshot operations, RPC capacity planning, independent key/trust review and paired interoperability require their own evidence. This draft does not claim them merely because the first transaction exists.