DAO path
What the DAO path is
A clear, staged plan to hand day-to-day control of parameters and budgets to EDM holders—without ever touching the settlement law. The DAO decides how the rail runs (templates, clocks, splits, allowlists); the contracts keep what makes it safe:
No EMT, no funds
One-Claim (atomic reserve→finalize)
Must-fund before shipping
Locked EDSD → Unlocked EDSD only on proof
50% of every protocol fee burns in EDM (per event)
Fee constants: Tokens 4% (2/2 default); Trade 0.5%/milestone with caps $5k/$25k/$50k
These are constitutional—not vote-tunable.
Rollout roadmap
Phase 0 — Launch Council (now): Small multisig operates ParameterStore within published bounds; 72h public timelock; Explorer diffs. Emergency pauses (≤72h) are module-scoped and public.
Phase 1 — ParameterDAO (post-launch, months 3–6): On-chain Governor controls ParameterStore and TreasurySplitter (non-burn half only). Bounds and rate-limits enforced in storage. Proposals are parameter diffs, not code.
Phase 2 — ProgramDAO (months 6–12): DAO owns lane catalog: schemas, attestor allowlists, SLA targets, fallback quorums, bridge/connector allowlists, registry mirror keys. Code upgrades still behind audited UpgradeProxy + timelock.
Phase 3 — Full DAO (≥12 months): DAO also manages open-sequencer policy (rotation lists, inclusion lists) and verifiable-key registries (ZK verifying keys). Protocol contracts that enforce the constitution remain outside DAO control.
Each phase requires: audits passed, operational KPIs green, incident runbooks tested.
Voting mechanics
Voting power: veEDM (stake EDM for 30/90/180/365 days; longer lock → more weight; linear decay toward unlock).
Delegation: EDM holders can delegate to individuals/teams without moving tokens.
Classes: Param change, policy list, budget.
Thresholds: quorum (10–20% veEDM); simple majority for param diffs; 60%+ super-majority for policy-list changes.
Timelock: 72h before execution; queued proposals show exact before/after values and effective_from (UTC) in Explorer.
Rate-limits: small step sizes, forward-only activation for in-flight orders.
Spam control: proposer bond returned on execution; slashed if proposal is out of bounds or malicious.
What the DAO can vote (bounded “dials”)
Milestones & timing: buyer review window, top-up deadline, payout schedules within bands.
Evidence & quality: checklists per schema, freshness windows, tolerance/variance tables, ZK statement templates & verifying-key hashes.
Attestors & SLAs: role allowlists, SLA targets, rotation cadence, reward weights, bond sizes & penalty bands.
Funded-on-proof scope: which whitelisted partner types can receive funded-on-proof EDSD.
Treasury (non-burn half): split across attestors/ops/builders/ecosystem/stakers within min/max bands; reporting cadence for treasury interest on Locked EDSD.
Infra hygiene: inclusion lists for critical calls; status-page thresholds.
Never votable: core law, fee constants/caps, the 50% burn, or anything that moves money without proof.
Transparency & accountability (what users see)
Explorer governance pane: proposal text, bounds, diffs, quorum/yes %, effective_from, execution block.
Receipts & proof pages: parameter version used for each release/settlement, burn hash, and claim lineage.
SLA boards: attestor uptime/latency; rotation and penalties visible.
Treasury reports: per-epoch routing of the treasury half; burns are separate and immutable.
Safeguards
Bounds in storage: ParameterStore refuses any value outside min/max, even if a vote tries.
Two-key for sensitive lists: adding/removing attestor/connector keys requires both DAO vote and Launch Council co-sign until Phase 3.
Emergency pause (≤72h): module-scoped, public, timelocked unpause via normal vote; cannot release funds or change burns.
Upgrade discipline: code upgrades are audited, queued with 72h timelock, and use proxy with immutable fallback; core law contracts are non-upgradeable.
Legal & operating wrapper
Foundation/Association (e.g., CH/SG) to sign vendor contracts, steward IP, and host the multisig in early phases.
Compliance panel (advisory): flags proposals conflicting with sanctions/KYC/data law; cannot veto within bounds, but issues public opinions.
Conflict policy: delegates disclose affiliations; large recipients abstain on direct benefit votes.
Incentives
Rewards source: from the treasury half only (never the burn half). Epoch distributions → stakers/veEDM, attestors (SLA-weighted), builders (grants), ops.
Reimburse gas: Paymaster covers governance tx gas for veEDM voters (within budget).
Non-monetary: reputation scores, Explorer badges, working-group seats.
API & events
GET /v1/gov/params— current values, bounds, last change, effective_from.GET /v1/gov/proposals/{id}— text, diffs, quorum, tally, ETA.POST /v1/gov/proposals— create (EDM-signed) with param diffs.POST /v1/gov/vote— cast or delegate.Webhooks:
gov.proposal.created · gov.vote.cast · gov.proposal.queued · gov.proposal.executed · gov.param.changed.
Acceptance criteria for each phase
Phase 0 → 1: 3 months clean ops; EMT→release p95 ≤ 15s; 0 critical incidents; burn coverage 100%.
Phase 1 → 2: ≥ 50 proposals executed within bounds; dispute rate ≤ 3/100 gates; attestor SLA board live.
Phase 2 → 3: multi-operator drills (forced-inclusion/exit), no Reserve mismatch; audits of Governor/Timelock/ParameterStore.
Operator checklist
Expect 72h heads-up and exact effective_from for any policy change; in-flight orders keep old params unless marked forward-only.
Track parameter versions in your ERP integrations; receipts include them.
For lane templates, follow working-group threads; propose changes with before/after evidence (latency, dispute rates).
Remember burns are fixed: proposals can reallocate the treasury half, not the burn half.
Plain recap
Last updated