Glossary (A–Z)

The vocabulary the protocol uses, defined against the contracts rather than the design documents. Where a term is an on-chain enum, its values are listed — those are the only values that exist.

The Explorer shows its own short definitions as tooltips beside the records they describe. This page is the longer form.

Structure

Frontier — A top-level data domain. Campaigns and tasks roll up to exactly one frontier. Dataset versions do not — assembly is frontier-agnostic on chain and the assemble event deliberately omits a frontier id. A version's metadata document may name a primaryFrontierId, and the indexer surfaces a frontier that can be null.

Campaign — A collection effort inside a frontier: it says what data is wanted and issues tasks. Created on chain by an allowlisted issuer, or by the owner of the DID it is created under.

Task — A unit of work under a campaign. Its stored record is thin — id, campaign, owner DID, and a metadata commitment — while its type and its execution mode are declared when it is created and emitted in the creation event rather than kept in that record. So a reader querying the contract sees less than a reader following the events; the indexer follows the events. The task's metadata document is where the acceptance rule lives.

Acceptance rule — How a task decides whether a contribution is admitted. Four shapes: consensus with a minimum number of agreeing validators, gold_standard with a match threshold, auto_accept, and agent_qa_with_spot — agent review with a spot-check percentage and a sidecar task for the checks. This is where "how was this judged" is answered.

Contribution

Atomic contribution — One indivisible piece of work: a sample, a label, an amendment or a validation. It is what a single Contribution Fingerprint records.

Contribution Fingerprint (CF) — The on-chain record of one atomic contribution: a commitment to its content, the contributor's DID, the validator's DID, the kind, the verdict and the grade. It carries no timestamp — a CF's time is the block that anchored it — and no evidence structure.

Kind — What a contribution is. On-chain enum: SAMPLE (raw data), LABEL (an annotation), AMENDS (a correction) or VALIDATION (a review).

Verdict — The outcome of validation. On-chain enum: PENDING, APPROVED or REJECTED. Re-settable after anchoring by any enabled validator.

Grade — A quality assessment set by the validator. On-chain enum: NONE for ungraded, then D < C < B < A < S ascending. The protocol defines the range; nothing constrains how a validator picks a value.

Execution — Whether a task is carried out by a HUMAN or an AGENT. Declared when the task is created and emitted in the event; not part of the task's stored record.

Task type — SUBMISSION for work that adds data, VALIDATION for work that reviews it. Declared and emitted the same way.

Contributors — People or agents who submit atomic contributions and can claim ownership shares in the dataset versions their accepted work goes into.

Validators — Holders of DIDs on an allowlist the contract owner curates. A validator's signature is required to anchor any CF, and a validator sets the verdict and grade. Validators are not royalty recipients, and nothing requires a validator's DID to differ from the contributor's.

Identity

Identity — The DID and the wallet behind it, which sign actions and set the policy context for access.

DID — Decentralized identifier for a contributor. The stable identity that fingerprints, shares and royalty attach to.

DBA (DID-bound account) — The account address bound to a DID. Shares mint here. Royalty is accounted against this account but paid to the DID's current owner wallet, not to the DBA — the engine says so explicitly, to avoid a two-step withdrawal. The address is derived deterministically from the DID, so it is known before the account is deployed; deployment happens on first use and is idempotent thereafter.

Dataset

Data assembly — Building a versioned dataset from CFs and committing to who contributed what.

Dataset version — A frozen dataset. Its identifier is derived from the assembler's DID, the manifest id and a version counter — never from the members — so assembling the same CFs twice produces two distinct versions. There is no separate dataset object that versions hang off.

Versioning — Each version is its own identifier and its own record, and a series is on chain: it is keyed by the assembler's DID plus the manifest id, and the contract assigns a monotonic version number starting at 1. There are getters for a series' latest version and its count, so "which supersedes which" is answerable on chain. Separately, a version's metadata document may carry a previousDatasetId — but that link is written by the publishing SDK as off-chain attribution, is absent from the published schema, and the indexer treats it as enrichment.

Manifest — The off-chain file describing a version's contents. The chain records a manifest id, a URI and a hash, never the data.

Merkle root — A single hash committing to the whole contributor-and-share list for a version. An individual claim verifies against it, so every entry does not have to live on chain.

Lineage — Recorded derivation. Two separate graphs, both with one edge type (derived_from): dataset version to previous version, and CF to parent CF. Membership — which CFs are in a version — is not lineage; it is a different query.

Provenance — The broader question lineage answers in part: for a served dataset, which contributions it contains and who made each of them. Where lineage is the recorded edges, provenance is what you can reconstruct from them plus membership.

Ownership and revenue

Tokenized ownership — Ownership of a dataset version as ERC-1155 shares, one token id per version.

Shares — Ownership units in one dataset version. A version fixes its total at assembly and transfers do not change it. Shares are transferable; there is no burn path — the registry does not expose one.

Claim — The act of minting the shares a version's Merkle root already committed to you. Shares start unclaimed, so an approved contributor's balance is zero until they claim — and claiming late costs nothing, because distributions divide by the assembled total rather than by shares minted so far.

Grant — An on-chain record authorising one subject to access one dataset version. It names a dataset and a subject DID, never a CF, and carries an optional expiry — zero means perpetual — plus a status: ACTIVE or REVOKED.

Royalty — Revenue paid in for a dataset version and distributed across its shares. Any standard ERC-20 or native ETH, accounted per token, up to ten distinct tokens per dataset. Claiming is permissionless — anyone may submit one — but the funds route to the DID's current owner.

Platform fee — A governed cut taken off each distribution before holders divide the rest, in whatever token that distribution carried.

Transfer — Moving shares between addresses. Revenue distributed while you held a share stays yours; revenue after the transfer accrues to the new holder.

Storage and access

Access control — Deciding who may read which dataset version. The authorisation half is on chain and live: a grant names a dataset version and a subject DID. The key-delivery half — handing that subject a decryption key rather than publishing one — is the undeployed access-control service, so treat it as the intended design and not as something running.

Storage — The protocol mandates no backend. It anchors a hash and a URI, and several schemes resolve: Arweave, Filecoin, IPFS and cloud object storage. Cloud storage is a primary custodian in that arrangement, not a cache in front of one.

Serving — Delivering a payload, addressed by the hash and URI the record anchored. Note what is not in that sentence: gateway reads are unauthenticated, so serving is not the layer that decides who may read. Access control is, and confidentiality is meant to come from encryption — see both entries here for what is actually running.

Payload — The data itself, as distinct from the records about it. A CF's metadata document describes its payload as raw, and confidentiality is designed as a dataset-version property rather than a CF one — one key per version, wrapped per grant. That key is designed to be held custodially, and the model is not implemented — no deployed service encrypts a payload or releases a key. A legacy SDK carries a complete proxy-re-encryption backend, which was the earlier answer and was rejected rather than deferred; see Access Control.

Not built

Both of these are recorded because they shape where the protocol is going, and neither exists. They are not the only unbuilt things named on this page — payload encryption and key delivery are designed and not running either — but they are the two that are nothing but design, so they get their own section rather than a caveat inside an entry.

TEE (trusted execution environment) — Computing on data without the party computing being able to read it. Not implemented — see Future Directions and Trusted execution environment.

Federated learning — Training across silos where the data stays put and only model updates move. Not implemented — see Future Directions, Wikipedia and McMahan et al..

Token

XNY — The protocol's token, a BEP-20 contract on BNB Smart Chain. See Token Info for the contract and supply, Tokenomics for the allocation, and Token Utility for what it does and does not do in the protocol today.