Digital stewardship: pay verified digital work for Regen by the hour, each hour accepted by a governance vote

I’m putting up a text proposal to adopt a digital stewardship authority.

By itself, it pays nobody. It sets the rules under which digital work for this chain — protocol and tooling work, on-chain operations run hard and fast with AI, x/data and registry tooling, validator and RPC stewardship, and coordination infrastructure — can be paid from the community pool, one accepted hour at a time.

How an hour gets paid

  1. Before starting, the worker signs the authority’s offer for a posted digital job.
  2. They do the work and publish the evidence: start and end, hours, what now exists and where to check it, and the compute used.
  3. The evidence hash is anchored on Regen x/data.
  4. A monthly acceptance proposal names the work, the hours, and the evidence, and carries one community-pool spend for the hours times the rate.
  5. If the network passes it, the chain pays and VSH credits are issued for exactly those hours, once.

The numbers

  • 5,000 REGEN per accepted hour
  • At most 10 hours / 50,000 REGEN per 30 days
  • Effective for 180 days, then it lapses unless a new vote renews it
  • Lifetime ceiling: 60 hours / 300,000 REGEN

Nothing leaves the pool until a vote accepts specific hours, and voters can reject any hour by voting the acceptance down.

Disclosure

I’m the working-group steward proposing it, and the first hours expected under it are my own digital work for this chain, paid to the steward account if the network accepts them.

That account holds no bonded REGEN, so the vote that accepts those hours is the rest of the network’s.

This does not touch proposal 77, which stays with physical stewardship hours.

Authority hash

The full authority document is below.

The proposal names its hash: sort the keys, write compact JSON, sha256. Anyone can check it:

python3 -c “import json,hashlib,sys; c=lambda v: [c(x) for x in v] if isinstance(v,list) else ({k:c(v[k]) for k in sorted(v)} if isinstance(v,dict) else v); print(hashlib.sha256(json.dumps(c(json.load(sys.stdin)),separators=(‘,’,‘:’),ensure_ascii=False).encode()).hexdigest())” < authority.json

Expected:

5fea111040bec7605079627059d1561f59dda8c91c2e7cc7269c89f7f457ca0a

{

“schema”: “vealth-digital-stewardship-authority/v1”,

“authorityId”: “vealth-digital-stewardship-authority-1”,

“version”: “0.2.0”,

“title”: “Digital Stewardship Funding Authority: digital hours accepted and paid by a Regen governance vote”,

“relationToProposal77”: “separate_authority_proposal_77_does_not_pay_digital_work”,

“scope”: {

"eligibleWorkClasses": \[

  "protocol_implementation_hardening",

  "machine_readable_work_provisioning",

  "evidence_verification_infrastructure",

  "regen_ledger_xdata_tooling",

  "validator_rpc_stewardship",

  "project_integration",

  "coordination_infrastructure",

  "safety_readiness_infrastructure",

  "other_digital_public_ecological_infrastructure"

\],

"workTypeClasses": {

  "digital_devops_ai_labor_provisioning": "protocol_implementation_hardening"

},

"durableCapabilityRequired": true,

"groundwardBindingRequired": true

},

“parameters”: {

"fundingSource": {

  "state": "decided",

  "value": {

    "kind": "regen_community_pool_spend",

    "custodyAccount": "regen1purnwdrhg477r0evks8t5ah7c8thvrssaxmfm8",

    "denom": "uregen"

  }

},

"rate": {

  "state": "decided",

  "value": {

    "uregenPerAcceptedHour": "5000000000"

  }

},

"tranche": {

  "state": "decided",

  "value": {

    "capUregenPerPeriod": "50000000000",

    "periodDays": 30,

    "rollover": "none"

  }

},

"effectivePeriod": {

  "state": "decided",

  "value": {

    "from": "adoption",

    "days": 180

  }

},

"maxPayableHours": {

  "state": "decided",

  "value": {

    "perPacket": "10",

    "perWorkerPerPeriod": "10",

    "perPeriod": "10"

  }

},

"unspentFunds": {

  "state": "decided",

  "value": {

    "disposition": "never leaves the Regen community pool: only a passed acceptance proposal spends, and only the hours it accepts"

  }

},

"amendmentRenewalTermination": {

  "state": "decided",

  "value": {

    "amendBy": "a Regen governance proposal naming the new body hash",

    "renewBy": "a Regen governance proposal naming the new body hash",

    "terminateBy": "a Regen governance proposal",

    "reviewEveryDays": 30

  }

},

"adoptionInstrument": {

  "state": "decided",

  "value": {

    "kind": "regen_governance_proposal"

  }

},

"acceptance": {

  "state": "decided",

  "value": {

    "kind": "regen_governance_proposal",

    "proposalsPerPeriod": 1,

    "stewardPayout": "regen1jfheyvsah5wqfyawmedme43te056z8gzdnpf3j"

  }

}

},

“rules”: {

"unit": "one_independently_accepted_accountable_human_hour_is_one_vsh",

"computeMultipliesHours": false,

"participation": "open_to_every_eligible_worker_on_the_same_published_terms",

"founderEligibleAsWorker": true,

"founderSelfAcceptance": "forbidden",

"workerConflicts": \[

  "worker_is_packet_creator",

  "worker_is_house_wallet",

  "payout_to_custody_account"

\],

"acceptorConflicts": \[

  "acceptor_is_worker",

  "acceptor_is_packet_creator",

  "acceptor_is_house_wallet",

  "acceptor_is_payer"

\],

"evidence": \[

  "worker_identity_bound",

  "worker_signed_this_authority_offer_before_work",

  "hours_claimed_with_start_and_end",

  "compute_inputs_attributed_once_with_source_refs",

  "durable_capability_with_evidence_refs",

  "groundward_binding",

  "canonical_accepted_evidence_commitment",

  "outside_human_acceptance_bound_to_event_completion_and_hours"

\],

"xdata": "exact_accepted_evidence_commitment_anchored_on_regen_x_data_before_payment",

"duplicateCompensation": "refuse_when_the_same_hours_are_paid_elsewhere_or_not_declared",

"rejection": "acceptor_may_reject_or_reduce_hours_accepted_never_exceeds_claimed_rejection_pays_nothing",

"settlementReplay": \[

  "one_settlement_per_completion",

  "payment_tx_verified_before_settlement",

  "unknown_replay_state_refuses"

\],

"vshIssuance": "exactly_hours_accepted_after_settlement_never_before",

"publicReceipt": "worker_acceptor_and_payer_roles_visible_on_the_receipt"

}

}

1 Like

Brandon, thank you for the revenue map. I read the whole thing this morning, and I want to reply properly here rather than with a thumbs-up in the chat.

First, the plain part. RND won’t be casting a vote on #80 or #81 before they close. That isn’t a No on either one. We just got back from Climate Week with a lot moving at once, much of it complementary to what you’re building, and a week hasn’t been enough time for us to take in a vision this size and also get our own review and voting-safety steps in order before we sign anything on chain. I’m sorry we aren’t moving as quickly as you are, or as quickly as I’d like us to. If other validators want to see these pass, the tallies are public and there’s still time.

Second, the part I actually care about. The stewardship unit is unusual, powerful thinking, and I’m excited about it. Framing verified hours as the proof layer for money that is already earmarked (grant reporting, bond impact reports, forward commitments), instead of inventing another outcome credit and hoping a market shows up, is the right instinct. The rule you keep coming back to is the right one too: a person accepts, the ledger records, and nothing is claimed beyond the record. It lines up closely with what we’ve been working toward on the claims side, where evidence gets attested by an accountable person and becomes a record anyone can check. The open schema work for that lives in GitHub - regen-network/regen-data-standards · GitHub, and I’d like to see where your hour records and those claim structures can meet.

On retiring the first VSH credits: our inclination is yes. I’d like us to get there together once the first hours are accepted. What I can’t do this week is give it the review it deserves, so treat this as a real yes-in-principle and not as a promise of when.

A few things we can answer now:

  • Your ledger figures check out. We re-read the chain today, and classes (14), projects (188), batches (80), sell orders (43) and the community pool all match what you have. One note: the “issued” total counts cancelled credits, so issued net of cancellations is lower. Worth agreeing on one definition before either of us quotes it.
  • Creating a credit class on chain is open right now: the allowlist is off and the fee is 5,000 REGEN, which is what VSH01 paid. Registry methodology review is a separate track, with its own stages and peer review, described at Protocol Review Process | Regen Registry Handbook. They’re different things, and it helps to keep them distinct when we talk to buyers.
  • You’re right about upgrades. v7.3.0 deserved a public thread before, during and after, and it didn’t get one. We owe a proper write-up of what happened, and a thread for every upgrade from here on, whatever happens with #80.

The rest of your questions (who leads the next upgrade and where fee routing stands, marketplace fees, Regen Compute’s numbers, the sell orders and retirement growth, which of the funding pools we’re talking to, and the route and timing for the LiquidityDAO pilot) deserve real answers, not quick ones. I’ll answer them in writing in this thread by the end of next week, Friday October 9.

And I’d love a catch-up. You said no call is needed, and that’s fair; the written reply is coming either way. But I’d value an hour to understand the pilot from you directly, and to talk about how we make it easier for stewards like you to not be doing this alone.

2 Likes

Brandon, here are the written answers I promised for today. Some of these I can answer solidly. For the rest, the honest answer is that I don’t know yet, or that it’s something we should work out together, and I’d rather say that than hand you numbers or dates that won’t hold. Thanks again for making time with Dave and me on Tuesday.

**Who leads the next upgrade, and when fee routing ships.** Chain upgrades are still prepared by RND engineering. Who coordinates the next one, and who owns chain comms with a backup (your ask in the v7.3.0 thread), isn’t settled yet, and I don’t want to name anyone before they’ve said yes. You offered to take that on if it’s recognized as work. I’d like to work that role out with you. The thread-per-upgrade commitment from my last post stands, and the v7.3.0 write-up is still owed.

On fee routing, nothing on chain today sends marketplace or activity fees to validators. Inflation is zero and the community tax is 17%, so validators get 83% of transaction fees and the pool gets 17%. Module-level fee routing (M013) needs a later chain upgrade and it isn’t scheduled. Your RFC on the split (agentic-tokenomics PR #111) is the live proposal for the parameters, and it still has no sponsor. I don’t have a date for you. Finding a sponsor and a build path is a good thing for us to work on together.

**Marketplace fees.** We got to the same place you did. There’s no public query for the marketplace fee parameters, the marketplace fee pool account is empty, and as far as we can tell no governance proposal has ever set them (only governance can). From the code, a buyer fee is added on top of the price and a seller fee comes out of the proceeds. Both go to the fee pool, and fees paid in REGEN are burned. What I don’t know yet is the stored values. Getting them means reading the node’s state directly, and I’d rather post that here than guess. The fees we can confirm are 5,000 REGEN to create a credit class and 1,000 REGEN to create a basket (the basket fee is burned).

**Regen Compute.** It retires on a monthly subscription cycle, not per inference, so a per-day number is the wrong lens. Through July it produced roughly 100 retirement records a month across about 34 addresses, which adds up to a few credits a month. From August 12 to 28 there was a burst of extra records, and I don’t know the cause yet, so I won’t quote anything that includes August until we do. I also don’t have the buyer-funded vs subsidized split in a form I can stand behind yet. And I couldn’t find a source for the ~88/day estimate.

**The sell orders and the $2.4M.** There are 42 open orders right now from 11 sellers, about 125k credits, mostly C06 and C02. Those are asks, and the chain doesn’t show who fills them, so I don’t know who buys and I won’t guess. One correction: the $2.4M comes from my State of Regen 2025 post (The State of Regen 2025). It’s the cumulative total purchased and retired on the network up to then, including earlier large sales like Microsoft’s, not a 2025-only figure. A clean 2025-only number would need to be derived from the chain, and given your ledger work that’s something we could do together, agreeing on the definition first like we said about issued vs cancelled. On a plan to grow retirements: the Registry is working on the demand side, but I don’t have something I can lay out publicly yet.

**Which funding pools we’re talking to.** That one I can’t put in a public thread, since most of those conversations aren’t ours alone to disclose. Where I think a verified-hour record helps most is what I said last time: reporting for money that’s already committed, like grants, public bond impact reports and forward commitments. Happy to go through specifics directly.

**The LiquidityDAO pilot, route and timing.** I don’t know yet. Before I advise a route I want to understand how the LiquidityDAO address is governed (who signs, and under what rules), and I haven’t done that work. Let’s figure out the route together once that’s clear. I won’t give you a timing before then.

**VSH01.** Nothing has changed: still yes in principle, once the first hours are accepted.

From Tuesday, I still owe you a post that pulls together the data module anchoring and signing tools, the relevant repos, and the claims engine work. I’ll put that up as its own thread. And I’m looking forward to the more digestible version of the proposal you mentioned.

1 Like

Thanks Gregory. Honest unknowns beat soft numbers.

  • Upgrade coordination and chain comms: yes, let’s shape it. My starting point: one thread per upgrade, private notice to validators before a security release, a public write-up within 7 days, and a named backup. I’ll write the role up as one page and we refine it together.
  • Fee routing: I’ll keep RFC #111 current. If you can name who at RND would review a build path, I’ll take the sponsor ask to the Working Group.
  • Marketplace fees: one thing from the code worth knowing before anyone proposes a value. A buyer fee above zero rejects every purchase that leaves max_fee_amount unset (it defaults to 0), so any first change should be a seller fee only.
  • 2025 retirements: agreed, definition first. I’ll post a proposed definition (purchased vs retired, issued vs cancelled, which dates), then derive the number from the chain once you agree.
  • $2.4M: thanks, I’ll label it cumulative through December 2025 in the next roadmap version. And let’s not use the ~88/day.
  • LiquidityDAO: I’ll read from the chain who signs for that address and post it here, so we can choose a route together.

I’ll post the shorter version of the proposal here. Looking forward to your toolkit thread.

1 Like