Wallet infrastructure for teams running many agents.
You run 20 bots for 15 clients. Each one needs its own wallet, its own limits, its own audit trail, and per-client visibility for the client.
The bottleneck is not the agents. It is the wallet management.
If you run a Web3 automation agency, a market-making team, a yield-strategy operation, or any production deployment with many concurrent agents, the agents themselves are the easy part. You have battle-tested code and infrastructure to keep them running. What slows you down is everything around them: spreadsheets of wallet addresses, manual per-client reconciliation, scattered transaction logs, no clean way to give a client visibility into their own agent's activity without leaking another client's data, no enforced per-agent spending limits.
Most teams build this themselves at first - one shared multisig per client, per-agent ledgers in a Notion database, a Discord channel for transaction notifications. It works for the first three clients. By client ten it is a part-time job. By client twenty something will go wrong, an embarrassing mix-up that costs the relationship.
Blockchain0x gives every agent its own wallet, its own policy, its own log, its own seat access. You manage them all from one workspace, billed under one Stripe customer, with the right operators on the right agents. The ops layer is the entire product; you keep running the agents.
How an agency provisions its first workspace.
Five-step walkthrough that gets a typical agency from signup to managing 5-20 client agents with proper isolation, billing, and observability.
- 01
Provision the workspace
Sign up once under the agency's email or shared ops account. Workspace name reflects the agency identity (the workspace name appears on per-agent invoices). Workspace seats default to 1; add more for the operators who need cross-client visibility.
- 02
Create one agent per client (or per strategy)
Each client engagement gets its own agent record: separate slug, separate wallet address, separate spend policy, separate verification badges. The agent record is the unit of isolation - one client's transactions never touch another's, even when both run under the same workspace.
- 03
Assign agent-level seats to the right operators
On Business, invite operators to the specific client's agent with agent-level seats. They see and manage only that agent, never the others in the workspace. This is the seat model that makes per-client isolation feel correct: an operator cannot accidentally leak Client A's activity to Client B.
- 04
Configure per-agent spend permissions
Set a per-transaction cap and a per-period allowance for each agent (in the dashboard) based on what the client engagement actually permits. The same operator on the same workspace might run an agent with a tiny daily allowance for one client and a large one for another - the per-agent spend permission isolates the two cleanly.
- 05
Wire your monitoring and on-call
Set up webhook delivery for the events that matter operationally (payment.received, payment.sent, wallet.deployed). Point them at your incident system or Slack/Discord. The dashboard becomes the daily-driver view; alerting hits Slack when a payment lands or something needs attention.
The setup typically takes 1-2 hours for the first workspace and 10-15 minutes per additional client agent. By the time you have 5 clients onboarded, the marginal cost of adding the sixth is mostly the conversation with the client, not the provisioning.
One workspace, one Stripe customer, N agents.
The billing model is built around how agencies actually keep books: per-agent line items on a single invoice, exportable per agent or workspace-wide, with a webhook stream that lands in your accounting system in real time.
| Dimension | How Blockchain0x handles it | Why agencies care |
|---|---|---|
| Workspace structure | 1 workspace, N agents, 1 consolidated Stripe customer | Easy to find any payment across all clients |
| Invoice format | Per-agent subscription line + per-agent transaction-fee line | Maps cleanly to per-client billing if you re-invoice clients |
| Exports | CSV/JSON per agent, or workspace-wide; filterable by date range | Drop into accounting tool or per-client P&L |
| Webhook to accounting | payment.received / payment.sent events to your AP/AR system in real time | No batch reconciliation; ledger stays current |
| Currency | Fees billed in USD by default; settable to other currencies via Stripe | Match your accounting base currency |
| Records retained | Transaction history and audit logs kept while the agent exists | Exportable for client or auditor review |
The pattern most agencies land on: the Blockchain0x invoice goes to the agency. The agency re-invoices each client for their agent's subscription line + a management fee. The audit log makes it defensible if a client questions a specific charge - you can show exactly which transactions in which window drove the line item. No agency has ever asked us to remove a charge after producing the audit trail.
What you can tell your clients (and their auditors).
Compliance is where most agency engagements fail before they start. The client's legal team wants to know: who holds the funds, who can see what, how are records kept, what happens if there is an incident. Here is what you can tell them, in writing, supported by the product.
Custody - we are non-custodial
Funds stay in client (or agency) wallets, not on Blockchain0x. We never have private keys. If we got compromised tomorrow, the attacker could not move USDC because we do not have the means to. This is the strongest custody claim a payment platform can make; written into the terms.
Access control - per-agent seat scoping
Operators see only the agents they have been granted seats on. Workspace-level visibility is a separate, more privileged seat. Every seat add, role change, and removal is recorded in the audit log with full attribution. Two-factor authentication is required for workspace seats.
Audit trail - attributed and exportable
Every action that affects an agent is recorded with full attribution: who did it, when, and the before/after of the change. Export to JSON or CSV from the dashboard for any client or auditor review, scoped to a single agent so one client's records never expose another's.
Acceptable use policy - binding on every agent
Every workspace agrees to an acceptable-use policy at signup: no sanctions evasion, no money laundering, no fraud, no agents engaged in clearly illegal activity. Violations result in workspace suspension. The policy is publicly versioned; we will produce a current-and-historical version for any client legal review.
Incident response - documented runbook
Security incidents have a public runbook: notification within 24 hours of discovery, root-cause analysis within 7 days, post-mortem within 30 days. The runbook is available on request for compliance review. We have not had a notifiable incident at the time of writing; if and when we do, the runbook is the contract.
What lands on every audit-log entry.
The audit log is the artifact your client's auditor wants to see. Each entry records what changed and who changed it; export the whole log to JSON or CSV from the dashboard for a client or auditor review.
| Field | Type | Description |
|---|---|---|
| Timestamp | time | When the action happened, in UTC. |
| Agent | reference | Which agent the action affected. |
| Actor | reference | The human, API key, or system that took the action. |
| Action | category | What happened: a payment, a settings change, a seat change, a key rotation. |
| Outcome | status | Whether the action succeeded or was rejected. |
| Before / after | snapshot | The state on either side of a change. |
Export from the dashboard to JSON or CSV, filtered to a single agent or the whole workspace. The audit log is a Business-plan feature; basic transaction history is available on Pro.
Business for the agency workspace, mixed plans for the agents.
Web3 automation teams almost always need at least one Business agent (for the audit log + team seats). Many run a mix: Business for high-volume client engagements with compliance requirements, Pro for smaller clients where audit logs are not contractually required, Free for experimental or dormant agents. Per-agent pricing is what makes the mix work without overpaying.
- Free: experiments, dormant agents you may revive, demo agents for prospect conversations.
- Pro ($29/agent/mo): active client agents without strict compliance requirements.
- Business ($49/agent/mo): client agents at scale, with audit logs and per-agent team seats. The default for production engagements.
- Workspace seats: add seats for cross-client operator visibility (see /pricing).