Daimo

• Name: Daimo
• URL: https://daimo.com/
• Category: stablecoin deposit ramp / onchain settlement infrastructure / fiat-and-crypto deposit orchestration
• Tags: ethereum-ecosystem solana-ecosystem
• Summary: Daimo at the project layer is the deposit-session product surface inside a broader Daimo company shell. Keep this note on destination-first routing, session lifecycle, hosted-versus-custom integration, and contract-call-aware settlement; use daimo when the practical question is who enables rails, hosts KYC, issues credentials, and publishes lifecycle truth.
• What it does:
  • Lets integrators create deposit sessions that specify a destination chain, token, amount, and optional contract call, then guides the user through payment and settlement
  • Supports deposits from supported EVM chains, Solana, and Tron, with destination delivery to multiple EVM chains and stablecoin/token pairs
  • Offers a prebuilt React modal SDK as well as a plain REST API for custom deposit flows
  • Uses a per-session clientSecret model so apps can safely expose limited session controls to the frontend while keeping account-wide API keys server-side
  • Adds hosted fiat payment flows for selected rails like Interac, ACH, and Apple Pay, with Daimo-hosted identity verification and onchain stablecoin delivery after fiat settlement
  • Supports more advanced destination behavior, including contract-call-based delivery such as direct deposit into Hyperliquid via a final-call adapter on HyperEVM
  • Maintains a public GitHub surface that suggests the company is also experimenting beyond the core pay product, including SDK, machine-payments, and agent-oriented payment tooling
• Key claims:
  • The homepage says Daimo is “the ramp for ambitious stablecoin apps” and claims apps can integrate once and accept deposits from anywhere
  • The docs introduction says Daimo lets apps “accept deposits from any wallet, any chain, any token” and receive funds as the stablecoin and chain they want
  • The sessions guide defines a full lifecycle from requires_payment_method through succeeded, which makes the product look like a deposit control plane rather than a one-off checkout button
  • The credential model explicitly separates server-side API keys from per-session client secrets that are safe for client-side use, which is a meaningful trust-model and integration clue
  • The fiat guide says users can pay in local currency through supported rails while Daimo handles hosted KYC, payment collection, and stablecoin delivery to the configured destination
  • The Hyperliquid advanced guide shows Daimo can route funds into a downstream trading venue using destination calldata and a HyperEVM adapter, reinforcing that it is application-facing settlement infrastructure rather than only a wallet top-up flow
  • The supported-chains page claims broad multichain source support and explicitly lists destination support across chains like Arbitrum, Base, Ethereum, Optimism, Polygon, HyperEVM, and others
• Whitepaper: No canonical Daimo whitepaper or litepaper surfaced in this pass. The clearest current source of truth is Daimo’s official docs set (llms.txt, sessions, fiat, API, supported-chains, and Hyperliquid guides) plus the public GitHub organization; see ../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

• Company boundary for the broader operator shell: daimo.
• halliday — closest product-layer comparison once the question is destination control and post-payment execution.
• walletconnect-pay — useful contrast when checkout and wallet choice are packaged more directly than Daimo’s deposit-session model.
• open-payments — sharper read if account discovery and authorization stay separate from the hosted deposit flow.

Protocol / company boundary

• Keep this note on the product shell: deposit-session creation, source and destination selection, the modal-versus-API integration split, hosted fiat handoff, and destination-specific settlement behavior such as contract-call delivery.
• Use daimo for the named-operator layer around integrator admission, per-org fiat-rail enablement, credential issuance, hosted identity verification, localized payment-method policy, and the session-state truth downstream apps inherit.
• That split matters because how does a Daimo deposit session behave? and which company controls onboarding, verification, routing defaults, and lifecycle publication? are related but not identical questions.

Control surface

• At the product layer, power sits in deposit-session creation, source and destination asset policy, clientSecret issuance, hosted KYC handoff, supported payment-method coverage, and the optional contract-call adapter that decides where funds land after settlement.

• For the wider onboarding, verification, and operator-policy shell, read daimo.

• Last reviewed: 2026-08-12 UTC