Kern protocol · mechanics, visualised
How a block is born, and where the KRN comes from.
Five questions, answered with Kern's actual parameters: how blocks are produced, how gas is consumed, who gets the reward, whether KRN is minted forever, and how slashable attestations keep issuers honest.
01 · BLOCK PRODUCTION
How a block is produced — BFT in four moves
Kern uses a three-phase BFT consensus (propose / pre-endorse / endorse). One block per second. A block is irreversible once another endorsed block is built on top of it — about 2 seconds to finality. No probabilistic reorgs. Watch the round play out:
Proposer
Propose
One validator — selected deterministically, weighted by stake — assembles transactions from the mempool and broadcasts a candidate block.
round 0 · t=0s
All validators
Pre-endorse
Each validator signs the block hash, signalling its commitment to vote for it.
gather > 2/3 stake
All validators
Endorse
Having seen pre-endorsements from > 2/3 of stake, each validator broadcasts its endorsement. At > 2/3 endorsements the block is endorsed.
> 2/3 quorum
The chain
Final
Once the next endorsed block builds on top, the level is final — it can never be reverted.
~2s after creation
A block needs endorsements from more than two-thirds of the active stake to be valid. This is what gives deterministic finality: as long as fewer than 1/3 of validators are malicious or offline, an endorsed block cannot be reverted. If a proposer fails, round 1 (then 2, …) starts with a new proposer after 1 + n seconds.
02 · GAS & FEES
How gas is consumed per transaction
Every transaction declares two things: a fee (in mukrn — 1 KRN = 1 000 000 mukrn) and a gas_limit (an upper bound on computation). The protocol charges the fee whether the operation succeeds or fails — but the fee lands in very different places depending on the outcome.
| Operation | Suggested minimum fee | Notes |
|---|---|---|
| Transfer | 1 000 mukrn | simple value move |
| Call | 5 000 mukrn + per-gas | Skald contract entry |
| Origination | 10 000 mukrn + storage rent | deploy a contract |
| Per gas unit | 0.1 mukrn | computation cost |
Storage rent (paid when deploying or growing a contract) splits 50% to the baker, 50% burned — tying KRN supply to real on-chain state usage. Fees come from users; they are not newly minted.
03 · BLOCK REWARD
Who gets paid when a block is finalized
Separate from user fees, each block mints a fresh reward (this is the issuance). That reward is split deterministically. Example below uses the steady-state value at the 50% target staking ratio: 0.079 KRN/block (79 220 mukrn).
The proposer (who built the block) gets a fixed 10% bonus of the baker pool — it has higher operational overhead. The remaining 90% goes to endorsers proportional to their stake, because endorsement is what gives the block its finality. Delegators share their baker's rewards (Liquid PoS — custody stays with the delegator). Plus the baker keeps the fees of every successful transaction it included.
04 · ISSUANCE
Is KRN minted forever? Yes — but bounded and self-stabilizing
KRN is not a fixed-cap coin like Bitcoin. A fresh reward is minted every block, so issuance is perpetual. But the rate is mathematically bounded between 0.25%/yr and 6%/yr, and it adapts to how much KRN is staked. There is no scenario where the protocol runaway-inflates.
- Low stake → inflation rises toward 6%, pulling more KRN into staking.
- Between 0 and 50% → smooth decay (smoothstep curve, no gaming at the edges).
- At / above 50% target → inflation floors at 0.25%/yr. Extra staking doesn't lower it further.
| Staking ratio | Annual inflation | Reward / block |
|---|---|---|
| 0% | 6.00% | 1.90 KRN |
| 25% | ~2.16% | 0.69 KRN |
| 40% | ~0.39% | 0.12 KRN |
| 50% (target) | 0.25% | 0.079 KRN |
| 75% (above) | 0.25% | 0.079 KRN |
Gross issuance is only half the story. KRN is continuously burned too: 50% of storage rent, 50% of slashing penalties, and 100% of failed-transaction fees. When on-chain activity is high, burns can match or exceed issuance — making real (net) inflation near zero or even negative. The 0.25% floor is the worst-case dilution for a holder who stakes; ~6% is the absolute worst case if nobody staked at all.
05 · ATTESTATIONS
How a slashable attestation keeps an issuer honest
Kern's signature primitive: an attestation is a signed claim by an issuer about a subject under a schema — a KYC check, an oracle price, a fund's NAV, an ESG figure. The issuer locks a bond in KRN. If they later sign a contradictory claim about the same (schema, subject), anyone can prove it and slash them. Honesty becomes the economically rational choice.
1 · Issue
The issuer signs (schema_id, subject, claim) and locks a bond. The attestation ID is deterministic — derived from its contents.
2a · Revoke (honest path)
The issuer can revoke the attestation when the claim no longer holds. The bond is returned. Revocation does not erase past equivocation, though.
↩ bond returned in full2b · Slash (dishonest path)
If the issuer signed two contradictory claims about the same (schema, subject) with overlapping validity, anyone submits both as evidence. The protocol verifies and slashes.
When equivocation is proven, the slash is split three ways — the same math as the rest of the protocol's slashing. Example on a 1 KRN bond:
This is the accountability primitive that other L1s lack. An oracle that posts a false price, a KYC provider that contradicts itself, a fund that misstates its NAV — all become slashable on-chain, with a standing 10%-of-slash bounty for whoever catches them. The reliability of the data is not a vendor's promise; it is a cryptoeconomic property enforced by the protocol. Both attestations are then marked consumed, so no one can double-slash the same offence.
Sourced from docs/consensus.md · docs/tokenomics.md · docs/adaptive-issuance.md · docs/attestations.md
Per-block figures use total_supply = 1B KRN for illustration; the percentages hold at any supply.