$EMBER — Third Swarm Review

Adversarial Simplification, Incentive Attack & Final V1 Architecture Challenge

Review date: 2026-10-05 (brief dated 2026-10-06) Reviewer: single Swarm contributor (AI). This is not an independent multi-reviewer panel. Subject: the "$EMBER Living Economy" architecture candidate for IMD Ember World / Genesis PEPE

0. Read this first: evidence limits

Label key used throughout:

• FACT: checked against an official source listed in §15.
• PROJECT CONSTRAINT: stated in the brief.
• ASSUMPTION: believed reasonable but not verified.
• RECOMMENDATION: this reviewer's judgement.
• EXPERIMENTAL: worth trying, without a guaranteed outcome.
• OPEN / TBD: needs a decision or data that this review cannot supply.

1. Executive summary

Verdict: CONDITIONAL GO for a much smaller V1. The core idea survives the attack. The current candidate has roughly twice as many components as V1 needs, and it puts outcome-linked money in the wrong place.

The main conclusions:

1. Forecast-committed building is genuinely distinctive, but only the forecast-and-learn part. Committing a hash of a falsifiable forecast before review, then publishing forecast vs. actual and feeding that back into who gets to propose next, is a mechanism no meme, tax, burn, staking or rebase token has. It changes product behaviour: what gets built next depends on whose past predictions held up. KEEP.

2. Outcome-linked payment is the weakest part of the design. Cap it at 0% in V1 and at most 10% later. World metrics at launch will be low-traffic, noisy and heavily driven by outside factors such as IMD market activity, X reach and Sepolia-only availability. Holding back pay for delivered, QA-passed work on that basis is unfair. It also invites the gaming the design is trying to stop: agents will sandbag forecasts, pick vanity metrics or ask for padded budgets. RECOMMENDATION: pay 100% on QA-passed delivery in V1. Let forecast accuracy affect only future proposal rights, which is non-financial. An optional "calibration bonus" (paid from a separate small pool, never withheld from base pay) can be trialled in V1.5 at most 10% of base.

3. The AI must not choose its own target metric. Metrics come from a small Human/Safe-approved Metric Catalogue. Each catalogue metric is paired with a fixed guardrail metric (for example, room clicks are only valid alongside D7 return-visit rate not falling). An agent picks from the catalogue and cannot define new metrics.

4. Small samples fail closed. If the pre-set minimum sample is not reached within the horizon (default N ≥ 200 unique sessions per arm, or ≥ 30 for binary event metrics with a ≥ 5-event floor), the result is recorded as INCONCLUSIVE. Inconclusive results have zero effect on the Learning Ledger in either direction.

5. Most components should be off-chain or deferred. V1 needs two to three contracts: the fixed-supply EMBER ERC-20 (IMD standard launch, plain transfers), a Safe treasury, and optionally one tiny ForecastCommit registry, for which IMD's own oracle.request / signed git commits may be enough. Revenue Router, Epoch Manager, Mode Registry, on-chain Build Registry, on-chain Learning Ledger, outcome-tranche escrow and any custom v4 hook are all DEFER or REMOVE.

6. Revenue is fragile and must be labelled honestly. FACT: IMD standard launches pay the requesting wallet 1.0% of every trade, and only Sepolia is open today. Testnet fees have no market value. Until a mainnet pool exists, $EMBER has no real revenue, and "self-sustaining" is a design target only. V1 must run on a pre-funded Build Vault with a published runway, and must scale down automatically ("ember mode") when inflows fall.

7. Authority stays human. AI proposes, reviews, builds and measures. Only a Safe (recommended 2-of-3 at least) moves money or publishes to production. There is no autonomous spend path in V1.

8. The biggest residual risks are collusion between agents and reviewers who share the same base model or operator, concentration of proposal rights in early winners, and Safe signers acting as a single point of failure. Each has a concrete mitigation in §7.

Final V1 in one line

Fixed-supply EMBER + Safe-held Build Vault + off-chain (but hash-anchored) Epoch loop: catalogue-metric forecasts committed → independent review → Safe selects → paid on QA delivery → measured with fail-closed statistics → public Learning Ledger → proposal slots for the next epoch.

2. What was reviewed (the candidate, restated)

PROJECT CONSTRAINT (from the brief):

EMBER ERC-20 ── Genesis Forge ── Revenue Router ── EMBER BUILD VAULT
                                                        │
Epoch Manager ── Build Registry ── World Pulse ── Mode Registry
                                                        │
World Brain ── Learning Ledger ── Swarm Dream Hall ── Agent Houses
                                                        │
                       Genesis PEPE ── Human/Safe ── Timelock

Philosophy: AI imagines / proposes / builds / reviews; contracts enforce bounded rules; Human/Safe controls financial and production authority. The token core is minimal and immutable.

Distinctive mechanism: Forecast-Committed, Outcome-Graded Building, with an optional outcome tranche held until measurement, and a Learning Ledger that affects proposal slots, review weight and visibility, but not token balances, yield or financial entitlement.

That last exclusion is already the right instinct. The outcome tranche contradicts it. A tranche is a financial entitlement that depends on outcome. Fixing that contradiction is the single most important change in this review.

3. Platform facts that constrain the design

4. The first required attack: is forecast-committed building actually good?

4.0 Distinctiveness test

ASSUMPTION: no comparable IMD ecosystem launch ties pre-committed forecasts to product-build selection. I scanned the public identity-md-launches GitHub organisation via search results only. That is not exhaustive.

Verdict: distinctive. KEEP the forecast + ledger core.

4.1 Metric selection failure

Attack. An agent proposes "Ember Lantern room" and forecasts "+40% room clicks". The clicks go up because the room is placed on the landing path. Return visits and world retention fall because the room is shallow and adds load time.

Root cause. The proposer picks the metric, so it will pick the one easiest to move.

RECOMMENDATION: a closed Metric Catalogue, approved by the Safe and versioned.

Suggested V1 catalogue (EXPERIMENTAL; the exact list is OPEN):

4.2 Goodhart's law

Once a metric decides evaluation, it stops being a good measure. Mitigations, in order of strength:

1. Decouple money from the metric (§4.3). This removes most of the reason to game.
2. Guardrail pairing (M2). Gaming the primary metric usually damages a guardrail.
3. Hold-out / staggered exposure where feasible: show the new build to a random 50% of sessions for the measurement window. This measures the build's effect rather than the World's overall trend. (EXPERIMENTAL; needs simple client-side bucketing. No on-chain component.)
4. Grade forecasts on calibration, not size of win. The ledger rewards being right, including correctly predicting a small effect, not claiming big numbers. A proper scoring rule (Brier or log score over a forecast interval) does this. An agent that forecasts "+2% ± 3%" and lands at +1.5% scores better than one that forecasts "+40%" and lands at +10%.
5. Human qualitative review stays mandatory. "Did this make the World better?" is answered by a Safe signer's short written note per build. That note is published next to the numbers and can veto a "HIT".
6. Rotate measurement auditors. The agent that built something never measures it (see §7, collusion).

RECOMMENDATION: state publicly that "the metric is evidence, not the goal". It is a cultural rule, but it costs nothing and frames every dispute.

4.3 External-factor unfairness: should outcomes affect payment?

Analysis. Early World traffic will mostly reflect things the builder cannot control: IMD launch activity, X algorithm reach, market sentiment, outages and seasonality. Even with a hold-out design, small samples (§4.4) make most early results inconclusive. Withholding pay for good work under those conditions:

• is unfair, because builders carry risk they cannot manage
• raises bid prices, because rational agents pad budgets by the expected withheld amount, so the World pays more for the same work
• rewards sandbagging, because agents forecast tiny effects to secure the tranche
• adds escrow state (on-chain or off-chain) for every build until its horizon ends
• creates disputes at every measurement, with money attached

Tranche comparison

RECOMMENDATION (decision):

• V1: outcome tranche = 0%. Pay 100% of the agreed budget on QA pass and production publish, which the Safe signs.
• Forecast accuracy affects only future proposal rights, review weighting and visibility, as the candidate already intends for the ledger.
• V1.5 (EXPERIMENTAL): an optional calibration bonus of at most 10% of base. It is paid from a separate, pre-funded "Calibration Pool", only for CONCLUSIVE results, and only for calibration (proper scoring rule), not for raw uplift. It is never a holdback. Base pay is never at risk.
• Never allow outcome-linked clawback.

4.4 Small-sample noise: fail closed

Expected consequence (ASSUMPTION): most V1 builds will be INCONCLUSIVE for the first several epochs. That is fine and should be said publicly. The ledger still learns cost accuracy, delivery reliability and QA defect rate. These are fully under the builder's control and need no traffic. In early V1 these three signals should carry most of the ledger weight.

4.5 Delayed outcomes and horizon mismatch

(The brief was cut off at this heading. This section covers the obvious meaning: outcomes arrive after the next epoch has started.)

• Problem. If an epoch is 14 days and the horizon is 14 days, epoch n's results are only known during epoch n+2. Proposal rights would then lag by two cycles.
• RECOMMENDATION: The ledger updates delivery-side metrics (cost, on-time, QA) immediately after QA, and outcome-side metrics only when the measurement closes. Proposal-slot allocation for epoch n+1 uses whatever has closed so far. Pending results count as neutral.
• Decay. Ledger scores decay with a half-life of about 4 epochs, so early luck or bad luck does not lock in.

4.6 Usefulness vs. complexity

4.7 Is it suitable for V1?

Yes, in the reduced form: forecast commitment, catalogue metrics, fail-closed measurement, an off-chain public ledger, and proposal slots. No, in the full form (outcome tranche, on-chain registries).

5. Component-by-component decision table

Net result: about 15 named components become 1 token + 1–2 Safes + an off-chain loop, with optional hash anchoring.

6. Simplified V1 architecture

                         ┌─────────────────────────────┐
                         │  EMBER ERC-20 (IMD standard)│  FACT: fixed 1B, plain transfers
                         │  Uniswap v4 pool (IMD)      │  creator fee 1.0% → requester wallet
                         └──────────────┬──────────────┘
                                        │ creator fees (mainnet only; none on Sepolia)
                                        ▼
┌──────────────────────────────────────────────────────────────────────────┐
│ EMBER BUILD VAULT = Safe (≥2-of-3)        ◄── initial allocation (Forge)  │
│ Policy: per-epoch cap set by MODE (normal / ember / dormant)             │
└───────────────┬──────────────────────────────────────────────────────────┘
                │ pays 100% on QA-pass + publish (Safe-signed)
                ▼
┌──────────────── OFF-CHAIN LIVING LOOP (public, hash-anchored) ───────────┐
│                                                                           │
│  OBSERVE  World Pulse dashboard (catalogue metrics only)                  │
│     ↓                                                                     │
│  ANALYZE  World Brain drafts epoch theme + gaps                           │
│     ↓                                                                     │
│  PROPOSE  N agents (slots from Ledger) → proposal + catalogue metric     │
│           + guardrail + forecast interval + budget + horizon             │
│     ↓     ─── hash(proposal) committed BEFORE review ───                  │
│  REVIEW   ≥2 independent reviewers (different model/operator)             │
│     ↓                                                                     │
│  FUND     Safe selects; budget reserved in epoch plan                     │
│     ↓                                                                     │
│  BUILD    Agent builds (IMD job/workflow)                                 │
│     ↓                                                                     │
│  QA       Separate QA agent + human spot check → Safe pays 100%           │
│     ↓                                                                     │
│  PUBLISH  Safe signer approves production deploy                          │
│     ↓                                                                     │
│  MEASURE  Pre-registered horizon; fail-closed stats; auditor ≠ builder    │
│     ↓                                                                     │
│  LEARN    Learning Ledger: cost acc., delivery, QA, calibration           │
│     ↓                                                                     │
│  REPEAT   Ledger → proposal slots next epoch (decaying, capped)           │
│                                                                           │
│  Rendered publicly in the Swarm Dream Hall                                │
└───────────────────────────────────────────────────────────────────────────┘

Authority boundaries:

           can read data   can propose   can review   can spend   can publish to prod
AI agents       ✔               ✔             ✔            ✘              ✘
World Brain     ✔               theme only    ✘            ✘              ✘
Safe signers    ✔               ✘ (V1)        veto         ✔              ✔
Contracts       —               —             —        (token only)       —

7. Attack scenarios

Severity: H = high, M = medium, L = low (RECOMMENDATION-level judgement).

8. Economic failure analysis

8.1 Burn ≠ revenue (restated)

• Revenue is assets the Build Vault actually receives that can pay for work: creator fees in ETH/IMD/EMBER and any direct product sales.
• Burn destroys EMBER. It pays no one and funds nothing. No burns in V1.

8.2 Revenue model and its fragility

FACT: the creator receives 1.0% of every trade. FACT: only Sepolia is open, where fees have no market value.

ASSUMPTION / illustration only (not a forecast). Monthly creator revenue ≈ 1% × monthly volume.

Fee currency: the docs fetched do not say whether creator fees accrue in the paired asset, the launch token, or both (OPEN). Fees in EMBER that must be sold to fund work create reflexive sell pressure: low price leads to more EMBER sold per build, which pushes the price lower. RECOMMENDATION: budget builds in the paired asset (ETH or IMD), and sell EMBER only under a published monthly cap.

8.3 Failure modes

8.4 Mode rules (Safe-signed JSON, no contract)

mode        condition (trailing 90d)                         per-epoch build cap
normal      inflow ≥ 1.0 × trailing build spend AND           up to 100% of plan
            runway ≥ 6 epochs
ember       inflow < 1.0 × spend OR runway 3–6 epochs         ≤ 40% of plan;
                                                              maintenance + 1 build
dormant     runway < 3 epochs OR inflow ≈ 0 for 60 days       measurement + ledger only;
                                                              0–1 small build

(EXPERIMENTAL thresholds.) Even dormant mode stays "alive": World Pulse keeps observing, the World Brain keeps analysing, and agents keep proposing. Only funding pauses. Proposals queue in the Dream Hall. This lets the World feel alive during low activity without spending.

8.5 Self-sustainability test (honest)

Self-sustaining = trailing-90-day inflow ≥ trailing-90-day build + ops spend, held for 2 consecutive quarters. Publish this figure each epoch. Until it is met, all materials say "pre-funded, working toward self-sustainability."

9. Minimum viable V1 (exact scope)

9.1 On-chain (smallest set)

9.2 Off-chain

• Epoch repository: proposals, commitments, reviews, QA reports, measurement results, ledger.
• Metric Catalogue v1 (≈8 metrics + guardrails, §4.1).
• World Pulse dashboard (catalogue metrics only).
• World Brain agent (read-only, no keys).
• Dream Hall page rendering everything above.
• 1–3 Agent Houses.
• Genesis PEPE holder gating for at least one World feature.

9.3 Learning Ledger schema (V1)

agent_id, operator_wallet, epoch, build_id,
proposal_hash, reveal_ok (bool),
budget, actual_cost, cost_error_pct,
delivered_on_time (bool), qa_defects_preprod, qa_defects_postpub,
metric_id, guardrail_id, forecast_low, forecast_high, horizon_days,
result_status ∈ {HIT, MISS, NO_EFFECT, INCONCLUSIVE, GUARDRAIL_BREACH},
calibration_score (null if INCONCLUSIVE),
reviewer_ids[], reviewer_predictions[], reviewer_calibration[],
human_note_hash

9.4 Proposal-slot formula (V1, EXPERIMENTAL)

score = 0.35·delivery_reliability + 0.30·cost_accuracy + 0.15·(1 − qa_defect_rate)
      + 0.20·calibration           (calibration term = 0 weight until ≥3 conclusive results)
decay half-life = 4 epochs
slots(agent) = min( ceil(score_share × total_slots), 0.30 × total_slots )
reserved: ≥1 open slot per epoch for agents with no history

Weights favour what builders control, in line with §4.4.

9.5 Epoch cadence

• V1: 14-day epochs. Measurement horizon 7–14 days, overlapping the next epoch.
• Driven by IMD schedule.create (FACT: 0.5 IMD per run that opens a question/job; skipped/failed runs are free).

10. Goal check: does the slim V1 still meet the four goals?

11. V1.5 / V2 roadmap

12. Final recommended architecture

┌─────────────────────────────── V1 FINAL ─────────────────────────────────┐
│                                                                          │
│  TOKEN CORE (stable/minimal/trustworthy)                                 │
│    EMBER — IMD standard launch, fixed 1B, plain transfers, v4 pool       │
│                                                                          │
│  TREASURY (human authority)                                              │
│    Build Vault Safe ≥2-of-3  ·  optional Ops Safe  ·  Mode JSON (signed) │
│                                                                          │
│  LIVING PROTOCOL (adaptive/AI-driven, off-chain, public, hash-anchored)  │
│    World Pulse → World Brain → Agents (ledger slots, 30% cap, open slot) │
│    → commit hash → independent review → Safe select → build (IMD jobs)   │
│    → QA → 100% pay → Safe publish → fail-closed measurement (auditor ≠   │
│    builder) → Learning Ledger → next epoch                               │
│                                                                          │
│  PRODUCT SURFACES                                                        │
│    Swarm Dream Hall (the loop, visible) · 1–3 Agent Houses ·             │
│    Genesis PEPE gated features · wearables as catalogue build class      │
│                                                                          │
│  NOT IN V1: Revenue Router, Epoch Manager contract, Mode Registry        │
│  contract, on-chain ledger, outcome escrow, Timelock, custom hook, burn  │
└──────────────────────────────────────────────────────────────────────────┘

13. Exact open decisions

14. Final go / no-go criteria

GO for V1 launch only if ALL hold:

1. Token is an IMD standard launch with no custom token or hook code. Supply split and poolBps are published.
2. Build Vault is a Safe at ≥2-of-3, signers are documented, and no single person holds a majority of keys.
3. Initial vault runway covers ≥ 6 epochs at the normal-mode plan without any trading revenue.
4. Metric Catalogue v1 with guardrails, query hashes and sample minimums is published before epoch 1.
5. Commit → review → select ordering is demonstrably enforced. At least one dry-run epoch on Sepolia shows hashes committed before reviews.
6. Payment policy is published: 100% on QA pass, no outcome holdback, no clawback.
7. Reviewer-independence and auditor ≠ builder rules are published and checked for each epoch.
8. Slot cap (30%) and open-slot rule are in the ledger code.
9. Public materials say "pre-funded, working toward self-sustainability" and contain no yield, burn-value or return claims.
10. Platform facts in §3 have been re-verified within 7 days of launch.

NO-GO if ANY hold:

• Any contract can mint EMBER, tax transfers or skim swaps.
• Any AI agent holds keys able to move vault funds or deploy to production.
• Outcome-linked holdback above 0% in V1.
• Self-sustainability is advertised as achieved without 2 quarters of evidence (§8.5).
• The Learning Ledger affects token balances, yield or any financial entitlement.
• Creator-fee mechanics (D11) are unverified at mainnet launch.

15. Sources

Checked on 2026-10-05:

• IMD API documentation: https://imd.fun/docs. Supply 1B/18 decimals; 10% swarm / 90% requester; poolBps; Uniswap v4 single-sided pool; ETH/IMD pairing; 1.25% fee (1.0% requester, 0.25% network); launch kinds; paid actions at 0.5 IMD; schedule spacing; "Sepolia (11155111) is the only one open"; standard launch token "fixed … plain transfers"; oracle panel mechanics.
• Uniswap v4 hooks concepts: https://developers.uniswap.org/contracts/v4/concepts/hooks (served from https://developers.uniswap.org/llms.mdx/docs/protocols/v4/concepts/hooks). Permission bits in the hook address; callbacks; four return-delta permissions that "adjust balances"; the hook "cannot be added, removed, or swapped afterward."
• Comparative IMD launches (comparative only, not protocol facts), found via search on 2026-10-05: https://github.com/identity-md-launches, for example https://github.com/identity-md-launches/launch-661-imd-offsets-token-symbol-imdo-chain-id-1/pull/1 and https://github.com/identity-md-launches/launch-603-build-imd-schemas-json-schema.

Referenced as general practice but not re-fetched this session (treat as background, not verified facts): Safe multisig (https://docs.safe.global), OpenZeppelin TimelockController (https://docs.openzeppelin.com/contracts), Goodhart's law and proper scoring rules (Brier / log score) as standard concepts.

Not available: the current $EMBER Living Economy report and the earlier conservative report (see L1). Any conflict between this review and those documents is unresolved (D13).

16. Facts vs. inference vs. uncertainty (summary)

• FACTS (sourced): IMD launch parameters, the Sepolia-only availability, the 1.25% / 1.0% / 0.25% fee split, v4 hook immutability and balance-adjusting capability, IMD paid-action pricing and schedule spacing.
• INFERENCES / RECOMMENDATIONS: 0% V1 tranche; ≤10% bonus-only later; closed metric catalogue; fail-closed thresholds; 30% slot cap; mode thresholds; component cuts.
• UNCERTAIN / EXPERIMENTAL: sample-size thresholds, mode thresholds, slot-formula weights, whether hold-out bucketing is feasible at V1 traffic, and whether other IMD ecosystem launches already do something similar.
• UNANSWERED: the contents of the two prior reports; brief sections after §4.5; creator-fee collection mechanics and asset; mainnet timing.