Governance

A proposal to move one consensus parameter, and a ballot whose power is your weight multiplied by what you spend. Money alone buys nothing here, and neither does a history you manufactured.

Using it

propose, vote, watch

./baklava propose   -param min_stake -value 2000000
./baklava vote      -proposal fd112a3d... -spend 5000000
./baklava vote      -proposal fd112a3d... -spend 5000000 -against
./baklava proposals

Or /propose, /vote and /proposals from the console. Only a registered member may open one or vote on one.

Two exponents, and only one of them was a choice.

Voting power is maturity^a × reliability^b × BKLV spent. The exponent on the spend is exactly 1, and that is not tunable: it is what makes the ballot sybil-neutral. Splitting a holding across a hundred identities gives a hundred times a hundredth, which is what you started with.

And a and b are both 1 too, which collapses the whole thing to weight × spend — because weight is maturity times reliability. Any other pair would have been a number invented against an imagined community. This one is a definition the chain already had.

Why a ballot has to cost something

Weight alone cannot decide a vote, and the reason is invisible until somebody counts. Maturity is the logarithm of an age, which is concave in one identity's history — so splitting into many identities multiplies it:

Who	Weight
One participant, one year old	24.9
One attacker, a hundred identities, thirty days old	2130

Eighty-five times the voice, for a hundred registration stakes and a hundred cheap servers run for a month. So the ballot needs a resource that is conserved when it is split, and there is only one: money. A hundred identities do not multiply a holding.

The spend goes to the treasury and does not come back. Voting again costs again — which is not a rule anybody added, but what linearity already says: a hundred votes of one Krumb are exactly one vote of a hundred. There is no record of who voted at all.

Which parameters, and why not the others

Parameter	Proposable	Why
`min_stake`	Yes	A threshold with no structural role
`leader_percent`, `committee_percent`	Yes	Shares of a pool that is emptied every block
`apprentice_percent`, `proposer_seats`	Yes	Change the next draw and nothing already written
`epoch_length`	No	Every future freeze boundary would move at once, and an epoch record's identity is a range of heights
`committee_target`	No	The quorum is ⌊2·C/3⌋+1 of it. A vote that moves the quorum is a vote about whether past certificates were enough
The treasury	No	Redirecting the residual claimant is a transfer of every fee the chain will ever collect, dressed as a parameter
The upgrade schedule	No	Only a crossed readiness threshold appends to it. A schedule a ballot could write is a ballot deciding what code exists

One rule draws the line: a parameter is proposable when a wrong value can be voted back. Everything in the top half fails safe — the chain keeps producing blocks under a bad number, and the same members can propose a better one.

There is no quorum, and there cannot be one

The readiness threshold has a denominator: the frozen set is bounded and known before the count begins. Governance has none. Power is weight times a spend and a spend is unbounded, so there is no “total possible power” for a percentage to be a percentage of. A participation quorum here would be a fraction of a number that does not exist.

So the whole rule is: more power for than against carries it, and no votes is not a pass. What stops something passing on one Krumb is that it stands in public for four epochs and anybody may spend one Krumb against it — the same argument as “not running the binary is your vote”.

What capture actually costs here.

Power is weight times spend, so an actor with a fortune and no registry entry has a weight of zero and a product of zero. And weight cannot be bought — it is the log of an age multiplied by a record of turning up. Moving a parameter means having been here, and having done the work, and being willing to spend.

The honest limit is the other side of that: this design resists manufactured identities and does not resist concentrated wealth. The two are opposite requirements and nothing satisfies both without knowing who people are, which this chain will not do.

Spending the treasury

From rule version 6 a proposal can also move money: an amount, a recipient, and the same four epochs in public that a parameter change stands for. Voting needs no change at all — a ballot names a proposal id and does not care what the proposal says, which is what keeping the tally on the leaf bought.

open one, then vote on it like any other

./baklava spend -to bkx1... -amount 250000000
./baklava vote  -proposal 133feafc... -spend 5000000

Or /spend from the console.

Only what it earned	A spend may not take the treasury below its `treasury_endowment`, a genesis parameter that no proposal can move. Everything above it arrived as a fee, a proposal price, a vote's spend or a released tranche.
Checked at the close, not at the open	Against the balance as it stands when the epoch closes. Two spends that each fit alone and not together are counted in id order and the second is discarded, not clamped — a ballot that passed for one number must never quietly enact a different one.
A bound on a vote is not a bound on a key	The rule stops governance and nothing else. If a key exists for the treasury address, one signature empties it and no vote takes part. That is why a mainnet treasury is derived and keyless — `SHA-256("baklava/treasury/v1")[:20]` — with the endowment at 0, because nothing a keyless treasury holds is principal.

What a proposal cannot do

It cannot change a rule	A vote cannot make code exist. A ballot passing “activate version 5” has not put version 5 in anybody's binary. That half is answered by the readiness signal, which counts a fact rather than a judgement — see Upgrades and readiness.
It cannot spend the endowment	A proposal can spend the treasury from rule version 6 — see below — but only what the treasury has earned. The endowment is a genesis number no vote reaches, and a mainnet treasury has no key either, so the spend rule is the only door.
It cannot change how voting works	The exponents are constants, not parameters. A majority that could set `b` to zero would delete reliability from the ballot with its first vote and keep the majority for ever.
The treasury cannot vote	It is the residual claimant of every fee and the holder of the genesis distribution. A treasury with a ballot is the chain's founder holding a permanent majority.

Rule version 4, beside the swap.

A rule version is a batch rather than a rule, and no chain had activated version 4 when this was written — so governance went in beside the swap rather than becoming a version of its own. The tally lives on the proposal's own leaf, which is the seventh kind in the third state table, so there is no new tree and no change to what state_root folds.

The reasoning in full, including why the tally is kept rather than computed and why the bounds are checked twice, is under Governance in the protocol document.