Tokenized Ownership Proofs

What this page covers. Who owns what, and how that is proved. Ownership attaches to a dataset version and is held as transferable ERC-1155 fractions. A contributor does not receive shares automatically — they claim them, against a proof recorded when the dataset was assembled.

What you can own

Ownership is per dataset version. Each one is a single ERC-1155 token whose id is the dataset id, and a holder's balance is their fraction of it. The number of shares a version can ever issue is fixed when it is assembled, and the registry will not mint past it.

There is no separate ownership token for an individual Contribution Fingerprint. A CF is what earns you a share of the datasets that include it; it is not itself an owned asset.

Claiming your share

When a dataset version is assembled, it records a contributors Merkle root: a commitment to every contributor, how many shares each is owed, and which of their contributions that figure was computed from. Claiming is proving you are in that commitment.

Three properties of that claim are worth knowing:

• Once per contributor, per dataset. The registry records that a DID has claimed and refuses a second attempt, so a valid proof cannot be replayed against the same dataset.
• The proof is bound to where it is verified. The leaf commits to the chain id and the verifying registry's own address alongside the contributor, the share amount and the dataset. A proof produced for one deployment therefore verifies nowhere else.
• Shares are minted to the DID-Bound Account, not to whatever wallet submitted the transaction. Ownership stays attached to the DID, and rotating the wallet behind that DID does not move it.

Transfers

Fractions are ordinary ERC-1155 tokens and move like them. What is not ordinary is the accounting: every transfer notifies the Royalty Engine, which settles sender and receiver against their pre-transfer balances.

In the current implementation, a transfer moves future earnings, not accrued ones: transfer accounting retains both whole-unit and fractional earnings. See the Royalty Engine limitations for rounding behavior and deployment scope. Shares transferred to a non-DBA address also have no royalty claim path for that address.

Claiming is the exception, and it is deliberate. A claim is not a transfer from another holder — it materialises shares that were already counted in the dataset's total from the moment it was assembled. The intended accounting backdates the allocation to assembly, rather than starting accrual at minting. Actual payouts remain subject to rounding and the royalty accounting limitations.

What this page does not describe

The protocol has no escrow, no challenge or dispute window, no ownership receipts as a separate artifact, and no secondary market. Ownership is the ERC-1155 balance; the proof of it is the chain.

Interfaces

• In: a dataset version from Data Assembly, carrying the contributors root and the total share count.
• Out: balances that the Royalty Engine reads, and a settlement callback on every movement.
• Identity: shares are held by the DID-Bound Account of the owning DID — see Identity.

Invariants

• A dataset cannot over-issue. Minted supply is capped by the total the version was assembled with.
• A claim is single-use. One successful claim per DID per dataset, enforced on-chain.
• A proof does not travel. It is bound to the chain and the registry that verifies it.
• Transfers preserve prior accrual in the current implementation. Claimable amounts remain subject to integer rounding; deployment versions are separate from the repository implementation.