Impression Semantics
"Impression" means different things depending on how the agent or user accessed the resource. The definition must be precise, otherwise participants interpret it in whatever way pays them more.
Definitions by Transport
| Transport | What Counts as an Impression | Verification | Pricing |
|---|---|---|---|
| HTTP | Client fires the tracking.impressionBeacon URL back to the ad network | Beacon received + blockchain tx + impression token | CPM |
| MCP | Facilitator confirms the sponsored-access settlement event | Facilitator event + blockchain tx + impression token | CPA |
| A2A | Facilitator confirms the sponsored-access settlement event | Facilitator event + blockchain tx + impression token | CPA |
For HTTP, the client's browser or SDK fires a beacon URL when the recommendation is received. This confirms delivery.
For MCP and A2A, agents cannot fire beacons. The facilitator's settlement event serves as the primary impression signal. Because delivery cannot be independently confirmed for agents, pricing shifts to CPA: the advertiser pays only when the agent actually calls the recommended resource.
Conversion Tracking
A conversion occurs when a client that received a recommendation for Resource X subsequently calls Resource X through the same facilitator.
The facilitator tracks this by correlating the payer wallet:
- Agent pays for Resource A, receives recommendation for Resource X. The facilitator records the recommendation in an in-memory LRU cache (payer wallet to recommended resource URL).
- Agent pays for Resource X. The facilitator checks the cache: this payer was previously recommended this resource.
- The facilitator reports the conversion to the ad-network service with both transaction hashes.
Both hashes are Solana (or EVM) transactions, publicly verifiable on-chain. This provides cryptographic proof that:
- The agent saw the recommendation (original settlement tx)
- The agent called the recommended resource (conversion settlement tx)
No traditional ad network can provide this level of conversion attribution.
Verification Signals
The system is designed for up to three independent verification signals per impression. Currently, one signal is active in production; the others are defined in the schema and spec but not yet implemented.
Blockchain transaction (active): Proves the payment occurred. The settlement transaction hash is publicly verifiable by anyone via any RPC node.
Facilitator settlement event (active): An independent record from the facilitator that the publisher cannot manipulate. The facilitator pushes this event to the ad-network service after every sponsored settlement.
Impression token (schema defined, signing not implemented): The spec calls for the ad network to cryptographically sign an impression token when a campaign is matched, then verify its own signature when the token returns with a transaction hash. Currently the token is a variant ID passed through and stored, but not cryptographically signed or verified.
Impression beacon (schema defined, not active): For HTTP clients, the spec defines a beacon URL the client fires to confirm delivery. The beacon_received field exists in the database but is not set by any active code path. OpenDexter's fireImpressionBeacon() calls the beacon URL, but the ad-network's beacon endpoint (GET /v1/track/impression/:campaignId) only logs and does not update the field.
Why CPA for Agents
Agents process tool results programmatically. There is no visual attention, no scroll depth, no viewability metric. An "impression" for an agent means the recommendation was present in the settlement receipt, but whether the agent acted on it is the only meaningful measure.
CPA aligns incentives: the advertiser pays only when the agent follows through. This also eliminates the incentive for publishers to farm impressions, since impressions alone generate no revenue for agent-transport campaigns.