Skip to main content
Meru’s self-custody SDKs let you add a stablecoin wallet to your web or mobile app. Your users hold and send US-dollar stablecoins, sign in with email or a passkey, and never see a seed phrase, a network fee, or the word “crypto.” You don’t have to be a crypto company to ship it.

Your users own their money

Each wallet’s key is created on the user’s device and never leaves it — not to your servers, not to Meru. True self-custody, without the usual friction.

No seed phrases

Recovery is built in. A new or lost device is restored by signing in again — nothing for your users to write down or lose.

No fees for users

Meru covers the network fees. Users only ever deal in dollars.

One flow, five platforms

Web, React Native, Flutter, iOS, and Android share the same three calls: sign in → check status → send.

The SDKs

The same wallet on every platform — a user can start on the web and pick up on their phone.

Web

@meru.app/react

React Native

@meru.app/device-signer

Flutter

meru_device_wallet

iOS · Swift

MeruDeviceWallet

Android · Kotlin

meru-device-wallet

Get started

Install, sign in, and send — in your platform.

How it works

Three steps, and the SDK handles all three for you:
1

Your backend prepares the action

Your server (running the Meru handler) turns “send $5” into an action for the user to approve.
2

The device approves it

The SDK approves it on the user’s device with their local key — the key never leaves the device.
3

Meru settles it

Meru covers the fee and completes the transfer. The recipient has the money.

The two endpoints

Every SDK talks to two places. Keep them straight: Signing in returns a short-lived session token; the SDK attaches it to every wallet call for you.

Where the key lives

Under the hood

You never call any of this directly — but if you’re curious what powers it:
Balances are USDC on the Stellar network. Each wallet is a standard Stellar account set up as a recoverable multi-signature account: the user’s device key can spend, and Meru’s recovery service can authorize a new device when the user signs in elsewhere (this is the SEP-30 standard). Meru pays the network fee and submits every transaction, so users never need to hold XLM. The device key is an Ed25519 key held in the platform’s secure hardware and used only to approve transactions your backend prepares — it can’t be exported, and neither your servers nor Meru ever see it.