Reference document

BitKuruş — Threat Model

This is the authoritative version, rendered from the project's own source document rather than retyped — so it cannot drift from what the team maintains.

Note: Reference documents are maintained in English. A Turkish summary of this material is on the summary page.

This document states, honestly, what BitKuruş defends against, what it does not, and the operational controls that bound the residual risk. It is written for security reviewers and exchange due-diligence teams.

Trust model in one sentence

BitKuruş is signed gossip among an allowlisted federation — every validator holds every other validator's Ed25519 public key ahead of time. It is not Byzantine-fault tolerant and does not claim to be a permissionless blockchain.

What an attacker must defeat (defended)

  1. User-key forgery. Every transaction is canonical-JSON serialized and Ed25519-signed client-side. Private keys never leave the browser. Nodes reject any missing / malformed / replayed / stale-version / non-matching signature before any DB write. (app/Services/Crypto/*, app/Services/Transactions/TransactionService.php.)
  2. Double-spend. Inputs are locked with a TTL, version-checked, and burned/minted inside a single DB transaction. Duplicate inputs/outputs, value-conservation breaks, and stale versions are rejected deterministically.
  3. Replication forgery / replay. Cross-node envelopes carry an issuer id, public key, ISO-8601 issued-at, and an Ed25519 origin_signature. Receivers reject unless the key is in the trusted registry, the envelope is inside a 60-second TTL, the peer is non-suspended, and the shape validates. sender+nonce is unique to stop replays. (app/Services/Replication/*.)
  4. Silent divergence. After every write, an async job pulls each peer's /api/state and compares state_hash; mismatches, conflicting issuance, dropped envelopes, and failed signatures open structured integrity alerts. A scheduled cross-check re-verifies each peer's signed /api/network identity card. (app/Services/Network/*.)
  5. Unauthorized / uncapped mint. Issuance is gated to an allowlisted source set (apple_tree in production) and every mint — including validator commission — is bounded by the 21M supply cap. (IssuanceService.)
  6. Perimeter misconfiguration. scripts/production-preflight.sh refuses to deploy with debug on, dev/faucet endpoints on, missing node seed, missing peers/validators, or a sub-majority quorum setting.

What BitKuruş does NOT defend against (accepted risk)

  • A malicious trusted validator. An allowlisted validator holds a trusted key by definition. It can refuse to broadcast, delay, or selectively forward. There is no BFT vote to override it; convergence relies on an honest majority of writes plus public divergence alerts, not on consensus that can slash or outvote a bad actor. Removing a validator is an operator action.
  • Concurrent minting near the cap. The supply cap is enforced locally per node; if two nodes minted independently at the same instant, they could briefly diverge near 21M. Mitigation: a single issuance authority (apple_tree) serializes issuance in production.
  • History reconstruction from genesis. New nodes bootstrap from a trusted peer's deterministic snapshot (/api/ledger/export), not by replaying from genesis. History is verifiable (canonical hash across peers) but not independently reconstructible from zero.
  • Transport-level peer authentication (mTLS). The peer endpoint is signed and rate-limited but not mTLS-gated. Internet-exposed validators MUST sit behind an IP allowlist or a private mesh (WireGuard / Tailscale).
  • Volumetric DoS. Per-route rate limits exist, but raw network-layer DoS is an infrastructure concern (CDN / WAF), not a protocol guarantee.

Verify it yourself

You do not need our cooperation to audit any node:

  • GET /api/state → SHA-256 state_hash over the active token set.
  • GET /api/network → the node's Ed25519-signed identity card.
  • GET /api/ledger/export → byte-identical canonical snapshot + canonical_hash.

Diff the canonical_hash from two different domains; if they match the federation agrees. The open-source bitkurus-ledger-verifier automates this and re-verifies every signature.

Roadmap to reduce accepted risk

Tracked for the architecture-hardening phase (out of scope for the current prototype): independent validator operators on distinct networks, mTLS / mesh between peers, and a globally-consensual supply-cap check. See the project roadmap.