Product

Crypto Splitter

Receive a deposit at one address and distribute it to several recipients by percentage — in the same asset, on the same network, after the chain has confirmed it.

Two modes, one rule set

Splitter — persistent receiving wallet

A splitter keeps a single long-lived address. You may edit recipients over time; every edit creates a new version, and each deposit is settled against the version that was current when the deposit was observed.

Settlement mode: Each confirmed deposit, or when the accumulated confirmed balance reaches a threshold you set.
Pause / resume: Pausing stops new settlements; deposits continue to be recorded and settle once resumed.
Good for: Revenue shares, collaborations, recurring payers, addresses printed on documents.

Split session — fresh address per request

A session allocates a never-used address for one request. Its recipients, percentages and fee policy are frozen at creation. Optional expected amount, expiry and a "target confirmed amount" trigger for payers who send in several parts.

Freshness: Addresses come from a pool and are checked against chain history before issue. If no fresh address is available yet, the session waits in an "allocating" state instead of reusing one.
Expiry: Between 5 minutes and 7 days. Deposits arriving after expiry are held for you to release, not silently split.
Good for: Checkouts, one-off collections, anything where the payer must be identifiable.

What you can rely on

Immutable snapshots

When a split is accepted, its recipients, percentages, and the fee policy are copied into a snapshot. Settlements read the snapshot, never the live configuration, so a later edit or an operator fee change cannot alter a deposit that is already in flight.

Fee preview before activation

The commission percentage that will apply, the recipient basis it is computed on, and whether the operator's fee wallet is configured are all shown before a splitter or session goes live — and returned in the API response as fee_policy.

Same asset, same network

USDT received on Tron is paid out as USDT on Tron. There is no conversion, no bridging and no cross-chain routing. Recipient addresses are validated for the network of the split before they are saved.

Custody boundary

The platform never holds private keys. Addresses are derived and transactions are signed by an external, policy-controlled signing provider that the operator connects and administers. The platform builds intents; the provider decides whether to sign them.

Network costs are separate

Gas and miner fees are never hidden inside the commission. For tokens (USDT, USDC) they are paid from a separately funded native-asset budget. For native coins (BTC, BCH, ETH, TRX) the estimated cost of the transfers is reserved from the deposit and shown as its own line. The estimate is displayed before you activate.

Confirmations, not promises

A deposit is settled only after the network's required confirmations or finality rule is satisfied. Transfers are then broadcast as ordinary transactions and take as long as the network takes. Nothing is described as "instant".

Deposit lifecycle

The states a deposit passes through, as reported in the dashboard, the API and webhooks.

Step 1

Observed

Seen by an indexer at the receiving address; amount and sender recorded.
Step 2

Confirming

Confirmation count or finality checked on each run; reorganisations are detected and the deposit is re-evaluated.
Step 3

Confirmed

Meets the network rule. Eligible for settlement according to the split's trigger.
Step 4

Settling

Commission and recipient amounts are computed from the snapshot; transfer intents are handed to the signing provider.
Step 5

Settled

All transfers broadcast and confirmed. Ledger entries and webhook events are final.

Deposits below the asset's minimum, deposits arriving after a session expired, and deposits to an address whose split was closed are held. Held funds are visible in your balance and can be released to an address you choose; they are never automatically returned to the sender, because a sender address is not a safe refund destination on every network.

Recipient limit on this installation: up to 20 recipients per split.

Start in the sandbox

All transfers broadcast and confirmed. Ledger entries and webhook events are final.

Create account Read the API docs