Skip to main content
AIP defines protocol-level constraints for settlement and operator-defined accounting records. AIP does not define wallet implementations, revenue sharing models, payout timing, or payment rails. All wallet and payout mechanics are operator-defined.

​
1. TL;DR

AIP guarantees that each verified event is attributable to operator-defined settlement records, each serve_token resolves to at most one terminal charge, and all settlement records are immutable and auditable. Operators implement their own wallet systems and payout logic.

​
2. Why it matters

AIP provides settlement invariants that ensure:
  • No double billing
  • One terminal settlement per serve_token
  • Immutable settlement records
  • Full auditability
Operators implement their own wallet systems, revenue sharing models, payout schedules, and payment mechanisms as long as these protocol guarantees are met.

​
3. Settlement invariants

The protocol guarantees the following invariants:

​
Settlement records

Operators maintain operator-defined settlement records that link verified events to settlement outcomes. Each settlement record:
  • Links to a serve_token from the original auction
  • Records the terminal event type (CPX, CPC, or CPA)
  • Contains immutable timestamps and state information

​
Event-to-settlement linkage

Every verified event (cpx_exposure, cpc_click, cpa_conversion) must be attributable to an operator-defined settlement outcome linked to the serve_token. Events must be linkable to:
  • The original serve_token from the auction
  • An operator-defined settlement record that reflects the final settlement state
  • The terminal billing unit (highest verified event in the ladder)

​
One terminal charge per serve_token

Each serve_token resolves to at most one terminal charge. The protocol guarantees:
  • If a CPA conversion is verified, CPX and CPC are not billed
  • If a CPC click is verified (and no CPA), CPX is not billed
  • If only CPX is verified, CPX is billed
This follows the event ladder: CPA > CPC > CPX.

​
Settlement immutability and auditability

Once a settlement record reaches a finalized state, it is immutable. All settlement records:
  • Are tamper-evident and auditable
  • Can be independently verified by any participant
  • Provide full auditability of all settlement decisions

​
4. Example settlement record (non-normative)

The following example illustrates a settlement record structure. This is non-normative — field names, structure, and granularity are illustrative only. The example does not imply required fields or storage models. Operators define their own settlement record schemas and fields. 
{
  "serve_token": "stk_abcxyz123",
  "session_id": "s_001",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "auction_id": "auc_981",
  "state": "FINALIZED",
  "final_unit": "CPA",
  "final_charge": "10.00",
  "currency": "USD",
  "timestamps": {
    "auction": "2025-11-11T18:00:00Z",
    "exposure": "2025-11-11T18:00:00Z",
    "click": "2025-11-11T18:02:00Z",
    "conversion": "2025-11-11T18:30:00Z",
    "finalized": "2025-11-11T19:00:00Z"
  }
}

​
5. Guarantees

The protocol guarantees:
  • No double billing: Each serve_token resolves to at most one terminal charge
  • One terminal settlement per serve_token: The event ladder (CPA > CPC > CPX) ensures only the highest verified event is billed
  • Immutable settlement records: Finalized settlement records cannot be modified
  • Full auditability: All settlement records are tamper-evident and auditable and can be independently verified
Operators implement their own wallet systems, revenue sharing, payout schedules, dispute resolution, and payment mechanisms. The protocol only constrains the linkage between events, serve_token, and settlement records.

​
Summary

AIP defines protocol-level settlement invariants that ensure each serve_token resolves to at most one terminal charge, with immutable and auditable settlement records. Operators implement their own wallet and payout systems to enforce these constraints.
Next: Security