Crossmint vs Skyfire

Cart

1. ai-native userMy agent can create and update a cart or order draft through a documented protocol call

   weight 3 · round to Crossmint
   Crossmint✓fullprobed8/10

   Crossmint's Agent Checkouts API is a documented protocol call that lets an agent submit a product URL and spending cap to create an order/checkout, and runtime probing confirms the endpoint is live and agent-scoped (requiring ServerKeyAgent auth). The lifecycle supports polling for status updates, which functions as order-draft state updates, and agent cards similarly document order-intent creation/tracking (total, reserved, spent, available). missing for 10: no explicit 'update cart' verb or partial-order-edit API, no OpenAPI/schema confirmation (openapi.json probes 404), and no independent third-party corroboration beyond first-party docs and the vendor's own runtime probe.

   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”

   proof ↗⚑ flag

   Skyfire—none0/10

   Skyfire's documented protocol (tokens, kya/pay/kya-pay, MCP tools like find-sellers/create-*-token) covers identity verification and payment authorization/settlement, but there is no documented call for creating or updating a cart or order draft — order/cart state is left to the seller's own system, not exposed via Skyfire's API or MCP server.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”

   proof ↗⚑ flag

Checkout

1. ai-native userMy agent can complete a purchase end-to-end — checkout session, delegated payment credential, confirmed order

   weight 3 · round drawn
   Crossmint✓fullprobed8/10

   Crossmint's Agent Checkouts API lets an agent be handed a product URL and spending cap and complete checkout on the user's behalf, with delegated payment credentials (agent cards/order intents or delegated wallet signer permissions) and a poll-driven order lifecycle to confirm terminal state; runtime probe confirms the endpoint is live and enforces agent-scoped auth. missing for 10: independent/third-party confirmation of a fully completed order in production (docs note no staging/test environment and no webhooks in v1, so end-to-end success is self-reported), and no public case study of a real merchant purchase completing.

   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

   Skyfire documents the full agent-checkout loop: MCP tools let an agent discover sellers, create kya/pay/kya-pay tokens (delegated payment+identity credential), and sellers charge the token post-delivery with funds moved between wallets, completing a confirmed order/settlement. missing for 10: independent/hands-on end-to-end transaction proof (evidence is vendor docs plus a narrow auth-only runtime probe, not a full live purchase trace) and no example of an explicit 'confirmed order' object/receipt returned to the buyer.

   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Sellers can use a `kya-pay` token to enable a guest checkout experience for buyer agents.”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”

   proof ↗⚑ flag

Embedded surfaces

1. merchantBuyers can complete purchases of my products inside chat and assistant surfaces (ChatGPT, Claude, Gemini, Copilot and peers)

   weight 2 · round to Crossmint
   Crossmint~partialclaimed3/10

   Crossmint documents generic agent-payment infrastructure (Agent Cards, Agent Wallets, Agent Checkouts) that lets any AI agent buy from merchants via API, which could theoretically be wired into chat surfaces, but there is no evidence of concrete integration or partnership with ChatGPT, Claude, Gemini, Copilot or similar assistant surfaces. Missing for 10: named integrations/plugins with specific chat/assistant platforms, evidence of buyers actually completing purchases inside those surfaces, and any merchant-facing onboarding flow tied to those platforms.

   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Skyfire's evidence documents a generic agent-to-agent payment/identity protocol (tokens, MCP server for 'find-sellers' and token creation) but nowhere mentions ChatGPT, Claude, Gemini, Copilot or any named chat/assistant surface, nor any commerce-in-chat integration or app-store listing. The MCP server is a generic protocol endpoint, not documented evidence of embedding within these specific consumer assistant surfaces.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”

   proof ↗⚑ flag

Protocol conformance

1. developerBuild against a versioned commerce protocol with a published schema and conformance or validation tooling

   weight 2 · round to Skyfire
   Crossmint—none0/10

   Crossmint documents payment flows (x402, MPP, agent checkouts) but there is no evidence of a versioned commerce protocol with a published schema or conformance/validation tooling — probes for OpenAPI/swagger specs all 404'd, and the live agent-checkouts endpoint is explicitly path-versioned as '/api/unstable/', signaling the opposite of a stable published protocol.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire~partialprobed4/10

   Skyfire points to an external 'open' KYAPay protocol (KYAPay.org) with JWT-based tokens that all Skyfire tokens conform to, giving a nominal published spec, but the evidence pack shows no OpenAPI/schema file for Skyfire's own API (all standard OpenAPI paths 404) and no conformance/validation tooling (test suites, schema validators, certification) is documented anywhere. Missing for 10: a published machine-readable schema for the Skyfire API itself, explicit protocol versioning, and any conformance/validation tooling a developer could run against.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”

   proof ↗⚑ flag

Agent search

1. ai-native userMy agent can programmatically search products or services across merchants — keylessly or with self-service credentials, no private partnership required

   weight 3 · round to Skyfire
   Crossmint—none0/10

   Crossmint's agent products (Agent Cards, Agent Wallets, Agent Checkouts) are all payment/execution infrastructure that require the agent to already have a specific product URL or merchant endpoint — 'hand it a product URL and a spending cap' — none of the evidence describes a search or product-discovery API across merchants. There is no documented catalog search, product query, or merchant-discovery endpoint; discovery is assumed to happen elsewhere before Crossmint is invoked.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”

   proof ↗⚑ flag

   Skyfire~partialprobed5/10

   Skyfire's MCP server exposes a 'find-sellers' tool for programmatic discovery, but access requires a self-service API key scoped to a registered agent (not fully keyless) and seller listings are approval-gated by Skyfire rather than an open, permissionless catalog; runtime probe confirms endpoints are key-gated. missing for 10: evidence of true keyless/anonymous discovery, breadth/independence of merchant catalog, and independent corroboration of discovery quality beyond Skyfire's own docs.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”

   proof ↗⚑ flag

Machine readable offers

1. developerRead machine-readable offer data — price, availability, variants, checkout links — for any listed product or service

   weight 2 · round to Skyfire
   Crossmint—none0/10

   Crossmint's docs describe agent checkout as handing it a merchant product URL and letting Crossmint execute the purchase, but nowhere is there evidence that Crossmint itself exposes machine-readable offer data (price, availability, variants, checkout links) for developers to read — it's a payment/checkout executor, not a product-data or listing API. Missing for 10: any API/schema returning structured product price/availability/variant data, any catalog or listing endpoint, any documentation of reading offer metadata rather than just completing a purchase given a URL.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”

   proof ↗⚑ flag

   Skyfire~partialprobed3/10

   Skyfire's MCP server exposes a 'find-sellers' tool for service discovery, and seller service creation includes a 'pricing' field (skyfire-docs-3, skyfire-docs-6, skyfire-supp-9), suggesting some machine-readable service metadata exists. However, there is no documented schema showing availability, variants, or checkout links returned to a developer/agent, and no OpenAPI spec was found (skyfire-probe-2) to confirm structured offer data beyond pricing and identity requirements. Missing for 10: documented availability/variant fields, explicit checkout-link data, and a public API schema showing full offer payloads.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”

   proof ↗⚑ flag

Service discovery

1. ai-native userMy agent can discover payable services and APIs through a published directory or discovery index

   weight 2 · round to Skyfire
   Crossmint—none0/10

   The evidence covers Crossmint's payment rails (cards, wallets, x402, MPP, checkouts) but nothing describes a published directory or discovery index of payable services/APIs that an agent could browse or query; llms.txt is a docs-crawling aid, not a service discovery index. This is a fair axis for an agent-payments platform, but no capability is evidenced.

   ⚑ flag

   Skyfire~partialclaimed6/10

   Skyfire's MCP server exposes a 'find-sellers' tool that lets an agent query for payable services/sellers programmatically, and sellers register services through an approval-gated catalog, giving agents a discovery mechanism (skyfire-docs-6, skyfire-supp-9, skyfire-docs-3). However, there's no evidence of a publicly browsable directory/index outside the MCP tool call, nor documentation of how the directory is structured, filtered, or how comprehensive/curated it is. Missing for 10: a documented public directory/catalog UI or API endpoint separate from the MCP tool, details on search/filter capabilities, and independent confirmation of discovery breadth.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Crossmint
   Crossmint✓fullprobed9/10

   Crossmint serves a live llms.txt (confirmed by direct probe returning HTTP 200 with agent-oriented content) and every docs page is also available as markdown via the same URL + .md suffix, directly matching the story of pointing an agent at llms.txt or agent-oriented docs. Missing for 10: no independent third-party report of an agent successfully consuming these docs end-to-end, and no OpenAPI spec (all candidates 404) to complement the llms.txt for structured agent consumption.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”
   • [probe] “PROBE runtime (recorded 2026-09-14): docs.crossmint.com serves llms.txt keylessly — '# Crossmint... checkout for onchain and physical-world …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

   Skyfire's docs site serves a working llms.txt (HTTP 200, agent-oriented summary) confirmed by both a probe and a runtime check, and its full docs are structured as agent-consumable markdown (.md endpoints throughout). This directly satisfies pointing an agent at llms.txt/agent-oriented docs. Missing for 10: no independent third-party report of an agent successfully consuming llms.txt end-to-end, and no OpenAPI spec (all candidate paths 404) which would further strengthen machine-readability.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.skyfire.xyz/llms.txt # Skyfire Developer Portal Documentation > Skyfire is the open identity and p…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Crossmint~partialprobed6/10

   Crossmint's core products are REST/headless APIs (explicit 'headless checkout API', agent checkouts API, wallet API) designed for programmatic, UI-less automation, and probes confirm keyless API-key-based auth suitable for scripted/CI calls. However there is no explicit documentation of CI pipeline usage, SDK examples for automated test suites, or non-interactive auth setup, and agent-checkouts testing is noted as production-only with no staging environment, complicating CI use. Missing for 10: documented CI/automation examples, staging/sandbox support for safe automated testing, and explicit non-interactive credential provisioning guidance.

   • [claimed-docs] “Crossmint's headless checkout API is a set of REST APIs that allow you to integrate credit card and cross-chain crypto payments inside your …”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”

   proof ↗⚑ flag

   Skyfire~partialprobed6/10

   Skyfire is API-first: agents authenticate via scoped API keys (no interactive login) and all core operations (token creation, introspection, charging) are REST endpoints, confirmed live and key-gated by a runtime probe, plus an MCP server for programmatic agent workflows. However, there's no explicit CI/CD example, headless setup guide, or CLI/SDK documentation showing automation-pipeline usage. missing for 10: explicit CI/headless usage guide, CLI or SDK tooling, and independent confirmation of non-interactive automation beyond API-key auth.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Crossmint✓fullprobed8/10

   Crossmint exposes a documented REST API surface (wallets, agent cards, agent checkouts, payment flows) with quickstarts and runtime probes confirming the endpoints are live and API-key/agent-key authenticated, and llms.txt/markdown docs are served for machine consumption. The main gap is the absence of a discoverable formal OpenAPI/Swagger spec (probe-2 shows all standard OpenAPI paths 404), so full machine-readable API introspection isn't confirmed. Missing for 10: a published OpenAPI/Swagger schema, independent third-party confirmation of API robustness beyond Crossmint's own docs.

   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [probe] “PROBE runtime (recorded 2026-09-14): docs.crossmint.com serves llms.txt keylessly — '# Crossmint... checkout for onchain and physical-world …”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”

   proof ↗⚑ flag

   Skyfire✓fullprobed8/10

   Skyfire ships a documented public REST API (tokens, introspect, charge-token) gated by per-agent API keys, confirmed live via runtime probe returning a structured auth error rather than a 404, plus llms.txt-served docs. Missing for 10: a published OpenAPI/swagger spec (probe found all candidate spec URLs 404) and independent third-party corroboration beyond vendor docs/probes.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.skyfire.xyz/llms.txt # Skyfire Developer Portal Documentation > Skyfire is the open identity and p…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”

   proof ↗⚑ flag

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

   weight 2 · round to Crossmint
   Crossmint✓fullprobed7/10

   Crossmint documents explicit least-privilege delegation for agents: user-owned wallets grant an agent a bound signer key with a spend cap, allowed counterparties, and a time window, all enforced onchain and revocable at any time; agent cards similarly use order-intent 'fixed allowance' credentials with amount/expiration limits and network-level enforcement. A runtime probe further shows an agent-specific credential type (ServerKeyAgent) is live on the Agent Checkouts API, confirming agent-scoped API keys exist in practice, not just in docs. Missing for 10: independent/third-party corroboration of these scoping guarantees, and clearer documentation of general-purpose (non-payment) API key scoping/role management beyond the wallet/card/checkout domain.

   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

   Skyfire API keys are scoped per-agent (Buyer/Seller) and pay tokens carry committed amounts with hard balance ceilings, and KYA-gated tokens enforce identity requirements, which together give agent-level least-privilege credentials. However, this is scoped to payment/identity tokens rather than granular API permission scopes (e.g., no fine-grained action/resource-level scoping or role-based permission sets), and there is no documented per-token revocation API. missing for 10: fine-grained permission/action scoping beyond agent+amount+identity, documented revocation controls, independent/hands-on verification of scoping enforcement.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Crossmint
   Crossmint~partialprobed5/10

   Crossmint's docs show a single REST API accessed via quickstarts (agent checkouts, cards, stablecoin wallets) and protocol-specific clients like @x402/core and mppx, implying SDK-style tooling, but no evidence names an official multi-language SDK package (e.g., npm/pip installable Crossmint SDK) and the OpenAPI probe found no published spec, undercutting a clean 'official SDK' story. missing for 10: explicit official SDK package names/install instructions, multi-language SDK coverage, and a discoverable OpenAPI/schema reference.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Evidence shows Skyfire has REST API reference docs, a Playground, and an MCP server for agent integration, but nowhere does it mention or link to an official language SDK (e.g., Python/JS client library). The openapi.json probe even returned 404, undermining any inference of auto-generated SDK tooling.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

6. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Crossmint—none0/10

   The only explicit evidence about webhooks states the opposite of the story: Agent Checkouts documentation says 'no webhooks in v1' and requires polling until a terminal state is reached, with no other evidence pack item describing a webhook subscription mechanism anywhere in Crossmint's API.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Evidence covers token issuance, charging, MCP tools, and identity verification, but nowhere mentions webhooks or any event subscription/callback mechanism for developers to receive notifications. Missing for 10: any webhook endpoint registration, event types, or push-notification documentation.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Crossmint~partialclaimed5/10

   Crossmint lets agents transact autonomously once delegated: onchain-enforced spend limits, counterparties, and time windows mean the agent acts 'with no user prompt per action' and checkouts/x402/MPP payments proceed without human intervention ([crossmint-supp-4], [crossmint-supp-6], [crossmint-supp-7]). However this is scoped strictly to payment/checkout automation, not a general-purpose background job/workflow scheduler, and agent checkouts require manual polling with no webhooks or staging ('no webhooks in v1', 'no staging environment') ([crossmint-supp-7]). Missing for 10: general-purpose automation/scheduling framework beyond payments, webhook/event-driven triggers, and evidence of autonomous background operation outside the payment domain.

   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

   Skyfire's MCP server lets an agent autonomously discover sellers, mint kya/pay tokens, and execute commerce transactions without human-in-the-loop approval up to committed token limits (skyfire-docs-6, skyfire-supp-9, skyfire-supp-4), which supports autonomous background operation for agent commerce specifically. But Skyfire is a payment/identity layer, not a general automation/orchestration platform — there's no documented scheduler, trigger system, or persistent background-job mechanism for setting up broader autonomous workflows beyond commerce transactions. missing for 10: evidence of a scheduling/trigger system, persistent background job execution beyond per-call MCP invocations, and support for non-commerce automation tasks.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”

   proof ↗⚑ flag

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

   weight 2 · round to Skyfire
   Crossmint—none0/10

   Crossmint's evidence describes REST APIs, SDKs, and agent-delegated payment flows (cards, wallets, checkouts, x402/MPP), but nothing shows a natural-language command interface for the human/AI-native user to directly operate Crossmint itself — no chat UI, NL-to-API translation layer, or documented conversational control surface. The axis is fair to ask of a product marketed as 'payment infrastructure for AI agents,' but no such capability is evidenced.

   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

   Skyfire ships an MCP server exposing tools (find-sellers, create-kya-token, create-pay-token, create-kya-payment-token) that let an LLM-driven agent translate natural-language requests into commerce actions like discovering sellers and issuing/charging tokens, which is the standard mechanism for natural-language operation in agentic products. Missing for 10: no evidence of a first-party conversational interface, no examples of actual natural-language prompts mapped to tool calls, and no independent/hands-on confirmation of NL-driven usage beyond the docs.

   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Create an MCP Server Resource that explains which token types are required (`kya`, `pay`, and/or `kya-pay`), how tokens must be passed (the …”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Crossmint—none0/10

   The evidence shows only markdown-based docs and an llms.txt feed; explicit probes for an OpenAPI/Swagger spec (openapi.json, swagger.json, etc.) all returned 404, and no evidence mentions an interactive API console, sandbox, or runnable code examples.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”
   • [probe] “PROBE runtime (recorded 2026-09-14): docs.crossmint.com serves llms.txt keylessly — '# Crossmint... checkout for onchain and physical-world …”

   proof ↗⚑ flag

   Skyfire—none0/10

   The evidence shows Skyfire has structured reference docs (charge-token, introspect-token, etc.) but the openapi probe found no machine-readable spec (404s on all candidate paths), and there is no mention of an interactive console, 'try it' feature, or runnable code examples anywhere in the pack — only static markdown-style API reference pages.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Crossmint—none0/10

   A direct probe found no OpenAPI/Swagger spec at any standard path (all 404s), and while an llms.txt/markdown docs format exists, that is not a machine-readable API spec. missing for 10: an OpenAPI/Swagger JSON or YAML spec, any documented spec download link, or equivalent machine-readable API schema.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.crossmint.com/llms.txt # Crossmint > Crossmint is a blockchain infrastructure platform for develop…”

   proof ↗⚑ flag

   Skyfire—none0/10

   The docs contain structured API reference pages (e.g., charge-token, introspect-token) suggesting an underlying spec, but a direct probe for machine-readable OpenAPI/Swagger files at all standard locations returned 404 for every candidate path, and no evidence shows a downloadable spec file or link.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”

   proof ↗⚑ flag

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

   weight 1 · round to Skyfire
   Crossmint~partialclaimed4/10

   Crossmint documents genuine testnet sandboxes for some flows (e.g., the stablecoin wallet quickstart runs on Base Sepolia, crossmint-docs-3), but for Agent Checkouts the docs explicitly state 'there is no staging environment for it' and testing is production-only (crossmint-supp-7). So sandboxed testing exists for part of the agent stack but is explicitly absent for another major agent capability. missing for 10: a unified sandbox/staging environment across all agent products (cards, checkouts, wallets), independent confirmation of testnet behavior beyond docs, and any sandbox coverage for Agent Cards/Checkouts specifically.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

   The MCP server docs explicitly reference a separate sandbox endpoint (mcp-sandbox.skyfire.xyz) distinct from the production mcp.skyfire.xyz, showing a dedicated test environment exists. However, there's no broader documentation of a sandbox for the core token/payment APIs, wallets, or KYA flows outside the MCP context, and no detail on how sandbox data is isolated from production. Missing for 10: dedicated sandbox docs for REST/token APIs beyond MCP, explicit guidance on test credentials/test wallets, independent confirmation the sandbox fully mirrors production without touching real funds.

   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Crossmint—none0/10

   No evidence pack item documents API versioning conventions or a deprecation policy; the only version-related signal is an endpoint path containing 'unstable' (crossmint-probe-rt-1), which if anything suggests unversioned/experimental APIs rather than a documented deprecation policy.

   ⚑ flag

   Skyfire—none0/10

   While the API path shows a v1 prefix (skyfire-probe-rt-1) and an OpenAPI spec probe returned 404s (skyfire-probe-2), there is no documentation of a versioning scheme, deprecation timeline, or migration policy anywhere in the evidence pack. Missing for 10: any deprecation policy page, versioning changelog, or migration guide.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Crossmint—none0/10

   The evidence pack covers single-item agent payment flows (cards, wallets, checkouts, x402/MPP) and mentions managing funds 'at scale' in passing, but there is no documented batch/bulk API, bulk wallet creation, or multi-item transaction endpoint that would let a user perform operations across many items at once.

   • [claimed-docs] “Secure, programmable wallets to manage and move company funds at scale.”
   • [claimed-docs] “Let your agent buy from any merchant with a single API.”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Skyfire's documented API is single-item/token-centric (create one token, charge one token, introspect one token) with no documented batch or bulk endpoints for processing many items in one call. No evidence of any bulk-operation capability across tokens, sellers, or charges.

   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”

   proof ↗⚑ flag

Fees transparency

1. merchantThe fees for agent-originated transactions are published — I can price agentic channels without asking sales

   weight 2 · round drawn
   Crossmint—none0/10

   Crossmint publishes general wallet MAU overage pricing and checkout fee tiers, but the evidence pack explicitly states 'No agent-card- or agent-checkout-specific price is published on the pricing page' (crossmint-supp-9), meaning a merchant cannot price the agent-specific channels (Agent Cards, Agent Checkouts) without contacting sales.

   • [claimed-docs] “Published pricing: wallets are "Free 1,000 Monthly Active Wallets" then "Overages start at $0.05 per MAU. Volume discounts available."; onra…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Evidence shows sellers set their own service pricing when configuring a service, but there is no published fee schedule for Skyfire's own transaction/take-rate fees on agent-originated payments — nothing lets a merchant price agentic channels without contacting sales.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

Payouts

1. merchantAgent-originated payments settle through documented payout and reporting flows, reconcilable like any other channel

   weight 1 · round to Skyfire
   Crossmint~partialclaimed3/10

   Evidence shows transaction-lifecycle tracking (order intents track total/reserved/spent/available amounts) and a documented authorization-hold/capture and dispute-management model for card checkout, which are reconciliation-adjacent, plus tiered per-transaction pricing. But there is no documented merchant payout schedule, settlement-to-bank-account flow, transaction reporting dashboard, or export/reconciliation tooling specific to agent-originated payments, and the agent-checkouts flow explicitly lacks webhooks ('no webhooks in v1' — poll until terminal state), undermining real-time reconciliation. Missing for 10: merchant payout/settlement documentation, reporting/dashboard or export tools, reconciliation-specific guidance for agent transactions, and webhook-based confirmation.

   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”
   • [claimed-docs] “Published pricing: wallets are "Free 1,000 Monthly Active Wallets" then "Overages start at $0.05 per MAU. Volume discounts available."; onra…”

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

   Skyfire documents the settlement mechanics merchants need — charge-token API, committed/ceiling amounts, multi-charge until balance exhausted, defined settlement windows (up to 51 hours), and overcharge rejection (402) — which supports reconciliation of individual transactions. However, there is no documented merchant-facing payout flow (e.g., withdrawal to bank/external accounts), no statement/reporting/export API, and no mention of standard accounting artifacts (invoices, ledgers, CSV/webhook reporting) that would let a merchant reconcile against other channels. missing for 10: documented payout/withdrawal mechanism to real-world funds, merchant reporting/statement or export API, reconciliation tooling or ledger export, independent confirmation of reporting flows.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”

   proof ↗⚑ flag

Attribution analytics

1. merchantOrders are attributed to the originating agent and I can report on or filter transactions by agent

   weight 2 · round to Skyfire
   Crossmint—none0/10

   The evidence describes agent payment mechanisms (cards, wallets, checkouts, spending rules) but contains no mention of merchant-facing reporting, dashboards, or transaction filtering by originating agent — the core of this story. Order intents and delegated signers are documented for controlling agent spend, not for merchant attribution/reporting.

   ⚑ flag

   Skyfire~partialclaimed5/10

   Skyfire ties every transaction to a specific Buyer Agent via KYA identity tokens and per-agent API keys, so orders are technically attributable to the originating agent (skyfire-docs-1, skyfire-supp-2, skyfire-supp-7), and introspect/charge-token APIs let a seller programmatically check token/agent status (skyfire-docs-4, skyfire-docs-5). However, there is no evidence of a merchant-facing report or dashboard view that lets a merchant filter/aggregate transactions by agent — only a general 'Agent Dashboard' for key management is mentioned. Missing for 10: documented merchant reporting/analytics UI or API for filtering transactions by agent, evidence of aggregate order-to-agent attribution reporting.

   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”

   proof ↗⚑ flag

Onboarding to agents

1. merchantI have a documented self-serve path to start accepting agent traffic — enable a setting, sign an agreement, or publish an endpoint

   weight 3 · round to Skyfire
   Crossmint—none0/10

   Evidence covers agent-side integrations (agent wallets, agent cards, x402/MPP payment flows, agent checkouts) but nothing documents a merchant-facing onboarding step — no setting to enable, agreement to sign, or endpoint-publishing guide aimed at merchants who want to accept agent traffic. The 'buy from any merchant' framing implies merchants need no explicit action, but this is never documented as a self-serve merchant enablement path.

   ⚑ flag

   Skyfire~partialclaimed7/10

   Skyfire documents a concrete merchant-facing path: create a Seller Agent, generate a scoped API key, click 'Create Service' with pricing/identity requirements, and use the Charge Token API to collect payment — all via the Agent Dashboard (skyfire-docs-3, skyfire-supp-8, skyfire-docs-4). However, service creation is explicitly 'Submit for approval,' meaning it's gated rather than a pure self-serve flip-a-switch flow. Missing for 10: confirmation of approval turnaround/criteria, an explicit merchant agreement/ToS signing step, and independent verification that the approval process is lightweight rather than a manual sales gate.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

   proof ↗⚑ flag

Traffic controls

1. merchantRate-limit, allow, or deny specific agents and agent platforms accessing my catalog and checkout

   weight 2 · round to Skyfire
   Crossmint—none0/10

   The evidence details user-side and agent-side spending controls (spend caps, counterparties, time windows, order intents) but nothing about merchants controlling which agents/agent platforms may access their catalog or checkout, nor any rate-limiting/allow-deny mechanism exposed to merchants. Crossmint's agent-checkout flow treats the merchant as an arbitrary third-party target ('buy from any merchant'), not as a Crossmint customer configuring agent access policies.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”

   proof ↗⚑ flag

   Skyfire~partialclaimed4/10

   Skyfire lets sellers set per-service identity requirements (KYA verification levels) that gate token creation and thus checkout access, and its payment-card flow lets a merchant's bot manager identify and allow known agents rather than block them — giving coarse allow/deny-by-identity control. However there is no documented rate-limiting feature, no explicit deny-list or per-agent/platform blocking mechanism, and no console for merchants to enumerate specific agents/platforms to throttle or reject. Missing for 10: rate-limiting controls, explicit allow/deny list management UI/API, granular per-agent-platform policy enforcement beyond identity-level gating.

   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “The site, or the bot manager in front of it, can then identify the agent/agent platform and allow it through rather than block it.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Crossmint~partialprobed6/10

   Crossmint is built API-first — wallets, agent cards, agent checkouts, and headless checkout are all exposed as REST APIs, with headless checkout explicitly positioned as the API-only alternative to Crossmint's embedded iframe UI, giving 'full control of the user experience' (crossmint-docs-1, crossmint-docs-7, crossmint-docs-8, crossmint-supp-1). However, there's no explicit claim or evidence of full UI/API feature parity across the whole platform, and the probe found no discoverable OpenAPI spec (404s on all candidate paths), suggesting some API surface may be undocumented or incomplete relative to the dashboard. Missing for 10: an explicit parity statement or audit showing every dashboard/UI action (account/team management, dispute handling, analytics) has an API equivalent, and a published OpenAPI spec confirming full API surface.

   • [claimed-docs] “Crossmint offers secure, programmable smart wallet infrastructure through a single API that is configurable for any use case”
   • [claimed-docs] “Crossmint's headless checkout API is a set of REST APIs that allow you to integrate credit card and cross-chain crypto payments inside your …”
   • [claimed-docs] “Embedded iframe with customizable UI.”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.crossmint.com/openapi.json, https://docs.crossmint.com/swagger.json, https://docs.cross…”

   proof ↗⚑ flag

   Skyfire~partialprobed6/10

   Core operations (token creation/charge/introspect, service creation, KYA verification) are all documented as REST API endpoints, and an MCP server exposes agentic workflows, showing strong API-first parity with the UI dashboard/playground. However, no OpenAPI/swagger spec was found (404s on all candidate paths), and some UI-only flows like account approval, dashboard-based key management, and paid KYA subscription setup aren't confirmed as fully API-driven. missing for 10: published OpenAPI/swagger spec, confirmation that account/service approval and subscription management can be done purely via API without dashboard interaction, independent third-party confirmation of full API/UI parity.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Add the Skyfire MCP server ... Your agent is now ready to discover sellers, generate `kya` or `pay` tokens, and instantly execute agentic co…”
   • [claimed-docs] “Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agent…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Crossmint—none0/10

   The evidence pack covers Crossmint's wallet, checkout, and agent-payment APIs in depth, but nothing addresses data export, open-format portability, or account/data takeout for users leaving the platform. Missing for 10: any documented data export feature, open-format (e.g., CSV/JSON) export tooling, or explicit portability/exit guarantees for user data.

   ⚑ flag

   Skyfire—none0/10

   Evidence covers token issuance, KYA identity verification, MCP commerce workflows, and payment settlement, but nothing describes a data export feature or open-format data portability for a user's account, transaction history, or identity data. missing for 10: any documented export/download capability, open-format (CSV/JSON) data dump, or account-closure data portability guarantee.

   ⚑ flag

Order events

1. developerMy agent or backend can subscribe to order lifecycle events — created, updated, fulfilled, canceled — pushed programmatically

   weight 3 · round drawn
   Crossmint—none0/10

   Crossmint's own docs explicitly state agent checkouts have 'no webhooks in v1' and require polling until a terminal state is reached, meaning there is no programmatic push-based subscription to order lifecycle events (created/updated/fulfilled/canceled). No other product area (wallets, cards) documents webhook/event subscription either.

   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire—none0/10

   Skyfire's docs cover token creation, charging, and introspection (pull-based checks), but there is no evidence of any webhook, event subscription, or push notification mechanism for order lifecycle events (created/updated/fulfilled/canceled). Developers must poll introspect-token rather than subscribe to pushed events.

   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”

   proof ↗⚑ flag

Delegated credentials

1. ai-native userHand my agent a scoped, limited-use payment credential — amount limits, expiry, merchant restrictions — instead of a raw card number

   weight 3 · round to Crossmint
   Crossmint✓fullprobed9/10

   Crossmint's Agent Cards give agents a one-time card number, expiration, and CVC scoped by an order intent with amount, description, merchant lock, and expiration — never exposing the real card number — enforced via Visa/Mastercard network rails (crossmint-supp-2, crossmint-supp-3, crossmint-supp-8). This is corroborated by a live runtime probe showing the agent-scoped checkout endpoint requiring agent-specific credentials (crossmint-probe-rt-1). Missing for 10: independent third-party (non-vendor) verification of the card-scoping behavior in production beyond the docs and single runtime probe.

   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Credentials are one-time and network-verified: minting returns "the secure one-time card number, expiration, and CVC", and verification is a…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”
   • [claimed-docs] “Give agents permission to pay with a user's card using Crossmint's Agentic Payments API.”

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

   Skyfire issues scoped pay/kya-pay tokens with committed amount ceilings, expiry windows (10s-24h plus grace period), and merchant/identity-requirement gating rather than raw card numbers, all documented via API and MCP server tooling. Missing for 10: independent third-party/hands-on corroboration beyond vendor docs, and explicit merchant-restriction scoping details (evidence shows identity/amount/time limits clearly but merchant-lock-in specifics are thinner).

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Machine payments

1. developerMonetize an API or service with HTTP 402 machine payments that agents pay per call without a checkout UI

   weight 3 · round to Skyfire
   Crossmint—none0/10

   All Crossmint evidence describes agents/wallets *paying* x402 or MPP-protected endpoints (client/payer side) — e.g. crossmint-supp-6 and crossmint-supp-5 explain how a Crossmint wallet reads a 402 challenge and retries with payment proof. There is no evidence of tooling for a developer to stand up their own API/service that returns HTTP 402 challenges and receives/settles per-call agent payments (the monetization/merchant side of x402). Missing for 10: any docs or API for creating/serving a 402-gated endpoint, receiving settlement, or configuring per-call pricing as a service provider — evidence only covers the consuming side.

   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “This guide shows how to pay x402-protected endpoints using a Crossmint wallet.”
   • [claimed-docs] “This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet.”

   proof ↗⚑ flag

   Skyfire~partialclaimed7/10

   Skyfire lets sellers register a service, gate access with kya/pay tokens, and charge per call via the Charge Token API after delivery — with no checkout UI, matching most of the story's intent, and the docs explicitly note overcharges are rejected with an HTTP 402 PAYMENT_ERROR. However, the evidence shows Skyfire's core mechanism is its own token/JWT (KYAPay) issuance-and-charge flow rather than a standard HTTP 402 challenge-response loop as the primary payment protocol. Missing for 10: explicit documentation that HTTP 402 is used as the initial payment-required response/handshake (not just an overcharge error code), and independent confirmation of the 402-based flow in production use.

   • [claimed-docs] “Click Create Service and provide details like: name, type, pricing, identity requirements, etc. Submit for approval.”
   • [claimed-docs] “Charge a `pay` or `kya-pay` token as a seller agent or seller service. Use this API after delivering a service, tool, or resource to collect…”
   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Settlement rails

1. developerSettle agent-initiated payments in stablecoins over documented rails

   weight 2 · round to Crossmint
   Crossmint✓fullprobed8/10

   Crossmint documents stablecoin settlement for agent payments via user-owned wallets with delegated signer permissions (USDXM/USDC), and explicit rails including x402 and MPP protocols with runtime-verified endpoint behavior, giving strong first-party and probe corroboration of documented stablecoin rails. missing for 10: independent (non-vendor) real-world case studies of production stablecoin settlement volume, and confirmation the x402/MPP flows work beyond testnet/Base Sepolia examples.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “This guide shows how to pay x402-protected endpoints using a Crossmint wallet.”
   • [claimed-docs] “This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet.”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Skyfire~partialclaimed3/10

   Skyfire documents thorough payment settlement rails — wallets, pay/kya-pay tokens, committed amounts, charge-token API, settlement timing windows, and open KYAPay token spec — but none of the evidence explicitly states that settlement occurs in stablecoins or names any specific blockchain/stablecoin rail. Missing for 10: explicit stablecoin currency mention, underlying blockchain/rail specification, and confirmation that wallet balances/settlement are denominated in a stablecoin rather than fiat/credit abstraction.

   • [claimed-docs] “Skyfire gives agents verified identity and payment credentials — "No 403 errors, captchas or blocked checkouts. Authenticated access and pay…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”
   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”

   proof ↗⚑ flag

Wallets

1. ai-native userProvision a wallet my agent holds and spends from — funded and controlled by me, with balance visibility

   weight 3 · round to Skyfire
   Crossmint~partialclaimed7/10

   Crossmint's Agent Wallets docs show a user-owned, non-custodial wallet that a user funds and controls, with the agent authorized as a scoped, revocable delegated signer (spend cap, counterparties, time window) enforced onchain, and a working stablecoin-wallet quickstart (crossmint-docs-3, crossmint-supp-4, crossmint-supp-5). However, the evidence never explicitly documents a balance-visibility feature (e.g., a balance/dashboard API for the funding user) — missing for 10: explicit balance-check/visibility API or UI evidence, independent/hands-on corroboration of the wallet flow.

   • [claimed-docs] “Create a user-owned smart wallet, authorize an agent as a delegated signer, and send USDXM on Base Sepolia.”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “MPP support is a first-class payment flow: "This guide shows how to pay MPP (Machine Payment Protocol) endpoints using a Crossmint wallet." …”
   • [claimed-docs] “Crossmint wallets pay x402 endpoints through the @x402/core client (prerequisite: "A funded Crossmint EVM wallet on Base with USDC."): on a …”

   proof ↗⚑ flag

   Skyfire✓fullclaimed7/10

   Docs describe a Buyer Agent wallet auto-created and pre-funded on signup, scoped per-agent via API keys that the user controls, with committed-amount enforcement against the wallet balance and an introspect-token API to check remaining balance. This covers user-provisioned/funded/controlled wallet plus balance visibility, but missing for 10: dashboard UI screenshots showing balance, explicit mechanism for manually topping up/funding beyond initial pre-fund, and independent/hands-on corroboration.

   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”
   • [claimed-docs] “Check whether a token is currently usable and get the remaining balance as a buyer or seller agent.”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

   proof ↗⚑ flag

Ecosystem adoption

1. developerAt least two independent parties beyond the vendor implement the protocol or platform — it is an ecosystem, not a private integration

   weight 2 · round drawn
   Crossmint—none0/10

   Evidence describes Crossmint as a single-vendor proprietary API/platform (wallets, checkout, agent cards) — even where it interoperates with external protocols like x402 or MPP, those are third-party specs Crossmint merely consumes, not evidence that independent parties implement Crossmint's own protocol/platform. No evidence pack item shows any other company or independent implementer building a competing or parallel implementation of Crossmint's infrastructure.

   ⚑ flag

   Skyfire—none0/10

   Skyfire claims tokens conform to an 'open KYAPay protocol' hosted at KYAPay.org, but every operational piece — charging, wallets, settlement, MCP server, verification — runs exclusively through Skyfire's own APIs and infrastructure per the evidence pack. There is no mention of any independent vendor, competitor, or third party implementing the protocol or running their own compatible service/settlement layer.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “The Skyfire MCP server at https://mcp.skyfire.xyz/mcp lets agents "Discover sellers", create tokens, and "Orchestrate agent commerce workflo…”

   proof ↗⚑ flag

Spec publication

1. developerThe commerce protocol this product speaks is published as an open, versioned specification I can read and implement without signing anything

   weight 3 · round to Skyfire
   Crossmint—none0/10

   Crossmint documents its own REST/agent APIs (cards, wallets, checkouts) but the evidence shows no open, versioned specification of its own commerce protocol — the OpenAPI/swagger probe returned 404 on all candidate paths, and no spec repository or versioning scheme is mentioned. While Crossmint implements external protocols like x402 and MPP, it does not publish its own commerce protocol as an open spec.

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

   proof ↗⚑ flag

   Skyfire~partialprobed4/10

   Skyfire claims tokens conform to "the open KYAPay protocol, an industry specification for identity-linked payment credentials" (referencing KYAPay.org), suggesting a published spec exists, but the evidence pack itself notes that charging, wallets, and settlement all run through Skyfire's own gated APIs, and every other capability (creating tokens, MCP server, seller services) requires an API key and account signup — no evidence of a version number, a standalone spec document, or an implementation path that doesn't require signing up with Skyfire. missing for 10: a link to a versioned KYAPay spec document, confirmation it can be implemented independently of Skyfire's account/API-key system, and independent corroboration of the spec's openness.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.skyfire.xyz/openapi.json, https://docs.skyfire.xyz/swagger.json, https://docs.skyfire.x…”
   • [probe] “PROBE runtime (recorded 2026-09-14): Skyfire's token API is live and key-gated as documented — a keyless POST to https://api.skyfire.xyz/api…”
   • [claimed-docs] “Onboarding: signup auto-creates a Buyer Agent with a "pre-funded wallet"; API keys are managed per agent and "each key is scoped to a single…”

   proof ↗⚑ flag

Disputes

1. developerDisputes and chargebacks on agent transactions can be handled via API — evidence submission, status, outcomes

   weight 2 · round drawn
   Crossmint—none0/10

   The only relevant evidence states that Crossmint itself absorbs dispute risk and manages chargebacks directly with the bank on the user's behalf (crossmint-supp-10), which is for the general Checkout product, not agent-specific. There is no documentation of any developer-facing API for submitting dispute evidence, checking dispute status, or retrieving outcomes. Missing for 10: any dispute-management API endpoints, evidence-submission workflow, or status/outcome reporting for agent transactions.

   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”

   proof ↗⚑ flag

   Skyfire—none0/10

   The evidence pack documents token creation, charging, introspection, settlement timing, and revocation limits, but nowhere describes a dispute or chargeback mechanism — no evidence-submission endpoint, dispute status API, or outcome reporting is mentioned. Payment guarantees are described as ceiling-bound token commitments rather than a dispute-resolution workflow, so this applicable axis has no supporting evidence.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”

   proof ↗⚑ flag

Refunds

1. developerRefunds on agent-placed orders can be initiated and tracked programmatically

   weight 2 · round drawn
   Crossmint—none0/10

   Evidence covers dispute/chargeback risk absorption for general card Checkout (crossmint-supp-10), but this describes Crossmint handling bank disputes, not a developer-facing refund API for initiating/tracking refunds on agent-placed orders. No refund endpoint, refund object, or tracking mechanism is documented anywhere for Agent Cards, Agent Wallets, or Agent Checkouts. Missing for 10: any refund API/endpoint, refund status tracking, and agent-order-specific refund workflow documentation.

   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”

   proof ↗⚑ flag

   Skyfire—none0/10

   The evidence pack covers token creation, charging, settlement, and revocation bounds in detail, but nowhere documents a refund API, refund initiation flow, or refund status/tracking endpoint. Since Skyfire is a payments platform, refunds are a plausible feature, but no evidence of programmatic refund support exists — missing for 10: any refund/dispute API reference, refund status tracking, or documented refund workflow.

   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”

   proof ↗⚑ flag

Agent identity

1. merchantAgents identify themselves verifiably — registered profiles, signatures, or trust tiers — so I can tell trusted agent traffic from anonymous bots

   weight 3 · round to Skyfire
   Crossmint~partialprobed5/10

   Crossmint's agent stack does embed verifiable-identity mechanisms — onchain delegated signer keys with scoped, revocable permissions (crossmint-supp-4), card-network verified 'Agent Cards' secured by Visa VIC/Mastercard Agent Pay (crossmint-supp-1, -3), and a distinct 'ServerKeyAgent' credential type confirmed live at the Agent Checkouts endpoint (crossmint-probe-rt-1). These give merchants some cryptographic/network-level basis to distinguish agent-initiated, permissioned transactions from anonymous traffic. However, there is no documented merchant-facing registry, trust-tier system, or API for merchants to look up/verify an agent's identity or reputation directly — the verification lives inside Crossmint/card-network infrastructure rather than being exposed as a merchant-consumable signal. Missing for 10: an explicit merchant-facing agent identity/reputation lookup or trust-tier classification, and independent confirmation that merchants can actually distinguish trust levels using this data.

   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “Credentials are one-time and network-verified: minting returns "the secure one-time card number, expiration, and CVC", and verification is a…”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Skyfire✓fullclaimed8/10

   Skyfire's KYA/KYA-Pay tokens give merchants a verifiable, signed identity credential (JWT) per agent, with optional real-world identity attachment and hard gating ('token creation fails and the transaction does not proceed' if verification level is insufficient), plus per-agent scoped API keys and a documented merchant/bot-manager flow to identify and admit agent traffic instead of blocking it. This directly addresses distinguishing trusted, verified agent traffic from anonymous bots via a signature-based, tiered identity system. Missing for 10: independent/third-party corroboration of real-world merchant adoption or trust-tier enforcement outside Skyfire's own docs, and no public API schema (openapi probes 404) to verify signature/verification details externally.

   • [claimed-docs] “Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agent…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “The site, or the bot manager in front of it, can then identify the agent/agent platform and allow it through rather than block it.”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

   proof ↗⚑ flag

Human oversight

1. ai-native userSensitive agent spending requires my documented approval — a confirmation step, signed mandate, or per-purchase consent — before money moves

   weight 3 · round to Crossmint
   Crossmint~partialclaimed6/10

   Crossmint documents strong pre-authorized consent mechanisms — user-signed onchain delegation with spend caps, counterparties, and time windows, plus order-intent 'agent cards' with fixed allowances and expiration — enforced without a per-purchase prompt, and revocable at any time. However, the story asks for documented approval INCLUDING per-purchase consent or signed mandate at time of spend, and Crossmint's model explicitly favors upfront scoped delegation with 'no user prompt per action' rather than a per-transaction confirmation step; this is a deliberate design tradeoff, not a failure, so it's partial rather than disputed. missing for 10: evidence of an optional per-purchase confirmation/step-up flow, independent/hands-on verification of the delegation and revocation actually working in production, and clarity on how disputes/approval work for agent checkouts specifically (dispute coverage is only confirmed for general checkout, not agent checkouts).

   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”

   proof ↗⚑ flag

   Skyfire~partialclaimed5/10

   Skyfire's pay/kya-pay tokens are signed JWT 'mandates' that commit a specific spending ceiling at creation time, and that ceiling is a hard cap enforced by the buyer's wallet balance and cardholder consent ('agent can never spend more than the cardholder approved'), giving a documented, auditable authorization trail per token. However, the evidence shows token creation is an agent/API-driven action, not a human-facing confirmation prompt or explicit per-purchase human sign-off — there's no documented UI step where a person approves each individual transaction before it fires, only the pre-set balance/identity gating. Missing for 10: an explicit human-in-the-loop confirmation/approval UI or workflow per purchase, and documentation of configurable spend policies beyond wallet pre-funding and KYA identity requirements.

   • [claimed-docs] “"A KYAPay token is a signed, interoperable credential that packages agent identity and payment intent into a verifiable envelope." Tokens ar…”
   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “"Skyfire supports identity verification through Know Your Agent (KYA), a single verification that applies to both your buyer and seller agen…”
   • [claimed-docs] “On signup, your Buyer Agent is created automatically, along with a pre-funded wallet so you can start using paid services right away.”

   proof ↗⚑ flag

Liability

1. merchantThe fraud, liability, and chargeback rules for agent-initiated transactions are documented so I know who bears the risk

   weight 2 · round to Skyfire
   Crossmint~partialclaimed4/10

   Crossmint documents dispute handling for its general Checkout product (Crossmint absorbs card dispute risk via authorization holds, per crossmint-supp-10) and describes spend caps/order-intent controls for agent cards and wallets, but explicitly notes this chargeback/liability coverage is not specific to agent-initiated transactions. There is no dedicated documentation defining fraud/liability/chargeback allocation rules for agent checkouts or agent-card/agent-wallet flows. missing for 10: explicit agent-transaction-specific liability/chargeback policy, merchant-facing dispute-resolution terms for agent checkouts, and clarity on who bears risk when an agent-initiated purchase is fraudulent or disputed.

   • [claimed-docs] “For card checkout, Crossmint absorbs dispute risk: "Crossmint will take on the risk and manage disputes directly with the bank.", using an a…”
   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Merchant coverage is URL-universal: "Let your agent buy from any merchant with a single API." — hand it "a product URL and a spending cap, a…”

   proof ↗⚑ flag

   Skyfire~partialclaimed6/10

   Skyfire's docs explicitly allocate payment risk: sellers are guaranteed payment up to a token's committed amount and 'do not carry buyer non-payment risk' (skyfire-supp-4), overcharges are rejected, and even after account deactivation in-flight tokens are still honored so sellers get paid (skyfire-supp-6). Card-based flows also state the agent can never exceed cardholder-approved amounts and purchases are never anonymous to the merchant (skyfire-supp-7). However, there is no dedicated chargeback/dispute-resolution policy, no explicit statement of who bears fraud losses when credentials are stolen or a buyer disputes via their bank, and no formal merchant-facing liability/ToS document. Missing for 10: explicit chargeback/dispute process, stolen-credential fraud liability terms, formal merchant liability agreement or ToS reference.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “Cardholder consent bounds card spending: "The agent/agent platform can never spend more than the cardholder approved." — an authorization co…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”

   proof ↗⚑ flag

Spend controls

1. ai-native userSet per-agent spend caps and usage limits and revoke an agent's payment authority instantly

   weight 2 · round to Crossmint
   Crossmint✓fullprobed8/10

   Crossmint documents onchain-enforced per-agent spend caps, allowed counterparties, and time windows for agent wallets, plus order-intent allowances with amount/expiration for agent cards, and explicitly states permissions are revocable at any time by the user. This is corroborated by detailed docs on delegation mechanics and a runtime probe confirming agent-scoped auth is live in production. Missing for 10: independent (non-vendor) confirmation that revocation is instantaneous in practice, and no evidence of a unified dashboard/UI for setting caps or revoking across all three agent products (cards, wallets, checkouts) in one place.

   • [claimed-docs] “Scoped card spending: "An order intent gives the agent a fixed allowance with an amount, description, and expiration, enforced through Visa …”
   • [claimed-docs] “Agent wallets are user-owned with onchain-enforced delegation: "The user owns a non-custodial wallet and grants the agent scoped permissions…”
   • [claimed-docs] “Crossmint's agent stack is three composable products, verbatim: Agent Cards — "a card for your agent to pay with, secured by Visa VIC and Ma…”
   • [claimed-docs] “"An agent card is an order intent that gives an agent a bounded amount to spend before a fixed expiration." Merchant locking: "The merchant …”
   • [probe] “PROBE runtime (recorded 2026-09-14): the Agent Checkouts endpoint is live and agent-scoped — a keyless POST to https://www.crossmint.com/api…”

   proof ↗⚑ flag

   Skyfire~partialclaimed4/10

   Skyfire supports per-agent scoping and spend caps: keys are scoped to a single agent, and pay tokens carry a committed amount ceiling that bounds spend and rejects overcharges. However, the docs explicitly state there is no per-token revocation API and that deactivating an account does not void already-issued tokens — in-flight tokens remain chargeable until expiry plus a 24-hour grace window — directly contradicting 'instant' revocation of payment authority. missing for 10: a documented instant per-agent/per-token revocation mechanism, independent or hands-on confirmation of revocation behavior, and granular usage-limit controls beyond token amount/expiry.

   • [claimed-docs] “Pay tokens carry committed amounts: "At creation, the token's amount is committed against the buyer's wallet (which is why token creation re…”
   • [claimed-docs] “Sellers collect via the Charge Token API: "Use this API after delivering a service, tool, or resource to collect payment from a buyer-issued…”
   • [claimed-docs] “Revocation is bounded by design: deactivating an account does not void already-issued pay/kya-pay tokens — "New token creation stops at deac…”
   • [claimed-docs] “API keys are created and managed in your Agent Dashboard, and each key is scoped to a single agent (Buyer or Seller).”

   proof ↗⚑ flag