Real regeneration, counted straight off the chain

recipient: regen105g89nqllu33nend0ce5eup4zxn0d4kfld3mkk
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen174tvh2dty7vsvwn2cfsmkwq8tplqgr5fduvkkk
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1c4y3j05qx652rnxm5mg4yesqdkmhz2f63crj08
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1ceunjpth8nds7sfmfd9yjmh97vxmwqfy4e70qz
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1h5z08rzvrwt3pzdjc03upvuh2x0j3yskr2e95r
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1k4pe2gjahthx2zmrs9dchhv9wfkfg6aneg92ra
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1n3mhyp9fvcmuu8l0q8qvjy07x0rql8q4qlxrup
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1rh7v5zrzmqlqp5ttn2uxna0cp0yh4mwkx3fxev
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1snn4uhxh04gzpgk4l8naw3n6fu7ucwx3zfv0hn
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1wexza7kxc8qktxqcwrt65anwuxjw8pg0p3m5z6
amount: [{"denom":"uregen","amount":"36000000000"}]

recipient: regen1ypwzuhaffvr06ktu0ne6lnm69gxj32qwjg7u8l
amount: [{"denom":"uregen","amount":"36000000000"}]

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.

recipient: regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j
amount: [{"denom":"uregen","amount":"100000000000"}]

The second half of the program fund, and it can be voted on its own. The standing stream routes a share of community-pool inflow; this moves one bounded amount out of the pool BALANCE into a payout account that pays only against work that is settled on a public board and accepted by a human, at a rate this proposal states, and returns what it does not spend. THE NUMBERS, READ AT BUILD TIME: the pool holds 5,035,750 REGEN. The rate is 10,000 REGEN per accepted hour of verified stewardship work, the unit proposal #75 added to this registry as VSH. The board has 0 accepted hours settled to date across 0 settlements, and the program asks for a forward budget of 10 hours on top of that. 10 hours at 10,000 REGEN is 100,000 REGEN, which is inside the stated ceiling of 5.0% of the balance, so the ask is: 100,000 REGEN, 1.99% of the pool, funding up to 10 accepted hours. THE RATE IS A STARTING FIGURE AND I WILL NOT DRESS IT UP: the board has settled no hours-denominated work yet, so there is no settlement history to derive a rate from. 10,000 REGEN per hour is a stated governance number, chosen to be legible and conservative against a pool this size, and it changes only by a later vote. Nobody is paid a REGEN of this until an hour is worked, proven, and accepted. THE RECEIPT SHAPE: every payment out of the payout account carries, publicly and before the payment counts, the work packet it settles, the place it was done at, the hours claimed by the worker and accepted by the human who accepted them, the settlement transaction, and the content hash of the proof anchored on Regen's own x/data module. A payment without that record does not exist and cannot be counted against this tranche. The running total is published beside the pool balance, so the spend can be audited against the chain rather than against a report from the party spending it. RETURN OF UNSPENT: whatever is not paid against accepted hours within 365 days returns to the community pool with a /cosmos.protocolpool.v1.MsgFundCommunityPool from the payout account. The tranche is custody, not income: it buys nothing, it pre-pays nobody, and it is not a grant. MECHANICS: one standard /cosmos.protocolpool.v1.MsgCommunityPoolSpend, effective the moment it passes, no chain upgrade, no new module. The message type is the whole risk on this chain and it is deliberate: proposal #63 won 43,683,675 REGEN to 0 and still ended FAILED at execution, because it carried x/distribution's identically-named MsgCommunityPoolSpend while the balance sits in the x/protocolpool module account. This carries the protocolpool one, the module the 5,035,750 REGEN is actually in, and the shape was run against this chain in check mode before it was proposed. The one thing a passing vote cannot guarantee is a balance at execution time, so if the pool has fallen below the ask when this executes, the spend fails and nothing moves. WHAT THIS IS NOT: it is not a burn. The steward closed proposal #68 because it spent the pool on a burn; spending the pool on verified regeneration is the opposite of that, and this proposal is the first instance of it. DISCLOSURE: the proposer is the current Regen Tokenomics working-group steward, and the payout account regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j is the proposer's own address, the same identity that signed proposals #64, #66, #67, #72, #73, #74 and #75 from this chain. No new wallet was created for this. Stated plainly so the network can weigh it on the merits. CONFIRM WITHOUT TRUSTING ME: the pool balance is at /cosmos/protocolpool/v1/community_pool; the credit type is at /regen/ecocredit/v1/credit-types; the board's settled work and its accepted hours are at hxxps://vealth[.]net/labor/settled.