Documentation
The full reference, organised to re-check.
The full reference — concepts, the record format, the mechanism specification, and integration guides — organised for reading and re-checking.
This is the reference. It documents the concepts, the record format, and the mechanism specification that describe how Veraq is designed to work. It is organised the way you would want to re-check something: each section names what it covers, and what it will point to once the open record's read API is live.
Read it end to end once to build the model, then return to a single section when you need to verify one claim — for now that means reading the design; the read API isn't live yet, so no entry is queryable directly from this page today.
Concepts: the seven entities
- Wave
- A defined round of participation. A wave references the mechanism committed before it begins and resolves to a single outcome after it ends.
- Mechanism
- The published selection process a wave runs on. The current specification is commit-reveal-v1: committed to the record before the wave, revealed and provable after.
- Participant
- A person who takes part. Centred as an active contributor, not a consumer; identified on the record without exposing private data.
- Participation
- A single act of taking part in one wave. It links a participant to a wave and is recorded as it happens.
- Outcome
- The resolved result of a wave, derived from the revealed mechanism. Neutral and exact; recorded, never promised.
- Contribution
- The defined share of a participation routed automatically to a verified cause, written from outcome to cause so it can be followed.
- Cause
- A verified destination for the defined share, fixed per wave and published in advance. Vetted and named openly on the record.
Every entity above is designed to be an entry you'll be able to read. The reference describes the system today; the record will prove it once it's live.
The open-record format
One record, seven entity types
Each entry is one of the seven entities. Entries are written as they happen and are not rewritten after the fact.
Entries link, they do not nest
A participation references a wave and a participant; an outcome references its wave; a contribution references its outcome and its cause. Follow the references to trace any claim.
Commit fields, then reveal fields
A wave carries the mechanism commitment before it runs and the reveal after. The reveal is checked against the earlier commitment so nothing can be substituted.
Open and inspectable
The format is documented and stable today. Once the read API is live, you'll read the same entries the platform reads, with no privileged path and no hidden state.
Mechanism reference: commit-reveal-v1
- 01
Commit
Before the wave opens, the mechanism’s deciding input is committed to the open record as a binding commitment. The math is published first; nothing about how the wave resolves is left to be filled in later.
- 02
Participate
Participations are recorded against the open wave. Each links one participant to this wave and is written as it is made, under the commitment already on the record.
- 03
Reveal
When the wave closes, the committed input is revealed. The reveal is verified against the commitment made at step one — a mismatch is detectable by anyone reading the record.
- 04
Resolve
The outcome is derived from the revealed input and the recorded participations, then written as an outcome entry. The same inputs reproduce the same outcome, so the result is provable rather than asserted.
- 05
Contribute
The defined share of the participation is allocated automatically to the wave's fixed cause and written as a contribution, linked from outcome to cause.
Guides and API reference
How do I read a single wave end to end?
The design: start from the wave entry, read its mechanism commitment, then its reveal, then follow the reference to its outcome and on to the contribution and cause, each hop one reference in the record. The read API isn't live yet, so today that's a description of the path, not one you can walk yourself.
How do I verify a wave myself?
Not yet, but that's the design: re-check the reveal against the commitment recorded before the wave, then re-derive the outcome from the revealed input and the recorded participations. Matching results will confirm the wave resolved as the mechanism specified, once the read API is live.
What can I build on?
The seven entities are documented and stable today. The open record itself — readable without special access, so you can read the entities, follow their links, and verify against the published commit-reveal-v1 specification yourself — is designed, not yet live; see Developers for current status.
How are breaking changes handled?
Entities and the record format are versioned. The mechanism is named by version (commit-reveal-v1) so an entry always states which specification resolved it; the changelog records what changed and when.
Documented to be read, versioned to be re-checked, and designed so any claim will trace back to its entry once the record is live.