C01 has a real pilot result.
A MuMaps/Emabled integration verified fresh consent, reused its original evidence, and detected an incremental revocation with a separate receiver.
Bounded testnet evidence. One recipient, one sender, one communication type, under draft-saez-xcim-04. The project operated the participating services. Production readiness and independent ESP interoperability remain open.
What changed
C01 was previously represented by local reference fixtures and an unfinished operational integration. On 26 October 2026, the composed implementation returned CONSENT_CURRENT, returned it again without renewing the original consent, and then returned CONSENT_REVOKED after a real, explicitly requested withdrawal. A further process invocation preserved that revoked result.
The consent and withdrawal commitments were published on Polygon testnet and verified under an explicitly admitted chain adapter. The original signed consent stayed off-chain. No email was sent.
What this demonstrates about the protocol
- A real implementation can combine address-control evidence, a separate affirmative consent decision, signed grants, shared revocation synchronization and blockchain verification.
- The original grant can be reused while the verifier synchronizes withdrawals. A five-minute freshness bound does not mean renewing recipient consent every five minutes.
- A verified withdrawal can suppress sending before its later chain proof is available; its commitment was subsequently anchored and checked.
Where the evidence stops
This was a project-operated test ESP and separate local receiver, not an independently operated ESP. The initial blockchain trust came from an explicitly approved PublicNode HTTPS checkpoint for this pilot. The withdrawal was requested in chat and executed through MuMaps’ authenticated API; a recipient unsubscribe screen is still missing.
A missing signing permission delayed the receiver’s revoked result by 280 seconds. The implementation blocked fresh positive evidence during recovery. The report preserves this incident; it is not a latency SLA. The latest-batch-only anchor adapter also needs historical proof refresh before a general rollout.
What remains before production
Operational preflight and monitoring, historical anchor refresh, recipient and ESP workflows, capacity measurements, independent integration, external review and production network trust admission remain required work. The pilot does not establish mainnet readiness, autonomous agent onboarding, campaign delivery or legal compliance.
XCIM remains an experimental open protocol. Emabled is the implementation used in this run, not a required provider or universal trust root. An individual Internet-Draft is not an approved RFC, working-group adoption or IETF endorsement.
The canonical implementation report includes the four observations, exact transactions, trust assumptions, incident timeline, reviewed public JSON and production gates. Earlier signed fixtures and reports remain unchanged and retain their original scope.