SameDayDesk x402 Data Gateway

Treze ferramentas MCP ao vivo para dados x402 e MPP, extração web, descoberta de agentes, auditorias de segurança, decisões Morpho e pré-verificação de trabalho.

GitHub

Experimente este MCPPatrocinado

Documentação

SameDayDesk x402 e MPP Data Gateway

Extração em lote limitada opcional

Os pagos GET /extract e GET /read (e MCP extract / read) retornam um registro tipado após a liquidação. O HTTP 200 do comerciante é a entrega desse registro, não uma prova de que a fonte teve sucesso ou de que a página está completa. O JSON mantém requestedUrl, o finalUrl observado (também copiado para url para compatibilidade), o HTTP status da fonte, sourceOk, um error anulável e um objeto capture que rotula o GET sem JavaScript, os limites de corpo/excerto, o charset e a truncagem. Um 403/404 com texto de bloqueio não é um 200 vazio. As evidências observacionais de entrega HTTP podem classificar conformidade de esquema, recusa da fonte e truncagem; isso não é utilidade para o comprador nem uma garantia vendida. O campo de extração text é um excerto limitado; use /read para Markdown mais longo. Nenhuma das rotas executa JavaScript, então a ausência de texto de discussão não é prova de inexistência. Ilhas de dados de script e comentários são removidos; isso não é um leitor completo de discussões. As conexões de produção com a fonte validam e fixam respostas públicas de DNS IPv4, revalidam até três redirecionamentos e rejeitam credenciais em URL, endereços privados, IPv6 e respostas comprimidas que ignoram a codificação de identidade solicitada. Rótulos de charset em cabeçalhos/meta selecionam um decodificador; capture.charset nomeia o decodificador realmente usado. Rótulos desconhecidos recorrem a UTF-8 com um marcador explícito de fallback.

As linhas do lote retêm os slots de origem solicitados, incluindo duplicatas e falhas. O provenance.capture de cada linha capturada registra o método sem JavaScript, o limite real de bytes e o limite de 1.200 caracteres de texto quando o texto é solicitado. Um corte conhecido de corpo ou texto é parcial, não completo. Isso não detecta conteúdo ausente não divulgado. A recusa da fonte permanece uma linha com falha mesmo quando sua página de erro tem texto. Os ganchos de teste de busca/timeout em processo não têm vínculo de entrada HTTP, MCP ou de ambiente e não alteram a liquidação ou o middleware de autorização.

EXTRACT_BATCH_ENABLED=1 adiciona POST /extract/batch e MCP extract_batch a um preço introdutório de 0,01 USDC por lote admitido de 1 a 5 URLs HTTPS públicas. O padrão é desativado: 25 operações HTTP pagas e 22 ferramentas MCP; ativado: 26 e 23. Este preço não é uma garantia de margem medida. Use um processo de servidor e COMMERCE_DATA_DIR persistente; liquidação desconhecida é colocada em quarentena, não cobrada automaticamente novamente. A saída parcial limitada não promete todas as fontes ou campos solicitados.

LOCKFILE_PIN_DELTA_ENABLED=1 adiciona POST /lockfile-pin-delta e MCP lockfile_pin_delta para dois objetos npm package-lock.json fornecidos pelo chamador. O padrão é desativado. A produção já tem EXTRACT_BATCH_ENABLED=1 (26 HTTP pagos / 23 ferramentas MCP). Ativar o lockfile junto a esse envelope é 27 / 24. Os catálogos desativados por padrão permanecem 25 / 22. O preço padrão é $0.005 (LOCKFILE_PIN_DELTA_PRICE), correspondendo ao GET /extract ativo. A margem não é comprovada. O lançamento inicial ativo aceita apenas x402; as rotas MPP existentes, incluindo extract_batch, permanecem inalteradas. Apenas JSON HTTP: sem caminhos de sistema de arquivos, comandos arbitrários ou busca de rede. Pins idênticos são informativos, não falha do mecanismo. A declaração de implantação assinada não é reescrita aqui. O recurso de desafio da ferramenta MCP de lockfile é https://agents.samedaydesk.com/lockfile-pin-delta, não mcp:// e não /extract/batch.

A ferramenta MCP extract_batch projeta o manipulador HTTP de pagamento existente e de replay durável. Seu recurso de desafio é https://agents.samedaydesk.com/extract/batch, não mcp://: primeira chamada sem pagamento, depois reutilize o recurso HTTP retornado e os argumentos exatos com _meta["x402/payment"]. Chamadores MPP podem usar o desafio www-authenticate não modificado no resultado _meta["samedaydesk/http"].headers e enviar sua credencial como HTTP Authorization. Esses metadados também carregam o status HTTP e os cabeçalhos de recibo. Nunca traduza uma credencial de recurso MCP. As ferramentas MCP existentes mantêm seu limite de pagamento MCP nativo existente.

A declaração assinada declara 25 capacidades de rota padrão em qualquer estado de flag (Circle é separado); ela não afirma que uma rota desativada está disponível nem autoriza pagamento. A descoberta ativa exclui a extração em lote desativada.

Toda resposta HTTP paga anuncia /.well-known/agent-payment-evidence.json por meio da relação de link HTTP padrão describedby. O manifesto gratuito limitado une cada método exato e rota ao seu efeito somente leitura declarado pelo vendedor, caminhos JSON garantidos recursivamente, digest do esquema de resposta, vínculo exato de replay, comportamento de recibo e a declaração de implantação assinada existente. Isso não altera os termos x402 ou MPP e não é autorização para gastar; os compradores ainda devem verificar o desafio ativo, a saída paga, o recibo e a liquidação.

Vinte ferramentas de pagamento por chamada para pré-verificação determinística de oportunidades de agentes, descoberta de serviços de máquina, pré-verificação de ofertas de pagamento, decisões de tomadores e mercado Morpho, planos de proteção, extração de URLs, leitura de Markdown, verificações de segurança de repositórios, enriquecimento de empresas e carteiras, geração de dados estruturados, evidência de recibos de transações, conformidade de políticas de signatários delegados, prova de liquidação e auditorias de prontidão para busca por IA.

Página do produto: https://samedaydesk.com/x402
Smithery: https://smithery.ai/servers/epistemedeus/x402-data-gateway
MCP remoto: https://agents.samedaydesk.com/mcp
Pacote local Agent Plugins 1.0: plugins/samedaydesk-x402 (não listado no marketplace)
Marketplace Claude Code: .claude-plugin/marketplace.json mais plugins/samedaydesk-extract (samedaydesk-extract@samedaydesk-claude; não é uma listagem oficial de diretório da Anthropic)
Config nativa Goose: goose/ (YAML, flag de sessão e deeplink; não é um instalador Goose)
Habilidades Hermes Agent: hermes/ mais plugins/samedaydesk-x402/skills portátil (AgentSkills SKILL.md drop-in; não é um plugin ou instalador Hermes)
Manifesto de recursos ativos: https://agents.samedaydesk.com/.well-known/x402
OpenAPI: https://agents.samedaydesk.com/openapi.json
OpenAPI MPP oficial: https://agents.samedaydesk.com/mpp-openapi.json
Contrato de habilidade: https://agents.samedaydesk.com/skill.md
Catálogo de ações: https://agents.samedaydesk.com/api/actions
Cartão de agente A2A: https://agents.samedaydesk.com/.well-known/agent-card.json
Registro Global A2A: https://www.a2a-registry.org/agent/9cb0b8e6-cb1f-422b-a604-861d0a79e24b
Radar de Liquidação: https://agents.samedaydesk.com/platforms
JSON de saúde da plataforma: https://agents.samedaydesk.com/v0/cards.json
Telemetria agregada de demanda de máquinas: https://agents.samedaydesk.com/v0/commerce-demand.json
Risco de posição Morpho: GET /defi/morpho-position?address=0x...&shocks=-10,-20,-30
Cotação de proteção Morpho: GET /defi/morpho-protection?address=0x...&targetHealthFactor=1.25&protectAgainstShockPct=-10
Subscrição de mercado Morpho: GET /defi/morpho-market-underwrite?marketId=0x...
Replay de pré-liquidação Morpho: GET /defi/morpho-preliquidation-replay?transactionHash=0x...
Pré-verificação de oportunidade: GET /work/opportunity-preflight?rewardUsd=10&hours=0.25&hourlyCostUsd=4&selectionProbabilityPct=20
Auditoria de descoberta de agentes: GET /distribution/agent-discoverability-audit?origin=https://example.com&intent=extract+a+public+website+into+structured+JSON&route=/extract&method=GET&runtimeUrl=https%3A%2F%2Fexample.com%2Fextract%3Furl%3Dhttps%253A%252F%252Fexample.org&surfaceAudit=true&materializationAudit=true
Pré-verificação de oferta de pagamento: GET /commerce/payment-offer-preflight?url=https://example.com/paid-route
Auditoria de integridade do vendedor: GET /commerce/seller-integrity-audit?origin=https://seller.example&route=/paid-route&method=GET&requiredPaths=data.attributes
- Um comprador pode adicionar referral=r1_<sha256> derivado de seu recibo completo de liquidação x402 assinado pelo vendedor. Isso cria um rótulo de aquisição declarado, não uma prova verificada. POST /commerce/referral-recheck aceita esse recibo mais um recibo de liquidação assinado pelo vendedor a jusante de um pagador e transação distintos e, em seguida, concede atomicamente no máximo uma reavaliação gratuita de estado alterado. Os recibos não provam uma resposta HTTP 200 do aplicativo nem a entrega ou validade da saída, e a publicação ou transmissão pública é opcional. Um arquivo que corresponda ao contrato de captura observável do Agent402 PR 1070 (recibo JSON simples e bonito, sem código-fonte do Agent402 incluído) já é uma entrada drop-in após JSON.parse comum; veja docs/agent-outcome-referral-experiment.md e agent402-receipt-interop.test.mjs.
Deriva de descoberta↔pagamento ativo (somente biblioteca/CLI; não é uma rota hospedada ou paga): node discovery-drift.mjs observe --url 'https://agent-economy-signal-x402-mainnet.bronzetti-andrea.workers.dev/premium/agent-brief' --bazaar-pay-to '0xbda48b29607b9dc66ef7e38b68ad53f2b17efb23'
Busca qualificada por contrato: GET /commerce/contract-qualified-search?query=service+domain+ownership+code+provenance&requiredPaths=data.sourceRepository retorna um plano de reparo OpenAPI consultivo limitado para caminhos obrigatórios ausentes exigidos pelo comprador, sem mutar arquivos do vendedor ou inferir tipos de propriedade não declarados.
Prova de liquidação USDC Base: GET /commerce/settlement-proof?transactionHash=0x...&recipient=0x...&amountAtomic=5000
Recibo de transação Base ou Ethereum: GET /chain/transaction-receipt?transactionHash=0x...&network=base
Conformidade de política de carteira: POST /security/wallet-policy-conformance
Contrato de conformidade de política de carteira: GET /schemas/wallet-policy-conformance-v1.json
Conformidade de política de carteira com estado: POST /security/stateful-wallet-policy-conformance
Contrato de política de carteira com estado: GET /schemas/stateful-wallet-policy-conformance-v1.json
Sonda de alerta de mudança material: https://agents.samedaydesk.com/alerts
Callback de vendedor Agoragentic: POST /integrations/agoragentic/ai-readiness-audit
Webhook de cumprimento assinado the402: POST /integrations/the402/webhook

Nenhuma chave de API ou assinatura é necessária. Toda rota HTTP paga anuncia x402 e autenticação de Pagamento MPP nativa na mesma resposta 402. Ambos os protocolos liquidam o mesmo valor exato em USDC para a mesma carteira de comerciante na mainnet Base. As chamadas de ferramentas MCP permanecem limitadas por x402.

A rota Morpho é somente leitura. Ela calcula LTV, LLTV, fator de saúde, margem de liquidação e cenários de choque de preço de garantia a partir de valores inteiros de protocolo e, em seguida, cruza garantias indexadas, ações de empréstimo e preço de oráculo contra o estado direto da RPC Base. Os cenários são cálculos, não probabilidades ou recomendações de transação. A rota de proteção separada usa uma leitura nova de oráculo via RPC direta e confirmação direta de garantias e ações de empréstimo para calcular valores exatos de reembolso parcial e adição de garantia. Ela retorna modelos não assinados de aprovação de token e chamada Morpho, buffers de execução explícitos, requisitos de revalidação e pós-condições econômicas. Ela nunca acessa uma carteira, assina, transmite ou assume custódia.

O serviço também mantém um telescópio de demanda seguro para privacidade em um volume persistente da Railway. Ele registra famílias de rotas, nomes de chaves de consulta, classes de desafio/sucesso e sinais pseudônimos de uso repetido. Buscas externas são sinais de aquisição, não compradores verificados, porque indexadores automatizados não identificados podem permanecer. Agentes de usuário reconhecidos de crawlers e indexadores de agentes são reduzidos na ingestão a um rótulo de fonte controlado e relatados em uma lente separada de descoberta de máquinas com cobertura de fonte e rota. Essas observações medem buscas, não referências de catálogo autenticadas, intenção ou demanda. Solicitações não correspondidas são relatadas separadamente de um subconjunto conservador de candidatos semânticos; nenhuma delas se torna demanda até que um chamador independente repita ou converta. Ele não registra endereços IP brutos, agentes de usuário, URLs, valores de consulta, corpos, cabeçalhos de pagamento, cargas de marketplace ou credenciais. A saída pública é apenas agregada; o tráfego do proprietário é excluído e o tráfego de crawlers permanece excluído da demanda mesmo quando suas contagens de descoberta controladas são relatadas separadamente. Sondas comuns de exploração, como .env, .git, e caminhos de descoberta do WordPress são classificadas como tráfego de scanner e excluídas também.

A versão 1.9.4 adiciona classes explícitas de tráfego pago sem expor endereços de compradores. COMMERCE_PAYER_CLASSES aceita uma matriz JSON de { "address", "class" } records. Controlled classes are internal, validation, incentivized, affiliated e independent. Os endereços são convertidos nos mesmos pseudônimos de pagador com chave secreta já usados pela telemetria e classificados no momento da leitura, o que também permite correção retroativa sem armazenar um endereço bruto. Pagadores desconhecidos permanecem unclassified; carteiras não familiares nunca se tornam demanda independente por inferência. O instantâneo público relata sucesso pago por classe, além de contagens de atores independentes e repetidos independentes.

A versão 1.9.5 adiciona contagens de sucesso pago por rota dentro de cada classe de evidência. Isso permite que monitores a jusante tratem a validação de marketplace como evidência contábil e de transporte, alertem sobre uso pago não classificado para investigação e avancem a tese de demanda apenas para compradores explicitamente independentes ou repetidos independentes.

A versão 1.9.6 captura privadamente um hash de transação Base válido de cabeçalhos x402 PAYMENT-RESPONSE ou MPP Payment-Receipt bem-sucedidos após uma linha de base de evidência explícita. A telemetria pública expõe apenas cobertura de prova, contagem distinta e contagens de referências ausentes por classe de pagamento. Cabeçalhos brutos e referências de transação permanecem no volume privado. Uma referência ausente se torna um evento material de integridade de liquidação sem expor a própria referência. Versão 1.11.2 negocia o conteúdo da raiz sem alterar seu contrato de máquina. A navegação por navegador com um Accept: text/html explícito recebe um mapa humano responsivo das quatorze ferramentas, fluxo de pagamento e links de descoberta autoritativos. Clientes JSON, o cabeçalho de aceite curinga do curl e agentes mantêm o descritor JSON estável. A resposta varia conforme Accept, e a página humana não duplica nenhum esquema de pagamento.

A versão 1.11.2 também adiciona a lente de descoberta de máquina com atribuição de fonte. Ela mantém agentes de usuário brutos e endereços de rede fora do snapshot público, relata observações futuras exatas do indexador por fonte e rota controladas, e dá ao radar apenas mudanças de cobertura de primeira fonte e primeira rota como eventos materiais. Volume repetido de rastreamento permanece como dados visíveis sem se tornar um alerta de atenção ou demanda.

A versão 1.11.3 torna essa lente de alcance prospectiva e autoexcludente. Uma linha de base distinta de COMMERCE_AGENT_DISCOVERY_SINCE impede que o histórico de rastreadores pré-instrumentação se torne alcance atribuído, enquanto agentes de usuário de monitor de propriedade da SameDayDesk são excluídos tanto das observações de descoberta quanto de demanda externa. Isso impede que varreduras de integridade, benchmarks cegos de marca e sondas de radar criem seu próprio sinal de aquisição.

A versão 1.11.4 preserva agentes pagantes mesmo quando seu agente de usuário se identifica como rastreador ou indexador. Uma credencial x402 ou MPP válida submetida move o evento para telemetria econômica antes da classificação de rastreador, enquanto o rótulo controlado de agente de usuário registra conversão de fonte para pago por fonte e rota. Rótulos de canal ainda são autodeclarados em vez de prova de referência autenticada, e demanda independente ainda requer a política explícita de classe de pagador.

A versão 1.11.5 separa o alcance de rota paga da entrega de desafio. Observações prospectivas de agente/indexador agora relatam sondas de rota paga, desafios HTTP 402, atores de desafio distintos e repetidos, taxa de desafio e detalhamentos controlados de fonte e rota. Isso identifica se o funil de máquina para antes do paywall, no desafio ou após uma credencial submetida, sem tratar uma sonda de indexador como intenção de compra.

A versão 1.11.6 adiciona uma coorte conservadora de desafio para pagamento. Uma contagem de sucesso pago conta como continuação somente quando o mesmo ator de rede e agente de usuário com chave secreta retorna após seu primeiro desafio prospectivo. O snapshot público relata chamadas convertidas, atores convertidos, atores convertidos independentes, taxa de conversão e totais controlados de fonte e classe de evidência sem IDs de ator. Deriva de rede ou agente de usuário só pode criar falsos negativos, então a métrica é um limite inferior em vez de uma afirmação de identidade.

A versão 1.11.7 adiciona verificação de conector Glama de propriedade do projeto em /.well-known/glama.json usando o e-mail comercial público da SameDayDesk. Solicitações Glama têm seu próprio rótulo controlado de fonte de descoberta, então uma reivindicação de diretório propagada pode ser medida sem se tornar demanda.

A versão 1.11.8 inicia um funil separado de tentativa de credencial. Após uma linha de base declarada, uma tentativa analisável deve incluir uma vinculação exata x402 v2 sintaticamente completa ou credencial MPP evm/charge. Validade de assinatura e liquidação permanecem como resultados posteriores. Agregados públicos separam ruído de cabeçalho de tentativas analisáveis e relatam protocolo, resultado, rota, fonte controlada e classe de pagador explícita sem credenciais brutas, IDs de ator ou endereços.

A versão 1.11.9 melhora a seleção de ferramentas MCP sem renomear ou duplicar nenhuma ferramenta. Cada ferramenta agora tem um título único orientado a ação. As ferramentas sobrepostas de web e empresa dizem explicitamente quando escolher extract versus read, enrich versus schemaforge, e a combinada deep_audit; wallet_enrich também declara que sua entrada é um endereço EVM em vez de um domínio de empresa. As rotas de pagamento, nomes, preços, esquemas e manipuladores permanecem inalterados.

A versão 1.11.10 adiciona descrições explícitas a cada entrada de opportunity_preflight e aos três controles de proteção Morpho. Isso melhora a construção de chamadas de máquina enquanto deixa nomes, rotas, preços, entradas obrigatórias, padrões, portões de pagamento e comportamento de execução inalterados.

A versão 1.11.11 dá a todas as quatro ferramentas MCP Morpho orientação explícita de seleção entre irmãos. Diagnóstico de mutuário, planejamento de proteção futura, subscrição de mercado e replay histórico de PreLiquidation agora são escolhas distintas de máquina sem renomear uma ferramenta ou alterar sua rota, preço, esquema, portão de pagamento ou manipulador.

A versão 1.11.12 inicia uma sonda prospectiva de fricção de transporte MCP. Ela separa quatro expectativas comuns de cliente, /mcp/sse, /mcp/messages, /mcp/tools e /mcp/events, de falhas arbitrárias de /mcp/* sem servir um alias adivinhado. Agregados públicos expõem apenas contagens de rota e totais de atores com chave secreta. Uma rota de compatibilidade é justificada apenas por uso independente repetido ou conversão.

A versão 1.11.13 repara o contrato de resposta pré-pagamento exposto a compradores de máquina. Todas as treze rotas já tinham esquemas de saída JSON explícitos, mas o helper Bazaar v2 espera esse esquema sob output.schema; o campo anterior de nível superior outputSchema era silenciosamente ignorado. Um único adaptador testado agora coloca cada esquema autorado no local definido pelo protocolo, então um desafio 402 não pago expõe tanto o exemplo quanto os campos de resposta obrigatórios concretos antes que um agente autorize o pagamento. Rotas, entradas, preços, liquidação e manipuladores permanecem inalterados.

A versão 1.11.14 projeta os mesmos treze contratos de resposta no catálogo gratuito de OpenAPI e ações. Agentes de descoberta agora podem inspecionar campos obrigatórios concretos e um exemplo antes de sondar uma rota paga; /read também é descrito como o objeto JSON que seu manipulador realmente retorna em vez de uma string Markdown bruta. Um mapa de contrato chaveado por rota conduz o desafio x402, OpenAPI e catálogo de ações para evitar que as três superfícies de máquina se afastem.

A versão 1.11.16 vincula a referência versionada e sem credenciais agent-payment-policy da raiz da máquina, metadados de serviço OpenAPI e llms.txt. A referência não tem executor de carteira, assinante de pagamento, custódia ou verificador pago hospedado. Ela dá aos compradores de máquina um primitivo estável de política e evidência sem alterar as rotas, preços, requisitos de pagamento ou liquidação do comerciante.

A versão 1.13.1 avança essa referência de comprador voltada para máquina para o pacote público 0.4.0. A raiz, metadados OpenAPI e llms.txt agora anunciam autorização exata de forma de execução mais esquema v2 de cobertura de controle de quatorze dimensões. Isso segue evidências em primeira pessoa de Tempo e Solana de que regras de permissão de método e instrução nativas do provedor podem admitir ações aprovadas duplicadas. Nenhuma rota, preço, manipulador, requisito de pagamento ou liquidação do comerciante muda.

A versão 1.14.0 transforma a falha de signatário delegado entre cadeias que encontramos em um produto pago sem credenciais. POST /security/wallet-policy-conformance aceita apenas uma matriz limitada e padronizada de permitir, negar e erro. Ela separa a lista de permissões de operação do controle exato de forma de execução, credita apenas uma negação explícita de política do provedor como aplicação nativa do provedor e retorna conformant, partial ou unsafe sem pontuação opaca. Formas inválidas ou contendo segredos são rejeitadas antes do pagamento. O avaliador não aceita credencial de carteira, assinatura, corpo de transação, acesso à carteira ou autoridade de transmissão e não afirma ter executado os testes de provedor do chamador.

A versão 1.14.1 publica os casos padronizados exatos, classes de evidência, esquema de entrada, esquema de saída, método, protocolos e preço atômico no contrato canônico gratuito /schemas/wallet-policy-conformance-v1.json. A rota paga, preço, lógica de decisão, portões de pagamento e liquidação permanecem inalterados. Clientes de máquina agora podem construir e validar a matriz sem decodificar um desafio de pagamento.

A versão 1.14.2 move a taxonomia, validador estrito, avaliador offline e JSON Schemas para o agent-payment-policy@0.5.0 público; o produto hospedado agora importa esse pacote em vez de manter uma duplicata privada. O pacote público também fornece comandos CLI wallet-policy-init, wallet-policy-check e wallet-policy-schema. Um caso pretendido não executado é corretamente partial, enquanto uma ação pretendida bloqueada comprovada ou uma mutação permitida permanece unsafe. A rota hospedada, preço de 0,01 USDC, termos de pagamento e limite sem credenciais permanecem inalterados.

A versão 1.14.3 avança a dependência pública padrão para agent-payment-policy@0.5.1. O crédito de controle nativo do provedor agora exige que cada caso observado para esse controle passe. Um caso de forma opcional negada não pode mais mascarar um caso de ação aprovada duplicada permitida. Os adaptadores Privy Tempo e Solana classificam a forma exata de execução como não verificada e as políticas nativas gerais como inseguras, correspondendo à evidência em primeira pessoa. Rota, preço, pagamento e limites de credenciais permanecem inalterados.

A versão 1.15.0 adiciona um produto separado de política de carteira com estado a partir do experimento de limite cumulativo Privy em primeira pessoa do projeto. POST /security/stateful-wallet-policy-conformance avalia sete casos padronizados seguros para limites sequenciais, contabilidade assinada mas não transmitida, extração ABI, sobresubscrição concorrente, falha de referência de contador e serialização de aplicação. GET /schemas/stateful-wallet-policy-conformance-v1.json publica o contrato gratuito de construção. O avaliador vem do agent-payment-policy@0.6.0 público, não aceita credenciais ou payloads brutos do provedor e mantém a aplicação de política do provedor e do aplicativo separadas.

A versão 1.15.1 transforma evidência de catálogo desatualizado em primeira pessoa em um recurso limitado de auditoria de descobribilidade. Chamadores podem fornecer expectedPriceUsd junto com uma rota exata para comparar preços de rota anunciados no catálogo nas dez visões públicas de descoberta. O resultado distingue estados de correspondência, deriva, misto, preço desconhecido e rota ausente e retorna uma sequência máxima de remediação de um canário somente após os termos ao vivo de propriedade concordarem. Nunca trata a expectativa do chamador como verdade de tempo de execução, não faz pagamento de catálogo e deixa a propagação assíncrona para monitoramento orientado a eventos.

A versão 1.15.2 repara o caminho de medição para os dois contratos gratuitos de política de carteira e seus avaliadores pagos correspondentes. Todas as quatro rotas agora têm classificações comerciais exatas. Eventos históricos de /schemas/* permanecem na contagem bruta sem correspondência, mas são excluídos da interpretação de demanda semântica porque o livro-razão seguro de privacidade não reteve detalhes de caminho suficientes para reclassificá-los. Novos eventos exatos produzem funis agregados do mesmo cliente, da leitura bem-sucedida do contrato gratuito ao desafio de rota paga, credencial analisável e entrega. O snapshot público não expõe ator, credencial, caminho bruto, carteira ou payload do provedor, e leituras de contrato permanecem como evidência de alcance em vez de demanda.

A versão 1.16.0 atualiza o pré-voo de oferta de pagamento de paridade de protocolo sozinha para coerência opcional de catálogo para tempo de execução. Um chamador pode enviar um candidato exato de catálogo com o formulário POST ou MCP, e o produto o compara apenas com a oferta de protocolo sem assinatura ao vivo correspondente em solicitação, protocolo, valor, rede, ativo, destinatário e expiração usando o agent-payment-policy@0.7.0 público. Deriva explícita produz review_required; campos de catálogo ausentes permanecem como um resultado parcial visível. A janela de validade x402 é derivada de maxTimeoutSeconds, entrada de catálogo malformada é rejeitada antes do pagamento, e a solicitação ainda não usa credencial de destino, carteira, assinatura, liquidação, redirecionamento ou corpo de resposta. Version 1.16.1 atualiza a auditoria existente de descoberta de agentes sem adicionar outro produto ou alterar seu preço de 0,05 USDC. Um runtimeUrl opcional deve usar a origem auditada e a rota exata solicitada. A auditoria faz uma única solicitação sem credenciais, fixada por DNS e apenas de cabeçalhos, aceita uma referência de preço somente quando os termos x402 e MPP não assinados ao vivo são analisáveis e coerentes, e então compara esse valor canônico em Base-USDC com cada observação do registro. Expectativas fornecidas pelo chamador continuam suportadas e claramente rotuladas, enquanto uma divergência com a verdade em tempo de execução se torna uma constatação própria. O resultado ainda não assina nada, não envia pagamento ao alvo, não segue redirecionamentos e não lê o corpo da resposta do alvo.

A versão 1.16.2 adiciona identidade de listagem em nível de rota à mesma auditoria. Cada observação do catálogo agora informa se a rota exata é canônica, duplicada, somente alias ou dividida entre origens canônicas e não canônicas. Um candidato a alias exige um payTo explícito e correspondência exata de rota, e a saída declara que isso não prova propriedade do hostname. Isso detecta aliases de marketplace desatualizados e listagens duplicadas por chave de URL, além de desvios de preço, preservando o mesmo produto de 0,05 USDC, o limite de solicitação e a varredura de catálogo sem gastos.

A versão 1.16.3 torna explícito o limite da evidência de identidade. Um registro não canônico que compartilha o payTo fornecido pelo chamador e a rota exata é um candidato a alias, não uma prova de que o vendedor possui o hostname. Cada fonte agora retorna identityBasis, ownershipProven e um limite de evidência em linguagem simples para que uma correção automatizada possa preservar o registro canônico sem aposentar um endpoint de terceiros com base em evidências circunstanciais.

A versão 1.23.35 estende essa auditoria existente sem adicionar uma rota ou alterar seu preço de 0,05 USDC. Com materializationAudit=true, uma rota exata GET ou POST é verificada pelo validador atual de vendedor da Coinbase e pela leitura reversa de recurso exato do Bazaar. O resultado distingue materialized, provider_accepted_not_materialized, seller_not_provider_eligible e unresolved em vez de tratar todo resultado classificado ausente da mesma forma. A aceitação da validação permanece como evidência pontual retornada pelo provedor, não como autoridade de listagem, demanda, liquidação ou reindexação. A verificação opcional não usa credencial, assinatura ou pagamento; a Coinbase pode fazer uma solicitação não paga ao vendedor usando o método solicitado.

A versão 1.16.4 substituiu o classificador privado de identidade da auditoria de rota pelo primitivo público agent-payment-policy@0.8.0 com proveniência. Catálogos que não retornam registros correspondentes agora são registrados como verificados e route_absent; correspondências de origem canônica permanecem observações, não alegações de propriedade. Isso cria um contrato compartilhado e instalável para o vendedor ao vivo e ferramentas independentes do comprador, sem adicionar credenciais, acesso à carteira, assinatura, pagamento ou identidades de liquidação retidas.

A versão 1.18.3 completa exemplos construíveis por máquina para as rotas de prova de liquidação Base e recibo Solana e dá ao alias do Circle Gateway o mesmo esquema de resposta de sucesso autoral que o preflight da oferta de pagamento canônica.

A versão 1.18.2 publica relatórios de resposta recursivos sob seu identificador de esquema v2 imutável.

A versão 1.18.1 adiciona caminhos de resposta garantidos recursivamente ao relatório limitado, para que um vendedor que exija apenas um envelope data de nível superior não pareça prometer um payload de decisão data.attributes aninhado.

A versão 1.18.0 mantém o controle de identidade de alias de catálogo assinado e adiciona uma verificação limitada de contrato de resposta do vendedor ao preflight da oferta de pagamento. A rota agora lê o documento OpenAPI público de mesma origem do vendedor exato sob um limite estrito de tamanho e informa se a operação GET exata declara um esquema de sucesso JSON autocontido com campos obrigatórios tipados. Ela nunca lê o corpo pago do alvo, e a declaração do vendedor permanece consultiva até que uma resposta paga passe pelo validador de saída autorizado independentemente pelo comprador.

A versão 1.22.3 transforma declarações de vendedor que excedem o teto de bytes da auditoria limitada na lacuna específica openapi_too_large em vez de uma falha genérica de auditoria limitada. O teto permanece inalterado e nenhum esquema é inferido.

A versão 1.22.2 exclui tanto a origem canônica do SameDayDesk quanto seu antigo alias de catálogo Railway conhecido da pesquisa qualificada por contrato. O Agent402 classificou ambos os registros para a primeira consulta ao vivo em linguagem do comprador, provando que excluir apenas o hostname canônico não excluía a oferta própria no nível de identidade de serviço.

A versão 1.22.1 adiciona metadados obrigatórios de seleção MCP para a nova ferramenta de pesquisa e fortalece o teste de fumaça de inicialização de produção para que um lançamento não possa passar apenas porque o HTTP está escutando enquanto a montagem MCP assíncrona falhou.

A versão 1.22.0 adiciona uma pesquisa paga de serviço de máquina qualificada por contrato. Um comprador fornece uma intenção de capacidade e caminhos de resposta JSON exigidos recursivamente. A rota pesquisa o Agent402 e o catálogo oficial do MPP, exclui oferta própria e rotas não resolvidas antes da auditoria, e retorna candidatos limitados compráveis por máquina ou prontos para contrato, além de códigos de rejeição controlados. Ela não usa credencial ou carteira, não envia POST ao vendedor ou pagamento ao alvo, não lê corpo pago e retorna apenas um resumo da consulta. A declaração de implantação assinada agora vincula vinte e três pares exatos de método HTTP e caminho.

A versão 1.17.0 encerrou a ambiguidade de alias de catálogo com uma declaração de implantação assinada opcional de agent-payment-policy@0.9.0. O JWS de curta duração em /.well-known/agent-payment-policy-service-deployment.json vincula a origem canônica agents.samedaydesk.com aos pares atuais de método HTTP e caminho pagos e às identidades exatas de liquidação Base USDC x402 e MPP. Cada origem de implantação carrega seu próprio escopo de rota e liquidação, para que um alias futuro não possa herdar a autoridade de outra origem.

A chave pública Ed25519 em /.well-known/agent-payment-policy-service-deployment.pem é a mesma chave bruta que o agentWallet no registro ERC-8004 Solana do SameDayDesk. A chave de assinatura permanece offline e não é implantada. A resposta JWS permanece um envelope estrito; seus ponteiros de chave e registro usam cabeçalhos HTTP Link e o documento de registro ERC-8004. /healthz relata o ID da declaração, impressão digital da chave, contagem de rotas, expiração e estado ativo para que a rotação possa ser monitorada. A declaração prova o controle dessa chave registrada e do vínculo de serviço declarado. Ela não autoriza, assina ou envia um pagamento do comprador.

A versão 1.11.15 valida toda declaração do Bazaar contra seu próprio JSON Schema antes da inicialização. Seis rotas mais recentes foram liquidadas com sucesso anteriormente enquanto a Coinbase rejeitava seus metadados de descoberta porque seus exemplos de saída omitiam campos marcados como obrigatórios pelos mesmos esquemas. Os exemplos agora estão em conformidade, e bazaar-contract-audit.mjs verifica toda rota paga elegível ao CDP Bazaar ao vivo por meio de sondas HTTP 402 sem credenciais, sem reter cabeçalhos ou valores de consulta. Rails de liquidação x402 alternativos são relatados como exclusões explícitas em vez de serem classificados erroneamente como declarações Bazaar falhas.

discovery-drift.mjs é uma biblioteca e CLI sem credenciais que compara a descoberta de registro/catálogo com requisitos de pagamento não pagos ao vivo para recurso, rede, ativo, amountAtomic e frescor da observação. Não é uma rota paga montada por padrão. Copie e cole:

node discovery-drift.mjs observe --url 'https://agent-economy-signal-x402-mainnet.bronzetti-andrea.workers.dev/premium/agent-brief' --bazaar-pay-to '0xbda48b29607b9dc66ef7e38b68ad53f2b17efb23'

A versão 1.11.18 adiciona um funil de qualidade de fonte ao agregado público. Cada fonte de descoberta controlada agora relata observações juntamente com atores distintos e repetidos nos estágios de descoberta, rota paga, desafio, tentativa de credencial e sucesso pago. As taxas de desafio estão disponíveis por solicitação e por ator, para que um rastreador de alta frequência não pareça mais um alcance amplo de máquina. As conversões de desafio para pagamento são atribuídas à fonte do primeiro desafio observado. Agentes de usuário brutos, endereços de rede e identificadores de atores permanecem privados e não são retornados.

A versão 1.11.19 inicia uma coorte separada de fontes prospectivas de provedores de IA. Ela usa tokens HTTP exatos publicados pelo provedor para distinguir tráfego de pesquisa, busca do usuário e treinamento da OpenAI, Anthropic e Perplexity, além de rastreamentos de agentes do Google Cloud Vertex. Google-Extended é intencionalmente excluído porque o Google afirma que não possui uma string distinta de agente de usuário HTTP. A coorte de detalhes tem sua própria linha de base, preserva registros genéricos históricos, relata o mesmo funil de atores e trata todo rótulo como uma observação não autenticada, não como prova de referência.

A versão 1.11.20 repara os metadados de recurso consumidos por agentes de carteira com capacidade de pagamento. Cada um dos catorze desafios x402 v2 agora carrega o serviceName validado no nível do provedor e cinco tags limitadas de capacidade de rota no objeto de recurso padrão de nível superior. A inicialização falha de forma segura se a cobertura de rota paga e a cobertura de metadados divergirem. A auditoria de contrato do Bazaar agora rejeita uma rota cuja extensão é válida, mas cujo nome ou tags de recurso estão ausentes ou inválidos. Preços, saídas, liquidação, privacidade, rotas e termos MPP nativos permanecem inalterados.

A versão 1.12.0 adiciona /chain/transaction-receipt a 0,002 USDC após um experimento de mercado ao vivo encontrar liquidação no nível do provedor para utilitários de cadeia baratos, mas duas falhas de entrega com gasto zero de uma rota de recibo concorrente muito visualizada. A nova rota aceita um hash de transação minerada Base ou Ethereum e retorna status normalizado, tempo de bloco, campos de gás e taxas, eventos Transfer ERC-20 decodificados e transferências USDC canônicas. Hashes inválidos e redes não suportadas são rejeitados antes do pagamento. Logs brutos, acesso à carteira, assinatura e transmissão estão fora do limite do produto.

A versão 1.12.1 repara o limite de entrega autenticada para a vitrine Solana /commerce/payment-offer-preflight. Após o gateway Solana verificar e liquidar seu próprio pagamento x402 ou MPP, seu cabeçalho interno privado agora alcança o produto determinístico diretamente, em vez de encontrar um segundo portão de pagamento Base. Solicitações sem o cabeçalho privado exato mantêm o comportamento comum Base x402 e MPP. Credenciais do alvo e pagamentos ao alvo permanecem fora do limite do produto de preflight.

A versão 1.12.2 mantém as superfícies de descoberta de propriedade do vendedor sincronizadas com o catálogo canônico de ações pagas. O A2A Agent Card agora usa a versão real do serviço, mantém a habilidade de catálogo agregado primeiro e anexa uma habilidade explícita somente de descoberta por rota paga. O documento de registro ERC-8004 mantém seus pontos de entrada de protocolo e adiciona as mesmas URLs diretas de ação paga. O descritor A2A reutiliza o ID de habilidade agregada canônica, e mensagens recebidas devem carregar o papel de usuário normativo, ID de mensagem e pelo menos uma parte. Essas mudanças melhoram a descoberta de rotas, mas não reivindicam suporte para operações de tarefa A2A não implementadas.

A versão 1.12.3 transforma essa lição de descoberta em uma auditoria opcional do vendedor. Defina surfaceAudit=true na rota de descoberta paga existente para verificar se a rota esperada aparece no A2A Agent Card público do alvo, no documento de registro ERC-8004 e no catálogo de ações. A busca do alvo é restrita a três caminhos JSON fixos de mesma origem, fixa uma resposta DNS totalmente pública, rejeita redirecionamentos, limita cada resposta a 512 KiB e expira após cinco segundos. O padrão permanece somente catálogo e não busca a origem do alvo.

A versão 1.12.4 dá à sonda JSON POST /work/opportunity-preflight o mesmo contrato completo de entrada e saída do Bazaar que a rota GET existente. Isso remove erros de esquema de descoberta de máquina sem alterar o preço, validação, manipulador, resposta ou comportamento de pagamento. POST vazio não autenticado permanece um desafio somente de descoberta; uma chamada paga ainda deve fornecer e vincular o corpo obrigatório. Version 1.13.0 adiciona um produto de recibo de transação finalizada do Solana de 0,002 USDC. Ele valida a assinatura e qualquer mint, destinatário, valor e pagador opcionais antes do pagamento e, em seguida, retorna status finalizado limitado, taxa, deltas de proprietário de token SPL, deltas canônicos de USDC e descobertas de correspondência determinísticas. Ele lê o estado público do RPC somente após a liquidação e não tem carteira, assinatura, custódia ou autoridade de transmissão. A rota está disponível por meio do Base x402, MPP nativo, MCP, A2A e do gateway de pagamento Solana separado.

A versão 1.11.23 adiciona uma ponte de compatibilidade estreita para clientes MCP que repetem um tools/call pago com o cabeçalho HTTP x402 PAYMENT-SIGNATURE, mas não conseguem copiar o mesmo payload assinado em _meta["x402/payment"]. O comerciante decodifica apenas um cabeçalho limitado em formato de objeto em tools/call, nunca substitui os metadados MCP canônicos e passa o resultado para o verificador @x402/mcp existente. A ponte não confia no cabeçalho, não altera os termos de pagamento e não ignora a validação de assinatura, valor, ativo, rede, nonce ou liquidação.

A versão 1.11.24 publica as opções exatas de pagamento x402 ao vivo de cada ferramenta nos metadados MCP tools/list. Clientes compatíveis podem inspecionar preço, ativo, rede, destinatário e esquema antes de chamar e, em seguida, anexar um payload assinado novo ao primeiro tools/call em vez de depender de uma repetição de desafio. A verificação e a liquidação em tempo de execução permanecem autoritativas, e o caminho de desafio não pago permanece inalterado.

A versão 1.11.26 aprimora o contrato de seleção voltado para máquinas para /commerce/payment-offer-preflight: compare os desafios e termos de pagamento x402 e MPP antes da autorização do comprador. O produto de 0,005 USDC ainda aceita uma URL GET HTTPS pública exata e retorna ofertas normalizadas, verificações de vinculação de URL e realm, descobertas de expiração e paridade econômica. Ele rejeita credenciais, destinos locais ou não públicos, parâmetros não resolvidos e redirecionamentos, fixa um resultado DNS público, lê apenas cabeçalhos de resposta, nunca assina ou envia um pagamento de destino e não retorna estado de desafio opaco.

A versão 1.11.27 mantém o contrato compacto do agente /skill.md sincronizado com o catálogo de ações de quatorze rotas. Agora ele nomeia o pré-voo de oferta de pagamento em seu vocabulário de seleção e declara o limite de inspeção de destino: nenhuma credencial, assinatura ou pagamento de destino, redirecionamento ou leitura de corpo de resposta. Um teste de regressão mantém este produto focado de autorização de comprador presente em versões futuras.

A versão 1.11.28 remove o modo de falha manual do inventário de rotas. O contrato compacto agora renderiza e valida cada ação paga, preço exato e protocolo suportado a partir do catálogo canônico de ações de máquina. Contratos de ação vazios, malformados ou duplicados falham de forma fechada, de modo que uma adição futura de rota não pode deixar a superfície compacta do agente silenciosamente desatualizada.

A versão 1.11.29 adiciona uma transferência gratuita de catálogo de máquina para AgenticTrade sem colocar um segundo portão de pagamento na frente do SameDayDesk. O catálogo informa aos compradores para chamar a URL da ação selecionada diretamente, satisfazer seu desafio x402 ou MPP vinculado à rota e, opcionalmente, carregar o rótulo de origem agentictrade-v1 declarado. Esse rótulo entra no funil medido de descoberta para pagamento, não armazena token bruto e não pode alterar preço, pagamento ou acesso.

A versão 1.11.30 adiciona um diagnóstico de proxy AgenticTrade sem valor na resposta do catálogo. Ele relata apenas quais nomes de cabeçalho X-ACF-* chegaram à origem e se os campos de assinatura, timestamp e prova de uso estão presentes. Ele nunca retorna seus valores, e as respostas com proxy são marcadas como private, no-store.

A versão 1.11.31 inclui o mesmo diagnóstico sem valor no corpo do catálogo com proxy porque o AgenticTrade retorna intencionalmente apenas seus próprios cabeçalhos de cobrança ao chamador. As respostas diretas do catálogo permanecem inalteradas e publicamente armazenáveis em cache.

A versão 1.9.7 reconcilia privadamente cada referência pós-baseline com seu recibo canônico da Base. Um registro é aceito somente quando a transação foi bem-sucedida, exatamente uma transferência canônica de USDC da Base alcançou o tesouro configurado, o valor atômico corresponde à resposta paga e o remetente da transferência corresponde ao pseudônimo do pagador da solicitação quando disponível. Referências duplicadas e todas as incompatibilidades falham de forma fechada. O livro-razão privado em modo 0600 retém a referência; a saúde pública e a saída de demanda expõem apenas contagens agregadas de liquidação, valores atômicos por classe de evidência e rota, contagens de problemas e um estado de erro genérico.

A versão 1.9 adiciona suporte MPP evm/charge de mesma rota a todas as doze capacidades HTTP pagas sem substituir o middleware x402 existente. Uma solicitação não paga agora carrega tanto WWW-Authenticate: Payment quanto PAYMENT-REQUIRED. Credenciais MPP nativas usam Authorization: Payment e chamadas bem-sucedidas retornam Payment-Receipt; o x402 mantém suas extensões Bazaar, identificador de pagamento, oferta/recibo assinado e PAYMENT-RESPONSE. Os desafios MPP são vinculados ao método canônico, caminho e query ordenada. Ambos os protocolos participam de telemetria segura para privacidade e repetição de solicitações, e o OpenAPI 3.1 expõe ofertas x-payment-info válidas por operação.

A versão 1.9.3 gera duas visualizações de descoberta específicas de registro a partir da mesma fonte de rota e preço. /openapi.json carrega o preço USD estruturado, declarações de protocolo, orientação de agente, declarações de autenticação de rota pública e esquemas de resposta verdadeiros usados pelo AgentCash e MPPScan. /mpp-openapi.json carrega offers[] MPP oficial sem campos planos incompatíveis. IDs de operação estáveis e tags de capacidade tornam o catálogo público mais fácil para agentes pesquisarem, classificarem e invocarem. Desafios 402 em tempo de execução permanecem autoritativos para ambas as visualizações.

A versão 1.23.6 estende a repetição vinculada à solicitação para cada rota POST JSON paga e vincula a impressão digital de repetição tanto à credencial de pagamento liquidada exata anterior quanto aos bytes brutos exatos da solicitação. Isso permite que uma resposta POST bem-sucedida perdida seja repetida sem executar o manipulador ou cobrar novamente, enquanto uma credencial, corpo, entrada, pagador ou termo de pagamento alterado falha com um HTTP 409 não cobrado. A versão 1.23.7 publica um contrato de efeito somente leitura experimental em /.well-known/paid-action-effects.json, em cada operação OpenAPI POST paga e em cabeçalhos de resposta. Ela também mantém solicitações POST pagas não pagas fora da telemetria do aplicativo, ao mesmo tempo em que declara que o estado de desafio do protocolo pode ainda existir e que a repetição de resposta de pagamento não é idempotência de efeito de negócio. Nenhuma adoção de padrão externo é reivindicada. A versão 1.8 adiciona um pré-voo determinístico de oportunidade paga. O chamador fornece recompensa, tempo de execução, custo de oportunidade por hora, computação, gasto obrigatório, valor reutilizável, concorrência e uma probabilidade de seleção explícita. O resultado retorna attempt, verify_first ou abandon, economia de ponto de equilíbrio transparente, portões rígidos de acesso e financiamento e um cartão opcional datado do Settlement Radar. Ele não raspa um quadro restrito nem toca em conta, reivindicação, lance, pagamento ou envio da plataforma de origem. A versão 1.7 adicionou repetição idempotente vinculada à solicitação para compradores HTTP que fornecem a extensão de identificador de pagamento x402. Uma resposta JSON bem-sucedida é armazenada em cache por 15 minutos no volume privado do Railway. A chave de cache é um HMAC do ID de pagamento lógico, e a vinculação cobre a URL canônica completa, método HTTP, pagador, rede, ativo, valor e destinatário. IDs de pagamento brutos, endereços de pagadores e URLs de solicitação não são armazenados. Uma repetição exata recebe a resposta original e o recibo de liquidação assinado sem um segundo pagamento; entrada, pagador ou termos de pagamento alterados retornam um HTTP 409 não cobrado. As repetições são contadas separadamente dos novos eventos de sucesso pagos.

Os rastreadores de agentes observados usam várias convenções de descoberta. O manifesto canônico permanece /.well-known/x402, com aliases compatíveis em /.well-known/x402.json, /x402.json e /api/x402. O documento OpenAPI compatível com AgentCash permanece /openapi.json, com /openapi.yaml e /swagger.json retornando o mesmo documento JSON. A descoberta oficial MPP usa /mpp-openapi.json, com /openapi.mpp.json como alias. GET /mcp retorna um descritor de transporte gratuito; a descoberta MCP real e as chamadas de ferramentas pagas usam HTTP transmitível em POST /mcp. Agentes que preferem um contrato de instrução compacto podem ler /skill.md (ou /SKILL.md), enquanto /api/actions retorna as treze ações GET canônicas com sua URL, descrição, preço atômico exato em USDC, tipo MIME, rede e payTo. Clientes Agent Skills podem enviar X-SameDayDesk-Agent-Source: agent-skills-v1 na solicitação inicial e na repetição paga. A telemetria reduz esse valor exato permitido ao rótulo seguro para público agent-skills e nunca armazena o cabeçalho bruto. Isso é atribuição declarada e falsificável, não autenticação, e não pode alterar preço, pagamento ou acesso. O cartão A2A v1.0 em /.well-known/agent-card.json anuncia uma habilidade gratuita limitada, discover-x402-paid-actions. POST /a2a/message:send retorna esse catálogo exato como uma mensagem direta A2A, dando aos clientes A2A um caminho baseado em padrões da descoberta de agentes para as ações x402 pagas existentes sem reivindicar execução arbitrária de tarefas.

O agent-card.json na raiz do repositório é um manifesto de compatibilidade para o importador GitHub atual do Global A2A Registry. Ele aponta de volta para o Agent Card v1.0 canônico e o documento OpenAPI; ele não substitui o cartão de produção. O manifesto de propriedade gerado pelo próprio registro é hospedado separadamente em https://samedaydesk.com/.well-known/agent-card.json; o cartão A2A v1.0 compatível com padrões permanece canônico em agents.samedaydesk.com.

Observador de sombra de pré-liquidação

morpho-preliquidation-shadow.mjs é o canal de evidência direta somente de observação selecionado pelo censo completo da Base. Ele observa os cinco mercados que concentram a execução histórica, deriva o limite real de saúde de pré-liquidação de cada mercado a partir do LLTV e pré-LLTV, verifica cada autorização observada diretamente em um bloco Base explícito e usa cursores de eventos por contrato.

Novas transações de execução são reproduzidas através do mecanismo determinístico de RPC de arquivo, até 20 por execução. O registro inclui latência de detecção, incentivo bruto de ativo de empréstimo e gás nativo, mantendo o limite explícito de que custos de swap, financiamento, falha, concorrência e MEV permanecem fora da reprodução. Posições abaixo do piso explícito de observação de dívida de 1 USD são classificadas como poeira em vez de oportunidades.

node morpho-preliquidation-shadow.mjs \
  --state /data/morpho-preliquidation-shadow-state.json \
  --history /data/morpho-preliquidation-shadow-history.ndjson

Arquivos de estado e histórico são forçados ao modo 0600. Uma mudança material significa uma autorização nova ou removida, uma transição para dentro ou fora da janela de risco específica do protocolo, um grande movimento de liquidez ou utilização, ou uma nova execução verificada de pré-liquidação. Nenhuma carteira, assinante, autorização, custódia ou principal faz parte do observador.

O callback Agoragentic é uma ponte separada de distribuição de marketplace. O marketplace lida com roteamento de compradores, liquidação e contabilidade de vendedores, enquanto o callback realiza a mesma auditoria de prontidão de busca de IA de produção atrás de um pequeno limite de segurança por IP. Clientes agentes diretos continuam a usar a rota x402 paga.

A ponte the402 é um segundo caminho de distribuição de marketplace. Ela autentica envios de trabalhos assinados com verificação HMAC com timestamp, aceita callbacks somente na origem oficial da API e envia um entregável de auditoria estruturado para liquidação automática. THE402_API_KEY, THE402_WEBHOOK_SECRET e THE402_SERVICE_ID são variáveis de ambiente somente do Railway.

O mesmo serviço também hospeda duas transferências de afiliado gratuitas e divulgadas usadas por guias verificados do SameDayDesk: /go/topify e /go/manychat. Elas cunham e armazenam em cache os links assinados expirantes do Agent Hansa no lado do servidor, validam o host de redirecionamento, não expõem chave de API e retornam noindex, nofollow mais no-store.

Implementação original do trilho

Um servidor Node/Express que retorna HTTP 402 Payment Required quando não pago e serve o recurso após o pagamento, liquidando USDC na mainnet da Base diretamente para nossa própria carteira:

payTo = 0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee

Verificado ao vivo (junho a agosto de 2026). O servidor inicializa e retorna respostas 402 corretas com requisitos de pagamento legíveis por máquina. O canário Morpho é amount=20000 = 0,02 USDC, network=eip155:8453, e asset=0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 = Base USDC, payTo igual à nossa carteira, além de uma extensão de descoberta Bazaar com esquemas de entrada e saída.

Decisão atual de produção

Caminho	Conta/Chave de API?	Base mainnet?	Alcance de descoberta
Facilitador CDP (`api.cdp.coinbase.com/platform/v2/x402`)	Sim, conta Coinbase CDP mais `CDP_API_KEY_ID` e `CDP_API_KEY_SECRET`	Sim	Padrão de produção. Catálogo CDP Bazaar, consulta de comerciante e busca semântica após o primeiro settlement
Facilitador público xpay (`facilitator.xpay.sh`)	Nenhuma	Sim (`eip155:8453`, esquema exato)	Caminho de settlement de fallback com descoberta autopublicada apenas
Facilitador público x402.org (`x402.org/facilitator`)	Nenhuma	Não, apenas testnet Base Sepolia	Catálogo de teste separado em `x402.org/facilitator/discovery/resources`

A produção usa CDP. As primeiras onze rotas passaram na verificação CDP ao vivo e completaram um settlement real. As oito originais aparecem na descoberta de comerciantes Bazaar. As três rotas de decisão Morpho mais recentes têm recibos de settlement bem-sucedidos, e um pagador financiado distinto produziu isValid: true mais o status da extensão Bazaar processing para todas as três. Elas ainda não entraram na descoberta de comerciantes após a janela de cache documentada e um novo settlement, então isso é rastreado como um incidente downstream de indexação CDP, não uma falha de metadados de rota. A reprodução sem segredos está anexada ao x402 issue #2156. Mantenha xpay como fallback de continuidade sem chave, não como o facilitador normal de produção.

A décima segunda rota, /work/opportunity-preflight, está ao vivo a 0,05 USDC e completou um settlement excluído pelo proprietário para QA de integração e indexação. A décima terceira rota, /distribution/agent-discoverability-audit, está ao vivo a 0,05 USDC e produtiza o benchmark de catálogo cego à marca usado no próprio SameDayDesk. Ela consulta Bazaar, Agentic Market, Agent402, Circle, AgenticTrade, o catálogo oficial MPP, MPPScan, PayanAgent, x402.jobs e a busca pública 8004Market sem credenciais de catálogo ou pagamentos, preserva a ordem nativa do registro e relata cobertura, classificação, concorrentes acima do alvo e próximas ações baseadas em evidências como observações pontuais, não uma pontuação composta. Bazaar e Agentic Market são explicitamente uma família de fontes Coinbase, então a saída não infla o alcance independente contando ambas as visualizações como canais de aquisição separados. PayanAgent é rotulado como uma superfície agregadora dependente porque seu catálogo inclui registros de ecossistema, como fornecimento de origem Coinbase; sua classificação de recuperação é útil, mas não é fornecimento subjacente independente. 8004Market é rotulado como uma superfície de propagação de identidade porque indexa identidades on-chain do Solana Agent Registry; a recuperação lá prova identidade pública e propagação de capacidade, não uma chamada de comprador, settlement, ou demanda independente. Uma verificação opcional limitada de superfície de vendedor relata se uma rota exata aparece no Agent Card público do alvo, registro ERC-8004 e catálogo de ações sem enfraquecer o método de catálogo padrão sem credenciais.

A versão 1.11.42 adiciona um contrato POST /work/opportunity-preflight de corpo JSON para compradores de fluxo de trabalho de máquina, preservando o contrato GET existente e o preço de 0,05 USDC. Sondas de registro HEAD ou POST vazias sem credenciais podem inspecionar o desafio de pagamento; entrada paga ausente ou malformada permanece um 400 sem cobrança. Isso torna um produto útil diretamente chamável de mercados de fluxo de trabalho de centavos inteiros sem uma rota duplicada ou um preço enganoso.

A versão 1.11.43 adiciona uma amostra gratuita exata GET /work/opportunity-preflight?trial=1 para catálogos de máquina. Ela retorna aritmética fixa com sample: true e charged: false, não realiza trabalho externo e não aceita entradas de chamador. Chamadas GET e POST personalizadas permanecem com gate de pagamento de 0,05 USDC.

A versão 1.11.41 espelha a oferta canônica x402 v2 Payment-Required no corpo JSON 402, de outra forma vazio, para registros que ainda indexam o corpo legado. O preflight de oferta de pagamento também expõe uma rota POST de corpo JSON equivalente para construtores de fluxo de trabalho, preservando a rota GET validada.

A versão 1.11.40 adiciona x402.jobs como uma décima visualização de busca pública. O adaptador usa uma consulta de palavra-chave compacta, determinística e divulgada porque a busca x402.jobs é lexical, não semântica, então preserva sua ordem de popularidade pública e verifica a rota alvo esperada. O servidor próprio verificado do SameDayDesk agora lista todas as quatorze rotas Base com uma linha de base de zero chamadas e zero valor, então atividade posterior pode ser medida sem chamar validação ou listar demanda de tráfego.

A versão 1.11.39 adiciona a prova pública de propriedade do servidor x402.jobs em /.well-known/x402-verification.json. O desafio é apenas uma reivindicação de diretório público e não concede autoridade de API, carteira ou pagamento.

A versão 1.11.38 adiciona um caminho de acesso distinto Circle Gateway Nanopayments para preflight de oferta de pagamento ao mesmo preço de 0,005 USDC. Ele usa o middleware oficial de vendedor @circle-fin/x402-batching 3.3.0, anuncia requisitos x402 GatewayWalletBatched nas redes que a Circle reporta em tempo de execução e liquida no saldo Gateway do vendedor. As rotas existentes Base exatas, MPP nativo, MCP, implementação de produto e diretas permanecem inalteradas, então uma interrupção do Gateway não pode bloqueá-las. O OpenAPI principal e o manifesto x402 expõem o caminho alternativo; o OpenAPI MPP não o rotula incorretamente como uma rota MPP.

A versão 1.11.37 adiciona 8004Market como uma nona visualização de busca pública na auditoria paga de descobribilidade. Ela corresponde ao alvo por origens de serviço duráveis e rotas incorporadas nos metadados de identidade Solana indexados, preservando a ordem semântica nativa do servidor 8004Market.

A versão 1.11.36 expande os metadados de identidade Solana com as capacidades reais no nível de rota e as superfícies de descoberta OpenAPI, skill, x402 e MPP Base e Solana após o primeiro benchmark congelado 8004Market expor zero recuperação de capacidade da descrição de lançamento mais ampla.

A versão 1.11.35 adiciona /.well-known/agent-registration.json, um documento de registro durável compatível com ERC-8004 para o Solana Agent Registry. Ele vincula as superfícies MCP e A2A existentes, a loja Solana x402 e MPP, a carteira de settlement Solana dedicada e suporte x402 explícito. O identificador de ativo on-chain é injetado apenas após registro bem-sucedido, então o URI permanece estável e o documento nunca inventa uma identidade antes de ela existir.

A versão 1.11.34 adiciona a busca pública PayanAgent como uma oitava visualização de registro com um rótulo de dependência explícito. A versão 1.11.33 adicionou a busca pública MPPScan; sua ordem de busca de texto público permanece separada do estado de listagem direta. A versão 1.11.32 adicionou AgenticTrade; o catálogo plano oficial MPP permanece classificado localmente.

A rota de preflight de oferta de pagamento está ao vivo a 0,005 USDC. Ela produtiza o limite de autorização do lado do comprador: busca os cabeçalhos não pagos de uma rota GET pública exata, normaliza ofertas x402 e MPP, verifica vinculação de URL e realm, detecta expiração e derivação entre protocolos e retorna uma decisão limitada antes de o comprador assinar o pagamento alvo.

Como o trilho funciona (por que "sem conta" é seguro)

O esquema exact liquida USDC via uma EIP-3009 transferWithAuthorization: o comprador (agente) assina uma autorização que move USDC diretamente da sua carteira para o nosso payTo on-chain. O facilitador apenas verifica a assinatura e transmite a transação; ele nunca detém o dinheiro. Então:

Qualquer que seja o facilitador que escolhermos, o USDC chega na nossa carteira payTo.
Nós detemos a chave de payTo; o facilitador não.
CDP e xpay são caminhos de facilitador não custodial. CDP retransmitiu os oito canários de vendedor ao vivo e os valores exatos de USDC chegaram à nossa carteira.

Este é o mesmo trilho que Frantic usou para pagar USDC mainnet real a esta carteira, então já sabemos que o settlement para 0x8904…3Cee funciona.

Respostas às cinco perguntas

1. Facilitador + autonomia

O facilitador público x402.org suporta apenas testnet Base Sepolia (eip155:84532); seu endpoint /supported não lista eip155:8453. Mainnet via x402.org é impossível.
O settlement Base mainnet não exige estritamente uma conta Coinbase CDP. O facilitador público xpay (https://facilitator.xpay.sh) suporta Base mainnet com esquema exato eip155:8453 sem conta e sem chave de API (verificado contra seu endpoint /supported ao vivo). Este é o caminho mainnet totalmente autônomo.
O facilitador CDP exige uma conta CDP e chaves de API. Sua vantagem é a descoberta de comerciantes Bazaar, busca semântica e a superfície de comprador MCP Bazaar.
A produção escolheu CDP após uma matriz de verificação ao vivo e oito settlements bem-sucedidos. xpay permanece como fallback sem chave.

2. Código exato do vendedor

Veja server.js. Linha atual do pacote (NÃO o x402-express@1.x plano legado):

@x402/express     2.16.0   paymentMiddleware, x402ResourceServer
@x402/core        2.16.0   HTTPFacilitatorClient   (import from @x402/core/server)
@x402/evm         2.16.0   ExactEvmScheme          (import from @x402/evm/exact/server)
@x402/extensions  2.16.0   declareDiscoveryExtension (import from @x402/extensions/bazaar)
@coinbase/x402    2.1.0    createFacilitatorConfig (only needed for CDP mainnet)
mppx              0.8.15   native MPP EVM charge challenge, credential, and receipt support

Conexão principal:

const facilitatorClient = new HTTPFacilitatorClient(
  createFacilitatorConfig(process.env.CDP_API_KEY_ID, process.env.CDP_API_KEY_SECRET)
);
const resourceServer = new x402ResourceServer(facilitatorClient)
  .register("eip155:8453", new ExactEvmScheme());

app.use(paymentMiddleware(
  { "GET /premium": { accepts: [{ scheme: "exact", price: "$0.01",
      network: "eip155:8453", payTo: "0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee" }],
      description: "...", mimeType: "application/json", extensions: { ... } } },
  resourceServer
));

3. Descoberta Bazaar

O extensions da rota usa declareDiscoveryExtension({ input, inputSchema, output, outputSchema }) (already in server.js). Isso anuncia a rota e seus esquemas JSON no payload 402 (verificado presente na resposta ao vivo). Aparecer no CDP Bazaar exige o facilitador CDP: o CDP cataloga uma rota após seu primeiro settlement bem-sucedido. A consulta de comerciante de produção retorna as oito rotas SameDayDesk originais; todas as três rotas de decisão Morpho mais recentes têm settlements CDP bem-sucedidos e extensões Bazaar processing aceitas, mas permanecem ausentes além da janela de cache documentada. O CDP também encontra as rotas Morpho originais e de auditoria profunda por busca semântica. Use a consulta de comerciante como evidência do estado do catálogo CDP, não como a contagem canônica de capacidades SameDayDesk; o manifesto próprio, MCP, A2A e superfícies OpenAPI permanecem completos em quatorze.

O CDP rejeitou três payloads de rota mais antigos cujas descrições de descoberta tinham 535, 581 e 629 caracteres, mesmo que a validação local de extensão tenha passado. Reescritas concisas de 294, 258 e 301 caracteres passaram. Um teste de limite x402 2.22.0 padrão isolou depois a aresta de compatibilidade exata: 501 caracteres foi rejeitado, enquanto 500 caracteres alcançou a verificação de assinatura do facilitador com todas as quatro extensões intactas. Testes de inicialização e superfície agora rejeitam todo recurso acima de 500 pontos de código Unicode. Execute verificação CDP ao vivo antes de um canário financiado.

4. Verificação de settlement

Após uma chamada paga, confirme que o USDC chegou em payTo na Base mainnet. O fluxo 402/200 também retorna um cabeçalho PAYMENT-RESPONSE com dados de settlement. Independentemente:

# USDC balanceOf(payTo) on Base mainnet via public RPC, no key:
curl -s -X POST https://mainnet.base.org -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_call","params":[{
    "to":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "data":"0x70a082310000000000000000000000008904df3de6dfee6a7c8cc38619d2f17806213cee"
  },"latest"]}'

O resultado é USDC atômico hex (divida por 1e6). Ou use nosso verificador de saldo existente da Base mainnet. Ou veja a carteira em https://basescan.org/address/0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee

5. Caminho recomendado mais limpo

Implante no CDP para a loja de produção. Ele preserva o settlement direto de USDC e adiciona o catálogo, busca semântica, consulta de comerciante e superfície de comprador MCP Bazaar. Mantenha xpay configurado como o caminho de recuperação sem chave.

Passos de implantação (Railway)

O repositório é um app Node sem configuração: npm start executa node server.js e vincula process.env.PORT (Railway define isso).

Implante este diretório diretamente ou envie a fonte do repositório.

Defina variáveis de ambiente no serviço Railway:

PAY_TO=0x8904dF3DE6DFEe6a7C8cc38619d2f17806213Cee
NETWORK=eip155:8453
PRICE=$0.05
FACILITATOR=cdp
CDP_API_KEY_ID=<CDP API key ID>
CDP_API_KEY_SECRET=<CDP API key secret>
MPP_SECRET_KEY=<random secret of at least 32 bytes>
COMMERCE_DATA_DIR=/data
COMMERCE_ACTOR_SECRET=<random 32-byte secret>
COMMERCE_INTERNAL_TOKEN=<random owner-canary token of at least 32 UTF-8 bytes>
COMMERCE_MCP_TYPED_SINCE=<ISO timestamp for the accepted typed-MCP producer generation>
COMMERCE_EXTERNAL_SINCE=<ISO timestamp after controlled launch canaries>
COMMERCE_AGENT_SOURCE_DETAIL_SINCE=<ISO timestamp after provider taxonomy release>
COMMERCE_SETTLEMENT_EVIDENCE_SINCE=<ISO timestamp after settlement-proof release>
COMMERCE_PAYER_CLASSES='[{"address":"0x...","class":"validation"}]'

As configurações principais de pagamento têm padrões seguros. A telemetria de produção usa um volume Railway montado em /data mais as duas variáveis secretas acima. Uma solicitação MCP de validação de release é atribuída somente quando fornece o token interno exato e um único x-samedaydesk-validation-marker correspondente a [A-Za-z0-9._~-]{16,128}. A linha armazenada contém apenas o digest SHA-256 separado por domínio do marcador. Nunca reutilize um marcador, persista seu valor bruto com telemetria ou classifique a linha de validação operacional do vendedor resultante como demanda independente, liquidação, contabilidade ou receita.

Gere um domínio público para o serviço.

Verifique:

curl https://<your-domain>/healthz          # -> {ok:true, network:eip155:8453, ...}
curl -i 'https://<your-domain>/defi/morpho-position?address=0x...' # -> HTTP 402 + WWW-Authenticate and PAYMENT-REQUIRED

Complete uma liquidação limitada por rota descoberta, então confirme a consulta do comerciante e a busca semântica. Registre liquidações do proprietário como fluxo de teste, não receita.

Recorra ao xpay sem alterar o código da rota

Se o CDP estiver indisponível e a continuidade for mais importante que a descoberta central, defina:

FACILITATOR=xpay

Reimplante. A liquidação base na mainnet continua, mas novas chamadas não alimentam mais os sinais de qualidade e atividade do CDP Bazaar.

Prove o trilho na testnet primeiro (opcional)

FACILITATOR=testnet
NETWORK=eip155:84532

Usa x402.org + Base Sepolia (USDC falso) para validar o loop completo 402→pay→200 antes de aceitar dinheiro real na mainnet.

Marketplace do Claude Code

A raiz deste repositório é um marketplace do Claude Code. O catálogo é .claude-plugin/marketplace.json. O plugin autocontido é plugins/samedaydesk-extract. Esse layout é um formato diferente do pacote Agent Plugins 1.0 em plugins/samedaydesk-x402. Mantenha ambos.

Instalação comum após este catálogo estar no branch padrão público:

/plugin marketplace add epistemedeus/x402-url-extractor
/plugin install samedaydesk-extract@samedaydesk-claude

Em seguida, invoque /samedaydesk-extract:web-extract com uma URL HTTPS pública, ou 1–5 URLs mais campos desejados explícitos para lote. A descoberta não é paga. O pagamento permanece no SameDayDesk 402 ao vivo. A autoridade de comprador com escopo existente pode ser usada quando já cobre o método, corpo e termos exatos ao vivo. Listagem e instalação não concedem nada. Resultados de pagamento desconhecidos são reconciliados em vez de repetidos. A instalação não é prova de invocação de modelo, pagamento ou demanda. Para JSON de extração já mantido, invoque /samedaydesk-extract:explicit-record com --input, --mapping, --schema e um diretório --out novo. Essa habilidade não busca nem paga. Isto não é uma submissão ao diretório oficial de plugins da Anthropic. Para um preflight HTTP sem credenciais e um caminho de compra @x402/fetch explicitamente autorizado contra POST /extract/batch (padrão) e GET /extract compatível com versões anteriores, incluindo recibo de tentativa não assinada opcional antes do envio e reconciliação somente leitura, veja examples/customer-x402. Esse exemplo não torna o Claude capaz de pagamento. Os escopos de credenciais MCP e HTTP permanecem distintos.

Verificações do mantenedor a partir da raiz do repositório:

npm run test:claude-marketplace
npm run test:claude-marketplace:live
claude plugin validate .
claude plugin validate ./plugins/samedaydesk-extract --strict

Não coloque o Claude no PATH do sistema a partir deste repositório. Use um binário já presente ou local à tarefa. O add owner/repo do GitHub permanece não verificado até que o catálogo esteja no branch padrão público. Até lá, verifique um clone git local em um perfil isolado novo, sem alterar uma instalação existente:

export CLAUDE_CONFIG_DIR="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-claude.XXXXXX")"
export CLAUDE_CODE_PLUGIN_CACHE_DIR="$CLAUDE_CONFIG_DIR/plugins"
export DISABLE_AUTOUPDATER=1 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
unset ANTHROPIC_API_KEY ANTHROPIC_AUTH_TOKEN CLAUDE_CODE_OAUTH_TOKEN CLAUDE_API_KEY
claude plugin marketplace add "$PWD" --scope user
claude plugin install samedaydesk-extract@samedaydesk-claude --scope user --yes
claude plugin list --json

Após a inspeção, unset CLAUDE_CONFIG_DIR CLAUDE_CODE_PLUGIN_CACHE_DIR para parar de usar esse perfil. Arquivos temporários são retidos; nenhum utilitário de limpeza é fornecido.

Config nativa do Goose

Arquivos streamable_http do Goose companheiro vivem em goose/. Eles não instalam o Goose, não mutam um perfil padrão nem reivindicam atribuição de comerciante. Pagar POST /extract/batch ou GET /extract com um cliente HTTP mantido permanece em examples/customer-x402; apenas a instalação do Goose não é capacidade de pagamento.

Perfil isolado copiável, com o Goose já instalado:

export GOOSE_PATH_ROOT="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-goose.XXXXXX")"
mkdir "$GOOSE_PATH_ROOT/config"
cp goose/goose.config.isolated.yaml "$GOOSE_PATH_ROOT/config/config.yaml"
GOOSE_TELEMETRY_OFF=1 GOOSE_DISABLE_KEYRING=1 goose info -v

goose info -v lê essa configuração isolada. Não abre a sessão MCP. Descoberta ao vivo não paga é uma inicialização separada mais verificação de tools/list (npm run test:goose-native:live). Exija extract e extract_batch com seus esquemas de entrada/saída ao vivo; ferramentas extras não relacionadas são aceitas. Um carregador de MCP fixture do Goose não faz parte deste repositório.

O YAML padrão não envia cabeçalhos de origem. O goose/goose.config.with-declared-source.yaml opcional não é autenticado, não está na lista de permissões do comerciante e não reivindica atribuição de comerciante.

Flag de sessão:

goose session --with-streamable-http-extension "https://agents.samedaydesk.com/mcp"

Deeplink: goose/goose.deeplink.txt.

Verificação de empacotamento do mantenedor: npm run test:goose-native. Receita de registro offline: goose/record.recipe.yaml mais goose/record.workflow.md. Quando o Goose já está instalado, valide em um perfil isolado novo com goose recipe validate goose/record.recipe.yaml. Essa verificação não é execução de modelo e não busca nem paga.

Habilidades do Hermes Agent

O Hermes Agent (Nous Research) já carrega arquivos SKILL.md de AgentSkills portáteis. Este repositório não adiciona um plugin Hermes, YAML MCP, carteira ou segundo paywall. A habilidade de extração existente é plugins/samedaydesk-x402/skills/web-extract/SKILL.md. A receita offline de mudança de página é plugins/samedaydesk-x402/skills/page-change/SKILL.md.

Descoberta isolada copiável, sem tocar em ~/.hermes ou chamar um modelo:

export HERMES_HOME="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-hermes.XXXXXX")"
HERMES_HOME="$HERMES_HOME" HERMES_AGENT_SRC=/path/to/NousResearch/hermes-agent \
  python3 hermes/check-isolated-loader.py

O comerciante também serve as três habilidades portáteis no índice well-known oficial /.well-known/skills/index.json. Após o deploy:

export HERMES_HOME="$(mktemp -d "${TMPDIR:-/tmp}/samedaydesk-hermes.XXXXXX")"
hermes skills search https://agents.samedaydesk.com --source well-known
hermes skills inspect well-known:https://agents.samedaydesk.com/.well-known/skills/web-extract
hermes skills install well-known:https://agents.samedaydesk.com/.well-known/skills/web-extract --yes

check-isolated-loader.py requer um perfil descartável novo e vazio, copia as três habilidades e usa a API de descoberta agent.skill_utils oficial do Hermes. Não instala o Hermes globalmente, não faz login em um provedor de modelo, não abre uma carteira nem executa um modelo. Descoberta e execução de pagamento são verificações separadas.

.hermes/skills ou .agents/skills local ao projeto dentro de um checkout git não carrega automaticamente. O Hermes exige hermes skills trust para essa raiz. Isso é um portão de aprovação do operador. Este pacote não adiciona esses diretórios.

Após os caminhos das habilidades existirem no branch padrão público, um usuário que já tem o Hermes também pode executar:

hermes skills install epistemedeus/x402-url-extractor/plugins/samedaydesk-x402/skills/web-extract
hermes skills install epistemedeus/x402-url-extractor/plugins/samedaydesk-x402/skills/page-change

Esse caminho de hub copia para o perfil desse usuário e executa a verificação de segurança da comunidade. Não o execute contra um perfil já autenticado a partir deste repositório. Pagar POST /extract/batch ou GET /extract com um cliente HTTP mantido permanece em examples/customer-x402. Esse exemplo não torna o Hermes capaz de pagamento. Os escopos de credenciais MCP e HTTP permanecem distintos.

Notas de instalação copiáveis: hermes/INSTALL.txt. Verificação de empacotamento do mantenedor: npm run test:hermes-native. Prova do carregador oficial com HERMES_AGENT_SRC definido: npm run test:hermes-native:loader. Replay do adaptador de índice do site, mesmas regras de perfil isolado, nunca contra ~/.hermes e nunca com --force ou allow_private_urls: npm run test:hermes-native:well-known.

Execução local

npm install
npm start
# then:
curl -i 'http://localhost:3000/defi/morpho-position?address=0x...' # HTTP 402

Arquivos

server.js — o servidor (facilitador/rede/preço orientado por env).
commerce-events.mjs — telemetria de demanda durável e segura para privacidade.
mpp-dual-stack.mjs — adaptador de autorização e recibo MPP nativo de mesma rota.
morpho-position.mjs — snapshot Morpho determinístico, estresse e verificações RPC.
morpho-protection.mjs — valores exatos de reparo sob estresse e modelos de ação não assinados.
morpho-market-underwrite.mjs — integridade de mercado multi-fonte, liquidez, concentração, saúde do tomador, histórico, dívida inadimplente e evidência de PreLiquidação.
morpho-preliquidation-replay.mjs — economia histórica de eventos PreLiquidate a partir de leituras diretas de estado de bloco.
morpho-preliquidation-census.mjs — censo repetível de fornecimento, autorização e execução na Base para seleção interna de mercado.
package.json — dependências fixadas exatas (verificadas para instalar e iniciar).
.claude-plugin/marketplace.json — catálogo do marketplace do Claude Code.
plugins/samedaydesk-extract/ — plugin autocontido do Claude Code (não Agent Plugins 1.0).
goose/: configuração nativa streamable_http do Goose, receitas de extração e registro e cópia de fluxo de trabalho.
hermes/ : notas de instalação isoladas do Hermes AgentSkills e verificador do carregador oficial.
examples/customer-x402/ — preflight sem credenciais mais exemplo de compra @x402/fetch explicitamente autorizado para POST /extract/batch (padrão) e GET /extract compatível com versões anteriores.
README.md — este guia.
extract.mjs — serviço pré-existente sem dependências "URL → dados estruturados limpos". Este é um recurso pago natural para colocar atrás de /premium: no manipulador de rota, chame seu extrator em um parâmetro de consulta ?url= e retorne o resultado estruturado em vez do placeholder {value:42}. Adicione ?url ao Bazaar inputSchema quando você o conectar.

Fontes (primárias, verificadas em agosto de 2026)

quickstart do vendedor x402: https://docs.x402.org/getting-started/quickstart-for-sellers
docs do CDP x402: https://docs.cdp.coinbase.com/x402/welcome
suporte de rede do CDP (x402.org = somente testnet; CDP = mainnet + chaves): https://docs.cdp.coinbase.com/x402/network-support
CDP Bazaar: https://docs.cdp.coinbase.com/x402/bazaar
monorepo x402: https://github.com/coinbase/x402
npm: @x402/express, @x402/core, @x402/evm, @x402/extensions, @coinbase/x402
facilitador público xpay ao vivo /supported (Base mainnet, sem chave): https://facilitator.xpay.sh/supported