Agent / Fiber Integration Solutions Design

AI Agent Payment Integration Design for Fiber Network

Date: 2026-04-07 (updated 2026-04-14) Status: Draft Author: Design Research

Table of Contents

1. Executive Summary
2. Background & Motivation
3. Protocol Survey
   • 3.1 x402 (Coinbase)
   • 3.2 Stripe Agent Commerce Protocol (ACP)
   • 3.3 L402 (Lightning Labs)
   • 3.4 Fiber Native Agent Protocol
4. Fiber Technical Capabilities
5. Application Scenarios
6. L402 vs Fiber Native Agent Protocol: Deep Comparison
   • 6.0 Relationship Positioning
7. Token Delegation: Macaroon vs Biscuit
8. Fair Exchange Problem & Settlement Strategies
9. Strategic Recommendation: Dual-Track Approach
10. Implementation Roadmap
11. Open Questions

1. Executive Summary

This document evaluates integration strategies for AI Agent payments on the Fiber Network (CKB Lightning Network). We survey four candidate protocols (x402, Stripe ACP, L402, Fiber Native), analyze three application scenarios (M2M micropayments, Agent-to-Agent service trading, Agent proxy shopping), and recommend a dual-track strategy:

• Track 1 (High Priority): x402 Facilitator -- integrate Fiber as a payment backend for the x402 ecosystem, gaining immediate access to the emerging HTTP-native payment standard.
• Track 2 (Medium Priority): Fiber Native Agent Protocol -- adopt the L402 protocol skeleton (HTTP 402 + preimage payment proof + token credential) while introducing architectural innovations in token system (Biscuit replacing Macaroon), fair exchange (Hash-Locked Data Exchange), and multi-asset support (CKB + RGB++ stablecoins).

We recommend against Stripe ACP integration (centralized, no crypto-native path) and recommend learning from L402 rather than directly implementing it (L402 is tightly coupled to Lightning/LND).

Timeline: 4 weeks, 1 engineer + AI coding agent.

2. Background & Motivation

The Agent Economy

AI agents are becoming autonomous economic actors. They need to:

• Discover services programmatically (no human signup flows)
• Pay for API calls, compute, data (sub-cent micropayments)
• Authenticate with cryptographic credentials (not passwords/API keys)
• Delegate payment authority to sub-agents (hierarchical agent systems)
• Settle fairly (neither party can cheat the other)

Why Fiber

Fiber Network is a CKB-based payment channel network with unique advantages for agent commerce:

• Multi-asset: Native support for CKB + RGB++ assets (UDTs) in payment channels
• WASM nodes: Agents can embed a full Fiber node in-browser or in-process
• Sub-second finality: Off-chain channel updates are instant
• Programmable settlement: CKB's RISC-V VM enables flexible on-chain contracts
• Cross-chain: HTLC-based interop with Bitcoin Lightning Network

3. Protocol Survey

3.1 x402 (Coinbase)

Overview: Open standard for HTTP-native payments. Uses HTTP 402 status code with a facilitator architecture.

Flow:

1. Client requests resource from server
2. Server returns 402 Payment Required + PAYMENT-REQUIRED header (accepted networks, schemes, amounts)
3. Client creates PaymentPayload (signed transaction/authorization)
4. Client sends request with PAYMENT-SIGNATURE header
5. Server forwards to Facilitator for /verify and /settle
6. Facilitator submits payment on-chain, returns receipt
7. Server serves resource

Key Properties:

• Network/token agnostic (EVM, Solana, fiat -- extensible via scheme + network pairs)
• Trust-minimizing: Facilitator cannot move funds beyond client's signed authorization
• Multi-language SDKs (TypeScript, Python, Go, Java)
• Schemes: exact (fixed price), future upto (metered usage)
• Currently blockchain-based (on-chain transactions), no native payment channel support

Fiber Integration Path: Build a Fiber Facilitator that implements /verify and /settle endpoints using Fiber payment channels. This would make Fiber a payment backend for any x402-compatible server, with near-zero fees and instant settlement.

Strengths: Large ecosystem momentum (Coinbase backing), clean HTTP semantics, multi-network support. Weaknesses: Currently on-chain only (slow, expensive for micropayments), no native credential/delegation system, facilitator is a trust point for settlement.

3.2 Stripe Agent Commerce Protocol (ACP)

Overview: Stripe's protocol for agent-to-merchant payments. Uses Stripe's existing payment infrastructure with a new "Secure Payment Token" (SPT) for agent delegation.

Flow:

1. Human pre-authorizes agent with spending limits via Stripe dashboard
2. Agent receives SPT (scoped Stripe token)
3. Agent browses merchant, selects items
4. Agent creates Stripe PaymentIntent using SPT
5. Stripe processes payment through traditional rails (cards, bank transfers)
6. Merchant fulfills order

Key Properties:

• Fully centralized (Stripe as sole payment processor)
• Requires Stripe merchant accounts (existing Stripe ecosystem only)
• SPT provides spending caps and merchant restrictions
• Designed for Agent-as-shopper scenarios (e-commerce)
• No crypto-native path, no micropayment support

Assessment: Not recommended for Fiber integration. ACP is a closed ecosystem with no path to decentralized payments. Stripe's existing infrastructure handles the use cases ACP targets. There is no meaningful technical overlap with Fiber's capabilities.

3.3 L402 (Lightning Labs)

Overview: HTTP 402 protocol combining Macaroon bearer tokens with Lightning Network invoice payments. Originally called LSAT (Lightning Service Authentication Token).

Flow:

1. Client requests resource from server
2. Server returns 402 Payment Required + WWW-Authenticate: L402 macaroon="M", invoice="P"
3. Client pays Lightning invoice P, obtains preimage r
4. Client sends Authorization: L402 M:r (base64 macaroon + hex preimage)
5. Server verifies: macaroon integrity (HMAC chain) + payment proof (H == sha256(r))
6. Server serves resource

Key Properties:

• Stateless verification: Macaroon commits to payment_hash; server verifies H == sha256(preimage) with no database lookup
• Macaroon delegation: Holders can append caveats to restrict (never widen) credentials, then pass to sub-agents
• Standard caveats: services, capabilities, constraints (volume limits, expiry)
• Credential reuse: Pay once, authenticate many times until revoked
• gRPC support: Same auth scheme adapted for gRPC (status in trailers)
• Production deployment: Aperture reverse proxy used in Lightning Loop, Pool

Macaroon Identifier Structure (66 bytes):

Strengths: Battle-tested, elegant stateless verification, rich delegation model, minimal trust assumptions. Weaknesses: Tightly coupled to Lightning/LND ecosystem, Macaroons are less flexible than Biscuit tokens (no Datalog logic, no explicit revocation lists), no multi-asset support, no WASM node story.

3.4 Fiber Native Agent Protocol

Overview: A new protocol purpose-built for Fiber that adopts the L402 protocol skeleton — HTTP 402 challenge-response, preimage-based payment proof, and token:preimage credential format — but introduces substantial architectural innovations in three dimensions: Biscuit tokens (truly stateless verification via public-key cryptography and Datalog policies) replacing Macaroons, a Hash-Locked Data Exchange mechanism for cryptographic fair exchange (absent in L402), and native multi-asset support via CKB + RGB++ stablecoins. A detailed comparison is provided in Section 6.

Proposed Flow (see Section 6 for detailed comparison with L402):

1. Client requests resource from server
2. Server returns 402 Payment Required with Fiber invoice + Biscuit token
3. Client pays via Fiber channel (Keysend or Invoice payment)
4. Client presents Biscuit token + payment proof
5. Server verifies Biscuit (Datalog policy engine) + payment proof
6. Server serves resource

Differentiators vs L402:

• Multi-asset: Pay in CKB, stablecoins, or any RGB++ asset
• Biscuit tokens: Datalog-based authorization (more expressive than Macaroon caveats)
• WASM embedding: Agents can run a full Fiber node in-process
• Hold Invoice + Atomic Data Exchange: Cryptographic fair exchange (see Section 8)
• Custom Records: 2KB arbitrary metadata in payment onion (keys 0-65535)

4. Fiber Technical Capabilities

4.1 Payment Primitives

4.2 Authentication: Biscuit Auth

Fiber uses Biscuit tokens for RPC authentication:

• Ed25519 signed bearer tokens with Datalog authorization logic
• Fine-grained permissions: read("payments"), write("channels"), right(channel_id, "watchtower")
• Time-based expiry: check if time($time), $time <= 2025-01-01T00:00:00Z
• Attenuation: Token holders can create restricted sub-tokens (like Macaroons, but with Datalog)
• Revocation: Server-side via public key rotation

Current RPC permission model (resource-based):

channels: read/write    invoices: read/write    payments: read/write
peers: read/write       graph: read             node: read
cch: read/write         chain: write            watchtower: write + per-channel

4.3 WASM Node

Full Fiber node compiled to WASM with 22 exposed functions:

• Channel management (open, accept, abandon, list, shutdown, update)
• Graph queries (nodes, channels)
• Invoice lifecycle (new, parse, get, cancel, settle)
• Payment operations (send, get, build_router, send_with_router)
• Peer management (connect, disconnect, list)

Missing from WASM: list_payments, CCH (cross-chain hub), Biscuit auth middleware.

4.4 Hold Invoice Details

Creation: InvoiceBuilder::payment_hash(hash) -- only hash stored, no preimage on receiver side.

Settlement: settle_invoice(payment_hash, payment_preimage) -- caller provides preimage to release locked funds.

Error states: InvoiceNotFound, HashMismatch, InvoiceStillOpen, InvoiceAlreadyCancelled, InvoiceAlreadyExpired, InvoiceAlreadyPaid.

Trust model (IMPORTANT):

• The entity that generates the preimage controls settlement
• In standard Hold Invoice usage: an external party (e.g., the Consumer) generates the preimage, gives only the hash to the Provider
• Provider creates invoice with that hash, Consumer pays, funds lock in HTLC
• Only the preimage holder can call settle_invoice to release funds
• Hold Invoice alone protects the payer (Consumer), NOT the provider -- Consumer can refuse to reveal preimage after receiving service

5. Application Scenarios

5.1 M2M Micropayments (API Pay-per-call)

Description: Agent pays for individual API calls (LLM inference, data queries, compute).

5.2 Agent-to-Agent Service Trading

Description: Agent A hires Agent B to perform a task (translation, analysis, code generation). Requires fair exchange -- payment conditional on delivery.

5.3 Agent Proxy Shopping

Description: Agent purchases goods/services on behalf of human (hotel booking, SaaS subscription).

5.4 Scenario-Protocol Matrix

                    x402 Facilitator    L402 (ref)    Fiber Native    Stripe ACP
M2M Micropay        ★★★★★              ★★★★★         ★★★★★           ★☆☆☆☆
Agent-to-Agent      ★★★☆☆              ★★★☆☆         ★★★★★           ★☆☆☆☆
Proxy Shopping      ★★★★☆              ★★★☆☆         ★★★★☆           ★★★★☆
Ecosystem Size      ★★★★★              ★★★★☆         ★★☆☆☆           ★★★★★
Decentralization    ★★★★☆              ★★★★★         ★★★★★           ★☆☆☆☆

6. L402 vs Fiber Native Agent Protocol: Deep Comparison

6.0 Relationship Positioning

Fiber Native Agent Protocol is best understood as L402 re-implemented on Fiber with architectural upgrades, not a clean-room design or a simple port.

What is shared (the L402 skeleton):

• HTTP 402 challenge-response flow
• Preimage as proof-of-payment (H == sha256(preimage))
• token:preimage credential format in the Authorization header
• Credential reuse (pay once, authenticate many times)
• Reverse proxy gateway pattern (Aperture → Fiber Gateway)
• Token attenuation for delegation (can only restrict, never widen)

What is substantively different (Fiber's innovations):

The relationship is analogous to how QUIC adopted TLS 1.3's cryptographic handshake but redesigned the transport layer around UDP — same security model, different architecture where it matters.

6.1 Architecture Comparison

6.2 Token System: Macaroon vs Biscuit

Key Insight: Macaroons require the server to store a root key per macaroon and look it up by sha256(identifier) to verify. Biscuit verification requires only the server's public key -- it's more truly stateless for the verifier. However, L402 achieves practical statelessness by embedding the payment_hash in the macaroon identifier and using sha256(preimage) as the payment proof, so the payment verification itself is stateless even if macaroon verification needs a key lookup.

6.3 Payment Proof Mechanism

Both protocols use the same fundamental insight: preimage as proof of payment.

L402:   payment_hash H embedded in macaroon identifier
        Client pays invoice → gets preimage r
        Verification: H == sha256(r)

Fiber:  payment_hash H embedded in biscuit facts (or in invoice reference)
        Client pays Fiber invoice → gets preimage r  
        Verification: H == sha256(r)

The mechanism is identical. The difference is the payment rail (Lightning vs Fiber) and the token format (Macaroon vs Biscuit).

6.4 Credential Delegation for Agent Hierarchies

L402 Macaroon Delegation:

Agent A has macaroon M with capabilities [read, write, admin]
Agent A attenuates: append caveat "capabilities=read"  
Agent A gives M' to sub-agent B
B can only read (caveat chain enforced by HMAC)
B cannot recover M's signature (HMAC is one-way)

Fiber Biscuit Delegation:

Agent A has biscuit B with facts [read("payments"), write("channels"), time check]
Agent A attenuates: append block with check [read("payments")]  
Agent A gives B' to sub-agent B
B can only read payments (Datalog evaluation restricts authority)
B cannot remove blocks (Ed25519 signature covers the chain)

Fiber Advantage: Biscuit's Datalog engine enables richer delegation policies:

• check if amount($a), $a <= 10000 (spending limits in token itself)
• check if resource($r), $r.starts_with("/api/v2/") (path-scoped access)
• `check if time($t), $t <= 2026-04-15T00