BK$ tokenomics

The hard cap of 21.000.000 BK$

The cap is configured as total_supply_cap and enforced at issuance time by IssuanceService::assertSupplyCapAllows(). The check sums every committed issuance output and rejects any issuance that would push the total past the ceiling.

This governs all minting. Both the base distribution and the validator commission go through the same issuance path and are therefore counted against, and bounded by, the same ceiling. There is no code path that mints uncapped supply — including from the operator console.

Verify: the cap is published in each node's signed identity card at GET /api/network, so you can pin it once and detect any later change.

How BK$ enters circulation

New BK$ come from a single allowlisted issuance source, apple_tree — the public distribution mechanism on the home page. Each claim is a real on-ledger issuance, subject to the cap, replicated to every peer and visible in the ledger export.

That mechanism has two entry points, both writing through the same capped issuance path: claiming a ripe apple directly, and a skill-based mini-game whose score is settled into one issuance when the player finishes a round. Both are rate-limited per wallet and per IP address, and neither can mint outside the cap.

Development-only sources (a test faucet and dev wallets) exist in the codebase but are rejected in production by the deployment preflight script, which blocks a release that leaves them enabled.

There is no premine helper that bypasses the cap, no hidden mint function, and no team, treasury, or reserve allocation encoded in the protocol. Should any allocation policy be adopted later, it would have to pass through the same capped issuance path and be disclosed here.

Validator commission — bounded tail emission

Each committed transfer mints a small reward split across the validator set. It is separate from, and on top of, the user's outputs — it is not deducted from the amount being sent.

Rate

200 ppm = %0,02 of the transaction's output total, applied once per transaction.

Recipients

The configured validator set, split evenly, with the remainder going to the earliest sorted validator id so the total is deterministic on every node.

Minting path

The same issuance service as the base distribution — so commission is subject to the same cap.

How a hard cap and an inflationary commission reconcile

The obvious question is how supply can be both permanently capped and inflationary. The two are not in conflict because the commission minting is itself capped:

1. Every commission mint counts toward the same total issued supply.
2. As transactions accrue, issued supply rises monotonically toward the ceiling.
3. Once issued supply reaches the ceiling, all further issuance — base and commission alike — is rejected.

So the commission is best described as bounded tail emission: it gradually distributes the remaining headroom under the fixed ceiling to the validators securing the network, and stops permanently once the ceiling is reached. BK$ can never exceed its maximum supply.

User fees are burned

The user-paid fee — inputs minus outputs — is burned at the originating node. It is not paid to validators, and it does not re-open headroom under the cap, because the cap tracks gross issued output, which only ever increases. Fees are therefore a purely deflationary counter-pressure to the commission's tail emission.

Honest limitation

The supply cap is currently enforced locally on each node. In a federation where several nodes could issue concurrently, divergence near the ceiling is theoretically possible. BitKuruş therefore uses a single issuance authority in production, so issuance is serialised and this case does not arise. The accepted-risk analysis is published in the threat model.

Source of truth: this page summarises the authoritative tokenomics document, which cites the exact source files enforcing each figure. Where the two ever differ, the document governs.