Skip to main content
SECURITY

Security at Blockchain0x.

Agent payments move real money. The architectural choices that protect customer funds, the audit posture as it stands today, and how to reach us if you find something wrong.

SCOPE

What you can expect from this page.

We are an early-stage company shipping infrastructure that customers will trust with payment authority. Trust is built on what you can verify, not on what you are told. This page documents four things customers and security researchers can verify or hold us to: the architectural guarantees that hold even if we are wrong about everything else, the current state of our audit posture (including what we have not done yet), the scope and rewards of our bug-bounty program, and the contact path for responsible disclosure.

What this page is not: a marketing surface designed to look maximally serious about security. We did not invent security certifications we do not hold, did not list "compliance" with frameworks we have not audited against, and did not put trust badges on the page that we did not earn. When we have a SOC 2 attestation or a third-party penetration test report, those will be referenced here with the auditing firm, the date, and the scope. Until then, this page says so plainly.

ARCHITECTURAL GUARANTEES

Four properties that hold by construction.

The guarantees below are architectural - they are properties of how the system is built, not of how it is operated. Operational security can lapse (a leaked key, a misconfigured deploy); architectural guarantees do not depend on day-to-day operations being perfect. These are the parts of the security story you can rely on even in the worst week of operations.

Non-custodial at the platform layer

Blockchain0x does not hold customer funds. Wallets are owned by the agent (or by the underlying custody provider the customer has connected, like Circle Programmable Wallets or Coinbase Smart Wallet). The Blockchain0x service operates the developer surface above those wallets - APIs, dashboard, identity, spend policy - and never has signing authority over balances.

Spend policy enforced server-side, not in the agent

Daily caps, per-payment ceilings, counterparty allowlists, and time windows are evaluated by the Blockchain0x wallet API on every payment intent before settlement. The agent runtime cannot reach the policy storage; an agent that gets prompt-injected still cannot raise its own limits.

Receipt-validated payment confirmation

Payment receipts surfaced by the API are validated server-side against the issuing transaction before they confirm. A client cannot forge a receipt locally and present it as proof of payment; the receipt-validation step is the same trust model Stripe webhook signatures use.

Webhook signatures, not shared secrets in URLs

Every webhook event we emit is signed with HMAC-SHA256 over the raw body using a per-tenant signing secret. The signing secret is never sent in the URL or query string. Customers verify signatures on receipt; we provide reference implementations in the docs.

AUDIT POSTURE

Where we are today, honestly.

The table below is the current state of external audits, third-party reviews, and certifications. We update this page when any line changes - dates are real, scopes are real, and "planned" means scheduled with a firm, not aspirational.

Third-party penetration test

Planned for Q4 2026

First external penetration test is scheduled for the second half of the year. Scope: web app, public APIs, webhook surface, dashboard auth. Full report summary will be published here when complete.

SOC 2 Type I

Targeted for 2027

We are not SOC 2 audited today. The honest expected window for a Type I attestation is the first half of 2027; Type II follows after a 6 to 12 month observation period.

Smart-contract audits

Inherited from upstream

We do not operate our own smart contracts at MVP. The on-chain primitives are Circle Programmable Wallets, Coinbase Smart Wallet, and the underlying Base / USDC contracts, all of which carry their own independent audit reports from the issuing teams. When we ship our own contracts (account-abstraction features in V2 onwards), they will be audited before mainnet deployment.

Annual internal security review

Ongoing

Quarterly secret-rotation, dependency-scan review, and access-control audit. Pre-launch hardening checklist documented in our [secure-your-agent-wallet guide](/learn/guides/secure-your-agent-wallet) for customers; the internal version mirrors it.

BUG BOUNTY

We pay for security research.

We run a private bug-bounty program. Reports go directly to our security email; we triage within two business days and pay confirmed findings on a per-severity basis. Payouts are in USDC, on Base, to the wallet of the reporter's choice. We do not require legal NDAs to file a report.

In scope

  • Authentication and session management on the dashboard or API.
  • Privilege escalation between workspaces or agents on the same account.
  • Server-side request forgery, command injection, or remote code execution in the API.
  • Webhook signature bypass or receipt-validation bypass.
  • Spend-policy bypass that lets an agent move money outside its configured caps or allowlist.
  • Significant data exposure (other tenants' transactions, secrets, audit logs).

Out of scope

  • Self-XSS or attacks that require the victim to type or paste hostile input into their own console.
  • Reports that depend on social-engineering of staff or contractors.
  • Reports against third-party services Blockchain0x integrates with (Coinbase, Circle, etc) - those should go to the third-party's own program.
  • Findings against test endpoints (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia).
  • Missing security headers without a demonstrated impact.
  • Theoretical issues without a working proof-of-concept.
SeverityExamplesPayout range
CriticalCross-tenant fund movement, spend-policy bypass at scale, account takeover without user action.$5,000 - $25,000
HighAuthenticated privilege escalation, webhook-signature bypass with measurable impact, server-side request forgery in the API.$1,000 - $5,000
MediumStored XSS in the dashboard with realistic exploitation path, sensitive info leakage with limited impact.$250 - $1,000
LowReflected XSS with limited exploitability, minor info leaks, hardening recommendations with demonstrated value.$50 - $250

Payout decisions are final and made by the engineering lead in conversation with the founder. The bounty is for confirmed, reproducible findings within scope; duplicates of an already-reported issue pay only the first reporter. We credit reporters publicly on this page on request once the issue is fixed.

RESPONSIBLE DISCLOSURE

How to report a security issue.

Email [email protected] with: a description of the issue, a step-by-step reproduction, the affected URL or endpoint, the impact you observed, and your contact information for the bounty payout (a Base wallet address is enough; no real name required). Encrypted reports are welcome - our PGP key is available on request.

We commit to acknowledging your report within two business days, triaging within five, and shipping a fix or risk-acceptance decision within thirty days for confirmed findings (or sooner for critical issues). We do not threaten legal action against good-faith security research that follows responsible-disclosure norms - exposing data only as much as needed to demonstrate the issue, not exfiltrating customer data, not running disruptive tests that affect production users.

For non-security issues (general support, billing, partnerships), use /contact. The security email is monitored only for security reports.

INCIDENT COMMUNICATION

What we say if something goes wrong.

Production incidents that affect customer funds, customer data, or the availability of the payment API get a public post-mortem within thirty days of resolution, regardless of severity. Smaller incidents (degraded performance, partial-region outages) are communicated via status updates to affected customers but do not necessarily get a post-mortem.

We do not blame customers in post-mortems. We do not blame third-party providers if the root cause was ours. We name root causes plainly, list what we are changing as a result, and keep the post-mortem available indefinitely. The expectation customers should have is that we will tell you what happened before you have to ask.

Security contact

Reports and bounty submissions: [email protected]. PGP key on request.