What is Anyflo

Anyflo is a neutral orchestration layer for stablecoin payments. One integration lets your application accept, send, and settle in any major stablecoin across any supported blockchain — without you ever managing liquidity, bridges, FX, or chain-specific gas.

For institutions, fintechs, and platforms moving money, stablecoin payments have become the fastest, cheapest, and most programmable rail available. But the ecosystem is fragmented: every chain holds different inventory, every issuer has different reach, every wallet expects a different format. Anyflo abstracts that fragmentation.

What you get

• One API for sending and receiving payments across USDC, USDT, USDs, EURC, PYUSD and more.
• Any-to-any routing — receive USDC on Base, settle in USDT on Sui, no manual bridging.
• Best execution through a competitive solver network that auctions every transfer for tightest spread and fastest settlement.
• Embedded compliance — KYT, sanctions, and travel rule checks happen inside the orchestration layer.
• No custody footprint — Anyflo never takes principal; funds move solver-to-recipient.

Who it's for

• PSPs and acquirers adding stablecoin acceptance to existing checkout flows.
• Remittance platforms routing payouts across corridors with mixed asset preferences.
• Treasury and OTC desks rebalancing inventory across chains without touching CEX rails.
• Wallets and neobanks embedding global transfers behind a familiar UX.

How It Works

Every payment on Anyflo flows through three phases: intent, solve, and settle.

1. Intent

Your application creates a TransferOrder describing what should happen — the amount, the asset the sender wants to pay in, and the asset and chain the recipient should receive. You don't specify the route. Intent is declarative.

2. Solve

The order is broadcast to Anyflo's solver network — a competitive marketplace of liquidity providers connected over WebSocket. Solvers bid on the order in real time. The winning quote is the one that gives the recipient the most value, net of fees and delivery time.

3. Settle

The winning solver fronts the payout to the recipient on the destination chain immediately. The original funds from the sender then move to the solver as reimbursement. Atomic, on-chain, no escrow held by Anyflo.

Quick Start

Send your first transfer in under five minutes.

1. Get API credentials

Request sandbox credentials at lola@mystenlabs.com. You'll receive an ANYFLO_API_KEY and your test environment URL.

2. Create a transfer order

curl -X POST https://anyflo-gateway.gonative-cc.workers.dev/v1/orders \
  -H "Authorization: Bearer $ANYFLO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source": { "asset": "USDC", "chain": "base" },
    "destination": {
      "asset": "USDT",
      "chain": "sui",
      "address": "0x7f3a...e12"
    },
    "amount": "1000.00",
    "reference": "order_8821"
  }'

3. Inspect the response

{
  "order_id": "ord_01HZF8K3...",
  "status": "pending_solver_bid",
  "quote": {
    "rate": "0.9994",
    "destination_amount": "999.40",
    "expires_at": "2026-05-26T20:35:12Z"
  },
  "deposit": {
    "address": "0xa1b2...c4d5",
    "chain": "base",
    "asset": "USDC"
  }
}

4. Track status

curl https://anyflo-gateway.gonative-cc.workers.dev/v1/orders/ord_01HZF8K3... \
  -H "Authorization: Bearer $ANYFLO_API_KEY"

Order states: pending_solver_bid → awaiting_deposit → solver_settling → completed. Subscribe to webhooks for real-time updates.

Transfer Orders

A TransferOrder is the primary object in Anyflo. It represents one party's intent to move stablecoin value to another party.

Shape

A transfer order describes:

• Source — the asset and chain the sender is paying in.
• Destination — the asset, chain, and address the recipient should receive on.
• Amount — the source-side amount denominated in the source asset.
• Reference — your own external ID, returned in every state update.
• Metadata — arbitrary key-value payload travelling with the order.

Lifecycle

Orders progress through deterministic states. Once an order reaches completed or failed, the state is terminal and the order is immutable.

• pending_solver_bid — order broadcast, awaiting solver quotes.
• quoted — best quote selected, sender can confirm.
• awaiting_deposit — sender funds inbound, watching deposit address.
• solver_settling — solver has fronted payout, waiting reimbursement confirmation.
• completed — payout confirmed on destination chain.
• failed — deposit timeout, quote expiry, or compliance reject.

Intent-Based Architecture

Anyflo separates what a user wants to happen from how it gets executed.

In legacy payment APIs, the caller specifies the route — choose a bank, pick a corridor, select a bridge. The caller is responsible for understanding inventory, fees, and reliability across every option. That doesn't scale to a world with dozens of stablecoins on dozens of chains.

Anyflo flips the model. Your application expresses intent — "1,000 dollars of USDT should arrive on Sui at this address" — and the orchestration layer chooses the route. The route can change between two otherwise identical transfers depending on real-time inventory, gas, and solver availability.

Why intents matter

• Future-proofing — new chains and assets become available without code changes on your side.
• Best execution by construction — the marketplace structure forces solvers to compete on price and speed for every order.
• Resilience — if one solver fails, the order automatically reroutes. There's no single point of failure.

Solver Network

Solvers are the liquidity providers that execute transfer orders. The solver network is where the actual value movement happens.

How solving works

Anyflo's solver hub accepts WebSocket connections from authorized solvers. When a new TransferOrder arrives, the hub fans it out to all eligible solvers based on the asset pair and chain combination. Solvers respond with quotes — typically within hundreds of milliseconds.

The hub selects the best quote on a configurable policy (default: lowest cost for the recipient, tie-break on speed). Once selected, the winning solver is responsible for delivering the destination asset to the recipient address on-chain.

Solver characteristics

• Pre-positioned inventory across major stablecoins and chains.
• Risk-managed and credit-vetted before joining the network.
• Real-time KYC/KYT screening integrated at the order level.
• Performance-monitored — fill rate, settlement time, and dispute rate drive routing weight.

To join the solver network, contact lola@mystenlabs.com.

REST API

All public Anyflo endpoints are served over HTTPS at https://anyflo-gateway.gonative-cc.workers.dev/v1.

Authentication

Every request must include a bearer token in the Authorization header.

Authorization: Bearer sk_test_xxxxxxxxxxxxxxxxxxxx

Sandbox and live use different keys. Never expose secret keys client-side. Rotate keys from the dashboard.

Endpoints

Errors

Anyflo returns standard HTTP status codes. The body of any error response includes a code, message, and optional field identifier.

{
  "error": {
    "code": "quote_expired",
    "message": "The selected quote has expired. Request a new quote and retry.",
    "field": null
  }
}

Rate limits

Sandbox: 60 requests / minute / key. Production: tier-based, contact your account manager. 429 responses include a Retry-After header.

WebSocket API (Solvers)

Solvers connect to the Anyflo hub over WebSocket to receive orders and stream quotes back in real time.

Endpoint

wss://same-solver-hub.gonative-cc.workers.dev/connect

Handshake

Authenticate by including your solver token in the Authorization header on the upgrade request.

const ws = new WebSocket(
  "wss://same-solver-hub.gonative-cc.workers.dev/connect",
  [],
  { headers: { Authorization: `Bearer ${SOLVER_TOKEN}` } }
);

ws.on("open", () => {
  ws.send(JSON.stringify({
    type: "subscribe",
    pairs: [
      { source: "USDC:base", destination: "USDT:sui" },
      { source: "USDC:base", destination: "USDC:polygon" }
    ]
  }));
});

ws.on("message", (raw) => {
  const msg = JSON.parse(raw);
  if (msg.type === "order") {
    const quote = computeQuote(msg);
    ws.send(JSON.stringify({
      type: "quote",
      order_id: msg.order_id,
      rate: quote.rate,
      ttl_ms: 4000
    }));
  }
});

Message types

SDKs Coming Soon

First-party SDKs for the most common runtimes are in active development.

• TypeScript / Node.js — @anyflo/node · Q3 2026
• Python — anyflo on PyPI · Q3 2026
• Go — github.com/anyflo/go-sdk · Q4 2026
• Rust — under evaluation

Until SDKs ship, use the REST API directly — every modern HTTP client works. Reach out at hello@anyflo.dev if you'd like to beta-test an SDK pre-release.

Webhooks Coming Soon

Subscribe to order lifecycle events without polling.

Webhooks will deliver signed JSON payloads to a URL you register on the dashboard. Every event includes the full current order object and the event type.

Planned event types

• order.quoted — a winning quote was selected.
• order.awaiting_deposit — sender funds expected at deposit address.
• order.settling — solver has fronted the destination payout.
• order.completed — destination payout confirmed.
• order.failed — order entered terminal failure state.

Signatures will use HMAC-SHA256 over the raw request body with your webhook secret. Replay protection via a timestamp header.

Stablecoins

Asset coverage expands continuously. Live assets are integration-ready in both sandbox and production today.

Blockchains

Anyflo abstracts gas, RPC, and wallet formats per chain — you don't need a per-chain integration.