Skip to content

Verifier Acceptance Spec

What This Page Explains

This page explains what the verifier acceptance path checks today in the published bounded profile.

Why It Matters

New readers need to distinguish structural acceptance, bounded semantic checks, and what remains host-side.

Plain-Language Concept

The verifier path accepts specific boundary formats and checks the bounded statement profile currently published. It is a milestone profile, not final verifier completeness for all future modes.

Technical Detail

Profile Accepted Today

  • Trustless Relation Query 1 (TRQ1)
  • backend id 2
  • bounded two-input lane profile

Inputs Accepted

verifySpend(...) accepts:

  1. piv1Bytes: Public Inputs version 1 (PIv1), wire magic "PIV1"
  2. pbv1Bytes: Proof Blob version 1 (PBv1), wire magic "PBV1"

What Is Checked

  • Structural checks: envelope parsing, encoding validity, profile/backend compatibility, binding consistency.
  • Bounded semantic checks: relation checks for the active bounded lane profile.
  • Host-side checks: transaction-carrier integrity and integration fail-closed behavior on the wallet/host path.

BCH Constraints And Bounded Verification

BCH script and carrier constraints shape a bounded verifier path in this milestone. The path is strong for its published profile, but not a claim of generalized verifier completeness across arbitrary profiles or full-system metadata closure.

Current Truth Boundary

  • Current truth: verifier acceptance path is live for the published profile.
  • Proof-enforced semantics: bounded profile checks are enforced when verification succeeds.
  • Artifact-described behavior: evidence reporting remains descriptive.
  • Public observables: BCH graph/economics/topology remain public.
  • Future optional aggregation: outside verifier acceptance scope.

Code Mapping