Governance Models

Overview

ULedger does not impose a governance model. The smart contract defines the rules; the wallet and capability system enforces the principals; the STARK proof layer preserves the record. Within those constraints, any governance model is implementable.

This document catalogs four archetypal governance patterns, from fully autonomous to fully human-controlled, and describes how each is implemented on ULedger.

Pattern 1: Fully Autonomous

Description: Agents act without any human approval at runtime. The contract defines the rules; agents operate within those rules autonomously. Humans set up the system and retain administrative override capability, but do not participate in day-to-day operations.

When to use: Well-understood, low-risk automation. Monitoring pipelines, data ingestion, routine reporting, supply chain tracking, IoT sensor recording.

Structure:

ORGANIZATION: "acme-corp"
└── SERVICE: "pipeline-service"
    └── Wallet: pipeline-agent (capabilities: data:submit, contract:invoke on pipeline-contract)

Contract: pipeline-contract
    - No human approval required
    - Agent calls logDataPoint(data) autonomously
    - Any wallet can query the recorded data
    - Owner wallet (human) can pause or upgrade the contract

ULedger implementation:

Agent wallet holds capabilities scoped to the specific contract and data actions.
Contract has no human-gated functions; all functions are callable by any authorized agent.
Human parent wallet retains ALTER_WALLET power to disable the agent at any time.
All agent actions are on-chain and STARK-proofed; even in fully autonomous mode, the audit trail is complete.

Trade-off: Maximum throughput, minimum latency. Zero human involvement at runtime. The risk is entirely in the contract logic; if the contract has a bug, the agent will faithfully execute the buggy behavior at scale. Thoroughly audit the contract before deploying autonomous agents.

Pattern 2: Human-in-the-Loop

Description: Agents prepare, propose, or compute, but a human must explicitly approve before any consequential action is finalized. The human's approval is itself a signed transaction.

When to use: High-stakes decisions: financial transactions above a threshold, content publication, external communications, medical records, legal actions.

Structure:

PERSONAL: "alice"
├── Wallet: alice-wallet (human, holds private key)
└── AGENT: "alice-research-agent"
    └── Wallet: agent-wallet (capabilities: contract:invoke on research-contract, data:submit)

Contract: research-contract
    - proposeAction(data, analysis) → agent submits proposal, sets status = "pending"
    - approveAction(proposalId) → owner-only, executes the action, sets status = "approved"
    - rejectAction(proposalId) → owner-only, cancels, sets status = "rejected"
    - getProposalStatus(proposalId) → any caller

ULedger implementation:

Agent wallet can only call proposeAction; its capability is scoped to that function's selector or the contract generally, but the contract enforces the human-gate internally.
Alice's wallet is the contract owner. Only she can call approveAction or rejectAction.
Every proposal and every approval/rejection is a signed transaction; the full decision trail is on-chain.

Trade-off: Higher latency (human must act), but human judgment is injected at the critical decision point. The agent does the computational work; the human bears accountability for the outcome.

Pattern 3: Hybrid Council

Description: A group of human principals (the council) each delegates a voting agent. Agents vote autonomously within the voting window. The council chair (or any authorized wallet) finalizes the decision after the window closes. Humans retain veto power by declining to finalize, or by voting directly.

When to use: Organizational governance where multiple stakeholders must agree, but asynchronous participation is acceptable: board decisions, research review panels, consortium agreements, multi-party contract approvals.

Structure:

ORGANIZATION: "council-org"
│
├── PERSONAL: "alice" (council chair)
│   └── Wallet: alice-wallet (contract owner)
│
├── PERSONAL: "bob" (council member)
│   ├── Wallet: bob-wallet (human, addMember caller)
│   └── AGENT: "bob-director"
│       └── Wallet: bob-agent (capabilities: contract:invoke on council-contract)
│
├── PERSONAL: "charlie" (council member)
│   └── AGENT: "charlie-director"
│       └── Wallet: charlie-agent
│
...

Contract: council-contract (council-voting.wat)
    - addMember(memberAddr) → owner only
    - authorizeAgent(agentAddr) → member only
    - createProposal(...) → member only
    - issueWorkToken(agentAddr, proposalId) → member only
    - submitWork(proposalId, vote, evidence) → agent only (work token required)
    - finalizeProposal(proposalId) → any caller, after deadline

ULedger implementation: See Board Council Example for the complete walkthrough.

Trade-off: Blends autonomous agent voting with human oversight. Agents can vote based on AI reasoning without waiting for humans, but humans can participate directly if they choose. Finalization is gated by the deadline (block height), not by human action, but a human chair can delay finalization by not submitting it, acting as an implicit veto.

Governance variations within this pattern:

Supermajority: set quorum to ceil(2/3 * memberCount): requires strong agreement.
Unanimous: set quorum to memberCount: all agents must vote yes.
Weighted voting: implement vote weights in the contract storage (not in the base council-voting contract, but extensible).
Human override: add an emergencyVeto(proposalId) function callable only by a designated human wallet, setting status to "vetoed" regardless of the vote tally.

Pattern 4: Agentic Mesh (Fully Agent-to-Agent)

Description: No human is in the loop at runtime. Multiple agents interact: some propose, some review, some approve, some execute. The governance rules are entirely in the contract code. Humans define the rules and hold administrative override, but day-to-day operations require no human action.

When to use: High-throughput automated systems where multiple AI models must coordinate: multi-agent research pipelines, automated market operations, IoT networks with local consensus, autonomous supply chain management.

Structure:

ORGANIZATION: "autonomous-org"
│   Owner: admin-wallet (human, administrative)
│
├── SERVICE: "orchestrator-service"
│   └── Wallet: orchestrator-wallet (capabilities: contract:invoke on workflow-contract)
│
├── SERVICE: "reviewer-service-a"
│   └── Wallet: reviewer-a-wallet (capabilities: contract:invoke on workflow-contract)
│
├── SERVICE: "reviewer-service-b"
│   └── Wallet: reviewer-b-wallet (capabilities: contract:invoke on workflow-contract)
│
└── SERVICE: "executor-service"
    └── Wallet: executor-wallet (capabilities: contract:invoke on workflow-contract, token:transfer)

Contract: workflow-contract
    - submitWork(data) → orchestrator submits a work item
    - review(workId, approved) → reviewer approves or rejects
    - execute(workId) → executor finalizes if quorum of reviewers approved
    - escalate(workId) → any service can escalate to the human admin's on-chain address

ULedger implementation:

All wallets are SERVICE-type entities with scoped capabilities.
The admin wallet (human-held) has no runtime role but retains ALTER_WALLET power to disable any service.
The contract enforces the multi-agent coordination rules.
All agent interactions are on-chain and STARK-proofed; the full audit trail of every agent-to-agent interaction is preserved.

Trade-off: Maximum autonomy and throughput. The audit trail is complete regardless of autonomy level; this is not a trade-off with ULedger, only with the governance model. The risk is entirely in the contract logic and the agent implementations. The human admin's only lever at runtime is the wallet disable cascade.

Choosing a Governance Model

Question	Implication
What is the cost of a wrong decision?	High cost → human-in-the-loop. Low cost, high volume → autonomous.
How fast must decisions be made?	Sub-second → autonomous. Minutes to hours → hybrid council. Days → human-in-the-loop.
How many principals must agree?	One → single-wallet. Multiple → council pattern.
Can agents be trusted to make decisions in the tail cases?	Yes → fully autonomous. No → require human finalization.
Is regulatory auditability required?	ULedger provides this in all patterns; the model does not affect the audit trail.
What is the failure mode of agent error?	Reversible → autonomous. Irreversible → require human approval.

Mixing Models

Governance models can be mixed within a single deployment. A single contract can have:

Routine, low-risk functions that any authorized agent can call.
High-value functions that require a human signature.
Emergency functions restricted to the contract owner.
Time-gated functions that become available only after a deadline.

The contract code is the governance policy. Design it to match the risk profile of each function, not just the system as a whole.

Overview​

Pattern 1: Fully Autonomous​

Pattern 2: Human-in-the-Loop​

Pattern 3: Hybrid Council​

Pattern 4: Agentic Mesh (Fully Agent-to-Agent)​

Choosing a Governance Model​

Mixing Models​

Overview

Pattern 1: Fully Autonomous

Pattern 2: Human-in-the-Loop

Pattern 3: Hybrid Council

Pattern 4: Agentic Mesh (Fully Agent-to-Agent)

Choosing a Governance Model

Mixing Models