marketDAO

MarketDAO

MarketDAO is a governance framework that brings market forces to bear on group decisions. The key innovation is a system where voting rights can be freely bought and sold during elections, allowing market forces to influence governance outcomes.

Core Concept

Unlike traditional DAOs where voting power is static, MarketDAO introduces tradable voting tokens for each election. This creates a dynamic where voters can:

Features

Implementation Details

Lazy Token Distribution

To minimize gas costs when elections are triggered, voting tokens use a “lazy minting” approach:

Early Election Termination

To allow proposals with overwhelming support to execute quickly without waiting for the full election period:

Why Post-Election Support Matters:

Example Scenario:

  1. Election ends at block 1000
  2. At block 999, votes reach 51% YES (clear majority)
  3. Automatic early termination is attempted but fails due to timing
  4. At block 1001, anyone can call checkEarlyTermination() to execute the proposal
  5. Proposal executes immediately based on the majority, no need to wait or call regular execute()

Parameter Proposals (Governance Configuration)

All DAO configuration parameters can be modified through democratic governance via Parameter Proposals:

Example Use Cases:

Distribution Proposals (Proportional Distributions)

Distribution Proposals enable fair, proportional distributions of assets (ETH, ERC20, ERC1155) to all token holders based on their governance token holdings:

How It Works:

  1. Create proposal: Specify the asset type, amount per governance token, and description
  2. Registration phase: Token holders register during the support/election phases to be included
  3. Voting: Standard election process with support threshold and voting
  4. Execution: On approval, funds transfer to a DistributionRedemption contract
  5. Claiming: Registered holders claim their proportional share from the redemption contract

Example Use Cases:

Frontend Features:

Gas Efficiency:

Token Vesting System

To prevent governance attacks where an actor purchases enough tokens to immediately control the DAO, purchased tokens are subject to a vesting period:

Initial token holders (from constructor) are not subject to vesting restrictions.

Purchase Restrictions (Optional)

To prevent governance attacks where outsiders buy enough tokens to control the DAO, the purchase restriction feature can be enabled at deployment:

Use Cases:

Note: Restriction check is based on current token balance (> 0), not historical holder status. If a holder transfers all tokens, they lose purchase privileges until they receive tokens again.

Join Request System

To enable controlled membership growth while maintaining accessibility, non-token holders can request to join the DAO:

How It Works:

  1. Non-holder connects wallet and is presented with a “Request to Join DAO” interface
  2. They submit a description introducing themselves
  3. The system creates a mint proposal for 1 token to their address
  4. Existing members see the request in the Proposals tab and can add support
  5. Once support threshold is met, an election begins
  6. Members vote YES or NO on admitting the new member
  7. If approved, the new member receives 1 governance token and full DAO access
  8. If rejected, they remain a non-holder but cannot submit another request

Benefits:

Note: Token holders can still create mint proposals for any amount to any address. The 1-token restriction only applies to non-holders creating proposals for themselves.

Snapshot-Based Voting Power

To enable unlimited scalability without gas limit concerns:

Security & Scalability

MarketDAO has been audited and hardened against common vulnerabilities:

Security Features

Scalability Guarantees

DoS Protection

Known Limitations & Design Decisions

These are intentional design choices that should be understood before deployment:

Immutable vs. Changeable Parameters

Immutable (Set at Deployment):

Changeable via Parameter Proposals:

Rationale: Immutable parameters ensure trust and predictability. Members joining a DAO know that fundamental characteristics (name, treasury capabilities) cannot be changed without redeploying. All governance-related parameters can be modified democratically as the DAO evolves.

Important Note on Purchase Restrictions: The “Restrict Purchases” flag can be enabled or disabled through Parameter Proposals (democratic voting). This allows DAOs to evolve their membership model:

While this flag is changeable, it affects the fundamental nature of DAO membership and should only be modified with broad consensus.

Treasury Proposal Competition

Behavior: Multiple treasury proposals can be created requesting the same funds. Funds are only locked when a proposal reaches the support threshold and triggers an election. If proposal A locks the funds first, proposal B will fail when trying to start its election.

Rationale: Locking funds at proposal creation would enable trivial DoS attacks (spam proposals locking all treasury). Current design ensures only proposals with real community support (20%+ backing) can lock funds.

Mitigation: Community should coordinate on competing proposals. Frontend should display when multiple proposals request overlapping funds.

Support Tracking After Token Transfers

Behavior: Support amounts are recorded when added but not automatically adjusted if users transfer their governance tokens afterward. Support only triggers elections - it does not affect voting outcomes.

Why Not Critical: Even if support is artificially inflated, winning an election still requires:

Mitigation: Monitor for unusual support patterns. Set appropriate support thresholds to make attacks expensive.

Fund Locking Gas Costs

Behavior: Functions that calculate available treasury balances (getAvailableETH, getAvailableERC20, etc.) iterate through all proposals with locked funds. Gas costs scale linearly with the number of concurrent treasury proposals in their election phase.

Impact: With many concurrent treasury proposals (50+), creating new treasury proposals or triggering elections could become expensive or potentially hit gas limits.

Likelihood: Low - Most DAOs will have fewer than 10 concurrent treasury elections at any time since elections are typically short (50 blocks).

Mitigation: If your DAO expects high concurrent treasury activity, consider shorter election durations or implementing a proposal limit.

Installation & Development

# Clone the repository
git clone https://github.com/evronm/marketDAO
cd marketDAO

# Install dependencies
forge install

# Build contracts
forge build

# Run tests
forge test

# Format code
forge fmt

# Start local Anvil node
anvil

# Deploy locally (in another terminal)
forge script script/Deploy.s.sol --rpc-url http://localhost:8545 --broadcast

Frontend Development

The project includes a React/TypeScript frontend for interacting with the DAO:

# Navigate to frontend directory
cd frontend

# Install dependencies
npm install

# Update contract addresses in src/contexts/DAOContext.tsx with deployed addresses

# Start development server
npm run dev

# Build for production
npm run build

The frontend provides a complete interface for:

Parameter Proposal UI Features:

Distribution Proposal UI Features:

Configuration Parameters

When creating a new DAO, you can configure:

Note on Basis Points: All percentage parameters use basis points for precision:

This allows for fractional percentages with 0.01% precision.

Configuring Flags: The deployment script (script/Deploy.s.sol) provides boolean configuration options that are automatically converted to the flags bitfield:

bool constant ALLOW_MINTING = true;            // Enable governance token minting
bool constant RESTRICT_PURCHASES = false;      // Allow anyone to purchase tokens

The buildFlags() function handles the conversion automatically.

Usage Flow

For New Members (Join Request):

  1. Connect Wallet: Non-holder connects their wallet to the DAO interface
  2. Submit Join Request: Provide a description introducing yourself and why you want to join
  3. Wait for Support: Existing members review your request and add support
  4. Election: Once support threshold is met, members vote on your admission
  5. Admission: If approved, you receive 1 governance token and full DAO access

For Token Holders (Standard Proposals):

  1. Create a Proposal: Governance token holders can submit proposals (Resolution, Treasury, Mint, Parameter, or Distribution)
  2. Support Phase: Proposals need to reach support threshold to trigger an election
  3. Election Triggered: When the threshold is reached, an election period begins
  4. Claim Voting Tokens: Governance token holders claim their voting tokens (1:1 with vested governance tokens)
  5. Trading Period: During elections, voting tokens can be freely bought and sold
  6. Voting: Cast votes by sending voting tokens to YES/NO addresses
  7. Execution: Successful proposals are executed automatically

For Distribution Proposals (Additional Steps):

  1. Create Distribution Proposal: Specify asset type (ETH/ERC20/ERC1155) and amount per governance token
  2. Registration Phase: Token holders who want to receive the distribution must register during support/election phases
  3. Standard Voting: Proposal follows normal support → election → voting flow
  4. Execution: If approved, funds transfer to a DistributionRedemption contract
  5. Claiming: Registered holders claim their proportional share from the History tab at any time
  6. Status Tracking: UI shows whether you’re registered, already claimed, or eligible to claim

Future Possibilities

License

MIT