BVNK vs Paxos

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Paxos
   BVNK✓fullprobed8/10

   BVNK hosts a live llms.txt file at docs.bvnk.com/llms.txt confirmed via HTTP 200 probe, containing structured summaries of its API documentation, and individual doc pages are also machine-readable markdown (.md) endpoints. Missing for 10: no independent third-party confirmation of agent usage/adoption of this llms.txt beyond the probe check.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “As a partner, you can add a markup fee to your customers' transactions, enabling you to collect additional revenue from your customers.”

   proof ↗⚑ flag

   Paxos✓fullprobed9/10

   Paxos hosts an llms.txt at docs.paxos.com/llms.txt, confirmed live by a direct probe returning HTTP 200 with structured documentation links, and the docs also advertise AI-assistance built into the documentation for contextual help. missing for 10: independent third-party confirmation of an agent successfully consuming the llms.txt beyond the first-party probe.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.paxos.com/llms.txt # Paxos Documentation - [Build with Paxos](https://docs.paxos.com/welcome.md): …”
   • [claimed-docs] “Sign Up for access to the Sandbox environment.”
   • [claimed-docs] “Get contextual help with Paxos APIs using AI assistance built into our documentation.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   BVNK~partialprobed6/10

   BVNK exposes a full REST API with Hawk authentication, webhooks for automated notifications, and a sandbox environment for simulating pay-ins/payouts—all of which support headless, non-interactive automation. There's also a mentioned agent-wallet-cli tool suggesting scriptable/CLI usage. However, there's no explicit documentation of CI pipeline integration, headless auth flows for automated agents, or CI-specific guidance. Missing for 10: explicit CI/automation guide, confirmation the CLI supports non-interactive auth/config for pipelines, and independent evidence of real-world CI usage.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   Paxos~partialclaimed6/10

   Paxos is API-first with client credentials, auth tokens, and a Sandbox environment explicitly designed for automated end-to-end integration testing (faucets, mock flows, transfers), which supports headless/CI-style automation. However, there is no explicit mention of CI/CD pipeline examples, SDKs, or automation tooling tailored for AI-native/headless workflows. Missing for 10: explicit CI/CD integration guides, official SDK/CLI support for headless automation, and independent confirmation of running in CI.

   • [claimed-docs] “API credentials using Client ID and Secret. Set allowed scopes to access specific API endpoints.”
   • [claimed-docs] “Generate an authentication token.”
   • [claimed-docs] “Source test crypto assets from faucets and deposit them into your Sandbox account for end-to-end integration testing.”
   • [claimed-docs] “Use the Sandbox environment to mock flows, execute transfers and test integrations.”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   BVNK—none0/10

   BVNK is a payments infrastructure product, and while an MCP server is a plausible axis for such an API platform, no evidence shows an official MCP server; only Hawk auth, webhooks, and REST APIs are documented, plus an unrelated CLI mention.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   Paxos—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to BVNK
   BVNK~partialprobed3/10

   A single probe result points to an 'agent-wallet-cli' GitHub repo described as an official CLI, but there is no documentation content, usage examples, or independent corroboration of its functionality. missing for 10: detailed CLI docs, command reference, install/usage examples, independent confirmation of adoption.

   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   Paxos—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   BVNK✓fullprobed8/10

   BVNK publishes a documented public API (Hawk auth, webhooks, wallets, transfers, payment rules) with a dedicated docs site and llms.txt endpoint confirming API-driven access, plus a sandbox for testing. missing for 10: independent third-party corroboration of API robustness/versioning and explicit rate-limit/SLA documentation.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   Paxos✓fullprobed8/10

   Paxos provides extensive documented public APIs covering authentication (Client ID/Secret, tokens), sandbox testing, identity onboarding, payments, conversions, crypto brokerage (REST v2.0, FIX, WebSocket), and webhooks — clearly enabling programmatic/agentic control of the platform. Missing for 10: a discoverable machine-readable OpenAPI/Swagger spec (probe found only 404s) and evidence of official SDKs, which would strengthen AI-native automation.

   • [claimed-docs] “API credentials using Client ID and Secret. Set allowed scopes to access specific API endpoints.”
   • [claimed-docs] “Generate an authentication token.”
   • [claimed-docs] “Source test crypto assets from faucets and deposit them into your Sandbox account for end-to-end integration testing.”
   • [claimed-docs] “Get market data, create orders, execute held-rate quotes, and transfer assets with Paxos API v2.0.”
   • [claimed-docs] “Leverage the Paxos FIX API to trade crypto.”
   • [claimed-docs] “Stream order book updates and executions in real time using the Smart Order Routing WebSocket API”
   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.paxos.com/llms.txt # Paxos Documentation - [Build with Paxos](https://docs.paxos.com/welcome.md): …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Paxos
   BVNK—none0/10

   BVNK's docs only mention Hawk-based API authentication (bvnk-docs-1) and webhooks, with no mention of scoped, least-privilege, or role-restricted API credentials or agent-specific key issuance. No evidence describes creating limited-permission API keys or tokens for AI agents.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   Paxos~partialclaimed5/10

   Paxos supports API credentials (Client ID/Secret) with configurable allowed scopes to restrict access to specific endpoints, which supports least-privilege credential issuance [paxos-docs-2]. However, there is no explicit documentation of an 'agent' use case, dynamic/programmatic credential issuance for AI agents, or fine-grained per-action scoping beyond endpoint-level access. Missing for 10: agent-specific credential provisioning workflow, evidence of granular per-resource scopes beyond endpoint-level, and independent/hands-on confirmation of scope enforcement.

   • [claimed-docs] “API credentials using Client ID and Secret. Set allowed scopes to access specific API endpoints.”
   • [claimed-docs] “Generate an authentication token.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   BVNK—none0/10

   Evidence shows extensive REST API documentation (auth, webhooks, sandbox, wallets, etc.) and one official CLI tool (agent-wallet-cli), but no evidence of official client SDKs (e.g., Python, JS, Java libraries) that developers could build against. The axis is fair for an API-driven fintech platform, but no SDK evidence is present, so this is 'none' rather than 'na'.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   Paxos—none0/10

   The evidence pack details Paxos's REST/FIX/WebSocket APIs, sandbox, webhooks, and docs, but never mentions official client SDKs or libraries in any language; the openapi.json probe also 404s, suggesting no even machine-readable spec is exposed for SDK generation.

   • [claimed-docs] “Get market data, create orders, execute held-rate quotes, and transfer assets with Paxos API v2.0.”
   • [claimed-docs] “Leverage the Paxos FIX API to trade crypto.”
   • [claimed-docs] “Stream order book updates and executions in real time using the Smart Order Routing WebSocket API”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   BVNK✓fullclaimed7/10

   BVNK documents webhook subscriptions for real-time account event notifications, with a dedicated setup guide for creating a webhook listener. Missing for 10: no details on event type filtering/selection, payload signing/verification specifics, or independent hands-on corroboration of webhook reliability.

   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”

   proof ↗⚑ flag

   Paxos✓fullclaimed7/10

   Paxos documents a dedicated Webhooks feature allowing registration of endpoints to receive asynchronous platform events, with configurable event types, auth, and RPS via the Dashboard. Missing for 10: independent/hands-on corroboration of webhook reliability, payload schema examples, and no OpenAPI spec confirming event types programmatically.

   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [claimed-docs] “Log in to your Dashboard account and navigate to the Webhooks section under the Developer tab. Configure your webhook with the relevant name…”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   BVNK—none0/10

   No evidence of AI-generated insights, analytics, or suggestions surfaced within BVNK's product based on user data; documentation covers payment infrastructure, wallets, APIs, and webhooks only.

   ⚑ flag

   Paxos—none0/10

   Paxos is a stablecoin/crypto infrastructure API platform; evidence only shows AI assistance for documentation help (paxos-docs-18), not AI-generated insights or suggestions derived from a user's own data within the product. No mention of analytics, dashboards, or AI-driven recommendations based on account/transaction data.

   • [claimed-docs] “Get contextual help with Paxos APIs using AI assistance built into our documentation.”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK exposes a rules-based automation API (e.g., POST /payment/v1/rules to auto-link fiat virtual accounts to crypto addresses) and webhooks for real-time automated notifications, plus automatic on-ramp/settlement flows, which together enable background, event-driven automations without manual triggering. However this is payment-domain automation (rules, webhooks) rather than a general agentic/background-task framework, and there's no documentation of scheduling, monitoring dashboards, or broader autonomous workflow orchestration beyond these payment rules. missing for 10: general-purpose scheduling/orchestration beyond payment rules, evidence of monitoring/alerting for autonomous runs, and independent confirmation of reliability of these automations running unattended.

   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”

   proof ↗⚑ flag

   Paxos—none0/10

   Paxos evidence covers APIs, webhooks, orchestrations (mint/redeem) and sandbox testing, but none of it describes a mechanism for setting up automations or agents that run autonomously in the background (e.g., scheduling, workflow triggers executed by Paxos itself, or an automation builder). Webhooks are reactive event notifications requiring external systems to act, not autonomous background execution.

   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [claimed-docs] “Log in to your Dashboard account and navigate to the Webhooks section under the Developer tab. Configure your webhook with the relevant name…”
   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Paxos
   BVNK—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Paxos~partialclaimed3/10

   Paxos docs mention only a documentation-embedded AI assistant for contextual API help (paxos-docs-18), not a built-in assistant capable of executing platform tasks like payments, conversions, or identity onboarding on the user's behalf. Missing for 10: evidence of an in-product AI agent that can perform actions (transfers, KYC, order execution) rather than just answer doc questions, and any first-party or independent confirmation of agentic task delegation.

   • [claimed-docs] “Get contextual help with Paxos APIs using AI assistance built into our documentation.”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   BVNK—none0/10

   No evidence BVNK offers a natural-language command interface; its API/CLI (bvnk-probe-2) and docs describe structured REST endpoints and a traditional CLI, not NL-driven interaction. Missing for 10: any chat/NL command interface, agent SDK, or documented natural-language operation mode.

   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   Paxos—none0/10

   Paxos is a financial/stablecoin API platform with developer docs, REST/FIX APIs, and an AI-assisted docs search helper, but there is no evidence of natural-language command operation of the product itself (e.g., no chat-driven transaction execution or NL-to-API interface). The 'AI assistance built into our documentation' (paxos-docs-18) is a doc-search helper, not a way to operate the product via NL commands.

   ⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   BVNK—none0/10

   BVNK's docs describe endpoints and a sandbox simulation environment, but there is no evidence of an interactive API reference (e.g., a Swagger/OpenAPI explorer or 'try it' console) with runnable code examples embedded in the docs.

   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   Paxos—none0/10

   The evidence pack shows Paxos has a Sandbox environment, docs with AI assistance, and various API guides, but nothing describing an interactive API reference (e.g., Swagger/OpenAPI explorer or 'try it' console) with runnable code examples; the probe for standard OpenAPI spec paths returned 404 across all checked locations, reinforcing the absence of such a feature.

   • [claimed-docs] “Use the Sandbox environment to mock flows, execute transfers and test integrations.”
   • [claimed-docs] “Get contextual help with Paxos APIs using AI assistance built into our documentation.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   BVNK—none0/10

   The evidence pack shows extensive API documentation (docs.bvnk.com, llms.txt) and endpoint references, but nowhere is an OpenAPI/Swagger spec or other machine-readable spec file mentioned or linked for download. missing for 10: explicit OpenAPI/Swagger JSON or YAML file, a documented spec download link, any mention of spec format.

   ⚑ flag

   Paxos—none0/10

   Direct probing of common OpenAPI/Swagger paths returned 404s, and the docs pack contains no link to a downloadable machine-readable spec despite extensive API documentation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Paxos
   BVNK✓fullclaimed7/10

   BVNK explicitly documents a sandbox environment that simulates pay-ins and payouts consistently across accounts, letting developers test without touching production data. Missing for 10: no explicit statement of how sandbox data/credentials are isolated from production, no independent/hands-on confirmation, and no detail on how to switch environments via API.

   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”

   proof ↗⚑ flag

   Paxos✓fullclaimed8/10

   Paxos provides a dedicated Sandbox environment with signup, credentials, test crypto asset faucets, and explicit guidance to mock flows, execute transfers, and test integrations without touching production data. missing for 10: independent/hands-on corroboration beyond vendor docs, and detail on data isolation guarantees between sandbox and production.

   • [claimed-docs] “Sign Up for access to the Sandbox environment.”
   • [claimed-docs] “Source test crypto assets from faucets and deposit them into your Sandbox account for end-to-end integration testing.”
   • [claimed-docs] “Use the Sandbox environment to mock flows, execute transfers and test integrations.”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to BVNK
   BVNK~partialclaimed3/10

   There is evidence of API versioning practice (Transfers v.3 replacing the legacy Quote API), showing BVNK does version and migrate APIs, but no documented deprecation policy, sunset timeline, or versioning scheme is provided. missing for 10: explicit deprecation policy documentation, versioning scheme details, sunset/EOL timelines, migration guarantees beyond one example.

   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”

   proof ↗⚑ flag

   Paxos—none0/10

   Evidence only shows a passing reference to 'Paxos API v2.0' (paxos-docs-19) with no changelog, versioning scheme, or deprecation/sunset policy documented anywhere in the pack; the OpenAPI/spec probes also returned 404s, suggesting no discoverable machine-readable API version metadata either.

   • [claimed-docs] “Get market data, create orders, execute held-rate quotes, and transfer assets with Paxos API v2.0.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   BVNK—none0/10

   No evidence of bulk/batch endpoints (e.g., batch payouts, bulk wallet creation, or bulk transfer APIs); documentation covers single-item operations (single wallet, single rule, single transfer) with no mention of batch processing or multi-item requests. missing for 10: bulk/batch API endpoints, batch job status tracking, documentation of multi-item request payloads.

   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”

   proof ↗⚑ flag

   Paxos—none0/10

   The evidence pack shows individual API operations (single mint/redeem, single identity creation, single transfers) but no batch or bulk endpoints for processing many items in one call. Bulk operations across many items are a fair ask for a financial API platform, but no documentation mentions batch processing, bulk uploads, or multi-item transactions.

   ⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK exposes a documented Rules API (POST /payment/v1/rules) that automatically links a fiat virtual account to a crypto address, and webhooks provide real-time event notifications that could trigger downstream automation. This shows genuine rule/event-driven automation, but only for a narrow, specific use case rather than a general-purpose rules engine covering arbitrary triggers/actions. Missing for 10: evidence of broader rule types (e.g., conditional logic across multiple event types), a general rules/automation dashboard, and third-party corroboration of rule reliability at scale.

   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”

   proof ↗⚑ flag

   Paxos~partialclaimed4/10

   Paxos offers webhooks that push asynchronous platform events to a user-defined endpoint (paxos-docs-16, paxos-docs-17), which lets a developer build custom automation externally, but there's no evidence of a built-in rules/automation engine where actions are defined and triggered directly within Paxos itself. Missing for 10: native rule-definition UI/API, conditional action triggers, and any AI-native automation tooling beyond raw webhook events.

   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [claimed-docs] “Log in to your Dashboard account and navigate to the Webhooks section under the Developer tab. Configure your webhook with the relevant name…”

   proof ↗⚑ flag

Kyc

1. ops leadCustomer and recipient onboarding is programmatic — documented KYC/KYB endpoints or flows that clear a counterparty for sending and receiving before money moves

   weight 2 · round to Paxos
   BVNK—none0/10

   Evidence pack covers wallets, payments, webhooks, embedded wallets, and API auth, but no documented KYC/KYB endpoints or onboarding/counterparty-clearance flows are mentioned anywhere in the docs list.

   ⚑ flag

   Paxos✓fullprobed7/10

   Paxos docs explicitly describe programmatic KYC/KYB flows: creating a person identity and handling onboarding decisions, creating an institution identity with required members and onboarding decisions, and collecting/transmitting beneficiary info for above-threshold transfers — directly matching counterparty clearance before money moves. missing for 10: X, Y — no visible OpenAPI/endpoint spec (openapi probe 404) and no independent/hands-on corroboration of these onboarding APIs.

   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Create an institution identity with required members and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Collect and transmit beneficiary information for above-threshold crypto transfers.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

Licensing

1. founderSee who I'm actually contracting with — the licensed or registered entities behind the product and the jurisdictions they cover, published rather than buried

   weight 2 · round drawn
   BVNK—none0/10

   The evidence pack contains only API/product documentation (webhooks, wallets, transfers, sandbox) and no published disclosure of the specific licensed or registered legal entities behind BVNK or the jurisdictions each covers. No regulatory/licensing page, entity list, or legal disclosures are cited anywhere in the evidence.

   ⚑ flag

   Paxos—none0/10

   The evidence pack is entirely API/developer documentation about sandbox, onboarding, payments, and webhooks; none of it addresses the legal/regulatory entities behind Paxos, their licensing status, or jurisdictional coverage. No trust/compliance/licensing page, entity disclosure, or regulatory registration info is cited anywhere.

   ⚑ flag

Screening

1. ops leadThe platform documents its sanctions screening, wallet risk checks, and travel-rule handling — compliance machinery named specifically, not waved at

   weight 2 · round to Paxos
   BVNK—none0/10

   None of the evidence names sanctions screening, wallet risk scoring/checks, or travel-rule handling—docs cover authentication, wallets, webhooks, transfers, and embedded partner features only. Absence of any specific compliance-machinery documentation means this axis is unmet.

   ⚑ flag

   Paxos~partialclaimed4/10

   Travel-rule handling is explicitly documented ('Collect and transmit beneficiary information for above-threshold crypto transfers') and identity onboarding decisions are named, but sanctions screening and wallet risk checks are never named as distinct compliance mechanisms — only vague 'onboarding decision' language. missing for 10: explicit sanctions screening documentation, explicit wallet/address risk-scoring documentation, and independent corroboration of these compliance mechanisms.

   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Create an institution identity with required members and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Collect and transmit beneficiary information for above-threshold crypto transfers.”

   proof ↗⚑ flag

Abstraction

1. developerI never operate blockchain infrastructure — the platform abstracts nodes, gas, and chain mechanics behind a conventional REST API with client libraries in my language

   weight 3 · round to Paxos
   BVNK~partialprobed5/10

   Docs show BVNK exposes a REST API for wallets, transfers, channels and payouts that hides on-chain mechanics (e.g., wallet, rule, and transfer endpoints), so nodes/gas are clearly abstracted. However, evidence only shows a Hawk-authenticated REST API and one CLI repo, not official client libraries/SDKs in multiple languages as the story specifies. Missing for 10: documented multi-language SDKs/client libraries, explicit statement that developers never touch node/gas mechanics.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   Paxos~partialprobed6/10

   Docs show Paxos exposes stablecoin mint/redeem, transfers, and conversions via REST-style orchestration endpoints with sandbox/auth, effectively hiding chain mechanics and gas from developers (paxos-docs-8, paxos-docs-9, paxos-docs-10, paxos-docs-22). However, there's no mention of official client libraries/SDKs in specific languages, and the probe found no discoverable OpenAPI spec, so the 'client libraries in my language' part of the story is unevidenced. missing for 10: language-specific SDKs/client libraries, published OpenAPI/swagger spec, independent confirmation of no direct chain exposure.

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Execute conversions between supported assets.”
   • [claimed-docs] “Use the Sandbox environment to mock flows, execute transfers and test integrations.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

Sandbox

1. developerRehearse everything without real funds — a documented sandbox or testnet mode covering payments, payouts, and conversions with test values that behave deterministically

   weight 3 · round to Paxos
   BVNK~partialclaimed5/10

   BVNK documents a dedicated sandbox ('payment-sim') that simulates pay-ins and payouts consistently across accounts, which covers part of the story, but there is no explicit documentation of sandbox coverage for currency conversions (Transfers v3) or of deterministic test values/testnet behavior for those flows. missing for 10: sandbox coverage for conversions/Transfers API, explicit deterministic test-value behavior, and independent developer confirmation of sandbox fidelity.

   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”

   proof ↗⚑ flag

   Paxos~partialclaimed6/10

   Docs confirm a dedicated Sandbox environment with test credentials, faucets for test crypto assets, and ability to 'mock flows, execute transfers and test integrations' (paxos-docs-1,4,22), which covers the general intent of rehearsing without real funds. However, there is no explicit documentation tying the sandbox to deterministic test values, nor confirmation that payouts/conversions (mint/redeem orchestrations) are specifically testable in sandbox mode rather than just payments. Missing for 10: explicit deterministic test-value behavior, sandbox coverage confirmation for conversions/payouts orchestrations, and independent/hands-on corroboration.

   • [claimed-docs] “Sign Up for access to the Sandbox environment.”
   • [claimed-docs] “Source test crypto assets from faucets and deposit them into your Sandbox account for end-to-end integration testing.”
   • [claimed-docs] “Use the Sandbox environment to mock flows, execute transfers and test integrations.”
   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”

   proof ↗⚑ flag

Webhooks

1. developerMoney movement emits signed webhooks — payment confirmed, payout settled, conversion executed — so my system tracks state without polling chains or dashboards

   weight 2 · round to Paxos
   BVNK~partialclaimed5/10

   Docs confirm BVNK webhooks deliver real-time, automated notifications for account changes (bvnk-docs-2), which supports event-driven state tracking without polling. However, the evidence never confirms webhook payloads are cryptographically signed/verifiable, nor does it enumerate specific event types like payment confirmed, payout settled, or conversion executed. Missing for 10: explicit signature/verification mechanism for webhooks, documented list of event types matching the story (payment/payout/conversion events), and any independent confirmation of reliability.

   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   Paxos~partialclaimed6/10

   Docs confirm Paxos Webhooks deliver asynchronous events for platform activity (configurable endpoint, event types, auth type of API Key or OAuth) which covers state tracking without polling, but there is no explicit mention of cryptographic signing/signature verification for webhook payloads, nor specific event-type names like 'payment confirmed' or 'payout settled'. Missing for 10: explicit payload-signing/signature-verification mechanism, and confirmation of exact event types matching payment/payout/conversion lifecycle.

   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [claimed-docs] “Log in to your Dashboard account and navigate to the Webhooks section under the Developer tab. Configure your webhook with the relevant name…”

   proof ↗⚑ flag

Conversion

1. developerConversion is a first-class API — quotes and executed conversions between fiat and stablecoins (and between stablecoins) with documented rates, fees, and settlement times

   weight 2 · round to Paxos
   BVNK~partialclaimed5/10

   BVNK exposes a dedicated Transfers v3 API for wallet-to-wallet currency conversion (replacing a legacy Quote API), plus fiat/stablecoin flows (fund in stablecoin, pay out in fiat) and partner markup-fee controls, indicating conversion is an API-first primitive. However, the pack lacks concrete documentation of quote request/response fields showing rates, fee breakdowns, or settlement-time SLAs for these conversions. missing for 10: explicit quote endpoint schema with rate/fee/settlement fields, independent confirmation of conversion accuracy or timing.

   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “As a partner, you can add a markup fee to your customers' transactions, enabling you to collect additional revenue from your customers.”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”

   proof ↗⚑ flag

   Paxos~partialclaimed6/10

   Paxos documents concrete conversion orchestrations (USD→stablecoin mint, stablecoin→USD redeem, and 'execute conversions between supported assets') plus held-rate quote execution in its crypto-brokerage API, showing conversion is a first-class, callable API surface. However, the evidence pack lacks explicit documentation of fee schedules or settlement-time SLAs tied to these conversion endpoints. missing for 10: documented fee tables/rate-spread disclosure, explicit settlement-time guarantees, and confirmation that quote/held-rate functionality extends to fiat↔stablecoin (not just crypto-brokerage trading pairs).

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Execute conversions between supported assets.”
   • [claimed-docs] “Get market data, create orders, execute held-rate quotes, and transfer assets with Paxos API v2.0.”

   proof ↗⚑ flag

Onramp

1. developerEmbed a fiat-to-stablecoin onramp — a documented widget or API where end users buy stablecoins with cards or bank transfers inside my product

   weight 2 · round drawn
   BVNK~partialclaimed5/10

   BVNK documents API-driven fiat-to-crypto conversion (linking fiat virtual accounts to blockchain addresses, automated on-ramp to crypto) and embedded wallets/virtual accounts that a developer could use to build an onramp flow, but there is no documented pre-built onramp widget, and no explicit mention of end users paying via card to buy stablecoins — the flow described is bank/virtual-account based automation rather than a card-based consumer buy widget. Missing for 10: a documented embeddable UI/widget component, explicit card-payment support for the onramp, and end-user-facing checkout flow evidence.

   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “Embedded Wallets provide partners with seamless payment and fund management capabilities directly within their platform while maintaining th…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”

   proof ↗⚑ flag

   Paxos~partialclaimed5/10

   Paxos provides APIs to convert USD to stablecoins and back (mint/redeem orchestrations) and identity onboarding flows, which are the backend building blocks for a fiat-to-stablecoin onramp, but the evidence describes a backend API/orchestration platform rather than a documented pre-built embeddable widget or turnkey onramp UI for end users to buy stablecoins via card/bank transfer. missing for 10: an explicit end-user-facing widget/UI component, card payment support (evidence only shows wire/CUBIX bank transfers, not card rails), and independent confirmation of a ready-to-embed onramp product.

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to BVNK
   BVNK~partialprobed7/10

   BVNK's docs show broad API coverage across core UI functions—wallet creation (fiat/crypto), transfers, payouts, rules, embedded wallets, webhooks—and explicitly note wallets can be managed 'through the Portal or API' (bvnk-docs-4), suggesting strong UI/API parity. However there is no explicit statement or independent audit confirming every UI feature (e.g., rewards, virtual cards, markup fee configuration) has a full API equivalent. Missing for 10: explicit parity documentation stating all UI actions are API-accessible, and independent/hands-on verification that no UI-only features exist.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Embedded Wallets provide partners with seamless payment and fund management capabilities directly within their platform while maintaining th…”
   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   Paxos~partialprobed6/10

   Paxos exposes a broad API surface (identity onboarding, transfers, conversions, payments, brokerage, webhooks) that mirrors most Dashboard functionality, suggesting strong API/UI parity for core workflows. However, evidence explicitly notes account/user management ('manage your platform and users') is documented as a Dashboard-only guide, webhook configuration is described as done via Dashboard login rather than API, and no OpenAPI spec was discoverable to verify full API coverage. missing for 10: confirmed API equivalents for Dashboard-only admin/user-management tasks, API-based webhook configuration, discoverable OpenAPI/swagger spec proving full endpoint parity, independent verification beyond vendor docs.

   • [claimed-docs] “Log in to your Dashboard account and navigate to the Webhooks section under the Developer tab. Configure your webhook with the relevant name…”
   • [claimed-docs] “Learn how to use the Paxos Dashboard to manage your platform and users.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”
   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Create an institution identity with required members and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”

   proof ↗⚑ flag

Batch

1. ops leadRun mass disbursements — batch or bulk payout APIs that push many stablecoin or fiat payouts in one documented operation with per-item status

   weight 2 · round drawn
   BVNK—none0/10

   Evidence shows individual payout, wallet, and transfer APIs (e.g., bvnk-docs-11, bvnk-docs-13, bvnk-docs-6) but nothing documenting a batch/bulk payout endpoint, mass-disbursement operation, or per-item status reporting for multiple payouts in one call. This is a fair axis for a payments platform, so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   Paxos—none0/10

   Evidence shows single-operation APIs (mint, redeem, convert, transfer) and payment acceptance flows, but nothing describing a batch/bulk payout endpoint that processes many payouts in one call with per-item status reporting. missing for 10: batch/bulk disbursement endpoint docs, per-item status/response schema, evidence of multi-recipient payout support.

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Execute conversions between supported assets.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”

   proof ↗⚑ flag

Offramp

1. ops leadRecipients can land in local fiat — documented off-ramp rails that convert stablecoins into bank transfers across a published set of currencies and countries

   weight 2 · round to BVNK
   BVNK~partialclaimed6/10

   BVNK docs describe fiat payout rails (payout-overview, virtual accounts in USD/EUR/GBP, stablecoin-to-fiat settlement flows) confirming that off-ramp to local bank accounts is supported, but there is no single published table enumerating all supported countries or the full currency corridor list beyond USD/EUR/GBP mentions. missing for 10: a published country/currency coverage matrix, confirmation of local payout rails outside USD/EUR/GBP, and independent verification of settlement speed/coverage claims.

   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   Paxos~partialclaimed5/10

   Paxos documents converting stablecoins to USD and settling directly to a bank account (redeem, settle-to-bank, auto-convert-to-fiat), which covers the core off-ramp-to-bank-transfer mechanic, but all evidence is USD/wire-transfer specific with no published list of supported fiat currencies or countries for payouts. missing for 10: published multi-currency/country coverage list, evidence of non-USD bank rails, independent confirmation of international payout reach.

   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Automatically convert the stablecoin to fiat, or opt to hold balances in stablecoin.”
   • [claimed-docs] “Settle USD directly to your bank account.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”

   proof ↗⚑ flag

Payouts

1. developerSend stablecoin payouts programmatically — pay a wallet address or stored recipient through the API with documented status tracking to final settlement

   weight 3 · round drawn
   BVNK~partialclaimed6/10

   BVNK's docs confirm programmatic stablecoin sending via API (bvnk-docs-13, bvnk-docs-14, bvnk-docs-18), wallet creation/management via API (bvnk-docs-4), and webhook-based notifications for account changes (bvnk-docs-2), plus a sandbox simulation for payouts (bvnk-docs-3). However, there is no explicit documentation of a 'stored recipient' object, dedicated payout endpoint with status-lifecycle documentation (e.g., pending→settled states), or confirmation that webhooks specifically track payout-to-settlement status. missing for 10: dedicated payout API/status-tracking docs, stored-recipient object documentation, explicit settlement-state webhook events.

   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”

   proof ↗⚑ flag

   Paxos~partialprobed6/10

   Paxos docs show programmatic stablecoin transfer/conversion orchestrations (mint/redeem, asset transfers), beneficiary/recipient handling for crypto transfers, and webhooks for asynchronous event tracking that could support payout status monitoring. However, there is no explicit documentation of a dedicated 'pay to wallet address or stored recipient' payout endpoint with full status-to-settlement tracking, and the OpenAPI spec probe failed (404), limiting confirmation of endpoint-level detail. Missing for 10: explicit payout-to-wallet/stored-recipient API reference, confirmed OpenAPI schema, and independent/hands-on verification of settlement status tracking.

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Execute conversions between supported assets.”
   • [claimed-docs] “Collect and transmit beneficiary information for above-threshold crypto transfers.”
   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [claimed-docs] “Get market data, create orders, execute held-rate quotes, and transfer assets with Paxos API v2.0.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   BVNK—none0/10

   No evidence describes data residency/region selection controls in BVNK's docs or product pages; the evidence pack covers payments, wallets, and API features only. This axis applies to a payments/fintech platform handling customer data, so absence of evidence yields none.

   ⚑ flag

   Paxos—none0/10

   No evidence in the pack addresses data residency, regional storage options, or geographic data controls for Paxos; the docs focus on API onboarding, payments, and trading flows only.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   BVNK—none0/10

   BVNK's evidence pack covers payments, wallets, webhooks, and API auth, but contains no mention of data retention policies, deletion controls, or privacy/data lifecycle management features for AI-native users. This is a fintech payments platform where such controls could plausibly exist (e.g., in compliance/data policies), but no documentation surfaces them.

   ⚑ flag

   Paxos—none0/10

   Paxos is a financial/stablecoin platform whose documentation covers identity onboarding, payments, brokerage, and webhooks, but there is no mention of data retention policies, user-controlled deletion, or export/erasure mechanisms for an AI-native user.

   ⚑ flag

Settlement

1. finance leadSettlement is legible — documented timing from payment to available balance, published fees per rail, and statements or reports my accounting can consume

   weight 2 · round drawn
   BVNK—none0/10

   No evidence pack items document settlement timing SLAs (payment to available balance), a published fee schedule per rail, or exportable statements/reports for accounting reconciliation; evidence only covers API mechanics like wallets, webhooks, transfers, and embedded partner features.

   ⚑ flag

   Paxos—none0/10

   Docs describe settlement mechanics (mint/redeem orchestrations, wire transfer/CUBIX, direct bank settlement) but nowhere document payment-to-available-balance timing, publish a fee schedule per rail, or provide statements/reports formatted for accounting consumption.

   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”
   • [claimed-docs] “Settle USD directly to your bank account.”

   proof ↗⚑ flag

Treasury

1. finance leadMove value between fiat and stablecoin balances on the platform — internal transfers and rebalancing through the API or dashboard, documented end to end

   weight 2 · round to BVNK
   BVNK✓fullclaimed8/10

   BVNK documents crypto/fiat wallet creation, the Transfers v3 API for wallet-to-wallet currency conversion, fiat-to-crypto automation rules, on/off-ramp flows, and messaging like 'use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat' — covering both API and dashboard rebalancing between fiat and stablecoin balances end to end. Missing for 10: an explicit worked example/tutorial showing a full internal transfer+rebalance flow with request/response payloads, and independent (non-vendor) confirmation of dashboard UX.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “The Transfers v.3 API replaces the legacy Quote API for wallet-to-wallet currency conversion.”
   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Automatically on-ramp to crypto and send to blockchain addresses.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   Paxos✓fullclaimed7/10

   Paxos docs describe end-to-end orchestrations for converting USD↔stablecoins in one API call (mint/redeem), moving USD on/off platform via wire/CUBIX, and general conversions between supported assets, plus a Dashboard for platform management, giving a finance lead both API and dashboard paths for treasury operations. Missing for 10: explicit dashboard UI screenshots/steps for initiating a fiat/stablecoin transfer or rebalancing (dashboard docs are generic), and independent/hands-on corroboration beyond first-party docs.

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Execute conversions between supported assets.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”
   • [claimed-docs] “Learn how to use the Paxos Dashboard to manage your platform and users.”
   • [claimed-docs] “Use the Sandbox environment to mock flows, execute transfers and test integrations.”

   proof ↗⚑ flag

Acceptance

1. developerAccept a stablecoin payment from a customer through a documented checkout or payment API — create the payment, present the address or flow, and confirm settlement programmatically

   weight 3 · round to BVNK
   BVNK✓fullclaimed8/10

   BVNK's docs describe creating payment channels (unique repeated-use blockchain addresses) to accept stablecoin payments, converting to fiat, plus webhook notifications for settlement confirmation and a sandbox for testing pay-ins programmatically. This covers create → present address → confirm settlement end-to-end via documented API, though evidence is docs-only without independent hands-on confirmation. Missing for 10: independent/hands-on verification of the checkout flow working in practice, and more detail on the specific 'create payment' endpoint/response schema.

   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “The sandbox environment provides a consistent simulation experience for pay-ins and payouts across all customer accounts.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”

   proof ↗⚑ flag

   Paxos✓fullprobed7/10

   Paxos has a dedicated Payments API documented to accept PYUSD/USDC/USDP on-chain transfers, auto-convert to fiat or hold in stablecoin, settle to bank, issue refunds, and receive async settlement confirmation via webhooks — covering create/present/confirm end-to-end. Missing for 10: no independent hands-on developer integration report, no OpenAPI spec exposed (404s), and no explicit example of presenting a checkout address/UI flow to an end customer.

   • [claimed-docs] “Accept PYUSD, USDC and USDP payments via on-chain transfers.”
   • [claimed-docs] “Automatically convert the stablecoin to fiat, or opt to hold balances in stablecoin.”
   • [claimed-docs] “Settle USD directly to your bank account.”
   • [claimed-docs] “Issue refunds to the original Buyer via stablecoin on-chain transfers.”
   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”
   • [claimed-docs] “Log in to your Dashboard account and navigate to the Webhooks section under the Developer tab. Configure your webhook with the relevant name…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.paxos.com/openapi.json, https://docs.paxos.com/swagger.json, https://docs.paxos.com/api…”

   proof ↗⚑ flag

Chains

1. developerThe platform documents which stablecoins and chains it supports — USDC, USDT and peers across multiple named networks — so I can match what my customers actually hold

   weight 2 · round to Paxos
   BVNK—none0/10

   The evidence pack shows BVNK supports generic 'stablecoins' and 'crypto' wallets, but nowhere does it name specific stablecoins (USDC, USDT, etc.) or specific blockchain networks/chains supported. missing for 10: named stablecoin list (USDC, USDT, etc.), named supported chains/networks, any coin-to-chain compatibility matrix.

   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   Paxos~partialclaimed5/10

   Docs explicitly list supported stablecoins for payments (PYUSD, USDC, USDP) and mention conversions between 'supported assets,' showing some named-coin documentation, but USDT is not mentioned anywhere, and no specific blockchain networks (e.g., Ethereum, Solana) are named in the evidence pack. missing for 10: USDT support, explicit multi-chain network list, and a consolidated supported-assets/chains reference page.

   • [claimed-docs] “Accept PYUSD, USDC and USDP payments via on-chain transfers.”
   • [claimed-docs] “Execute conversions between supported assets.”
   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”

   proof ↗⚑ flag

Fiat settlement

1. finance leadTake crypto payments but settle in fiat — a documented option to auto-convert stablecoin receipts into a fiat balance or bank payout so my books never hold crypto

   weight 3 · round to BVNK
   BVNK✓fullclaimed9/10

   BVNK explicitly documents accepting stablecoin payments and receiving fiat currency in the account (bvnk-docs-9), with marketing and docs confirming 'Accept payments globally in stablecoins. Settle in fiat' and 'fund in stablecoins and pay out in fiat' (bvnk-docs-18, bvnk-docs-19), plus payout mechanisms to bank accounts (bvnk-docs-11) and fiat virtual accounts in major currencies (bvnk-docs-12). missing for 10: independent/hands-on confirmation of the auto-conversion accounting flow beyond vendor docs.

   • [claimed-docs] “Crypto converted and received in fiat: Accept stablecoin payments from customers and receive fiat currency in your account”
   • [claimed-docs] “Use your fiat balance to send stablecoins, or fund in stablecoins and pay out in fiat.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”
   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”

   proof ↗⚑ flag

   Paxos✓fullclaimed8/10

   Docs explicitly describe accepting PYUSD/USDC/USDP payments with an option to automatically convert stablecoin to fiat or settle USD directly to a bank account, matching the finance-lead's no-crypto-on-books requirement, plus a redeem orchestration to convert stablecoins to USD and withdraw to bank in one call. Missing for 10: independent/hands-on confirmation of the auto-convert toggle in production and clearer accounting/reporting detail on how converted balances appear in books.

   • [claimed-docs] “Accept PYUSD, USDC and USDP payments via on-chain transfers.”
   • [claimed-docs] “Automatically convert the stablecoin to fiat, or opt to hold balances in stablecoin.”
   • [claimed-docs] “Settle USD directly to your bank account.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”

   proof ↗⚑ flag

Agent payments

1. ai-native userAn agent can move stablecoins under scoped authority — documented agent payment flows where an agent initiates a payment or payout with spend controls a human configured

   weight 3 · round drawn
   BVNK—none0/10

   Evidence shows general wallet/payment/API capabilities (wallets, rules automation, transfers) but nothing describing an 'agent' actor, scoped spend authority, or human-configured spend limits governing agent-initiated payments. The lone 'agent-wallet-cli' repo mention has no accompanying documentation of spend controls or agent payment flows, so this doesn't establish the capability.

   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”
   • [claimed-docs] “To create a rule that links a fiat virtual account to a crypto blockchain address, send the `POST /payment/v1/rules` request”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”

   proof ↗⚑ flag

   Paxos—none0/10

   Evidence shows generic API credentialing with scopes (paxos-docs-2) and various payment/transfer/orchestration endpoints, but nothing documents an agent-specific payment flow, delegated spend limits, or scoped authority configured by a human for an autonomous agent to initiate stablecoin payments. Missing for 10: any mention of AI agents, agent-specific spend controls, or delegated payment authority workflows.

   • [claimed-docs] “API credentials using Client ID and Secret. Set allowed scopes to access specific API endpoints.”
   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”

   proof ↗⚑ flag

Agent wallets

1. ai-native userAgents can hold and use wallets safely — programmatic wallet issuance for agents with scoped keys, policy controls, and documented limits on what an agent can move

   weight 2 · round to BVNK
   BVNK~partialprobed3/10

   BVNK documents general programmatic wallet creation (crypto/fiat) via API/Portal and Hawk-based API authentication, and a probe references an 'agent-wallet-cli' repo, suggesting some agent-oriented wallet tooling exists. However there is no documentation of scoped API keys per agent, policy/permission controls, or explicit spending/movement limits tailored to autonomous agents. Missing for 10: scoped-key issuance mechanics, policy engine/spend-limit configuration, and agent-specific governance documentation.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [probe] “official CLI documented at https://github.com/bvnk/agent-wallet-cli”

   proof ↗⚑ flag

   Paxos—none0/10

   Paxos docs show API credentials with configurable scopes (paxos-docs-2), sandbox testing, and identity onboarding, but there is no evidence of agent-specific wallet issuance, scoped keys tied to autonomous agents, or documented spending/policy limits governing what an agent can move.

   • [claimed-docs] “API credentials using Client ID and Secret. Set allowed scopes to access specific API endpoints.”
   • [claimed-docs] “Generate an authentication token.”
   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”

   proof ↗⚑ flag

Protocols

1. ai-native userThe platform speaks the machine-payment protocols by name — x402, ACP, MPP, or AP2 support documented with endpoints or SDKs, not just a blog aspiration

   weight 2 · round drawn
   BVNK—none0/10

   No evidence of x402, ACP, MPP, or AP2 protocol support anywhere in the docs pack; BVNK documents Hawk auth, webhooks, wallets, and fiat/crypto conversion APIs but never mentions these machine-payment protocols by name or provides endpoints/SDKs for them.

   • [claimed-docs] “BVNK uses **Hawk authentication** for secure API access.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.bvnk.com/llms.txt # BVNK API Documentation > Complete API documentation for BVNK payment infrastru…”

   proof ↗⚑ flag

   Paxos—none0/10

   No evidence names or documents x402, ACP, MPP, or AP2 protocols; Paxos documentation covers stablecoin issuance, payments, brokerage, and webhooks but never references these specific machine-payment protocols by name with endpoints or SDKs.

   ⚑ flag

Issuance

1. founderIssue a branded stablecoin on the platform's infrastructure — a documented issuance product covering minting, redemption, and reserve management, with its gating quoted honestly

   weight 2 · round drawn
   BVNK—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Paxos—none0/10

   The evidence pack shows Paxos APIs for minting/redeeming existing stablecoins (mint.md, redeem.md) and payment flows, but nothing documenting a distinct 'issue your own branded stablecoin' program, its reserve-management practices, or the eligibility/gating requirements (e.g., minimum volume, regulatory vetting) stated honestly. Missing for 10: dedicated issuance-product docs, reserve/attestation disclosure, and explicit gating/eligibility criteria for founders wanting a new branded coin.

   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”

   proof ↗⚑ flag

Yield

1. finance leadThe economics of held stablecoins are documented — reserve composition, attestations, and any yield or rewards program with its eligibility and regulatory caveats stated plainly

   weight 2 · round to BVNK
   BVNK~partialclaimed2/10

   Marketing copy mentions a rewards program ('Put idle balances to work with built-in rewards') implying some yield mechanism, but there is no documentation of reserve composition, attestation reports, eligibility criteria, or regulatory caveats for held stablecoins. Missing for 10: reserve composition disclosure, third-party attestation reports, yield program eligibility rules, regulatory/risk caveats for the rewards program.

   • [claimed-docs] “Put idle balances to work with built-in rewards.”

   proof ↗⚑ flag

   Paxos—none0/10

   The evidence pack covers API/developer documentation for minting, redeeming, payments, and sandbox testing, but contains no mention of reserve composition, attestation reports, or any yield/rewards program with eligibility or regulatory caveats for held stablecoins.

   ⚑ flag

Balances

1. finance leadMy business can hold a stablecoin balance on the platform — documented custodial accounts with stated availability, geographies, and any gating quoted honestly

   weight 3 · round drawn
   BVNK~partialclaimed5/10

   BVNK docs and marketing confirm you can create and hold crypto/stablecoin wallets/balances (bvnk-docs-4, bvnk-docs-15, bvnk-docs-13, bvnk-docs-17, bvnk-docs-19), but there is no documentation on custodial account structure, licensing, geographic availability, or any gating/eligibility disclosures for holding stablecoin balances. missing for 10: explicit custodial/regulatory documentation, stated geographic availability, and honest disclosure of any gating or KYC/jurisdiction restrictions for balance holding.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “Send stablecoins or cryptocurrencies from your BVNK account.”
   • [claimed-docs] “Spin up stablecoin and fiat wallets for your customers.”
   • [claimed-docs] “Put idle balances to work with built-in rewards.”
   • [claimed-docs] “Accept payments globally in stablecoins. Settle in fiat.”

   proof ↗⚑ flag

   Paxos~partialclaimed5/10

   Docs describe custodial-style flows (person/institution identity onboarding, USD-to-stablecoin conversion, holding balances, wire/CUBIX movement) implying an account structure for holding stablecoin balances, but nowhere do they state specific geographies served, eligibility/gating criteria, or availability constraints as the story requires. Missing for 10: explicit geographic availability list, stated eligibility/gating (e.g., institutional-only, jurisdictional restrictions), and independent confirmation of custodial account terms.

   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Create an institution identity with required members and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Convert USD to Stablecoins and transfer all in one call.”
   • [claimed-docs] “Convert stablecoins to USD and withdraw to your bank in one call.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”
   • [claimed-docs] “Automatically convert the stablecoin to fiat, or opt to hold balances in stablecoin.”

   proof ↗⚑ flag

Virtual accounts

1. developerIncoming funds are attributable — named virtual accounts or dedicated deposit addresses per customer so reconciliation knows who paid without manual matching

   weight 2 · round to BVNK
   BVNK✓fullclaimed7/10

   BVNK docs show both named virtual accounts (USD/EUR/GBP) for businesses/customers and 'channels' — unique, repeated-use blockchain deposit addresses that never change per customer — plus webhooks for real-time notification of incoming funds, directly enabling attribution without manual matching. missing for 10: explicit documentation tying a specific virtual account/address to a customer ID in transaction payloads, and independent/hands-on confirmation of reconciliation workflow.

   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Webhooks provide real-time, automated notifications for changes in your BVNK account.”
   • [claimed-docs] “This process allows for the ability for the `CUSTOMER ENABLED` wallet to complete payouts to other bank accounts using their virtual account…”

   proof ↗⚑ flag

   Paxos—none0/10

   Paxos docs describe payment acceptance (PYUSD/USDC/USDP on-chain transfers), auto-conversion to fiat, and webhooks for event notifications, but nowhere mention per-customer virtual accounts or dedicated deposit addresses for automatic reconciliation of incoming funds. missing for 10: any documentation of per-customer/dedicated deposit addresses or virtual account assignment, reconciliation tooling tying incoming transfers to specific customers.

   • [claimed-docs] “Accept PYUSD, USDC and USDP payments via on-chain transfers.”
   • [claimed-docs] “Automatically convert the stablecoin to fiat, or opt to hold balances in stablecoin.”
   • [claimed-docs] “Issue refunds to the original Buyer via stablecoin on-chain transfers.”
   • [claimed-docs] “Paxos Webhooks allow you to register your own endpoints to receive asynchronous events driven by the Paxos Platform.”

   proof ↗⚑ flag

Wallets

1. developerCreate wallets programmatically — per-customer or per-purpose wallets and deposit addresses provisioned through the API with documented key custody semantics

   weight 2 · round to BVNK
   BVNK~partialclaimed6/10

   Docs confirm crypto/fiat wallet and virtual-account creation via API or Portal (bvnk-docs-4, bvnk-docs-12), per-customer wallet provisioning (bvnk-docs-15), and reusable deposit addresses/'channels' for receiving crypto (bvnk-docs-10), which together demonstrate programmatic wallet/address provisioning. However there is no documentation of key custody semantics (custodial model, key management, signing responsibility) anywhere in the pack. Missing for 10: explicit key custody/ownership documentation, independent confirmation of API wallet creation workflow beyond docs snippets.

   • [claimed-docs] “On BVNK, you can create and manage both crypto and fiat wallets through the Portal or API.”
   • [claimed-docs] “A channel is a unique, repeated-use blockchain address that can receive crypto or stablecoins at any time. The address never changes.”
   • [claimed-docs] “Create virtual accounts in USD, EUR, GBP for your business or customers.”
   • [claimed-docs] “Spin up stablecoin and fiat wallets for your customers.”

   proof ↗⚑ flag

   Paxos—none0/10

   The evidence pack covers identity onboarding, fiat/crypto conversions, payments, webhooks, and brokerage trading, but contains no mention of programmatic wallet creation, per-customer deposit address provisioning, or documented custody/key-management semantics. Missing for 10: wallet/deposit-address creation API docs, custody model documentation, evidence of per-customer wallet provisioning.

   • [claimed-docs] “Create a person identity and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Create an institution identity with required members and handle the onboarding decision on the Paxos Platform.”
   • [claimed-docs] “Move USD on and off the Paxos Platform via wire transfer or CUBIX.”

   proof ↗⚑ flag