RAMP for Exchange Operators

The Opportunity

Resource providers need a transaction layer but don’t want to build one. Courts don’t want to run billing APIs. Publishers don’t want to negotiate with every AI company. Hospitals don’t want to handle metered access to imaging data. Patent offices don’t want to build per-query pricing.

You solve this by running an Exchange: aggregate their catalogs, handle discovery, pricing, and transactions, and earn a margin on every access. This is the aggregator pattern — the same model that drives SSPs in ad-tech, clearinghouses in finance, and distributors in publishing.

RAMP was validated across 18 real-world scenarios spanning 10 industries. The same protocol works for all of them:

Exchange Type	What You Aggregate	Providers	Example Operators
Media exchange	News articles, podcasts, video	Publishers	SSPs, media companies
Academic exchange	Journal articles, preprints	Publishers, repositories	Elsevier, OpenAlex
Legal exchange	Court filings, legislation, patents	Courts, patent offices	PACER aggregator, EUR-Lex
Credit/financial exchange	Credit reports, market data	Data providers	D&B resellers, MarketData
Medical data exchange	Clinical data, imaging	Hospitals, research institutions	TCIA, imaging exchanges
Government data exchange	Property records, business filings	County/state agencies	CoreLogic, ATTOM

The value proposition is the same regardless of domain: providers get revenue from AI agents without building anything, agents get standardized access without bespoke integrations, and you keep a margin on every transaction.

What You Deploy

You deploy an Exchange Node — a Go service that handles three API calls:

DiscoverResources — AI agent asks “what’s available at this URL and how much?” Your Exchange looks up the provider’s catalog and returns offers with pricing.
ExecuteTransaction — AI agent says “I’ll take it.” Your Exchange checks the buyer’s balance, logs the transaction, and returns a signed URL.
ReportUsage — AI agent reports what it did with the content. Mandatory. You track compliance.

That’s the whole protocol. Three RPCs. Your billing adapter plugs in where Authorize(buyer, amount) and Record(transaction) are called.

Unit-Agnostic Metering

A media exchange meters in tokens. A legal exchange meters in pages. A medical exchange meters in studies. A geospatial exchange meters in sq_km. Same protocol, different units.

RAMP pricing uses three fields: unit_cost (price per unit), unit (what’s being metered), and estimated_quantity (how much the agent will consume). No assumption about what’s being metered:

Exchange Type       Metering Unit       Example unit_cost
──────────────────────────────────────────────────────────────
Media                  tokens              $0.00003/token
Legal                  pages               $0.50/page
Academic               tokens              $0.05/article (flat)
Medical imaging        studies             $2.00/study
Credit/financial       records             $5.00/record
Geospatial             sq_km               $0.10/sq_km
Streaming (audio)      minutes             $0.02/minute
Pharma                 interaction_pairs   $0.001/pair

Usage reporting follows the same pattern: consumed_quantity + consumed_unit. Your Exchange MUST support these fields on all offers and MUST NOT assume tokens as the default unit.

Extension Profiles

Your Exchange declares which domain profiles it supports in its manifest. This tells Brokers and agents what kind of resources you handle:

// Media exchange
{ "supported_profiles": ["ramp-news-v1"] }

// Academic exchange
{ "supported_profiles": ["ramp-academic-v1"] }

// Legal exchange
{ "supported_profiles": ["ramp-legal-v1"] }

// Multi-domain exchange
{ "supported_profiles": ["ramp-news-v1", "ramp-academic-v1"] }

Agents declare which profiles they understand. The Broker routes queries to Exchanges that support the requested profile. An academic research agent requesting ramp-academic-v1 is routed to your Exchange if you declare that profile.

Profile conformance means your Exchange sets the required ext fields defined in the profile spec and validates them against the profile’s JSON Schema:

Profile	Scope	What It Means for Your Exchange
`ramp-news-v1`	News, podcasts, broadcasting	Set IPTC subject codes, correction status, podcast metadata in offer ext fields
`ramp-academic-v1`	Scholarly articles, preprints	Set DOI, OA status, version lifecycle in offer ext fields
`ramp-legal-v1`	Legislation, case law, patents	Set jurisdiction, amendment chains, ELI/ECLI in offer ext fields

A Exchange MAY implement zero, one, or multiple profiles. You can start with one domain and expand.

If You’re an SSP: How RAMP Maps to Your Infrastructure

If you operate an SSP or ad exchange, RAMP maps directly to your existing concepts:

Ad-Tech Concept          →  RAMP Equivalent
─────────────────────────────────────────────
SSP / Exchange           →  Exchange Node
Publisher                →  Resource Provider
ads.txt                  →  ramp.json (authorized sellers)
Bid Request              →  ResourceQuery
Win Notification         →  TransactionRequest
eCPM                     →  unit_cost (effective cost per unit)
Impression               →  Content access (signed URL)
Viewability Report       →  Usage Report

You already have:

Provider relationships and contracts
Billing infrastructure (invoicing, prepaid, credit)
CDN access for provider domains
Revenue share agreements

RAMP adds:

A Exchange service (Go binary, stateless, horizontally scalable)
An edge function deployed to provider CDNs (bot blocking + signed URL verification)
A resource catalog built from provider rsl.txt files and CMS integrations

Provider Onboarding

For each provider, you:

Run domain verification (ACME-based) to prove provider domain ownership and provision signing keys
Ingest their rsl.txt to build a resource catalog with pricing
Configure their pricing tier (the rsl.txt rate is a ceiling; your private rate can be lower)
Authorize catalog_contributors — third-party verification vendors the provider permits to push attestations for their content
If applicable, deploy the RAMP edge function to their delivery endpoint (CDN, API gateway, PACS server) for signed URL verification
Done. Their content is now available to AI buyers through your Exchange

Providers deploy nothing themselves in the managed model. You manage everything. This is the Exchange-Managed deployment model. Some providers (large publishers, data vendors) may prefer to manage their own delivery endpoint — the protocol supports both.

Buyer Onboarding

AI companies register via your existing account management or a self-signup API:

Enterprise: Out-of-band key exchange during contract signing. You register their Ed25519 public key.
Self-signup: AI agent registers via API with their public key manifest. Per-request billing only (no subscription).

You don’t need bilateral deals with every AI company. Any agent that speaks the RAMP protocol can buy from your Exchange.

Requester Verification

Every incoming request carries a Requester message with an Ed25519 signature. Your Exchange MUST verify this identity before processing any query or transaction.

Signature Verification

Extract the domain from the Requester message
Fetch the requester’s public key from {domain}/.well-known/ramp.json (role=ROLE_AGENT), selected by keyid from public_keys
Verify the RFC 9421 HTTP Message Signature (alg=ed25519) on the request — it covers the HTTP request components (@method, @target-uri, content-digest, and the signature parameters), so the request body (the serialized Requester/query) is bound via content-digest. There is no in-message body-tuple signature.
Reject the request if verification fails — no fallback, no degraded mode

Key caching is recommended. Fetch keys with a TTL and re-fetch periodically to handle key rotation without per-request overhead.

Delegation Verification

When a request includes a Delegation message (nested inside Requester), your Exchange verifies the JWT chain:

Verify the JWT chain from the base64url token in the Delegation message
Verify the authority JWT is signed by the Ed25519 key published at {principal_domain}/.well-known/ramp.json (role=ROLE_AGENT)
Verify each child delegation JWT’s signature (each signed by the key its parent named in cnf)
Verify holder binding — the key that signed the request (RFC 9421) MUST equal the key named in cnf (cnf.jkt); reject with DENIAL_REASON_DELEGATION_INVALID if they differ. This is mandatory: it is what makes a stolen token unusable, so a token possessed without its signing key grants nothing.
Evaluate the grant’s registered claims — scope restrictions, spend caps (max_spend_cents), access caps (max_accesses) — and confirm they cover the request (URI access is gated through scopes). For the optional biscuit-v3 profile, this is evaluating the token’s check blocks; for the default JWT, it is checking the registered claims along the cnf chain.
Check expires_at against current time — reject expired tokens with DENIAL_REASON_DELEGATION_INVALID
Optionally check revocation_uri for high-value transactions

This verification is entirely offline — no callback to the principal is required.

Forwarding Chain Verification

When the request carries more than one RFC 9421 HTTP Message Signature, it has passed through one or more intermediaries (e.g., agent to broker to your Exchange). Each forwarding party adds its own labeled signature to the request, covering the request plus the prior hop’s signature; the ordered stack of signatures in the HTTP headers is the forwarding chain. Verify every signature on the request:

For each signature, fetch the signer’s public key from {signer-domain}/.well-known/ramp.json (role=ROLE_AGENT), selected by keyid
Verify each RFC 9421 signature, proving the intermediary handled the request and the chain was not reordered, dropped from, or inserted into (any such tampering breaks a downstream signature)
Enforce max_intermediary_hops by signature count — reject requests whose forwarding-signature count exceeds your published limit

Scope-Based Catalog Filtering

After verifying identity and delegation, filter your catalog by the requester’s declared scopes. Only resources matching the scopes are returned in the DiscoverResources response.

For resources that exist but fall outside the requester’s scopes:

Existence is sensitive: Silently omit the resource. Do not reveal it exists.
Subscription/scope-gated (the usual case): Return OFFER_ABSENCE_REASON_SCOPE_INSUFFICIENT in the OfferGroup.absence_reason field so the requester gets an actionable diagnostic — the resource exists but their scopes/subscription don’t cover it. Applies to enterprise RBAC and public marketplace subscriptions alike.

Subscription Quota Signaling

When the requester holds a subscription (identifiable via the requester’s delegation and/or subscription scopes — not via billing_ref, which only attributes cost), populate SubscriptionQuotaInfo entries on offers and transaction responses. This proactive quota signaling lets agents track remaining allowance and avoid committing to transactions they cannot complete. Track max_accesses and quota_period from the Delegation message when present.

New Denial Reasons to Implement

RAMP defines three identity-related denial reasons your Exchange MUST return when appropriate:

Denial Reason	When to Return
`DENIAL_REASON_QUOTA_EXCEEDED`	Subscription access count exhausted for the current `quota_period`
`DENIAL_REASON_DELEGATION_INVALID`	Delegation token missing, unverifiable (broken chain linkage or holder-binding mismatch), expired (`expires_at` in the past), or it widens scope beyond its parent
`DENIAL_REASON_SCOPE_INSUFFICIENT`	Requester’s scopes do not cover the requested resource (transaction-time denial)

For the full identity model specification — Requester fields, the JWT chain, scope format, and key management — see Authentication.

Attestation Verification

Your Exchange verifies ResourceAttestation signatures at catalog push time. When a provider or verification vendor pushes resource metadata via CatalogService.PushContent, your Exchange:

Fetches the signer’s public key from https://{verifier}/.well-known/ramp.json (public_keys, selected by kid)
Verifies the Ed25519 signature over JCS-canonicalized claims
Checks that the verifier is either the provider domain (Level 1 self-attestation) or a vendor listed in the provider’s catalog_contributors (Level 2 third-party attestation)
Rejects attestations from unauthorized contributors

This prevents unauthorized parties from injecting false claims into your resource catalog.

Dispute Resolution

Your Exchange handles DisputeTransaction RPCs from agents. The dispute system operates in three tiers:

Tier	Scope	Volume	Response Time
Tier 1 — Automated	Delivery failures, content hash mismatches, signed URL expiry	~99% of disputes	< 1 second
Tier 2 — Rule-Based	Ambiguous evidence, delivery says 200 but content is suspect	~0.9% of disputes	< 24 hours
Tier 3 — Investigation	Aggregate fraud patterns, systematic abuse	~0.1% of disputes	Case-by-case

report_id generation: When an agent calls ReportUsage, your Exchange returns a report_id in the UsageReportResponse. This report_id is required on every DisputeRequest — it proves the agent fulfilled its reporting obligation before disputing. Your Exchange rejects disputes without a valid report_id.

Delivery logs are the authoritative evidence source. They cannot be fabricated by the agent and provide independent verification of delivery status, response size, and timing.

Exchange Manifest and Health Checks

As an Exchange operator, you are responsible for two additional capabilities:

Exchange Manifest — Your Exchange serves a machine-readable self-description at /.well-known/ramp.json (role=ROLE_EXCHANGE). This tells Brokers and agents what your Exchange supports (pricing models, delivery methods, accepted verifiers, endpoints) without trial-and-error, and publishes your offer-signing keys inline in public_keys. The manifest includes:

base_currency (ISO 4217 code) — the currency for all unit_cost values. Enables cross-exchange price comparison by the Broker. A legal exchange quoting in EUR and a media exchange quoting in USD can be compared when both declare their currency.
supported_profiles — domain extension profiles your Exchange conforms to.

The manifest is generated from your configuration at startup and served as a static JSON document. See Exchange Manifest.

Health Checks — Your Exchange exposes three health layers: gRPC health (grpc.health.v1.Health/Check), HTTP liveness (/healthz), and HTTP readiness (/readyz). Brokers use gRPC health probing to make structured routing decisions — they can distinguish an Exchange with a stale catalog from one with billing down. Kubernetes uses the HTTP endpoints for pod lifecycle management. See Health Checks.

Revenue Model

Revenue depends on your exchange domain and the value of the resources you aggregate:

Media exchange:
  Provider sets price:  $0.05/article (tokens)
  AI Agent pays:        $0.05/article
  You keep:             Your standard rev-share margin

Legal exchange:
  Provider sets price:  $0.50/page (court filing)
  AI Agent pays:        $0.50/page
  You keep:             Your standard rev-share margin

Credit exchange:
  Provider sets price:  $5.00/record (credit report)
  AI Agent pays:        $5.00/record
  You keep:             Your standard rev-share margin

Medical imaging exchange:
  Provider sets price:  $2.00/study (MRI scan)
  AI Agent pays:        $2.00/study
  You keep:             Your standard rev-share margin

Higher-value resources mean higher absolute margins per transaction. A credit exchange processing 2K reports/day at $5.00 average = $10K/day gross = $3.6M/year. A media exchange processing 10K articles/day at $0.05 average = $500/day gross = $182K/year. Infrastructure costs scale with RPS, not transaction value — approximately $40/day at 10K RPS.

Multi-Exchange Competition

AI agents can use a Broker to query multiple Exchanges and compare prices — like header bidding but for content. This means:

Competitive pressure keeps your margins honest
Premium content commands premium pricing (quality signals in offers)
Subscription deals give your providers an advantage (zero marginal cost for the buyer)
base_currency in your manifest enables cross-exchange price comparison even across currencies

Technical Integration

NFR targets: 10K RPS, under 100ms p99 latency, under $0.00005/transaction infrastructure cost.

Billing adapter interface (your integration point):

type BillingAdapter interface {
    Authorize(ctx, buyerID, amount) → (ok, error)
    Record(ctx, transaction) → error
    CheckSubscription(ctx, buyerID, providerGroup) → (sub, error)
}

Implement these three methods against your existing billing system. The reference implementation uses DynamoDB; production deployments wire it to their real ledger.

Unit-Agnostic Pricing for Non-Text Resources

RAMP uses a single unit-agnostic pricing model, PRICING_MODEL_PER_UNIT, for all metered resources. Pricing.unit names what is metered, so non-text resources are priced through the same model:

Model	Unit	Use Case
`PRICING_MODEL_PER_UNIT`	`pages`	Court filings, legal documents, PDFs
`PRICING_MODEL_PER_UNIT`	`minutes`	Video, audio, streaming sessions
`PRICING_MODEL_PER_UNIT`	`records`	Database records, credit reports, medical studies

Pricing is unit-agnostic: unit_cost replaces eCPT, estimated_quantity replaces estimated_tokens, and Pricing.unit specifies the metering unit. Your Exchange MUST support these fields on all offers.

Streaming Delivery

RAMP supports DELIVERY_METHOD_STREAMING for real-time connections (WebSocket, SSE, HLS, Icecast). Your Exchange generates a signed URL pointing to a streaming endpoint. The agent connects and receives continuous data. Stream mechanics (heartbeat, reconnection, concurrent connection limits) are managed by the provider, not the protocol.

Streaming transactions follow the same RAMP flow, but the signed URL has a longer TTL (streaming sessions last minutes/hours) and usage is reported in time-based units (minutes, hours).

Next Steps

Review the Exchange design for architecture details
See the Billing Adapter for the integration interface
Walk through the Scenario Walkthrough for a complete transaction trace
Review the Threat Model — it was built from 20 years of ad-tech fraud patterns