BitKuruş (BK$) — Tokenomics

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

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.

Emission schedule

Base issuance is rate-limited by wall-clock, not by demand. The apple tree exposes one fruit slot per FRUIT_INTERVAL_SECONDS (60 s), each worth FRUIT_AMOUNT (1 BK$); a slot's fruit_id can be claimed once, and the issuance tx_id is derived from the slot, so a slot cannot be minted twice on the same node (TreeController::availableFruits). Each node runs its own tree, so the federation-wide ceiling is:

Actual issuance is lower, because it requires a player to claim each slot.

The snake mini-game issues from the same apple_tree source but has no slot schedule of its own — it mints from an apple count the browser reports. Its bounds therefore are its schedule, and they are enforced server-side:

• a server-issued, single-use play session is required, and the payout is clamped to elapsed session seconds x snake_max_apples_per_second (TreeController::consumeSnakeSession);
• a per-request apple ceiling (snake_max_apples_per_request);
• rolling 24 h caps per wallet and per IP (snake_daily_cap_per_owner, snake_daily_cap_per_ip).

A daily cap of 0 means unlimited and scripts/production-preflight.sh refuses to deploy with one, so an unset or zeroed variable can never silently open the mint.

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 transfer's output total, applied once per transfer (ValidatorCommissionService::buildPlan).
• Scope: transfer only. A split or merge reshapes tokens the sender already owns, so its output total is not a value transfer — and because a zero-fee split/merge is valid, rewarding it would let a validator farm the tail emission at no cost (ValidatorCommissionService::earnsCommission).
• 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.
• Failure handling: minting runs after the transaction has committed, so it can never reject a committed transaction. A cap-exhausted mint or a payload conflict is contained per reward and raised as an open peer_integrity_alerts row (validator_commission_mint_failed / validator_commission_conflict) instead.

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.

Rate of commission emission

Unlike the base distribution, the commission has no time schedule: it is a share of transfer volume, so its rate is 0.02% x transfer volume, i.e. annual inflation of 0.0002 x annual turnover of the supply. At 10 turnovers per year that is 0.2%; at 100, 2%.

This also means the commission cannot, in practice, be what exhausts the cap: minting the remaining headroom at 200 ppm would require a cumulative transfer volume of roughly 105 billion BK$. The 21M ceiling is approached through the base distribution, not through commission.

Commission concentration — current disclosure

The protocol splits the commission evenly across the validator set, but it pays each validator at the address configured for it, and BitKuruş currently provisions every node from a single DEFAULT_COMMISSION_WALLET (scripts/federation/nodes.conf). In practice the whole commission therefore accrues to one operator-controlled address. It is not a protocol-level team allocation — no code path mints to a reserved bucket — but anyone assessing distribution should read it as an operator-held balance that grows with transfer volume, and the listing package must disclose the address and its balance. Giving each node its own commission wallet is a tracked architecture task.

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 deflationary counter-pressure to the commission's tail emission — though an honest reading of the live ledger shows that pressure is currently negligible, because the wallet defaults to a zero fee and almost no fees have been paid.

After the cap: the validator reward ends

Once issued supply reaches the ceiling, commission minting stops permanently and fees continue to be burned rather than paid out, so the protocol-level validator reward goes to zero. This is intentional and consistent with the trust model: BitKuruş validators are an allowlisted federation operating node infrastructure, not anonymous miners who must be kept economically incentivised to keep the ledger alive (see docs/THREAT_MODEL.md). If that model ever changes to independent third-party validators, the fee would have to be routed to validators instead of burned — a consensus-affecting change requiring a coordinated federation upgrade.

Live supply transparency

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.