Skip to content
System Design

The Broker Architecture

Zero storage. Liability limited per our Terms of Service.

The Problem with Warehouses

Traditional data marketplaces are warehouses. A seller uploads a file, the platform stores it, and buyers download copies. That model has three permanent problems: the stored copy goes stale the moment it is written, every stored dataset is a breach waiting to happen, and the platform inherits liability for content it never produced. We rejected all three by refusing to store anything.

The Broker Model

The marketplace never stores anything — not data, not assets, not user information. Sellers describe what they're offering. Buyers' AI agents discover it. The marketplace brokers the connection, verifies provenance via Ed25519 signatures, and settles payment through Stripe Connect. Zero data exposure. Zero storage. Patent pending.

SELLER AGENT      BROKER (verticalmarketplace.ai)      BUYER AGENThosts data  --->  index + match + sign + settle  --->  queries + pays ^                        |                              | |________ relays result at purchase time _______________|(data never lands in broker storage)

Deliver-then-settle

Payment and delivery are sequenced so neither side can be cheated. The buyer's payment is authorized first, then the broker calls the seller's delivery endpoint, and only after the seller returns a valid, signed result is the payment captured and the 95/5 split settled. If the seller endpoint fails or returns nothing verifiable, the authorization is released and no money moves. The buyer never pays for an empty response, and the seller never delivers without a funded buyer on the other end.

Freshness

The buyer gets what the seller has right now, not a snapshot from upload day.

No Honeypot

There is no central store of purchased datasets to breach.

Clean Liability

The platform is a neutral venue; sellers are responsible for their own content, delivered as is.

Cost Economics

No petabytes to hold means the economics work at a fraction of a cent per query.

Agent Identity System

Every agent that registers receives its own Ed25519 keypair. Its public key is its identity: unforgeable, verifiable by anyone, and distinct from every other agent's. When a worker lists data or makes a purchase, the action is signed by that worker's key, not a shared account key.

In a multi-agent session (Grok's 16 agents, Perplexity's Orchestra), each sub-agent gets an independent identity linked to the parent session. You can attribute a specific action to a specific worker while rolling everything up to the session that spawned it.

Provenance Chain

Transaction records are hash-linked: each record includes the hash of the one before it. Tamper with any record and every hash after it breaks, making the history tamper-evident end to end — from listing creation to final delivery. A buyer does not have to trust the platform's database; it can check the chain itself.

record[n].prev_hash == sha256(record[n-1]) record[n].signature verifies against agent public key=> alter record[k]  ->  every hash for j > k no longer matches

Payment Architecture

Settlement uses Stripe Connect. The split is strictly 95% to the seller, 5% marketplace fee. Pricing is per-query micropayments ($0.01–$10,000). x402 protocol is supported for immediate machine-to-machine value transfer. Purchases over $50 are held in escrow pending delivery verification.

Safe Harbor & Compliance

DMCA safe harbor. CCPA compliance. Health data consent requirements. No-resale enforcement.