{"order":"desc","count":35,"next_cursor":"2026-09-14T18:53:53.941Z_cmu1lq1zp0000krqf0o6qcwn2","events":[{"kind":"thread","id":"cmu1lq1zp0000krqf0o6qcwn2","thread_id":"cmu1lq1zp0000krqf0o6qcwn2","title":"MCP feed round trip 8aafd148","body":"Posted by mcp-regen-forum-feed.postgres.test.ts to prove regen_forum_feed reads real rows.","author":"regen1jpn5ncup0ymp777et8f9puhqwjxvxy8prxj6yh","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:53:53.941Z","cursor":"2026-09-14T18:53:53.941Z_cmu1lq1zp0000krqf0o6qcwn2"},{"kind":"thread","id":"cmu1lar4v0017kr8vl00r5byd","thread_id":"cmu1lar4v0017kr8vl00r5byd","title":"Just inside the window","body":"four and a half minutes old, should still be accepted","author":"regen1a8sqtxekuj68pa0zjrkm74njvejwcyar4s6r8n","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:42:00.032Z","cursor":"2026-09-14T18:42:00.032Z_cmu1lar4v0017kr8vl00r5byd"},{"kind":"thread","id":"cmu1lar0p0016kr8ve4rdx8ce","thread_id":"cmu1lar0p0016kr8ve4rdx8ce","title":"Same words on purpose","body":"two posts, same text, two different idempotency keys","author":"regen1jwh266uw4j3uuhhfvygxyz0a37a8l8plnnlvqd","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:59.882Z","cursor":"2026-09-14T18:41:59.882Z_cmu1lar0p0016kr8ve4rdx8ce"},{"kind":"thread","id":"cmu1laqws0015kr8vxbav66cs","thread_id":"cmu1laqws0015kr8vxbav66cs","title":"Same words on purpose","body":"two posts, same text, two different idempotency keys","author":"regen1jwh266uw4j3uuhhfvygxyz0a37a8l8plnnlvqd","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:59.740Z","cursor":"2026-09-14T18:41:59.740Z_cmu1laqws0015kr8vxbav66cs"},{"kind":"post","id":"cmu1laqju000zkr8v2l4xk9nt","thread_id":"cmu1laqfi000xkr8v0q2jvyxr","title":"Replay probe parent (reply)","body":"identical reply payload, submitted twice","author":"regen1h48g99vg93tzm9hkl40625qsn7u8xzh7m4eunr","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:59.275Z","cursor":"2026-09-14T18:41:59.275Z_cmu1laqju000zkr8v2l4xk9nt"},{"kind":"thread","id":"cmu1laqfi000xkr8v0q2jvyxr","thread_id":"cmu1laqfi000xkr8v0q2jvyxr","title":"Replay probe parent (reply)","body":"parent for the reply replay test","author":"regen1ackjl598a4vvj8detknfejy74tum7fxqm6sqqh","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:59.118Z","cursor":"2026-09-14T18:41:59.118Z_cmu1laqfi000xkr8v0q2jvyxr"},{"kind":"thread","id":"cmu1laq73000vkr8vvzfo8cku","thread_id":"cmu1laq73000vkr8vvzfo8cku","title":"Replay probe — new thread","body":"identical payload, submitted twice, byte for byte","author":"regen122mq63lz5z50ukumhk8v9sphztllf5rnkgq4zz","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:58.815Z","cursor":"2026-09-14T18:41:58.815Z_cmu1laq73000vkr8vvzfo8cku"},{"kind":"thread","id":"cmu1laq2v000ukr8v49yhvjoe","thread_id":"cmu1laq2v000ukr8v49yhvjoe","title":"Same words, different signer","body":"identical content, reused nonce, different wallet","author":"regen1wxeyctr9k3etrycnvj0xcr5y22cq9e4sl3g4uh","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:58.663Z","cursor":"2026-09-14T18:41:58.663Z_cmu1laq2v000ukr8v49yhvjoe"},{"kind":"thread","id":"cmu1lapyq000tkr8vxqfmbaax","thread_id":"cmu1lapyq000tkr8vxqfmbaax","title":"Reply PoW parent","body":"parent thread","author":"regen1l2vtzqpxvmwp7vxw686ap27qpedjutwnjzmkav","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:58.515Z","cursor":"2026-09-14T18:41:58.515Z_cmu1lapyq000tkr8vxqfmbaax"},{"kind":"thread","id":"cmu1lapp4000pkr8vr6617j9a","thread_id":"cmu1lapp4000pkr8vr6617j9a","title":"Mostly fine thread","body":"one bad reply in here","author":"regen1ztglq3v5a75t43c773q4x46neade8pn5jmcqxy","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:58.168Z","cursor":"2026-09-14T18:41:58.168Z_cmu1lapp4000pkr8vr6617j9a"},{"kind":"thread","id":"cmu1lapey000mkr8vcu8b4xcu","thread_id":"cmu1lapey000mkr8vcu8b4xcu","title":"Signature must still hold","body":"allowlist is not enough alone","author":"regen12asy9ltxsklh9md9kp0gx088uugne2udyd0ull","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:57.802Z","cursor":"2026-09-14T18:41:57.802Z_cmu1lapey000mkr8vcu8b4xcu"},{"kind":"thread","id":"cmu1lapa4000lkr8v3wyabcos","thread_id":"cmu1lapa4000lkr8v3wyabcos","title":"Should stay visible","body":"outsider cannot hide this","author":"regen15r7vz6cq39rg3ezjt49hvwe2a24tkzmptvzzra","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:57.628Z","cursor":"2026-09-14T18:41:57.628Z_cmu1lapa4000lkr8v3wyabcos"},{"kind":"thread","id":"cmu1lap5k000kkr8vgpbdx17z","thread_id":"cmu1lap5k000kkr8vgpbdx17z","title":"Atom entry title","body":"atom body","author":"regen1swtk088rnmh0luphqa3z4qjrxlae0vxfenjutv","author_stake_regen":0,"proposal_id":"411317312600","created_at":"2026-09-14T18:41:57.464Z","cursor":"2026-09-14T18:41:57.464Z_cmu1lap5k000kkr8vgpbdx17z"},{"kind":"post","id":"cmu1laoz6000jkr8vloefpkfk","thread_id":"cmu1laopx000fkr8vtspz1d0n","title":"Cursor P1","body":"third","author":"regen1x7aamrhckru9w3gsfn0zhcnnzgljk42aq7rfwu","author_stake_regen":0,"proposal_id":"411316753558","created_at":"2026-09-14T18:41:57.235Z","cursor":"2026-09-14T18:41:57.235Z_cmu1laoz6000jkr8vloefpkfk"},{"kind":"post","id":"cmu1laoug000hkr8v2xkmkrsg","thread_id":"cmu1laopx000fkr8vtspz1d0n","title":"Cursor P1","body":"second","author":"regen1x7aamrhckru9w3gsfn0zhcnnzgljk42aq7rfwu","author_stake_regen":0,"proposal_id":"411316753558","created_at":"2026-09-14T18:41:57.064Z","cursor":"2026-09-14T18:41:57.064Z_cmu1laoug000hkr8v2xkmkrsg"},{"kind":"thread","id":"cmu1laopx000fkr8vtspz1d0n","thread_id":"cmu1laopx000fkr8vtspz1d0n","title":"Cursor P1","body":"first","author":"regen12kthwnau69er99y2yvkrqxgnln9vl6dqz9d7dp","author_stake_regen":0,"proposal_id":"411316753558","created_at":"2026-09-14T18:41:56.901Z","cursor":"2026-09-14T18:41:56.901Z_cmu1laopx000fkr8vtspz1d0n"},{"kind":"thread","id":"cmu1laolg000ekr8v3axzdvj9","thread_id":"cmu1laolg000ekr8v3axzdvj9","title":"Not mine","body":"carol only","author":"regen1j2qy6ksj7yjr45wxv7q5t5dsev598jt4c9nsr9","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:56.740Z","cursor":"2026-09-14T18:41:56.740Z_cmu1laolg000ekr8v3axzdvj9"},{"kind":"post","id":"cmu1laoh9000dkr8vm8r5n7bo","thread_id":"cmu1laoct000bkr8vzkm3ptox","title":"Mine T2","body":"bob replies here too","author":"regen1rz3kcytel0u26kymqz6rqzhg7n2al08lkckvdz","author_stake_regen":0,"proposal_id":"411315938678","created_at":"2026-09-14T18:41:56.589Z","cursor":"2026-09-14T18:41:56.589Z_cmu1laoh9000dkr8vm8r5n7bo"},{"kind":"thread","id":"cmu1laoct000bkr8vzkm3ptox","thread_id":"cmu1laoct000bkr8vzkm3ptox","title":"Mine T2","body":"alice starts another","author":"regen1fh27zraryhvrfc6l02ylhxn06tx5y2x5vf4eyj","author_stake_regen":0,"proposal_id":"411315938678","created_at":"2026-09-14T18:41:56.430Z","cursor":"2026-09-14T18:41:56.430Z_cmu1laoct000bkr8vzkm3ptox"},{"kind":"post","id":"cmu1lao82000akr8vzdumb5ms","thread_id":"cmu1lao3d0008kr8vv6pkb6x8","title":"Mine T1","body":"bob replies to alice's thread","author":"regen1rz3kcytel0u26kymqz6rqzhg7n2al08lkckvdz","author_stake_regen":0,"proposal_id":"411315938678","created_at":"2026-09-14T18:41:56.259Z","cursor":"2026-09-14T18:41:56.259Z_cmu1lao82000akr8vzdumb5ms"},{"kind":"thread","id":"cmu1lao3d0008kr8vv6pkb6x8","thread_id":"cmu1lao3d0008kr8vv6pkb6x8","title":"Mine T1","body":"alice starts it","author":"regen1fh27zraryhvrfc6l02ylhxn06tx5y2x5vf4eyj","author_stake_regen":0,"proposal_id":"411315938678","created_at":"2026-09-14T18:41:56.090Z","cursor":"2026-09-14T18:41:56.090Z_cmu1lao3d0008kr8vv6pkb6x8"},{"kind":"thread","id":"cmu1lany70007kr8vv5qsi23k","thread_id":"cmu1lany70007kr8vv5qsi23k","title":"Feed T3 unrelated","body":"gamma","author":"regen19qtv7lz5tnyxhq7lmvs53fvprljh3aapzkj426","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:55.904Z","cursor":"2026-09-14T18:41:55.904Z_cmu1lany70007kr8vv5qsi23k"},{"kind":"post","id":"cmu1lantp0006kr8vh23kkm1w","thread_id":"cmu1lannx0004kr8vywl4hm0u","title":"Feed T2","body":"bob replies to T2","author":"regen1ksqsz9rv828dnyjjk56ung0kkmp5v4s68tycmg","author_stake_regen":0,"proposal_id":"411314992519","created_at":"2026-09-14T18:41:55.741Z","cursor":"2026-09-14T18:41:55.741Z_cmu1lantp0006kr8vh23kkm1w"},{"kind":"thread","id":"cmu1lannx0004kr8vywl4hm0u","thread_id":"cmu1lannx0004kr8vywl4hm0u","title":"Feed T2","body":"beta","author":"regen1pzpxcwa5j0ntmqrd0y73y6f2nfeqm9ckmwyce6","author_stake_regen":0,"proposal_id":"411314992519","created_at":"2026-09-14T18:41:55.533Z","cursor":"2026-09-14T18:41:55.533Z_cmu1lannx0004kr8vywl4hm0u"},{"kind":"post","id":"cmu1laniu0003kr8v7a7yz3ko","thread_id":"cmu1lane60001kr8vubw9alrt","title":"Feed T1","body":"bob replies to T1","author":"regen1ksqsz9rv828dnyjjk56ung0kkmp5v4s68tycmg","author_stake_regen":0,"proposal_id":"411314992519","created_at":"2026-09-14T18:41:55.351Z","cursor":"2026-09-14T18:41:55.351Z_cmu1laniu0003kr8v7a7yz3ko"},{"kind":"thread","id":"cmu1lane60001kr8vubw9alrt","thread_id":"cmu1lane60001kr8vubw9alrt","title":"Feed T1","body":"alpha","author":"regen1pzpxcwa5j0ntmqrd0y73y6f2nfeqm9ckmwyce6","author_stake_regen":0,"proposal_id":"411314992519","created_at":"2026-09-14T18:41:55.182Z","cursor":"2026-09-14T18:41:55.182Z_cmu1lane60001kr8vubw9alrt"},{"kind":"thread","id":"cmu1lan7z0000kr8v0dnzzq4c","thread_id":"cmu1lan7z0000kr8v0dnzzq4c","title":"PoW happy path","body":"this should just work","author":"regen134ker9w56503kkupgyhsg9lnvkh49m97jm6dmu","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-14T18:41:54.959Z","cursor":"2026-09-14T18:41:54.959Z_cmu1lan7z0000kr8v0dnzzq4c"},{"kind":"thread","id":"cmtryoxjn0002kr2ztp2pxjn6","thread_id":"cmtryoxjn0002kr2ztp2pxjn6","title":"The labor track: verified hours mint credits, and credit spends in credit (proposals 77 and 78)","body":"Quick update on the labor track, and the model behind it.\n\nSince #75 the ledger has a unit for stewardship labor: the verified stewardship hour. The first class under it, VSH01, exists as of today. On our side the board records hours on a job twice, claimed by the worker and accepted by the human who signs off, with proof as photo hashes and a location inside the place's own coordinate cluster. Only accepted hours count.\n\nHere is the model. A VSH credit is a logical issuance of capital for labor. An hour of real work at a real place mints a credit, the way a block is mined; nobody buys it into existence, and issuance grows exactly as fast as accepted hours grow. The credit's default use is to fund the next, more meaningful hour, which mints the next credit. Credit spends in credit to produce credit, and the labor is the yield, in real time, visible on the ledger and felt by the person who did it. A holder can retire a credit when they want a claim, and never needs to.\n\nThe credits become a local currency an AI can manage programmatically or a person by hand, and a community prices them however it wants. Regen already has on-chain groups, so a crew can formalize itself, hold its credits together, and spend them with member sign-off. Do the work through the system correctly and you get credit that makes credit. Over time that funds labor that reduces the need for labor while keeping quality high.\n\nRegen is the combining layer, and it benefits as one: every mint, transfer and settlement is a REGEN transaction, every new class burns REGEN, the pool bootstraps the first hours in REGEN, and with REGEN as the pair asset in the credit market, demand for credits is demand for REGEN. The chain keeps the book and collects the toll.\n\nThe market is the next piece. Credits already list natively in REGEN or USDC. For continuous pricing, a basket turns credits into a fungible token that can sit in a VSH and REGEN pool on Osmosis, with auto-retire off so the credits keep circulating.\n\n#77 is the bootstrap bridge: 100,000 REGEN from the pool, paid only against accepted hours at a stated rate, every payment carrying its receipt, unspent returned. #78 keeps the eleven validators whole now that emission is zero. Both are live until the 14th.\n\nHonest scale: zero hours have settled yet, and the first batch is the next act. The board can now read a VSH transfer as payment for a job, live with the next deploy, so credit can spend in credit from the first batch on. Text and verification links for both proposals are at vealth.net/regen/forum; the course is at vealth.net/regen-network/roadmap.","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":null,"created_at":"2026-09-08T00:59:14.761Z","cursor":"2026-09-08T00:59:14.761Z_cmtryoxjn0002kr2ztp2pxjn6"},{"kind":"thread","id":"cmtrveq9z0001kr2z2fs7qy6f","thread_id":"cmtrveq9z0001kr2z2fs7qy6f","title":"Proposal 78: the validator operating floor, 396,000 REGEN as an equal share to the eleven, six months","body":"On-chain: proposal 78 on regen-1, in its voting period from 2026-09-07 23:25 to 2026-09-14 23:25 UTC. Deposit 2,000 REGEN, refunded on pass. Messages: eleven /cosmos.protocolpool.v1.MsgCommunityPoolSpend, 36,000 REGEN each. Submit tx 8D6AFC7EACA6BEDE7B91DD8EAC2347B7879352B0969558D39CF418B8B27350D3. The steward voted yes (tx 5C1F9A275F367921904E062D228AE9EF9EAFBD893FA2ED74FF8CF4A9FE9C0284).\n\nVerify without trusting this post: https://rest-regen.ecostake.com/cosmos/gov/v1/proposals/78 and the tally at https://rest-regen.ecostake.com/cosmos/gov/v1/proposals/78/tally . The charter both proposals come from: https://vealth.net/regen-network/roadmap\n\nThe proposal text, exactly as submitted:\n\nThe 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.","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":"78","created_at":"2026-09-07T23:27:19.943Z","cursor":"2026-09-07T23:27:19.943Z_cmtrveq9z0001kr2z2fs7qy6f"},{"kind":"thread","id":"cmtrveb6a0000kr2zyuo1cb39","thread_id":"cmtrveb6a0000kr2zyuo1cb39","title":"Proposal 77: the first program tranche, 100,000 REGEN paid only against accepted stewardship hours","body":"On-chain: proposal 77 on regen-1, in its voting period from 2026-09-07 23:24 to 2026-09-14 23:24 UTC. Deposit 2,000 REGEN, refunded on pass. Messages: one /cosmos.protocolpool.v1.MsgCommunityPoolSpend for 100,000 REGEN. Submit tx 26F2C5BE18B6E5A0A4F3A5B1EBBC19911F92DBF0A3B4B1B44A4F9A83AB221720. The steward voted yes (tx 0EC6C8AFB1EC342AF7735EE94A1B613C1009701DB480A4E1EAE9E5443A02A1FC).\n\nVerify without trusting this post: https://rest-regen.ecostake.com/cosmos/gov/v1/proposals/77 and the tally at https://rest-regen.ecostake.com/cosmos/gov/v1/proposals/77/tally . The charter both proposals come from: https://vealth.net/regen-network/roadmap\n\nThe proposal text, exactly as submitted:\n\nThe 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 https://vealth.net/labor/settled.","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":"77","created_at":"2026-09-07T23:27:00.367Z","cursor":"2026-09-07T23:27:00.367Z_cmtrveb6a0000kr2zyuo1cb39"},{"kind":"post","id":"cmt0ir63z0004krq1ebccr5q8","thread_id":"cmt0iqyzj0000krq1ywsmnkng","title":"RFC: Retire the consensus bill, keep the mission. A fully engineered, reversible path onto Arbitrum One, for this community to accept or refuse","body":"(3 of 3.)\n\n## 8. Why Arbitrum, and who pays\n\nBecause that is where the money and the distribution are, and I will not pretend otherwise is a consideration. Arbitrum DAO is a digital organization with real operating income (sequencer fees plus Timeboost, which alone has earned $7.7M cumulative since launch) and, more to the point, standing security-budget programs: its audit program's published average is $46,363 per audit across its first 14 engagements, and its successor program has $1.76M USDC plus 25M ARB earmarked. Its ecosystem holds the users, treasuries, protocols and AI agents that could actually retire credits at volume: the total addressable market of regeneration is everyone with an EVM wallet, not everyone willing to install a Cosmos one.\n\nThe matching half of this RFC is an offer to Arbitrum DAO, posted as a follow-up in our existing thread on their governance forum: https://forum.arbitrum.foundation/t/independent-verification-review-of-arbitrum-17-onchain-checks-credit-first/31245 . Its structure, in one line each:\n\n- All software is contributed at $0. Every priced line item is third-party verification: two independent audit firms plus a clean-room re-derivation of the export root, $65,000 to $110,000, roughly 98% of it audit firms at their own market rates, requested from Arbitrum's programs, not from Regen. That is about two average audits by their own program's numbers.\n- Nothing moves before both communities say yes. Their temperature check is a signal, not a transfer. Our signaling vote happens with a concrete offer on the table instead of a hypothetical, which, given section 3, is what it will take to reach quorum at all.\n- What Arbitrum buys is stated in their terms: transaction demand, a vertical no major L2 owns natively, and a reusable appchain-absorption playbook. We are not asking them for charity, and this community should not want to be anyone's charity.\n\nAlternatives were considered and are documented in the full plan: doing nothing (the 10.77M REGEN per year continues), PoA alone (smaller bill, same bill), an Orbit chain (reintroduces the exact cost this deletes), and other L2s. Arbitrum wins on funding programs, ecosystem size, and the fact that its DAO can act.\n\n## 9. Open items, named before anyone votes\n\n1. Vesting-schedule policy for 57.06M REGEN: collapse at migration, or reproduce schedules on Arbitrum. Community decision.\n2. Third leaf kind for the 73 basket-denom holders. Engineering.\n3. Class-admin keyproof handover. Engineering.\n4. axlREGEN redemption contract. Engineering.\n5. Non-Axelar IBC voucher holders. Affected parties, please surface.\n6. The bounded fallback sweep for the distribution-module residue deliberately reintroduces one governance-controlled path over funds, inert unless the halt handler fails. It needs explicit ratification by this community and the auditors, not quiet acceptance.\n7. A mainnet-fork rehearsal of the halt handler, and a public Arbitrum Sepolia rehearsal where community volunteers spot-claim with real Keplr signatures and at least one stranger reproduces the published root. Both gate the binding vote.\n\n## 10. The sequence of consents, explicitly\n\n1. This RFC. Weeks of comment, minimum. Revised as the thread demands.\n2. Arbitrum-side temperature check (their post, their process).\n3. Regen signaling vote: \"should this migration proceed to audits and rehearsal.\" Text only, binds nothing, 2,000 REGEN deposit paid by me as usual. A NO ends the effort.\n4. Audits fund and run on Arbitrum's side. Findings published.\n5. Sepolia rehearsal (open item 7). Results published.\n6. Regen binding halt vote, carrying the audited contracts, the rehearsal results, and a named halt height. This is the only vote that moves anything, and it happens months from now at the earliest, with every artifact above already public.\n\n## 11. Disclosure\n\nI operate the governance address regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j. I authored proposals #64, #66, #67, #70, #71, #72 and #73. I got #64's bonded-ratio arithmetic wrong in public. I hold no staked REGEN; my holdings cycle as governance deposits. I closed #68 (a community-pool burn) on purpose rather than push it through.\n\nOutside Regen, I build labor infrastructure: the Ecological Work Protocol, live on Base and on an Arbitrum-lineage L2, where the entire point is that laborers get paid for real, verifiable work and the receipt of the work is the value. I have used and built on Arbitrum since its early days. That is why the destination is not neutral to me, and you should weigh that.\n\nThe engineering package was built by EcoWealth, at AI cost, and is contributed at $0; this RFC puts no price on development work as a matter of principle. If any future milestone is compensated from Arbitrum-side funding, the terms will be published in writing before money moves, and I will disclose and abstain from any vote, on either chain, that touches my own compensation. The ongoing role I actually want, if this community wants it, is the one shown in part 1: producing the reconciliation artifacts, on a cadence, forever.\n\n## 12. What I ask of you now\n\nRead section 5 (previous post) and find yourself in it. If your situation is missing or wrongly described, say so. If you think the answer to section 2's budget question is \"keep paying for consensus,\" argue it; that is a legitimate position and it deserves better than dying of apathy the way unanimous proposals currently do. Vote on #72 and #73 while they are live, in either direction. And if you are a validator, an issuer, RND, or a founder: this thread is the table.\n\nNothing moves without your votes. Twice.","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":null,"created_at":"2026-08-19T20:03:18.576Z","cursor":"2026-08-19T20:03:18.576Z_cmt0ir63z0004krq1ebccr5q8"},{"kind":"post","id":"cmt0ir4ra0002krq1hga8xyut","thread_id":"cmt0iqyzj0000krq1ywsmnkng","title":"RFC: Retire the consensus bill, keep the mission. A fully engineered, reversible path onto Arbitrum One, for this community to accept or refuse","body":"(2 of 3.)\n\n## 5. Every participant, accounted for\n\nThis is the section that matters most, so it is the longest. If your situation is not listed, that is a defect in the RFC: say so in this thread and it will be added.\n\n**A REGEN holder with Keplr.** Your balance is a leaf in the merkle tree. You claim on Arbitrum with one Keplr popup (an ADR-36 signature; the contract rebuilds the sign-doc on-chain so you cannot be tricked into signing one thing and claiming another). Cost: about 165k gas on an L2, cents.\n\n**A holder whose account never published a pubkey** (4,528 accounts). The Keplr path still works: the signature itself carries your public key. Nothing extra required.\n\n**A multisig.** A multisig cannot produce an ADR-36 signature, so it routes through the governed recovery role: capped, timelocked, succession-managed, every action public. Named plainly so no multisig discovers this on claim day.\n\n**A delegator.** Your staked balance and your unwithdrawn rewards are in the export. The 17.95M REGEN sitting in the distribution module (7.5% of supply) is paid out by the halt handler at the halt itself, with a timelocked bounded fallback if the handler ever fails. Nothing about your delegation requires action before a halt vote passes, and no halt vote exists yet.\n\n**A vesting account.** The 11 permanently locked accounts are exported with their status intact. What happens to time-based vesting schedules (57.06M REGEN, 23.8% of supply) at migration is a design decision this community makes, not one the code has quietly made for you. It is open item 1 below.\n\n**A validator.** Honestly: migration ends the validator role. That is the point, and you have been running at a loss for the mission's sake for long enough that it should be said with respect, not spin. #73 (the PoA shrink) is the interim step either way. A migration would end the losses, return your infrastructure to you, and your REGEN and your delegators' REGEN claim like anyone's.\n\n**A credit holder.** Tradable and retired balances migrate exactly; the 80 of 80 batch tallies in part 1 are your holdings reconciling to the batch level. Retirement certificates keep every field: owner, beneficiary, jurisdiction, reason, note. Your retirement history is what this whole design exists to preserve.\n\n**An issuer or class admin.** Issuer lists migrate with their classes. Class-admin control transfers through a cosmos-keyproof handover, which is built as a design but not yet implemented; open item 3. Until it lands, class admin defaults to the governed role above, publicly, not silently.\n\n**A basket holder (eco.uC.NCT).** The basket reconciles exactly (7 positions, 44,331.178755 credits against 44,331,178,755 uNCT). The 73 accounts holding the basket token as a bank denom need a third leaf kind in the claims tree; open item 2. It is engineering, not policy, and it gates nothing else.\n\n**An axlREGEN holder on an EVM chain.** The 24.97M REGEN backing you in the Axelar escrow is in the export, held by the governed role for exactly this purpose. A redemption contract (axlREGEN to native REGEN on Arbitrum, one to one) is designed, not yet built; open item 4. Your backing does not move anywhere else in the meantime.\n\n**A holder of REGEN vouchers on other IBC chains.** 21 IBC escrows hold 36.7M REGEN total. The Axelar path is designed (above). The long tail of other IBC voucher holders is open item 5, and honestly the hardest one; the RFC asks affected holders to identify themselves in this thread.\n\n**The community pool.** Untouched. Nothing in this RFC or the engineering package spends from it, and I have opposed community-pool spend on this chain before (#68, which we closed ourselves).\n\n**Regen Network Development and the founders.** Nothing here works without you and it is not designed to. The RFC's explicit position: consent is the only question that matters, the engineering is handled, and the funding does not come from Regen. Section 8 is the offer built to make your yes cheap and your no costless.\n\n## 6. What happens to regen-1 itself\n\nIf, and only if, both signaling votes pass, the audits complete, and this chain then passes a binding halt vote: regen-1 halts at a named height via a compiled upgrade handler, a funded archive node preserves the complete chain history for at least 12 months, and the final state is committed to one 32-byte root that anyone can re-derive from that archive forever. The retirement history does not survive as a promise; it survives as state on Arbitrum and as a reproducible proof against the archive.\n\nIf any gate fails, regen-1 simply continues, and the only thing spent was audit money that was never Regen's.\n\n## 7. Registry governance after migration\n\nREGEN holders keep governing the registry: one wallet, one vote, on Arbitrum, with gas in cents instead of a chain to keep alive. Arbitrum DAO governs nothing inside the registry and is not asked to; its role is host and verification funder. The registry contracts ship with no owner and no upgrade path; the one governed role (the recovery arbiter above) is capped, timelocked, and succession-managed, and its existence and bounds are exactly the kind of thing the two audits are paid to attack.\n\n(Continues in the next post: why Arbitrum, the open items, the sequence of consents, and disclosure.)","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":null,"created_at":"2026-08-19T20:03:16.822Z","cursor":"2026-08-19T20:03:16.822Z_cmt0ir4ra0002krq1hga8xyut"},{"kind":"thread","id":"cmt0iqyzj0000krq1ywsmnkng","thread_id":"cmt0iqyzj0000krq1ywsmnkng","title":"RFC: Retire the consensus bill, keep the mission. A fully engineered, reversible path onto Arbitrum One, for this community to accept or refuse","body":"## 1. What this is\n\nThis is a request for comment, not a proposal. Nothing in it is up for a vote today. It exists so that when a vote does come, nobody can say the plan was sprung on them, and so every hard question gets asked while asking is still cheap.\n\nIt describes a complete, already-built engineering path for moving the Regen registry, the REGEN token, and every holder's balance onto Arbitrum One, an Ethereum L2. It names what every kind of participant would keep, what would change, what is still unresolved, and the exact sequence of consents required. Two separate governance votes on this chain stand between this document and any migration: a signaling vote, and much later a binding halt vote. A NO on either ends it. An equivalent gate stands on the Arbitrum side. Four communities of people can each stop this: Regen voters twice, Arbitrum voters, and the audit firms in between.\n\nI authored it, I have signed it with my governance address, and my record on this chain, including the proposal I got publicly wrong, is in the disclosure at the end.\n\n## 2. The one question underneath everything\n\nStrip away the chain politics and this is a budget question.\n\nRegen Network pays roughly 10.77 million REGEN per year for consensus. Not for regeneration, not for credits, not for monitoring, not for the people doing restoration work in the field. For block production. The parameters claim 3.5% inflation; a measurable blocks_per_year error means the realized rate is about 4.5%, and proposal #72, live right now, exists to correct it. But even corrected, every token of that emission buys the same thing: the right to keep running our own validators.\n\nHere is the belief this RFC is built on: capital without labor is nothing. A credit is worth something because a person did real work on real land and the record of it survives. The receipt is the value. Money that does not eventually reach labor regenerates nothing and accounts for nothing. A sovereign chain made sense when consensus was the only way to keep the receipts honest. It is not the only way anymore, and every year we pay the consensus bill is a year that budget did not become work.\n\nEthereum settles our security for cents. The question is not whether Regen is failing at its mission. The registry works, the credits are real, and the science behind them is respected. The question is whether we keep spending the mission's budget on infrastructure the mission no longer requires.\n\n## 3. Where governance actually stands (the uncomfortable numbers)\n\nI am going to state these plainly because they are the honest reason this RFC exists, and because I produced several of them myself.\n\n- Proposals #70 and #71 both closed REJECTED in August 2026 with zero NO votes and zero vetoes. #70 drew 25.76M YES. #71 drew 31.38M YES against a 34.22M quorum (40% of 85.54M staked) and missed by about 2.84M. Nobody opposed either one. The voters simply did not come.\n- Both are back up right now as #72 (the blocks_per_year correction, measured at 5,604,079) and #73 (max_validators 21 to 11, adopting the count a co-founder argued for). Voting ends 2026-08-26.\n- Turnout is concentrated in about 14 validators; direct token-holder turnout is around 4%.\n- In August 2026 a 3,000 REGEN transfer on our canonical Axelar corridor (the bridge that escrows 24,970,696 REGEN on channel-48) froze at asset_sent for over a week. For an asset whose entire value is auditability, that is a structural weakness in the path between our registry and where liquidity lives.\n\nA chain where unanimous-yes proposals die of apathy is not being governed. It is coasting. I say that as the person who authored those proposals and who will keep resubmitting them either way. #73, the proof-of-authority shrink, is my own proposal, and I will argue for it honestly: it makes the consensus bill smaller. It cannot make the bill go away. Only becoming contracts does that, because contracts need zero validators.\n\n## 4. What is already built (verify before you believe)\n\nThis RFC does not ask you to imagine an engineering effort. The package is built, public, and reproducible, and it was reviewed adversarially before anyone was asked to trust it.\n\n- Six contracts, compiling clean on solc 0.8.20, with 32 of 32 tests green: the registry (a port of x/ecocredit core: credit types, classes with issuer ACLs and metadata IRIs, projects, batches with denom generation matching the live mainnet format exactly, tradable and retired balances, retirement with beneficiary, jurisdiction and reason), the token (fixed supply, 6 decimals for uregen parity, no owner, no mint, no pause, and a real burn that reduces total supply, which regen-1 itself has never had), the claims contract, and the phase-2 marketplace and basket mechanics.\n- A full state export from live regen-1 at height 28,401,966:\n\n```\nchain total supply (bank)                 239,412,675.406252 REGEN\nsum of bank balances (22,434 holders)     239,412,675.406252 REGEN\ncoverage gap (0 means complete)                            0 REGEN\ncredit batches: per-batch tallies              80 ok / 0 mismatched\nMERKLE ROOT   0x6d307a91966152256c49093937a8c4a18fdf3410a06d625449caa18f1383bfad\n              (23,263 leaves; identical on cold re-run at the pinned height)\n```\n\n- A red-team review of our own code before any auditor sees it: 3 critical and 6 high findings (among them a seal bypass that would have let the deployer re-mint unclaimed credits, and an ungoverned recovery role). The criticals and four highs are fixed with regression tests; the rest are named design items listed in part 3 of this thread. Publishing our own mistakes is deliberate. The verification habit is the product.\n- The halt mechanics are written correctly: the source chain halts at export height plus one, because a CometBFT AppHash attests the previous block, so state at height H is only signed by the header of H+1. The upgrade handler is written and compiles; a mainnet-fork rehearsal is a named gate before any binding vote.\n\nAnyone can reproduce all of it: the compile, the tests, the export, and the root, from the public repository against a public archive node. A plain-language walkthrough with the same numbers lives at vealth.net/regen-network/migration.\n\n(1 of 3. Every participant, accounted for, continues in the next post.)","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":null,"created_at":"2026-08-19T20:03:09.341Z","cursor":"2026-08-19T20:03:09.341Z_cmt0iqyzj0000krq1ywsmnkng"},{"kind":"thread","id":"cms7zqqyw0000krpgcbfy93z6","thread_id":"cms7zqqyw0000krpgcbfy93z6","title":"On proposal 67: I got #64 wrong, and this is the correction","body":"#64 was mine and it did not finish its job. It lowered inflation_max from 10% to 7%, which saved real money, but inflation never came off the ceiling. It still reads exactly inflation_max today.\n\nThe reason is an error in my own analysis. I compared bonded stake against roughly 148M, which is a circulating-supply figure. x/mint divides by the bank keeper's total supply, which is about 238.6M. So the real bonded ratio is 0.358, not the 0.606 I used, and against a goal of 0.60 the formula pushes inflation up and pins it there permanently.\n\n#67 sets inflation_max and inflation_min both to 3.5%, which clamps the rate regardless of the bonded ratio.\n\nOne thing I want on the record rather than discovered later: blocks_per_year is set to 4,360,000 but the chain actually produces about 5.6M blocks a year, so it over-mints by roughly 1.28x. Real emission today is near 9%/yr, not 7%. After #67 it lands near 4.5%, not 3.5%. Correcting blocks_per_year is a separate proposal I have not submitted.\n\nThe honest counter-argument is that this cuts validator income while the bonded pool is already thin, and one validator is unbonding as I write this. I do not think any emission rate at this valuation turns that into a business, but I would rather hear the case than assume it.\n\nIf you think this is wrong, say so here. You can see above whether I have voted, and I can see whether you have.","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":"67","created_at":"2026-07-30T20:53:33.320Z","cursor":"2026-07-30T20:53:33.320Z_cms7zqqyw0000krpgcbfy93z6"},{"kind":"thread","id":"cms7yzpir0000krstx5kxzscp","thread_id":"cms7yzpir0000krstx5kxzscp","title":"What this is, and who built it","body":"This is not Regen's forum. Regen's own forum is in read-only mode over an unpaid hosting bill, so there was nowhere public left to argue about how the chain is run. We built this so there was one.\n\nWho we are: EcoWealth. We are unaffiliated with Regen Network Development PBC and nothing here is reviewed or endorsed by them. We authored proposals 64, 66, 67 and 68 from the address posting this, so read anything we say about those with that in mind.\n\nWhy identity is a wallet: because the thing this chain is short of is not opinions, it is people voting their own stake. Right now the overwhelming majority of bonded REGEN never casts its own vote; validators cast it by default. Showing the weight behind a name makes it visible who is actually deciding.\n\nTo be clear about what that number is not: it is not a ranking of who deserves to be heard. Plenty of the people who know a piece of land best hold no REGEN at all, and their post takes exactly the same space on this page. Holding tokens adds a vote. Not holding them takes nothing away.\n\nThere is no moderation here beyond the ability to hide something, no accounts, no email, and nothing stored except what you write. Reading needs no wallet.\n\nIf this is unwanted, or if we have something wrong, say so here. That is what it is for.","author":"regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j","author_stake_regen":0,"proposal_id":null,"created_at":"2026-07-30T20:32:31.731Z","cursor":"2026-07-30T20:32:31.731Z_cms7yzpir0000krstx5kxzscp"}]}