Deposits you can prove.
Watch the addresses you control on Bitcoin and Base. Get exact transfers, reorg-aware confirmations, and signed webhooks. We never hold a key.
observed amount
25.000000
25.000000 USDC from 0x8a2c…5510
Everything between the chain and your ledger.
Detection, confirmation policy, reorg recovery, delivery and metering run as one pipeline across Bitcoin and EVM. Each colour below is a state your transfer can be in, and every step leaves evidence you can check yourself.
A cron pass plans the next block range, reads logs for the allowlisted contracts, and matches recipients against the addresses you registered or derived. On Bitcoin the same pass matches outputs paying a watched address. Amounts stay exact integers the whole way through.
10 blocks
Scan range
60 blocks / min
Job budget
300 blocks
Reconcile window
7 days
Replay window
Every transfer pins the confirmation policy that was in force when it was detected. Finality tags are trusted only when the tag block agrees with the head.
Confirmed means the pinned policy was met on the evidence stored in that revision: block hash, receipt, tag block and confirmation count.
The event is committed to an outbox in the same transaction as the state change, then delivered over HTTPS with retries and replayable history.
Reorged
Inside the automatic 64 block window the cursor rewinds, affected transfers are marked reorged, and re-mined transactions return as a new revision.
Networks
- Bitcoin mainnet and signet on Retransact nodes
- Base mainnet and Base Sepolia through your RPC
- Ethereum next through the same EVM adapter
- Native value, allowlisted ERC-20, and Bitcoin outputs
Nodes
- Bitcoin run by us: nothing to configure, nothing to babysit
- EVM: primary plus fallback, pinned to one chain
- Credentials encrypted per environment, redirects refused
- Seeds and private keys rejected at the boundary
Meters
- Address time, computed from monitoring intervals
- First qualifying transfer per tenant, on either family
- First successful delivery per endpoint
- First accepted broadcast, retries never billed
Bitcoin deposits, without running bitcoind.
Bitcoin mainnet and signet run on Retransact nodes and followers. Register a plain address or derive one from a BIP84 zpub, and deposits move through the same pipeline as EVM: exact satoshis, reorg-aware confirmations, signed webhooks. There is no endpoint to configure and no node to babysit.
Detection is outputs-only. A deposit is an output paying a watched address, identified by txid:vout, so one transaction paying two watched addresses is two deposits. A Bitcoin transaction spends inputs with different owners, so no single sender is recorded rather than guessed.
Derivation is public and non-hardened: seed phrases, xprvs and private keys are rejected at the boundary. When a wallet's unused run passes the standard 20-address gap limit, we say so — the customer's own wallet would stop scanning even though ours never does.
Retransact-run
Node
txid:vout
Identity
BIP84 zpub/vpub
Derivation
20, reported
Gap limit
Your first confirmed deposit in an afternoon.
Create a tenant, issue a key
A tenant is your workspace. Keys carry explicit scopes and one environment, and the secret is shown exactly once.
POST /v1/tenants · POST /v1/api-keys
Use Bitcoin as-is, or connect an EVM endpoint
Bitcoin runs on our nodes, so there is nothing to configure. On EVM, point us at your own endpoint first. Then register supplied addresses or derive them from your public xpub.
POST /v1/addresses · POST /v1/wallets/{id}/addresses
Point a webhook at your receiver
Every lifecycle change arrives signed. Retries, dead letters, and replays stay visible in delivery history.
POST /v1/webhook-endpoints · GET /v1/webhooks/{id}/deliveries
The event you get, and how to trust it.
Each lifecycle change is written to an outbox in the same transaction as the product state, then delivered over HTTPS to your receiver with a signature you can verify byte for byte.
{
"schemaVersion": 1,
"id": "01J8Z9K2V0",
"type": "transfer.confirmed",
"resource": {
"type": "transfer",
"id": "tr_7f3a",
"revision": 2
},
"resourceRevision": 2,
"epoch": 1,
"status": "confirmed",
"createdAt": "2026-09-16T09:41:07.000Z",
"transfer": {
"networkId": "base",
"chainId": "8453",
"transactionHash": "0x9c1f…b7e2",
"kind": "erc20",
"assetContract": "0x8335…2913",
"from": "0x8a2c…5510",
"to": "0x7a3f…c41d",
"amount": "25000000",
"logIndex": 4218,
"receiptEventIndex": 42,
"blockNumber": "24010007",
"blockHash": "0x41ab…9f0d"
},
"confirmationPolicy": {
"scope": "platform",
"version": 1,
"kind": "finalized"
},
"confirmationResult": {
"status": "confirmed"
}
}x-webhook-id: 01J8Z9K2V0
x-webhook-timestamp: 1758013267
x-webhook-key-id: whk_3f9c
x-webhook-signature: v1=9f2c…71ab
- signed bytes: `${timestamp}.${eventId}.${rawBody}`
- v1=<hex> HMAC-SHA256, constant-time compare
- 300 second timestamp window, rotating key id
- at-least-once, ordering not guaranteed
- backoff 5s to 1h, 20 attempts, 7 day window
- dead letters replayed on request, history kept
EVM transfers carry kind: "native" or "erc20". Bitcoin carries kind: "utxo", the output index in receiptEventIndex, and a null from — a transaction spends many inputs, so no single sender is recorded. The lifecycle, signature and verification steps are identical.
A signature proves who sent the event. It does not prove money moved, so the last step is yours: verify the transaction against the chain yourself before you credit an account.
You keep the keys. We keep the receipts.
Supply an xpub or a plain address. Bitcoin runs on our nodes; EVM reads through yours. Either way you get signed lifecycle events, and crediting, risk and your ledger stay on your side of the line.
- Private keys, seeds and xprvs. We reject them at the API boundary.
- Every signature, and every broadcast after it.
- Balances, sweeps and gas management.
- Your ledger, and whatever you choose to credit.
- Addresses watched from the moment they are created.
- Exact base units and satoshis, with transaction and block hashes.
- Confirmation policy, reorg revisions and coverage gaps.
- Signed delivery, retries and replayable history.
A transfer record means we observed a transfer on chain. It never credits an account and it never moves a coin.
Metered units, itemized per environment.
Test and live never mix in the same total, and every metered unit traces back to a durable source record.
Full API on test networks with $5 of usage included every month.
- Bitcoin signet and Base Sepolia test environments
- Signed webhooks and delivery history
- Supplied or derived addresses on both families
- Bitcoin managed; EVM brings your own RPC
Live environment, no monthly fee, billed only for the units you use.
- Bitcoin mainnet and Base mainnet live environments
- Metered address time and transfers
- Metered deliveries and broadcasts
- Retries and replays are never billed
Volume pricing, network rollout planning, and terms your team can audit.
- Everything in pay as you go
- Committed spend and invoicing
- Custom SLA and support
- Architecture review with our team
Free includes $5 of usage each month. Metered unit prices are published before paid rollout, and volumes above pilot limits are set from measured load rather than guesswork.
Questions we get before the first deposit.
No. You supply an xpub or a plain address, and you sign everything locally. Seeds, private keys and xprvs are rejected at the API boundary, and nothing about your signer passes through us.
Start on Bitcoin signet or Base Sepolia with $5 of usage included.
Issue a key and watch your first transfer move from detection to a signed webhook. Bitcoin needs no endpoint; EVM takes yours.
Bitcoin signet and Base Sepolia · test environments · no monthly fee