Skip to content

Verifier Policy

OpenETR is an open signed-event system.

Any organization can write its own verifier rule book on top of the OpenETR event graph.

Baseline Verifier

The generic verifier should inspect:

  • event signatures;
  • event kinds;
  • object tag o;
  • action tags;
  • prior-event links through e;
  • participant tags;
  • encumbrance references;
  • lifecycle state;
  • known or unknown npubs.

When a transition breaks a rule, the generic verifier should report a warning rather than erase the event or raise an unrecoverable error.

Separate Results

A verifier should not reduce every question to one valid result. Where applicable, it should report separately:

  • artifact integrity;
  • event authenticity and structural validity;
  • graph continuity;
  • transition validity;
  • consequential state;
  • retrieval coverage;
  • evidence sufficiency;
  • optional Temporal Proof;
  • actor and authority recognition;
  • reliable-system evidence; and
  • external recognition and effect.

Useful status values include valid, invalid, unverifiable, absent, not_evaluated, and not_applicable.

Retrieval coverage is source-specific. A relay saying that it returned all matching records it stores does not prove that no additional record exists on another relay, in an archive, or outside the observed evidence boundary.

Each proof proves only what it proves.

Domain Verifiers

An MLWR verifier can add domain-specific policy:

  • whether an issuer is a recognized warehouse operator;
  • whether a holder is recognized;
  • whether an encumbrance is effective;
  • whether a discharge was signed by an appropriate releasing party;
  • whether a termination event should be accepted;
  • whether a change of medium is recognized;
  • whether KYC, registry, TRQP, or Web of Trust evidence is sufficient.

Recognition Boundary

OpenETR focuses on control.

Recognition concerns sit above it:

  • KYC;
  • legal entity mapping;
  • warehouse licensing;
  • registry status;
  • attestation;
  • Web of Trust;
  • Trust Registry Query Protocol;
  • jurisdiction-specific effect.

This is similar to TCP/IP supporting applications without enforcing application-level policy. The protocol can carry identifiers and signed facts; the integrating system decides which facts it recognizes.

Source Notes