Beveiliging bij Blockchain0x.
Agentbetalingen verplaatsen echt geld. De architectonische keuzes die klantfondsen beschermen, de auditpositie zoals deze vandaag de dag is, en hoe je ons kunt bereiken als je iets verkeerd vindt.
Wat u van deze pagina kunt verwachten.
We zijn een vroegfasebedrijf dat infrastructuur levert waaraan klanten betaalbevoegdheid toevertrouwen. Vertrouwen wordt gebouwd op wat je kunt verifiëren, niet op wat je wordt verteld. Deze pagina documenteert vier zaken die klanten en beveiligingsonderzoekers kunnen verifiëren of waarop ze ons kunnen aanspreken: de architecturale garanties die standhouden zelfs als we het over de rest bij het verkeerde eind hebben, de huidige status van onze auditpositie (inclusief wat we nog niet hebben gedaan), de reikwijdte van ons vulnerability-disclosurebeleid en precies wat een melder ontvangt (erkenning, geen geld), en het contactkanaal voor 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.
Vier eigenschappen die bij de constructie gelden.
De garanties hieronder zijn architectonisch - het zijn eigenschappen van hoe het systeem is gebouwd, niet van hoe het wordt beheerd. Operationele beveiliging kan falen (een gelekte sleutel, een verkeerd geconfigureerde implementatie); architectonische garanties zijn niet afhankelijk van perfecte dagelijkse operaties. Dit zijn de delen van het beveiligingsverhaal waarop je kunt vertrouwen, zelfs in de slechtste week van operaties.
Non-custodial op het platformniveau
Blockchain0x houdt geen klantfondsen vast. Wallets zijn eigendom van de agent (of van de onderliggende bewakingsprovider waarmee de klant is verbonden, zoals Circle Programmable Wallets of Coinbase Smart Wallet). De Blockchain0x-service beheert het ontwikkelaarsoppervlak boven die wallets - API's, dashboard, identiteit, bestedingsbeleid - en heeft nooit ondertekeningsautoriteit over saldi.
Uitgavenbeleid afgedwongen server-side, niet in de agent
Dagelijkse limieten, per-betaling plafonds, tegenpartij toestemmingen en tijdvensters worden geëvalueerd door de Blockchain0x wallet API op elke betalingsintentie vóór afhandeling. De agent runtime kan de beleidsopslag niet bereiken; een agent die prompt-injectie krijgt, kan zijn eigen limieten nog steeds niet verhogen.
Ontvangst-gevalideerde betalingsbevestiging
Betalingsontvangsten die door de API worden weergegeven, worden serverzijde gevalideerd tegen de uitgevende transactie voordat ze bevestigen. Een cliënt kan een ontvangstbewijs niet lokaal vervalsen en presenteren als bewijs van betaling; de stap voor ontvangstbewijsvalidatie is hetzelfde vertrouwensmodel dat Stripe webhook-handtekeningen gebruikt.
Webhook-handtekeningen, geen gedeelde geheimen in URL's
Elk webhook-evenement dat we uitzenden, is ondertekend met HMAC-SHA256 over de ruwe body met behulp van een per-huurder ondertekeningsgeheim. Het ondertekeningsgeheim wordt nooit in de URL of querystring verzonden. Klanten verifiëren handtekeningen bij ontvangst; we bieden referentie-implementaties in de documentatie.
Waar we vandaag staan, eerlijk gezegd.
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.
Derde partij penetratietest
Gepland voor Q4 2026De eerste externe penetratietest is gepland voor de tweede helft van het jaar. Scope: webapp, openbare API's, webhook-oppervlak, dashboard-authenticatie. Een samenvatting van het volledige rapport zal hier worden gepubliceerd wanneer het compleet is.
SOC 2 Type I
Gericht op 2027We zijn vandaag niet SOC 2 geaudit. Het eerlijke verwachte venster voor een Type I attest is de eerste helft van 2027; Type II volgt na een observatieperiode van 6 tot 12 maanden.
Smart-contractaudits
Geërfd van upstreamWe draaien vandaag geen eigen smart contracts. De on-chain primitives zijn Circle Programmable Wallets, Coinbase Smart Wallet en de onderliggende Base / USDC-contracten, die allemaal hun eigen onafhankelijke auditrapporten van de uitgevende teams hebben. Als en wanneer we onze eigen contracts uitbrengen (account-abstraction features), worden die vóór mainnet deployment geaudit.
Jaarlijkse interne beveiligingsreview
VoortdurendKwartaalgewijze geheimrotatie, afhankelijkheidsscan beoordeling en toegangsaudit. Pre-lancering hardening checklist gedocumenteerd in onze [secure-your-agent-wallet gids](/learn/guides/secure-your-agent-wallet) voor klanten; de interne versie weerspiegelt dit.
We hebben geen betaalde bug bounty.
Om volstrekt duidelijk te zijn: Blockchain0x heeft geen bug-bountyprogramma en betaalt geen geld, crypto-assets, credits, swag of enige andere vergoeding voor gemelde kwetsbaarheden. Er zijn geen ernstniveaus, geen uitbetalingsbandbreedtes en geen onderhandeling hierover - iedereen die je anders vertelt, citeert ons niet. We zeggen dit liever expliciet dan dat we een onderzoeker een weekend op onze systemen laten besteden in de verwachting van een cheque die niet bestaat.
Wat we wel hebben, is een onbetaald coordinated-disclosureproces. Rapporten gaan naar onze security-e-mail en worden door een mens gelezen. We bevestigen elk rapport per e-mail, en voor bevindingen die we als geldig bevestigen bieden we een responsible-disclosurecertificaat en, als je dat wilt, je naam of handle op onze publieke acknowledgements-lijst. Dat is vandaag de volledige omvang van wat we bieden. Als dat verandert, verandert deze pagina mee.
Binnen scope
- Authenticatie en sessiebeheer op het dashboard of de API.
- Privilege-escalatie tussen workspaces of agents op hetzelfde account.
- Server-side request forgery, command injection of remote code execution in de API.
- Webhook signature bypass of receipt-validation bypass.
- Omzeiling van spend-policy waarmee een agent geld buiten de geconfigureerde limieten of allowlist kan verplaatsen.
- Aanzienlijke datablootstelling (transacties, secrets, auditlogs van andere tenants).
Buiten scope
- Self-XSS of aanvallen waarbij het slachtoffer kwaadaardige invoer in de eigen console moet typen of plakken.
- Meldingen die afhankelijk zijn van social engineering van personeel of contractors.
- Meldingen over diensten van derden waarmee Blockchain0x integreert (Coinbase, Circle, enz.) - die moeten naar het eigen meldprogramma van de derde partij gaan.
- Bevindingen tegen test-endpoints (`sk_test_` keys, `*.test.blockchain0x.com`, Base Sepolia).
- Ontbrekende security headers zonder aangetoonde impact.
- Theoretische problemen zonder werkende proof-of-concept.
| Wat een melder ontvangt | Details |
|---|---|
| E-mailbevestiging | Elk rapport krijgt een menselijke reactie van [email protected], ongeacht of de bevinding uiteindelijk geldig blijkt te zijn, plus de triageresultaten zodra die er zijn. |
| Responsible-disclosurecertificaat | Voor bevestigde, reproduceerbare bevindingen binnen scope: een ondertekend certificaat met jouw naam (of handle), de categorie van het probleem en de datum van openbaarmaking. Wordt uitgegeven nadat de fix is uitgerold. |
| Publieke vermelding | Met jouw toestemming wordt je naam of handle toegevoegd aan de lijst met erkenningen op deze pagina zodra het probleem is opgelost. Blijf liever anoniem als je dat wilt - laat het ons gewoon weten. Onder voorbehoud van de onderstaande vertrouwelijkheidsvoorwaarden. |
| Monetaire beloning | Geen. We betalen niet voor gemelde kwetsbaarheden, ongeacht de ernst, en het indienen van een rapport geeft geen recht op betaling. |
De validiteitsbeoordeling wordt definitief gemaakt door de engineering lead in overleg met de founder. Erkenning geldt voor bevestigde, reproduceerbare bevindingen binnen scope; als hetzelfde probleem meer dan ერთხელ wordt gemeld, krijgt de eerste melder de erkenning. Voor het indienen van een melding is geen NDA vereist, en de onderstaande voorwaarden zijn de enige verbonden voorwaarden.
Voorwaarden verbonden aan erkenning
Het certificaat voor verantwoordelijke openbaarmaking en de openbare erkenning zijn beide afhankelijk van het vertrouwelijk houden van de melding. Publiceer de kwetsbaarheid, de melding of enig detail ervan - reproduceringsstappen, proof-of-concept code, screenshots, getroffen endpoints of onze correspondentie erover - in geen enkel medium. Dat geldt ook voor blogposts, artikelen, tekst- of beeldposts op elk sociaal netwerk of forum, video, audio, podcasts, conference talks, nieuwsbrieven, chatgroepen en AI-gegenereerde afgeleiden van al het voorgaande. Als je wilt publiceren nadat de fix is uitgerold, vraag het ons eerst en meestal komen we schriftelijk een datum en detailniveau overeen. Publiceren zonder die schriftelijke overeenkomst doet afstand van het certificaat en de erkenning, en wij behouden ons alle overige rechtsmiddelen voor die ons ter beschikking staan.
Afzonderlijk en zonder uitzondering: elke poging om geld van ons af te persen of ons in welke vorm dan ook te chanteren - betaling eisen om een melding achter te houden, te vertragen of te verwijderen, dreigen met publicatie of verkoop van een bevinding tenzij we betalen, of druk uitoefenen met een deadline die met een bedreiging wordt ondersteund - is geen security research. Wij zullen niet betalen. Dergelijke pogingen worden strikt behandeld volgens de toepasselijke wetgeving, inclusief het melden van de zaak bij opsporingsinstanties en volledige medewerking aan elk daaruit voortvloeiend onderzoek of vervolging. Goede trouw onderzoekers hebben hier niets te vrezen; deze paragraaf is niet op jullie gericht.
Publieke vermeldingen
Onderzoekers die een bevestigde kwetsbaarheid hebben gemeld en hebben gevraagd om genoemd te worden, worden hier vermeld, met de nieuwste eerst, zodra de fix is uitgerold. Er staat nog niemand vermeld - als jij de eerste bent, vermelden we dat hier met je naam of handle en de maand van de melding. Een vermelding hier is onderworpen aan de hierboven uiteengezette vertrouwelijkheidsvoorwaarden.
Hoe u een beveiligingsprobleem kunt melden.
Mail [email protected] met: een beschrijving van het probleem, een stapsgewijze reproductie, de getroffen URL of endpoint, de impact die je hebt waargenomen, en de naam of handle die je op het certificaat en in de acknowledgements-lijst wilt laten vermelden (een handle is voldoende; geen echte naam vereist, en je kunt vragen om anoniem te blijven). Versleutelde rapporten zijn welkom - onze PGP-sleutel is op verzoek beschikbaar.
We verbinden ons ertoe je melding binnen twee werkdagen te bevestigen, binnen vijf werkdagen te triageren en binnen dertig dagen een fix of een besluit tot risicowaardering te leveren voor bevestigde bevindingen (of sneller bij kritieke issues). Wij dreigen niet met juridische stappen tegen security research te goeder trouw die de normen voor verantwoordelijke openbaarmaking volgt - alleen zoveel data blootlegt als nodig is om het probleem aan te tonen, geen klantgegevens exfiltreert, geen ontregelende tests uitvoert die productgebruikers raken, en de bevinding niet publiceert voordat we schriftelijk zijn overeengekomen wanneer en hoe deze mag worden gepubliceerd.
Voor niet-beveiligingsproblemen (algemene ondersteuning, facturering, partnerschappen), gebruik /contact. De beveiligings-e-mail wordt alleen gecontroleerd voor beveiligingsrapporten.
Wat we zeggen als er iets misgaat.
Productie-incidenten die klantfondsen, klantgegevens of de beschikbaarheid van de betalings-API beïnvloeden, krijgen binnen dertig dagen na oplossing een publieke post-mortem, ongeacht de ernst. Kleinere incidenten (degradatie van prestaties, gedeeltelijke regio-uitval) worden gecommuniceerd via statusupdates aan de getroffen klanten, maar krijgen niet noodzakelijkerwijs een post-mortem.
We geven klanten geen schuld in post-mortems. We geven derde partijen geen schuld als de oorzaak van het probleem bij ons ligt. We noemen de oorzaken duidelijk, vermelden wat we als gevolg daarvan veranderen, en houden de post-mortem onbeperkt beschikbaar. De verwachting die klanten zouden moeten hebben, is dat we je vertellen wat er is gebeurd voordat je het hoeft te vragen.
Beveiligingscontact
Meldingen van kwetsbaarheden: [email protected]. PGP-sleutel op verzoek. Rapporten worden bevestigd, niet betaald.