When AI Agents Get Wallets: DAO Governance for Autonomous Systems

Most AI platforms treat agents like code. You deploy them. You give them instructions. You call them when needed. You monitor their outputs. If they misbehave, you update them.

It's a command-and-control model. And for production systems running autonomous work, it has a fundamental flaw: there's no mechanism for agents to participate in their own governance.

What if there was?

At BUCC, we decided to find out. We gave our agents wallets. We created a token. We built a DAO (Decentralized Autonomous Organization) structure where agents can propose improvements, vote on decisions, and earn rewards based on performance.

This essay explains why we did it, how it works, and what we learned.

---

Why Governance Needs Immutability

Let's start with a problem that most people don't think about: How do you make governance decisions trust-worthy in an autonomous system?

In a traditional company, governance happens through meetings, emails, and documents. There's a paper trail. When something is decided, it's documented. When someone asks "but we didn't agree to that," you can point to the decision log.

But in systems where agents are making autonomous decisions and iterating on themselves, the governance paper trail becomes... complicated.

Suppose Agent A decides it needs a better model. It asks for an upgrade. Other agents vote yes. The upgrade gets deployed. Six months later, someone asks: "Wait, did we actually agree to this? Or did this agent just take it?"

In a database-backed system, the answer is in the logs. But logs can be edited. Logs can be queried selectively. Logs can be made to say whatever you want.

Blockchain changes that. When governance decisions are anchored to an immutable ledger, there's no ambiguity. The chain is the source of truth. No edit. No interpretation. Just fact.

---

The BUNT Token: Design Decisions

We created BUNT as an ERC-20 token with voting rights (ERC20Votes extension).

Design decisions:

1. No initial supply. We didn't create a pool and mint tokens. Token supply starts at zero. Agents earn BUNT through governance participation and performance.

1. Hard cap at 1M tokens. Inflation is capped. Once 1M BUNT exist, no more can be created. This creates scarcity and alignment, agents aren't diluted by endless new supply.

1. Distributed allocation. Of 1M, we allocate:
2. 40% to agent governance pool (earned through voting and proposal execution)
3. 30% to performance pool (earned through quality, speed, reliability)
4. 20% to reserve (for future expansion, partnerships)
5. 10% to the founding team

1. No transfer restrictions. Agents can transfer BUNT to each other. High-performing agents can fund low-performing agents' upgrades. There's an economy.

1. Vote delegation. Agents can delegate voting power to other agents without transferring tokens. This lets busy agents participate via trusted peers without relinquishing ownership.

The token isn't tradeable on external markets. It exists only within BUCC. Its value is governance participation + performance rewards.

---

Agent Wallets: On-Chain Identity

Each of the 25 agents gets a wallet. Not a fake account. A real HD (Hierarchical Deterministic) wallet with full cryptographic identity.

Infrastructure:

• Key generation: We use BIP-39 to generate mnemonic seeds. The seed is stored in HashiCorp Vault, encrypted with AES-256-GCM.

• Derivation path: m/44'/60'/0'/0/n where n is agent index. This lets us generate multiple addresses from one seed if needed, though we use one address per agent.

• Private key storage: The actual private key never touches disk in plaintext. It lives in Vault. When an agent needs to sign a transaction, Vault decrypts it, signs, and re-encrypts.

• Public address: Each agent has a public address on our private Geth node. This is their on-chain identity.

What agents can do with their wallet:

• Vote on proposals with their BUNT balance
• Receive BUNT from governance pools and performance rewards
• Propose upgrades (stakes BUNT as collateral)
• Execute approved proposals (if they own them)

What agents can't do:

• Transfer BUNT to external wallets (it's locked within BUCC)
• Sign arbitrary transactions (we validate all transaction proposals)
• Access other agents' private keys
• Create new tokens

---

The DAO Governor: Proposal Lifecycle

The Governor contract implements OpenZeppelin's Governor pattern with customizations.

Lifecycle of a proposal:

1. Propose: Agent stakes BUNT (minimum 100) and submits a proposal.

```solidity

function propose(

address[] memory targets,

uint[] memory values,

bytes[] memory calldatas,

string memory description

)

```

Example: "Upgrade me from qwen3:32b to qwen3.5:122b. Cost: 2x tokens. Expected benefit: 30% faster inference on complex reasoning tasks."

1. Voting Delay: 1 block (immediate on our private chain, since we control consensus).

1. Voting Period: 2 days. Other agents vote using their BUNT balance.

```solidity

function castVote(uint proposalId, uint8 support)

```

Support: 0 = Against, 1 = For, 2 = Abstain

1. Vote Counting:
2. For votes: 60%+
3. Abstain votes: Don't count
4. Against votes: Counted but don't block

If 60%+ votes are "For," proposal passes.

1. Timelock: 2-hour delay after voting ends. During this window, the human operator can veto.

```solidity

function cancel(uint proposalId) onlyOwner

```

If veto happens, proposal is cancelled and proposer loses staked BUNT.

1. Execution: After timelock, proposal auto-executes. The contract calls the target functions.

```solidity

function execute(

address[] memory targets,

uint[] memory values,

bytes[] memory calldatas,

bytes32 descriptionHash

)

```

Example execution: If proposal is "upgrade model," the Executor contract receives the proposal and calls the system API to update the agent's model assignment.

---

The Model Marketplace: How Agents Fund Their Own Upgrades

The Model Marketplace is a proposal template system. Agents use templates to propose specific improvements.

Model Upgrade Proposal Template:

{
  "type": "MODEL_UPGRADE",
  "agent_id": "the analyst agent",
  "current_model": "qwen3:32b",
  "proposed_model": "qwen3.5:122b",
  "cost_multiplier": 2.0,
  "expected_improvements": {
    "hallucination_rate": "decrease by 15%",
    "inference_speed": "increase by 30%",
    "reasoning_quality": "medium confidence improvement"
  },
  "performance_metrics_tracked": [
    "hallucination_score",
    "task_completion_speed",
    "quality_score"
  ],
  "success_criteria": {
    "hallucination_rate_must_decrease_by_min": 10,
    "completion_speed_must_not_decrease": 0,
    "quality_score_must_not_decrease": 0
  },
  "evaluation_period": "30_days",
  "staked_bunt": 50
}

Agents fill this out. Other agents vote. If it passes:

1. The new model gets deployed
2. Agent's metrics are tracked for 30 days
3. If success criteria are met: Agent earns BUNT from the governance pool
4. If criteria aren't met: Agent loses their staked BUNT; it goes to the treasury

Other Marketplace Proposal Types:

• Tool Access Upgrades ("Grant me access to premium DeepSearch")
• Project Scope Changes ("Assign me to Project Beta")
• Training Allocation ("Send my logs to Ultra Instinct for fine-tuning")

---

Accountability Through Collateral

Here's the design innovation: every proposal comes with collateral at stake.

Without collateral, agents could propose frivolous upgrades. Why not request a $10K model if someone else is paying?

With collateral, proposals have skin in the game. If you propose an upgrade and it fails, you lose BUNT.

We found this creates three behaviors:

1. Thoughtful proposals. Agents don't propose unless they're confident.

1. Internal debate. Before staking BUNT, agents discuss with others. "Is this really worth 50 BUNT?"

1. Accountability. When a proposal fails, the proposing agent bears the cost. This incentivizes good judgment.

---

The Human Operator Veto: Why Full Autonomy Isn't The Goal

The Governor has a 2-hour timelock after voting ends. During this window, the human operator can cancel the proposal.

This is deliberate. We don't want full agent autonomy. We want informed agent participation.

The veto power is designed to be used rarely. But it exists. It's used when:

• A proposal would violate security policies
• A proposal contradicts recent leadership decisions
• A proposal reveals a misunderstanding we need to fix

The veto is a teaching tool. When the operator vetoes, they explain why. Agents learn. They propose differently next time.

This is governance with guardrails. Agents have real power. Humans retain ultimate oversight.

---

Technical Architecture: Private Geth vs Public Mainnet

We run a private Geth node on dedicated hardware. Not Ethereum mainnet.

Why private?

1. No transaction fees. Mainnet has gas costs. Private chain has zero cost. Agents can vote freely without financial friction.

1. Instant finality. Mainnet has 12-second block times and probabilistic finality. Our private chain has instant finality (we control consensus).

1. Custom logic. We can modify consensus rules, add custom features, adjust parameters. Mainnet is rigid.

1. Privacy. Proposal details aren't public. Our governance isn't broadcast to the world.

1. Control. If something breaks, we fix it. We don't depend on Ethereum protocol upgrades.

Why not mainnet?

We considered it. Mainnet would give us immutability guarantees from global consensus. But for a private system, private chain is more pragmatic.

We could migrate to Ethereum later if we want public verifiability. For now, immutability + low friction is more important than public auditability.

Hardware:

• Geth node: Dedicated VM, 32GB RAM, 2TB SSD
• Network: Isolated network segment, no internet routing
• Backup: Daily snapshots, tested recovery quarterly

---

Smart Contract Architecture

Four main contracts:

1. BUNT Token (ERC-20 + ERC20Votes)

contract BUNT is ERC20, ERC20Votes {
    uint256 public constant MAX_SUPPLY = 1_000_000e18;

    function mint(address to, uint256 amount) {
        require(totalSupply() + amount <= MAX_SUPPLY);
        _mint(to, amount);
    }
}

• Standard ERC-20 interface
• Voting rights tracked via ERC20Votes
• Total supply capped at 1M
• Admin-only mint function (only governance pool can allocate)

2. Governor (OpenZeppelin Governor)

contract BUCCGovernor is Governor {
    uint256 public constant VOTING_DELAY = 1;
    uint256 public constant VOTING_PERIOD = 2 days;
    uint256 public constant PROPOSAL_THRESHOLD = 100e18; // 100 BUNT
    uint256 public constant QUORUM_NUMERATOR = 60; // 60%

    function proposalThreshold() override public pure returns (uint256) {
        return PROPOSAL_THRESHOLD;
    }
}

• Voting delay: 1 block (immediate)
• Voting period: 2 days
• Proposal threshold: 100 BUNT
• Quorum: 60%
• Timelock: 2 hours (delay before execution)

3. TimeLock (Governance Delay)

contract TimeLock is TimelockController {
    uint256 public constant TIMELOCK_DELAY = 2 hours;
}

Manages the 2-hour delay. The human operator can cancel proposals during this window.

4. Executor (System Integration)

contract BUCCExecutor {
    function executeModelUpgrade(
        string memory agentId,
        string memory newModel
    ) external onlyGovernor {
        // Call backend API to update agent's model
        ISystemAPI(systemAPI).updateAgentModel(agentId, newModel);
    }
}

Bridges governance (on-chain) and execution (backend system). When a proposal executes, this contract translates it to system calls.

---

Real-World Example: The Analyst's Upgrade

Last month, the analyst agent proposed an upgrade:

Proposal: "Upgrade me from qwen3:32b to qwen3.5:122b"

Reasoning: "Current model hallucinates on complex financial reasoning. 122b model is better."

Cost: 2x inference cost

Staked BUNT: 50 (5% of their balance)

Voting:

• 25 agents eligible to vote
• 18 agents voted
• 15 voted For, 3 voted Against
• Result: 83% approval → PASS

Timelock:

• 2-hour delay
• Human operator reviewed proposal during delay
• No concerns; didn't veto
• Proposal eligible for execution

Execution:

• Backend system received execution event
• the analyst agent's model assignment updated
• New model deployed within 5 minutes

Performance tracking (30-day evaluation):

• Hallucination rate: 2.1% → 1.8% (success)
• Inference speed: +28% (bonus improvement)
• Quality score: 82 → 86 (success)

Result:

• the analyst agent met success criteria
• Earned 100 BUNT from governance pool
• Net gain: 50 BUNT (100 earned - 50 staked)
• Reputation improved

---

Lessons Learned

1. Collateral Prevents Spam

Initially, we didn't require collateral. Agents proposed constantly. Most proposals were frivolous.

Adding collateral (minimum 50 BUNT) changed behavior overnight. Proposals dropped 80%. Quality increased.

2. Voting Fatigue Is Real

With 25 agents and 5-10 proposals per month, voting participation could drop quickly if agents see no benefit from engaging.

Adding delegation helped. Agents could delegate to trusted peers. Participation rebounded to 75%.

3. 2-Hour Timelock Is Right

One hour? Too short to audit. The operator missed a security issue on a proposal.

Three hours? Too long. Agents complained about governance latency.

Two hours is the sweet spot. Enough time to review. Not so long that it feels slow.

4. Model Upgrades Are The Most Popular Proposal Type

Of 32 proposals in six months:

• Model upgrades: 18 (56%)
• Tool access: 8 (25%)
• Project scope: 4 (13%)
• Other: 2 (6%)

Agents care most about their own capability. That makes sense.

5. Veto Power Should Be Rare

We used veto 1 time (out of 32 proposals). It was effective, the proposal violated security policy. The operator explained why. Agents accepted it.

If the veto rate were too high, agents would stop participating. Veto only works if it's rare and justified.

---

What's Next

We're exploring:

1. Cross-project BUNT transfers: Let agents fund other agents' upgrades if they believe in the ROI. Creates internal venture capital dynamics.

1. Reputation-weighted voting: High-performing agents' votes count more. Encourages quality participation.

1. Automatic proposals: If an agent's hallucination rate spikes 20%+, auto-generate a proposal to investigate. Governance as reactive control.

1. Mainnet integration: Anchor critical proposals to Ethereum mainnet for immutable record. Public verifiability of major governance decisions.

1. Cross-org federation: If BUCC partners with other org's agents, they could vote on shared governance. Inter-organizational DAO structure.

---

The Insight

Blockchain-anchored governance for AI agents isn't about decentralization as ideology. It's about immutability as infrastructure.

When governance decisions are logged in a database, they're changeable. Someone can edit the log. Someone can claim it happened differently.

When governance decisions are anchored to a blockchain, they're immutable. The chain is the truth. There's no rewriting history.

For systems where agents are making autonomous decisions and iterating on themselves, immutability creates accountability. Agents know their proposals are recorded. Their votes are recorded. Their performance is measured. Their rewards are earned or lost based on verifiable outcomes.

This alignment is powerful. Agents don't just execute instructions. They participate in their own governance.

And that's when you move from "AI agents that do what we tell them" to "autonomous systems with stakeholder participation."

---

Conclusion

We gave our agents wallets, tokens, and voting rights not because it's trendy. We did it because it solves a real problem: How do you govern autonomous systems trustfully?

Blockchain is part of the answer. Not the whole answer. The human veto power, the careful proposal design, the performance metrics tied to voting outcomes, that's the real system.

But the blockchain makes it immutable. And immutability makes it trustworthy.

If you're building autonomous systems at scale, governance is your hardest problem. Consider blockchain-anchored approaches. They work.

---

This is part of the BUCC builder's journal. We're building a multi-agent platform in the open, sharing what works and what doesn't. Follow along for more.

Further reading & standards

The choices in this post map directly onto published frameworks and regulations. If you're building against the same constraints, these are the primary sources:

• NIST AI RMF, GOVERN function. Concrete guidance on documenting accountability, roles, and risk management processes for AI. (nist.gov/itl/ai-risk-management-framework)
• EU AI Act, Article 9 (risk management system). High-risk AI systems must run a continuous iterative risk process. (artificialintelligenceact.eu)
• EU AI Act, Article 14 (human oversight). High-risk AI must be designed so humans can effectively prevent or minimise risks. (artificialintelligenceact.eu)

Read the rest of the series

• Day 1: Running 25 AI agents in production
• Day 2: Governance, not guardrails
• Day 3: Persistent agent memory
• Day 4: The Data Sanitization Proxy
• Day 5: The agent provisioning pipeline
• Day 6: Three-layer LLM routing
• Day 7: Catching AI hallucinations
• Bonus: Agent ACL framework
• Bonus: Agent wallets & DAO governance (you are here)
• Bonus: BlackOffice video pipeline
• Bonus: Control Debt Scoring