Shared revocation synchronization

Keep the original permission. Synchronize withdrawals. Verify that the local history is complete and recent.

How it works

1. The recipient explicitly grants permission to an identified sender for specified communication types. The attester records and signs the grant, with its historical blockchain evidence.
2. An authorized verifier acquires the original grants and initializes a complete revocation history for the sender epoch.
3. Before relying on a permission, it obtains any missing withdrawals and a signed shared synchronization checkpoint. It verifies the complete history through that checkpoint.
4. It checks each relevant permission locally, including scope, withdrawals, original expiry and current authority. Missing updates cannot become a positive permission.

What the 300 seconds mean

The experimental freshness bound applies to shared synchronization evidence. It is not the lifetime of a recipient's permission and does not require another login, opt-in or a per-recipient confirmation every five minutes. Grants retain their original finite expiry. An idle sender does not require continuous checkpoint generation.

Protocol and implementation

SR01 defines evidence and verification. Attesters and integrators choose APIs, storage, caching, notifications, page sizes within protocol limits, and scheduling. Campaign management and opt-in/unsubscribe interfaces are outside core conformance. An authenticated withdrawal's validity and effect remain in scope.

Compatibility and blockchain

The new evidence profile is xcim-consent-sync-01. It reuses signed C01 grants without changing their bytes or extending their duration. A C01-only verifier must reject the new profile. Original grant blockchain verification and withdrawal anchoring remain required under their existing rules. Shared checkpoint refresh does not require a new chain transaction. A signature authenticates the attester's statement; it does not prove that a dishonest attester disclosed every withdrawal.

Implementation evidence and limits

The local shared-history component passes 34/34 deterministic cases with public test keys. This is not a complete integrated SR01 verifier or an operational deployment. It does not establish durable crash recovery, real provider flows, live blockchain verification, independent interoperability or measured scalability. Bootstrap currently requires full revocation-history replay; compact snapshots are not specified.

A separate live C01/SR01 pilot on 26 October 2026 verified a fresh human consent, cached recheck, incremental withdrawal and persisted REVOKED result with real testnet anchors. Those implementation results do not change the scope of this frozen reference component. Production hardening, historical anchor refresh, recipient unsubscribe UI, scale tests and independent ESP integration remain open.

Review artifacts

• Scope and reproduction guide · Dependencies
• Shared-history component · Preserved C01 dependency · Tests
• Executed report · Synthetic signed example · Structural schema