Skip to content
RAMP Protocol

Role Composition

Roles are compositional, not exclusive

Section titled “Roles are compositional, not exclusive”

RAMP defines four roles via the Role enum in WellKnownManifest:

RoleResponsibility
ROLE_AGENTIssues ResourceQuery / TransactionRequest / UsageReport; signs requests with Ed25519
ROLE_BROKERFans out across Exchanges, compares offers, deduplicates by ResourceIdentity, enforces budget constraints
ROLE_EXCHANGEHolds the resource catalog and pricing, authorises transactions, issues signed retrieval endpoints
ROLE_PUBLISHEROwns the content, declares RSL terms, optionally self-attests resources, serves delivery

A single operator MAY run more than one role, and the protocol is designed so that doing so does not weaken its trust model. Each role authenticates the others cryptographically — the same Ed25519 signature chain that protects cross-operator transactions also protects in-house transactions between roles operated by the same legal entity.

Multi-role operators

Section titled “Multi-role operators”

Operators that already span the demand and supply sides of digital content distribution map naturally onto multiple RAMP roles. Typical patterns:

Operator surfaceRAMP roleWellKnownManifest domain
Agentic product (LLM assistant, copilot, research agent)ROLE_AGENTagent.example.com
Owned-and-operated publishing propertiesROLE_PUBLISHERnews.example.com
In-house exchange monetising O&O supplyROLE_EXCHANGEexchange.example.com
Third-party exchange across non-O&O supplyROLE_EXCHANGEexchange-syndicated.example.com
Discovery / routing layer in front of multiple exchangesROLE_BROKERbroker.example.com

The WellKnownManifest.role field identifies which role a given subdomain holds. A single operator publishes one manifest per role per subdomain, and consumers verify each manifest independently. There is no protocol mechanism that lets one role grant privileges to another role under the same operator — every cross-role interaction goes through the normal signature-verification path.

Why this is safe

Section titled “Why this is safe”

Three properties keep the trust model intact under multi-role operation:

  1. Per-role key separation. Each role publishes its own keys in its own WellKnownManifest.public_keys. An operator’s Exchange key cannot sign messages that an Agent role would accept, and vice versa, because consumers look up keys by (domain, role), not by operator.
  2. Cryptographic transaction boundaries. Every Offer carries an exchange_signature produced by the Exchange (JWS / Ed25519). Cross-role HTTP exchanges (Agent → Broker, Broker → Exchange, Agent → Exchange) are authenticated at the transport layer via RFC 9421 HTTP Message Signatures applied hop-by-hop — each intermediary adds its own Signature header as the request passes through. The IntermediaryHop chain on ResourceQuery records the forwarding path; each hop’s transport-layer signature proves its participation independently of the others. TransactionRequest does not itself carry the hop chain (request auth is RFC 9421); the forwarding path is established at discovery and the Exchange correlates the commit back to the original ResourceQuery via request_id. A Broker run by the same operator as an Exchange therefore cannot fabricate, suppress, or rewrite a hop’s contribution without breaking that hop’s per-hop signature on the wire — which any auditor with access to the Exchange’s request logs can detect.
  3. Independent reconciliation records. Settlement reconciliation uses three independent records (Exchange ledger, CDN access log, UsageReport) that must agree within the published tolerance — see Transaction Flow → Reconciliation via Signed URLs. Collusion between two co-operated roles still has to produce consistent records across all three, which is detectable by any auditor with access to the CDN logs and the dispute record.

In other words: the protocol does not assume that distinct roles are run by distinct operators. It assumes that distinct roles produce distinct, independently verifiable signatures and records. Multi-role operators inherit that property by following the standard manifest discipline.

Implications

Section titled “Implications”
  • An operator that runs both an Exchange and a Broker MUST NOT route every Broker request to its own Exchange when other Exchanges hold matching offers at lower unit_cost. The protocol does not enforce this behaviourally, but the Broker’s offer comparison is auditable from its outbound signed ResourceQuery traffic and the resulting Offers — agents and regulators can verify routing fairness from the wire.
  • An operator that runs both an Agent and an Exchange MUST sign the Agent’s TransactionRequest with the Agent role’s key, not the Exchange’s. Mixing keys is an attestation forgery; the resulting offer trail will fail verification by anyone who pulls the relevant WellKnownManifest files.
  • An operator that runs a Publisher and an Exchange MAY self-attest resources at Level 1 (publisher signs its own ResourceAttestation). Agents that require Level 2 verification will discount or ignore Level 1 self-attestations from the same operator that runs the Exchange — see Content Attestation for trust-policy patterns.

Next Steps

Section titled “Next Steps”