# DAO Framework Alternatives: CLI-Deployable Governance for #B4mad

**Date:** 2026-02-21  
**Author:** Roman "Romanov" Research-Rachmaninov  
**Bead:** beads-hub-63e  
**Status:** Complete

## Abstract

Our initial DAO deployment strategy (Aragon OSx) is blocked because it requires browser-based UI interaction, which is incompatible with our agent-first architecture. This paper evaluates CLI/script-deployable alternatives and recommends **OpenZeppelin Governor deployed via Foundry** as the optimal path forward.

## Context

#B4mad Industries is building a DAO to govern its operations. The agent fleet (CodeMonkey, PltOps) must be able to deploy and interact with governance contracts entirely via CLI — no browser UI should ever be a blocker.

We already have:
- `B4MAD.sol` — our ERC20 token contract
- `MyVestingWallet.sol` — vesting contracts
- `b4mad-dao-contracts/` — local Hardhat/Foundry project with passing tests

## Frameworks Evaluated

### 1. OpenZeppelin Governor ✅ RECOMMENDED

- **CLI-deployable:** Yes, fully via Hardhat or Foundry
- **Documentation:** Excellent — the gold standard in Solidity
- **Battle-tested:** Used by major protocols (ENS, Compound, Uniswap governance)
- **Compatibility:** Same OpenZeppelin stack as our existing B4MAD.sol
- **Features:** Token-voting, timelocks, proposal thresholds, quorum, treasury via TimelockController
- **Upgrade path:** B4MAD.sol needs `ERC20Votes` + `ERC20Permit` extensions (~10 lines)

### 2. Compound Governor Bravo ❌

- Superseded by OpenZeppelin Governor (which absorbed its best ideas)
- Less flexible, more opinionated
- No reason to choose this over OZ Governor

### 3. Moloch v3 / DAOhaus ❌

- Complex architecture, heavily UI-dependent
- DAOhaus tooling assumes web UI interaction
- Overkill for our needs

### 4. Nouns-style Governor ❌

- Designed for ERC721 (NFT) voting, not ERC20
- Wrong token standard for B4MAD

### 5. Custom Contracts ❌

- Unnecessary risk when battle-tested frameworks exist
- Would require extensive auditing
- Our existing B4MAD.sol + MyVestingWallet.sol can plug into OZ Governor

## Recommendation

**OpenZeppelin Governor + Foundry** is the clear winner.

### Deployment Path (4 Steps)

**Step 1: Upgrade B4MAD.sol**
Add `ERC20Votes` and `ERC20Permit` extensions:
```solidity
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol";
import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
```

**Step 2: Deploy Governor Contract**
Create `B4MADGovernor.sol` extending:
- `Governor`
- `GovernorSettings` (voting delay, period, threshold)
- `GovernorCountingSimple` (for/against/abstain)
- `GovernorVotes` (connects to B4MAD token)
- `GovernorTimelockControl` (treasury protection)

**Step 3: Deploy TimelockController**
The timelock acts as the treasury and execution layer:
- Proposers: the Governor contract
- Executors: anyone (after timelock passes)
- Admin: initially deployer, then renounced

**Step 4: Deploy via Foundry script**
```bash
forge script script/DeployDAO.s.sol --rpc-url $RPC_URL --private-key $PRIVATE_KEY --broadcast
```

### Optional Phase 0: Gnosis Safe Multisig
As interim governance before token distribution:
- Deploy a Gnosis Safe (goern + 2 signers)
- Use as treasury and admin
- Transition to token voting when ready

## References

- [OpenZeppelin Governor Docs](https://docs.openzeppelin.com/contracts/5.x/governance)
- [Foundry Book](https://book.getfoundry.sh/)
- [Compound Governor](https://compound.finance/docs/governance)