Mission 11: ERC-7710 Liquid Democracy — Production Implementation

[jeremie-olivier]

Board item: ERC-7710 Liquid Democracy Production — Contracts + UI
Status: Blocked | Priority: P0
Reward: $3,000 USDC + iBox token
Target: Solidity / full-stack developer with smart account and governance experience
Validation: Hard requirement — Intuition Team must validate before payout
Chain: Intuition Network (mainnet: 1155, testnet: 13579)
Prerequisite: Mission 10 (POC) must be completed and validated first

⚠️ This mission is blocked. It opens once Mission 10 is completed and validated by the Intuition Box core contributors.

---

Context

Mission 10 delivers a proof-of-concept for ERC-7710 liquid democracy with Intuition graph domain caveats. This mission takes the POC to production: hardened contracts, a full-featured governance UI, and mainnet deployment.

The core mechanic (proven in Mission 10): a voter delegates their voting power scoped to a domain (e.g., design), and the caveat enforcer resolves that scope semantically via the Intuition knowledge graph — so a branding proposal automatically passes a design-scoped delegation because branding - is a sub-domain of - design exists onchain.

Objective

Ship a production-ready liquid democracy system on the Intuition chain: robust, auditable contracts with a full governance UI that any community could use to set up scoped delegation chains and vote on proposals.

Deliverables

Contracts

• Production Graph Domain Caveat Enforcer — harden the POC enforcer:
  • Chosen traversal approach solidified (onchain reads or proof-based — informed by POC writeup)
  • Full snapshot/root hash support — graph state is captured at delegation time, recomputed and verified at enforcement time to prevent graph manipulation attacks
  • Comprehensive edge case handling: circular graph paths, deleted atoms, type mismatches
  • Gas-optimized traversal with clear documented limits
  • Natspec documentation
• Delegation factory — a contract that lets users create and manage delegation chains without raw calldata
• Audit-ready test suite — 100% branch coverage, fuzz tests on traversal depth and caveat parameters, invariant tests on revocation

Frontend

• Delegation manager UI — create, view, and revoke ERC-7710 delegations
  • Connect wallet (wagmi + RainbowKit)
  • Browse and select domain atoms from the Intuition graph as delegation scope
  • Configure caveat parameters (depth, expiry, edge types)
  • Visualize active delegation chains (who delegated what to whom)
• Governance UI — submit and vote on proposals through delegated authority
  • Create mock proposals with a declared domain
  • Show in real time whether the connected account has (direct or delegated) authority to vote
  • Display semantic resolution: why a proposal passed or failed the domain enforcer
• Domain graph explorer — browse the Intuition knowledge graph to understand scope relationships
  • Search atoms, traverse is a sub-domain of paths
  • Show which domains are in scope for a given delegation
• Deployed on intuition.box subdomain (TBD with team)

Documentation

• Architecture doc: contracts, interfaces, trusted components, upgrade path
• User guide: how to set up a delegation chain, how scope resolution works
• Article / X thread for ecosystem announcement

Acceptance Criteria

• All contracts deployed on Intuition mainnet (1155) and testnet (13579)
• Enforcer passes a comprehensive audit-focused review (internal team review minimum)
• Snapshot hash mechanism prevents graph manipulation — test suite proves it
• Frontend is fully functional end-to-end with a real wallet on mainnet
• A new user can set up a scoped delegation chain in under 5 minutes from the UI
• Architecture doc is sufficient for the Intuition team to maintain and extend the system

Technical Notes

• Build on the chosen approach from Mission 10 — do not reinvent; extend and harden
• Suggested contract stack: Solidity 0.8.x + Foundry (fuzz + invariant tests)
• Suggested frontend stack: React + wagmi v2 + RainbowKit + viem
• Snapshot hashing design: at delegation time, hash the relevant subgraph (domain node + descendant edges within max depth); enforcer recomputes and compares — prevents an attacker from adding a malicious edge to the graph after delegation
• The delegation factory should follow a pattern similar to Uniswap V2 factory for discoverability
• Coordinate with the Intuition team on the canonical is a sub-domain of predicate and any existing domain atoms to reuse

Application

Step 1 — Comment on this issue explaining why you think you are a right fit for this mission and what excites you about it.

Step 2 — Contact zet.box on Discord to plan a call with the Intuition team.

---

Open Questions

• Should the production enforcer support pluggable edge types (any Intuition predicate can be a "sub-domain" relation), or should it be fixed to a single canonical predicate?
• What's the upgrade/migration path from the POC testnet deployment?
• Should the governance UI support a specific governor standard (OZ Governor, etc.) or remain mock-only for now?
• Is there a target subdomain (e.g., democracy.intuition.box) for deployment?

---

Prerequisite: Mission 10 — ERC-7710 Liquid Democracy POC
Origin: https://x.com/olivierjeremie/status/1925983073540370651
Related: ERC-7710, Smart Account Kit, Intuition Knowledge Graph

[aliveevie]

I'd like to take this on.
I'm a Solidity + full-stack dev with a strong security focus, which fits the bar here: hardened enforcer contracts, audit-ready tests, and a governance UI that's actually usable end-to-end.
Why I'm a fit:

My core work is smart contract security — bug bounties and invariant/fuzz testing in Foundry. A "100% branch coverage + fuzz on traversal depth + invariant tests on revocation" suite is exactly how I already work.
I've placed 1st in multiple DeFi/security hackathons (Shape Rotator, ArbiLink) building circuit-breaker and FSM-style enforcement logic, so the snapshot/root-hash mechanism (hash the subgraph at delegation time, recompute and verify at enforcement) to block graph-manipulation attacks is the kind of design I enjoy getting right.
On the frontend I ship React + wagmi v2 + viem + RainbowKit — delegation manager, governance flow, and a graph explorer for traversing is a sub-domain of paths are all in reach.

Most excited about the semantic resolution piece — surfacing why a proposal passed or failed a domain-scoped delegation. Making that legible in the UI is what turns this from a clever enforcer into something a real community can trust and use.

[htvnhe]

Hi @jeremie-olivier and the Intuition Box team,

I'd like to apply for Mission 11 — ERC-7710 Liquid Democracy: Production Implementation. This is exactly the kind of work I want to be doing: a security-critical smart-account system where the hard part isn't the delegation plumbing, it's making semantic scope resolve safely and cheaply onchain. I'll lay out my approach below and reach out to zet.box on Discord to schedule the call.

Up front: I'll build on Mission 10's chosen approach rather than reinvent it — the POC writeup's traversal decision drives several choices here, so I'd treat aligning on the POC and the canonical is a sub-domain of predicate as step zero.

The mechanic, and the threat that defines the design

The core loop is clear: a voter delegates domain-scoped voting power (say design), and the Graph Domain Caveat Enforcer decides whether a proposal's domain falls within that scope by resolving is a sub-domain of paths in the Intuition graph — so a branding proposal passes a design-scoped delegation because branding → design exists onchain.

What makes this production rather than a demo is one threat: the graph is mutable, so scope is mutable. If Alice scopes Bob to design today, an attacker can later add treasury is a sub-domain of design and silently expand Bob's authority over Alice's stake. Any enforcer that reads the live graph at vote time is exposed to this. So the entire contract design is organized around freezing the scope at delegation time and proving against that frozen state at enforcement time.

Contracts

1. Graph Domain Caveat Enforcer

Built on the framework's CaveatEnforcer base, implemented in beforeHook (which MUST revert when scope isn't satisfied). I'd use the split the framework already gives us:

• terms (committed and signed by the delegator at creation): delegatedDomainAtomId, maxDepth, the allowed predicate id(s), a snapshotRoot (Merkle root over the in-scope subgraph), a minSignal threshold, and expiry. Because terms are part of the signed delegation, none of this is tamperable after the fact.
• args (supplied by the redeemer/voter at vote time): proposalDomainAtomId, the path of atoms from the proposal domain up to the delegated domain, and Merkle inclusion proofs for each edge on that path.

The hook then verifies, with no live-graph reads at all:

1. each edge on the path is (child) is-a-sub-domain-of (parent) using an allowed predicate id;
2. every edge is proven to be in snapshotRoot (so post-delegation edges cannot be used);
3. the path actually connects proposalDomainAtomId → delegatedDomainAtomId, contains no repeated node (kills cycles by construction), and its length ≤ maxDepth;
4. the ERC-7579 ModeCode is the expected single-execution mode (a class of bug Consensys Diligence has flagged in framework enforcers);
5. expiry hasn't passed.

Why proof-based + snapshot instead of onchain traversal: it's both cheaper (verification is O(pathLen · log N) hashing on calldata — no SLOADs across the graph) and it's the only version that's actually safe against graph manipulation. Live onchain traversal re-introduces the attack and blows the gas budget on a large mainnet graph. I'd keep a small documented onchain-read fallback for tiny graphs, but recommend proof-based as the production default — pending the POC writeup, which may already settle this.

Edge cases, explicitly:

• Circular paths — rejected, because the supplied path must be simple (no repeated atom).
• Deleted / unstaked atoms — scope edges must clear minSignal at snapshot time, so spam or zero-signal atoms can't manufacture scope; the snapshot is authoritative for inclusion. Whether live removal of an edge should also revoke in-flight authority is a genuine design fork — my default is "snapshot is authoritative; removal is handled via revocation / re-delegation," but I'd confirm the intended semantics with the team.
• Type mismatches — enforce expected atom type and exact predicate id(s); anything else fails closed.

Plus full Natspec, documented depth / proof-size limits, and a gas table per depth.

2. Delegation Factory

Modeled on the Uniswap V2 factory's two properties — deterministic addresses + a discoverable registry:

• CREATE2 / counterfactual addresses for DeleGator accounts, so chains are discoverable and addresses predictable.
• An onchain DelegationRegistry recording chain metadata (delegator, delegate, scoped domain, snapshotRoot commitment, status), so the UI can render "who delegated what to whom" and reflect revocation without scraping raw calldata.

Authorization itself stays on offchain EIP-712 signed delegations — the gas-efficient path the framework is built for; the registry stores commitments/metadata only. Revocation hooks into the framework's delegation-disabling and flips registry status.

3. Audit-ready test suite (Foundry)

• 100% branch coverage (forge coverage).
• Fuzz over depth, path length, predicate ids, and randomized tree shapes — property: a valid proof always passes, an invalid one always reverts.
• Invariant (handler-based) tests for the properties that actually matter: a revoked delegation can never be redeemed under any call sequence; no path beyond maxDepth ever passes; no edge absent from the snapshot ever passes.
• Attack reproductions as named tests: post-snapshot edge injection, cycle injection, depth overflow, type mismatch, sub-minSignal edge, signature replay / malleability, wrong ModeCode.
• Differential test: an offchain reference resolver vs. the onchain enforcer must agree on random graphs — this is also what keeps the frontend's snapshot builder honest.

Frontend (React + wagmi v2 + RainbowKit + viem + @metamask/delegation-toolkit)

The subtle correctness requirement: the client's snapshot / Merkle encoding must match the contract's byte-for-byte. I'd factor the leaf / encoding logic into one shared module derived from the Solidity types, so the builder and enforcer can never drift.

• Delegation Manager — connect wallet; browse and pick domain atoms from the Intuition graph as scope; set depth / expiry / predicate(s); the client fetches the in-scope subgraph, builds the snapshotRoot, and signs the EIP-712 delegation via the toolkit; view and revoke; visualize active delegation chains from the registry + events.
• Governance UI — create mock proposals with a declared domain; show in real time whether the connected account can vote by simulating redeemDelegations with the constructed path + proofs (the simulation-based check ERC-7710 itself recommends) before anything is submitted; and display the semantic resolution — render the actual branding → design path and exactly why the enforcer passed or rejected it. That "show your work" view is, to me, what makes this legible to a real community.
• Domain Graph Explorer — search atoms, traverse is a sub-domain of paths, and show which domains are in scope for a given delegation (reusing a force-graph view).
• Deployed on an intuition.box subdomain — I'd suggest democracy.intuition.box, TBD with the team.

Answers to the open questions

1. Pluggable vs. fixed predicate: support a delegator-committed allowlist of predicate ids inside terms, defaulting to the single canonical one. You keep flexibility (a delegator can opt into other relations) without losing the security property, because the allowlist is signed and snapshotted.
2. Upgrade / migration path: immutable, versioned enforcers — no upgradeable proxy for security-critical enforcement logic. New versions deploy at new addresses; existing delegations keep pointing at the enforcer they were signed against, so POC testnet delegations keep working untouched. Ship a version registry + a short migration guide instead of in-place upgrades.
3. Governor standard vs. mock: ship a mock governor behind a governor-agnostic adapter interface, so this mission stays scoped while leaving a clean seam for OZ Governor (or others) to plug in later. The delegated-authority resolution is the reusable core; the governor is swappable.
4. Target subdomain: coordination item — democracy.intuition.box is my suggestion; happy to follow the team's convention.

Documentation

Architecture doc (contracts, interfaces, trusted components, the threat model above, and the versioning / upgrade path), a user guide (set up a delegation chain in under 5 minutes, how scope resolution works), and an ecosystem article / X thread for the announcement.

Proposed milestones

• M0 — Alignment (short): lock the POC traversal decision + canonical predicate with the team.
• M1 — Enforcer + snapshot model: beforeHook, terms/args layout, Merkle verification, edge cases; fuzz + first invariants.
• M2 — Factory + registry + revocation: CREATE2 deploys, registry, full invariant suite, attack reproductions, branch coverage to 100%.
• M3 — Frontend: manager, governance (live simulation + resolution view), explorer; shared snapshot-builder module.
• M4 — Testnet (13579) + E2E + internal audit-focused review: end-to-end with a real wallet; address findings.
• M5 — Mainnet (1155) + docs + article.

Realistically a few focused weeks given the audit bar; I'll firm up the schedule on the call and can adjust scope / sequencing to the team's priorities.

Relevant experience

[Replace this with your real background — be specific and honest; the team validates this on the call.]

[e.g., production Solidity with Foundry incl. fuzz / invariant testing; account abstraction / ERC-4337 / smart-account or delegation work; governance or DeFi protocol contracts; security / audit experience; and React + wagmi / viem dApp frontends.] What pulls me to this one specifically is the semantic layer — using a live trust graph to decide authority, not just to display relationships, is a genuinely new primitive, and the snapshot-proof problem is a real, fun security challenge.

Next step: I'll reach out to zet.box on Discord to schedule the call. Looking forward to it.

[htvnhe]

Hi @jeremie-olivier and the Intuition Box team,

I'd like to apply for Mission 02 — Proxy Fee Template V2. I've gone through V1 and the open issue, and I'm happy to take on the full V2 set (contracts + factory webapp + docs). Since the sub-bounties are independent, I'm also glad to be scoped to whichever are still open — a couple already have PRs in flight (more on 2A below), so I'd confirm assignment with the team first.

Quick framing so you know I've read the code: V1 is a proxy sitting in front of the Intuition EthMultiVault that intercepts deposit / createAtoms / createTriples / depositBatch, takes a fixed + percentage fee, and forwards the rest. V2 hardens that into something safe to custody fees and easy for anyone to deploy. Here's how I'd approach each bounty.

2A — Fix Issue #1 (receiver validation) — $200

The bug is real and worth fixing carefully: receiver is forwarded straight to ethMultiVault.deposit(), so a misconfigured or malicious integrator can pay with the user's msg.value while minting shares to a different address.

My approach goes one step past the issue's suggested patch:

• Default to self, by construction. For deposit / createAtoms / createTriples, mint to msg.sender rather than a caller-supplied receiver (issue's Option A). Hardcoding removes the footgun entirely instead of guarding a param that could be reintroduced later. Because this changes the external signature, I'd land it as a clean breaking change and version-note it (which dovetails with 2B's versioning).
• If deposit-on-behalf is a wanted feature (smart accounts, sponsored / gift deposits), expose it as an explicit, clearly-named depositFor(receiver, …) so redirection is always intentional — never a silent default.
• depositBatch is handled consistently (each entry resolves to msg.sender, or validated per-entry).
• One nuance I'd flag: msg.sender is the immediate caller, so for contract-wallet / AA / meta-tx integrators the "user" is the calling contract. The fix correctly scopes shares to the caller; I'd document that for integrators.
• Tests, TDD-style: first a failing test that reproduces the exploit (shares minted to an attacker), then the fix; coverage across all four functions, the depositFor happy path, and a fuzz over the receiver argument. I'd also assert fee accounting is unchanged by the fix.

Note: issue #1 already has open PRs (e.g. #11). I'd check what's merged / in-review before duplicating, and coordinate with the team.

2B — Upgradable Proxy via ERC-7936 — $100

ERC-7936 isn't a plain UUPS / Transparent proxy — it's the versioned proxy interface: a registry of bytes32 versionId → implementation, with callers able to pin a specific version via executeAtVersion and a default version behind the fallback for backward compatibility. I'd implement it as specified, with EIP-1967 slots for tooling.

• Admin-gated version registration = the "upgrade" action. A property worth highlighting: because users can stay pinned to an audited version, a bad / admin-pushed version can't silently capture everyone — a real plus once the contract custodies fees (2C).
• State preservation is the hard part, and it's a storage-layout problem. All versions share the proxy's storage, so I'd use ERC-7201 namespaced storage (+ append-only discipline) and add a CI check that diffs storage layouts between versions (forge inspect / OZ upgrade checks), so an incompatible layout can never ship.
• Migration from the current non-upgradable deployment: you can't retrofit an immutable contract, so migration = deploy the versioned proxy fresh, register V1-equivalent logic as version 1, and cut over with a short integrator guide (plus draining any accumulated fees once 2C lands).
• Tests: version routing, pinning, default fallback, admin-only registration, and the key one — write state through v1, read it through v2, prove it's preserved; storage-collision and delegatecall-surface tests.
• One thing I'd confirm with the team: whether you want strict opt-in version semantics (ERC-7936's emphasis) or simply "latest is default." I'll build shared-state + default-latest + optional pinning, which covers both.

2C — Withdraw Function — $200

Switching from auto-forwarding to accumulate-then-withdraw turns the proxy into a fund-custodying contract, so this is mostly a safe-custody exercise:

• Remove per-deposit forwarding; track accumulated fees in contract state (native primarily, defensively handling tokens).
• Add withdraw(to, amount) / withdrawAll(to) gated to the fee recipient (and / or admin).
• Security: pull-over-push, nonReentrant, strict checks-effects-interactions (decrement accounting before transfer), safe native send with success check.
• Invariant: address(this).balance >= accumulatedFees — asserted as a Foundry invariant.
• Tests / edge cases: zero withdraw, over-balance (revert), reentrancy attempt, access control (non-recipient reverts), partial vs full, accounting-exactness per deposit, and that deposits still succeed after removing forwarding.
• Given the new custody + upgrade surface, I'd recommend (and document) a multisig / timelock for withdraw + version-registration authority.

2D — Factory Webapp — $300

• Factory contract deploys per-user fee-proxy instances as UUPS proxies (ERC1967Proxy → a shared UUPSUpgradeable fee-proxy implementation), initialized with the deployer's fee params (fixed, %, recipient, MultiVault, admin). Uniswap-V2-style discoverability: CREATE2 deterministic addresses, a registry (deployer → proxies[], allProxies, getProxy), and a ProxyCreated event. Each instance is independently owned and UUPS-upgradeable by its deployer (_authorizeUpgrade gated to the instance admin). Where possible the instance logic reuses the template from 2A–2C.
• Webapp (React + wagmi v2 + viem + RainbowKit): one-click deploy (configure params → factory tx → new proxy address), plus a management dashboard for your deployed proxies (read from registry / events): adjust fees, withdraw, upgrade. Network switcher for mainnet 1155 and testnet 13579.
• Docs on how the factory + webapp work, with a deploy-and-manage walkthrough.
• Tests: correct UUPS proxy deployed + initialized, registry / event recording, CREATE2 determinism, per-instance owner-only upgrade, and collision handling.

2E — Article & Social — $100

A walkthrough article covering the four V2 changes (receiver fix, versioned-upgradeable proxy, accumulate + withdraw, one-click factory) with code snippets and usage examples, plus a tight X thread announcing it and pointing at the factory webapp + repo. (I can draft both.)

Cross-cutting

Foundry throughout (fuzz + invariant + 100%-branch where it matters), a CI pipeline (build / test / coverage / fmt / gas snapshot / storage-layout diff), and verified forge script deploys to 1155 and 13579. Each bounty ships as its own PR so it can be reviewed, merged, and validated independently per the acceptance criteria.

Relevant experience

[e.g., production Solidity + Foundry (incl. fuzz / invariant testing), proxy / upgradeable-contract work (EIP-1967 / UUPS / ERC-7201 storage), DeFi / vault integrations, and React + wagmi / viem dApp frontends.] What I like about this one is that it's small but genuinely security-sensitive — a fee proxy that custodies funds and is user-deployable has to be boringly correct.

Next step: happy to sync with the team on which sub-bounties are still open and start with whichever you'd prefer (2A or 2D are the natural entry points). I'll follow the per-bounty flow: PR → tests passing → Intuition Team validation.

[BenraouaneSoufiane]

I would like to work on some erc7710 with metamask accounts kit with advanced permissions/delegation on chain if you can assign me to such mission, check my example: https://auditsfor.me
Repo: https://github.com/BenraouaneSoufiane/auditsforme

[ayushsingh82]

Hi @jeremie-olivier — I'd like to work on this. Rather than pitch a plan upfront, I'll build first: I'll put together a working prototype (enforcer + basic delegation flow) so you can judge it on substance, and go from there. Will follow up once I have something to show. Happy to hop on a call with the team in the meantime.

[TS-mfon]

Hi @jeremie-olivier, I would lobe to work on this once it opens up.
I noticed this is gated behind Mission 10, so I don't want to jump ahead of that. If Mission 10 is still open or needs a second set of hands, I'd be glad to help there first since it directly informs the traversal approach this mission builds on.
On the technical side, I've worked with delegation based permission flows before (ERC-7715 style scoped delegation with a wallet as the enforcement point), so the general shape of "delegate authority, then have a caveat enforcer check it before allowing an action" is familiar ground for me. The part I find most interesting here is the snapshot/root hash requirement, since letting the graph move between delegation time and enforcement time is the obvious attack surface, and getting that verification right without making traversal too expensive in gas is the real engineering problem in this mission.
For the frontend side, I've built wallet connected interfaces with live on chain state visualization before, so the delegation manager and graph explorer pieces are within what I can commit to alongside the contracts.
Happy to share more detail on relevant past work if useful. Let me know when Mission 10 clears and if this one is still open.

[Saber1Y]

Hi @jeremie-olivier

Background: I build ZK proof systems (Noir/Circom) and ERC-4337 account abstraction with session-key scoping — currently running a live ZK disclosure agent (Minima) on Base Sepolia that does proof-gated authorization, and separately working on a ZK-gated ERC-7710 caveat enforcer proposal for this ecosystem. So my lane is slightly different from the pure-security/audit angle already represented here: I'd bring depth on the semantic scoping and proof-verification side — particularly relevant to the snapshot/Merkle verification piece, since that's structurally close to how I already verify Noir proofs against committed state before allowing an action to execute.

Where I'd need to ramp: I haven't shipped a Foundry invariant/fuzz suite at the audit-grade bar this mission requires, and I'd want to align with the team on Mission 10's chosen traversal approach before locking contract design — not looking to reinvent that.

Given the field here, I'd genuinely value being considered alongside or in support of another builder on this — e.g. pairing on the enforcer/proof-verification piece while someone else leads the audit-hardening and frontend. Happy to hop on a call with the team (and zet.box) to figure out where I'd add the most value, whether that's this mission directly or a complementary piece of it.

[jerrynoah96]

@jeremie-olivier

I spent almost five years at an ethereum Layer2, where I worked on production smart contracts for a Layer 2 protocol. Some of the work included building order book contracts for a Central bank, developing a game hub protocol that sat on top of a DEX, and contributing to other protocol infrastructure, staking and reward systems. I was also involved in security reviews, audits and designing features with security, gas efficiency and maintainability in mind.

Before that, I worked at Coinvise, building production smart contracts powering creator tokens and Web3 social primitives.

I also have production experience with ERC-7710, governance systems and smart account delegation, so the core concepts behind this mission are already familiar to me.

What excites me most is the semantic delegation model. Using the Intuition knowledge graph to resolve delegation scope

My focus would be on delivering audit-ready contracts backed by comprehensive Foundry tests (including fuzz and invariant testing), while also building the React/wagmi/RainbowKit UI needed to make delegation and governance intuitive for users.

Answers to the Open Questions

• Pluggable edge types? I'd support pluggable predicates while defaulting to the canonical is a sub-domain of relationship.
• Migration from the POC? Keep interfaces stable where possible and provide a straightforward migration path if storage changes are required.
• Governor integration? Build the UI to be modular so it can support OpenZeppelin Governor or remain mock-based during development.
• Deployment? Happy to coordinate with the team on the preferred intuition.box subdomain.

I'd love to help take this from a POC to a production-ready governance system.