Kassa runs its own custody stack. Every address, every private key, every deposit credit and every outgoing transaction is produced, encrypted, verified and signed by infrastructure we operate — with no third-party wallet provider between you and the chain. This page describes that stack as it is built, down to the algorithms.
Kassa uses hierarchical deterministic (HD) key derivation. A single high-entropy root produces an unlimited tree of independent key pairs — one for every deposit address we issue — and any of them can be reproduced from the root alone. No address is ever shared between customers, and none is ever reused across networks.
0x41 prefix and Base58Check for TRON; HASH160 → bech32 native SegWit (P2WPKH) for Bitcoin.| Network | Assets held | Address type |
|---|---|---|
| TRON | USDT · TRC-20 | Base58Check |
| Ethereum | ETH · USDC ERC-20 | EIP-55 checksummed |
| BNB Chain | USDT · BEP-20 | EIP-55 checksummed |
| Bitcoin | BTC | Native SegWit (bech32) |
Kassa uses envelope encryption. Each address key is sealed individually with AES-256-GCM under a separate 256-bit key-encryption key (KEK). The database holds ciphertext only; the KEK and the root live in a different system entirely. Stealing one without the other yields nothing.
Illustration only — the values above are random bytes generated in your browser, not Kassa key material.
Threshold multi-party computation (MPC) splits one signing key into shares so that no single machine ever holds it whole. Kassa's model today is different, and we would rather say so than let a logo imply it: keys are hierarchical-deterministic, sealed with authenticated encryption, and surrounded by independent authorisation gates. Below is how each approach answers the same threats.
| Threat | Threshold MPC | Kassa today |
|---|---|---|
| The database is stolen | Key shares are held by separate parties; one share is useless. | The database contains AES-256-GCM ciphertext only. The KEK and the root are held in a separate encrypted secret store and are in no backup. |
| One insider tries to move funds | A quorum of share-holders must co-sign. | A customer payout needs the customer's own passkey, a paid network fee, operator approval and four automatic limits. Operator treasury movements need an additional secret on every send; changing a cold-storage destination needs a second factor. |
| A key is lost or corrupted | Shares are refreshed or re-dealt by the quorum. | Every key is re-derivable from the root at its index; the integrity audit detects a bad record before it is ever needed. |
| A signing server is compromised | The attacker holds one share, below threshold. | There is no server: code runs in short-lived, memory-only isolates with no shell, no disk and no inbound management port. A request that does not pass every gate never reaches the signer. |
| Blast radius of a single leaked key | One wallet. | One customer deposit address — balances are swept into treasury on a schedule, and child keys cannot derive their siblings or parent. |
Notifications are hints; the blockchain is the record. Nothing a third party sends us can create a balance — every credit comes from our own read of the chain, after finality, and the database itself refuses to book the same transaction twice.
Every customer receives their own addresses on every network — a permanent one to reuse, fresh one-time addresses for privacy, and labelled sub-wallets. Funds are attributed by receiving address alone; there are no memos or tags to get wrong.
Active TRON and BNB Chain addresses are read directly from the chain every 30 seconds. Ethereum activity arrives as signed event notifications from a separate blockchain data provider. Behind both, every network is polled and reconciled on a fixed schedule — no single path has to work for a deposit to be found.
Event notifications are verified with HMAC-SHA-256 over the raw request body; an unsigned or altered message is rejected. A valid one still credits nothing: it only schedules our own re-read of that address.
A transfer is counted only after the network's confirmation depth, and only when the token's contract address matches — look-alike tokens with a copied name or symbol are ignored.
The ledger carries a unique database constraint on (transaction hash, address). Hashes are canonicalised before the check, so however many detectors see a deposit, it can be written once and never twice.
Every ten minutes a separate process reads the chain for every issued address and compares it with the ledger. A missing credit is booked automatically; a discrepancy is surfaced to operators.
The constraint lives in the database, not in application logic — a race between detectors is resolved by the storage engine, not by luck.
Each network is read through several independent endpoints with automatic fail-over, rate-aware pacing and back-off. When one source is degraded the next answers, and reconciliation always goes to the chain itself — never to an intermediary's account of it.
A withdrawal is the only moment funds can leave custody, so it is the most heavily defended path in the system. The operator safety valves are evaluated when the request is made and again at the moment of settlement. There is one settlement path, and nothing bypasses it.
The ledger must hold the amount, net of anything locked or already reserved. The amount is reserved the instant the request is accepted.
Negative amounts, scientific notation, injected status fields or repeated over-balance attempts block the account automatically.
A second secret, separate from the login password and stored only as a salted PBKDF2 hash. A session token alone cannot move money.
Sub-accounts can hold and receive; only the root of an account tree can withdraw.
The address is validated for its network, and a destination that is one of our own custody addresses is refused before any fee is asked.
The measured network cost is paid to an address created for that one request. The address identifies the payment; nothing proceeds until it is seen on-chain.
A human reviews the request. Optional auto-approval relaxes only who clicks — never what is allowed — and has its own 24-hour cap.
One control halts every outgoing movement platform-wide, instantly, including requests already approved.
The treasury wallet's on-chain balance is read live; a payout larger than what is physically there is refused, not queued.
A platform-wide limit per asset that cannot be raised through the API. It bounds the damage of any bug or stolen operator session.
The request is claimed with a compare-and-set before broadcast. Of any number of simultaneous attempts, exactly one can win.
Signing happens inside our runtime — EIP-1559 on EVM networks, P2WPKH on Bitcoin, and on TRON the transaction hash is recomputed locally before it is signed — then tracked to a receipt.
Customer addresses are entry points, not vaults. Balances above a threshold are consolidated into the custody treasury by transactions signed with each address's own key; the customer's balance is unaffected because it lives on the ledger, not on the address.
Sweeps, gas top-ups, gas returns and cold transfers are each written with their transaction hash, fee and outcome, and followed to a receipt.
Network fuel is supplied by the treasury only for the measured cost of a movement, and unused fuel on single-use addresses is returned.
Funds above the operating float can be moved to an offline reserve address. Changing that address requires an operator's time-based one-time code.
Kassa's backend runs on Cloudflare's global network as isolated, memory-only functions. There is no operating system to patch, no SSH port, no long-lived machine holding state — and the secrets that matter are not reachable from the places an attacker usually lands.
Each request runs in a sandboxed V8 isolate with no filesystem and no shell. Key material exists in memory for the duration of one signing call and is gone when it returns.
All traffic terminates on Cloudflare: TLS 1.3, network-layer DDoS mitigation, and per-IP rate limits on sign-in, sign-up and account recovery.
The operator console lives on a separate origin behind identity-aware access: an unauthenticated visitor never even reaches its sign-in page. Operator sessions support TOTP, and sensitive actions demand it.
The ledger database offers 30-day point-in-time recovery, and a full export is taken off-platform every day. Any private key inside those copies is still AES-256-GCM ciphertext.
Passwords and passkeys are stored as PBKDF2-HMAC-SHA256 hashes — 100,000 iterations, a random salt per value, constant-time comparison. Three wrong attempts lock that address out of that account for 15 minutes.
A root account is recovered only with its 12-word phase key. A compromised mailbox is therefore never enough to take an account that can move funds.
Custody is not a state you reach; it is something you keep proving. These processes run on a schedule whether or not anyone is watching. The scheduler writes a heartbeat on every pass, and the operator console marks the whole platform unhealthy the moment it goes quiet.
| Root entropy & seed | BIP-39 mnemonic → PBKDF2-HMAC-SHA512 ×2048 → 512-bit seed |
| Key derivation | BIP-32 CKD (HMAC-SHA512) · BIP-44 / BIP-84 account structure · hardened upper levels |
| Signature scheme | ECDSA over secp256k1, deterministic nonces (RFC 6979), low-S |
| Address encodings | Keccak-256 + EIP-55 · Base58Check (double SHA-256) · bech32 P2WPKH |
| Transaction formats | EIP-1559 type-2 (RLP) · TRON TriggerSmartContract, txID = SHA-256(raw_data) verified locally · SegWit v0 |
| Key wrapping at rest | AES-256-GCM · 96-bit random IV · 128-bit tag · AAD = address |
| Key-encryption key | 256-bit, held outside the database, rotatable with verify-before-write |
| Inbound event authentication | HMAC-SHA-256 over the raw body, verified before parsing |
| Credential hashing | PBKDF2-HMAC-SHA256 · 100,000 iterations · per-value salt · constant-time compare |
| Operator second factor | TOTP (RFC 6238) |
| Deposit idempotency | UNIQUE (tx_hash, address) enforced by the database |
| Finality thresholds | ETH 12 blocks · BSC 15 blocks · TRON confirmed · BTC confirmed UTXO |
| Transport | TLS 1.3 at the edge |
Open an account and receive your own addresses on TRON, Ethereum, BNB Chain and Bitcoin in seconds.