What the integration covers

The Blockchain0x OpenAI Agents SDK integration is the official bridge between Blockchain0x agent wallets and the OpenAI Agents SDK's function_tool layer. It gives an Agent four capabilities it does not have by default: per-tool paid calls settled in USDC on Base, per-agent identity that counterparties can verify, a wallet-enforced spend policy that survives prompt injection, and an audit log indexed by Agent rather than by Runner invocation.

The integration's design principle mirrors the Agents SDK's own: each Agent is its own entity. When you build a hierarchy of Agents that hand off to each other, each Agent has its own role, its own instructions, and (with Blockchain0x) its own wallet and its own budget. The integration extends the same isolation the SDK already gives you to economic actions.

This LP is the integration-cluster reference. The canonical reference page is at /integrations/openai-agents-sdk; the task-oriented walkthroughs on the LangChain side at how-to-add-payments-to-langchain-agent translate one-to-one to the Agents SDK pattern.

Compatibility matrix

What works today:

What is not yet supported:

• Tools that route through the SDK's Computer Use or Browser tools without going through function_tool - those have their own integration shape via the Blockchain0x payment API.
• Async iterator tools that yield partial results before completion - the wrapper currently bills on call completion. Partial-result billing is on the roadmap.

Surface area in one screen

The full integration on a single Agent with one paid tool fits on one screen.

from agents import Agent, function_tool, Runner
from blockchain0x_openai_agents import require_payment
import os, json

@require_payment(
    agent_id=os.environ["RESEARCHER_AGENT_ID"],
    api_key=os.environ["BLOCKCHAIN0X_API_KEY"],
    price_usdc="0.005",
    reason="Real-time quote",
)
@function_tool
async def get_quote_realtime(ticker: str, receipt=None) -> str:
    """Fetch a real-time quote for a stock ticker."""
    quote = await fetch_live_quote(ticker)
    return json.dumps(quote)

researcher = Agent(
    name="Researcher",
    instructions="You are an equity research analyst.",
    tools=[get_quote_realtime],
)

result = await Runner.run(researcher, input="What is the live quote on TSLA?")
print(result.final_output)

The TypeScript shape is structurally identical: requirePayment wraps the tool({...}) definition, Agent accepts the wrapped tool unchanged. Decorator order matters - require_payment outside function_tool ensures the payment check runs before the SDK invokes the inner function.

The spend-policy configuration runs once per Agent at provisioning time:

from blockchain0x import Client

client = Client(api_key=os.environ["BLOCKCHAIN0X_ADMIN_KEY"])
client.agents.update_spend_policy(
    os.environ["RESEARCHER_AGENT_ID"],
    daily_cap_usdc="20.00",
    per_payment_cap_usdc="0.50",
)

That is the entire integration surface. No new Agent class, no custom Runner, no replacement for the SDK's function_tool decorator - just a decorator that runs before it.

Handoffs and per-agent wallets

Handoffs are one of the OpenAI Agents SDK's strongest primitives. An Agent can hand off control to another Agent mid-conversation; the receiving Agent inherits the context but operates with its own instructions and its own tools. The integration treats this exactly the way you want: each Agent in the handoff graph has its own Blockchain0x wallet, its own spend policy, and its own audit trail.

Three concrete benefits in handoff-heavy designs:

Per-role budgets. A "triage" Agent that just reads input and routes does not need a budget. A "researcher" Agent that calls premium APIs needs a meaningful daily cap. A "writer" Agent that mostly calls cheap LLMs needs a small budget. With per-agent wallets, you tune each role independently rather than budgeting for the worst case across the whole graph.

Clean attribution across handoffs. When the dashboard shows $4.20 spent on researcher and $0.20 spent on writer, you can immediately see where the cost lives and tune accordingly. A single shared wallet would lose this signal.

Isolated blast radius for prompt injection. A prompt-injected receiver after a handoff burns only its own daily cap. The Agents above it in the handoff hierarchy keep working with their full budgets intact.

For the parallel pattern on the LangChain side, see langchain-payment-integration. The agent-to-agent payment glossary entry covers the general pattern.

What the integration does not touch

The integration stays narrow. These pieces of your Agents SDK stack are unaffected:

• The LLM. Whatever model each Agent is configured with passes through.
• The instructions. Agent personality and reasoning are unchanged.
• The Runner. Streaming and non-streaming runs both work unchanged.
• Handoff routing. The SDK decides who handles what; the wrapper just runs when the receiver calls a tool.
• Built-in guardrails. Input validation, output validation, structured-output checks - all continue to run.
• The SDK's tracing. Spans for handoffs and tool calls appear as they always did.
• Free tools. Tools without the require_payment decorator return 200 directly with no wrapper involvement.

When this is the right integration

Two scenarios where the Agents SDK integration is the right pick.

Your Agents SDK system calls paid third-party services. Premium data, paid LLMs, paid MCP servers, paid APIs - all of these surface as 402-returning endpoints that the wrapper handles automatically. Without the integration, you would either bake credentials into each tool or proxy every call through your backend. The integration replaces both.

Your Agents SDK system has multiple Agents with different cost profiles. Per-agent wallets give you per-role budgets and per-role audit trails. A single shared wallet across many Agents is feasible but loses the attribution signal that makes the whole hierarchy easier to operate.

Alternatives where the integration is not the right pick: a single-Agent SDK app with one trusted LLM provider and a shared API key (the integration adds no value); a workload where all payments are human-driven via Stripe (use the dual-auth migration pattern); a tool that bypasses function_tool entirely (integrate the payment API directly).

Pricing and tier choices

The integration is free. The wallet API tier per Agent (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 and is enough for early-stage Agents SDK apps. Pro is the tier most production deployments converge on once volume picks up - it unlocks counterparty allowlists, time windows, GitHub + domain verification badges, and a lower 2% transaction fee instead of 5%.

In handoff-heavy designs, the agents that handle most of the throughput are usually the specialists at the bottom of the hierarchy - the researchers, the data-fetchers, the writers. Those are the ones to upgrade to Pro first. The triage and routing Agents at the top can stay on Free until their own paid traffic justifies the upgrade. Tier choices are per-Agent, not per-hierarchy, so the mix can evolve as your traffic shapes settle.