Policy upgrades

What a “policy upgrade” is (and isn’t)

A policy upgrade is a bounded parameter change that makes the rail easier to operate—without touching the settlement law. EDM holders can tune checklists, clocks, splits, and templates; they cannot change the brakes:

• No EMT, no funds

• One-Claim (atomic reserve→finalize)

• Must-fund before shipping (top-up after Pre-Ship EMT)

• 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 $5k / $25k / $50k caps

These are not vote-tunable.

What EDM holders can change

We group tunables by surface. Every dial is stored in a ParameterStore with min/max bounds and rate-limits (small step sizes), so no proposal can swing the system.

• Marketplaces (Trade & Tokens)

  • Buyer review window per lane (e.g., 0–4h)

  • Top-up deadlines (e.g., T-12h…T-72h before On-Board)

  • Payout schedules within bands (e.g., choose 20/60/20 vs 20/10/70; total must equal 100%)

  • Open-order limits per tier (B0/B1/B2), assignment caps per seller tier (S0→S2)

  • Explorer visibility (fields on proof pages/receipts), never the amounts

• PoV layer

  • Schema templates (add/retire versions; never mutate a published version)

  • Role quorums and freshness windows per schema (tighten/relax within bounds)

  • Tolerance/variance tables (short-shipment, damage, shelf-life, cold-chain bands)

  • ZK statement allowlist and verifying-key hashes (privacy page governs specifics)

• Attestors

  • SLA thresholds, reward weights, rotation cadence

  • Bond sizes and penalty bands for bonded roles

  • Fallback quorum templates (short-term alternates if a role is down)

• Treasury (non-burn half only)

  • Split across attestors / network ops / builders / ecosystem / stakers within bands

  • Treasury interest reporting cadence and the allowed range for the T-bill/cash ladder (the ~75% / 25% policy)

• L2/Sequencer hygiene (not economics)

  • Inclusion lists for critical calls (EMT mint, release, forced exit)

  • Status page thresholds (block delay, batch lag, inbox depth alarms)

What a policy upgrade looks like

1. Draft (EDIP) — what changes, why users benefit, exact before/after values, bounds proof.

2. Temperature check — public feedback from buyers, sellers, attestors.

3. On-chain vote — EDM holders (or delegates) vote; quorum + majority enforced.

4. Timelock (72h) — Explorer shows a diff; downstream systems can prepare.

5. Execute — Timelock updates the ParameterStore and (if needed) TreasurySplitter. Each param is versioned with effective_from.

• Safety rails: ParameterStore refuses values outside min/max; rate-limits prevent shock moves; staged activation supports safe rollouts.

Explorer shows: proposal text, bounds, before/after, ETA, block of execution, and the list of affected lanes/schemas.

Examples

• Tighten buyer review from 4h → 2h on the gloves lane after good pilot data.

• Advance top-up deadline from T-48h → T-24h, keeping must-fund intact.

• Switch payout to 20/10/70 for a route where risk is at destination QA.

• Raise cold-chain tolerance band by 0.5 °C for validated sensors (within max).

• Boost attestor SLA weight for INSPECTOR role after repeated on-time performance.

• Adjust treasury split (non-burn half) +5% to attestors, −5% to builders for a quarter (within bands), with public rationale.

What we never upgrade by policy

• Release money without PASS (no EMT → no funds)

• Reuse evidence (break One-Claim)

• Permit shipping before top-up (must-fund before shipping)

• Flip Locked EDSD → Unlocked EDSD without proof

• Reduce or delay the 50% burn of protocol fees, or change fee constants/caps

• Rewrite history (retract finalized claims or burns)

Such proposals are invalid and won’t enter the queue.

Emergency controls

• If a critical incident appears (e.g., bad key, mis-configured schema), governance may trigger a module-scoped pause for ≤72h—for example, “open new On-Board gates = paused.”

• Pauses are public (status page banner + Explorer event), scoped (one module/lane, not the whole rail), and followed by a normal proposal that permanently fixes the root cause.

• Pauses cannot move money, bypass PoV/One-Claim, or alter burns.

API & webhooks

• GET /v1/gov/params: current values, bounds, effective_from, last change.

• GET /v1/gov/proposals/{id}: text, diffs, votes, status, ETA.

Events:

• gov.proposal.created · gov.vote.cast · gov.proposal.queued · gov.proposal.executed

• gov.param.changed — includes param key, old/new, effective_from (systems can adapt automatically)

Operator impact

• You get a 72h heads-up with exact numbers and the block/UTC when they take effect.

• Open orders keep their current policy unless the change is marked forward-only; new orders use the new values from effective_from.

• The Explorer and ledgers show the parameter version used for each release/settlement so audit can replay with the right rules.

Plain recap

Policy upgrades on EDMA are parameter changes with brakes: bounded values, small steps, 72h timelock, public diffs, and clear effective_from. EDM holders can tune how proof is gathered, when reviews happen, and how the non-burn half is shared—never whether proof is required or burns occur. That’s how the rail improves without risking the law that keeps it trustworthy: facts first, then cash.