This page describes the custody and security controls currently implemented in Coinwaka’s running system, plus the controls still on our roadmap. We separate current controls from planned institutional assurance items so we do not claim what has not yet shipped. Our live transparency page shows internal user-liability and ledger-reconciliation data.
Coinwaka does not maintain customer fiat wallet balances or a pooled customer fiat float. When you buy crypto, fiat is processed through the payment provider and the purchased crypto is credited to your Coinwaka wallet balance. When you sell, crypto is reserved first, then payout is processed through the supported payment rail.
All balances, holds, and money movements are recorded through one authority: the wallet-ledger service. Every money-affecting operation writes double-entry ledger records and uses a strict idempotency key designed to prevent duplicate application. No other service should be able to move user crypto balances without going through the ledger.
A scheduled reconciliation job verifies the core balance invariants: each wallet’s spendable balance must match its ledger entries, held balances must match hold records, and held balances must never exceed total balance. Any drift is surfaced through reconciliation instead of being left to manual discovery.
On-chain withdrawals are handled by a dedicated withdrawal-signer service separated from the API and web tiers. Signing keys are loaded only inside the signer boundary and are not exposed to normal application services. Runtime handling is designed to reduce the chance of key exposure through logs, debug output, or downstream service compromise. A signing lease prevents multiple signer instances from processing the same withdrawal concurrently.
User crypto balances are tracked separately from Coinwaka’s treasury and liquidity inventory. A withdrawal is only released when it is backed by on-chain inventory of the same asset. A BTC withdrawal requires BTC inventory; USDT inventory cannot be treated as BTC cover.
Moving value out requires account-level authorization checks, including verified email, transaction PIN, device checks, and two-factor authentication based on amount, account risk, and device history. Suspicious or high-risk withdrawals can be delayed for review before broadcast. API-key access is blocked from fiat-out paths.
Deposits are received into operational hot wallets and swept toward cold storage where automated sweep coverage is already enabled. Only operational balances should remain online. Uniform sweep coverage across every supported chain is still being completed and is listed on the roadmap below.
Coinwaka publishes live internal transparency data showing total user crypto liabilities, current user holdings by asset, and ledger-reconciliation status. This is computed from the running ledger rather than presented as a static screenshot. Independent signed proof-of-reserves attestations are not yet in place and are listed on the roadmap below.
We do not claim what has not shipped. These controls are planned and not yet in place:
