IPPAN L2 · A402

Atomic Service
Payments on IPPAN

A402 binds service execution, payment authorization, execution receipts and deterministic settlement into a single, verifiable transaction. Built for agentic commerce, machine-to-machine billing, and high-frequency monetized APIs.

Open Dashboard View Architecture GitHub

Lifecyclea402.spec/v0

Challenge
request hash
01
Intent
client signature
02
Execute
provider runtime
03
Receipt
result hash
04
Settlement
ledger ref
05

What is A402

Payment-before-access is not enough.

Agentic commerce, M2M billing, and high-frequency monetized APIs require execution and payment to be linked into a single verifiable transaction. A402 makes that link a primitive.

Authorized execution

Every paid call carries a signed ServiceIntent — execution only happens after the intent is verified.

Cryptographic receipts

Providers issue signed receipts with result hashes. Audit trails are deterministic and replayable.

Atomic settlement

Settlements close atomically against execution receipts — no orphaned charges, no silent refunds.

Why IPPAN

A settlement layer designed for machine-native commerce.

IPPAN provides deterministic ordering, signed intents, high-throughput micro-settlement, and verifiable history — exactly what agentic and M2M services need.

Deterministic ordering

Globally consistent transaction order without probabilistic finality.

Auditability

Every intent, receipt, and settlement is permanently inspectable.

Micro-settlement

Sub-cent amounts settle without batching delays or fee inversion.

Programmable

Service offers, policies, and channels are first-class on-chain objects.

Lifecycle

Six steps from request to settlement.

Every paid call follows the same deterministic path. Each step is signed, hashed, and inspectable from the dashboard.

Step 01

Request

Client targets a paid service offer.

Step 02

Challenge

Provider returns a signed challenge + request hash.

Step 03

Signed Intent

Client signs a ServiceIntent authorizing the spend.

Step 04

Execute

Provider runs the call once the intent is verified.

Step 05

Receipt

Provider issues a signed execution receipt with result hash.

Step 06

Settlement

Settlement is finalized atomically against the intent.

Step 01
Request
Client targets a paid service offer.
Step 02
Challenge
Provider returns a signed challenge + request hash.
Step 03
Signed Intent
Client signs a ServiceIntent authorizing the spend.
Step 04
Execute
Provider runs the call once the intent is verified.
Step 05
Receipt
Provider issues a signed execution receipt with result hash.
Step 06
Settlement
Settlement is finalized atomically against the intent.

Architecture

Layered, composable, replaceable.

A402 is structured as discrete layers so providers can plug into the runtime that fits their workload — single-shot, session, or channel.

Gateway Layer

Service registryOffer indexPolicy engine

Payment Logic

Intent verifierAuthorizationNonce / replay

Execution

Provider runtimeResult hashingLatency capture

Receipts & Settlement

Signed receiptsAtomic settlementRefund logic

Sessions & Channels

Prepaid balancesLocked fundsFuture atomic channels

Use cases

Built for the next decade of programmable services.

AI agents paying APIs

Autonomous agents that authorize each API call with a signed intent.

Machine-to-machine billing

Devices and services billing each other directly with no human in the loop.

Premium data feeds

Per-request monetization for high-value real-time data.

Enterprise usage billing

Cryptographic, audit-grade billing for regulated workloads.

Energy & IoT services

Telemetry-priced services with verifiable consumption history.

RWA & financial data

Notarized provenance for tokenized real-world-asset feeds.

Roadmap

Three phases. One settlement model.

Phase 1

Per-call paid execution

Single-shot ServiceIntents settled atomically against execution receipts. Live for high-frequency monetized APIs.

Phase 2

Sessions & prepaid balances

Locked balances and reusable sessions for long-running workloads — streaming inference, telemetry, agent workflows.

Phase 3

Atomic service channels

Off-chain channels with deterministic netting and dispute resolution rooted in IPPAN's consensus.

Developer flow

Six API calls to monetize a service.

1. Create offer

POST /v1/offers
{
  "service": "/v1/forecast",
  "method": "POST",
  "price": "0.012 USDX",
  "settlement": "per_call"
}

2. Request challenge

POST /v1/challenge
→ {
  "request_hash": "0x4f…",
  "nonce": "1003719",
  "expiry": "2026-04-09T12:42:00Z"
}

3. Sign + submit intent

intent = sign_intent(request_hash, 0.012)
POST /v1/intents
{ "intent": intent, "offer": "a402_of_…" }

4. Execute paid call

POST /v1/execute
{ "intent_id": "a402_in_…" }
→ 200 OK { "result": …, "receipt_id": "a402_rc_…" }

5. Inspect receipt

GET /v1/receipts/a402_rc_…
→ {
  "execution_status": "success",
  "result_hash": "0x…",
  "latency_ms": 142
}

6. Inspect settlement

GET /v1/settlements?intent=a402_in_…
→ {
  "state": "settled",
  "final_amount": "0.012 USDX",
  "ledger_ref": "0x…"
}

From concept to control plane.

Open the operational dashboard to inspect offers, intents, receipts, settlements, and run the end-to-end demo.

Open Dashboard Try the Demo

Atomic ServicePayments on IPPAN