Key Concepts

The terms below are the ones the contracts use. Where a value is an enumeration, its members are listed exactly as they are defined on-chain.

How they refer to one another:

Four edges are worth reading twice. The dashed one is not a stored reference: a dataset version records a contributors Merkle root and a share cap, and no contract holds the list of fingerprints behind it — the link is proven at claim time, not looked up. Share balances are what a royalty is paid against, which is why ownership and royalty are joined rather than two things hanging off the same dataset: each deposit is divided by the version's fixed total shares from assembly — not by the shares minted so far, so claiming late is intended to forfeit nothing — and every balance then draws its slice. Every transfer notifies the engine, so a balance that moves takes its future earnings with it while what it already accrued stays behind. And the two claim edges are not gated to the person owed: claimDatasetShares and claimRoyalty are both open calls, with the recipient derived from the DID rather than from the caller.

Where work is defined

• Frontier — a top-level data domain. Campaigns, tasks and everything downstream roll up to one.
• Campaign — a collection effort inside a frontier: what data is wanted, and the tasks that gather it.
• Task — the unit of work a contribution is made against. One registry holds all three, because they share a shape: an identifier, an owning DID, and a metadata hash with a URI.
• Task type — SUBMISSION (collects new contributions) or VALIDATION (reviews existing ones).
• Execution — HUMAN or AGENT: who the task expects to do the work.

Neither is stored in the task record, so both are read from the task-created event rather than from a getter — and they are not read the same way: task type is an indexed topic and can be filtered on, while execution travels in the event data and has to be decoded.

Identity

• DID — the stable identity a contribution, a share and a royalty claim all attach to.
• DID-Bound Account (DBA) — one contract wallet per DID, holding that DID's shares. Its control is read from the DID registry at call time, so rotating the wallet behind a DID moves the account with it and needs no migration. See Identity.

Contribution

• Atomic contribution — the smallest unit of work. Its kind is one of SAMPLE, LABEL, AMENDS or VALIDATION.
• Contribution Fingerprint (CF) — the on-chain record of one atomic contribution: what was contributed (a content hash), who contributed it, which task it was done for, and the validator's assessment. A CF references a task, and the contract rejects a task that does not exist — so CF → Task → Campaign → Frontier resolves on-chain. See Contribution Fingerprint.
• Parent CF — a CF may reference an earlier one. Corrections do not edit the original; they are new CFs pointing back at it. Which kinds may reference which parents is policy the frontier enforces off-chain, not an on-chain rule.
• Metadata hash and URI — metadataHash fixes the content; metadataUri says where to find it, by convention arweave:// or ipfs://. Only the hash is attested, which is what lets a broken location be repaired without weakening the guarantee.

Validation

• Verdict — PENDING, APPROVED or REJECTED, written onto a CF by a validator.
• Quality grade — NONE, then D, C, B, A, S in ascending order.
• Validator — an identity permitted to submit that assessment. Review state is written onto the CF; the contributed content it refers to is not changed.

Assembly

• Dataset version — a curated, versioned set of contributions. It records who assembled it, the manifest it was built from, its version number, the contributors commitment and the total shares it may ever issue. See Data Assembly.
• Manifest — the description of what the version contains. Its id is on-chain; the manifest itself is not.
• Contributors Merkle root — a commitment, fixed at assembly, to every contributor and the share each is owed. Claiming is proving membership in it.

Ownership and royalty

• Ownership fraction — an ERC-1155 balance. One token id per dataset version; a holder's balance is their share of it. See Tokenized Ownership Proofs.
• Claim (shares) — the act of turning a proof into shares. Once per DID per dataset, minted to that DID's account.
• Distribution — revenue paid in for a dataset, in the native currency or an ERC-20. The call is open: anyone may pay in.
• Platform fee — a governed cut taken off a distribution before holders divide the rest.
• Claim (royalty) — earnings accrue against a DID's account and are paid, on claim, to the wallet that currently owns that DID. See Royalty Engine.

Access

• Grant anchor — the on-chain record that a grant exists: which dataset, which subject, when issued, when it expires, and whether it is still active.
• Revocation status — a grant's status on that anchor. Revoking it withdraws access at the source, whatever credentials are already in circulation.
• Access credential — a verifiable credential signed by the dataset owner naming the subject, the dataset and the grant. Checked alongside the anchor, never instead of it.
• Grant — how a consumer becomes authorised to read a dataset version: a credential the owner signs off-chain, with its minimal facts anchored on chain so it can be revoked at the source. The anchor alone does not release a key. Proxy re-encryption was the earlier answer to key delivery and was rejected; custody is. See Access Control.