Skip to main content
Trace is live on staging and production. Write access to both requires onboarding: contact our team to get a provider scope and API keys. Reads are public.

​
What is Trace?

Trace is the DATA Foundation’s data provenance and audit layer. Data providers send normalized metadata about the content they handle (content hashes, perceptual hashes, contributor consent, KYC signals, and capture/upload behavior) to the DATA Foundation, which assigns each record a global data_id, stores an append-only metadata history, and exposes public audit views over the whole dataset. The result is a portable, queryable, verifiable record of where data came from and under what terms it was contributed, across every provider that integrates, not just one.

​
Trace on Sui

Trace has registered 250M+ contributions since launch, and it’s joining the Sui stack. Sui brings the other pieces Trace needs to grow into the data layer for AI, end to end:
  • Walrus: storage for the underlying data. Walrus becomes the default storage layer for DATA Foundation apps.
  • Seal: dynamic access control over who can use the data.
  • Nautilus: verifiable off-chain compute, like inference in TEEs.
With sourcing, access control, processing, and inference on the same stack, Trace’s audit layer can prove and verify every step. That gives more depth and weight to the metadata Trace stores, and makes Trace a source of truth for AI data.

​
The Trace Schema

Every provider maps its own payload onto a single shared shape, the Trace Schema (schema_version: trace-v1.0), and includes its full original payload under provider_payload so no provider-specific detail is lost. The normalized fields are the portable contract that the Trace frontend, audit flows, and other providers all rely on. The schema covers:
  • file: content hash (content_sha256), MIME type, media category, perceptual hashes (phash64, dhash64, ahash64, keyframe hashes), and non-PII capture/upload behavior signals.
  • user / contributor: KYC status and country, tax status, account verification status, and the exact Terms of Service / Privacy Policy versions, hashes, and URIs the contributor accepted.
  • app: platform name and legal entity behind the integration.
  • timestamps: when the content was captured, uploaded, and occurred.
  • attestation: payload hash and an optional provider signature for independent verification.
  • provider_payload: the provider’s full original public payload.

​
How Providers Integrate

Integration is a REST flow keyed by an API key and provider scope, no SDK required.

Integration Guide

The complete write, read, search, and scoped-group API, the Trace Schema, and limits/retry behavior.

Become a provider

Reach out to get a provider scope and API keys.
A provider:
  1. Receives a provider scope (e.g. X-Provider: kled) and an API key.
  2. Registers records in batches via the webhook endpoint, sending normalized Trace fields plus its full original payload.
  3. Submits metadata updates over time as KYC, consent, or other mutable fields change: each update is the full latest state, independently verifiable.
  4. Sets its active Terms of Service and Privacy Policy through the provider policy endpoint.
Reads, search, stats, feeds, and scoped-group summaries are public audit views keyed by the global data_id, with provider available as an optional filter.