Defense in depth — what an attacker must defeat
BitKuruş is engineered so that no single component — your browser, our servers, a peer node, or even a database administrator — can move funds without leaving a public, cryptographic trail. To steal or alter a single token, an attacker has to defeat every one of the following layers at the same time, on every node in the federation, without producing a divergence anyone can audit.
1. Private keys never leave the user's device
Wallets are pure-browser: Ed25519 keypairs are generated and stored client-side, encrypted under a password-derived key, and only signatures are sent over the wire. The server cannot sign for the user, cannot recover keys from a backup, and cannot impersonate a wallet — there is no server-side custody surface to compromise.
2. Every accepted transaction is cryptographically authenticated
Each transaction is serialized as canonical JSON (sorted keys, raw UTF-8, preserved zero fractions) and signed with the wallet's Ed25519 private key. Nodes reject any envelope with a missing, malformed, replayed, stale-version, or non-matching signature before any database write happens.
3. Spend-once UTXO semantics, enforced atomically
Inputs are locked with a TTL before commit, their version is checked, and burn/mint happen inside one database transaction. Duplicate inputs, duplicate outputs, value-conservation breaks, output collisions, and stale token versions are all rejected deterministically — the same way, on every node.
4. Quorum of independent validators before commit
Every user transaction is sent to peer validators for a pre-flight check, and every reachable validator holds veto power: a single rejection from any responding peer aborts the commit. Peers that are offline for the round are excluded so they cannot stall the network, but at least one independent validator must approve — a solo node can never push a transaction into the ledger on its own.
5. Peer replication is signed and time-bounded
Cross-node convergence happens through signed HTTP envelopes carrying a kind, payload, issuer node id, issuer public key, ISO-8601 issued-at, and an Ed25519 origin_signature. Inbound envelopes are rejected unless they match a trusted public key, fall inside a 60-second TTL window, come from a non-suspended peer, and pass strict shape validation. Replays, forgeries, and stale envelopes all fail closed.
6. Continuous integrity monitoring
After every committed write, an asynchronous job pulls each peer's /api/state and compares state_hash. Mismatches, conflicting issuance, dropped envelopes, and failed signatures all open structured alerts (state_divergence, issuance_conflict, replication_rejected, replication_failed) on the operator dashboard. A scheduled cross-check then re-verifies every peer's signed /api/network identity card against the local registry — a peer that mutates its key, its peer list, or its commission wallet is flagged immediately.
7. Operator hardening at the perimeter
A production preflight script blocks deployment unless APP_DEBUG is false, dev endpoints are off, the faucet is off, the node signing seed is set, peers and validators are configured, and the trusted-proxy list is explicit. Admin endpoints are gated behind session + role + an admin_enabled flag (and return 404 otherwise). Every public route has its own per-minute rate limit (submit, mutating, public read, peer replicate, ledger export) so no single client can drown the cluster.
8. Conservative monetary policy
A hard total supply cap (default 21,000,000 BK$) is enforced at issuance time. The validator commission is a fixed 0.02% inflation rate, split deterministically across the configured eligible validator set — same set on every node, defined in the environment file, not in mutable database tables. There is no path that mints uncapped supply, even from an admin console.
