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.
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 of our vulnerability-disclosure policy and exactly what a reporter receives (recognition, not money), 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.
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.
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 2026First 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 2027We 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 upstreamWe do not operate our own smart contracts today. 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. If and when we ship our own contracts (account-abstraction features), they will be audited before mainnet deployment.
Annual internal security review
OngoingQuarterly 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.
We do not run a paid bug bounty.
To be completely clear: Blockchain0x has no bug-bounty program and pays no money, crypto-assets, credits, swag, or any other compensation for reported vulnerabilities. There are no severity tiers, no payout ranges, and no negotiation on this - anyone telling you otherwise is not quoting us. We would rather say this plainly than let a researcher spend a weekend on our systems expecting a cheque that does not exist.
What we do run is an unpaid coordinated-disclosure process. Reports go to our security email and are read by a human. We acknowledge every report by email, and for findings we confirm as valid we offer a responsible-disclosure certificate and, if you want it, your name or handle on our public acknowledgements list. That is the full extent of what we offer today. If that changes, this page changes with it.
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.
| What a reporter gets | Details |
|---|---|
| Email acknowledgement | Every report gets a human reply from [email protected], whether or not the finding turns out to be valid, plus the triage outcome once we have one. |
| Responsible-disclosure certificate | For confirmed, reproducible, in-scope findings: a signed certificate naming you (or your handle), the class of issue, and the date of disclosure. Issued after the fix ships. |
| Public acknowledgement | With your permission, your name or handle is added to the acknowledgements list published on this page once the issue is fixed. Stay anonymous instead if you prefer - just tell us. Conditional on the confidentiality terms below. |
| Monetary reward | None. We do not pay for reported vulnerabilities at any severity, and submitting a report creates no entitlement to payment. |
Validity calls are made by the engineering lead in conversation with the founder and are final. Recognition is for confirmed, reproducible findings within scope; where the same issue is reported more than once, the first reporter is the one credited. We do not require an NDA to file a report, and the conditions below are the only strings attached.
Conditions attached to recognition
The responsible-disclosure certificate and the public acknowledgement are both conditional on you keeping the report confidential. Do not publish the vulnerability, the report, or any of its details - reproduction steps, proof-of-concept code, screenshots, affected endpoints, or our correspondence about it - in any medium whatsoever. That includes blog posts, write-ups, text or image posts on any social network or forum, video, audio, podcasts, conference talks, newsletters, chat groups, and AI-generated derivatives of any of the above. If you want to publish after the fix has shipped, ask us first and we will usually agree in writing on a date and a level of detail. Publishing without that written agreement forfeits the certificate and the acknowledgement, and we reserve every other remedy available to us.
Separately, and without exception: any attempt to extort money from us or to blackmail us in any form - demanding payment to withhold, delay, or delete a report, threatening publication or sale of a finding unless we pay, or pressuring us with a deadline backed by a threat - is not security research. We will not pay. Such attempts will be dealt with strictly as per applicable law, including reporting the matter to law enforcement agencies and cooperating fully with any resulting investigation or prosecution. Good-faith researchers have nothing to worry about here; this paragraph is not aimed at you.
Public acknowledgements
Researchers who reported a confirmed vulnerability and asked to be credited are listed here, newest first, once the fix has shipped. Nobody is listed yet - if you are the first, we will say so here with your name or handle and the month of the report. A listing here is subject to the confidentiality conditions set out above.
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 the name or handle you would like on the certificate and the acknowledgements list (a handle is enough; no real name required, and you can ask to stay anonymous). 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, and not publishing the finding before we have agreed in writing on when and how it can be published.
For non-security issues (general support, billing, partnerships), use /contact. The security email is monitored only for security reports.
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
Vulnerability reports: [email protected]. PGP key on request. Reports are acknowledged, not paid.