Real consent. Reused evidence. Verified revocation.

A bounded MuMaps → Emabled → test ESP pilot verified the C01/SR01 lifecycle on Polygon testnet: CURRENT, an unchanged CURRENT recheck, then REVOKED.

What this result means: one real recipient, one sender and one communication type, under draft-saez-xcim-04. The project operated the attester, test ESP and separate receiver. This is a completed pilot, not a production service, mainnet result or independent ESP interoperability test. No email was sent.

What we demonstrated

A person completed a fresh Google-backed MuMaps session and separately accepted “MuMaps news.” Emabled issued the signed consent. The authenticated test ESP acquired its evidence, and a separate local receiver checked the exact recipient/sender/type query, issuer authority, signed grant, revocation synchronization and admitted blockchain proof.

The same original consent was retained throughout. Its explicit pilot expiry stayed at 21:00:01 UTC. Neither unchanged recheck renewed the consent, downloaded it again or required a new chain transaction. Each evaluation ran in a separate process with the same durable receiver state; the final recheck retained REVOKED.

Byte counts measure acquisition JSON only. They exclude HTTP/TLS, login, blockchain proof downloads and storage. An empty delta still includes a signed checkpoint and head. These four observations are not a throughput benchmark or a cost estimate for millions of subscribers.

How revocation reached the receiver

The person explicitly requested the test withdrawal in chat. MuMaps executed that one request through its authenticated application API. The event records actor=sender and method=emabled-permission-api-v1. MuMaps did not yet have an unsubscribe screen; this was not a new recipient OAuth ceremony or a self-service UI withdrawal.

The receiver downloaded one authenticated withdrawal and moved its sender sequence from 0 to 1. It returned REVOKED without waiting for the event’s later blockchain proof. Batch 2 subsequently anchored the event, and its membership, signature, predecessor and chain proof were checked separately. The next recheck downloaded no additional events and remained REVOKED.

Freshness is not consent renewal

SR01’s experimental 300-second bound concerns the freshness of shared synchronization evidence. It does not require every recipient to opt in again every five minutes. The verifier retains original grants, synchronizes missing withdrawals and checks each relevant permission’s original expiry and scope before relying on it. This pilot’s grant had an explicit two-hour duration; it was not silently extended.

Two real testnet anchors, with an explicit trust boundary

Network: Polygon testnet, chain ID 80002. The attester submitted commitments through RPC access; no dedicated blockchain node was provisioned. The exact network identifiers and explorer links below identify the testnet used, not an infrastructure requirement for adopters.

• Batch 1: consent — block 51,218,855. View transaction0x0f1683a58ac51e3c114ad4035550dbd5e681ea863c3621a141483029a6ef5dbbRecorded chain-verifier output.
• Batch 2: withdrawal — block 51,220,017. View transaction0x15af373cf21bf1a243032b62ce4b6aa0e9e104e8cd298a989ec5499df3454c1cRecorded chain-verifier output.

The admitted adapter verified retained Heimdall validator continuity and consensus signatures, milestone state proofs, Bor ancestry, transaction and receipt roots, contract runtime and storage proofs, exact calldata, recovered signer, batch commitment and registry sequence. A mined transaction or matching RPC responses alone were not accepted as consent proof.

Initial trust: an operator-approved PublicNode HTTPS checkpoint, accepted only for this testnet pilot. Later verification advanced the same durable trust store; it did not restart trust from fresh provider responses. The network was not authenticated independently of that initial checkpoint. Separate tools do not make the participating organizations independent.

Contract: 0xfd7FdA6F5eab64D74F90A70995AAF13d54f272a9

An operational failure we found

The permission API accepted withdrawal at 19:17:51 UTC, but the worker lacked access to the existing revocation-signing key. The pending-withdrawal barrier blocked fresh evidence responses with HTTP 409 while that signature was unavailable. This did not retroactively invalidate previously issued checkpoints or remove their bounded cache window.

After the missing, time-limited signing permission was corrected, the event entered the stream at 19:22:11 UTC; the receiver returned REVOKED at 19:22:31 UTC. Request-to-stream delay was 260 seconds, and request-to-receiver delay was 280 seconds. Those measurements include diagnosis and recovery. They are not normal latency claims or an SLA.

No grant, queue entry or receiver history was reset to obtain the result. After the run, pilot execution was disabled and temporary access was removed. Evidence and durable receiver state were retained. This report documents a historical execution, not current endpoint availability or permission to send.

What remains before production

1. Operational preflight and failure handling. Verify database and signing permissions before activation; alert on blocked withdrawal queues; bound retries; measure propagation under normal and failed conditions; handle policy expiry deliberately.
2. Historical anchor refresh. The pilot adapter accepts the latest batch only. A general implementation must refresh proof for a still-valid grant after later batches appear, without silently reinitializing trust or changing the grant.
3. Recipient and operator workflows. Provide an authenticated unsubscribe experience and supported sender/ESP interfaces, with explicit authorization, evidence retention and recovery procedures.
4. Scale and independent integration. Test multiple recipients, senders, pages and concurrent updates; measure total proof cost and sustained load; run an independently operated ESP integration and external security review.
5. Production network admission. Establish and review production trust, key lifecycle, chain/finality policy, service commitments and recovery. This testnet bootstrap does not authorize a mainnet deployment.

The pilot also does not demonstrate autonomous agent account creation, campaign sending, inbox placement, legal compliance or protection from every spam complaint.

Public evidence and its limits

These files report the observed run and the chain-verifier outputs. Recipient addresses, salts, tokens, original grant envelopes and private permission mappings are withheld. The redacted publication alone cannot reproduce every consent check. Hashes identify these published files; they are not independent certification.

The anchor component reports operational_c01_proof=false because it verifies an anchor only. The composed receiver supplied the historical consent results. Recorded proof deadlines are historical, not renewed by downloading these files.

The archived real signatures, complete SR01 prefixes and grant/event batch memberships were cross-checked with the unchanged draft-04 Python components at the recorded evaluation times. The separate synthetic suite reported 167 assertions plus cross-language and recovery checks. Those synthetic tests are not additional live recipients or live failure-injection results.

Protocol interpretation on xcim.org · Exact Internet-Draft revision · SR01 reference component · Earlier implementation reports