Identity

Identity primitives

A DID is the stable identifier recorded for contributors, validators and owners. The protocol resolves its current owner through the external DID registry. A DID-Bound Account (DBA) holds ownership shares and reads that owner when authorizing wallet operations. A task can distinguish human and agent work, but the protocol has no separate agent registry or implemented account-linking flow.

Verification levels (progressive trust)

The proposed ladder of assurance would let tasks request different identity checks:

• Pseudonymous: proves control of a key. Default for most contributions.
• Linked accounts: optional links (email, GitHub, ORCID) for continuity and recovery.
• Verifiable Credentials (VCs): third-party attestations — a license, an affiliation — for expert tasks. Note what a VC is in this system today: the one credential it defines is an access grant, issued by a dataset version's owner to a consumer, carrying a grant id, a dataset, allowed actions and an expiry. Nothing issues, holds or checks an attestation about a person.
• KYC/KYB: legal identity for regulated datasets or specific payout policies.

The ladder is a design for how much assurance a task can demand. The protocol does not currently read a verification level anywhere — nothing on-chain or in the services gates on one.

Enrollment & linking

DID registration and wallet binding belong to the external DID system. Connecting email or social accounts and adding personal VCs or KYC are planned capabilities, not steps available in this protocol today.

There is no separate royalty payout-address setting: claimRoyalty resolves the DID's current owner and pays that wallet. Shares remain in the DBA when the external DID owner changes; this page does not prescribe that external system's enrollment or recovery procedure.

The identity and share-holding account stay the same when the owner changes. Control of the account and the destination of future royalty claims follow the current owner wallet.

Signing & binding CFs

The contributor DID records who supplied the work. An allowlisted validator DID attests to the CF payload, verdict and grade with an EIP-712 signature verified against that DID's owner. The contributor is not required to provide that validator signature.

The submitter may be anyone, including a relayer that pays gas; sending the transaction does not make it the contributor or validator. The batch submission interface uses one batch-scoped validator signature, not an aggregator co-signature.

These are three roles, not three required people. Attribution names the contributor; the validator signature authorizes the submission; the transaction sender transports it.

Privacy modes & selective disclosure

Pseudonymity is the default, and it is the whole of what this layer currently provides: a DID proves control of a key and says nothing else about who holds it. The rest of this section describes an intention. Requiring a claim such as “licensed clinician” is declarable and not enforceable. A campaign's metadata carries a required qualification block naming what it wants — crs_min for a minimum reputation score, plus skills, credentials and geo — and a task may override it through qualification_override, not through a second qualification. Both are in the published 1.0 schemas. What is missing is everything on the other side: no credential type carries such a claim, nothing issues or holds one, nothing checks the block, and the indexer keeps it as opaque JSON without decoding it. Confidentiality of the payload is not this layer's to promise either, and is not running: see Access Control for what a grant does and does not currently get you.

Where identity is used in access

An access request is designed to be checked against the DID that opened the session and the DID named as the subject of the access credential — the two must match. Verification level is not itself an input to that check. See Access Control for the full sequence.

Security practices

Use hardware wallets for high-value operations; enable 2FA/TOTP on dashboards; apply least-privilege keys for agents; follow a rotation/compromise playbook.

Invariants (must hold)

• CFs carry validator attestations: the signature binds the contributor and CF payload; contributor, validator and transaction submitter are separate roles.
• Minimal disclosure, by having nothing to disclose: a DID is a key, not a name, and the protocol asks for no attribute beyond it. This holds because there is no disclosure mechanism rather than because one is configured narrowly.
• Auditability, narrowed to what is auditable. Account links — email, GitHub, ORCID — appear on the ladder above as a design and have no implementation, so there is no link history to audit. Owner rotation lives in the DID registry, which is a contract outside this repository: the protocol's own interface for it declares only ownerOf, so what it emits is not this documentation's to promise.

Interfaces

• To CF: contributor attribution, validator signature verification, and a permissionless submitter.
• To Access Control: the DID that opened the session, and the DID named as a grant's subject.
• To Royalty: the DID a claim is made for, and the wallet that currently owns it.

Next up → Data Assembly