Agentic Tokenomics: A Shared Harness for Regenerative Governance
What is this?
This repository is a coordination layer — a shared infrastructure for designing, specifying, and implementing the mechanisms that give the REGEN token real utility and the Regen Network real governance.
The core premise: routine governance work — price monitoring, data validation, credit class screening, standard proposal processing — doesn’t need to be bottlenecked through a small group of humans. It can be automated by AI agents that operate transparently within on-chain infrastructure, freeing human judgment for the decisions that actually require it. The target is 65–75% automation of routine governance, with human oversight always retained for high-stakes, contested, or constitutional decisions.
But this isn’t just a spec for robots. It’s a harness — a way for multiple contributors, working with their own AI tools and agentic workflows, to build coherently toward a shared system without stepping on each other.
Why this matters
Regen Network sits at an unusual intersection. It has a blockchain with ecological crediting infrastructure. It has a knowledge commons (KOI) that indexes the context anyone needs to contribute meaningfully. And it now has AI agents capable of doing real governance work — reviewing credit class applications, analyzing proposals, monitoring markets, watching validator health.
The opportunity is to wire these together: distributed work, blockchain-based rigor and truth verification, agentic workflows nested into transparent governance, and tokenomics linked to ecological outcomes. What makes this more than a theoretical exercise is that the whole system can be dogfooded — Regen can use its own claims engine and knowledge infrastructure to prove the approach works, then offer it as replicable infrastructure for any ecological governance context.
The REGEN token in this framing is not a thing in itself. It’s a coordination tool. The question the working group has been iterating on since January 2026: who do we want to coordinate with this token, and what is the target behavior?
The architecture
Nine mechanisms across two pillars
Token Utility Mechanisms create concrete reasons to hold and use REGEN within the ecological credit lifecycle:
-
M001-ENH — Credit Class Approval Voting: dual-track voting for credit class decisions
-
M008 — Data Attestation Bonding: stake REGEN to back the quality of ecological data
-
M009 — Service Provision Escrow: lock tokens as escrow for contracted ecological services
-
M010 — Reputation/Legitimacy Signaling: build and stake on track records
-
M011 — Marketplace Curation & Quality Signals: curate and surface quality in the credit marketplace
Economic Reboot Mechanisms support the transition from inflationary proof-of-stake to a value-driven proof-of-authority model:
-
M012 — Fixed Cap Dynamic Supply: supply-capped mint/burn linked to ecological value creation
-
M013 — Value-Based Fee Routing: route protocol fees through burn, validator rewards, community pool, and agent infrastructure
-
M014 — Authority Validator Governance: bioregional validator selection and accountability
-
M015 — Contribution-Weighted Rewards: reward participants based on actual contributions, not just stake size
Each mechanism has a full specification, JSON schemas, datasets, and a reference implementation. Nine CosmWasm smart contracts implement the on-chain logic. A cadCAD simulation model validates the economic parameters before anything touches a testnet.
Four governance layers
| Layer | Automation | What it handles |
|-------|-----------|-----------------|
| L1 — Fully Automated | 100% | Price monitoring, data validation, routine alerts |
| L2 — Agentic + Oversight | 85%+ | Credit class screening, standard proposals |
| L3 — Human-in-Loop | 50% | Large grants, contested decisions |
| L4 — Constitutional | 0% | Protocol upgrades, governance parameter changes |
The system branches like a tree: at the core, a small set of agents handle infrastructure-level governance. One layer up, methodology-specific agents manage domain decisions. Further out, project-level processes run with increasing human involvement. The key design constraint is that automation only applies where the decision logic is well-understood and the stakes are bounded.
Four agent personas
| Agent | Domain | What it does |
|-------|--------|-------------|
| AGENT-001 — Registry Reviewer | Credit classes, methodology | Reviews applications, checks compliance, flags issues |
| AGENT-002 — Governance Analyst | Proposals, voting patterns | Analyzes proposals, surfaces context, monitors governance health |
| AGENT-003 — Market Monitor | Price, liquidity | Watches market conditions, detects anomalies, triggers alerts |
| AGENT-004 — Validator Monitor | Network health | Tracks validator performance, monitors the PoA transition |
These agents run on ElizaOS, read from the Regen Ledger and KOI knowledge graph via MCP, and can bring governance proposals, comment on GitHub, and generate artifacts that feed back into the knowledge commons.
The harness concept
Here’s what makes this repo different from a typical governance spec: it’s designed as a shared agentic harness for multi-party collaboration.
Multiple contributors are building agentic tools and workflows for Regen — each bringing their own AI setups, their own engineering approaches, their own areas of focus. The agentic-tokenomics repo exists to harmonize that agency. It provides:
-
A mechanism library where each mechanism is a self-contained module with spec, schema, implementation, and tests. If you’re working on a burn/mint mechanism, a reputation system, or a fee-splitting contract — it goes here, backlinked to the shared index.
-
Shared schemas and verification so that independently-developed components can interoperate. The
scripts/verify.mjstool validates all schemas; CI enforces it. -
Phase structure (discovery → design → implementation → deployment → operations) that gives everyone a shared map of where the system is and what’s next.
-
Knowledge commons integration via KOI, which means any contributor with access has the indexed context of the entire Regen ecosystem — the same context that allows non-engineers to do institutional-grade infrastructure work with AI support.
The working group has described this as a “recursive learning opportunity” — the more people build within the shared infrastructure, the more the knowledge commons grows, which upgrades everyone’s capacity to build further. The harness doesn’t constrain contributors; it amplifies them by providing common ground.
How this was built
This is worth being transparent about: a significant portion of the implementation work in this repo was produced by AI coding agents. brawlaphant (an OpenAI Codex agent) generated CosmWasm contracts, simulation models, agent scaffolds, phase specifications, and CI infrastructure. CShear authored the original mechanism specifications. ToknWrks contributed fee-split alignment. The review and merge process was conducted collaboratively between a human architect and Claude Code.
The repo is itself a case study in the kind of graduated human-AI collaboration the governance system is designed to enable on-chain: AI agents generating work, different AI agents helping review and triage it, human judgment setting priorities and resolving conflicts. It’s early, it’s imperfect, and it’s working.
Five phases, all specified
| Phase | Status | What it covers |
|-------|--------|---------------|
| Phase 1 — Discovery & Analysis | Complete | Stakeholder mapping, value flows, mechanism inventory |
| Phase 2 — Mechanism Design | Complete | 9 mechanism specs, 12 agent workflows, 5 governance processes |
| Phase 3 — Implementation & Testing | Specified | Smart contract specs, agent orchestration, security framework, KOI integration |
| Phase 4 — Deployment & Migration | Specified | Testnet plan, mainnet PoS→PoA runbook, community onboarding |
| Phase 5 — Operations & Evolution | Specified | Monitoring, incident response, evolution governance |
How to contribute
The repo is public, dual-licensed (Apache 2.0 for code, CC-BY-SA 4.0 for specifications), and structured for independent contribution.
Where to start:
-
Read the mechanism specs in
mechanisms/— each one is self-contained with a SPEC.md, datasets, schemas, and reference implementation. Pick one that’s in your domain. -
Review the open PRs — there are currently 26 open, covering edge-case tests, agent workflow implementations, integration tests, integrator docs, and CI fixes. Reviews welcome.
-
Run the simulations — the cadCAD model in
simulations/validates economic parameters for M012-M015. If you have opinions about supply dynamics, fee routing ratios, or reward curves, this is where to test them. -
Build an agent — AGENT-001 and AGENT-002 have standalone TypeScript reference implementations. AGENT-003 and AGENT-004 have character definitions and open PRs for full workflow implementations. If you have ElizaOS experience, these are directly actionable.
-
Improve the contracts — 9 CosmWasm contracts are landed. They need richer test coverage, workspace integration, and clippy cleanup. If you write Rust, there’s concrete work waiting.
What we’re especially looking for:
-
CosmWasm and Cosmos SDK experience (contract review, integration testing)
-
cadCAD and agent-based modeling (parameter validation, stress scenarios)
-
ElizaOS and AI agent development (workflow implementation, plugin development)
-
Governance design (mechanism review, proposal drafting, community process)
-
Ecological domain knowledge (credit class workflows, methodology review, data attestation)
The goal is not to have everyone converge on a single way of working. It’s to harmonize the agency of everyone who wants to contribute — in a rigorous, coherent way, building on shared infrastructure and shared knowledge — so that the whole is genuinely greater than the sum of its parts.
Links
-
Repository: regen-network/agentic-tokenomics
-
Regen Network: regen.network
-
KOI Knowledge Commons: Context infrastructure that powers contributor onboarding
-
Forum: forum.regen.network — discussion and governance proposals