Sphere Labs: Solana-native stablecoin payments API for global businesses

Your Solana app settles in USDC in under a second. Your customer still pays by ACH, wire, SEPA, or PIX. The gap between those two worlds is not a wallet SDK problem; it is bank rails, KYC/KYB, FX, sanctions screening, and reconciliation. Sphere (product: SpherePay; company: Sphere Labs) is the Solana-native answer in that category: one REST API that converts between USD, EUR, and BRL bank money and USDC, USDT, and EURC on-chain, with Solana as a first-class settlement network rather than an afterthought.

We already placed Sphere next to Bridge and Squads Grid in Bank APIs for Solana apps. This piece is the deep dive: company context, the three product primitives, Solana-specific network codes and asset limits, concrete request shapes, and the trade-offs you only learn from the docs.

Click to zoom

What Sphere Labs is

Sphere Labs was founded in 2022 by Arnold Lee (CEO) and Luigi Charles, out of a Solana hackathon payments track win. The public brand is spherepay.co; the engineering org on GitHub is Sphere-Laboratories. In December 2024 they closed a $5M round led by Coinbase Ventures and Kraken Ventures to expand cross-border stablecoin payments. The company also powers the official Solana Ramp page on solana.com: a useful signal that Solana Foundation and ecosystem GTM treat Sphere as the Solana-native ramp operator, not just another multichain listing.

Positioning is deliberate: stablecoin payments infrastructure for businesses and regulated institutions, with B2B cross-border, payroll, payment acceptance, treasury, and trade-finance shaped solution guides in the docs. They are not a consumer wallet, not a DEX, and not a stablecoin issuer. You bring the product; they bring the rails and compliance layer.

The integration model: three hard steps

Every SpherePay flow, whether a one-off transfer or an automated virtual account, follows the same sequence. Each step is a hard prerequisite for the next.

1. Authenticate
   Bearer API key from the SpherePay dashboard
   Base URL: https://api.spherepay.co/

2. Create + verify a customer
   POST /v2/customer  → individual (KYC) or business (KYB)
   Hosted KYC link or API + document upload (Sumsub under the hood)
   Status must reach approved before any transfer

3. Register transfer instruments
   POST /v2/bank-account  → ACH / wire / SEPA / PIX / SWIFT
   POST /v2/wallet        → address + network + currency

4. Move money
   POST /v2/transfer              → explicit on-ramp or off-ramp
   POST /v2/virtual-account       → Onramper (fiat deposits → stablecoins)
   POST /v2/offloader-wallet      → Offloader (stablecoins → bank payout)

Auth is a dashboard-issued API key in the Authorization: Bearer … header. OpenAPI 3.0 is published if you want generated clients. Rate limit baseline is 100 RPS for reads and writes.

One operational detail that surprises teams used to Stripe-style sandboxes: SpherePay does not maintain a separate sandbox environment. Docs state testing runs against production systems with real identity information, so your KYC path and banking partners match what customers will hit. Plan test identities and small-dollar flows accordingly.

Product surface: Transfers, Onramper, Offloader

Think of Sphere as three ways to express the same conversion, with different control vs automation trade-offs.

1. Transfers API (explicit control)

POST /v2/transfer creates a single on-ramp (fiat → stablecoin) or off-ramp (stablecoin → fiat). You name customer, amount, source instrument, and destination instrument. Status moves through pendingFunding → fundsReceived → processing → succeeded (or failed / returned). Poll GET /v2/transfer/{id} or list with filters.

Optional: lock FX first with POST /v2/quote, then attach the quote when creating the transfer so rate risk is bounded for the quote duration.

2. Onramper Accounts (virtual bank → stablecoin)

Onramper Accounts are the classic bank-API virtual account pattern. You call POST /v2/virtual-account with customer, source currency, destination stablecoin, network, and wallet address. Sphere returns real deposit instructions (account number, routing number, beneficiary). Any fiat that lands there converts automatically to the configured stablecoin and ships on-chain. No per-deposit API call.

Onramper is an add-on product (enablement via sales). Fiat in: USD via ACH/wire, EUR via SEPA. Stablecoin out includes USDC on Solana (and other EVM chains) and USDT on Ethereum/Tron. Create one Onramper Account per customer: shared accounts lose attribution and force ugly amount/timing matching.

3. Offloader Wallets (stablecoin → bank, automatic)

This is Sphere's cleanest differentiator for Solana payouts. POST /v2/offloader-wallet provisions a dedicated on-chain address bound to a customer bank account. Any supported stablecoin sent to that address converts and pays out via ACH, wire, or SEPA. Configure once; every subsequent deposit is automatic.

Offloader is also add-on. Supported inbound includes USDC and EURC on Solana (plus USDC/USDT/EURC on other listed chains). Fiat destinations: USD (ACH/wire), EUR (SEPA). Critical caveat from the docs: webhooks are not currently supported for Offloader Wallets. You poll the Transfers API for conversion status. Same one-wallet-per- customer rule as Onramper.

Solana specifics developers miss

• Network code is sol, not solana. Channel codes in the docs list blockchain networks as ethereum, sol, base, polygon, arbitrum, avalanche, tron, starknet. Mixing a fiat channel code into a wallet object (or the reverse) errors.
• Assets on Solana: USDC and EURC for transfers and offloaders. USDT on Solana is not in the supported-rails matrix the way USDC is.
• BRL / PIX does not support Solana. PIX on-ramps settle USDC/USDT to EVM and Tron destinations; off-ramps from those chains can pay BRL via PIX. Requests with "network": "sol" and a BRL leg are rejected. PIX also needs a separate verification profile (kyc_profile_b / kyb_profile_b) beyond the default profile.
• SWIFT USD payouts are supported as an off-ramp destination but require verification profile C and (for third-party payments) supporting documents. Do not assume SWIFT is open on day one of an API key.

A Solana on-ramp, concretely

After the customer is approved, register a US bank account and a Solana USDC wallet, then create the transfer. Shape mirrors the public first-call guide; network values use the documented channel codes.

const BASE = "https://api.spherepay.co"
const headers = {
  Authorization: `Bearer ${process.env.SPHERE_API_KEY}`,
  "Content-Type": "application/json",
}

// 1. Customer already KYC-approved: customer_…
// 2. Bank account registered: bankAccount_… (networks: ["ach"])
// 3. Register Solana wallet destination
const wallet = await fetch(`${BASE}/v2/wallet`, {
  method: "POST",
  headers,
  body: JSON.stringify({
    customerId: "customer_…",
    address: "YourSolanaPubkeyBase58…",
    network: "sol",
    currency: "usdc",
  }),
}).then((r) => r.json())

// 4. On-ramp: ACH USD → USDC on Solana
const transfer = await fetch(`${BASE}/v2/transfer`, {
  method: "POST",
  headers,
  body: JSON.stringify({
    amount: "100.00",
    customer: "customer_…",
    source: {
      type: "bank_account",
      id: "bankAccount_…",
      currency: "usd",
      network: "ach",
    },
    destination: {
      type: "wallet",
      id: wallet.id,
      currency: "usdc",
      network: "sol",
    },
  }),
}).then((r) => r.json())
// transfer.status starts as pendingFunding until ACH funds arrive

Onramper virtual account → Solana USDC

For recurring inbound fiat (invoices, payroll funding, merchant deposits), issue a virtual account once and hand the customer bank details.

const onramper = await fetch(`${BASE}/v2/virtual-account`, {
  method: "POST",
  headers,
  body: JSON.stringify({
    customerId: "customer_…",
    sourceCurrency: "USD",
    destinationCurrency: "USDC",
    network: "sol",
    walletAddress: "YourSolanaPubkeyBase58…",
  }),
}).then((r) => r.json())

// onramper.depositInstructions.bankAccountNumber
// onramper.depositInstructions.bankRoutingNumber
// Share those; every ACH/wire deposit auto-converts to USDC on Solana.

Offloader wallet → ACH

For the reverse treasury shape (protocol revenue, marketplace seller balances, contractor USDC that must become payroll USD), bind a Solana deposit address to a bank account.

// bankAccount_… already registered with ACH details
const offloader = await fetch(`${BASE}/v2/offloader-wallet`, {
  method: "POST",
  headers,
  body: JSON.stringify({
    customerId: "customer_…",
    currency: "usdc",
    network: "sol",
    destination: {
      bankAccountId: "bankAccount_…",
      currency: "usd",
      network: "ach",
      achReference: "PAYOUT-001",
    },
  }),
}).then((r) => r.json())

// Share offloader.address — USDC on Solana only.
// Poll GET /v2/transfer (no Offloader webhooks today).

Rails and assets at a glance

Fiat rails     ACH · Wire · SEPA · PIX · SWIFT (profile C)
Fiat currencies USD · EUR · BRL

Stablecoins    USDC  ethereum, sol, base, polygon, arbitrum, avalanche
               USDT  ethereum, tron (+ limited polygon/base paths)
               EURC  ethereum, sol, base

Solana notes   network code: sol
               USDC + EURC in; USDC + EURC out to ACH/wire/SEPA
               No Solana leg on BRL/PIX corridors

Automation     Onramper  = virtual bank → stablecoin (add-on)
               Offloader = stablecoin address → bank (add-on, no webhooks)

What you can ship with it

Official solution guides map the same primitives onto product shapes:

• Payroll — W-2 / 1099 in stablecoin or fiat; virtual- account funding so you are not calling the API per paycheck.
• Payment acceptance — end users pay ACH/wire/SEPA/PIX; you settle USDC/USDT/EURC to a treasury wallet or protocol account.
• Trading / FX corridors — BRL ↔ USD and USD ↔ EUR with stablecoins as the bridge asset between local rails.
• Cross-border trade finance — invoice and receivable settlement across currencies for importers/exporters and platforms sitting on top of them.
• Treasury — company fiat ↔ stablecoin conversion for yield, faster settlement, or multi-currency ops.

Where Sphere sits in the stack

Adjacent pieces on this site, so you do not double-integrate the wrong layer:

• Bridge vs Sphere vs Squads Grid — category map. Bridge (Stripe) for maximum reach and cards; Sphere for Solana-native + PIX + Offloader; Grid when the account itself must be an on-chain smart account.
• Stables — similar multichain payments API shape; compare geography, sandbox story, and quote/idempotency model.
• Lead Bank — the FDIC charter and Visa USDC settlement layer underneath some Bridge/card flows. You usually integrate Bridge or Sphere, not Lead directly.
• Brale — issue your own stablecoin with bank rails, not move USDC.
• Zoneless — marketplace split payouts; different product shape from pure ramps.
• Visa Stablecoin Platform — network control plane for bank-to-bank USDC settlement, not an app-facing virtual account API.

Honest pick for Sphere: Solana is home chain, you need LatAm (PIX) or cross-border B2B payouts, and the Offloader "any USDC that lands here becomes ACH" primitive is worth more to you than card issuing or on-chain multisig accounts.

Caveats that affect schedule

• KYC/KYB is the critical path. API calls are simple; approved customers are not. Hosted link vs API document upload both exist; business KYB needs UBOs and face verification paths.
• No sandbox. Production identity and banking partners only. Budget real test money and compliance-safe test subjects.
• Onramper and Offloader are add-ons. Confirm enablement before you design the UX around virtual accounts.
• Offloader has no webhooks today. Poll transfers; design ops dashboards accordingly.
• Profile-gated rails. Default KYC is not enough for PIX (profile B) or SWIFT (profile C). Ask which profiles your application is approved for before promising a corridor in a pitch deck.
• Prohibited countries and industries apply. Read the reference lists early; geo and industry exclusions live in your critical path once you intermediate fiat.
• Public open source is thin. Sphere-Laboratories on GitHub is mostly take-home tasks and an archived docs repo. The product surface is the hosted API + OpenAPI + Mintlify docs, not self-hosted programs.

Resources

• Product: spherepay.co
• Docs: docs.spherepay.co (llms.txt and OpenAPI available for agents and codegen)
• GitHub: github.com/Sphere-Laboratories
• X: @sphere_labs
• Solana Ramp: solana.com/solanaramp
• Related on devrels.xyz: Bank APIs for Solana apps, Stables payments API, Lead Bank, Stablecoins on Solana

TL;DR

• Sphere Labs builds SpherePay: a stablecoin payments API for businesses, with Solana as a first-class chain and the name behind solana.com/solanaramp.
• Model is customer (KYC/KYB) → bank/wallet instruments → transfer, plus Onramper virtual accounts and Offloader deposit wallets for zero-per-deposit automation.
• Use network code sol for Solana; USDC and EURC settle there. PIX is a real LatAm differentiator, but not with a Solana leg.
• No public sandbox; Offloader lacks webhooks; Onramper/Offloader and some rails are enablement-gated. Compliance and profiles dominate calendar risk more than the HTTP surface.