Skip to content
veraq

Concepts

The seven entities.

Veraq's record is built from seven entities and one mechanism. Field names and prose use only these nouns — this is the contract every SDK, the explorer, and the API reference agree with.

The record entities

  • Wave

    A round of participation. Runs one mechanism; contains many participations; resolves to outcomes.

    Runs one Mechanism · contains many Participations · resolves to Outcomes.

  • Mechanism

    The published selection rule (commit-reveal-v1), committed to the open record before a wave runs.

    Committed to the open record before a Wave runs.

  • Participant

    A person taking part. Makes participations; chooses a cause.

    Makes Participations · chooses a Cause.

  • Participation

    One participant's entry into a wave; written to the open record.

    Belongs to a Wave and a Participant · written to the open record.

  • Outcome

    What a wave resolves to. A defined share routes to a contribution.

    Belongs to a Wave · a defined share routes to a Contribution.

  • Contribution

    The defined share routed to a cause, derived from an outcome.

    Derived from an Outcome · addressed to a Cause.

  • Cause

    A verified public-good recipient of contributions chosen by participants.

    Receives Contributions chosen by Participants.

  • Allocation

    One recipient's share of the participant-distributable class, reaching that recipient at the resolution of one outcome — a level-6 record entity (03 §2; ADR 0016 §1 spells the level out as 'the per-event record entities').

  • Attestation

    An independent party's report that it replayed a settled outcome and what it found — the open class 03 §5.5(b) names as the source of Outcome.verified: '.net's open attestation class, which anyone may publish and for which Veraq certifies nobody and pays nobody.' THE OPENNESS IS THE CONTROL, NOT A CONVENIENCE.

  • Challenge

    A dispute raised against a container's settlement — 03 §2 level 6's sixth and last leaf ('Participation, Outcome, Allocation, Contribution, Funding, Challenge'), never built until 04 W3-E13.

  • Commitment

    What was pinned before a container opened, per container, discriminated on verification form.

  • Container

    A cohort with a freeze predicate.

  • ContainerClassTotal

    A container's open-record total for one obligation class — the shape `04` W4-E10's own design artefact (docs/ops/foundation-principle-reporting-dimension.md:82-93) specifies for `03` §7.3 rule 2's first half: 'Per-container class totals are open-record entries.' ADR 0015 §6 states the same rule in its own words: 'Per-container class totals are Open Record entries.

  • Fund

    A long-lived economic, governance and accounting boundary anchored to a jurisdiction — ADR 0028 Decision 1, answering `01` §8 Q14 ('What is a Fund?'), OPEN from ADR 0013 (2026-08-02) until ADR 0028 (2026-08-11).

  • Funding

    One inflow recorded against a container — a level-6 record entity (03 §2), and the moving input a threshold container's freeze predicate is read against.

  • JurisdictionBalanceCommitment

    Control-ledger only, per `03` §7.3 rule 2's second half and ADR 0015 §6, same rule — 'Per-jurisdiction balances remain control-ledger, anchored as digests only.' The shape `04` W4-E10's own design artefact specifies (docs/ops/foundation-principle-reporting-dimension.md:94-104).

  • ParticipationPartitionReport

    Per participation, per `03` §7.3 rule 3 and ADR 0015 §6, same rule — 'Per participation, only `partition_rule_digest` is published, openable by the holder — because publishing the applied `(product, jurisdiction)` pair would publish the participant's jurisdiction.' The shape `04` W4-E10's own design artefact specifies (docs/ops/foundation-principle-reporting-dimension.md:105-114).

  • PayoutRail

    A discriminated payout-rail taxonomy.

  • PolicyBinding

    `04` W4-E06 — `03` §3 binding 6, verbatim: 'eligibility, jurisdiction, age, limits.' `02` §4: 'Policy: `.io` executes, `.org` binds via `PolicyBinding`' — this is that binding, real for the first time (`02` §4 previously filed governance binding as 'currently mis-filed as a future E1 plugin').

  • ReserveObligation

    The per-class record for a jurisdiction's public-obligation classes — `01-platform-architecture.md` §4.3 change 6, RETAINED under ADR 0015 §11.1's amended point 1 and its own text: 'it remains the per-class record for the public-obligation classes; the partition rule decides what enters it.' THIS IS A RECORD SHAPE, NOT A COMPUTATION — the same distinction allocation.schema.json draws against ADR 0015's crossing authorities: a record shape at level 6 versus an authority over a money crossing.

  • ResultObservation

    What was RECORDED AT RESOLUTION for an `external`-form container — `03` §5.1, verbatim: "observed value, provenance, source-publication digest, and every failed capture attempt"; `02` §7 unpacks provenance as "where fetched, when, by whom".

  • ResultSource

    The pinned definition of WHAT TO OBSERVE for an `external`-form product — `03` §5.1's committed "source authority, publication URL, exact field, format, revision policy".

The wave lifecycle

announcedopenresolvingsettled

Wave lifecycle. 'announced' = mechanism published, not yet open. 'resolving' = window between closes_at and the recorded outcome. 'settled' = outcome verified and contributions transferred.

commit-reveal-v1

The published selection rule. The seed commitment is written to the open record before a wave opens; the seed itself is revealed after the draw, so anyone holding the participation list can deterministically replay the outcome. It is never “the algorithm” and never dressed up as magic — it is committed and provable.

commit-reveal-v1✓ verifiable
# commit-reveal-v1 — committed before, provable after.
commitment = sha256(seed ‖ parameters)   # published BEFORE the wave opens
            … the wave runs …
reveal     = the seed, published AFTER resolves_at
verify     : sha256(reveal ‖ parameters) == commitment   ✓ matches

Verify

Both public repositories ship golden vectors — canonical input/output fixtures for commit-reveal-v1 and the record format. A green run against the published vectors is the proof that any independent implementation is correct.