Skip to main content
Every measurable action in AIP is recorded as an Event.
Events are how the protocol verifies that value was created — from a user seeing an ad to completing a conversion.

​
1. TL;DR

Events track and verify each stage of user engagement: exposure, click, and conversion.

​
2. Why it matters

Traditional ad systems rely on cookies or opaque tracking pixels.
AIP replaces those with signed, timestamped events that can be independently verified by all participants. This means:
  • No duplicate billing
  • No fake clicks or conversions
  • Transparent proof of every monetized action

​
3. The Event Ladder

AIP defines three progressive event types — each building on the last.
Only one unit settles per serve_token.
Event TypeAbbreviationTriggerBilling UnitVerification Responsibility
ExposureCPXUser sees an ad or recommendationCost per ExposureOperator (may use platform signals)
ClickCPCUser clicks or engagesCost per ClickOperator (may use platform and network signals)
ConversionCPAUser completes a purchase or signupCost per ActionOperator (may use brand agent and network signals)
Once a higher event (like CPA) is verified, lower-tier events (CPX or CPC) are not billed again.

​
4. Event lifecycle

Each transition is verified and timestamped.
If no further event occurs, the lifecycle ends at the last verified state.

​
5. EventPacket schema

All events share common required fields that link them back to the auction and enable verification.

​
Common Required Fields

FieldTypeDescription
event_typestringEvent type identifier (cpx_exposure, cpc_click, or cpa_conversion)
serve_tokenstringServe token from the auction result - links event to original bid
tsstringISO 8601 timestamp of when the event occurred

​
Event-Specific Fields

At the protocol level, events require event_type, serve_token, and timestamp. Each event type has additional required and optional fields that are implementation-specific.

​
Example: CPX Exposure Event

{
  "event_type": "cpx_exposure",
  "serve_token": "stk_abcxyz123",
  "session_id": "s_001",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "wallet_id": "w_890",
  "pricing": {
    "unit": "CPX",
    "amount": "0.034",
    "currency": "USD"
  },
  "ts": "2025-11-11T18:00:00Z"
}
The serve_token links each event back to the original auction and winning bid.

​
6. Verification process

Operators define their own verification logic for each event type. Acceptable signal sources include:
Event TypeSignal Sources (Informational)
ExposurePlatform display logs, visibility events, viewability metrics
ClickPlatform interaction logs, user click events, timestamp validation
ConversionBrand agent callbacks, server-side API confirmations, conversion tracking pixels
Every event is digitally signed and validated against the original serve_token. Operators implement their own verification and reconciliation logic to ensure event integrity.

​
7. Example flow

  1. Platform renders a sponsored recommendation → CPX logged
  2. User clicks the recommendation → CPC verified
  3. User signs up on advertiser site → CPA confirmed
  4. Lower events (CPX, CPC) are marked as verified but not billed

​
8. Payout implications

Operators determine settlement based on verified events according to the event ladder (CPA > CPC > CPX). Settlement terms, revenue sharing, and payout schedules are defined by each operator’s policies and agreements with platforms and brand agents.

​
9. Guarantees

  • Each event is uniquely linked to a serve token.
  • Events cannot be duplicated or retroactively modified.
  • Signatures are auditable by any party in the chain.
  • Billing and payout data are mathematically verifiable.

​
Summary

Events are the backbone of AIP — they turn user actions into verified, auditable, and monetizable outcomes.