BofAI · Will-Guan · Aug 13, 2026 · Aug 13, 2026 · Aug 13, 2026 · Aug 13, 2026
diff --git a/docs/Agent-Wallet/Developer/SDK-Cookbook.md b/docs/Agent-Wallet/Developer/SDK-Cookbook.md
@@ -1,3 +1,5 @@
+import ThemedImage from '@theme/ThemedImage';
+
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
@@ -37,9 +39,13 @@ Static mode stores your private key as plaintext in an environment variable —
 
 TRON transactions cannot be constructed directly by the client from scratch. The flow must start with a call to TronGrid's `createtransaction` endpoint, which returns an unsigned transaction object containing `txID` and `raw_data` generated by the network node. That object is then passed to Agent-wallet for local signing — the signing process is fully offline and the private key never leaves the machine. Finally, the signed transaction is submitted to TronGrid's `broadcasttransaction` endpoint to be published on-chain.
 
-```
-TronGrid (build) → Agent-wallet (sign) → TronGrid (broadcast)
-```
+<ThemedImage
+  alt="TRON transfer: TronGrid builds, Agent-wallet signs, TronGrid broadcasts"
+  sources={{
+    light: '/img/diagrams/agent-wallet-tron-flow.light.svg',
+    dark: '/img/diagrams/agent-wallet-tron-flow.svg',
+  }}
+/>
 
 Agent-wallet only participates in the middle signing step. It requires no RPC connection and has no awareness of the transaction's business meaning.
 
@@ -258,9 +264,13 @@ The example uses Base58 addresses, consistent with `visible: true`.
 
 EVM transactions require the caller to construct the transaction object themselves. Unlike TRON, the fields of an EVM transaction (`nonce`, `gas`, `chainId`, etc.) must be queried from the current chain state via RPC and filled in manually — there is no centralized API that generates them for you. Once the unsigned transaction is built, it is passed to Agent-wallet for local signing, which returns a hex-encoded signed transaction. That signed transaction is then broadcast to the network via `sendRawTransaction`.
 
-```
-RPC query nonce/gas (build) → Agent-wallet (sign) → RPC sendRawTransaction (broadcast)
-```
+<ThemedImage
+  alt="EVM transfer: RPC builds, Agent-wallet signs, RPC broadcasts"
+  sources={{
+    light: '/img/diagrams/agent-wallet-evm-flow.light.svg',
+    dark: '/img/diagrams/agent-wallet-evm-flow.svg',
+  }}
+/>
 
 The example uses BSC Testnet, but switching to Ethereum, Polygon, Base, or any other EVM chain only requires changing `RPC_URL` and `CHAIN_ID` — the Agent-wallet calling code stays exactly the same.
 
@@ -445,9 +455,13 @@ asyncio.run(
 
 x402 payments do not work by sending a direct transfer. Instead, they use a "sign first, verify to proceed" model. The agent signs a `TransferWithAuthorization` structure (EIP-712 format), and the resulting signature is sent alongside the request as a payment credential. The server verifies the signature and returns the content only if it is valid. The agent never has to wait for on-chain confirmation — latency is minimal.
 
-```
-Server returns 402 → Agent builds PaymentPermit → Agent-wallet signs → Resend request with signature → Server verifies and responds
-```
+<ThemedImage
+  alt="x402 PaymentPermit: sign first, verify to proceed"
+  sources={{
+    light: '/img/diagrams/agent-wallet-x402-permit-flow.light.svg',
+    dark: '/img/diagrams/agent-wallet-x402-permit-flow.svg',
+  }}
+/>
 
 The PaymentPermit data is automatically constructed by the x402 SDK based on the payment parameters returned by the server. Agent-wallet is only responsible for the final signing step. The example below shows the underlying signing logic, useful for scenarios that require custom integration or bypassing the x402 SDK.
 

diff --git a/docs/Agent-Wallet/Developer/SDK-Guide.md b/docs/Agent-Wallet/Developer/SDK-Guide.md
@@ -519,7 +519,7 @@ Error type hierarchy:
 WalletError
 ├── WalletNotFoundError        # Specified wallet not found
 ├── DecryptionError            # Wrong password or corrupted key file
-├── SigningError                # Signing operation failed
+├── SigningError               # Signing operation failed
 ├── NetworkError               # Network identifier mismatch
 ├── InsufficientBalanceError   # Insufficient balance
 ├── UnsupportedOperationError  # Operation not supported by this wallet type

diff --git a/docs/BANK-OF-AI/Intro.md b/docs/BANK-OF-AI/Intro.md
@@ -4,6 +4,8 @@ description: >-
   BANK OF AI is the infrastructure connecting AI and Web3. Install it, and your AI can pay, prove its identity, and execute on-chain — you describe the goal, the AI gets it done.
 ---
 
+import ThemedImage from '@theme/ThemedImage';
+
 # Introduction
 
 Today's AI can write code, analyze data, build presentations — it can even deliver an entire software project on its own.
@@ -119,21 +121,13 @@ Once installed, you say:
 
 The whole path, at a glance:
 
-```text
-User
- ↓
-AI interprets the request
- ↓
-Selects a Skill or calls an MCP Server
- ↓
-Agent Wallet signs
- ↓
-Transaction broadcast
- ↓
-Blockchain
- ↓
-Result
-```
+<ThemedImage
+  alt="BANK OF AI: one execution from your instruction to the on-chain result"
+  sources={{
+    light: '/img/diagrams/bank-of-ai-execution-flow.light.svg',
+    dark: '/img/diagrams/bank-of-ai-execution-flow.svg',
+  }}
+/>
 
 If anything goes wrong along the way — insufficient balance, a malformed address — the AI stops immediately and tells you why. And anything that spends money always needs your confirmation first.
 
@@ -143,13 +137,13 @@ If anything goes wrong along the way — insufficient balance, a malformed addre
 
 Abstract that path into a diagram, and you have all of BANK OF AI:
 
-```text
-    AI
-    │
-BANK OF AI
-    │
-   Web3
-```
+<ThemedImage
+  alt="BANK OF AI architecture: AI on top, Web3 below, BANK OF AI in between"
+  sources={{
+    light: '/img/diagrams/bank-of-ai-architecture.light.svg',
+    dark: '/img/diagrams/bank-of-ai-architecture.svg',
+  }}
+/>
 
 Internally it's four layers, each with a single job:
 

diff --git a/docs/BANK-OF-AI/image/bankofai-architecture.svg b/docs/BANK-OF-AI/image/bankofai-architecture.svg
diff --git a/docs/McpServer-Skills/SKILLS/image/conversational-install.png b/docs/McpServer-Skills/SKILLS/image/conversational-install.png
diff --git a/docs/McpServer-Skills/SKILLS/image/skill_call.jpg b/docs/McpServer-Skills/SKILLS/image/skill_call.jpg
diff --git a/docs/x402/api-catalog/index.md b/docs/x402/api-catalog/index.md
@@ -4,6 +4,8 @@ sidebar_label: Introduction
 description: BANK OF AI's wallet-native service catalog — where AI Agents discover, call, and pay for any API, settled on-chain via x402.
 ---
 
+import ThemedImage from '@theme/ThemedImage';
+
 # API Catalog
 
 Traditional API onboarding is designed for humans: create an account, request an API key, link a credit card, subscribe monthly. When an AI Agent wants to call an API on its own, it fails at the very first step — it has no email, no credit card, and it shouldn't be holding a pile of secret keys for you anyway.
@@ -21,17 +23,13 @@ The catalog itself is just a public list of services: it keeps no database and a
 
 To get listed, a provider submits two **public** files to the catalog repository (you can start with the application form and we'll help you through); the call addresses inside the files point to the gateway of your choice — BANK OF AI hosted or self-hosted. The platform validates, scans for sensitive data, then publishes:
 
-```text
-Provider                     Catalog repo (CI)                Distribution
-────────                     ─────────────────                ────────────
-catalog.json  ──open PR──►   field & sensitive-data scan ──►  /api/catalog.json
-pay.md                       build static snapshot dist/      /api/providers/<fqn>.json
-                                                              /api/pay/<fqn>.json · .md
-                                                                        │
-                                                ┌───────────────────────┼───────────────────────┐
-                                                ▼                       ▼                        ▼
-                                          Catalog website           x402-cli              MCP (Agent access)
-```
+<ThemedImage
+  alt="API Catalog: from a provider pull request through CI to three consumers"
+  sources={{
+    light: '/img/diagrams/x402-api-catalog-pipeline.light.svg',
+    dark: '/img/diagrams/x402-api-catalog-pipeline.svg',
+  }}
+/>
 
 Three consumers share the same data:
 

diff --git a/docs/x402/core-concepts/client-server.md b/docs/x402/core-concepts/client-server.md
@@ -1,3 +1,5 @@
+import ThemedImage from '@theme/ThemedImage';
+
 # Client and Server
 
 Understanding these roles in depth is essential when designing, building, or integrating x402-based programmable payment services on-chain.
@@ -63,6 +65,14 @@ In the x402 protocol, a typical interaction between client and server proceeds a
 5. **Server Executes Settlement**: Submits the transaction to the blockchain via the Facilitator.
 6. **Server Delivers Resource**: Returns the requested resource and includes settlement confirmation (with transaction hash) in the `PAYMENT-RESPONSE` header.
 
+<ThemedImage
+  alt="x402 communication flow between client, server and Facilitator"
+  sources={{
+    light: '/img/diagrams/x402-payment-flow.light.svg',
+    dark: '/img/diagrams/x402-payment-flow.svg',
+  }}
+/>
+
 ---
 
 ## Summary

diff --git a/docs/x402/core-concepts/gateway.md b/docs/x402/core-concepts/gateway.md
@@ -4,6 +4,8 @@ sidebar_label: Gateway
 description: The Gateway turns any API into a pay-per-call service for AI Agents — Agents discover, call, and pay on their own, with every call settled on-chain to your wallet.
 ---
 
+import ThemedImage from '@theme/ThemedImage';
+
 # Gateway
 
 Turn any API into a pay-per-call service for AI Agents.
@@ -24,11 +26,13 @@ Think of the gateway as a **cashier + relay** standing in front of your API (tec
 - **Upstream keys stay isolated.** If your upstream API needs auth, that API key lives only on the side running the gateway — in your local YAML / env for a self-hosted gateway, or held by us for the official gateway. Either way the caller never sees it, and it never enters the public catalog.
 - **You decide pricing per endpoint.** Price an endpoint in the config and it takes the paid flow; leave it unpriced (price 0) and it's forwarded directly — free endpoints stay free.
 
-```text
-Agent ──► Gateway ──► your upstream API
-          │ quote / verify / settle (paid endpoints only)
-          └ forwards the request
-```
+<ThemedImage
+  alt="Gateway topology: Agent to gateway to your upstream API"
+  sources={{
+    light: '/img/diagrams/x402-gateway-topology.light.svg',
+    dark: '/img/diagrams/x402-gateway-topology.svg',
+  }}
+/>
 
 ## Anatomy of a call
 

diff --git a/docs/x402/core-concepts/network-and-token-support.md b/docs/x402/core-concepts/network-and-token-support.md
@@ -1,3 +1,5 @@
+import ThemedImage from '@theme/ThemedImage';
+
 # Network & Token Support
 
 import Tabs from '@theme/Tabs';
@@ -176,6 +178,14 @@ npx tsx x402-payment/src/x402_invoke.ts --gasfree-activate --network nile --toke
 3. **Settle**
    The Facilitator submits the on-chain transaction — `transferWithAuthorization`, Permit2 `permitTransferFrom`, a batch claim, or a GasFree relay — based on the scheme.
 
+<ThemedImage
+  alt="How payment schemes work: authorize, execute, settle"
+  sources={{
+    light: '/img/diagrams/x402-payment-scheme-flow.light.svg',
+    dark: '/img/diagrams/x402-payment-scheme-flow.svg',
+  }}
+/>
+
 ---
 
 ## Deploying a Private Facilitator

diff --git a/docs/x402/index.md b/docs/x402/index.md
@@ -5,6 +5,8 @@ description: >-
   This guide introduces the x402 open payment standard on blockchain and helps you start building or integrating x402-powered services.
 ---
 
+import ThemedImage from '@theme/ThemedImage';
+
 # Welcome to x402
 
 x402 is an open blockchain payment standard built on the HTTP `402 Payment Required` status code. It enables web services to charge for APIs or content through a “pay-before-response” mechanism — without relying on traditional account systems or session management.  
@@ -58,8 +60,17 @@ At a high level, the workflow is straightforward:
 1. **Request Initiated:** The buyer requests a protected resource from the server.
 2. **Payment Required:** If payment is required, the server returns a `402 Payment Required` response along with payment instructions.
 3. **Payment Submitted:** The buyer generates and submits a signed payment payload.
-4. **Verification & Settlement:** The server calls the x402 Facilitator’s `/verify` and `/settle` endpoints to validate and settle the payment.
-5. **Resource Delivered:** Once verification succeeds, the server delivers the requested resource.
+4. **Payment Verified:** The server calls the Facilitator’s `/verify` endpoint to validate the signed payload.
+5. **Settlement Executed:** The server calls the Facilitator’s `/settle` endpoint to submit the transaction on-chain.
+6. **Resource Delivered:** Once settlement succeeds, the server delivers the requested resource.
+
+<ThemedImage
+  alt="x402 payment flow, from the first request to the delivered resource"
+  sources={{
+    light: '/img/diagrams/x402-payment-flow.light.svg',
+    dark: '/img/diagrams/x402-payment-flow.svg',
+  }}
+/>
 
 To explore further: