From f9ec8850296050c37865505c6a542be8818155d9 Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 15:58:54 +0800 Subject: [PATCH 1/9] add devnotes --- devnotes/index.md | 2 +- .../x402-stablecoin-payments-for-agents.md | 268 ++++++++++++++++++ .../current/index.md | 2 +- .../x402-stablecoin-payments-for-agents.md | 268 ++++++++++++++++++ sidebarsDevnotes.js | 3 +- .../img/devnotes/bankofai-product-matrix.svg | 161 +++++++++++ .../img/devnotes/batch-settlement-channel.svg | 28 ++ .../img/devnotes/tron-x402-payment-flow.svg | 14 + 8 files changed, 743 insertions(+), 3 deletions(-) create mode 100644 devnotes/x402-stablecoin-payments-for-agents.md create mode 100644 i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md create mode 100644 static/img/devnotes/bankofai-product-matrix.svg create mode 100644 static/img/devnotes/batch-settlement-channel.svg create mode 100644 static/img/devnotes/tron-x402-payment-flow.svg diff --git a/devnotes/index.md b/devnotes/index.md index 6d1bc88e..76b3e1b2 100644 --- a/devnotes/index.md +++ b/devnotes/index.md @@ -9,4 +9,4 @@ Practical, battle-tested guidance from the BANK OF AI team — hands-on walkthro ## Practices -- [**Your First On-Chain Swap, Step by Step**](./first-onchain-swap/) — a complete walkthrough of one real task on the Nile testnet, including what to check at each step and what to do when it fails. +- [**BANK OF AI x402: Stablecoin Payments for AI Agents**](./x402-stablecoin-payments-for-agents/) — how the HTTP 402 challenge–response works, when to choose `exact` / `exact_gasfree` / `upto` / `batch-settlement`, and an end-to-end paid-inference case study on TRON. diff --git a/devnotes/x402-stablecoin-payments-for-agents.md b/devnotes/x402-stablecoin-payments-for-agents.md new file mode 100644 index 00000000..a4f9b6a7 --- /dev/null +++ b/devnotes/x402-stablecoin-payments-for-agents.md @@ -0,0 +1,268 @@ +--- +title: 'BANK OF AI x402: Stablecoin Payments for AI Agents' +description: 'From the HTTP 402 challenge–response flow to choosing between exact, exact_gasfree, upto, and batch-settlement — plus an end-to-end paid-inference case study on TRON.' +--- + +# BANK OF AI x402: Stablecoin Payments for AI Agents + +## 1. When AI agents need to pay + +AI agents do more than read public information. They retrieve data, call models, buy specialized tools, and hand tasks off to other agents. In these scenarios the consumer of a service is no longer always a person sitting in front of a browser — it is software deciding, on its own, what to call based on the task, the price, and the budget. + +Traditional billing was designed for humans: register an account, store an API key, buy a plan or pre-load credit. That still fits long-term customer relationships, but it handles one-off, cross-service, very small machine calls badly. The caller has to open an account and get credit approved in advance, while the provider maintains accounts, quotas, and invoices — and a capability needed just once may end up being something the agent simply cannot buy on its own. + +x402 moves payment negotiation back into the HTTP request itself. The service states what payment this resource requires; the client, having understood the terms, signs a payment credential and retries. Pay-per-call then lives in the same interaction loop as the API call: no account relationship established up front, and no checkout page wedged into the agent's execution path. + +## 2. BANK OF AI x402 and TRON + +### 2.1 What x402 is + +HTTP `402 Payment Required` has long been reserved for "payment is needed." x402 turns it into a machine-processable challenge–response flow: + +1. The client requests a protected resource. +2. The Resource Server returns `402` and offers one or more acceptable Payment Requirements in the `PAYMENT-REQUIRED` header — network, asset, amount, recipient, validity window, and payment scheme. +3. The client picks a requirement it can satisfy, signs a Payment Payload with its wallet, and carries it in the `PAYMENT-SIGNATURE` header on the retried request. +4. The server verifies the payment; where needed a Facilitator validates the signature and on-chain settleability, then returns the resource along with `PAYMENT-RESPONSE` once settled. + +Payment Requirements are the server's quote and constraints; the Payment Payload is the client's signed response to one of them. The two must be verified together: it is not enough to confirm "a transfer happened" — the network, token, amount, recipient address, validity window, and chosen scheme must all match the original quote. + +### 2.2 Why TRON first + +TRON gives x402 a settlement environment built around stablecoins. For dollar-denominated APIs, model inference, and data services, TRC-20 stablecoins make the quote line up directly with what users expect to pay; the network also suits applications that need frequent, small payments. The SDK currently supports TRON Nile and Shasta testnets plus mainnet — validate the full path on a testnet before going further. + +But "low cost" is not "no cost." An ordinary TRON transaction still involves bandwidth, energy, or TRX; confirmation time, RPC availability, token contract support, and the Facilitator's liquidity and risk policies all shape the real experience. The value of BANK OF AI x402 is in reaching these stablecoin capabilities through one unified HTTP payment protocol — not in guaranteeing that payment will go through automatically under any token, wallet, or network condition. + +### 2.3 BANK OF AI x402 + +BANK OF AI x402 is fully compatible with the core HTTP payment protocol and interaction model of Coinbase x402: the server publishes payment requirements via `402 Payment Required`, the client signs a credential and retries, and delivery completes through a standardized verify-and-settle flow. Agents, Resource Servers, and Facilitators that support x402 can therefore reuse the same protocol model. BANK OF AI's extensions sit at the multi-network, stablecoin-asset, and corresponding signing/settlement implementation layers — with TRON being the settlement network this article focuses on. + +Within the TRON ecosystem, [BANK OF AI](/BANK-OF-AI/Intro/) positions itself as "your Web3 AI gateway," giving agents the ability to pay, prove identity, act, and reason. Its architecture divides into four layers. The infrastructure layer provides blockchain networks, foundation models, stablecoin assets, and contracts. The protocol layer consists of MCP, x402, and 8004 — defining agent tool interaction, on-chain payment, and identity/reputation respectively. The agent capability and platform services layer covers agent integration and Skills, wallet signing, developer tooling and SDKs, x402 payment services, and MCP services. The ecosystem and application layer serves AI agents, agent applications, and marketplaces. + +![BANK OF AI product matrix](/img/devnotes/bankofai-product-matrix.svg) + +In this layering, x402 is the protocol layer's open payment protocol, sitting alongside 8004 which handles agent identity and reputation; MCP defines how agents and tools exchange context. The x402 Gateway, x402 Facilitator, Agent Wallet, Skills, and the various MCP Servers live in the platform services layer, turning those protocols into directly callable capabilities. Each layer can be used on its own or combined as the scenario requires: x402 when you need to pay, 8004 when you need to verify identity or reputation, MCP when you need to connect to tools or on-chain services. + +## 3. Architecture and payment flow + +### 3.1 The participants + +- **AI agent and Agent Wallet**: the agent decides whether to buy a resource; the wallet holds keys, checks budget and policy, and produces a TIP-712 signature for the payment requirement. Private keys should never be handed to the Resource Server or Facilitator. +- **Resource Server**: serves the protected resource, generates Payment Requirements, and delivers content or performs the service once verification and settlement succeed. +- **Facilitator**: verifies payment credentials per network and scheme, simulates or submits on-chain settlement, and returns an auditable result. It can be deployed independently, or the server can take on the same logical responsibility. +- **Blockchain network and payment contracts**: carry the assets, authorizations, and settlement transactions; different schemes may rely on different contracts or proxies. The payment flow diagram here uses TRON and TRC-20 assets as the example. + +### 3.2 One complete x402 payment + +![One complete BANK OF AI x402 payment](/img/devnotes/tron-x402-payment-flow.svg) + +1. The agent sends an ordinary HTTP request to a paid endpoint. +2. The Resource Server returns `402 Payment Required`, publishing the acceptable payment options. +3. The agent's selector picks a supported network, asset, and scheme; the wallet simultaneously checks balance, limits, recipient, and validity window. +4. The wallet signs a Payment Payload for the chosen requirement, and the agent retries the original request carrying `PAYMENT-SIGNATURE`. +5. The Resource Server passes the requirements and payload to the Facilitator for verification, settling either before or after delivery depending on the service's own value and failure-handling policy. +6. The Facilitator returns the verification/settlement result and a transaction identifier; the Resource Server delivers the resource and returns the outcome to the client in `PAYMENT-RESPONSE`. + +### 3.3 The core protocol data + +- **`PAYMENT-REQUIRED`**: the payment challenge in the 402 response, typically containing an `accepts` list. Each entry describes one payable combination rather than a vague "please send money." +- **`PAYMENT-SIGNATURE`**: the encoded payment response on the retried request, containing the requirement the client accepted plus the scheme-specific signed payload. +- **`PAYMENT-RESPONSE`**: settlement information on a successful response — final settled amount, transaction hash, or the scheme's follow-up state. +- **Payment Requirements / Payload**: the former is the quote, the latter a verifiable commitment to it. A secure implementation must check the binding between them and reject credentials that are expired, tampered with, replayed, or over-settled. + +## 4. The payment schemes + +### 4.1 Exact: fixed-amount payment + +`exact` is for services whose price is known before the call. The server quotes 0.01 USDT, the client signs that exact amount, and the Facilitator settles it once after verification. It has the simplest mental model and suits single reports, fixed-price data queries, file downloads, or one-off tool calls. + +Its limits are equally clear: when the real cost is only known after execution, the server cannot treat `exact` as a blank cheque it may mark up at will. For inference, bandwidth, or compute tasks with uncertain pricing, use `upto` instead — or split the price into stages that can each be quoted up front. + +### 4.2 Exact Gasfree: paying on TRON without TRX + +`exact_gasfree` is a TRON-only fixed-amount scheme. The payer can pay in USDT or USDD without holding TRX in their ordinary wallet; the official GasFree Proxy/relayer path submits the transaction and pays the corresponding on-chain resource cost. + +This is not universally "free" payment. The scheme requires the wallet, token, GasFree service, and Facilitator to all support the flow, and the fee may surface through service rules, asset balances, or the quote structure. Production deployments should explicitly check available assets, GasFree account status, fee configuration, and the failure fallback path — you cannot decide whether payment is possible from the main wallet's TRX balance alone. + +### 4.3 Upto: paying for actual usage + +`upto` lets the client authorize a maximum amount rather than fixing the final one in advance. After completing the work, the Resource Server submits an actual settlement amount — no greater than the cap — based on auditable metering. An agent might authorize "up to 0.10 USDT," and the model service charges 0.063 USDT based on actual input/output tokens, inference duration, or bandwidth used. + +The cap protects the payer; it is not a suggested value for the server. Final settlement must be less than or equal to the authorized cap. Providers should also publish their metering units, prices, rounding rules, and charging policy on failure — otherwise "usage-based" becomes an unexplainable bill. + +### 4.4 Batch Settlement: a channel scheme for high-frequency micropayments + +`batch-settlement` targets continuous, high-frequency service calls with small per-call amounts. The payer first creates a channel and deposits into it; each subsequent charge is represented by an off-chain signed cumulative voucher. The server verifies the voucher and can deliver immediately, then claims/settles in batches by request count, cumulative amount, or time window. No individual agent tool call has to wait for an on-chain transaction. + +It is not a drop-in replacement for single payments. Channel funds are locked up in advance, and both client and server must manage voucher state, validity, replay protection, retries, and final reconciliation. It therefore suits continuous retrieval, market-data subscriptions, multi-turn inference, and agent workflows; for occasional one-off calls, `exact` or `upto` is usually more direct. + +### 4.5 Choosing a scheme + +| Business condition | Preferred scheme | Why, and what it assumes | +| --- | --- | --- | +| Fixed-price API, download, one-off result | `exact` | Terms and amount can be determined before execution. | +| Payer wallet holds no TRX, but uses supported assets and services | `exact_gasfree` | Depends on joint support from GasFree Proxy, relayer, and Facilitator. | +| Price depends on actual tokens, duration, or bandwidth | `upto` | Authorize a cap first, settle on actual usage after. | +| High-frequency, small-amount, continuous calls | `batch-settlement` | Channels and off-chain vouchers remove the need to go on-chain every call. | + +## 5. Batch Settlement in depth + +### 5.1 Why it exists + +`exact` and `upto` both fit "one request, one settlement": once payment terms are clear, the server verifies and submits the corresponding on-chain settlement. That premise becomes a bottleneck in high-frequency micropayments — per-transaction network cost can exceed the price of the service itself, on-chain confirmation stretches out the HTTP response, and continuous retrieval, market-data subscriptions, or multi-turn agent orchestration generate far too many transactions. + +The core idea of `batch-settlement` is to decouple *access authorization* from *final value transfer*. The agent submits a verifiable payment commitment with each request; the server verifies it and delivers immediately, while the actual collection of funds happens later, in batches. The settlement result the client receives can be channel state or a credential identifier rather than a transaction hash per call. + +In BANK OF AI x402, Batch Settlement can use the appropriate channel implementation per network. On TRON it takes the form of a unidirectional payment channel: funds are locked in the channel first, off-chain vouchers cover many charges, and the Facilitator ultimately submits batched on-chain claims on the provider's behalf. It reduces how often each call touches the chain — it does not eliminate the engineering cost of locked capital, state storage, reconciliation, and dispute handling. + +### 5.2 The mechanics + +- **Deposit**: the payer creates or identifies a channel with an immutable `ChannelConfig` and deposits payable assets. The config binds payer, recipient, token, authorizer, withdrawal delay, and a random salt; the channel ID derives deterministically from that config, the network, and the contract address. +- **Voucher**: each call is signed by the agent as a cumulative credential whose key field is `maxClaimableAmount`. It means "as of this call, the provider may claim at most this much" — not an isolated small transfer. +- **Claim**: the provider submits one or more latest vouchers, registering the claimable amount on-chain as `totalClaimed`. This step confirms the debt but does not necessarily transfer tokens yet. +- **Settle**: consolidates registered amounts for the same recipient and token into an actual transfer out. A single `settle` can cover multiple channels and a large number of requests — this is where the batch cost advantage really comes from. +- **Refund / Withdraw**: a cooperative refund returns unused balance immediately; if the provider does not cooperate, the payer can initiate a unilateral withdrawal with a waiting period, ensuring funds are never locked permanently. + +Cumulative vouchers are also the key to replay protection. The cap on call N equals "cumulative amount already charged + the cap acceptable for this call," so a new credential naturally supersedes the previous, lower cap; the server only needs to keep the latest state, and an old credential replayed cannot increase the claimable amount. Before signing again, the client should check `chargedAmount`, the cumulative amount, channel balance, and `channelId` — and on any mismatch, stop signing and move to recovery or withdrawal. + +### 5.3 The full flow + +![Batch Settlement payment channel and cumulative vouchers](/img/devnotes/batch-settlement-channel.svg) + +The flow in the diagram splits into three phases. The first two solve "how to establish a payable balance" and "how to call continuously without waiting for on-chain confirmation"; only the third formally settles the accumulated charges. + +#### Phase 1: Open the channel (the one on-chain transaction) + +1. **The client submits the deposit payload**: on first use, or when the channel balance runs out, the Agent Wallet sends the `ChannelConfig`, the first voucher, and a token deposit authorization. `ChannelConfig` fixes payer, recipient, token, authorizer, withdrawal delay, and salt, and derives a deterministic `channelId`. +2. **The Resource Server requests verification and deposit**: the server hands the payload to the Facilitator, which runs `/verify` and `/settle(deposit)`; after validating the signature and deposit authorization, it places the assets into the channel escrow contract. +3. **The channel is ready**: the on-chain channel holds the funds and initial state. From here on the payer submits no on-chain transaction per call, and the Facilitator covers the resource cost of that one on-chain operation. + +#### Phase 2: High-frequency requests (local signing, off-chain execution) + +1. **The client signs a new cumulative voucher**: for each request, the Agent Wallet updates `maxClaimableAmount` to "historical cumulative charged + the maximum fee acceptable this time," signing entirely locally. +2. **The server verifies locally and does the work**: the Resource Server validates the voucher, channel config, cumulative cap, and balance without touching the chain for this request; once valid, it immediately runs the inference, retrieval, or other paid service. +3. **The server returns a billing snapshot**: the server returns `200 OK`, the actual `chargedAmount`, and `channelState`. The actual fee must not exceed the voucher cap; the client checks amount, cumulative value, balance, and `channelId` before signing again. +4. **New credentials supersede old ones**: after N repetitions on the same channel, the server only needs to persist the latest cumulative voucher and `chargedCumulativeAmount`. Older, lower-amount credentials cannot increase the claimable amount, so there is no need to manage a nonce per call. + +#### Phase 3: Batch settlement (on-chain, by policy) + +1. **Choose when to settle**: the server can trigger settlement on a fixed interval, a cumulative-amount threshold, or a payer-initiated withdrawal, then pull the latest vouchers from multiple channels. +2. **Claim — confirm claimable amounts in bulk**: the server asks the Facilitator to call `/settle(claim)`, which bundles the latest credentials across channels and submits `claimWithSignature`, registering the cumulative amount as `totalClaimed`. The funds are still in the channel contract at this point. +3. **Settle — consolidate and transfer to the recipient**: the Facilitator then uses `/settle(settle)` to consolidate the accounted funds for the same recipient and token, executing one actual token transfer. +4. **Exit and refund**: once the service is done, unused balance can be returned via a cooperative `refund`; if the payer calls `initiateWithdraw`, the provider must complete its claim within `withdrawDelay`, after which the payer can `finalizeWithdraw` to recover whatever was not claimed. + +### 5.4 Settlement strategy + +Settlement can be triggered three ways: periodic settlement makes network cost and accounting rhythm predictable; an amount threshold caps the provider's unclaimed risk exposure; settling only when the payer withdraws is the most gas-efficient but leaves the provider with the greatest "failed to claim in time" risk. Production systems usually combine a threshold with a maximum wait rather than relying on a single strategy. + +You must distinguish four states: "request succeeded," "voucher accepted," "claim is on-chain," and "tokens settled." The server should store the latest state atomically, indexed by `channelId` and cumulative amount; on-chain retries should be judged by transaction hash, events, and idempotency keys. For the payer, the risk ceiling is the `maxClaimableAmount` of signed vouchers; for the provider, the key risk is failing to claim within `withdrawDelay` after the payer starts withdrawing. + +### 5.5 Benefits and costs + +The benefits are fewer on-chain transactions, lower average settlement overhead, and a shorter service path that never waits for per-call confirmation. It suits cases where per-call value is close to or below network cost, low latency matters, and the same payer keeps calling the same provider. + +The costs are just as concrete: the payer's funds are locked up front; the server must persist and correctly recover channel state; the client must check every billing snapshot; and both sides must handle offline credentials, retries, channel closure, and exit windows. For occasional one-off calls, `exact` or `upto` is often simpler; for high-value transactions needing protocol-level refund guarantees, evaluate a more suitable escrow/capture model. Use the channel management and recovery logic the SDK provides rather than assembling vouchers and a settlement state machine yourself. + +## 6. End-to-end case study: an agent calling a paid inference service + +This chapter uses the **TRON Nile testnet** to show how an agent uses TRC-20 stablecoins to call a paid inference service through BANK OF AI x402's `batch-settlement` scheme. Production can switch the same flow to TRON mainnet; the protocol interaction, channel state, and voucher mechanics stay the same. + +### 6.1 The scenario + +Picture a research agent working through a cross-source analysis task. It needs to call the same inference service repeatedly: summarize a batch of documents, ask multiple rounds of follow-up questions, extract structured conclusions, and finally generate a report. Each call costs very little, but the whole task may produce dozens to hundreds of requests within tens of minutes. + +If every inference settled separately on TRON, the service response would be dragged out by on-chain interaction and network cost would eat the economics of micropayments. So we use `batch-settlement`: on the first call the agent opens and funds a payment channel on **TRON Nile** with TRC-20 USDT or USDD; each subsequent inference only signs an incrementing voucher; the inference service returns results immediately and consolidates the charges for collection in the background. + +### 6.2 The inference service's billing model + +Unlike a fixed-price weather lookup, inference cost depends on the model, context length, and generation length. In the 402 requirement the server should state `network=TRON_NILE`, the acceptable TRC-20 assets (USDT or USDD, say), and the **maximum fee** for this call, spelling out input token price, output token price, model tier, and minimum billing unit. The agent's budget policy decides from that whether to sign the voucher; once the service completes, the actual fee must not exceed that call's cap. + +Beyond the model result, a successful inference response should return the following auditable information: + +| Response field | What it means for inference | What the agent checks | +| --- | --- | --- | +| `chargedAmount` | The actual fee for this call | Must not exceed the maximum fee signed for this call. | +| `channelState.chargedCumulativeAmount` | Cumulative spend for this task on the channel | Must equal the previous cumulative value plus this call's actual fee. | +| `channelState.balance` | Basis for remaining usable funds in the channel | Stop calling or fund a new channel when the balance runs low. | +| Usage breakdown | Input/output tokens, model version, billing rule version | Used for bill explanation, cost analysis, and anomaly auditing. | + +Batch Settlement is only responsible for aggregating multiple authorized charges into one settlement; *why this particular inference cost what it did* remains the job of the inference service's metering system, and should be disclosed to the payer along with the result. + +### 6.3 A worked billing example + +Suppose the agent has a 5 USDT research budget on TRON Nile and needs to summarize, cross-question, and report on 40 source materials. The service sets the per-inference cap at 0.10 USDT, with the actual price computed from input/output tokens. The payment process reads like this: + +1. **Task starts**: the agent uses its TRON wallet to open a channel and deposit 5 USDT on the first call. It does not need to know the exact cost of each inference in advance — only that each is capped at 0.10 USDT and the whole task at 5 USDT. +2. **First summary**: the agent signs a voucher capped at 0.10 USDT; the service actually uses 12,000 input tokens and 800 output tokens, charging 0.042 USDT. The response returns the summary, `chargedAmount=0.042`, and cumulative spend `0.042`. +3. **Subsequent inference**: before the second call, the agent signs a new cumulative cap built on the confirmed `0.042`. As retrieval, comparison, and rewriting proceed, the service keeps returning token usage and a new cumulative value; the agent stops signing the moment any amount, channel, or metering rule fails to line up. +4. **Threshold reached**: at, say, 1 USDT cumulative or 10 minutes elapsed, the server has the TRON Facilitator batch-claim the latest vouchers for this channel and other users' channels, then settles collectively by recipient and TRC-20 token. The model calls themselves never wait for this on-chain operation. +5. **Task ends**: when the report is finished, suppose 80 calls consumed 3.16 USDT. The signed vouchers let the provider claim that amount; the unspent 1.84 USDT returns to the agent through a cooperative refund or the withdrawal flow. + +In this case the inference metering, the agent's budget, and the payment channel each have clear boundaries: the metering system determines the actual fee, the agent decides whether to accept the next cap, and Batch Settlement consolidates charges that have already occurred. + +### 6.4 A minimal reference implementation + +The repository's `examples/typescript` provides a runnable reference with the same **TRON Nile** structure described above: it substitutes `GET /weather` for the inference endpoint, but the path through the first TRC-20 deposit, subsequent vouchers, and background claim/settle is identical. To use it for an inference service, replace the route's business logic with a model call and keep the `batch-settlement` TRON payment registration and channel management. + +The Facilitator is an indispensable settlement service on this TRON path. For a minimal integration, prefer the official BANK OF AI hosted Facilitator: on the Nile testnet set `FACILITATOR_URL` to `https://tn-facilitator.bankofai.io`, and switch to `https://facilitator.bankofai.io` for production. It handles the on-chain execution of verification, deposit, claim, settle, and refund. + +```ts +const facilitator = new HTTPFacilitatorClient({ + url: "https://tn-facilitator.bankofai.io", // TRON Nile + // In production use facilitator.bankofai.io and attach X-API-KEY to requests. +}); +``` + +On the client, the key steps are registering `BatchSettlementTronScheme` and wrapping a plain `fetch` into a payment-capable request function: + +```ts +import { resolveWallet } from "@bankofai/agent-wallet"; +import { x402Client, wrapFetchWithPayment } from "@bankofai/x402-fetch"; +import { createClientTronSigner, TRON_NILE } from "@bankofai/x402-tron"; +import { BatchSettlementTronScheme } from "@bankofai/x402-tron/batch-settlement/client"; + +const wallet = (await resolveWallet({ network: TRON_NILE })) as + Parameters[0]; +const signer = await createClientTronSigner(wallet, { network: TRON_NILE }); +const client = new x402Client((_version, accepts) => + accepts.find((item) => + item.scheme === "batch-settlement" && item.network === TRON_NILE, + )!, +); + +client.register( + TRON_NILE, + new BatchSettlementTronScheme(signer, { + depositPolicy: { depositMultiplier: 5 }, + }), +); + +const paidFetch = wrapFetchWithPayment(fetch, client); +const response = await paidFetch("https://inference.example.com/v1/generate"); +``` + +The server registers the same TRON scheme and runs the channel manager in the background: + +```ts +const scheme = new BatchSettlementTronScheme(process.env.TRON_ADDRESS!); +resourceServer.register(TRON_NILE, scheme); + +scheme.createChannelManager(facilitator, TRON_NILE).start({ + claimIntervalSecs: 60, + settleIntervalSecs: 120, + maxClaimsPerBatch: 100, +}); +``` + +## 7. Summary + +BANK OF AI x402 lets APIs quote and collect payment through an HTTP-native challenge–response, so agents can buy digital services on demand within a controlled budget. TRON provides first-class support for TRC-20 stablecoin settlement here: `exact` fits fixed quotes, `exact_gasfree` serves TRX-free wallets that meet the GasFree conditions, `upto` bounds actual usage within a pre-authorized cap, and `batch-settlement` reduces on-chain settlement frequency for high-frequency micropayments. + +A genuinely reliable agent payment system still has to implement protocol capability alongside product rules: least-privilege wallets, explicit asset and service allowlists, amount caps, short validity windows with replay protection, recoverable idempotent flows, auditable metering, and step-by-step validation from testnet to mainnet. That is what makes payment a capability agents can safely compose — rather than a new source of uncontrolled risk. + +--- + +## Related docs + +- [x402 Payment Protocol](/) — protocol overview and core concepts +- [x402 CLI](/x402/cli/) — pay and run paywalls from your terminal +- [SDK Features](/x402/sdk-features/) — which schemes the SDK supports diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/index.md b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/index.md index 80286c6c..cf8fd8be 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/index.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/index.md @@ -9,4 +9,4 @@ BANK OF AI 团队沉淀的实战经验——动手演练，以及让 AI 上链 ## 实践列表 -- [**手把手完成第一笔链上兑换**](./first-onchain-swap/) —— 在 Nile 测试网上完整走一遍真实任务，包括每一步该确认什么、出错了怎么办。 +- [**BANK OF AI x402：面向 AI 智能体的稳定币支付方案**](./x402-stablecoin-payments-for-agents/) —— HTTP 402 挑战—响应流程如何运作、`exact` / `exact_gasfree` / `upto` / `batch-settlement` 四种方案怎么选，以及一个基于 TRON 的端到端付费推理案例。 diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md new file mode 100644 index 00000000..5771b847 --- /dev/null +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md @@ -0,0 +1,268 @@ +--- +title: 'BANK OF AI x402：面向 AI 智能体的稳定币支付方案' +description: '从 HTTP 402 的挑战—响应流程，到 exact / exact_gasfree / upto / batch-settlement 四种支付方案的取舍，以及一个基于 TRON 的端到端付费推理案例。' +--- + +# BANK OF AI x402：面向 AI 智能体的稳定币支付方案 + +## 1. 当 AI 智能体开始需要支付 + +AI 智能体不只是读取公开信息。它会检索数据、调用模型、购买专业工具，甚至把一个任务交给另一个 Agent。在这些场景里，服务的消费者不再总是坐在浏览器前的人，而是会根据任务、价格和预算自行作出调用决策的软件。 + +传统收费方式为人工操作而设计：先注册账户、保存 API Key、购买套餐或预充值。它们仍然适合长期客户关系，却不擅长处理一次性的、跨服务的、金额很小的机器调用。调用方必须预先开户和授信，服务方又要维护账户、额度和账单；一项临时需要的能力也可能因此无法被 Agent 自主购买。 + +x402 把支付协商放回 HTTP 请求本身。服务先说明「这个资源需要什么付款」，客户端在理解条件后签署付款凭证并重试请求。于是，按次付费可以与 API 调用处于同一交互闭环：没有预先建立账户关系，也不需要把支付页面塞进 Agent 的执行路径。 + +## 2. BANK OF AI x402 与 TRON + +### 2.1 x402 是什么 + +HTTP `402 Payment Required` 长期保留为「需要支付」的状态码。x402 将它变成一次可机器处理的挑战—响应流程： + +1. 客户端请求受保护的资源。 +2. Resource Server 返回 `402`，并在 `PAYMENT-REQUIRED` 头中提供一个或多个可接受的 Payment Requirements，例如网络、资产、金额、收款方、有效期和支付方案。 +3. 客户端选择自己能够满足的一项要求，使用钱包签署 Payment Payload，并在重试请求中通过 `PAYMENT-SIGNATURE` 头携带它。 +4. 服务端验证付款；必要时由 Facilitator 验证签名和链上可结算性，并在结算后向客户端返回资源与 `PAYMENT-RESPONSE`。 + +Payment Requirements 是服务端的报价与约束，Payment Payload 是客户端对其中一项条件的签名响应。两者必须一起被验证：不能只验证「有一笔转账」，还必须确认网络、Token、金额、收款地址、有效期及所选 scheme 与最初的报价一致。 + +### 2.2 为什么优先支持 TRON + +TRON 为 x402 提供了面向稳定币的结算环境。对于以美元计价的 API、模型推理和数据服务，TRC-20 稳定币使报价与用户的成本预期更直接；网络也适合需要频繁、小额支付的应用。当前 SDK 支持 TRON Nile、Shasta 测试网及主网，开发时应先在测试网完成全链路验证。 + +但「低成本」不是「零成本」。普通 TRON 交易仍涉及带宽、能量或 TRX；确认时间、RPC 可用性、Token 合约支持及 Facilitator 的流动性与风控策略都会影响真实体验。BANK OF AI x402 的价值在于以统一的 HTTP 支付协议接入这些稳定币能力，而不是保证任何 Token、钱包或网络条件下都能自动付款。 + +### 2.3 BANK OF AI x402 + +BANK OF AI x402 完全兼容 Coinbase x402 的核心 HTTP 支付协议与交互模型：服务端以 `402 Payment Required` 发布支付要求，客户端签署支付凭证后重试请求，并通过标准化的验证与结算流程完成交付。因此，支持 x402 的 Agent、Resource Server 和 Facilitator 可以复用相同的协议模型。BANK OF AI 的扩展重点位于多网络、稳定币资产以及相应的签名和结算实现层；TRON 则是本文重点展开的结算网络。 + +在 TRON 生态中，[BANK OF AI](/zh-Hans/BANK-OF-AI/Intro/) 将自身定位为「你的 Web3 AI 门户」，为 Agent 提供付款、身份、行动与认知能力。其架构可分为四层：基础设施层提供区块链网络、基础模型、稳定币资产与合约；协议层由 MCP、x402 和 8004 构成，分别定义 Agent 的工具交互、链上支付以及身份与信誉；Agent 能力与平台服务层覆盖 Agent 集成与 Skills、钱包签名、开发工具与 SDK、x402 支付服务及 MCP 服务；生态与应用层则面向 AI Agent、Agent 应用和 Marketplace。 + +![BANK OF AI 产品矩阵](/img/devnotes/bankofai-product-matrix.svg) + +在这套分层中，x402 是协议层的开放支付协议，与负责 Agent 身份和信誉的 8004 并列；MCP 则定义 Agent 与工具之间的上下文交互方式。x402 Gateway、x402 Facilitator、Agent Wallet、Skills 及各类 MCP Server 位于平台服务层，将这些协议转化为可直接调用的能力。各层可独立使用，也可按场景组合：需要支付时使用 x402，需要验证身份或信誉时使用 8004，需要连接工具或链上服务时通过 MCP。 + +## 3. BANK OF AI x402 的架构与支付流程 + +### 3.1 核心参与方 + +- **AI Agent 与 Agent Wallet**：Agent 决定是否购买资源；钱包保存密钥、检查预算和策略，并为付款要求生成 TIP-712 签名。私钥不应交给 Resource Server 或 Facilitator。 +- **Resource Server**：提供受保护资源，生成 Payment Requirements，在验证和结算成功后交付内容或执行服务。 +- **Facilitator**：按网络和 scheme 验证支付凭证、模拟或提交链上结算，并返回可审计的结果。它可以独立部署，也可以由服务端承担相同的逻辑职责。 +- **区块链网络与支付合约**：承载资产、授权及结算交易；不同 scheme 可能依赖不同的合约或代理。本文的支付流程图以 TRON 和 TRC-20 资产为例。 + +### 3.2 一次完整的 x402 支付 + +![一次完整的 BANK OF AI x402 支付](/img/devnotes/tron-x402-payment-flow.svg) + +1. Agent 向付费端点发送普通 HTTP 请求。 +2. Resource Server 返回 `402 Payment Required`，公布可接受的支付选项。 +3. Agent 的选择器从中挑选支持的网络、资产与 scheme；钱包同时检查余额、额度、收款方和有效期。 +4. 钱包为所选要求签署 Payment Payload，Agent 带着 `PAYMENT-SIGNATURE` 重试原请求。 +5. Resource Server 将 requirements 与 payload 交给 Facilitator 验证；在交付前或交付后结算，取决于服务自身的价值和失败处理策略。 +6. Facilitator 返回验证/结算结果及交易标识，Resource Server 交付资源，并以 `PAYMENT-RESPONSE` 向客户端回传结果。 + +### 3.3 核心协议数据 + +- **`PAYMENT-REQUIRED`**：402 响应中的支付挑战，通常包含 `accepts` 列表。每项描述一种可支付的组合，而非笼统地说「请转账」。 +- **`PAYMENT-SIGNATURE`**：重试请求中的已编码支付响应，包含客户端接受的要求和 scheme 特定的签名 payload。 +- **`PAYMENT-RESPONSE`**：成功响应中的结算信息，例如最终结算金额、交易哈希或 scheme 的后续状态。 +- **Payment Requirements / Payload**：前者是报价，后者是对报价的可验证承诺。安全实现必须校验它们的绑定关系，并拒绝过期、篡改、重复使用或超额结算的凭证。 + +## 4. BANK OF AI x402 的支付方案 + +### 4.1 Exact：固定金额支付 + +`exact` 用于价格在调用前就确定的服务。服务端报价 0.01 USDT，客户端签署这笔确定金额，Facilitator 验证后一次性结算。它的心智模型最简单，适合单篇报告、固定价格的数据查询、文件下载或一次性工具调用。 + +它的限制同样明确：实际成本若在执行后才知道，服务端不能把 `exact` 当作一张可随意加价的空白支票。对价格不确定的推理、带宽或计算任务，应改用 `upto`，或先把价格拆成可预先报价的阶段。 + +### 4.2 Exact Gasfree：TRON 网络的无 TRX 支付 + +`exact_gasfree` 是 TRON 专用的固定金额方案。付款人可使用 USDT 或 USDD 支付，而无需在自己的普通钱包中持有 TRX；官方 GasFree Proxy/中继路径负责提交交易并支付相应的链上资源费用。 + +这不是普适的「免成本」付款。该方案要求钱包、Token、GasFree 服务与 Facilitator 都支持相应流程；费用可能通过服务规则、资产余额或报价结构体现。生产部署应显式检查可用资产、GasFree 账户状态、费用配置和失败回退路径，不能仅根据主钱包的 TRX 余额判断是否可付。 + +### 4.3 Upto：按实际用量支付 + +`upto` 让客户端授权一个最大金额，而不是预先确定最终金额。Resource Server 在完成工作后，依据可审计的计量结果提交一个不超过上限的实际结算金额。例如，Agent 可以授权「最多 0.10 USDT」，模型服务按实际输入/输出 Token、推理时长或带宽使用量收取 0.063 USDT。 + +上限是对付款人的保护，不是服务端的建议值：最终结算必须小于或等于授权上限。服务方也应公开计量单位、价格、舍入规则和失败时的收费政策，否则「按量」会变成不可解释的账单。 + +### 4.4 Batch Settlement：高频微支付的通道方案 + +`batch-settlement` 面向连续、高频且单笔金额较小的服务调用。付款方先创建通道并 Deposit，之后每次消费由链下签名的累积 Voucher 表示；服务端验证 Voucher 后即可交付服务，再按请求数量、累计金额或时间窗口批量 Claim/Settle。这样无需让每一次 Agent 工具调用都等待链上交易。 + +它并非单笔支付的简单替代。通道资金会被预先占用，客户端和服务端都需要管理 Voucher 状态、有效期、重放防护、失败重试与最终对账。因此，它适合持续检索、行情订阅、多轮推理和 Agent 工作流；偶发的单次调用通常仍以 `exact` 或 `upto` 更为直接。 + +### 4.5 支付方案选择 + +| 业务条件 | 优先方案 | 原因与前提 | +| --- | --- | --- | +| 固定价格 API、下载、一次性结果 | `exact` | 条件和金额可在执行前确定。 | +| 付款钱包没有 TRX，但使用受支持资产和服务 | `exact_gasfree` | 依赖 GasFree Proxy、中继与 Facilitator 的共同支持。 | +| 价格取决于实际 Token、时长或带宽 | `upto` | 先授权上限，后按实际用量结算。 | +| 高频、小额、连续调用 | `batch-settlement` | 以通道与链下 Voucher 减少每次调用都上链的需要。 | + +## 5. Batch Settlement：面向高频智能体调用的批量结算 + +### 5.1 为什么需要 Batch Settlement + +`exact` 和 `upto` 都适合「一次请求，一次结算」：付款条件明确后，服务端验证并提交对应的链上结算。但这一前提在高频微支付中会成为瓶颈——单笔网络成本可能超过服务本身的价格，链上确认会拉长 HTTP 响应，持续检索、行情订阅或多轮 Agent 编排也会产生过多交易。 + +`batch-settlement` 的核心是将「访问授权」与「最终价值转移」解耦。Agent 在每次请求时提交一份可验证的支付承诺，服务端验证通过后立即交付；真正的资金领取则在稍后按批次进行。客户端得到的结算结果可以是通道状态或凭证标识，而不必是每次调用的一笔交易哈希。 + +在 BANK OF AI x402 中，Batch Settlement 可在不同网络上采用相应的通道实现。以 TRON 为例，它表现为一个资金的单向支付通道：资金先锁定在通道中，链下 Voucher 覆盖多次消费，最终由 Facilitator 代表服务方批量提交链上领取。它降低的是每次调用的链上交互频率，不会消除资金占用、状态存储、对账和争议处理的工程成本。 + +### 5.2 核心机制 + +- **Deposit**：付款方以不可变的 `ChannelConfig` 创建或识别通道，并存入可支付资产。配置绑定付款方、收款方、Token、授权方、提现等待期与随机盐；通道 ID 由该配置、网络和合约地址确定性派生。 +- **Voucher**：每次调用由 Agent 签署一张累积凭证，核心字段是 `maxClaimableAmount`。它表示「截至这次调用，服务方最多可领取多少」，而不是一笔孤立的小额转账。 +- **Claim**：服务方提交一张或多张最新 Voucher，将可领取金额登记到链上 `totalClaimed`。这一步确认债权，但不一定立即转出 Token。 +- **Settle**：将同一收款方、同一 Token 下已登记的金额合并转出。一次 `settle` 可以覆盖多个通道和大量请求，这才是 batch 的主要成本优势。 +- **Refund / Withdraw**：合作退款可立即退回未用余额；若服务方不配合，付款方可发起带等待期的单边提现，保障资金不会永久锁定。 + +累积 Voucher 也是防重放的关键。第 N 次调用的上限等于「已计费累计金额 + 本次可接受的上限」，因此新凭证天然覆盖上一个较低的上限；服务端只需保留最新状态，旧凭证即使被重放也无法增加可领取金额。客户端在继续签署前应核对 `chargedAmount`、累计金额、通道余额和 `channelId`，不一致时停止签署并进入恢复或提现流程。 + +### 5.3 完整流程 + +![Batch Settlement 支付通道与累积凭证](/img/devnotes/batch-settlement-channel.svg) + +图中的流程可分为三个阶段。前两阶段分别解决「如何建立可支付余额」与「如何在不等待链上确认的情况下连续调用」；第三阶段才把累积的消费正式结算。 + +#### 阶段一：开通道（首次链上交易） + +1. **客户端提交 Deposit 载荷**：首次使用或通道余额耗尽时，Agent Wallet 发送 `ChannelConfig`、首张 Voucher 与 Token 存款授权。`ChannelConfig` 固定付款方、收款方、Token、授权方、提现等待期与 salt，并派生确定性的 `channelId`。 +2. **Resource Server 请求验证与存款**：服务端将载荷交给 Facilitator，执行 `/verify` 和 `/settle(deposit)`；Facilitator 验证签名与存款授权后，把资产存入通道托管合约。 +3. **通道准备就绪**：链上通道保存资金与初始状态。此后付款方不必为每次调用再提交链上交易；Facilitator 负责该次链上操作的资源费用。 + +#### 阶段二：高频请求（本地签名，链下执行） + +1. **客户端签署新的累积 Voucher**：每次请求，Agent Wallet 将 `maxClaimableAmount` 更新为「历史已计费累计金额 + 本次可接受的最高费用」，并只在本地完成签名。 +2. **服务端本地验签并执行业务**：Resource Server 验证 Voucher、通道配置、累计上限与余额，无需为这一笔请求访问链上；验证通过后立即执行推理、检索或其他付费服务。 +3. **服务端回传计费快照**：服务端返回 `200 OK`、本次实际 `chargedAmount` 与 `channelState`。实际费用不得超过 Voucher 的上限；客户端在下一次签名之前核对金额、累计值、余额和 `channelId`。 +4. **新凭证覆盖旧凭证**：同一通道重复 N 次后，服务端只需持久化最新的累积 Voucher 与 `chargedCumulativeAmount`。较低金额的旧凭证不会增加可领取金额，因此无需为每笔调用单独管理 nonce。 + +#### 阶段三：批量结算（按策略上链） + +1. **选择结算时机**：服务端可按固定周期、累计金额阈值或付款方发起提现来触发结算，并取出多个通道的最新 Voucher。 +2. **Claim：批量确认可领取金额**：服务端请求 Facilitator 调用 `/settle(claim)`；后者将多通道的最新凭证打包，提交 `claimWithSignature`，把累计金额登记为 `totalClaimed`。此时资金仍在通道合约中。 +3. **Settle：归集并转给收款方**：Facilitator 再通过 `/settle(settle)` 归集同一收款方、同一 Token 的已记账资金，并执行一次实际的 Token 转账。 +4. **退出与退款**：服务完成后可合作 `refund` 未用余额；若付款方发起 `initiateWithdraw`，服务方必须在 `withdrawDelay` 内完成 Claim，期满后付款方可 `finalizeWithdraw` 取回未被领取的余额。 + +### 5.4 批次结算策略 + +结算可按三种策略触发：定期结算使网络成本和账务节奏可预测；金额阈值限制服务方的未领取风险敞口；仅在付款方提现时结算最省 Gas，却让服务方承担最大的「未及时领取」风险。生产系统通常会将阈值与最长等待时间结合，而不是只依赖一种策略。 + +必须区分「请求成功」「Voucher 已接受」「Claim 已上链」和「Token 已 Settle」四种状态。服务端需以 `channelId` 与累计金额为索引，原子保存最新状态；链上重试则应依据交易哈希、事件和幂等键判断。对付款方而言，风险上限是已签 Voucher 的 `maxClaimableAmount`；对服务方而言，关键风险是付款方开始提现后未能在 `withdrawDelay` 内完成 Claim。 + +### 5.5 Batch Settlement 的收益与代价 + +收益是更少的链上交易、更低的平均结算开销，以及不必等待每次确认的更短服务路径。它适合单笔价值接近或低于网络成本、需要低延迟响应，且同一付款方会持续调用同一服务方的场景。 + +代价也很具体：付款方资金会预先占用；服务端需要持久化并正确恢复通道状态；客户端需要核对每次的计费快照；双方还要处理离线凭证、重试、通道关闭与退出窗口。对偶发的单次调用，`exact` 或 `upto` 往往更简单；对高价值且需要协议级退款保障的交易，也应评估更适合的托管/捕获模型。建议直接使用 SDK 提供的通道管理与恢复逻辑，而不要自行拼装 Voucher 和结算状态机。 + +## 6. 端到端应用案例：AI 智能体调用付费推理服务 + +本章以 **TRON Nile 测试网**为例，展示 Agent 如何使用 TRC-20 稳定币，通过 BANK OF AI x402 的 `batch-settlement` 方案调用付费推理服务。生产环境可将同一流程切换到 TRON 主网；协议交互、通道状态和 Voucher 机制保持不变。 + +### 6.1 案例场景 + +设想一个研究 Agent 正在完成一项跨来源的分析任务。它需要连续调用同一个推理服务：先摘要一批文档，再做多轮追问、抽取结构化结论，最后生成报告。每次调用的金额很小，但整个任务可能在几十分钟内产生数十到数百次请求。 + +如果每次推理都单独在 TRON 上结算，服务响应会被链上交互拖慢，网络成本也会吞噬微支付的经济性。这里采用 `batch-settlement`：Agent 首次调用时在 **TRON Nile** 上以 TRC-20 USDT 或 USDD 打开并充值支付通道；随后每次推理只签署一张递增的 Voucher；推理服务即时返回结果，并在后台把多次消费合并领取。 + +### 6.2 推理服务的计费模型 + +与固定价格天气查询不同，推理成本取决于模型、上下文长度和生成长度。服务端应在 402 要求中明确 `network=TRON_NILE`、可接受的 TRC-20 资产（如 USDT 或 USDD）和本次调用的**最高费用**，并将输入 Token 单价、输出 Token 单价、模型等级和最小计费单位写清楚。Agent 的预算策略据此决定是否签署 Voucher；服务完成后，实际费用必须不超过该次上限。 + +一次成功的推理响应除模型结果外，还应返回以下可审计信息： + +| 返回字段 | 推理服务中的含义 | Agent 的核对动作 | +| --- | --- | --- | +| `chargedAmount` | 本次实际收费 | 不得超过本次签署的最高费用。 | +| `channelState.chargedCumulativeAmount` | 本任务在该通道上的累计消费 | 必须等于上次累计值加本次实际收费。 | +| `channelState.balance` | 通道剩余可用资金的依据 | 余额不足时停止继续调用或充值新通道。 | +| 使用量明细 | 输入/输出 Token、模型版本、计费规则版本 | 用于账单解释、成本分析和异常审计。 | + +这样，Batch Settlement 只负责把多次已授权的消费聚合结算；「本次推理究竟为什么收费」仍由推理服务的计量系统负责，并应随结果一同公开给付款方。 + +### 6.3 一次研究任务的计费实例 + +假设 Agent 在 TRON Nile 上获得 5 USDT 的研究预算，要对 40 份材料做摘要、交叉提问和报告生成。服务将单次推理的上限设为 0.10 USDT，实际价格按输入/输出 Token 计算。支付过程可以这样理解： + +1. **任务开始**：Agent 使用 TRON 钱包在首次调用时打开通道并 Deposit 5 USDT。它不需要预先知道每次推理的精确成本，只需确认每次最高不超过 0.10 USDT、总任务不超过 5 USDT。 +2. **第 1 次摘要**：Agent 签署最高 0.10 USDT 的 Voucher；服务实际使用 12,000 输入 Token 和 800 输出 Token，计费 0.042 USDT。响应返回摘要、`chargedAmount=0.042` 以及累计消费 `0.042`。 +3. **后续推理**：第 2 次调用前，Agent 以已确认的 `0.042` 为基础签署新的累积上限。随着多轮检索、比较和改写进行，服务持续返回 Token 用量与新的累计值；Agent 发现任何金额、通道或计量规则不一致时立即停止签署。 +4. **达到结算阈值**：例如累计消费到 1 USDT 或经过 10 分钟，服务端通过 TRON Facilitator 将该通道及其他用户通道的最新 Voucher 批量 Claim，再按收款方与 TRC-20 Token 集中 Settle。模型调用本身始终不等待这次链上操作。 +5. **任务结束**：报告生成完成时，假设 80 次调用实际消费 3.16 USDT。已签 Voucher 使服务方可以领取这部分费用；未消费的 1.84 USDT 通过合作 Refund 或提现流程回到 Agent。 + +这个案例中，推理计量、Agent 预算和支付通道各自有明确边界：计量系统决定实际费用，Agent 决定是否接受下一次上限，Batch Settlement 则把已经发生的多次消费合并结算。 + +### 6.4 最小参考实现 + +仓库的 `examples/typescript` 提供了与上述 **TRON Nile** 结构相同的可运行参考实现：它以 `GET /weather` 代替推理端点，但首笔 TRC-20 Deposit、后续 Voucher 与后台 Claim/Settle 的路径完全一致。要将它用于推理服务，只需把路由业务替换为模型调用，并保留 `batch-settlement` 的 TRON 支付注册与通道管理。 + +Facilitator 是这条 TRON 路径中不可缺少的结算服务。最小接入建议优先使用 BANK OF AI 官方托管 Facilitator：在 Nile 测试网将 `FACILITATOR_URL` 配置为 `https://tn-facilitator.bankofai.io`；切换生产环境时使用 `https://facilitator.bankofai.io`。它负责验证、Deposit、Claim、Settle 与 Refund 的链上执行。 + +```ts +const facilitator = new HTTPFacilitatorClient({ + url: "https://tn-facilitator.bankofai.io", // TRON Nile + // 生产环境使用 facilitator.bankofai.io，并为请求附带 X-API-KEY。 +}); +``` + +客户端的关键是注册 `BatchSettlementTronScheme`，再将普通 `fetch` 包装为具备支付能力的请求函数： + +```ts +import { resolveWallet } from "@bankofai/agent-wallet"; +import { x402Client, wrapFetchWithPayment } from "@bankofai/x402-fetch"; +import { createClientTronSigner, TRON_NILE } from "@bankofai/x402-tron"; +import { BatchSettlementTronScheme } from "@bankofai/x402-tron/batch-settlement/client"; + +const wallet = (await resolveWallet({ network: TRON_NILE })) as + Parameters[0]; +const signer = await createClientTronSigner(wallet, { network: TRON_NILE }); +const client = new x402Client((_version, accepts) => + accepts.find((item) => + item.scheme === "batch-settlement" && item.network === TRON_NILE, + )!, +); + +client.register( + TRON_NILE, + new BatchSettlementTronScheme(signer, { + depositPolicy: { depositMultiplier: 5 }, + }), +); + +const paidFetch = wrapFetchWithPayment(fetch, client); +const response = await paidFetch("https://inference.example.com/v1/generate"); +``` + +服务端则注册同一 TRON scheme，并把通道管理器放在后台运行： + +```ts +const scheme = new BatchSettlementTronScheme(process.env.TRON_ADDRESS!); +resourceServer.register(TRON_NILE, scheme); + +scheme.createChannelManager(facilitator, TRON_NILE).start({ + claimIntervalSecs: 60, + settleIntervalSecs: 120, + maxClaimsPerBatch: 100, +}); +``` + +## 7. 总结 + +BANK OF AI x402 让 API 能用 HTTP 原生的挑战—响应方式报价和收款，令 Agent 可以在受控预算内按需购买数字服务。TRON 为其中的 TRC-20 稳定币结算提供了重点支持；`exact` 适合固定报价，`exact_gasfree` 面向满足 GasFree 条件的无 TRX 钱包，`upto` 将实际用量限制在预先授权的上限内，`batch-settlement` 则为高频微支付降低链上结算频率。 + +真正可靠的 Agent 支付系统仍需把协议能力与产品规则一起实现：最小权限的钱包、明确的资产和服务白名单、金额上限、短有效期与防重放、可恢复的幂等流程、可审计的计量，以及测试网到主网的逐步验证。这样，支付才会成为 Agent 可安全组合的一项能力，而不是新的不可控风险来源。 + +--- + +## 相关文档 + +- [x402 支付协议](/zh-Hans/) —— 协议总览与核心概念 +- [x402 CLI](/zh-Hans/x402/cli/) —— 在终端里支付与自建付费端点 +- [SDK 功能](/zh-Hans/x402/sdk-features/) —— 各支付方案的 SDK 支持情况 diff --git a/sidebarsDevnotes.js b/sidebarsDevnotes.js index 3df9c642..0840ad18 100644 --- a/sidebarsDevnotes.js +++ b/sidebarsDevnotes.js @@ -6,7 +6,8 @@ const sidebars = { id: 'index', label: 'Overview', }, - 'first-onchain-swap', + 'x402-stablecoin-payments-for-agents', + // 'first-onchain-swap', // 暂时隐藏（文件保留） ], } diff --git a/static/img/devnotes/bankofai-product-matrix.svg b/static/img/devnotes/bankofai-product-matrix.svg new file mode 100644 index 00000000..cc18adf4 --- /dev/null +++ b/static/img/devnotes/bankofai-product-matrix.svg @@ -0,0 +1,161 @@ + + BANK OF AI 五层架构 + BANK OF AI 由生态与应用、Agent 平台服务、开发工具与 SDK、协议和基础设施五层组成。浅灰色模块代表外部生态与依赖。 + + + + + + BANK OF AI: 面向AI Agent的Web3基础设施 + + + BANK OF AI + + External / Standard + + + + + + + + + 生态与应用层 + + + + + Agent Harness + Claude Code · Cursor · Codex + + + + Agent Applications + Payment Agent · DeFi Agent + + + + Marketplaces + x402 Marketplace · Skill Catalog + + + + + + + + Agent 平台服务层 + + + + + Agent Integration & Skills + BAIclaw · OpenClaw Extension · BANK OF AI Skills + + + + Agent Wallet + Privy · wallet-cli + + + + x402 Payment Services + x402 Gateway · x402 Facilitator · x402 Recharge Server + + + + MCP Services + TRON MCP Server · SUN MCP Server · JustLend MCP Server · TronScan MCP Server + + + + + + + + 开发工具与 SDK + + + + + x402 SDK + Client SDK · Server SDK + + + + 8004 SDK + Identity Registration · Credentials + + + + CLI Tooling + x402 CLI · SUN CLI · wallet-cli + + + + + + + + 协议层 + + + + + MCP + Model Context Protocol + + + + x402 Protocol + HTTP-native Payment Standard + + + + 8004 Protocol + On-chain Agent Identity & Trust + + + + + + + + 基础设施层 + + + + + + Wallet-cli + Wallet · Transfer + Staking · Governance + + + + Contracts + x402 · 8004 + + + + Assets + USDT · USDD · USDC + + + + Blockchain Networks + TRON · BNB Chain · Base + + + + LLM Service + Unified OpenAI-compatible API · Model Routing · x402 Billing + + + + Foundation Models + GPT · Claude · Gemini · Kimi · GLM · DeepSeek + + + + diff --git a/static/img/devnotes/batch-settlement-channel.svg b/static/img/devnotes/batch-settlement-channel.svg new file mode 100644 index 00000000..ff7b28ae --- /dev/null +++ b/static/img/devnotes/batch-settlement-channel.svg @@ -0,0 +1,28 @@ + + + + + + + + Bank of AI x402 Batch Settlement：单向支付通道 + 累积凭证 + 客户端（payer） + 资源服务器 + Facilitator + Settlement Contract通道托管合约 + + 阶段一：开通道（首次，一次性链上交易，Facilitator 代付 Gas） + deposit 载荷：ChannelConfig + 首张凭证 + 资产存款授权 + /verify + /settle(deposit) + 存入托管，channelId =Hash(ChannelConfig) + 阶段二：高频请求（每笔仅一次本地签名，零链上交互、零 Gas） + 凭证：maxClaimableAmount = 已计费累计 + 本次上限（累积递增） + 凭证可本地验签（无 RPC）→ 执行业务实际计费 ≤ 上限（动态定价），累计入 chargedCumulativeAmount + 200 OK + chargedAmount + channelState 快照（客户端逐笔核对）… 重复 N 次，新凭证自然覆盖旧凭证，无需 nonce … + 阶段三：批量结算（服务器自主择机：定期 / 阈值 / 提现触发） + /settle(claim)：多通道最新凭证打包 + claimWithSignature：只记账 + /settle(settle)：归集已记账资金 + settle：一笔转账给 receiver + 逃生通道：合作退款（refund，即时）或限时提现（initiateWithdraw → 等待 withdrawDelay 15分钟~30天 → finalizeWithdraw） + diff --git a/static/img/devnotes/tron-x402-payment-flow.svg b/static/img/devnotes/tron-x402-payment-flow.svg new file mode 100644 index 00000000..b45801a3 --- /dev/null +++ b/static/img/devnotes/tron-x402-payment-flow.svg @@ -0,0 +1,14 @@ + + 一次完整的 Bank of AI x402 支付六步时序图：请求资源、收到 402、选择方案、签名重试、验证并结算、返回资源与支付结果。 + + 一次完整的 Bank of AI x402 支付 + AI Agent + WalletResource ServerFacilitatorBlockchain Network + + ① 请求付费资源GET /paid-resource + ② 返回 402 Payment RequiredPAYMENT-REQUIRED · accepts[] + ③ 选择支付要求并签名检查网络、资产、额度、收款方与有效期 + ④ 携带支付凭证重试请求PAYMENT-SIGNATURE + Payment Payload + ⑤ 验证并完成结算/verify：校验 requirements 与 payload/settle：提交链上交易交易与结算结果 + ⑥ 返回资源与支付结果200 OK · PAYMENT-RESPONSE · 交易标识 + 服务端需以支付标识、授权 nonce 或 Voucher 维护幂等性，避免重试造成重复扣款或重复交付。 + From 60280c186ec4287ea8334edf2b6c6146ae88f930 Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 16:01:31 +0800 Subject: [PATCH 2/9] add version --- package.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package.json b/package.json index 8d1f7526..c79f15c0 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "@x402-tron/docs", - "version": "1.3.10", + "version": "1.3.14", "description": "x402-tron documentation", "license": "MIT", "resolutions": { From a58b7bdc852b72308300b426ddbac6758bd5679c Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 16:18:26 +0800 Subject: [PATCH 3/9] add example url --- devnotes/x402-stablecoin-payments-for-agents.md | 2 +- .../current/x402-stablecoin-payments-for-agents.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/devnotes/x402-stablecoin-payments-for-agents.md b/devnotes/x402-stablecoin-payments-for-agents.md index a4f9b6a7..a352eab6 100644 --- a/devnotes/x402-stablecoin-payments-for-agents.md +++ b/devnotes/x402-stablecoin-payments-for-agents.md @@ -201,7 +201,7 @@ In this case the inference metering, the agent's budget, and the payment channel ### 6.4 A minimal reference implementation -The repository's `examples/typescript` provides a runnable reference with the same **TRON Nile** structure described above: it substitutes `GET /weather` for the inference endpoint, but the path through the first TRC-20 deposit, subsequent vouchers, and background claim/settle is identical. To use it for an inference service, replace the route's business logic with a model call and keep the `batch-settlement` TRON payment registration and channel management. +The repository's [`examples/typescript`](https://github.com/BofAI/x402/tree/main/examples/typescript) provides a runnable reference with the same **TRON Nile** structure described above: it substitutes `GET /weather` for the inference endpoint, but the path through the first TRC-20 deposit, subsequent vouchers, and background claim/settle is identical. To use it for an inference service, replace the route's business logic with a model call and keep the `batch-settlement` TRON payment registration and channel management. The Facilitator is an indispensable settlement service on this TRON path. For a minimal integration, prefer the official BANK OF AI hosted Facilitator: on the Nile testnet set `FACILITATOR_URL` to `https://tn-facilitator.bankofai.io`, and switch to `https://facilitator.bankofai.io` for production. It handles the on-chain execution of verification, deposit, claim, settle, and refund. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md index 5771b847..b9e223fb 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md @@ -201,7 +201,7 @@ BANK OF AI x402 完全兼容 Coinbase x402 的核心 HTTP 支付协议与交互 ### 6.4 最小参考实现 -仓库的 `examples/typescript` 提供了与上述 **TRON Nile** 结构相同的可运行参考实现：它以 `GET /weather` 代替推理端点，但首笔 TRC-20 Deposit、后续 Voucher 与后台 Claim/Settle 的路径完全一致。要将它用于推理服务，只需把路由业务替换为模型调用，并保留 `batch-settlement` 的 TRON 支付注册与通道管理。 +仓库的 [`examples/typescript`](https://github.com/BofAI/x402/tree/main/examples/typescript) 提供了与上述 **TRON Nile** 结构相同的可运行参考实现：它以 `GET /weather` 代替推理端点，但首笔 TRC-20 Deposit、后续 Voucher 与后台 Claim/Settle 的路径完全一致。要将它用于推理服务，只需把路由业务替换为模型调用，并保留 `batch-settlement` 的 TRON 支付注册与通道管理。 Facilitator 是这条 TRON 路径中不可缺少的结算服务。最小接入建议优先使用 BANK OF AI 官方托管 Facilitator：在 Nile 测试网将 `FACILITATOR_URL` 配置为 `https://tn-facilitator.bankofai.io`；切换生产环境时使用 `https://facilitator.bankofai.io`。它负责验证、Deposit、Claim、Settle 与 Refund 的链上执行。 From a5c997383a9d6de50cc32a601cffc5763594576e Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 16:32:53 +0800 Subject: [PATCH 4/9] add example url --- devnotes/x402-stablecoin-payments-for-agents.md | 2 +- .../current/x402-stablecoin-payments-for-agents.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/devnotes/x402-stablecoin-payments-for-agents.md b/devnotes/x402-stablecoin-payments-for-agents.md index a352eab6..d49c67d7 100644 --- a/devnotes/x402-stablecoin-payments-for-agents.md +++ b/devnotes/x402-stablecoin-payments-for-agents.md @@ -201,7 +201,7 @@ In this case the inference metering, the agent's budget, and the payment channel ### 6.4 A minimal reference implementation -The repository's [`examples/typescript`](https://github.com/BofAI/x402/tree/main/examples/typescript) provides a runnable reference with the same **TRON Nile** structure described above: it substitutes `GET /weather` for the inference endpoint, but the path through the first TRC-20 deposit, subsequent vouchers, and background claim/settle is identical. To use it for an inference service, replace the route's business logic with a model call and keep the `batch-settlement` TRON payment registration and channel management. +The repository's [examples/typescript](https://github.com/BofAI/x402/tree/main/examples/typescript) provides a runnable reference with the same **TRON Nile** structure described above: it substitutes `GET /weather` for the inference endpoint, but the path through the first TRC-20 deposit, subsequent vouchers, and background claim/settle is identical. To use it for an inference service, replace the route's business logic with a model call and keep the `batch-settlement` TRON payment registration and channel management. The Facilitator is an indispensable settlement service on this TRON path. For a minimal integration, prefer the official BANK OF AI hosted Facilitator: on the Nile testnet set `FACILITATOR_URL` to `https://tn-facilitator.bankofai.io`, and switch to `https://facilitator.bankofai.io` for production. It handles the on-chain execution of verification, deposit, claim, settle, and refund. diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md index b9e223fb..1aa95343 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md @@ -201,7 +201,7 @@ BANK OF AI x402 完全兼容 Coinbase x402 的核心 HTTP 支付协议与交互 ### 6.4 最小参考实现 -仓库的 [`examples/typescript`](https://github.com/BofAI/x402/tree/main/examples/typescript) 提供了与上述 **TRON Nile** 结构相同的可运行参考实现：它以 `GET /weather` 代替推理端点，但首笔 TRC-20 Deposit、后续 Voucher 与后台 Claim/Settle 的路径完全一致。要将它用于推理服务，只需把路由业务替换为模型调用，并保留 `batch-settlement` 的 TRON 支付注册与通道管理。 +仓库的 [examples/typescript](https://github.com/BofAI/x402/tree/main/examples/typescript) 提供了与上述 **TRON Nile** 结构相同的可运行参考实现：它以 `GET /weather` 代替推理端点，但首笔 TRC-20 Deposit、后续 Voucher 与后台 Claim/Settle 的路径完全一致。要将它用于推理服务，只需把路由业务替换为模型调用，并保留 `batch-settlement` 的 TRON 支付注册与通道管理。 Facilitator 是这条 TRON 路径中不可缺少的结算服务。最小接入建议优先使用 BANK OF AI 官方托管 Facilitator：在 Nile 测试网将 `FACILITATOR_URL` 配置为 `https://tn-facilitator.bankofai.io`；切换生产环境时使用 `https://facilitator.bankofai.io`。它负责验证、Deposit、Claim、Settle 与 Refund 的链上执行。 From 0c4194b7d3f2a4873201e2b031307a36df7cc4be Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 19:17:21 +0800 Subject: [PATCH 5/9] update --- .../x402-stablecoin-payments-for-agents.md | 4 +- .../x402-stablecoin-payments-for-agents.md | 4 +- .../img/devnotes/bankofai-product-matrix.svg | 130 +++++++++--------- 3 files changed, 67 insertions(+), 71 deletions(-) diff --git a/devnotes/x402-stablecoin-payments-for-agents.md b/devnotes/x402-stablecoin-payments-for-agents.md index d49c67d7..3305e6a1 100644 --- a/devnotes/x402-stablecoin-payments-for-agents.md +++ b/devnotes/x402-stablecoin-payments-for-agents.md @@ -36,11 +36,11 @@ But "low cost" is not "no cost." An ordinary TRON transaction still involves ban BANK OF AI x402 is fully compatible with the core HTTP payment protocol and interaction model of Coinbase x402: the server publishes payment requirements via `402 Payment Required`, the client signs a credential and retries, and delivery completes through a standardized verify-and-settle flow. Agents, Resource Servers, and Facilitators that support x402 can therefore reuse the same protocol model. BANK OF AI's extensions sit at the multi-network, stablecoin-asset, and corresponding signing/settlement implementation layers — with TRON being the settlement network this article focuses on. -Within the TRON ecosystem, [BANK OF AI](/BANK-OF-AI/Intro/) positions itself as "your Web3 AI gateway," giving agents the ability to pay, prove identity, act, and reason. Its architecture divides into four layers. The infrastructure layer provides blockchain networks, foundation models, stablecoin assets, and contracts. The protocol layer consists of MCP, x402, and 8004 — defining agent tool interaction, on-chain payment, and identity/reputation respectively. The agent capability and platform services layer covers agent integration and Skills, wallet signing, developer tooling and SDKs, x402 payment services, and MCP services. The ecosystem and application layer serves AI agents, agent applications, and marketplaces. +Within the TRON ecosystem, [BANK OF AI](/BANK-OF-AI/Intro/) positions itself as "your Web3 AI gateway," giving agents the ability to pay, prove identity, act, and reason. The product matrix uses a three-layer architecture: the **ecosystem and application layer** serves agent harnesses, agent applications, and marketplaces; the **middle layer** holds agent platform services, developer tooling and SDKs, plus the MCP, x402, and 8004 protocols; the **infrastructure layer** provides multi-chain networks, stablecoin assets, on-chain contracts, and LLM capability. ![BANK OF AI product matrix](/img/devnotes/bankofai-product-matrix.svg) -In this layering, x402 is the protocol layer's open payment protocol, sitting alongside 8004 which handles agent identity and reputation; MCP defines how agents and tools exchange context. The x402 Gateway, x402 Facilitator, Agent Wallet, Skills, and the various MCP Servers live in the platform services layer, turning those protocols into directly callable capabilities. Each layer can be used on its own or combined as the scenario requires: x402 when you need to pay, 8004 when you need to verify identity or reputation, MCP when you need to connect to tools or on-chain services. +In this layering, x402 is the open payment protocol within the middle layer's protocol stack, sitting alongside 8004 which handles agent identity and reputation; MCP defines how agents and tools exchange context. The x402 Gateway, x402 Facilitator, x402 Recharge Server, Agent Wallet, Skills, and the various MCP Servers live in the platform services layer, turning those protocols into directly callable capabilities. Each layer can be used on its own or combined as the scenario requires: x402 when you need to pay, 8004 when you need to verify identity or reputation, MCP when you need to connect to tools or on-chain services. ## 3. Architecture and payment flow diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md index 1aa95343..98cfc864 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md @@ -36,11 +36,11 @@ TRON 为 x402 提供了面向稳定币的结算环境。对于以美元计价的 BANK OF AI x402 完全兼容 Coinbase x402 的核心 HTTP 支付协议与交互模型：服务端以 `402 Payment Required` 发布支付要求，客户端签署支付凭证后重试请求，并通过标准化的验证与结算流程完成交付。因此，支持 x402 的 Agent、Resource Server 和 Facilitator 可以复用相同的协议模型。BANK OF AI 的扩展重点位于多网络、稳定币资产以及相应的签名和结算实现层；TRON 则是本文重点展开的结算网络。 -在 TRON 生态中，[BANK OF AI](/zh-Hans/BANK-OF-AI/Intro/) 将自身定位为「你的 Web3 AI 门户」，为 Agent 提供付款、身份、行动与认知能力。其架构可分为四层：基础设施层提供区块链网络、基础模型、稳定币资产与合约；协议层由 MCP、x402 和 8004 构成，分别定义 Agent 的工具交互、链上支付以及身份与信誉；Agent 能力与平台服务层覆盖 Agent 集成与 Skills、钱包签名、开发工具与 SDK、x402 支付服务及 MCP 服务；生态与应用层则面向 AI Agent、Agent 应用和 Marketplace。 +在 TRON 生态中，[BANK OF AI](/zh-Hans/BANK-OF-AI/Intro/) 将自身定位为「你的 Web3 AI 门户」，为 Agent 提供付款、身份、行动与认知能力。产品矩阵采用三层架构：**生态与应用层**面向 Agent Harness、Agent 应用与 Marketplace；**中间层**包含 Agent 平台服务、开发工具与 SDK，以及 MCP、x402、8004 等协议；**基础设施层**提供多链网络、稳定币资产、链上合约与 LLM 能力。 ![BANK OF AI 产品矩阵](/img/devnotes/bankofai-product-matrix.svg) -在这套分层中，x402 是协议层的开放支付协议，与负责 Agent 身份和信誉的 8004 并列；MCP 则定义 Agent 与工具之间的上下文交互方式。x402 Gateway、x402 Facilitator、Agent Wallet、Skills 及各类 MCP Server 位于平台服务层，将这些协议转化为可直接调用的能力。各层可独立使用，也可按场景组合：需要支付时使用 x402，需要验证身份或信誉时使用 8004，需要连接工具或链上服务时通过 MCP。 +在这套分层中，x402 是中间层协议栈里的开放支付协议，与负责 Agent 身份和信誉的 8004 并列；MCP 则定义 Agent 与工具之间的上下文交互方式。x402 Gateway、x402 Facilitator、x402 Recharge Server、Agent Wallet、Skills 及各类 MCP Server 位于平台服务层，将这些协议转化为可直接调用的能力。各层可独立使用，也可按场景组合：需要支付时使用 x402，需要验证身份或信誉时使用 8004，需要连接工具或链上服务时通过 MCP。 ## 3. BANK OF AI x402 的架构与支付流程 diff --git a/static/img/devnotes/bankofai-product-matrix.svg b/static/img/devnotes/bankofai-product-matrix.svg index cc18adf4..90786f51 100644 --- a/static/img/devnotes/bankofai-product-matrix.svg +++ b/static/img/devnotes/bankofai-product-matrix.svg @@ -1,6 +1,6 @@ - BANK OF AI 五层架构 - BANK OF AI 由生态与应用、Agent 平台服务、开发工具与 SDK、协议和基础设施五层组成。浅灰色模块代表外部生态与依赖。 + BANK OF AI 三层架构 + BANK OF AI 由生态与应用层、中间层和基础设施层组成；中间层包含 Agent 平台服务、开发工具与SDK、协议。浅灰色模块代表外部生态与依赖。 @@ -39,81 +39,77 @@ x402 Marketplace · Skill Catalog - - + + - + - Agent 平台服务层 - - - - - Agent Integration & Skills - BAIclaw · OpenClaw Extension · BANK OF AI Skills - - - - Agent Wallet - Privy · wallet-cli - - - - x402 Payment Services - x402 Gateway · x402 Facilitator · x402 Recharge Server - - - - MCP Services - TRON MCP Server · SUN MCP Server · JustLend MCP Server · TronScan MCP Server + 中间层 - - + + Agent 平台服务 + - - - 开发工具与 SDK - - - - - x402 SDK - Client SDK · Server SDK - - - - 8004 SDK - Identity Registration · Credentials - - - - CLI Tooling - x402 CLI · SUN CLI · wallet-cli + + + Agent Integration & Skills + BAIclaw · OpenClaw Extension · BANK OF AI Skills + + + + Agent Wallet + Privy · wallet-cli + + + + x402 Payment Services + x402 Gateway · x402 Facilitator · x402 Recharge Server + + + + MCP Services + TRON MCP Server · SUN MCP Server · JustLend MCP Server · TronScan MCP Server - - + + 开发工具与SDK + - - - 协议层 + + + x402 SDK + Client SDK · Server SDK + + + + 8004 SDK + Identity Registration · Credentials + + + + CLI Tooling + x402 CLI · SUN CLI · wallet-cli + + + 协议 + - - - MCP - Model Context Protocol - - - - x402 Protocol - HTTP-native Payment Standard - - - - 8004 Protocol - On-chain Agent Identity & Trust + + + MCP + Model Context Protocol + + + + x402 Protocol + HTTP-native Payment Standard + + + + 8004 Protocol + On-chain Agent Identity & Trust From 0e4b00046a1d73aee383336dd67404f0a4dce18a Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 20:14:06 +0800 Subject: [PATCH 6/9] update --- .../x402-stablecoin-payments-for-agents.md | 4 +- .../x402-stablecoin-payments-for-agents.md | 4 +- .../img/devnotes/bankofai-product-matrix.svg | 262 ++++++++---------- 3 files changed, 118 insertions(+), 152 deletions(-) diff --git a/devnotes/x402-stablecoin-payments-for-agents.md b/devnotes/x402-stablecoin-payments-for-agents.md index 3305e6a1..106eb057 100644 --- a/devnotes/x402-stablecoin-payments-for-agents.md +++ b/devnotes/x402-stablecoin-payments-for-agents.md @@ -36,11 +36,11 @@ But "low cost" is not "no cost." An ordinary TRON transaction still involves ban BANK OF AI x402 is fully compatible with the core HTTP payment protocol and interaction model of Coinbase x402: the server publishes payment requirements via `402 Payment Required`, the client signs a credential and retries, and delivery completes through a standardized verify-and-settle flow. Agents, Resource Servers, and Facilitators that support x402 can therefore reuse the same protocol model. BANK OF AI's extensions sit at the multi-network, stablecoin-asset, and corresponding signing/settlement implementation layers — with TRON being the settlement network this article focuses on. -Within the TRON ecosystem, [BANK OF AI](/BANK-OF-AI/Intro/) positions itself as "your Web3 AI gateway," giving agents the ability to pay, prove identity, act, and reason. The product matrix uses a three-layer architecture: the **ecosystem and application layer** serves agent harnesses, agent applications, and marketplaces; the **middle layer** holds agent platform services, developer tooling and SDKs, plus the MCP, x402, and 8004 protocols; the **infrastructure layer** provides multi-chain networks, stablecoin assets, on-chain contracts, and LLM capability. +Within the TRON ecosystem, [BANK OF AI](/BANK-OF-AI/Intro/) positions itself as "your Web3 AI gateway," giving agents the ability to pay, prove identity, act, and reason. The product matrix uses a three-layer architecture. The **application layer** is where agents run and get used — agent harnesses, agent applications, and marketplaces. The **middle layer** is what BANK OF AI provides — agent integration and Skills, Agent Wallet, x402 payment services, and MCP services, plus the x402 SDK, 8004 SDK, and the CLI tooling. The **infrastructure and standards layer** holds the protocol standards and the chain and model foundations they depend on — MCP / x402 / 8004, on-chain contracts and assets, and LLM services and foundation models. ![BANK OF AI product matrix](/img/devnotes/bankofai-product-matrix.svg) -In this layering, x402 is the open payment protocol within the middle layer's protocol stack, sitting alongside 8004 which handles agent identity and reputation; MCP defines how agents and tools exchange context. The x402 Gateway, x402 Facilitator, x402 Recharge Server, Agent Wallet, Skills, and the various MCP Servers live in the platform services layer, turning those protocols into directly callable capabilities. Each layer can be used on its own or combined as the scenario requires: x402 when you need to pay, 8004 when you need to verify identity or reputation, MCP when you need to connect to tools or on-chain services. +In this layering, x402 is the open payment protocol in the infrastructure and standards layer, sitting alongside 8004 which handles agent identity and reputation; MCP defines how agents and tools exchange context. The x402 Gateway, x402 Facilitator, x402 Recharge Server, Agent Wallet, Skills, and the various MCP Servers live in the middle layer, turning those protocols into directly callable capabilities. Each layer can be used on its own or combined as the scenario requires: x402 when you need to pay, 8004 when you need to verify identity or reputation, MCP when you need to connect to tools or on-chain services. ## 3. Architecture and payment flow diff --git a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md index 98cfc864..d2641112 100644 --- a/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md +++ b/i18n/zh-Hans/docusaurus-plugin-content-docs-devnotes/current/x402-stablecoin-payments-for-agents.md @@ -36,11 +36,11 @@ TRON 为 x402 提供了面向稳定币的结算环境。对于以美元计价的 BANK OF AI x402 完全兼容 Coinbase x402 的核心 HTTP 支付协议与交互模型：服务端以 `402 Payment Required` 发布支付要求，客户端签署支付凭证后重试请求，并通过标准化的验证与结算流程完成交付。因此，支持 x402 的 Agent、Resource Server 和 Facilitator 可以复用相同的协议模型。BANK OF AI 的扩展重点位于多网络、稳定币资产以及相应的签名和结算实现层；TRON 则是本文重点展开的结算网络。 -在 TRON 生态中，[BANK OF AI](/zh-Hans/BANK-OF-AI/Intro/) 将自身定位为「你的 Web3 AI 门户」，为 Agent 提供付款、身份、行动与认知能力。产品矩阵采用三层架构：**生态与应用层**面向 Agent Harness、Agent 应用与 Marketplace；**中间层**包含 Agent 平台服务、开发工具与 SDK，以及 MCP、x402、8004 等协议；**基础设施层**提供多链网络、稳定币资产、链上合约与 LLM 能力。 +在 TRON 生态中，[BANK OF AI](/zh-Hans/BANK-OF-AI/Intro/) 将自身定位为「你的 Web3 AI 门户」，为 Agent 提供付款、身份、行动与认知能力。产品矩阵采用三层架构：**应用层**是 Agent 运行和被使用的地方——Agent Harness、Agent 应用与 Marketplace；**中间层**是 BANK OF AI 提供的服务与开发工具——Agent 集成与 Skills、Agent Wallet、x402 支付服务、MCP 服务，以及 x402 SDK、8004 SDK 与各类 CLI；**基础设施与标准层**则是协议标准与所依赖的链上、模型基座——MCP / x402 / 8004 协议，链上合约与资产，以及 LLM 服务与基础模型。 ![BANK OF AI 产品矩阵](/img/devnotes/bankofai-product-matrix.svg) -在这套分层中，x402 是中间层协议栈里的开放支付协议，与负责 Agent 身份和信誉的 8004 并列；MCP 则定义 Agent 与工具之间的上下文交互方式。x402 Gateway、x402 Facilitator、x402 Recharge Server、Agent Wallet、Skills 及各类 MCP Server 位于平台服务层，将这些协议转化为可直接调用的能力。各层可独立使用，也可按场景组合：需要支付时使用 x402，需要验证身份或信誉时使用 8004，需要连接工具或链上服务时通过 MCP。 +在这套分层中，x402 是基础设施与标准层里的开放支付协议，与负责 Agent 身份和信誉的 8004 并列；MCP 则定义 Agent 与工具之间的上下文交互方式。x402 Gateway、x402 Facilitator、x402 Recharge Server、Agent Wallet、Skills 及各类 MCP Server 位于中间层，将这些协议转化为可直接调用的能力。各层可独立使用，也可按场景组合：需要支付时使用 x402，需要验证身份或信誉时使用 8004，需要连接工具或链上服务时通过 MCP。 ## 3. BANK OF AI x402 的架构与支付流程 diff --git a/static/img/devnotes/bankofai-product-matrix.svg b/static/img/devnotes/bankofai-product-matrix.svg index 90786f51..8b6bcbf5 100644 --- a/static/img/devnotes/bankofai-product-matrix.svg +++ b/static/img/devnotes/bankofai-product-matrix.svg @@ -1,157 +1,123 @@ - - BANK OF AI 三层架构 - BANK OF AI 由生态与应用层、中间层和基础设施层组成；中间层包含 Agent 平台服务、开发工具与SDK、协议。浅灰色模块代表外部生态与依赖。 + + BANK OF AI 架构：面向 AI Agent 的 Web3 基础设施 + 自上而下分为应用层、中间层、基础设施与标准层。中间层包含 BANK OF AI 提供的服务与开发工具。 + - + + + - - BANK OF AI: 面向AI Agent的Web3基础设施 - - - BANK OF AI - - External / Standard - - - - - - - - - 生态与应用层 - - - - - Agent Harness - Claude Code · Cursor · Codex - - - - Agent Applications - Payment Agent · DeFi Agent - - - - Marketplaces - x402 Marketplace · Skill Catalog - + - - - - - - 中间层 - + + BANK OF AI · ARCHITECTURE + 面向 AI Agent 的 Web3 基础设施 - - Agent 平台服务 - - - - - Agent Integration & Skills - BAIclaw · OpenClaw Extension · BANK OF AI Skills - - - - Agent Wallet - Privy · wallet-cli - - - - x402 Payment Services - x402 Gateway · x402 Facilitator · x402 Recharge Server - - - - MCP Services - TRON MCP Server · SUN MCP Server · JustLend MCP Server · TronScan MCP Server + + + - - - 开发工具与SDK - - - - - x402 SDK - Client SDK · Server SDK - - - - 8004 SDK - Identity Registration · Credentials - - - - CLI Tooling - x402 CLI · SUN CLI · wallet-cli + 01 + 应用层 + Agent 在哪里运行、被谁使用 + + + + Agent Harness + Claude Code · Cursor · Codex + + + + Agent Applications + Payment Agent · DeFi Agent + + + + Marketplaces + x402 Marketplace · Skill Catalog + + + + + + - - - 协议 - - - - - MCP - Model Context Protocol - - - - x402 Protocol - HTTP-native Payment Standard - - - - 8004 Protocol - On-chain Agent Identity & Trust - - - - - - - - 基础设施层 + 02 + 中间层 + BANK OF AI 提供的服务与开发工具 + + + + Agent Integration & Skills + BAIclaw · OpenClaw Extension · Skills + + + + Agent Wallet + Encrypted Keystore · Offline Signing + + + + x402 Payment Services + Gateway · Facilitator · Recharge Server + + + + MCP Services + TRON · SUN · JustLend · TronScan MCP Server + + + + x402 SDK + + 开发工具 + Client SDK · Server SDK + + + + 8004 SDK + + 开发工具 + Identity Registration · Credentials + + + + CLI Tooling + + 开发工具 + x402 CLI · SUN CLI · wallet-cli + + + + + + - - - - - Wallet-cli - Wallet · Transfer - Staking · Governance - - - - Contracts - x402 · 8004 - - - - Assets - USDT · USDD · USDC - - - - Blockchain Networks - TRON · BNB Chain · Base - - - - LLM Service - Unified OpenAI-compatible API · Model Routing · x402 Billing - - - - Foundation Models - GPT · Claude · Gemini · Kimi · GLM · DeepSeek - - - + 03 + 基础设施与标准层 + 协议标准与依赖的链上、模型基座 + + + + 协议标准 + x402 · HTTP-native Payment + 8004 · Agent Identity & Trust + MCP · Model Context Protocol（外部） + + + + 链上基础 + Wallet-cli · Wallet / Transfer / Staking + Contracts · x402 / 8004 + Assets · USDT / USDD / USDC（外部） + Blockchain Networks · TRON / BNB / Base（外部） + + + + 模型基座 + LLM Service · OpenAI-compatible API + Model Routing · x402 Billing + Foundation Models（外部） + GPT / Claude / Gemini / Kimi / GLM / DeepSeek From b55136875a862ef9f8c5803c9f0f03771944fe8f Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 20:23:32 +0800 Subject: [PATCH 7/9] update --- static/img/devnotes/bankofai-product-matrix.svg | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/static/img/devnotes/bankofai-product-matrix.svg b/static/img/devnotes/bankofai-product-matrix.svg index 8b6bcbf5..0db242a8 100644 --- a/static/img/devnotes/bankofai-product-matrix.svg +++ b/static/img/devnotes/bankofai-product-matrix.svg @@ -11,8 +11,8 @@ - BANK OF AI · ARCHITECTURE - 面向 AI Agent 的 Web3 基础设施 + ARCHITECTURE + BANK OF AI: 面向 AI Agent 的 Web3 基础设施 From 58f85ed688519fe0c9d2fb0241b0db996f682538 Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 21:05:29 +0800 Subject: [PATCH 8/9] update --- .../x402-stablecoin-payments-for-agents.md | 6 +- .../devnotes/bankofai-product-matrix-en.svg | 123 ++++++++++++++++++ .../devnotes/batch-settlement-channel-en.svg | 28 ++++ .../img/devnotes/batch-settlement-channel.svg | 2 +- .../devnotes/tron-x402-payment-flow-en.svg | 14 ++ .../img/devnotes/tron-x402-payment-flow.svg | 4 +- 6 files changed, 171 insertions(+), 6 deletions(-) create mode 100644 static/img/devnotes/bankofai-product-matrix-en.svg create mode 100644 static/img/devnotes/batch-settlement-channel-en.svg create mode 100644 static/img/devnotes/tron-x402-payment-flow-en.svg diff --git a/devnotes/x402-stablecoin-payments-for-agents.md b/devnotes/x402-stablecoin-payments-for-agents.md index 106eb057..9b0a6f89 100644 --- a/devnotes/x402-stablecoin-payments-for-agents.md +++ b/devnotes/x402-stablecoin-payments-for-agents.md @@ -38,7 +38,7 @@ BANK OF AI x402 is fully compatible with the core HTTP payment protocol and inte Within the TRON ecosystem, [BANK OF AI](/BANK-OF-AI/Intro/) positions itself as "your Web3 AI gateway," giving agents the ability to pay, prove identity, act, and reason. The product matrix uses a three-layer architecture. The **application layer** is where agents run and get used — agent harnesses, agent applications, and marketplaces. The **middle layer** is what BANK OF AI provides — agent integration and Skills, Agent Wallet, x402 payment services, and MCP services, plus the x402 SDK, 8004 SDK, and the CLI tooling. The **infrastructure and standards layer** holds the protocol standards and the chain and model foundations they depend on — MCP / x402 / 8004, on-chain contracts and assets, and LLM services and foundation models. -![BANK OF AI product matrix](/img/devnotes/bankofai-product-matrix.svg) +![BANK OF AI product matrix](/img/devnotes/bankofai-product-matrix-en.svg) In this layering, x402 is the open payment protocol in the infrastructure and standards layer, sitting alongside 8004 which handles agent identity and reputation; MCP defines how agents and tools exchange context. The x402 Gateway, x402 Facilitator, x402 Recharge Server, Agent Wallet, Skills, and the various MCP Servers live in the middle layer, turning those protocols into directly callable capabilities. Each layer can be used on its own or combined as the scenario requires: x402 when you need to pay, 8004 when you need to verify identity or reputation, MCP when you need to connect to tools or on-chain services. @@ -53,7 +53,7 @@ In this layering, x402 is the open payment protocol in the infrastructure and st ### 3.2 One complete x402 payment -![One complete BANK OF AI x402 payment](/img/devnotes/tron-x402-payment-flow.svg) +![One complete BANK OF AI x402 payment](/img/devnotes/tron-x402-payment-flow-en.svg) 1. The agent sends an ordinary HTTP request to a paid endpoint. 2. The Resource Server returns `402 Payment Required`, publishing the acceptable payment options. @@ -126,7 +126,7 @@ Cumulative vouchers are also the key to replay protection. The cap on call N equ ### 5.3 The full flow -![Batch Settlement payment channel and cumulative vouchers](/img/devnotes/batch-settlement-channel.svg) +![Batch Settlement payment channel and cumulative vouchers](/img/devnotes/batch-settlement-channel-en.svg) The flow in the diagram splits into three phases. The first two solve "how to establish a payable balance" and "how to call continuously without waiting for on-chain confirmation"; only the third formally settles the accumulated charges. diff --git a/static/img/devnotes/bankofai-product-matrix-en.svg b/static/img/devnotes/bankofai-product-matrix-en.svg new file mode 100644 index 00000000..9a54da81 --- /dev/null +++ b/static/img/devnotes/bankofai-product-matrix-en.svg @@ -0,0 +1,123 @@ + + BANK OF AI architecture: Web3 infrastructure for AI agents + Top to bottom: application layer, middle layer, infrastructure and standards layer. The middle layer holds the services and developer tooling BANK OF AI provides. + + + + + + + + + + + ARCHITECTURE + BANK OF AI: Web3 Infrastructure for AI Agents + + + + + + 01 + Application Layer + Where agents run and who uses them + + + + Agent Harness + Claude Code · Cursor · Codex + + + + Agent Applications + Payment Agent · DeFi Agent + + + + Marketplaces + x402 Marketplace · Skill Catalog + + + + + + + + 02 + Middle Layer + Services and developer tooling from BANK OF AI + + + + Agent Integration & Skills + BAIclaw · OpenClaw Extension · Skills + + + + Agent Wallet + Encrypted Keystore · Offline Signing + + + + x402 Payment Services + Gateway · Facilitator · Recharge Server + + + + MCP Services + TRON · SUN · JustLend · TronScan MCP Server + + + + x402 SDK + + Dev tool + Client SDK · Server SDK + + + + 8004 SDK + + Dev tool + Identity Registration · Credentials + + + + CLI Tooling + + Dev tool + x402 CLI · SUN CLI · wallet-cli + + + + + + + + 03 + Infrastructure & Standards + Protocol standards, plus the chain and model foundations they rely on + + + + Protocol Standards + x402 · HTTP-native Payment + 8004 · Agent Identity & Trust + MCP · Model Context Protocol (external) + + + + On-chain Foundation + Wallet-cli · Wallet / Transfer / Staking + Contracts · x402 / 8004 + Assets · USDT / USDD / USDC (external) + Blockchain Networks · TRON / BNB / Base (external) + + + + Model Foundation + LLM Service · OpenAI-compatible API + Model Routing · x402 Billing + Foundation Models (external) + GPT / Claude / Gemini / Kimi / GLM / DeepSeek + diff --git a/static/img/devnotes/batch-settlement-channel-en.svg b/static/img/devnotes/batch-settlement-channel-en.svg new file mode 100644 index 00000000..19e44f0c --- /dev/null +++ b/static/img/devnotes/batch-settlement-channel-en.svg @@ -0,0 +1,28 @@ + + + + + + + + BANK OF AI x402 Batch Settlement: channel + cumulative vouchers + Client (payer) + Resource Server + Facilitator + Settlement ContractChannel escrow contract + + Phase 1: Open the channel (one-time on-chain tx; Facilitator pays the gas) + deposit payload: ChannelConfig + first voucher + deposit authorization + /verify + /settle(deposit) + Deposited into escrow, channelId =Hash(ChannelConfig) + Phase 2: High-frequency requests (one local signature each — no chain, no gas) + Voucher: maxClaimableAmount = charged so far + this call's cap (cumulative) + Voucher verified locally (no RPC) → run the serviceActual charge ≤ cap (dynamic pricing), added to chargedCumulativeAmount + 200 OK + chargedAmount + channelState snapshot (client checks each one)… repeat N times; each new voucher supersedes the last, no nonce needed … + Phase 3: Batch settlement (server picks the moment: interval / threshold / withdrawal) + /settle(claim): bundle the latest vouchers across channels + claimWithSignature: records the debt only + /settle(settle): consolidate the recorded funds + settle: one transfer to the receiver + Exit paths: cooperative refund (instant), or timed withdrawal (initiateWithdraw → wait withdrawDelay, 15 min–30 days → finalizeWithdraw) + diff --git a/static/img/devnotes/batch-settlement-channel.svg b/static/img/devnotes/batch-settlement-channel.svg index ff7b28ae..90e8cbe4 100644 --- a/static/img/devnotes/batch-settlement-channel.svg +++ b/static/img/devnotes/batch-settlement-channel.svg @@ -5,7 +5,7 @@ - Bank of AI x402 Batch Settlement：单向支付通道 + 累积凭证 + BANK OF AI x402 Batch Settlement：单向支付通道 + 累积凭证 客户端（payer） 资源服务器 Facilitator diff --git a/static/img/devnotes/tron-x402-payment-flow-en.svg b/static/img/devnotes/tron-x402-payment-flow-en.svg new file mode 100644 index 00000000..4bb6b9b3 --- /dev/null +++ b/static/img/devnotes/tron-x402-payment-flow-en.svg @@ -0,0 +1,14 @@ + + One complete BANK OF AI x402 paymentSix-step sequence: request the resource, receive 402, select a requirement, retry signed, verify and settle, return the resource and payment result. + + One complete BANK OF AI x402 payment + AI Agent + WalletResource ServerFacilitatorBlockchain Network + + ① Request the paid resourceGET /paid-resource + ② Respond 402 Payment RequiredPAYMENT-REQUIRED · accepts[] + ③ Select a requirement and signCheck network, asset, limit, recipient, and validity + ④ Retry with the payment credentialPAYMENT-SIGNATURE + Payment Payload + ⑤ Verify and settle/verify: check requirements against payload/settle: submit the on-chain transactionTransaction and settlement result + ⑥ Return the resource and payment result200 OK · PAYMENT-RESPONSE · transaction id + The server must stay idempotent — keyed on the payment id, authorization nonce, or voucher — so a retry never double-charges or double-delivers. + diff --git a/static/img/devnotes/tron-x402-payment-flow.svg b/static/img/devnotes/tron-x402-payment-flow.svg index b45801a3..b339d29f 100644 --- a/static/img/devnotes/tron-x402-payment-flow.svg +++ b/static/img/devnotes/tron-x402-payment-flow.svg @@ -1,7 +1,7 @@ - 一次完整的 Bank of AI x402 支付六步时序图：请求资源、收到 402、选择方案、签名重试、验证并结算、返回资源与支付结果。 + 一次完整的 BANK OF AI x402 支付六步时序图：请求资源、收到 402、选择方案、签名重试、验证并结算、返回资源与支付结果。 - 一次完整的 Bank of AI x402 支付 + 一次完整的 BANK OF AI x402 支付 AI Agent + WalletResource ServerFacilitatorBlockchain Network ① 请求付费资源GET /paid-resource From ddcbb15e86ef96d41d3c35453f9e83f292b3db10 Mon Sep 17 00:00:00 2001 From: jizhen181-dot Date: Thu, 30 Jul 2026 21:12:49 +0800 Subject: [PATCH 9/9] update --- static/img/devnotes/batch-settlement-channel-en.svg | 2 +- static/img/devnotes/tron-x402-payment-flow-en.svg | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/static/img/devnotes/batch-settlement-channel-en.svg b/static/img/devnotes/batch-settlement-channel-en.svg index 19e44f0c..ea11d3fd 100644 --- a/static/img/devnotes/batch-settlement-channel-en.svg +++ b/static/img/devnotes/batch-settlement-channel-en.svg @@ -5,7 +5,7 @@ - BANK OF AI x402 Batch Settlement: channel + cumulative vouchers + BANK OF AI x402 Batch Settlement: Channel + Cumulative Vouchers Client (payer) Resource Server Facilitator diff --git a/static/img/devnotes/tron-x402-payment-flow-en.svg b/static/img/devnotes/tron-x402-payment-flow-en.svg index 4bb6b9b3..48586b76 100644 --- a/static/img/devnotes/tron-x402-payment-flow-en.svg +++ b/static/img/devnotes/tron-x402-payment-flow-en.svg @@ -1,7 +1,7 @@ - One complete BANK OF AI x402 paymentSix-step sequence: request the resource, receive 402, select a requirement, retry signed, verify and settle, return the resource and payment result. + One Complete BANK OF AI x402 PaymentSix-step sequence: request the resource, receive 402, select a requirement, retry signed, verify and settle, return the resource and payment result. - One complete BANK OF AI x402 payment + One Complete BANK OF AI x402 Payment AI Agent + WalletResource ServerFacilitatorBlockchain Network ① Request the paid resourceGET /paid-resource