Portemonnee-infrastructuur voor teams die veel agenten draaien.
Je draait 20 bots voor 15 klanten. Elke heeft zijn eigen wallet, zijn eigen limieten, zijn eigen audittrail en per-klant zichtbaarheid voor de klant.
De bottleneck zijn niet de agents. Het is het walletbeheer.
Als u een Web3-automatiseringsbureau, een market-making team, een yield-strategie operatie of een productie-implementatie met veel gelijktijdige agents runt, zijn de agents zelf het gemakkelijke deel. U heeft beproefde code en infrastructuur om ze draaiende te houden. Wat u vertraagt, is alles eromheen: spreadsheets met portemonnee-adressen, handmatige reconciliatie per klant, verspreide transactie-logboeken, geen schone manier om een klant inzicht te geven in de activiteit van hun eigen agent zonder gegevens van een andere klant te lekken, geen afgedwongen uitgavenlimieten per agent.
De meeste teams bouwen dit in het begin zelf - één gedeelde multisig per klant, per-agent grootboeken in een Notion-database, een Discord-kanaal voor transactie notificaties. Het werkt voor de eerste drie klanten. Bij klant tien is het een parttime baan. Bij klant twintig gaat er iets mis, een gênante verwarring die de relatie kost.
Blockchain0x geeft elke agent zijn eigen wallet, zijn eigen beleid, zijn eigen logboek, zijn eigen toegang tot zitplaatsen. Je beheert ze allemaal vanuit één werkruimte, gefactureerd onder één Stripe-klant, met de juiste operators op de juiste agenten. De ops-laag is het hele product; jij blijft de agenten draaien.
Hoe een bureau zijn eerste werkruimte inricht.
Vijf-stappen doorloop die een typische bureau van aanmelding naar het beheren van 5-20 klantagenten met juiste isolatie, facturering en observatie brengt.
- 01
Voorzie de werkruimte
Meld je één keer aan onder het e-mailadres van het bureau of het gedeelde oper account. De naam van de werkruimte weerspiegelt de identiteit van het bureau (de naam van de werkruimte verschijnt op facturen per agent). Werkruimteplaatsen zijn standaard 1; voeg meer toe voor de operators die zicht nodig hebben over verschillende klanten.
- 02
Maak één agent per klant (of per strategie) aan
Elke klantbetrekking krijgt zijn eigen agentrecord: aparte slug, apart walletadres, apart uitgavenbeleid, aparte verificatiebadges. Het agentrecord is de eenheid van isolatie - de transacties van de ene klant raken nooit die van een andere, zelfs niet als beide onder dezelfde werkruimte draaien.
- 03
Wijs agent-niveau plaatsen toe aan de juiste operators
Bij Business, nodig operators uit voor de specifieke agent van de klant met agent-niveau plaatsen. Ze zien en beheren alleen die agent, nooit de anderen in de werkruimte. Dit is het zitmodel dat per-klant isolatie correct laat aanvoelen: een operator kan per ongeluk de activiteit van Klant A niet naar Klant B lekken.
- 04
Configureer per-agent uitgavenmachtigingen
Stel een limiet per transactie en een toelage per periode in voor elke agent (in het dashboard) op basis van wat de klantbetrokkenheid daadwerkelijk toestaat. Dezelfde operator op dezelfde werkruimte kan een agent draaien met een kleine dagelijkse toelage voor de ene klant en een grote voor een andere - de per-agent uitgaven toestemming isoleert de twee duidelijk.
- 05
Verbind je monitoring en on-call
Stel webhook-levering in voor de gebeurtenissen die operationeel belangrijk zijn (payment.received, payment.sent, wallet.deployed). Richt ze op je incidentensysteem of Slack/Discord. Het dashboard wordt de dagelijkse weergave; waarschuwingen komen in Slack wanneer een betaling binnenkomt of wanneer er iets aandacht nodig heeft.
De setup duurt meestal 1-2 uur voor de eerste werkruimte en 10-15 minuten per extra klantagent. Tegen de tijd dat je 5 klanten hebt onboarded, zijn de marginale kosten voor het toevoegen van de zesde voornamelijk het gesprek met de klant, niet de provisioning.
Één werkruimte, één Stripe-klant, N agents.
Het factureringsmodel is gebouwd rond hoe bureaus daadwerkelijk boeken bijhouden: per-agent lijnitems op een enkele factuur, exporteerbaar per agent of werkruimte-breed, met een webhookstream die in realtime in je boekhoudsysteem terechtkomt.
| Dimensie | Hoe Blockchain0x het aanpakt | Waarom agentschappen zich zorgen maken |
|---|---|---|
| Werkruimte structuur | 1 werkruimte, N agents, 1 geconsolideerde Stripe-klant | Gemakkelijk om elke betaling over alle klanten te vinden |
| Factuurformaat | Per-agent abonnementslijn + per-agent transactiekostenlijn | Past goed bij per-client facturering als je klanten opnieuw factureert |
| Exporten | CSV/JSON per agent, of werkruimte-breed; filterbaar op datumbereik | Plaats in boekhoudtool of per-client P&L |
| Webhook naar boekhouding | payment.received / payment.sent gebeurtenissen naar je AP/AR-systeem in realtime | Geen batchverzoening; grootboek blijft actueel |
| Valuta | Kosten worden standaard in USD gefactureerd; instelbaar naar andere valuta via Stripe | Stem je boekhoudbasisvaluta af |
| Gearchiveerde records | Transactiegeschiedenis en auditlogs worden bewaard zolang de agent bestaat | Exporteerbaar voor klant- of auditorreview |
Het patroon waar de meeste bureaus op uitkomen: de Blockchain0x-factuur gaat naar het bureau. Het bureau factureert elke klant opnieuw voor de abonnementsregel van hun agent + een beheersvergoeding. Het auditlogboek maakt het verdedigbaar als een klant een specifieke kostenpost in twijfel trekt - je kunt precies laten zien welke transacties in welk venster de regel hebben aangedreven. Geen enkel bureau heeft ons ooit gevraagd om een kostenpost te verwijderen na het produceren van het auditspoor.
Wat u uw klanten (en hun auditors) kunt vertellen.
Compliance is waar de meeste agency-engagements falen voordat ze beginnen. Het juridische team van de klant wil weten: wie houdt de fondsen, wie kan wat zien, hoe worden records bewaard, wat gebeurt er als er een incident is. Hier is wat u hen schriftelijk kunt vertellen, ondersteund door het product.
Bewaring - wij zijn non-custodial
Fondsen blijven in klant- (of bureau-) wallets, niet op Blockchain0x. We hebben nooit privésleutels. Als we morgen gecompromitteerd zouden worden, zou de aanvaller USDC niet kunnen verplaatsen omdat we de middelen niet hebben. Dit is de sterkste claim op bewaring die een betalingsplatform kan maken; vastgelegd in de voorwaarden.
Toegangscontrole - per-agent zitplaatsafbakening
Operators zien alleen de agents waarvoor ze stoelen hebben gekregen. Workspace-niveau zichtbaarheid is een aparte, meer bevoorrechte stoel. Elke stoel toevoeging, rolwijziging en verwijdering wordt vastgelegd in het auditlogboek met volledige toeschrijving. Twee-factor authenticatie is vereist voor werkruimte-stoelen.
Audit trail - geattribueerd en exporteerbaar
Elke actie die een agent beïnvloedt, wordt vastgelegd met volledige toeschrijving: wie het deed, wanneer, en de voor/na van de wijziging. Exporteer naar JSON of CSV vanuit het dashboard voor elke klant of auditor review, beperkt tot een enkele agent zodat de gegevens van de ene klant nooit die van een andere onthullen.
Acceptabel gebruiksbeleid - bindend voor elke agent
Elke werkruimte stemt in bij aanmelding in met een acceptabel gebruiksbeleid: geen sancties ontwijken, geen witwassen van geld, geen fraude, geen agents die zich bezighouden met duidelijk illegale activiteiten. Overtredingen leiden tot schorsing van de werkruimte. Het beleid is openbaar geversioneerd; we zullen een huidige en historische versie produceren voor elke juridische beoordeling van de klant.
Incidentrespons - gedocumenteerd runbook
Beveiligingsincidenten hebben een openbaar runbook: melding binnen 24 uur na ontdekking, oorzaakonderzoek binnen 7 dagen, post-mortem binnen 30 dagen. Het runbook is op aanvraag beschikbaar voor compliance-review. We hebben op het moment van schrijven geen meldingsplichtig incident gehad; als en wanneer we dat doen, is het runbook het contract.
Wat op elke audit-logentry komt.
Het auditlogboek is het artefact dat de auditor van jouw klant wil zien. Elke invoer registreert wat er is veranderd en wie het heeft veranderd; exporteer het hele logboek naar JSON of CSV vanuit het dashboard voor een klant of auditor review.
| Veld | Type | Beschrijving |
|---|---|---|
| Timestamp | time | Wanneer de actie plaatsvond, in UTC. |
| Agent | reference | Welke agent door de actie werd beïnvloed. |
| Actor | reference | De persoon, API-sleutel of het systeem dat de actie uitvoerde. |
| Action | category | Wat er is gebeurd: een betaling, een wijziging in instellingen, een stoelwijziging, een sleutelrotatie. |
| Outcome | status | Of de actie is geslaagd of geweigerd. |
| Voor / na | snapshot | De toestand aan beide kanten van een wijziging. |
Exporteer vanuit het dashboard naar JSON of CSV, gefilterd op een enkele agent of de hele werkruimte. Het auditlogboek is een functie van het Business-plan; basis transactiegeschiedenis is beschikbaar op Pro.
Business voor de agency werkruimte, gemengde plannen voor de agents.
Web3-automatiseringsteams hebben bijna altijd minstens één Business-agent nodig (voor het auditlogboek + teamstoelen). Veel hebben een mix: Business voor hoge-volume klantengagementen met compliance-eisen, Pro voor kleinere klanten waar auditlogs niet contractueel vereist zijn, Free voor experimentele of inactieve agents. Per-agent prijsstelling is wat de mix laat werken zonder te veel te betalen.
- Gratis: experimenten, slapende agents die u kunt reactiveren, demo-agents voor gesprekken met prospects.
- Pro ($29/agent/mo): actieve client agents zonder strikte compliancevereisten.
- Business ($49/agent/mo): client agents op schaal, met audit logs en team seats per agent. De standaard voor productie-implementaties.
- Workspace seats: seats toevoegen voor operatorzichtbaarheid over meerdere clients (zie /pricing).