Architecture

TL;DR XnY Protocol records who contributed what, composes accepted contributions into versioned datasets, and turns a contributor's place in one into transferable ERC-1155 shares that revenue is divided against pro rata. There is no asset object between a contribution and a dataset version — ownership is shares in a version, and nothing else. The chain carries identities, anchors and ownership; content, access decisions and decryption stay off it.

Architecture

The chain is deliberately thin. Registries hold identifiers, hashes and anchors. Each metadataUri locates a public metadata document, and metadataHash fixes that document’s bytes; the document carries the references to the payload. Storage location and access restrictions belong to those referenced artifacts, not to the metadata URI itself. No plaintext payload, keys or access policy are written on-chain.

The four-step flow (end to end)

1. Contribution. A contributor — human or agent — submits work against a Task. It is sealed as a Contribution Fingerprint, bound to their Identity and carrying a validator's signed verdict and quality grade. Every CF references the task it was done for, and the contract rejects a task that does not exist — so attribution resolves upward as CF → Task → Campaign → Frontier with no off-chain bookkeeping.
2. Assembly. Contributions are composed into versioned datasets (Data Assembly). A version records who assembled it and the manifest it was built from, and its datasetId is derived from those two plus a version counter the contract assigns — never from the members. So assembling the same contributions twice produces two different versions, and there is no dataset object that versions hang off.
3. Ownership. Contributors claim their share of a dataset by proving their contributions belong to it, and Tokenized Ownership is minted as transferable ERC-1155 fractions. Shares are minted to the contributor's DID-Bound Account, so the DID stays attached to the ownership even as the wallet behind that DID changes.
4. Royalty. Revenue paid in for a dataset accrues to its holders through the Royalty Engine. The current implementation preserves prior accrual across share movements using whole-unit and fractional accounting; see the Royalty Engine page for rounding limits and deployment scope. Earnings accrue against the contributor's DID-Bound Account and are paid out, on claim, to the wallet that currently owns that DID.

What lives on-chain, and what does not

This split is the part most often assumed wrongly, so it is worth stating directly.

Access control is decided off-chain, but the chain is not a bystander. Whether a given consumer may read a given dataset version is designed to be evaluated by the off-chain access-control-service — which is deployed in no environment, so no authorised read happens today. Its key delivery is a custodial data encryption key, one per dataset version, wrapped per grant; the proxy re-encryption that page-length descriptions of this system used to feature was rejected in September rather than deferred, and Access Control is the page that carries both. What the chain holds is the set of necessary conditions — that a grant exists, for which dataset and subject, when it expires, and whether it has been revoked. The service reads that anchor and fails closed: a grant that is missing, not ACTIVE, or past its expiry is refused. So the chain can withdraw access but cannot by itself confer it; the policy evaluation, the credential and the keys never touch it.

Note who writes that anchor. The dataset owner does, through the Owner SDK — every direct write requires the caller to own the dataset version, and those are the only writes deployed. The access-control-service only reads it.

Key components at a glance

• Identity and DID-Bound Accounts — a DID is the stable identity that contributions, shares and royalties attach to. Its DID-Bound Account is a contract wallet deployed once per DID, whose control is read from the DID registry at call time rather than stored, so rotating the DID's owner moves the wallet with it and needs no migration.
• Frontier, Campaign, Task — the hierarchy work is defined in. One registry holds all three because they share a shape: an identifier, an owning DID, and a metadata hash with a URI.
• Contribution Fingerprint (CF) — the atomic, signed record of who did what, when, and with what evidence. Its kind is a sample, a label, an amendment or a validation. A CF's anchored content is immutable: metadataHash fixes what was contributed, and a correction is a new CF referencing the old one rather than an edit to it. Review state is not — a validator writes the verdict and grade onto the CF, and which parent kinds an amendment may reference is policy the frontier enforces off-chain, not an on-chain invariant.
• Dataset versions — compose CFs into versioned datasets with provenance you can query.
• Tokenized ownership — ERC-1155 fractions over a dataset, claimed against a Merkle proof that the claimant's contributions are in it, and minted to their DID-Bound Account.
• Royalty engine — accounts for revenue per version and token, with transfer callbacks that preserve prior accrual in the current implementation. Integer rounding limits are described on the Royalty Engine page.
• Access control and grants — a grant is an off-chain credential whose minimal facts are anchored on-chain, so it can be revoked at the source. There is no policy language, and the service that would check a grant and release a key is deployed in no environment.

How to acquire ownership (short)

• Contribute. Submit samples, labels, amendments or validations. When a contribution is accepted and published as a CF, it counts toward the share you can claim in any dataset that includes it.
• Claim. Prove your contributions belong to a dataset version and the corresponding fractions are minted to your DID-Bound Account.
• Transfer. Fractions are ERC-1155 tokens and can be moved. Transfers are intended to move future royalty entitlement while preserving prior accrual; the Royalty Engine page explains the current accounting limitations.

Where to start

• Understanding the record: Contribution Fingerprint → Identity → Data Assembly → Tokenized Ownership Proofs → Royalty Engine.
• Seeing it live: the Lineage Explorer renders the same records, with the block each one came from.