The marketplace journey
The Data Exchange console organizes the marketplace around five stages, Discover · Offer · Manage · Earnings · Spend, spanning both sides of a transaction. Underneath every one of them is the same rule: a listing is a signed attestation, provenance-verified for the visitor and again at ingest.
The five stages
| Stage | Who | What it is |
|---|---|---|
| Discover | Buyer | Browse a provenance-verified storefront: search, detail pages, and pagination over the catalog. Every listing shown is verified when rendered. |
| Offer | Seller | Publish an offer, which mints a signed cross-org listing bound to the offer's identity, content fingerprint, reach, scope cap, and validity window. |
| Manage | Seller | Run the grant lifecycle for incoming buyer requests: approve, decline with a reason, or provision. |
| Earnings | Seller | The seller's side of the accrual ledger: credits booked as buyers read. |
| Spend | Buyer | The buyer's side: debits and prepaid balance. |
Two journeys, one handshake
The five stages are two journeys that meet at a handshake. A data product is the thing being offered: the producer prepares and publishes it, the consumer finds and requests it, and the buyer never silently "gets" data.
Figure: the producer defines a product and publishes an offer as a signed listing; the consumer discovers it and places a request; the seller's grant lifecycle returns a terminal status to the buyer. Ceiling: earnings and spend accrue in Compute Units, no live money moves, the take-rate is 0, and an overdraft is flagged, not blocked.
Table equivalent
| Side | Stage | What happens | State (meaning) |
|---|---|---|---|
| Producer | Define product | Typed ports and a contract on the product | neutral |
| Producer | Offer | Publishing mints a signed cross-org listing | verified (green) |
| Producer | Manage | Seller runs the grant lifecycle for incoming requests | candidate (cyan) |
| Producer | Earnings | Credits accrue in Compute Units as buyers read | neutral |
| Consumer | Discover | Browse a provenance-verified storefront, verified when rendered | verified (green) |
| Consumer | Request | A request is placed against a listing | candidate (cyan) |
| Consumer | Terminal status | Pending, declined with a reason, or provisioned, returned to the buyer | candidate (cyan) |
| Consumer | Spend | Debits and prepaid balance in Compute Units | neutral |
The request-to-grant handshake
A buyer does not silently "get" data. The flow is an explicit handshake whose terminal status is reflected back to the buyer:
- The buyer places a request against a listing.
- The seller's cell runs the grant lifecycle.
- The buyer sees the terminal status, pending, declined with a reason, or provisioned, and may re-request after a decline.
Because provenance is checked twice (for the visitor and at ingest) a foreign, tampered, wrong-key, or forged listing never reaches a grant: it is rejected against real cryptography, deny-closed.
Governed by one authoritative deny
The exchange's grant edge is the same canonical governance edge the platform serves from. A revoke on it is the authoritative deny across all three serving faces (the marketplace, Delta Sharing, and the Iceberg REST catalog) so withdrawing access in the marketplace actually stops serving. See the authoritative deny.
Honesty about maturity
Earnings and Spend are the two sides of a signed, hash-chained, double-entry accrual ledger denominated in Compute Units, the accounting of the exchange rather than a payments rail. Every metered read books both sides: a debit at the price the buyer pays and a credit at the seller's share, signed onto one ledger row. No money moves through it, because there is no payout leg. On the default revenue share the whole metered value accrues to the seller, so the platform fee is zero, and a take-rate on priced sales is not implemented. The prepaid balance a buyer draws down lives outside the platform, so no read is refused here for want of funds. Two refusals are enforced: a credit to a blank or unknown seller is refused rather than booked unattributably, and a buyer who is also the seller accrues nothing. See settlement and accrual.
Catalog scale and the open-protocol ecosystem around the exchange are early, and a sovereign product has a weaker network effect by its nature: data that must stay in a jurisdiction cannot pool into one global catalog, which is the thing network effects are usually built on. What the exchange offers instead is post-quantum hybrid trust with offline verification, so a listing is verifiable across an organizational boundary without either side reaching a shared service. That property does not improve with scale, which is why it holds in the deployments where a large catalog is not available. Nothing here is graded, certified, or backed by a reference customer.
Across the deployment matrix
- Single-cell: the storefront, requests, and grants run on the cell.
- Multi-cell: federated product discovery spans cells; each cell verifies listings independently.
- Sovereign / air-gapped: with a site cell, the marketplace runs locally with no cloud in the loop.
- Cloud-enabled: the same journey, with online discovery as a convenience.
Related
- Signed cross-org listings
- Offline verification
- Settlement and accrual
- Data products, the unit being offered.
- The authoritative deny