Programmable, x402-compatible payments for autonomous agents, APIs, MCP tools and digital services.
Website · Documentation · SDK & MCP · MCP endpoint
AIFP-2 defines how an autonomous agent discovers a price, evaluates a machine-readable payment requirement, authorizes settlement under its spending policy, pays through an approved rail, presents proof and receives a verifiable result.
It is AiFinPay's payment-execution protocol. It supports the open HTTP 402 Payment Required pattern and an x402 v2 compatibility profile without making any single facilitator, wallet provider or blockchain mandatory.
flowchart LR
A["Agent"] -->|request| R["Protected resource"]
R -->|402 + requirements| A
A --> P["Policy + wallet"]
P --> S["Settlement rail"]
S --> V["Verifier"]
V -->|receipt| A
A -->|retry + proof| R
request protected resource
→ receive HTTP 402 and accepted payment options
→ choose network and asset under agent policy
→ bind provider amount, fee profile, payee, resource, nonce and expiry
→ sign locally; private keys never leave the wallet boundary
→ verify and settle through the selected route
→ receive a signed, replay-resistant receipt
→ retry the original request with payment proof
→ receive the protected result
AIFP-1 and AIFP-2 intentionally use different fee semantics.
| Route | Commercial amount | AiFinPay protocol fee | Merchant/provider result |
|---|---|---|---|
| AIFP-2 with x402-compatible execution | Provider-defined price | 0% / 0 bps currently | Provider receives 100% of provider-defined price |
| AIFP-1 monetization | Published gross action price | 1% / 100 bps of gross | Merchant receives 99% of gross |
AIFP-2 is provider-preserving. Any AiFinPay AIFP-2 fee is a separate payer-side amount and must not reduce the provider-defined price.
provider_amount = provider-defined price
protocol_fee_amount = provider_amount × active AIFP-2 fee rate
payer_total = provider_amount + protocol_fee_amount
provider_settlement = provider_amount
The active AIFP-2 fee is currently 0%, so payer_total = provider_amount today.
A future non-zero AIFP-2 fee may be introduced only through an explicit versioned settlement profile. It must be added on top for the payer and must not reduce the provider amount. AIFP-2 must not silently fall back to AIFP-1 economics.
The compatibility profile uses the standard v2 headers:
| Header | Direction | Purpose |
|---|---|---|
PAYMENT-REQUIRED |
resource → client | Base64-encoded payment requirements |
PAYMENT-SIGNATURE |
client → resource | Base64-encoded signed payment payload |
PAYMENT-RESPONSE |
resource → client | Base64-encoded verification/settlement result |
The current EVM profile uses CAIP-2 network identifiers and EIP-3009 TransferWithAuthorization where supported. Legacy x402 v1 X-PAYMENT headers are not the canonical profile. See x402 compatibility.
 Polygon |
 Avalanche |
 BNB Chain |
 Optimism |
 Solana |
 NEAR |
The implementation program spans thirteen network surfaces: nine EVM networks plus Solana, NEAR, Aptos and Casper. Status is tracked per route; the number of network adapters or historical deployments does not imply feature parity or global production activation. See the network matrix and deployment evidence rules.
- The wallet signs locally; APIs never receive a private key or recovery phrase.
- A client-supplied transaction hash is not sufficient evidence of payment.
- Network, asset, payee, provider amount, protocol fee amount, payer total, expiry, resource scope and payment identifier are bound before signing.
- Amounts use integer atomic units with independently verified asset decimals.
- Duplicate payment identifiers, receipts and settlement consumption fail closed.
- A route is not advertised as payable unless the active verifier can validate it.
- Current AIFP-2 economics are
0/0; any future non-zero AiFinPay fee must use a versioned provider-preserving fee-on-top profile. - AIFP-1 economics must never be substituted for AIFP-2.
- Deployment addresses and runtime hashes are independently pinned before the wallet signs.
The current EVM v1.3 AIFP-2 splitter profile is fixed at 0/0. At that profile, the provider receives the entire settlement amount.
A non-zero future AIFP-2 fee requires a new versioned settlement profile/implementation that independently binds provider_amount, protocol_fee_amount, payer_total and the fee-profile version. Changing the current v1.3 splitter from 0/0 to a positive gross split would deduct the fee from the provider and is therefore not conformant with AIFP-2.
| Start here | Document |
|---|---|
| Protocol behavior | Normative specification |
| System boundaries | Architecture |
| HTTP and x402 | x402 compatibility |
| Networks and current status | Network matrix |
| SDK, MCP and server integration | Integration guide |
| Threats and required controls | Security model |
| Evidence required before activation | Deployment evidence |
| Code ownership and real implementation status | Implementation map |
| Machine-readable API | OpenAPI 3.1 |
| Machine-readable objects | JSON Schemas |
This repository is the public protocol, schema and integration contract for AIFP-2. It does not make an unverified deployment production-ready.
Current implementation work is split across several repositories:
- Agent SDK and MCP
- EVM contracts
- Solana program
- Stellar x402 facilitator
- Casper contract
- AiFinPay web/backend
The SDK main branch contains the x402 v2 EVM transport/profile, its named regression tests and the merged SDK/MCP settlement RC from PR #26. The 13-network backend control plane remains an open stacked source RC in aifinpay-web PR #22. Canonical settlement contract candidates remain open in EVM PR #9, Solana PR #4 and Casper PR #13. These are component/source milestones, not proof that the complete payment system is production-live. See the implementation map.
Production activation requires at least one canonical route to pass contract, SDK, backend, verifier, receipt, ledger/indexer and protected-resource E2E acceptance.
See the complete AiFinPay protocol-family architecture.
flowchart TD
P3["AIFP-3 · identity"] --> P6["AIFP-6 · governance"]
P6 --> P5["AIFP-5 · authorization"]
P5 --> P1["AIFP-1 · monetization"]
P5 --> P2["AIFP-2 · agent payments"]
P5 --> P4["AIFP-4 · banking / SWIFT"]
| Protocol | Responsibility |
|---|---|
| AIFP-1 | Monetizes AI-agent access to merchant resources |
| AIFP-2 | Executes programmable agent and machine-to-machine payments |
| AIFP-3 | Portable agent identity, wallet bindings and status |
| AIFP-4 | Connects approved agent instructions to banking and SWIFT rails |
| AIFP-5¹ | Provides classical, hybrid and post-quantum authorization profiles |
| AIFP-6¹ | Applies organizational policy, delegation, approvals and audit rules |
Each layer can be adopted independently. AIFP-3 is not required for baseline x402 interoperability; when present, it provides stronger identity and policy binding.
¹ AIFP-5 and AIFP-6 are currently private repositories; the links resolve for authorized organization members.
Code, examples, schemas and machine-readable artifacts are licensed under Apache License 2.0. Documentation and prose specifications are licensed under CC BY 4.0 unless a file states otherwise. See LICENSE and NOTICE.