The validator operating floor: 396,000 REGEN from the community pool, an equal share to the 11 bonded validators, 6 months

Original Proposal Text

The 11 validators who secure this chain run at a loss. Proposal #74 took emission to zero, so nothing on Regen Ledger is paid by new coins any more, and the chain upgrade that will route registry fees to them is not written yet. This is the bridge between those two facts: one bounded payment out of the community pool, divided equally, covering 6 months. THE NUMBERS, READ AT BUILD TIME: the pool holds 5,035,750 REGEN. The stated floor is 6,000 REGEN per validator per month. 11 validators for 6 months at that figure is 396,000 REGEN, which is inside the stated ceiling of 10.0% of the balance, so the ask is: 396,000 REGEN, 7.86% of the pool. Each validator receives exactly 36,000 REGEN, an effective 6,000 REGEN a month. The amounts are identical to the uregen; equality here is arithmetic, not a promise. WHY THIS IS A SPEND AND NOT A STREAM: the instrument that looks built for this job is x/protocolpool's MsgCreateContinuousFund, and it even carries an optional expiry. It was not used, and the reason is a measurement rather than a preference. A continuous fund pays a percentage of the pool's INFLOW, and since #74 that inflow is the community tax on gas alone. That is not a guess. Over the 20,000 blocks between heights 28,693,367 and 28,713,367, every one of them after emission stopped, 0.121846 REGEN reached x/protocolpool, which annualises at the chain's live blocks_per_year to about 34 REGEN a year. The #66 burn fund took 14.95% of it against its configured 15.00%, which is the mechanism confirming itself rather than my arithmetic. A continuous fund taking ALL of that inflow would pay each of the 11 validators about 3.1 REGEN a year. That is a gesture, not a floor. The pool's 5,035,750 REGEN sits in the BALANCE, and MsgCommunityPoolSpend is the only message that reaches it. THE TWO SHAPES, AND WHY THIS ONE: an equal share can be paid as one message per validator, or as one message into a payout account that divides the money afterwards. This proposal carries 11 messages, one per validator. The case for the 11-message shape is that it needs no trusted middle. Equality is in the proposal's own bytes, checkable before the vote rather than after it. Governance executes a proposal's messages in a single transaction, so it is all of them or none. And this chain has no trustless splitter available: CosmWasm code upload on regen-1 is restricted to the governance authority itself, so a splitting contract would need its own prior vote, which means a payout account here can only be somebody's wallet. The honest case AGAINST it is that the recipients are fixed at draft time, so if the bonded set changes between the draft and execution the money follows the old list. The answer is that the set below is stated as of this draft and a change to it is a re-draft, not a discretionary substitution. WHAT "UNTIL THE UPGRADE" CAN AND CANNOT MEAN: no message on this chain expires on an event. MsgCreateContinuousFund's expiry is a wall-clock timestamp, not a condition, and a one-off spend has nothing to expire because it completes when it executes. So this floor is bounded by the only things that are real: the amount is fixed at the vote, it covers a stated 6 months, and NOTHING RENEWS IT WITHOUT ANOTHER VOTE. It expires by default. That is why the period is short rather than a year: asking for one bridge period at a time is what makes "until the upgrade" enforceable instead of aspirational. If the upgrade lands early, or a validator leaves the active set inside the period, the unearned remainder is expected back in the pool by MsgFundCommunityPool. Say plainly what that is: a commitment in this text, not something the chain makes anyone do. THE FLOOR IS A STATED FIGURE AND I WILL NOT DRESS IT UP: 6,000 REGEN a month is a governance number, not a measured cost. The roadmap asks the validators to state their monthly infrastructure cost so the floor can be sized to it, and they have not stated it yet. At what REGEN trades for today this contributes toward a server bill and does not cover a salary. It is what the pool can pay without becoming the pool's only act, and it is the instrument the upgrade's fee router later fills. The figure is in REGEN and not in dollars on purpose: a dollar rate would put a live price feed inside a governance proposal. When the cost lines arrive, this figure is what a later vote moves. THE RECIPIENTS, READ LIVE FROM THE CHAIN AT DRAFT TIME (bonded set, 11 validators): polkachu.com regen105g89nqllu33nend0ce5eup4zxn0d4kfld3mkk; Regenerator regen174tvh2dty7vsvwn2cfsmkwq8tplqgr5fduvkkk; ECO Stake 🌱 | REStake.app regen1c4y3j05qx652rnxm5mg4yesqdkmhz2f63crj08; Simply Staking regen1ceunjpth8nds7sfmfd9yjmh97vxmwqfy4e70qz; Vitwit (Previously Witval) regen1h5z08rzvrwt3pzdjc03upvuh2x0j3yskr2e95r; Alex (Bambarello) Validator regen1k4pe2gjahthx2zmrs9dchhv9wfkfg6aneg92ra; 0base.vc regen1n3mhyp9fvcmuu8l0q8qvjy07x0rql8q4qlxrup; ecoBridge.earth regen1rh7v5zrzmqlqp5ttn2uxna0cp0yh4mwkx3fxev; Chainflow regen1snn4uhxh04gzpgk4l8naw3n6fu7ucwx3zfv0hn; Earthist regen1wexza7kxc8qktxqcwrt65anwuxjw8pg0p3m5z6; KalpaTech regen1ypwzuhaffvr06ktu0ne6lnm69gxj32qwjg7u8l. Each account address is the same twenty bytes as that validator's operator address under the account prefix, so anyone can re-derive this list from /cosmos/staking/v1beta1/validators and check it against the messages. MECHANICS: standard /cosmos.protocolpool.v1.MsgCommunityPoolSpend, effective the moment it passes, no chain upgrade and no new module. The message type is the whole execution risk on this chain and it is deliberate: proposal #63 won 43,683,675 REGEN to 0 and still ended FAILED, because it carried x/distribution's identically named MsgCommunityPoolSpend while the balance sits in the x/protocolpool module account. What a passing vote cannot guarantee is a balance at execution time, so if the pool has fallen below the ask by then the spend fails and nothing moves. DISCLOSURE: the proposer is the current Regen Tokenomics working-group steward, is not a validator, and receives nothing from this proposal. Continues the contributor work behind proposals #64, #66, #67, #72, #73, #74 and #75. CONFIRM WITHOUT TRUSTING ME: the bonded set is at /cosmos/staking/v1beta1/validators?status=BOND_STATUS_BONDED; the pool balance is at /cosmos/protocolpool/v1/community_pool; emission is at /cosmos/mint/v1beta1/params and /cosmos/mint/v1beta1/annual_provisions; the existing continuous fund and its share are at /cosmos/protocolpool/v1/continuous_funds. Every figure above came from those endpoints when this was drafted. More details: https://vealth.net/regen-network/roadmap