Topics · Protocol concept

Protocol governance

Third parties audit who changed rules, when anchors were accepted, and whether offline receipt validity still holds regardless of governance UI availability.

Concrete scenario

What this looks like in practice

A platform updates anchoring policy quietly after a disputed batch. Operators claim receipts were always recognized under the new rule. External verifiers need immutable governance events and independent validator signatures — not a dashboard toggle, retroactive spreadsheet, or operator blog post.

Problem

What breaks today

If the same party mints receipts, writes anchor rules, and controls verifier narratives, disputes collapse into vendor trust. Proof infrastructure needs role separation with visible rule changes and independently replayable governance events.

Mechanism

How ZK-SNAP responds

Governance authorizes meta-rules through chain-visible events mirrored publicly to independent verifiers. Validators sign blocks, operators submit anchors, verifiers check cryptography independently without portal access. Launch gates keep mainnet recognition and settlement staged until hardening completes.

Verifiable outcome

What a verifier can check

  • Governance events are replayable from chain-visible records and public mirrors.
  • Validator sets and operator lanes match published role separation rules.
  • Receipt validity checks do not depend on governance portal uptime.
  • Pre-testnet staging flags are visible where launch gates still apply.

Related profiles and labels

Role separationGoverned witnessVisible rule changesPre-testnet staging

Scope boundary

What a receipt does not replace

Governance structures protocol rules — not national law, contractual SLAs between vendors, or automatic certification of every operator without 3DVC conformance testing.

Go deeper

Try the workflow, then read the spec.

Use Cases tells the story with cards. Proof Lab runs create and verify locally. Protocol holds the normative reference.