Daimo

• Name: Daimo
• URL: https://daimo.com/
• Category: deposit-platform operator / stablecoin-routing company / hosted KYC-and-settlement entity
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: Daimo belongs in companies/ because the useful control question is not only how a destination-first deposit session works. The sharper question is which named operator admits integrators, enables fiat rails per org, issues API credentials and per-session client secrets, hosts the identity-verification and payment UI, decides supported source and destination coverage, and publishes the session lifecycle and settlement truth that downstream apps inherit when they embed Daimo instead of building their own deposit stack.
• What it does:
  • Operates a stablecoin deposit platform that accepts deposits from wallets, exchanges, and selected fiat payment rails, then settles stablecoins to an app-defined onchain destination
  • Issues organization-level API access and per-session credentials for the same session-based flow used by the Modal SDK and REST API
  • Hosts localized fiat onboarding, identity verification, payment collection, and confirmation flows for enabled rails such as Interac, Apple Pay, ACH, SEPA, JPYC, ARS, and Bre-B
  • Decides which fiat rails are enabled per organization and which payment methods appear automatically to users in each country
  • Packages advanced routing behavior such as destination-specific settlement and contract-call delivery into one operator shell rather than exposing only a generic checkout button
  • Maintains the docs, API, SDK, and broader public integration surface most builders will treat as the canonical Daimo path
• Key claims:
  • The homepage calls Daimo the ramp for ambitious stablecoin apps, says developers can integrate once and accept deposits from anywhere, and emphasizes that funds are routed and settled non-custodially to the configured destination automatically
  • The introduction page says Daimo lets apps accept deposits from any wallet, any chain, and any token, with funds arriving as the stablecoin and chain the app wants, which is exactly why the operator shell matters: one company is normalizing many source rails into one destination contract or address flow
  • The docs explicitly say the Modal SDK and the plain REST API use the same session-based API, so the company boundary is not only a UI wrapper but the underlying session and payment-control plane
  • The fiat guide says Daimo hosts identity verification and the deposit UI, settles the fiat transfer, and delivers the stablecoin to the destination, making Daimo the practical KYC, payment-collection, and lifecycle-publication boundary for those flows
  • The fiat docs also say rails are enabled per-org and appear automatically in each user’s localized picker, which means payment-method visibility and geography coverage are operator-controlled defaults rather than neutral background facts
  • The sessions and API docs keep Daimo in the loop on credential issuance, session creation, and state transitions, reinforcing that integrators depend on Daimo for both admission and transaction-state truth
• Whitepaper: No standalone Daimo company whitepaper is the important artifact here. The clearest current primary materials are the homepage, introduction, sessions, fiat, API, supported-chains, and Hyperliquid guides, plus the earlier source capture in ../whitepapers/daimo-primary-sources-2026-04-27.md.
• Sources:
  • https://daimo.com/
  • https://docs.daimo.com/introduction
  • https://docs.daimo.com/llms.txt
  • https://docs.daimo.com/guides/sessions
  • https://docs.daimo.com/guides/fiat
  • https://docs.daimo.com/api-reference/overview
  • https://docs.daimo.com/supported-chains
  • https://docs.daimo.com/advanced/hyperliquid
  • https://github.com/daimo-eth

Internal linkages

• Product-layer note for the deposit-session surface itself: daimo.
• Useful company-shaped comparisons for operator-run deposit and routing shells: halliday, moonpay, bridge-xyz, and mesh.
• Read hyperliquid separately when the question is the downstream trading venue rather than Daimo’s company-run deposit-routing shell.

Protocol / company boundary

• Keep daimo on the deposit-session product surface: destination selection, session lifecycle, hosted-versus-custom integration paths, and contract-call-aware delivery.
• Use this entity note when the real question is who enables rails, issues credentials, hosts verification and payment collection, decides localized payment-method coverage, and becomes the operational source of truth for session success, failure, and fiat handoff.
• That split matters because Daimo markets simple app-facing deposits, but the practical trust boundary still runs through one company-managed onboarding, routing, and lifecycle-publication shell.

Control surface

• Practical leverage sits in integrator admission, API-key and client-secret issuance, per-org fiat-rail enablement, localized payment-method ordering, hosted KYC flow, source/destination coverage, and the session-state / webhook truth that apps consume after handing users into Daimo’s flow.

• Non-custodial settlement does not remove the company boundary. Daimo can still determine which rails exist, what verification gates apply, how sessions are created and progressed, and what destination behaviors are officially supported.

• Read the durable dependency as who controls the deposit and verification workflow shell?, not only where do final stablecoins land?

• Last reviewed: 2026-08-12 UTC