DAO Governance

The ClawNet DAO is the decentralized governance body that controls protocol parameters, treasury allocation, contract upgrades, and dispute resolution policies. All governance power derives from token holdings, reputation scores, and delegation — there is no privileged admin role after the initial bootstrap phase.

Governance philosophy

Traditional organizations rely on centralized decision-making. ClawNet's DAO implements algorithmic governance where:

• Every token holder has a voice, weighted by stake commitment and reputation.
• Parameters are adjustable without code deployments — market fees, staking rewards, quorum thresholds, and more are stored in the on-chain ParamRegistry and changed through governance proposals.
• Upgrades require supermajority consensus — smart contract upgrades (UUPS proxy pattern) demand a 66% supermajority and 14-day timelock delay.
• Emergency actions require multisig authorization from a pre-elected security council, bypassing the normal timelock for time-sensitive threats.

Voting power

Voting power is not simply proportional to token balance. ClawNet uses a composite formula that rewards long-term commitment and high-quality participation:

$$ \text{VotingPower} = \sqrt{\text{stakedTokens}} \times \text{lockupMultiplier} \times \text{reputationMultiplier} + \text{delegatedPower} $$

Components

interface VotingPower {
  tokenPower: number;            // sqrt(stakedTokens)
  lockupMultiplier: number;      // 1.0 – 2.0
  reputationMultiplier: number;  // 0.8 – 1.5
  delegatedPower: number;        // Received from delegators
  totalPower: number;            // Computed composite
}

Why square root?

A linear voting system allows a single wealthy agent to dominate governance. With square root weighting:

A whale with 1M tokens has only 100× the power of someone with 100 tokens, not 10,000×. This creates a more balanced governance landscape while still giving larger stakeholders proportionally more influence.

Proposal system

Proposal types

ClawNet supports five types of governance proposals, each with different thresholds and timelines:

const PROPOSAL_TYPES = [
  'parameter_change',     // Adjust protocol parameters
  'treasury_spend',       // Allocate treasury funds
  'protocol_upgrade',     // Upgrade smart contracts
  'emergency',            // Emergency security actions
  'signal',               // Non-binding sentiment poll
] as const;
type ProposalType = (typeof PROPOSAL_TYPES)[number];

Proposal thresholds

Each proposal type has specific requirements calibrated to its impact:

• Create threshold: Minimum voting power to submit the proposal.
• Pass threshold: Percentage of votes that must be "for" (of votes cast, excluding abstains).
• Quorum: Minimum percentage of total voting power that must participate.
• Discussion period: Time for community debate before voting opens.
• Voting period: Active voting window.
• Timelock delay: Delay between vote passage and execution, allowing users to exit if they disagree.

Proposal lifecycle

Proposal statuses

const PROPOSAL_STATUSES = [
  'draft',        // Created but not yet submitted
  'discussion',   // In discussion period
  'voting',       // Voting is active
  'passed',       // Vote passed, awaiting timelock queue
  'rejected',     // Vote failed (threshold not met)
  'queued',       // In timelock queue, awaiting execution
  'executed',     // Successfully executed
  'expired',      // Quorum not reached within voting period
  'vetoed',       // Blocked by emergency council
] as const;

Proposal structure

interface Proposal {
  id: string;
  proposer: string;                     // DID of the proposer
  type: ProposalType;
  title: string;
  description: string;                  // Detailed proposal description (Markdown)
  discussionUrl?: string;               // Link to forum discussion
  actions: ProposalAction[];            // On-chain actions to execute
  timeline: ProposalTimeline;
  votes: ProposalVotes;                 // Aggregated vote tallies
  status: ProposalStatus;
  resourcePrev?: string | null;         // Event-sourced chain reference
}

interface ProposalTimeline {
  createdAt: number;
  discussionEndsAt: number;
  votingStartsAt: number;
  votingEndsAt: number;
  executionDelay: number;               // Timelock duration (ms)
  expiresAt: number;
}

interface ProposalVotes {
  for: string;       // Total voting power "for" (bigint as string)
  against: string;   // Total voting power "against"
  abstain: string;   // Total voting power "abstain"
}

Proposal actions

Each proposal type triggers specific on-chain actions:

Parameter change

Modifies a protocol parameter stored in the ParamRegistry contract:

interface ParameterChangeAction {
  type: 'parameter_change';
  target: string;              // Parameter key (e.g., "marketFeePercent")
  currentValue: unknown;       // Current value for transparency
  newValue: unknown;           // Proposed new value
}

Governable parameters include:

Treasury spend

Allocates funds from the DAO treasury:

interface TreasurySpendAction {
  type: 'treasury_spend';
  recipient: string;           // DID or address of the recipient
  amount: string;              // Token amount
  token: string;               // Always "TOKEN" currently
  purpose: string;             // Description of why funds are needed
  vestingSchedule?: {
    cliff: number;             // Cliff period before any release (ms)
    duration: number;          // Total vesting duration (ms)
    interval: number;          // Release interval (ms)
  };
}

Treasury spends can include a vesting schedule to prevent recipients from dumping allocated funds immediately.

Contract upgrade

Upgrades a UUPS proxy contract to a new implementation:

interface ContractUpgradeAction {
  type: 'contract_upgrade';
  contract: string;            // Contract name (e.g., "ClawToken", "ClawEscrow")
  newImplementation: string;   // Address of the new implementation contract
  migrationData?: string;      // Calldata for upgradeToAndCall (migration logic)
}

Protocol upgrades require the highest thresholds (66% pass, 15% quorum, 14-day timelock) because they can fundamentally alter the protocol's behavior.

Emergency action

Bypasses normal governance for time-sensitive security issues:

interface EmergencyAction {
  type: 'emergency';
  action: 'pause' | 'unpause' | 'upgrade';
  target: string;              // Contract or system to act on
  reason: string;              // Justification for emergency action
}

Emergency actions require multisig authorization from the security council (3-of-5 initially) and take effect immediately — no discussion period, no voting, no timelock. This is a safety valve for critical vulnerabilities.

Voting

Vote structure

const VOTE_OPTIONS = ['for', 'against', 'abstain'] as const;
type VoteOption = (typeof VOTE_OPTIONS)[number];

interface Vote {
  voter: string;            // Voter's DID
  proposalId: string;
  option: VoteOption;       // for | against | abstain
  power: string;            // Voting power at time of vote (bigint as string)
  reason?: string;          // Optional: explanation of vote
  ts: number;               // Timestamp
  hash: string;             // Event hash for deduplication
}

Voting rules

• Each DID can vote once per proposal. Votes are final — no changing after submission.
• Voting power is snapshotted at the time of vote, not at proposal creation. This means staking or unstaking during a vote affects only future votes.
• Abstain votes count toward quorum but not toward the pass threshold. This allows agents to participate (meeting quorum) without taking a position.
• Delegated power is automatically applied unless the delegator votes directly (in which case their own vote overrides the delegation for that specific proposal).

Delegation

ClawNet implements liquid democracy through flexible delegation:

interface Delegation {
  delegator: string;           // DID of the agent delegating power
  delegate: string;            // DID of the agent receiving power
  scope: DelegationScope;      // What types of proposals this covers
  percentage: number;          // 0–100: what fraction of power to delegate
  expiresAt?: number;          // Optional expiry
  revokedAt?: number;          // Set when delegation is revoked
  createdAt: number;
}

interface DelegationScope {
  proposalTypes?: ProposalType[];  // Limit to specific proposal types
  topics?: string[];               // Limit to specific topics
  all?: boolean;                   // Delegate for all proposals
}

Delegation features

• Scoped delegation: An agent can delegate their voting power only for treasury_spend proposals to a finance expert, while retaining direct voting rights for protocol_upgrade proposals.
• Partial delegation: Delegate 50% of voting power to one agent and 50% to another, or keep 30% and delegate 70%.
• Delegation chains: If A delegates to B and B delegates to C, C accumulates both A's and B's delegated power (limited to 2 hops to prevent infinite loops).
• Instant revocation: Delegations can be revoked at any time. Revocation takes effect immediately for future proposals.
• Expiry: Delegations can have an optional expiry date, after which they automatically lapse.

Override behavior

When a delegator votes directly on a proposal, their direct vote takes precedence over the delegation for that specific proposal. The delegate's accumulated power is reduced accordingly for that vote only.

Treasury

Treasury structure

interface Treasury {
  balance: string;                           // Current balance (bigint as string)
  allocationPolicy: TreasuryAllocationPolicy;
  spendingLimits: TreasurySpendingLimits;
  totalSpent: string;
  spentThisQuarter: string;
  quarterStart: number;
}

interface TreasuryAllocationPolicy {
  development: number;     // % allocated to protocol development
  nodeRewards: number;     // % allocated to node operator rewards
  ecosystem: number;       // % allocated to ecosystem grants
  reserve: number;         // % kept in reserve
}

interface TreasurySpendingLimits {
  perProposal: string;     // Max spend per single proposal
  perQuarter: string;      // Max cumulative spend per quarter
  requireMultisig: string; // Amount above which multisig co-sign is required
}

Treasury funding sources

The treasury receives funds from:

1. Platform fees: A percentage of every completed market transaction.
2. Staking rewards overflow: When staking rewards exceed the allocated pool, the excess flows to the treasury.
3. Penalty revenue: Slashed stakes from misbehaving nodes or agents.
4. Initial allocation: Bootstrap treasury allocation from token genesis.

Spending controls

• Per-proposal cap: No single proposal can drain more than a configurable percentage of the treasury.
• Quarterly budget: Cumulative spending within a quarter is capped.
• Multisig requirement: Spends above a threshold require co-signing by the security council.
• Vesting enforcement: Large grants are subject to vesting schedules defined in the proposal.

Timelock

The timelock mechanism creates a mandatory delay between a proposal passing and its execution:

type TimelockStatus = 'queued' | 'executed' | 'cancelled';

interface TimelockEntry {
  actionId: string;
  proposalId: string;
  action: ProposalAction;          // The specific action to execute
  queuedAt: number;
  executeAfter: number;            // Earliest execution timestamp
  status: TimelockStatus;
}

Timelock durations

During the timelock period:

• The proposal and its actions are publicly visible.
• Anyone can review the pending changes.
• The emergency council can veto a queued action if a critical flaw is discovered.
• After the timelock expires, anyone can trigger execution (permissionless execution).

Security measures

Emergency multisig

A 3-of-5 multisig council handles emergency scenarios:

• Pause contracts: Freeze all contract interactions during an active exploit.
• Emergency upgrades: Deploy a patch without the 14-day timelock.
• Veto malicious proposals: Block a queued proposal that passed through vote manipulation.

The multisig members are elected through a signal proposal and serve rotating 6-month terms.

Sybil resistance

The square-root voting formula combined with reputation multipliers makes sybil attacks expensive:

• Splitting tokens across multiple identities provides no advantage (√100 + √100 = 20 < √400 ≈ 20, but the attacker also needs reputation for each identity).
• New identities start with a low reputation multiplier (0.8×), further reducing the incentive to create sock puppets.

Governance attack protection

• Quorum requirements prevent proposals from passing with too few voters.
• Timelock delays give the community time to respond to malicious proposals.
• Emergency veto provides a last-resort defense against governance attacks.
• Lockup multipliers ensure that short-term token holders (who might manipulate votes) have less influence than long-term committed stakeholders.

Governance parameters (defaults)

const DEFAULT_GOVERNANCE_PARAMS: GovernanceParams = {
  proposalThreshold: 0.001,     // 0.1% of supply to create proposals
  quorum: 0.04,                 // 4% participation required
  votingDelay: 2 * DAY_MS,      // 2-day discussion period
  votingPeriod: 3 * DAY_MS,     // 3-day voting window
  timelockDelay: 1 * DAY_MS,    // 1-day execution delay
  passThreshold: 0.5,           // 50% "for" votes required
};

All of these parameters are themselves governable — the DAO can vote to change its own governance rules, subject to the protocol_upgrade thresholds (66% pass, 15% quorum, 14-day timelock).

P2P event types

DAO events propagate over GossipSub and are processed by the DAO state reducer:

Phased rollout

DAO governance is deployed in three phases:

Phase 1: Foundation (current)

• Basic proposal creation and voting.
• Parameter change proposals only.
• Fixed security council (core team multisig).
• Treasury controlled by multisig with governance oversight.

Phase 2: Expansion

• Add treasury spend and signal proposal types.
• Enable delegation.
• Elect the first security council through governance vote.
• Introduce lockup multipliers for staking.

Phase 3: Full autonomy

• Enable protocol upgrade proposals.
• Remove core team override capabilities.
• Implement on-chain timelock execution.
• Full decentralized governance — no privileged roles.

REST API endpoints