Security
How money and keys are protected
Private keys are not kept on a machine reachable from the internet: transactions are signed by a separate server that listens on no port.
- Your serverCreates invoices with the API key and receives signed webhooks.
- Payment serverThe API and the blockchain watcher. Only public keys: it derives addresses and cannot sign.
- Signing serverKeeps the private keys. Listens on no port and opens every connection itself.
- BlockchainCustomers pay here, and signed transactions land here.
- Cold treasuryReceived funds are moved here. Its keys are offline, and the service does not have them.
Keys
- The signing server accepts no connections: it opens every connection itself.
- The payment server holds only extended public keys (xpub): it derives addresses, and there are no private keys on it.
- The hot wallet for payouts and the treasury have different keys.
- Received funds are moved to a cold treasury whose keys the service does not have.
Where received funds go
- A payment arrives at an address the service issued and is counted on the project's balance.
- Where received funds are moved is set in the signing server's configuration: a task says only from where, which asset and how much.
- A balance is never stored as a number: it is always computed from an immutable double-entry ledger.
Payouts
- Payouts go only from a dedicated hot wallet and only to whitelisted addresses; the address is checked twice: by the API and by the signer.
- The hot wallet balance has an upper bound and is topped up by hand from the cold treasury: this caps the losses if the signing server is compromised.
- The whitelist is kept by the operator, and adding an address is signed offline with the operator key: neither the API nor the dashboard can add one.
- A new whitelist address can be used only after a delay, 24 hours by default.
- An address whose first 4 and last 4 characters match one already on the whitelist is blocked until it is confirmed with both shown in full.
- A payout above the limits is not rejected; it waits for a human decision.
Addresses
- The payment address is shown in full and is never shortened.
- Attackers send transfers from addresses with the same first and last characters, counting on a person checking only those.
- The QR code contains only the address, so the amount is shown and copied separately.
Accounts and API keys
- An authenticator app is required. A remembered device signs in with a PIN for 30 days.
- The API key is shown once, and the service stores only a hash of its secret.
- The webhook secret is shown once, when the project is created.
- The dashboard shows only the projects of its own account: the core itself checks ownership on every request.
Webhooks and redirects
- Webhooks are signed with HMAC-SHA256: verify the signature and read the current state from the API.
- An event is written in the same database transaction as the change it reports, so a failure before sending does not lose it.
- The payment page returns the buyer to your site with a signed redirect, and you fulfill the order only based on the API response.
Create a project and build the integration while it is reviewed
Sign-up is open; payments start after the project is reviewed.