How CryptoLike protects funds, payouts and accounts

CryptoLike keeps signing keys in a separate signing service that the API cannot reach into, sends every payout through checks that you configure, and asks for a fresh 2FA code for payouts made in the cabinet or the Telegram bot. This page lists those controls as they work in the product, with the defaults, so you can decide which ones to switch on. Who runs the platform and how we write about it: about CryptoLike.

#Where the keys are

Private keys exist only inside a separate signing service. The API, the cabinet and the main database hold addresses and public keys, never private keys. The signing service accepts requests only over mutually authenticated TLS (mTLS) from a fixed list of internal services, and it checks every request against its own rules before it signs anything.

• A payout is signed only for a payout that is in processing and has a matching hold on your balance in the ledger.
• Consolidation goes only to allowlisted addresses; adding an address to the signing service's allowlist takes two different administrators, removing one takes one.
• No configured limit means no signature. A request above the limit waits in a manual queue until an operator approves it with a separate one-time code; wrong codes lead to a lockout.
• Keys are kept encrypted at rest and wiped from memory after use.

#Hot and cold wallets

Payments arrive on separate deposit addresses, one per payment or customer; the platform then consolidates them into the hot wallet, which funds payouts. When the hot balance of an asset rises above the limit set for it, the system proposes a transfer to cold storage; it never moves funds to cold storage on its own. An operator approves each transfer with a fresh 2FA code, and a proposal that nobody approves expires without moving anything.

The cold address itself changes only with two people: one administrator proposes it and a different one confirms it. The signing service does not sign transfers from the cold wallet, which it only watches. How this affects payouts, and a treasury routine for your own funds: hot and cold wallets.

#Payout controls

Every payout from the cabinet or the Telegram bot needs a fresh 2FA code for that action (a CSV batch takes one code for the whole file), and the same code cannot be used twice. A payout through the API is authorised by an API key with the withdraw permission and asks for no 2FA code, so limit such a key to your server's IP addresses and enforce the whitelist. On top of that, you choose how strict payouts are: the whitelist, the second approval and the key permissions are yours to set. The table shows each control and its default.

A payout created through the API can carry your own payout_id: repeating the request with the same asset, amount and address returns the same payout instead of a second one, and different parameters answer 409. How these work in practice: payout whitelist, second approval and mass payouts.

#Account protection

Sign-in to the cabinet uses a password and, once you turn it on, a TOTP code from an authenticator app, with 10 one-time recovery codes. The TOTP secret is stored encrypted.

• Passwords are 10 to 128 characters and are stored as argon2id hashes.
• Lockout. The number of sign-in attempts is limited. Repeated failures lock the account, and each new lock lasts longer; wrong 2FA codes count too.
• Sessions. "Sign out everywhere" ends every session; a password reset does the same. A session ends after 24 hours without activity and after 30 days at most.
• Security log. You see your own sign-ins and security changes; owners and admins also see the team's. The log cannot be edited.
• Alerts. E-mails when the password changes, 2FA is turned on or off, or the account is locked after wrong 2FA codes; Telegram messages about a new sign-in, a new API key and whitelist changes.

#API and webhooks

Every API request is signed with HMAC-SHA256 over the timestamp, the method, the path and the body hash. A timestamp more than 5 minutes off is refused, and a signature that was already used is refused as a replay. The API secret is shown once, stored encrypted and, after rotation, the old secret keeps working for 10 minutes so you can deploy the new one. Details: API authentication.

Webhooks carry an HMAC-SHA256 signature of the timestamp and the raw body, made with the endpoint's own secret. Delivery goes only to https:// addresses on public hosts: private, loopback and link-local addresses are refused when you save the URL and again when CryptoLike connects. A delivery that does not get a 2xx answer within 10 seconds is retried after 1, 5 and 15 minutes, 1, 6 and 24 hours — 7 attempts over about 31 hours. How to verify them: webhooks.

#Screening and verification

The sender of an incoming transfer is screened after its confirmations, before the money becomes available on your balance. Funds from a sanctioned source or above the risk threshold are held for a compliance review, and your server gets a deposit.on_hold webhook; if the screening service cannot answer, the credit waits instead of going through unscreened. Screening rules are set by the platform for your account, including how a transfer whose sender cannot be determined is handled: it is either credited with a mark or held for review. Payout destinations are screened when the payout is created and again before it is signed: a sanctioned address is refused and a high-risk one goes to review. What you see at each step and how to handle a held payment: AML screening of incoming payments.

#The ledger and reconciliation

Every balance change is a double-entry posting in an append-only ledger: the database rejects edits and deletions of entries, and a balance cannot go below zero. A reconciliation job regularly compares balances on the blockchains with the ledger and raises an alert on any difference.

Payments are credited only after the asset's confirmations. If a block reorganisation removes a confirmed transfer, CryptoLike reverses the credit and sends invoice.reverted or deposit.reverted; a reorganisation deeper than the platform handles on its own stops processing on that network for an operator.

#FAQ

#Does CryptoLike hold the private keys of my balance?

Yes. CryptoLike runs the wallets for you: payments arrive on addresses the platform manages, and the keys stay inside a separate signing service that signs only requests passing its own checks. You do not run nodes or store keys. You control where money goes through payouts, with 2FA, an optional address whitelist and an optional second approval.

#Can someone who steals my API key withdraw funds?

Only if that key has the withdraw permission. Keys for shops and plugins need just create_invoice and read. You can also limit a key to your server's IP addresses and enforce the payout whitelist, so even a key with withdraw can pay only to addresses you added at least 24 hours earlier.

#What happens if someone learns my cabinet password?

With 2FA turned on, the password alone does not open the account, and every payout from the cabinet needs a fresh code from your authenticator. Repeated wrong codes lock the account and sign out every session, and you get an e-mail. A new whitelist address becomes usable only 24 hours after it is added, which leaves time to notice.

#How do I know a webhook really came from CryptoLike?

Check the X-Signature header: it is sha256= followed by the HMAC-SHA256 of the X-Timestamp value, a dot and the raw request body, made with your endpoint's secret. Compare in constant time and reject old timestamps. The webhook verification guide has code for four languages.

#What happens to funds that fail screening?

They are held, not credited. A screened transfer from a sanctioned source or above the risk threshold waits for a compliance review, and your server receives a deposit.on_hold webhook for it. The review decides whether the funds are credited or handled otherwise; until then they do not appear in your available balance.