How do you detect a deposit?

Every new block is parsed and transfers are matched against the addresses you subscribed to. The match arrives as a signed webhook carrying the transaction hash, the amount and the current confirmation count.

Who decides the confirmation threshold?

You do, per asset. The webhook can fire on the first block and keep arriving as confirmations grow, so risk and product can credit at different points without a second integration.

Do you hold hot wallet keys?

No. Signing stays inside your infrastructure — we accept an already signed transaction and broadcast it. Settla never sees a private key.

What if a withdrawal gets stuck?

The receipt check shows it is still pending and the fee estimate gives the price of a replacement. Replacing or cancelling stays your call: we never touch a signed transaction.

What happens on a reorg?

You receive tx.reverted with the same event id as the original credit. Which threshold makes that impossible in practice is a policy question — three Bitcoin blocks or twelve Ethereum ones already make it exceptional.

When is a dedicated node worth it?

When deposit detection and broadcast cannot wait behind someone else's spike, when limits have to follow your load rather than a pricing tier, or when isolation is a compliance requirement rather than a performance one.

For exchanges

Deposits in, withdrawals out.
On capacity that is yours alone.

An exchange answers for other people's money: a deposit has to be noticed and credited, a withdrawal signed and confirmed, and by the end of the day the numbers have to add up. Settla covers the chain side of all three — on isolated capacity, so somebody else's traffic never lands in your tail.

Discuss a dedicated node Read the docs

4: Networks in production
21 ms: Broadcast · p50
0.4 s: Deposit to credit
99.99%: Uptime · 30 days

Exchange operations

Median and tail, ms

dedicated node

Operation	p50	p99
Deposit detectedwebhook: address.credited	live	—
Withdrawal broadcasteth_sendRawTransaction	21	56
Confirmation checketh_getTransactionReceipt	19	45
Price quotes/v1/market/quotes	11	29

The tail is what a customer feels. The median is nearly the same on shared capacity — the p99 is not.

Isolation

Somebody else's spike, and what it does to your deposits

Flip the switch and watch the same minute on shared endpoints and on a dedicated node. Nothing here is broken: on shared capacity throughput is shared, and for most products that is fine — until deposits and withdrawals are the product.

shared capacity

last 30 s throughput shared with other projects

24 ms: Now
338 ms: p95 · window
0: Withdrawals queued
0.9 s: Deposit to credit

The tail, not the average
Median latency is nearly identical on both. What diverges is the p99 — and that is the number deciding when a customer sees the deposit.
A queue nobody asked for
While answers are slow, signed withdrawals pile up waiting to be broadcast. That delay lands on support, not on the graph.
Isolation buys predictability
A dedicated node does not make the chain faster. It takes other people's traffic out of your tail — the part you cannot plan around.

Two pipelines

Money in, money out, and the step you cannot take back

Both pipelines are laid out the same way on purpose: each has a point of no return, and the only difference is who pays when it lands in the wrong place.

Deposit

From the block to the customer's balance

+180 msTransaction seenThe node in the nearest region picks the transfer out of a new block.
+240 msAddress matchedThe transfer is checked against your deposit addresses.
+410 msWebhook deliveredA signed address.credited lands on your endpoint with the current confirmation count.
on chainThreshold reachedConfirmations reach the policy you set for this asset; events keep arriving as they grow.After this the money sits on the customer's balance — a rolled-back block turns into your loss.
+120 msBalance updatedYour ledger credits the customer — with the transaction hash and the block from the same event.

Withdrawal

From the request to the receipt

+14 msFee estimateA current fee for the confirmation time you are aiming at.
your sideSigned by youThe key never leaves your infrastructure: we accept an already signed transaction.
+21 msBroadcastThe transaction goes into the mempool from the nearest region.Once broadcast, a transaction cannot be recalled — only replaced with a higher fee.
on chainIncluded in a blockThe transaction waits for a block — and if the fee falls short, it can be replaced.
+19 msReceipt checkedThe receipt closes the withdrawal in your ledger and releases the reserved balance.

Reconciliation

By the end of the day the numbers add up

Reconciliation pain is rarely arithmetic. It is a deposit credited twice, an event that never arrived, and a block that came back.

One event, one id
Repeats carry the same event id: your idempotency key filters them out, and nobody is credited twice.
A reorg arrives as an event
If the block is rolled back you get tx.reverted instead of silence — the credit can be held before it leaves as a withdrawal.
Archive from genesis
Any day can be replayed for an audit or a dispute: full history with no depth limit on a dedicated node.

Daily reconciliation

24 h

Deposits credited: 4,812
Withdrawals broadcast: 1,396
Events delivered: 6,208

Unmatched

Every event carries the transaction hash and the block, so a row in your ledger traces back to the chain without a support ticket.

Shared or dedicated

The shared endpoint stays right there — it is the easy place to start and to test.

Both run on the same API and the same key, so you can keep part of the traffic on the shared pool and move only the critical part to your own node.

Criterion	Shared RPC	Dedicated nodes
Capacity	Shared pool, scaled by us	Reserved node, yours alone
Noisy neighbours	Fair queue per key	None — single tenant
Rate limits	Per plan, burst-friendly	Whatever the node can serve
Archive	Included	Included, custom retention
Placement	Nearest healthy region	Pinned to your region
Setup	Instant	Provisioned within a day
Best for	Wallets, apps, bursty traffic	Exchanges, indexers, steady load

Capacity

Shared RPC: Shared pool, scaled by us
Dedicated nodes: Reserved node, yours alone

Noisy neighbours

Shared RPC: Fair queue per key
Dedicated nodes: None — single tenant

Rate limits

Shared RPC: Per plan, burst-friendly
Dedicated nodes: Whatever the node can serve

Placement

Shared RPC: Nearest healthy region
Dedicated nodes: Pinned to your region

Setup

Shared RPC: Instant
Dedicated nodes: Provisioned within a day

Best for

Shared RPC: Wallets, apps, bursty traffic
Dedicated nodes: Exchanges, indexers, steady load

See plans Shared RPC endpoints

Questions

What exchange teams ask

Infrastructure shouldn't be the thing slowing you down.

Free to start. No credit card required.

Get a free endpoint Talk to an expert

Deposits in, withdrawals out.On capacity that is yours alone.

Somebody else's spike, and what it does to your deposits

The tail, not the average

A queue nobody asked for

Isolation buys predictability