Wallet-as-a-Service (WaaS)

WaaS gives each of your customers a hierarchical-deterministic (HD) wallet with derived addresses across BTC, BCH, LTC, ETH, BSC, POL, TRX, SOL, XRP, BASE, ARB, AVAX and CELO, balances, transfers, and 24/7 deposit monitoring. Authenticate with your Payments API key (X-API-Key).

Base, Arbitrum, Avalanche and Celo are newly supported. They work the same way as the other EVM chains (native coin + USDC/USDT), but have had less production traffic than ETH/BSC/POL — test with small amounts first.

Base URL: https://api.rach.finance/api/v1/ · Auth: X-API-Key

What you can hold on each chain

GET /wallet/assets returns the exact asset list configured for your current environment — read it at runtime rather than hard-coding this table. It also returns transfers_enabled, which is false on a test key.

Network	Native coin	Stablecoins	Sandbox?
`ETH`	ETH (18)	USDT (6), USDC (6)	Yes
`BSC`	BNB (18)	USDT (18), USDC (18)	Yes
`POL`	POL (18)	USDT (6), USDC (6)	Yes
`BASE`	ETH (18)	USDT (6), USDC (6)	—
`ARB`	ETH (18)	USDT (6), USDC (6)	—
`AVAX`	AVAX (18)	USDT (6), USDC (6)	—
`CELO`	CELO (18)	USDT (6), USDC (6)	—
`SOL`	SOL (9)	USDT (6), USDC (6)	SOL + USDC only
`TRX`	TRX (6)	USDT (6) only	Yes (USDT)
`BTC`	BTC (8)	—	Yes
`LTC`	LTC (8)	—	Yes
`BCH`	BCH (8)	—	Yes
`XRP`	XRP (6)	—	—

Numbers in brackets are the asset’s decimals.

Two traps worth reading twice:

USDT and USDC on BSC have 18 decimals, not the 6 they have everywhere else. A base-unit amount copied from an ETH integration is off by a factor of a trillion.
There is no USDC on TRON. TRON carries USDT only; asking for USDC there is refused.

BASE, ARB, AVAX, CELO and XRP have no sandbox. They exist on live keys only, so build those flows against a live key and small amounts. A test key asking for them is refused with … is not configured for this environment.

Network names are normalised, so ETHEREUM, POLYGON, MATIC, BNB, TRON, SOLANA, BITCOIN, LITECOIN, RIPPLE, ARBITRUM and AVALANCHE all resolve to the codes above.

1. Create a customer wallet

One wallet per customer (idempotent per customer_id).

curl https://api.rach.finance/api/v1/wallet/customers \
  -H "X-API-Key: $RACH_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "customer_id": "cust_001", "word_count": 12 }'

const w = await (await fetch("https://api.rach.finance/api/v1/wallet/customers", {
  method: "POST",
  headers: { "X-API-Key": process.env.RACH_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({ customer_id: "cust_001", word_count: 12 }),
})).json();

import requests, os
w = requests.post("https://api.rach.finance/api/v1/wallet/customers",
    headers={"X-API-Key": os.environ["RACH_KEY"]},
    json={"customer_id": "cust_001", "word_count": 12}).json()

Response

{
  "wallet_id": 42,
  "customer_id": "cust_001",
  "mnemonic": ["...", "..."],
  "created_at": "2026-08-14T12:00:00Z"
}

The mnemonic is returned once at creation. It is the customer’s recovery phrase — store it securely (or hand it to the customer) and never log it.

2. Derive a deposit address

Create a receive address on a specific chain. Set enable_monitoring: true to have Rach watch it for deposits and fire webhooks.

curl https://api.rach.finance/api/v1/wallet/cust_001/derive \
  -H "X-API-Key: $RACH_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "network": "ETH", "enable_monitoring": true }'

const addr = await (await fetch("https://api.rach.finance/api/v1/wallet/cust_001/derive", {
  method: "POST",
  headers: { "X-API-Key": process.env.RACH_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({ network: "ETH", enable_monitoring: true }),
})).json();

Response

{
  "address": "0xAbC123...",
  "network": "ETH",
  "derivation_path": "m/44'/60'/0'/0/0",
  "index": 0,
  "is_testnet": false,
  "monitored": true,
  "customer_id": "cust_001"
}

network is one of BTC BCH LTC ETH BSC POL TRX SOL XRP BASE ARB AVAX CELO. Share address with your customer to receive funds.

3. Read balances

Balances are served from Rach’s database, which our monitor keeps in step with the chain (raising it on deposits, lowering it on spends). Reading them is free and instant, so you can poll this as often as your UI needs.

curl https://api.rach.finance/api/v1/wallet/cust_001/balances \
  -H "X-API-Key: $RACH_KEY"

Response

{
  "customer_id": "cust_001",
  "total": 2,
  "addresses": [
    {
      "network": "ETH",
      "address": "0xAbC123...",
      "index": 0,
      "source": "database",
      "balances": [
        { "currency": "ETH",  "balance": "0.0412",  "spendable": "0.0412",  "as_of": "2026-09-18T12:04:31Z" },
        { "currency": "USDT", "balance": "125.50",  "spendable": "125.50",  "as_of": "2026-09-18T12:04:31Z" }
      ]
    }
  ]
}

Each address returns one entry per supported currency on that network, including zeros. as_of is when we last read that figure from the chain, and source is database or chain.

Refreshing

Query	What happens	Cost to you
(none)	Returns stored balances immediately.	Free
`?refresh=true`	Returns stored balances immediately and asks the monitor to re-read these addresses on its next cycle (typically within 30s).	Free
`?live=true`	Reads the chain directly. Rate-limited per address.	Slower

?refresh=true does not block on a chain read — it returns right away and schedules the refresh, replying with refresh_requested: true and refresh_eta_seconds. Poll again after that interval to see the updated figure. Many concurrent refresh requests collapse into a single chain read, so a “pull to refresh” button is safe to wire directly to it.

Use ?live=true only when you genuinely need the chain read this instant — for example the confirmed-vs-unconfirmed split on BTC/LTC/BCH, which only the live path returns. It is throttled per address, so it is not a substitute for normal polling.

Spendable vs balance

spendable is what can actually be sent right now, and it is not always equal to balance:

XRP — spendable excludes the locked ~1 XRP base reserve.
BTC / LTC / BCH — with ?live=true you also get confirmed; balance may include unconfirmed (0-conf) funds that cannot be spent yet.
Everything else — spendable equals balance.

4. Quote a transfer

POST /wallet/{customer_id}/transfer-quote takes the same body as the transfer and returns what would happen, without sending anything. Use it to show your customer the real delivered figure before they confirm.

curl https://api.rach.finance/api/v1/wallet/cust_001/transfer-quote \
  -H "X-API-Key: $RACH_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "network": "ETH",
    "currency": "USDT",
    "to_address": "0xRecipient...",
    "amount": "25.00",
    "unit": "decimal"
  }'

Response

{
  "network": "ETH",
  "currency": "USDT",
  "to_address": "0xRecipient...",
  "gross_amount": "25000000",
  "fee_amount": "125000",
  "recipient_amount": "24875000",
  "fee_address": "0xYourFeeAddr...",
  "decimals": 6,
  "unit": "base",
  "fee_quote_hash": "9c1f…"
}

Quote amounts come back in base units (unit: "base"), whatever unit you sent — divide by 10^decimals to display them. recipient_amount is gross_amount minus your WaaS fee; the TRON sponsorship fee below is applied separately at settlement.

Pass the returned fee_quote_hash back on the transfer and the send is refused with 409 and code: "quote_changed" if your fee configuration moved in between. Omit it and the transfer proceeds at whatever the fee is when it lands.

5. Send crypto out

amount is a string; unit is decimal (whole coins, default) or base (wei/satoshi).

Idempotency-Key is required, 16–128 characters, and a transfer without one is rejected with 400. Generate one per transfer attempt (a UUID is fine) and reuse the same value when you retry — that is what stops a timeout from sending the money twice.

curl https://api.rach.finance/api/v1/wallet/cust_001/transfer \
  -H "X-API-Key: $RACH_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{
    "network": "ETH",
    "currency": "USDT",
    "to_address": "0xRecipient...",
    "amount": "25.00",
    "unit": "decimal",
    "fee_quote_hash": "9c1f..."
  }'

import requests, os, uuid
key = str(uuid.uuid4())          # keep this to retry the same transfer
tx = requests.post("https://api.rach.finance/api/v1/wallet/cust_001/transfer",
    headers={"X-API-Key": os.environ["RACH_KEY"], "Idempotency-Key": key},
    json={"network": "ETH", "currency": "USDT",
          "to_address": "0xRecipient...", "amount": "25.00", "unit": "decimal"}).json()
print(tx["tx_hash"])

Response

{
  "tx_hash": "0x9f8e...",
  "status": "submitted",
  "network": "ETH",
  "currency": "USDT",
  "amount": "25.00",
  "from_address": "0xAbC123...",
  "to_address": "0xRecipient...",
  "fee_amount": "0.42",
  "gas_fee": "0.0003",
  "timestamp": "2026-08-14T12:05:00Z"
}

XRP transfers accept a destination_tag. For chains that need it, gas/fees are handled by Rach and reported back in fee_amount / gas_fee.

amount is what leaves the wallet, not always what the recipient receives. Two things can be deducted from it before it lands: your own WaaS fee if you have configured one, and the TRON sponsorship fee below. Always read the amount field in the response — that is the figure actually sent — rather than echoing back what you requested.

Transfers require a live key. A test_sk_ key is refused with 400 — there is no sandbox for sending. You can create wallets, derive addresses and read balances on testnet, but the send path is live-only. GET /wallet/assets reports this as transfers_enabled.

6. Check a transfer’s status

A transfer’s HTTP response tells you it was submitted, not that it confirmed. Read the outcome back with the Idempotency-Key you sent:

curl https://api.rach.finance/api/v1/wallet/cust_001/transfers/$IDEMPOTENCY_KEY \
  -H "X-API-Key: $RACH_KEY"

Response

{
  "uuid": "b2e1...",
  "customer_id": "cust_001",
  "network": "ETH",
  "currency": "USDT",
  "from_address": "0xAbC123...",
  "to_address": "0xRecipient...",
  "gross_amount": "25000000",
  "quoted_fee_amount": "125000",
  "status": "confirmed",
  "tx_hash": "0x9f8e...",
  "created_at": "2026-09-27T12:05:00Z",
  "updated_at": "2026-09-27T12:06:11Z"
}

`status`	Meaning
`processing`	Accepted and being prepared. Not yet on-chain.
`pending`	Broadcast, waiting for confirmations.
`confirmed`	Settled on-chain.
`failed`	Did not settle. Safe to raise a fresh transfer with a new key.
`needs_review`	Held by Rach for manual checking. Do not retry — contact support.

This is the endpoint to poll after a timeout. If your transfer call never returned, replay it with the same Idempotency-Key — you will get the original result rather than a second transfer — or read it here.

WaaS fee collection

You can charge your own fee on every customer transfer. Rach deducts it from the transfer amount and sends it on-chain directly to your address — Rach never holds it.

curl -X POST https://api.rach.finance/api/v1/wallet/fees \
  -H "X-API-Key: $RACH_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "is_enabled": true,
    "fee_mode": "percentage",
    "fee_percent": "0.005",
    "fee_cap_usd": "5",
    "fee_addresses": { "ETH": "0xYourAddr...", "TRX": "TYourAddr..." }
  }'

Field	Meaning
`fee_mode`	`percentage` or `flat`
`fee_percent`	Fraction, not percent — `"0.005"` means 0.5%. Percentage mode only.
`fee_cap_usd`	Caps the percentage fee in USD. `"0"` = uncapped.
`flat_fee_usd`	Fixed USD charge, converted to the transferred asset. Flat mode only.
`fee_addresses`	Network code → your receiving address.

No address for a network means no fee is collected on it. Fees are only taken where you have supplied an address, so add one per network you want to earn on. PUT /wallet/fees/addresses updates addresses alone; sending "" for a network removes it and stops collection there.

USD figures (fee_cap_usd, flat_fee_usd) are converted to the asset at the current market rate; stablecoins convert 1:1. On UTXO chains (BTC/LTC/BCH) the fee is an extra output in the same transaction, so fee_tx_hash is empty. On every other chain it is a second transaction. Read your earnings with GET /wallet/earnings.

Sending USDT on TRON without TRX

TRON does not work like the EVM chains, and this trips up nearly every integration:

A TRON address does not exist on-chain until it receives something. An unactivated address cannot send anything at all, no matter how much USDT it holds.
A USDT (TRC-20) transfer costs ENERGY. Without it, the sender burns TRX — often 13–30 TRX per transfer. A customer holding only USDT is otherwise stuck.

Rach handles both automatically. When your customer sends USDT on TRON, we activate their address if needed and cover the energy, so the transfer works with zero TRX in the wallet. You do not need to pre-fund customers with TRX.

A sponsorship fee of 1 USDT is deducted from the transfer amount. If your customer sends 100 USDT, the recipient receives 99 USDT and 1 USDT is taken to cover the network cost Rach paid on their behalf.

It is taken out of the amount, not charged separately — so a customer whose entire balance is USDT can always transfer.
It is only charged after the transfer succeeds.
It is skipped when the transfer is too small to carry it.
It applies only to USDT on TRON, and only when we actually sponsored the transfer. A customer with their own energy pays nothing.

Surface this to your users before they confirm a TRON USDT transfer, and read the response’s amount field for the true delivered figure.

This is a platform-level fee for TRON network costs. It is separate from — and additional to — any WaaS fee you configure for yourself.

More endpoints

Endpoint	Purpose
`GET /wallet/assets`	Assets configured for your environment, and whether transfers are enabled
`GET /wallet/customers`	List your customer wallets
`GET /wallet/addresses`	Every derived address across all your customers
`GET /wallet/{id}/addresses`	All derived addresses for one customer
`GET /wallet/{id}/transactions`	Transaction history
`POST /wallet/estimate-gas`	Estimate a transfer’s gas before sending (EVM)
`POST /wallet/{id}/export-key`	Export a customer’s private key (guard carefully)
`GET /wallet/{id}/seed`	Recover a customer’s mnemonic (guard carefully)
`GET /wallet/earnings`	Fees you’ve earned on WaaS transfers
`GET` / `POST /wallet/fees`	Read / set your fee configuration
`PUT /wallet/fees/addresses`	Update fee receiving addresses only

Full schemas are in the Payments API Reference under WaaS. Deposits are detected automatically — see 24/7 Monitoring.

Get Started

Core Products

Monitoring & Webhooks

Wallet-as-a-Service (WaaS)

What you can hold on each chain

1. Create a customer wallet

2. Derive a deposit address

3. Read balances

Refreshing

Spendable vs balance

4. Quote a transfer

5. Send crypto out

6. Check a transfer’s status

WaaS fee collection

Sending USDT on TRON without TRX

More endpoints

​What you can hold on each chain

​1. Create a customer wallet

​2. Derive a deposit address

​3. Read balances

​Refreshing

​Spendable vs balance

​4. Quote a transfer

​5. Send crypto out

​6. Check a transfer’s status

​WaaS fee collection

​Sending USDT on TRON without TRX

​More endpoints

What you can hold on each chain

1. Create a customer wallet

2. Derive a deposit address

3. Read balances

Refreshing

Spendable vs balance

4. Quote a transfer

5. Send crypto out

6. Check a transfer’s status

WaaS fee collection

Sending USDT on TRON without TRX

More endpoints