Infraestrutura de carteira para equipes que gerenciam muitos agentes.
Você executa 20 bots para 15 clientes. Cada um precisa de sua própria carteira, seus próprios limites, sua própria trilha de auditoria e visibilidade por cliente para o cliente.
O gargalo não são os agentes. É a gestão da carteira.
Se você administrar uma agência de automação Web3, uma equipe de criação de mercado, uma operação de estratégia de rendimento ou qualquer implantação de produção com muitos agentes simultâneos, os próprios agentes são a parte fácil. Você tem código e infraestrutura testados em batalha para mantê-los funcionando. O que o atrasa é tudo ao redor deles: planilhas de endereços de carteira, reconciliação manual por cliente, registros de transações dispersos, nenhuma maneira limpa de dar a um cliente visibilidade sobre a atividade de seu próprio agente sem vazar dados de outro cliente, sem limites de gastos por agente aplicados.
A maioria das equipes constroem isso sozinhas no início - uma multisig compartilhada por cliente, livros contábeis por agente em um banco de dados Notion, um canal Discord para notificações de transações. Funciona para os primeiros três clientes. Com o décimo cliente, torna-se um trabalho de meio período. Com o vigésimo cliente, algo dará errado, uma confusão embaraçosa que custará o relacionamento.
Blockchain0x dá a cada agente sua própria carteira, sua própria política, seu próprio log, seu próprio acesso a assentos. Você os gerencia todos de um único espaço de trabalho, faturado sob um único cliente Stripe, com os operadores certos nos agentes certos. A camada de operações é todo o produto; você continua executando os agentes.
Como uma agência provisiona seu primeiro espaço de trabalho.
Um guia de cinco etapas que leva uma agência típica do cadastro ao gerenciamento de 5-20 agentes de clientes com isolamento, cobrança e observabilidade adequados.
- 01
Provisionar o espaço de trabalho
Inscreva-se uma vez sob o e-mail da agência ou conta de operações compartilhadas. O nome do espaço de trabalho reflete a identidade da agência (o nome do espaço de trabalho aparece nas faturas por agente). As cadeiras do espaço de trabalho têm padrão de 1; adicione mais para os operadores que precisam de visibilidade entre clientes.
- 02
Criar um agente por cliente (ou por estratégia)
Cada engajamento de cliente recebe seu próprio registro de agente: slug separado, endereço de carteira separado, política de gastos separada, badges de verificação separados. O registro do agente é a unidade de isolamento - as transações de um cliente nunca tocam as de outro, mesmo quando ambos operam sob o mesmo espaço de trabalho.
- 03
Atribua assentos de nível de agente aos operadores certos
No Business, convide operadores para o agente do cliente específico com assentos de nível de agente. Eles veem e gerenciam apenas aquele agente, nunca os outros no espaço de trabalho. Este é o modelo de assento que faz a isolação por cliente parecer correta: um operador não pode acidentalmente vazar a atividade do Cliente A para o Cliente B.
- 04
Configure permissões de gasto por agente
Defina um limite por transação e uma concessão por período para cada agente (no painel) com base no que o engajamento do cliente realmente permite. O mesmo operador no mesmo espaço de trabalho pode executar um agente com uma pequena concessão diária para um cliente e uma grande para outro - a permissão de gasto por agente isola os dois de forma limpa.
- 05
Conecte sua monitoração e plantão
Configure a entrega de webhook para os eventos que são operacionais (payment.received, payment.sent, wallet.deployed). Aponte-os para seu sistema de incidentes ou Slack/Discord. O painel se torna a visão diária; alertas atingem o Slack quando um pagamento chega ou algo precisa de atenção.
A configuração geralmente leva de 1 a 2 horas para o primeiro espaço de trabalho e de 10 a 15 minutos por agente cliente adicional. Quando você tiver 5 clientes a bordo, o custo marginal de adicionar o sexto é principalmente a conversa com o cliente, não a provisão.
Um espaço de trabalho, um cliente Stripe, N agentes.
O modelo de cobrança é construído em torno de como as agências realmente mantêm livros: itens de linha por agente em uma única fatura, exportável por agente ou em todo o espaço de trabalho, com um fluxo de webhook que chega ao seu sistema contábil em tempo real.
| Dimensão | Como a Blockchain0x lida com isso | Por que as agências se importam |
|---|---|---|
| Estrutura do espaço de trabalho | 1 workspace, N agents, 1 cliente consolidado do Stripe | Fácil de encontrar qualquer pagamento entre todos os clientes |
| Formato da fatura | Linha de assinatura por agente + linha de taxa de transação por agente | Mapeia de forma limpa para faturamento por cliente se você re-faturar clientes |
| Exportações | CSV/JSON por agente ou em toda a área de trabalho; filtrável por intervalo de datas | Insira na ferramenta de contabilidade ou P&L por cliente |
| Webhook para contabilidade | eventos payment.received / payment.sent para seu sistema AP/AR em tempo real | Sem reconciliação em lote; o livro-razão permanece atualizado |
| Moeda | Taxas cobradas em USD por padrão; ajustáveis para outras moedas via Stripe | Combine sua moeda base de contabilidade |
| Registros mantidos | Histórico de transações e logs de auditoria mantidos enquanto o agente existir | Exportável para revisão de cliente ou auditor |
O padrão em que a maioria das agências se baseia: a fatura do Blockchain0x vai para a agência. A agência re-fatura cada cliente pela linha de assinatura de seu agente + uma taxa de administração. O log de auditoria torna defensável se um cliente questionar uma cobrança específica - você pode mostrar exatamente quais transações em qual janela geraram o item da linha. Nenhuma agência jamais nos pediu para remover uma cobrança após produzir o registro de auditoria.
O que você pode dizer aos seus clientes (e seus auditores).
A conformidade é onde a maioria dos engajamentos de agências falha antes de começar. A equipe jurídica do cliente quer saber: quem detém os fundos, quem pode ver o que, como os registros são mantidos, o que acontece se houver um incidente. Aqui está o que você pode dizer a eles, por escrito, apoiado pelo produto.
Custódia - somos não-custodiais
Os fundos permanecem nas carteiras do cliente (ou da agência), não no Blockchain0x. Nunca temos chaves privadas. Se fôssemos comprometidos amanhã, o atacante não poderia mover USDC porque não temos os meios para isso. Esta é a afirmação de custódia mais forte que uma plataforma de pagamento pode fazer; escrita nos termos.
Controle de acesso - escopo por sede de agente
Os operadores veem apenas os agentes para os quais receberam assentos. A visibilidade em nível de espaço de trabalho é um assento separado e mais privilegiado. Cada adição de assento, mudança de função e remoção é registrada no log de auditoria com total atribuição. A autenticação de dois fatores é necessária para assentos de espaço de trabalho.
Rastro de auditoria - atribuído e exportável
Cada ação que afeta um agente é registrada com total atribuição: quem fez, quando e o antes/depois da mudança. Exporte para JSON ou CSV do painel para qualquer revisão de cliente ou auditor, limitado a um único agente para que os registros de um cliente nunca exponham os de outro.
Política de uso aceitável - vinculativa para cada agente
Cada espaço de trabalho concorda com uma política de uso aceitável ao se inscrever: sem evasão de sanções, sem lavagem de dinheiro, sem fraudes, sem agentes envolvidos em atividades claramente ilegais. Violações resultam na suspensão do espaço de trabalho. A política é versionada publicamente; produziremos uma versão atual e histórica para qualquer revisão legal do cliente.
Resposta a incidentes - runbook documentado
Incidentes de segurança têm um runbook público: notificação dentro de 24 horas após a descoberta, análise de causa raiz dentro de 7 dias, post-mortem dentro de 30 dias. O runbook está disponível mediante solicitação para revisão de conformidade. Não tivemos um incidente notificável no momento da redação; se e quando tivermos, o runbook é o contrato.
O que aparece em cada entrada do log de auditoria.
O log de auditoria é o artefato que o auditor do seu cliente deseja ver. Cada entrada registra o que mudou e quem mudou; exporte todo o log para JSON ou CSV a partir do painel para uma revisão de cliente ou auditor.
| Campo | Tipo | Descrição |
|---|---|---|
| Timestamp | time | Quando a ação aconteceu, em UTC. |
| Agent | reference | Qual agente foi afetado pela ação. |
| Actor | reference | O humano, API key ou sistema que executou a ação. |
| Action | category | O que aconteceu: um pagamento, uma alteração de configurações, uma mudança de assento, uma rotação de chave. |
| Outcome | status | Se a ação foi bem-sucedida ou rejeitada. |
| Antes / depois | snapshot | O estado em ambos os lados de uma mudança. |
Exporte do painel para JSON ou CSV, filtrado para um único agente ou todo o espaço de trabalho. O log de auditoria é um recurso do plano Business; o histórico básico de transações está disponível no Pro.
Business para o espaço de trabalho da agência, planos mistos para os agentes.
Equipes de automação Web3 quase sempre precisam de pelo menos um agente Empresarial (para o registro de auditoria + assentos da equipe). Muitas operam uma mistura: Empresarial para engajamentos de clientes de alto volume com requisitos de conformidade, Pro para clientes menores onde registros de auditoria não são contratualmente exigidos, Gratuito para agentes experimentais ou inativos. A precificação por agente é o que torna a mistura viável sem pagar a mais.
- Free: experimentos, agentes inativos que você pode reativar, agentes de demonstração para conversas com prospects.
- Pro ($29/agent/mo): agentes de clientes ativos sem requisitos rígidos de compliance.
- Business ($49/agent/mo): agentes de clientes em escala, com logs de auditoria e assentos de equipe por agente. O padrão para contratos em produção.
- Assentos de workspace: adicione assentos para visibilidade do operador entre clientes (veja /pricing).