Reference document

BitKuruş (BK$) — Tokenomics

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 is the authoritative description of BitKuruş monetary policy. All figures are enforced in code; file references are given so anyone can verify.

Summary

Property Value
Name / ticker BitKuruş / BK$
Precision 18 decimals (decimal(36,18))
Maximum supply 21,000,000 BK$ (hard cap)
Supply model Fixed-cap; bounded tail emission via validator commission
Issuance mechanism Deterministic distribution (apple_tree source)
Consensus / mining None (no PoW/PoS); signed-gossip federation
Address format 64-hex-char Ed25519 public key

Maximum supply — the 21,000,000 cap

The hard cap is configured at config/bitkurus.php as total_supply_cap (default 21000000.000000000000000000) and enforced at issuance time by IssuanceService::assertSupplyCapAllows(). The check sums every committed issuance output and rejects any new issuance that would push the total past the cap.

This cap governs all minting — both the base distribution and the validator commission (below) go through the same IssuanceService issuance path and are therefore counted against, and bounded by, the same 21,000,000 ceiling. There is no code path that mints uncapped supply, including from the admin console.

Honest limitation: the cap is currently enforced locally on each node. In a federation where multiple nodes could issue concurrently, divergence near the cap is theoretically possible. BitKuruş therefore uses a single issuance authority (apple_tree) in production so issuance is serialized. See docs/THREAT_MODEL.md.

Distribution / emission

  • Base issuance comes from a single allowlisted source, apple_tree (BITKURUS_ISSUANCE_SOURCES=apple_tree in production). New BK$ enter circulation through this deterministic distribution mechanism (TreeController, IssuanceService).
  • Demo faucet / dev-wallet sources (test_faucet, dev_wallet, …) exist for development only and are rejected in production by scripts/production-preflight.sh.

There is no premine helper that bypasses the cap, no hidden mint function, and no team/treasury allocation encoded in the protocol. Any allocation policy (team, treasury, reserve) is an off-chain decision applied through the same capped issuance path and must be disclosed in the listing package.

Validator commission (tail emission)

Each committed transfer transaction mints a small reward split across the validator set — this is separate from, and on top of, the user's outputs.

  • Rate: BITKURUS_COMMISSION_RATE_PPM, default 200 ppm = 0.02% of the transaction's output total, applied once per transaction (ValidatorCommissionService::buildPlan).
  • Recipients: the configured validator set, split evenly (remainder to the earliest sorted validator id) so the sum is deterministic across nodes.
  • Minting path: commission tokens are issued through IssuanceService::issueIfMissing() — i.e. they are subject to the 21M cap.

Hard cap vs. inflation — how they reconcile

There is a natural question: "how can supply be both hard-capped at 21M and inflationary via commission?" The answer is that the two are not in conflict because commission minting is itself capped:

  1. Every commission mint counts toward the same 21,000,000 issued-supply total.
  2. As transactions accrue, issued supply rises monotonically toward the cap.
  3. Once issued supply reaches 21,000,000, all further issuance — base and commission — is rejected (Total supply cap exceeded.).

So the commission is best described as bounded tail emission: it gradually distributes the remaining headroom under the fixed 21M ceiling to validators as a reward for securing the network, and stops permanently once the ceiling is reached. BK$ can never exceed 21,000,000.

User transaction fees

The user-paid fee_amount (transaction inputs minus outputs) is burned at the originating node — it is not paid to validators and does not re-open cap headroom (the cap tracks gross issued outputs, which is monotonic). Fees are a pure deflationary counter-pressure to the commission's tail emission.

Live supply transparency

Endpoint Meaning
GET /api/supply/circulating Circulating supply (plain number)
GET /api/supply/total Total existing supply = sum of active tokens
GET /api/supply/max Hard cap (21,000,000)
GET /api/network Signed identity card incl. total_supply_cap, commission rate
GET /api/ledger issued_supply, active_supply, total_supply_cap, fees burned
GET /api/ledger/export Byte-identical canonical snapshot + canonical_hash

Circulating and total supply are equal today because BitKuruş has no locked, vesting, or treasury bucket at the protocol level. If such a bucket is introduced, it must be subtracted from circulating supply in SupplyController.