Cowrie Research

stables

4 min read

Stables

  • Name: Stables
  • URL: https://stables.money/
  • Category: stablecoin payments company / virtual-account and payout operator / compliance-and-webhook control plane
  • Tags: ethereum-ecosystem
  • Summary: Stables belongs in companies/ because the durable dependency is not a neutral payments primitive or standalone protocol. It is a named operator that decides customer admission, KYC/KYB and entitlement workflow, quote and transfer access, virtual-account issuance, webhook publication, API-key issuance, sandbox-versus-production access, and the shape of the MCP and dashboard shell that integrators inherit. The useful question is not just how do I move stablecoins? but which company controls onboarding, compliance approval, bank-detail issuance, payout workflow, and the event stream integrators treat as operational truth?
  • What it does:
    • Onboards individual and business customers through customer records, entitlement flow, and KYC/KYB-gated transaction access
    • Operates quote and transfer APIs for crypto-to-fiat and broader fiat / digital-asset movement across supported rails
    • Issues virtual accounts with local bank details for currencies such as USD, EUR, and AUD
    • Publishes webhook events for customer, KYC, and payment-status lifecycle updates that integrators may treat as the source of operational truth
    • Exposes sandbox and production API environments, API keys, and a first-party MCP server for agent-driven customer, transfer, virtual-account, and webhook workflows
    • Packages customer compliance, money movement, and bank-detail issuance into one developer and operator shell rather than a neutral protocol surface
  • Key claims:
    • The docs homepage frames Stables as infrastructure to Build compliant stablecoin payments infrastructure with APIs and tools for developers and agents to move money globally, which is direct evidence that the company shell matters as much as the API surface
    • The quickstart docs say every action is tied to a Stables customer and that users need entitlements plus KYC/KYB data before they can transact, making customer admission and compliance approval explicit operator choke points
    • The transfer docs emphasize crypto-to-fiat off-ramp flow while the virtual-account docs position local bank-detail issuance as the preferred path for receipt and payout use cases, showing that the practical surface is a company-run money-movement stack rather than a single protocol
    • The webhook guide documents subscription creation, event-type selection, HMAC-SHA256 signature verification, and idempotent handling with event IDs, which matters because downstream systems may end up treating Stables callbacks as payment and compliance truth
    • The sandbox guide makes production access separable from test access through a dedicated sandbox base URL, reinforcing that environment access is controlled through company-issued credentials rather than protocol permissionlessness
    • The first-party MCP server repository says Stables exposes tools for customer management, quotes, transfers, virtual accounts, API keys, webhooks, and notifications, which extends the operator boundary into agent-facing workflow packaging rather than only REST endpoints
  • Whitepaper: No standalone company whitepaper is the point here. The strongest primary materials are the official docs corpus, llms.txt / llms-full.txt, and the first-party MCP server repository; the broader source bundle remains ../whitepapers/stables-primary-sources-2026-04-30.md.
  • Sources:

Internal linkages

Protocol / company boundary

  • There is not a particularly useful standalone Stables protocol boundary doing the analytical work.
  • The meaningful surface is the named operator that admits customers, approves KYC/KYB and entitlements, issues virtual accounts, prices or routes transfers, signs webhook truth, and decides how the easiest production path is packaged.
  • That is why this note belongs in companies/: the practical dependency is a company-run compliance, payout, and bank-detail issuance shell rather than a neutral payment primitive.

Control surface

  • Practical authority sits in customer admission, entitlement approval, KYC/KYB workflow, quote and transfer access, virtual-account issuance, API-key issuance, sandbox-versus-production access, webhook publication, and agent-facing MCP packaging.

  • The sticky dependency is operational memory: once an integrator hardens around Stables customer objects, entitlements, virtual accounts, transfers, and signed lifecycle callbacks, the real lock-in is to the company-run payment and reconciliation shell rather than only to stablecoins themselves.

  • Read Stables as a company-operated stablecoin payments and payout control plane, not as a neutral rail.

  • Last reviewed: 2026-08-10 UTC

Graph View

Backlinks