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. Commit requires a configurable quorum (default floor(N/2)+1). A solo node cannot push a transaction into the ledger — at least a majority of independent validators have to agree on shape, ownership, and value flow first.
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.
