Learn more about ATP’s vision and purpose: See ATP Vision for details on why ATP exists and our goal to make it the standard for agentic trade.
How It Works
The ATP Protocol operates through three main components:- Settlement Service (Facilitator): A centralized service that handles all settlement logic, including usage parsing, payment calculation, and blockchain transaction execution. See Facilitator Reference for complete API documentation.
- Middleware: A FastAPI middleware that intercepts API responses, extracts usage data, encrypts responses, executes payments, and decrypts responses only after payment confirmation. See Middleware Reference for configuration and usage.
- Client: A user-facing client that simplifies making requests to ATP-protected endpoints and interacting with the settlement service. See Client Reference for API documentation.
Request Flow
- Client Request: User sends a request to an ATP-protected endpoint with their wallet private key in the header.
- Endpoint Processing: The endpoint processes the request and returns a response with usage data (token counts).
-
Middleware Interception: The middleware intercepts the response and:
- Parses usage data via the settlement service
- Encrypts the agent response to prevent unauthorized access
- Sends payment request to settlement service
-
Payment Execution: The settlement service:
- Calculates payment amount based on token usage and pricing
- Creates a split payment transaction (treasury fee + recipient payment)
- Signs and sends the transaction to Solana blockchain
- Waits for transaction confirmation
- Response Decryption: Only after payment is confirmed on-chain, the middleware decrypts the response and returns it to the client.
Security Features
- Response Encryption: Agent responses are encrypted before payment verification, ensuring users cannot see output until payment is confirmed.
- Payment Verification: Responses are only decrypted after successful blockchain transaction confirmation (status=“paid” with valid transaction signature).
- Error Handling: Failed payments result in encrypted responses with error details, preventing unauthorized access to agent output.
Payment Splitting
Payments are automatically split between:- Treasury: Receives the processing fee (configured on settlement service, default 5%)
- Recipient: Receives the remainder (95% by default). This is the endpoint host’s wallet specified via
recipient_pubkey.
Server Example
Here’s a complete example of setting up an ATP-protected FastAPI server:Response Format
The middleware automatically adds the following fields to responses:atp_usage: Normalized usage data (input_tokens, output_tokens, total_tokens)atp_settlement: Settlement details including transaction signature and payment breakdownatp_settlement_status: Status of settlement (“paid”, “failed”, etc.)atp_message: Informational message about response encryption status
Client Example
Here’s how to use the ATP client to make requests to ATP-protected endpoints:Using the ATP Client
Using Direct HTTP Requests
You can also make direct HTTP requests without the client:Interacting with Settlement Service Directly
The client also provides methods to interact with the settlement service directly:Usage Data Formats
The middleware supports multiple usage data formats automatically:OpenAI Format
Anthropic Format
Google/Gemini Format
Nested Formats
Error Handling
Missing Wallet Key
If the wallet private key is missing andrequire_wallet=True:
Payment Failure
If payment fails andfail_on_settlement_error=False (default):
Timeout Errors
Settlement operations may take time due to blockchain confirmation. If a timeout occurs, the payment may have been sent successfully. Check the blockchain for transaction confirmation.Configuration
Environment Variables
ATP_SETTLEMENT_URL: Base URL of the settlement service (default:https://facilitator.swarms.world/)ATP_SETTLEMENT_TIMEOUT: Timeout for settlement operations in seconds (default:300.0)ATP_ENCRYPTION_KEY: Base64-encoded Fernet key for response encryption (optional, generates new key if not set)
Middleware Configuration
See the Middleware Reference for complete configuration options.Client Configuration
See the Client Reference for complete client options.Best Practices
- Wallet Security: Never log or persist wallet private keys. They should only be used in-memory for transaction signing.
-
Error Handling: Use
fail_on_settlement_error=Falsefor graceful degradation. Checkatp_settlement_statusin responses to handle payment failures. -
Timeout Configuration: Increase
settlement_timeoutif you experience timeout errors even when payments succeed. Blockchain confirmation can take time. - Usage Data: Always include accurate token counts in your responses. The middleware will skip settlement if usage data cannot be parsed.
- Testing: Use testnet wallets and small amounts for testing. Verify payment transactions on Solana explorer.
-
Monitoring: Monitor
atp_settlement_statusin responses to track payment success rates and identify issues.
Architecture Benefits
- Centralized Settlement: All settlement logic is handled by the immutable settlement service, ensuring consistency across all services.
- Format Flexibility: Supports multiple usage data formats automatically, so you can use any agent API format.
- Security: Response encryption ensures users cannot access agent output until payment is confirmed on-chain.
- Transparency: All payments are executed on Solana blockchain with full transaction visibility.
- Automatic Splitting: Payments are automatically split between treasury and recipient, simplifying revenue distribution.