What the integration covers

The Blockchain0x LangChain integration is the official bridge between Blockchain0x agent wallets and LangChain's Tool layer. It gives a LangChain agent four capabilities it does not have by default: the ability to pay third parties per tool call, an identity counterparties can verify, a wallet-enforced spend policy, and an audit log indexed by agent rather than by user. None of these require changes to the agent's reasoning loop, the chain of prompts, or the model behind it.

This LP is the integration-cluster reference - what the integration is, what it touches, and the trade-offs against alternatives. If you want the task-oriented walkthrough ("install, wrap a tool, ship in 15 minutes"), the companion how-to-add-payments-to-langchain-agent is the step-by-step version. The LangChain integration page is the canonical reference and feature list.

Compatibility matrix

What works today:

What is not yet supported:

• Tools that bypass the Tool interface and call HTTP directly - the wrapper is on the Tool boundary, not the HTTP layer. For those, wire the payment API directly.
• Pure LCEL chains without Tools - the integration is Tool-shaped because that is the surface where pay-per-call mapping is well-defined.

Surface area in one screen

The full integration is small enough to fit on one screen. The two packages export one helper each:

import { DynamicStructuredTool } from "@langchain/core/tools";
import { requirePayment } from "@blockchain0x/langchain";

const paidTool = new DynamicStructuredTool({
  name: "get_quote_realtime",
  description: "Fetch a real-time quote for a stock ticker.",
  schema: /* zod schema */,
  func: requirePayment(
    { agentId: ..., apiKey: ..., priceUsdc: "0.005", reason: "Real-time quote" },
    async ({ ticker }, { receipt }) => fetchLiveQuote(ticker),
  ),
});

The Python shape is structurally identical (StructuredTool.from_function + require_payment decorator). The full code example with both languages is in the how-to-add-payments-to-langchain-agent walkthrough.

The other piece of the integration is the spend policy, configured once per agent through the platform SDK:

await client.agents.updateSpendPolicy(agentId, {
  daily_cap_usdc: "20.00",
  per_payment_cap_usdc: "0.50",
});

That is the entire surface area. No new executor, no replacement agent, no wrapper around LangChain itself - just a Tool-level decorator and a one-shot policy call.

What the integration does not touch

The integration deliberately stays narrow. These pieces of your LangChain stack are not affected:

• The LLM. Whatever model you have configured (GPT-4o, Claude Sonnet, Llama, Mistral) keeps working unchanged.
• The prompt. No additional system-prompt scaffolding is injected; the tool's description is what you wrote.
• The agent executor. AgentExecutor, LangGraph, custom - all see the wrapped tool as a normal Tool.
• The memory layer. LangChain memory (BufferMemory, VectorStoreMemory, custom) operates independently.
• Streaming, callbacks, tracing. LangSmith, OpenTelemetry, custom callbacks all work as before.
• Other tool integrations. Search tools, retrieval tools, custom Python functions - unwrapped tools coexist with wrapped ones on the same agent.

The integration is additive. You can introduce it on one tool at a time, validate behavior, and expand. There is no "all or nothing" rip-out-and-replace step.

When this is the right integration

Three scenarios where the LangChain integration is the right choice over alternatives.

Your LangChain agent calls paid tools or other paid agents. The wrapper turns each paid call into a wallet-settled transaction. Without the integration, you would either bake credentials into each tool (one per provider, no unified spend policy) or proxy every call through your backend (more code, no per-tool spend attribution). The integration collapses both paths.

You want per-agent isolation in a multi-agent LangChain system. Each LangChain Agent or LangGraph node gets its own Blockchain0x wallet, its own spend policy, its own audit trail. A prompt-injected agent burns only its own budget. Without per-agent isolation, the blast radius of any one compromised agent is the entire workspace's balance.

Your LangChain agent is itself a paid service. You can flip the direction and have your agent's tools return 402 to external callers. This is the LangChain integration page's focus on the monetization side. The same wrapper, different position in the call graph.

Alternatives the integration is not the right pick over: a pure-internal agent with one trusted LLM provider and a shared API key (the integration adds no value); a static LCEL chain with no Tools (no Tool boundary to wrap); a workload where the agent is the buyer's product and the platform charges via Stripe (use the Stripe-to-x402 migration pattern instead).

Pricing and tier choices

The integration itself is free. The wallet API tier (Free, Pro, Business) determines transaction-fee rates and feature unlocks - see /pricing/ for the breakdown. The Free tier supports per-agent wallets and basic spend policy; the Pro tier unlocks the more sophisticated spend policy (counterparty allowlists, time windows), custom branding on the agent's public profile, GitHub + domain verification badges, and a lower 2% transaction fee instead of 5%. The Business tier adds hash-chained audit logs and the advanced spend-policy controls enterprise customers usually want.

For a single LangChain agent doing modest daily volume, Free is enough to ship. The crossover point where Pro pays for itself is around $400-500/month of transaction volume; below that, Free's 5% fee is cheaper than Pro's $9/agent/month + 2% fee.

Migration from a homegrown setup

Teams that have already built ad-hoc payment glue for a LangChain agent (per-tool credentials, a backend proxy, a custom rate limiter) can usually migrate in a single afternoon. The migration shape:

• Replace your custom Tool wrapping with requirePayment. The wrapper's surface is a strict superset of what most ad-hoc implementations expose.
• Move per-tool credentials out of env vars and into the Blockchain0x agent's wallet. One wallet handles all payments going forward.
• Set the spend policy on the wallet and remove the rate-limiter code from the agent runtime - the wallet API enforces server-side, which is where the limit belongs anyway.
• Wire the audit log to read from /v1/transactions instead of your custom log. The structure is identical to what most ad-hoc systems already produce, so dashboard code rarely needs to change.

A homegrown setup of about 500 lines typically shrinks to about 50 lines after migration, with stronger security guarantees. The integration is more capable than most ad-hoc systems because it pushes the policy enforcement out of agent-side code and into the wallet API.

For the parallel pattern on the CrewAI side, see crewai-payment-integration. For the broader category framing, the Blockchain0x payment API page is the reference.