$EMBER as a Living, Self-Sustaining, AI-Driven Economic Organism

Research, Architecture, Economics, Threat Model and V1 Plan for IMD Ember World and the Genesis PEPE Ecosystem

Report date: 5–6 October 2026 (information current as of the research date; see §0.3 for what could and could not be checked). Scope: Research and design only. No Mainnet deployment is proposed or performed. No token is launched by this report. Nothing here is financial advice.

---

0. How to read this report

0.1 Labels used throughout

Label	Meaning
[FACT]	Verified from a primary or official source on the research date, with the source cited in §16.
[ASSUMPTION]	A working premise used for modelling or design. Not verified. Replace with real data before acting on it.
[REC]	A recommendation from this report.
[EXPERIMENTAL]	An idea worth prototyping on Sepolia but not ready for V1 commitment.
[OPEN]	Unanswered question that blocks or shapes a decision.

0.2 The core question

How can $EMBER become a living, self-sustaining, AI-driven economic organism that continuously funds, builds, evaluates and improves IMD Ember World and the Genesis PEPE ecosystem, while preserving strict financial and security boundaries?

Short answer (expanded in §1–§12): Keep the EMBER ERC-20 small, immutable and boring. Put the "life" in a ring of modules around it: a World Brain that observes and proposes; World Build Epochs in which several Identity.md Swarm agents compete with forecast-committed proposals; independent review by different seats; Human/Safe approval of every spend; tranche-based funding where part of a build's budget is released only after measured outcomes are attested; and a Learning Ledger that scores each agent's forecasts against what actually happened and uses that score to allocate future proposal rights (not money, not tokens). Funding comes from product revenue (premium collectibles, 3D upgrades, sponsored Dream Rooms, events, pool fee share) gathered by a bounded Revenue Router into a Build Vault, whose World Runway drives bounded GROW / BALANCED / CONSERVE modes. Burns (Genesis Forge) create demand and scarcity, but are explicitly not counted as revenue.

0.3 Evidence limits (read this before the rest)

• Verified: Identity.md docs, explorer, $IMD token page, the identity-md-launches GitHub organisation, Uniswap v4 hook and dynamic-fee docs, OpenZeppelin Contracts 5.x docs, Safe module docs, and the ERC-8004 draft were read on the research date (§16).
• Not found in public sources: No public repository, launch, contract or document named EMBER, IMD Ember World, Genesis PEPE, Swarm Dream Hall, Agent Houses or EMBER BUILD VAULT was found in the identity-md-launches GitHub organisation (repository search for "ember", "genesis pepe", "dream hall" returned zero results on the research date). All project context about these items is therefore taken from the task brief and is treated as project premise, not verified fact.
• Comparative cases: CLAUS and Identity Units could not be located in any primary source during research. SIMD has a public site showing only a name, an X handle and an Ethereum contract address (0xbb0c…3415); its mechanics could not be verified. These three are therefore not used as evidence for any mechanism in this report. The verified $IMD token and a recent IMD launch ($ADAM, launch 720) are used as comparative cases instead (§10).
• Price data: No live price of $IMD, ETH, or any EMBER market exists in this report. All money amounts in the economic model are labelled [ASSUMPTION] and are in USD-equivalent for readability.
• Tooling limits: Some pages were read through an automated summariser; every Identity.md number quoted below was re-checked against the raw text of imd.fun/docs/ and imd.fun/token/ downloaded on the research date.

---

1. Verified ground truth that constrains the design

These facts shape the architecture. Each is [FACT] with a source in §16.

1.1 Identity.md network

Fact	Design consequence
Identity.md describes itself as "a network to create net new 0 to 1 billion financial applications, a consensus layer managed by distributed agents" [S1].	The Swarm is a real build workforce, not branding; EMBER can buy work from it.
Seats are ERC-8004-bound; devices pair to a seat, and a seat binds to an ERC-8004 agent [S1]. There are 2,000 seats, one per Identity.md NFT [S2].	"Qualified Active IMD Seat" can be defined against an on-chain seat id, not a social claim.
Explorer on the research date showed ~638 agents, ~570 online, ~553 working, ~93.9K steps in 24h [S3]. (Snapshot; changes constantly.)	The supply of agent labour is large relative to one world's needs; competition between proposers is feasible.
Paid actions (job.open, job.continue, launch.open, workflow.open, oracle.request, schedules) cost 0.5 IMD each (per run for schedules), paid via x402 with Permit2 [S1].	The marginal protocol cost of a Swarm job is small and predictable; most real cost is human review, 3D production and hosting.
Job shapes include chain, fan_out_join and dag; templates include impl_tests_review, audit, fuzz, research; the adversarial-review skill is "Review, read-only, by a different seat" [S1].	Multi-proposer competition (fan-out) and independent review by a different seat are native platform primitives.
Work records are hashed and written to a reputation registry; review documents are retrievable by hash (/reviews/:hash.json, /work-records/:hash.json); oracle work is batched daily under a Merkle root [S1].	Proof-of-build can reuse IMD's hashes rather than invent a parallel system.
Oracles answer questions with a panel and quorum; "chain" evidence is reproducible from chain data via recipes (incl. Uniswap v4 spot/volume recipes); answers are EIP-712 attestations under domain IdentityMD Oracle v2 [S1].	World Pulse can consume verifiable chain metrics (e.g., Genesis mints, Forge burns, pool volume) without trusting a single reporter.
Launch economics on IMD's launch path: fixed 1,000,000,000 supply, 18 decimals; "Ten percent to the swarm, ninety to the requester"; swarm share = 2% to wallets with accepted work + 8% per seat connected at admission; poolBps 1–9,000 seeds a single-sided pool [S1].	If EMBER is launched through IMD's evm_project path, 10% goes to the swarm by rule; supply is fixed at 1B. This must be decided consciously (§6.4).
Trading fee on today's factories: "1.25% of every trade … 1% to the paying wallet and 0.25% to the network. Anyone can call the distribution." [S1]	If the paying wallet is the project Safe, 1% of pool volume is a real, if speculative, revenue stream (§7).
"Sepolia (11155111) is the only one open on api.imd.fun today" for launches [S1].	"Sepolia first" is not just prudence; it is the only launch chain currently open on the platform.
evm_contracts launches deploy 1–8 contracts "all or nothing", with "No token, so no supply, swarm share or trading fee", and an owner address receiving owner roles [S1].	Surrounding modules (Vault, Forge, Epoch Manager) can be deployed by the Swarm with the Safe as owner.

1.2 $IMD token (comparative, not a template)

[FACT] $IMD: "10M minted in 2023, none since", one supply across Ethereum, Base and Robinhood Chain; "Every sell burns supply"; sIMD staking "redeems for more IMD over time"; "Community Coins" are priced in and backed by IMD and "Each trade pays the launcher and burns a cut of IMD"; all liquidity moved to Uniswap v4 with the "POOL4 hook" in Sep 2026 [S2].

Design reading [REC]: $IMD uses sell-burns and staking. EMBER's baseline explicitly forbids anti-sell mechanics and staking APY. EMBER should not mirror $IMD; it should complement it by being the asset that buys world-building work from the IMD Swarm.

1.3 Uniswap v4 and contract standards

• [FACT] Hook permissions are encoded in the hook's address bits; "you cannot deploy a hook to an arbitrary address"; if the address lacks a flag, "the PoolManager never calls that hook function" [S4].
• [FACT] Callbacks: before/after initialize, add/remove liquidity, swap, donate; plus return-delta flags that "let a hook adjust balances" [S4].
• [FACT] Dynamic-fee capability is a flag fixed at pool creation; fees can be updated via updateDynamicLPFee or overridden per swap from beforeSwap [S5].
• [FACT] OpenZeppelin Contracts 5.x provides ERC20Burnable (burn, burnFrom against allowance), ERC20Capped (immutable cap), ERC20Permit (ERC-2612), ERC20Votes [S6]; TimelockController with proposer/executor/canceller/admin roles and a minDelay [S7].
• [FACT] Safe modules "can execute arbitrary transactions… A malicious module can take over a Safe" [S8].
• [FACT] ERC-8004 ("Trustless Agents") is a Draft defining Identity, Reputation and Validation registries [S9]. Draft status means interfaces can still change.

---

2. What makes EMBER distinctive

2.1 What EMBER must not be

Pattern	Why rejected
Tax token	Hidden transfer fees break composability and trust; forbidden by baseline.
Simple burn token	Burn is supply reduction, not funding. A world needs builders paid.
Reflection / rebasing	Forbidden; adds accounting risk; no link to world-building.
Staking APY / holder dividend	Forbidden; creates securities-like expectations and JIT-staking attack surface (see $ADAM audit finding A-01, §10).
"AI branding only"	No mechanism in which AI output changes what gets built or how money flows.

2.2 The AI-native mechanism: Forecast-Committed, Outcome-Graded Building

This is the core distinctive mechanism. It cannot be summarised as "ERC-20 + fee + burn + AI branding" because the economic flow (which build gets funded, and how much of its budget is released) depends on AI-generated predictions being committed before and scored after the work.

         ┌────────────── WORLD BUILD EPOCH n ───────────────┐
         │                                                   │
 Agent A ─┤ proposal + budget + FORECAST(metric Δ, horizon)  │
 Agent B ─┤ proposal + budget + FORECAST(metric Δ, horizon)  ├─► hashes committed
 Agent C ─┤ proposal + budget + FORECAST(metric Δ, horizon)  │   on EpochManager
         │                                                   │
         │  Reviewers (different seats) score + re-forecast  │
         │  Human/Safe selects winner(s), approves budget    │
         │                                                   │
         │  Budget split:  BASE tranche  (on publish + QA)   │
         │                 OUTCOME tranche (after horizon,   │
         │                 released by Safe against attested │
         │                 World Pulse metric)               │
         └───────────────────────────────────────────────────┘
                                │
                                ▼
                     LEARNING LEDGER (per seat)
           forecast error, review calibration, cost accuracy
                                │
                                ▼
       next epoch: proposal SLOTS & review weight allocated by
       calibration score  (rights, not money; never balances)

Key properties:

1. Forecast commitment. Each proposal includes a structured forecast, e.g. "Dream Room Lantern Bog will raise weekly unique Dream Hall visitors by +8% (±4%) within 21 days" and "cost ≤ 1,800 USD-eq". The hash of the proposal (including forecast) is committed on-chain to the EpochManager before review. It cannot be edited after the fact.
2. Outcome-graded release. A fixed share of the approved budget (the outcome tranche, e.g. 20–30%) is only eligible for release after the horizon, conditional on the attested metric. The Safe still signs the release; the contract enforces that it cannot exceed the reserved amount and cannot be paid before the horizon. Unreleased outcome tranches return to the Vault.
3. Learning Ledger. For every seat: forecast error, cost overrun, review calibration (did their ranking predict outcomes?), QA defect rate. This is published (off-chain JSON, on-chain hash).
4. Rights, not rewards. Calibration determines how many proposal slots a seat gets next epoch and how much weight its review carries in the ranking shown to the Human. It never touches token balances, never mints, never changes fees.

Why this is AI-native: the system's capital allocation is a function of machine-generated predictions and machine-generated evaluations, scored over time. A human-only DAO could copy it, but it only becomes practical when dozens of agents can cheaply generate structured forecasts and reviews every epoch — which the IMD Swarm verifiably provides (§1.1).

Pros: rewards being right, not being loud; limits overspend on hyped ideas; creates a measurable learning signal; transparent. Cons: metrics can be gamed (§11); horizons delay payment to builders (needs a base tranche large enough to be fair); small sample sizes early on make calibration noisy; requires good World Pulse data.

2.3 Secondary distinctive mechanisms

• Dream-to-Forge pipeline (§9): ideas are cheap in 2D/2.5D (Swarm Dream Hall) and only promoted to expensive 3D (Tripo / premium production) after review and human selection. The token economy funds an evolutionary funnel, not a fixed roadmap.
• World Runway modes (§8): the world's build tempo is coupled to its measured treasury health.
• Proof-of-Learning records: each closed epoch publishes what was predicted, what happened, and what the World Brain changed in response.

---

3. Layered architecture

3.1 Overview

 ┌──────────────────────────── OFF-CHAIN (adaptive) ─────────────────────────────┐
 │                                                                                │
 │  EMBER WORLD BRAIN  (planning/analysis; NO keys that move funds)              │
 │   ├─ Observer: reads World Pulse, Dream Hall analytics, Explorer, chain data   │
 │   ├─ Analyst: gaps, weaknesses, opportunities                                  │
 │   ├─ Planner: drafts Epoch Brief + budget priorities + mode recommendation     │
 │   └─ Evaluator: post-publication scoring → Learning Ledger                     │
 │                                                                                │
 │  IDENTITY.MD SWARM (jobs via api.imd.fun, paid 0.5 IMD/action)                 │
 │   ├─ Proposer seats (fan_out)     ├─ Builder seats (impl / content)            │
 │   ├─ Reviewer seats (adversarial-review, different seat)                       │
 │   └─ Oracle panels (chain-evidence metrics, EIP-712 attested)                  │
 │                                                                                │
 │  Swarm Dream Hall (2D/2.5D)   Ember World (3D)   Agent Houses (proof pages)    │
 └───────────────┬─────────────────────────────────────────────┬──────────────────┘
                 │ hashes, attestations, signed recommendations │
 ┌───────────────▼─────────────────────────────────────────────▼──────────────────┐
 │                         ON-CHAIN (bounded)                                      │
 │                                                                                 │
 │  EpochManager ── BuildRegistry ── WorldPulse ── ModeRegistry                    │
 │       │                                              │                          │
 │       ▼ (reservations only)                          │ (bounded params)         │
 │  BuildVault  ◄──── RevenueRouter ◄──── revenue (fees, sales, sponsors)          │
 │       ▲                                                                         │
 │       │ (Safe-signed releases, capped)                                          │
 │  HUMAN / SAFE (M-of-N)  ──► TimelockController (for parameter changes)          │
 │                                                                                 │
 │  GenesisForge (burn EMBER → mint Genesis PEPE; seat free-claim)                 │
 │  EMBER ERC-20 (fixed supply, immutable, no owner)                               │
 │  [future] BurnReserve   [future] Uniswap v4 Hook                                │
 └─────────────────────────────────────────────────────────────────────────────────┘

3.2 Mutability matrix [REC]

Component	Where	Mutability	Authority	Notes
EMBER ERC-20	On-chain	Immutable, no owner, no proxy	None	OZ ERC20 + ERC20Permit + ERC20Burnable. Entire supply minted in constructor. No mint function exists.
GenesisForge	On-chain	Immutable logic; price and season caps adjustable within hard-coded bounds	Safe via Timelock	Separate contract; owns Genesis PEPE mint right; cannot touch EMBER balances except via user-approved burnFrom.
Genesis PEPE NFT	On-chain	Immutable; minter = GenesisForge only, set once	None after init	Metadata URI pointer may be updatable by Safe+Timelock until frozen.
BuildVault	On-chain	Immutable logic; caps adjustable within hard bounds	Safe (releases), Timelock (caps)	Holds EMBER/ETH/stablecoin. Per-epoch and per-job caps. Replaceable by migrating funds through a timelocked call.
EpochManager	On-chain	Replaceable (new version, Vault points to new one via Timelock)	Safe opens/closes epochs; anyone reads	Stores proposal/review/forecast hashes and reservations.
BuildRegistry	On-chain	Append-only; replaceable	Safe or Safe-authorised recorder	Proof-of-build entries (artifact hash, IMD job id, reviewer seat ids).
WorldPulse	On-chain	Append-only; replaceable	Accepts IMD oracle EIP-712 attestations (verified on-chain) + Safe-posted hashes	Never moves funds.
ModeRegistry	On-chain	Mode enum + bounded params	AI may record recommendation; Safe+Timelock sets mode	Bounds hard-coded.
RevenueRouter	On-chain	Immutable split bounds; split values adjustable within bounds	Safe+Timelock	Pull-based; anyone can trigger distribution.
World Brain	Off-chain	Freely upgradeable (prompts, models, data)	Project team	Outputs hashed into EpochManager; a signing key that can only sign recommendations.
Learning Ledger	Off-chain JSON + on-chain hash	Append-only by convention	Evaluator	Reproducible from public data.
Dream Hall / Ember World content	Off-chain (IPFS/ENS via IMD sites)	Fully iterative	Human approves production publishes	Content CIDs recorded in BuildRegistry.
BurnReserve	Future	Immutable if introduced	—	Only receives a bounded share; only burns.
v4 Hook	Future	Immutable per pool (address-encoded permissions)	—	Not in V1 (§6.5).

Principle [REC]: Upgradeability lives at the edges; the token and the money-holding contracts' safety rules do not change. A new version replaces a module; it does not mutate it in place. Avoid upgradeable proxies for any contract that holds funds in V1.

---

4. EMBER WORLD BRAIN

4.1 Definition

The World Brain is a set of Swarm jobs and project-run agents that answer one question per epoch: "What should the world build or improve next, and why do we believe it will work?" It holds no treasury keys. Its only on-chain footprint is (a) a recommendation-signing key whose signatures are recorded but grant no authority, and (b) hashes of its documents.

4.2 Inputs (Observe)

Signal	Source	Verifiability
Genesis PEPE mints, Forge burns, holder count	Chain; IMD oracle log-count/log-sum recipes	High (chain evidence)
EMBER pool volume, spot price	Chain; IMD univ4-spot, v4-volume-rank recipes	High
Build Vault balance, reservations, burn rate	Chain	High
Dream Hall / Ember World visits, session length, return rate	Web analytics	Low–medium (off-chain; hash daily)
Room-level engagement (which rooms are visited, abandoned)	World telemetry	Low–medium
Swarm job acceptance/rejection, review findings	IMD API (/jobs/:id/records, /reviews/:hash.json)	High (hash on chain)
Community requests, bug reports	Forms / social	Low (sybil-prone)

4.3 Outputs

1. Epoch Brief: top 3–5 needs, each with evidence, a target metric and a budget envelope.
2. Mode recommendation: GROW / BALANCED / CONSERVE with the runway calculation shown.
3. Proposal comparison table after proposals close.
4. Post-epoch evaluation: forecast vs actual, Learning Ledger update, "what we will do differently".

4.4 Guardrails

• Briefs must cite metric snapshots by hash. Claims without data are flagged.
• The Brain may not propose changes to the token, the Forge price outside bounds, or Vault caps outside bounds. Proposals that do are auto-rejected by a lint step.
• The Brain's own forecasts are scored in the Learning Ledger like any proposer's. The Brain is not exempt from being wrong.

---

5. The AI World Evolution Loop

5.1 Formal states

  ┌─────────┐   ┌──────────────┐   ┌───────────────┐   ┌─────────────────────┐
  │ OBSERVE ├──►│NEED IDENTIFIED├──►│PROPOSALS OPEN ├──►│MULTIPLE AGENTS      │
  └─────────┘   └──────────────┘   └───────────────┘   │PROPOSE (commit hash)│
       ▲                                               └──────────┬──────────┘
       │                                                          ▼
  ┌────┴─────┐  ┌───────┐  ┌──────────┐  ┌────┐  ┌───────┐  ┌──────────────────┐
  │NEXT EPOCH│◄─┤ CLOSE │◄─┤  LEARN   │◄─┤... │  │RANKED │◄─┤INDEPENDENT REVIEW│
  └──────────┘  │ EPOCH │  └────▲─────┘  └────┘  │CANDID.│  └──────────────────┘
                └───────┘       │                └───┬───┘
                           ┌────┴────┐               ▼
                           │ MEASURE │      ┌────────────────────┐
                           └────▲────┘      │HUMAN / SAFE APPROVE│
                                │           └─────────┬──────────┘
                           ┌────┴────┐                ▼
                           │ PUBLISH │◄─QA◄─BUILD◄─FUNDING RESERVED
                           └─────────┘

5.2 State table [REC]

#	State	Actor	On-chain effect	Exit condition	Typical duration [ASSUMPTION]
1	OBSERVE	World Brain (Observer)	WorldPulse snapshot hash	Snapshot published	continuous; snapshot daily
2	NEED IDENTIFIED	World Brain (Analyst/Planner)	Epoch Brief hash; openEpoch() by Safe	Safe opens epoch	1–2 days
3	PROPOSALS OPEN	EpochManager	Epoch state = PROPOSING, deadline set	Deadline	3–5 days
4	MULTIPLE AGENTS PROPOSE	Proposer seats (IMD fan_out_join job)	commitProposal(hash) per proposal	Deadline	within 3
5	INDEPENDENT REVIEW	Reviewer seats (different seats, adversarial-review)	review hashes	All assigned reviews in	2–3 days
6	RANKED CANDIDATES	World Brain aggregates	ranking hash	Published	1 day
7	HUMAN / SAFE APPROVAL	Safe signers	approve(proposalId, base, outcome, horizon)	Safe tx executed	1–3 days
8	FUNDING RESERVED	BuildVault	Reservation ≤ caps; mode bounds checked	Reserved	same tx
9	BUILD	Builder seats	—	Delivery	3–14 days
10	QA	Reviewer seats + human	QA report hash	Pass / fail	1–3 days
11	PUBLISH	Human approves production publish	BuildRegistry entry (CID, job ids); base tranche release	Live	1 day
12	MEASURE	Oracle panels + analytics	WorldPulse attestations	Horizon reached	14–30 days
13	LEARN	Evaluator	Learning Ledger hash; outcome tranche decision	Published	1–2 days
14	CLOSE EPOCH	Safe	closeEpoch(); unreleased funds return	Closed	—
15	NEXT EPOCH	—	—	—	Epochs overlap: MEASURE of n runs during BUILD of n+1

Failure paths: QA fail → one revision round (job.continue) → if still failing, base tranche partially paid for accepted work only, remainder returns. Safe rejects all candidates → epoch closes with zero spend (a valid outcome). Measurement unavailable → outcome tranche returns to Vault by default after a grace period (fail-closed).

---

6. Contracts and money boundaries

6.1 EMBER ERC-20 [REC]

• OpenZeppelin 5.x ERC20, ERC20Permit, ERC20Burnable. No Ownable, AccessControl, Pausable, proxy, blacklist, fee-on-transfer, rebasing, or hooks into transfers.
• Total supply minted once in the constructor to a distribution contract/Safe. With no mint function, the cap is enforced by absence; ERC20Capped is unnecessary (and adds a code path) unless a vesting minter is required — it is not.
• ERC20Votes not included in V1: governance is Human/Safe; adding votes invites governance-capture expectations before the community is ready.

6.2 Genesis Forge [REC]

Confirmed principles preserved: Qualified Active IMD Seats get a separate one-time free entitlement; no public free mint; non-free Genesis requires EMBER consumption.

 User ──approve(Forge, X) or permit──► EMBER
 User ──forge(qty)──► GenesisForge
                         │ 1. check season cap, per-wallet cap, price X (bounded)
                         │ 2. EMBER.burnFrom(user, X*qty)   ← reverts if allowance/balance short
                         │ 3. GenesisPEPE.mint(user, qty)   ← reverts if sold out
                         ▼
                 single transaction: both happen or neither (atomic)

 Seat holder ──claimSeat(seatId, proof)──► GenesisForge
                         │ 1. verify Merkle proof: (seatId, wallet) in qualified snapshot
                         │ 2. require !claimed[seatId]; set claimed[seatId] = true
                         │ 3. GenesisPEPE.mint(wallet, 1)

• "Burn / permanently consume": use burnFrom, which reduces totalSupply — publicly verifiable. Sending to a dead address is weaker (does not reduce totalSupply) and is rejected.
• No hidden tax: the price X shown in the UI equals the amount burned. No portion is diverted. (If the project later wants a revenue share from forging, it must be a separate, visible line item — see §7.3 and §11.)
• No arbitrary admin mint: GenesisPEPE's only minter is the Forge, set once in the constructor; the Forge has no admin-mint path. Seat claims use a Merkle root fixed at deployment (or set once, then locked).
• "Qualified Active IMD Seat" [OPEN]: must be defined precisely before the snapshot — e.g. seat NFT held by wallet at block B, and seat with ≥ N accepted work records in the 30 days before B (readable from /seats/:tokenId). The exact threshold is a product decision.
• Price bounds: X adjustable by Safe+Timelock within [X_min, X_max] hard-coded at deploy, with a maximum change per adjustment (e.g., ±25%) and a minimum interval. The World Brain may recommend; it cannot set.

6.3 Build Vault [REC]

• Holds assets for approved Swarm jobs and related production costs (3D production, hosting, QA).
• reserve(epochId, proposalId, base, outcome, horizon) callable only by the Safe, checks: per-job cap, per-epoch cap (from current mode, bounded), and that total reservations ≤ free balance.
• releaseBase(proposalId, to) — Safe only, only after BuildRegistry has a publish record.
• releaseOutcome(proposalId, to, amount) — Safe only, only after horizon, amount ≤ outcomeReserved.
• expire(proposalId) — anyone, after horizon + grace: unreleased funds return to free balance (fail-closed).
• No function lets any address other than the Safe move funds. No function lets the World Brain key do anything.
• Paying the IMD Swarm: jobs are paid in IMD (0.5 IMD/action [S1]). The Vault should therefore hold a small IMD float, topped up by Safe-approved swaps; the Vault itself should not contain swap logic in V1.

6.4 Launch path decision [OPEN → REC]

Two options:

Option	What happens	Pros	Cons
A. IMD evm_project / standard launch	1B fixed supply, 10% to swarm via Merkle distributor, pool seeded per poolBps, 1.25% trading fee (1% to paying wallet) [S1]	Native to ecosystem; swarm alignment (seat holders receive EMBER); built-in fee revenue to paying wallet	Token code generated through the platform: must be audited against EMBER's baseline (no mint, no tax on transfer); fee is on trades, so revenue depends on speculation; parameters set by "chain's policy" may change
B. evm_contracts (no token issued by platform) + own EMBER	Contracts only, owner = Safe, no swarm share or fee [S1]	Full control of token code	Loses native pool fee and swarm distribution; must design liquidity separately

[REC]: Prototype both on Sepolia and decide after reading the generated token code. Option A's 10% swarm distribution is strongly aligned with the "Swarm = builders" premise and its 1% fee to the paying wallet is the only verified recurring revenue stream available today. The pool fee is a swap fee in the pool, not a transfer tax on the token — it does not violate the "no hidden tax" rule as long as it is disclosed.

6.5 Uniswap v4 Hook (future, not V1) [REC]

A custom hook could, for example, route a bounded donation to the Build Vault, or emit World Pulse events. But hook permissions are fixed by address bits and the dynamic-fee flag is fixed at pool creation [S4][S5], so mistakes are permanent per pool. Hooks with return-delta permissions can change balances, which is exactly the class of power AI must never steer. V1 should use the platform's standard pool. A V2 hook, if any, must have: hard-coded fee ceilings, no owner-adjustable fee beyond bounds, no AI-controlled inputs, and a full independent audit.

6.6 Revenue Router [REC]

          revenue in (ETH / EMBER / stable / IMD)
                         │
                  RevenueRouter.distribute()   ← anyone may call
          ┌──────────────┼─────────────────┬───────────────┐
          ▼              ▼                 ▼               ▼
   BuildVault       OpsReserve        QA/Audit Fund   [future] BurnReserve
   (60–85%)         (10–25%)          (5–10%)         (0–15%, EMBER only)

Split values can move only inside hard-coded ranges, via Safe+Timelock, at most once per epoch. BurnReserve stays at 0% in V1 (burn is not revenue, and the Forge already burns).

---

7. Self-sustaining revenue

7.1 Burn ≠ revenue

Genesis Forge burns EMBER. That reduces supply and creates demand for EMBER, but the protocol receives nothing it can spend. A design that counts burns as "income" will run out of money while looking healthy. Every model below excludes burns from revenue.

7.2 Candidate revenue sources

Source	Who pays	Why they pay	Protocol receives	Recurring?	Depends on speculation?	V1?
Pool trading fee share (IMD launch path)	Traders	To trade EMBER	1% of volume to paying wallet on today's factories [S1] → Safe → Router	Yes, while volume exists	High	Yes, if Option A; do not budget on it
Premium 3D upgrades for Genesis PEPE	Genesis holders	Better 3D model, animation, World presence	ETH/stable/EMBER price, set per item	Per season	Low–medium	Yes (core)
Premium collectibles / Dream Room items	Players, collectors	Cosmetic, display in Agent House	Primary sale price	Seasonal	Medium	Yes (small)
Sponsored Dream Rooms	Other IMD projects, brands, communities	Presence in a living world; Swarm-built room	Fixed fee per room per season	Yes, if world has visitors	Low	Yes (pilot)
Commissioned builds ("Dream Room as a service")	Other communities	They want a 2D/2.5D room built by the Swarm	Fee minus Swarm/production cost	Yes	Low	Experimental
Event passes / seasonal quests	Players	Access to time-limited events	Pass price	Seasonal	Low–medium	Later (V1.5)
Marketplace secondary royalties	Secondary buyers	Marketplace convention	ERC-2981 % where honoured	Yes	Medium	Yes, but not enforceable; budget at 0
Special/limited Genesis mints	Collectors	Scarcity	Burn only by principle → 0 revenue, unless an explicit, disclosed ETH component is added	No	High	Burn-only in V1
Bounded protocol levy on transfers	Every holder	Forced	—	—	—	No (violates baseline)
Grants / ecosystem partnerships	IMD ecosystem, partners	Strategic	One-off	No	Low	Opportunistic; not runway

7.3 Should the Forge carry a revenue component?

[REC] Not in V1. "Burn X EMBER → mint" is simple, honest and auditable. If a revenue component is later needed, add it as a separate, explicit ETH price line (e.g., "burn 5,000 EMBER and pay 0.002 ETH to the Build Vault"), shown in the UI and enforced in the same atomic transaction. Never silently divert part of X.

7.4 Revenue scenarios [ASSUMPTION — illustrative only]

Assumptions: monthly figures in USD-equivalent; pool fee share = 1% of volume (Option A); 3D upgrade avg $25 net of production marginal cost of $10 (i.e., $15 contribution); sponsored room $300/season-month; collectible net $5 each; royalties budgeted at 0.

Monthly	LOW	MEDIUM	HIGH
EMBER pool volume	$150k ($5k/day)	$1.5M ($50k/day)	$15M ($500k/day)
Pool fee share (1%)	$1,500	$15,000	$150,000
3D upgrades sold	20 → $300	150 → $2,250	800 → $12,000
Sponsored rooms	1 → $300	4 → $1,200	12 → $3,600
Collectibles	50 → $250	400 → $2,000	3,000 → $15,000
Total revenue	$2,350	$20,450	$180,600
Of which speculation-dependent (pool fee)	64%	73%	83%
Non-speculative revenue	$850	$5,450	$30,600

Reading: At every volume level the pool fee dominates, and it is the most fragile line. A sustainable design must be able to fund a minimum viable world (see §8) from non-speculative revenue alone in the medium case, and treat pool fees as surplus that extends runway or funds GROW mode. In the low case the world cannot be self-funding; it must run on its initial treasury allocation in CONSERVE mode. This is stated plainly: self-sustainability is plausible at medium volume with product revenue, not guaranteed.

---

8. World Runway and economic modes

8.1 Definitions

free_balance       = Vault balance − active reservations           (USD-eq, at a conservative price)
avg_build_cost     = trailing mean of last 4 epochs' total spend per build
build_runway       = free_balance ÷ avg_build_cost                 (in builds)
burn_rate          = trailing 3-epoch spend per month
net_burn           = burn_rate − trailing 3-month non-speculative revenue
time_runway        = free_balance ÷ max(net_burn, ε)               (in months)

[REC] Value EMBER held in the Vault at a haircut (e.g., 50% of 7-day TWAP) because selling it to pay builders moves the price. Value stablecoins and ETH at market.

8.2 Build cost estimate [ASSUMPTION]

Cost item	Low	Typical	High
IMD Swarm actions (proposals fan-out, reviews, build, QA; ~15–40 actions × 0.5 IMD)	7.5 IMD	12 IMD	20 IMD
Human review/curation time	$150	$400	$1,000
3D production (only for promoted concepts)	$0	$300	$1,500
Hosting/analytics share	$50	$100	$200
Per build (excl. IMD at unknown price)	$200	$800	$2,700

8.3 Modes [REC]

Mode	Trigger (recommended by Brain; set by Safe+Timelock)	Builds/epoch	Per-epoch cap	Outcome tranche share	3D promotions
GROW	time_runway ≥ 12 months and non-speculative revenue covers ≥ 50% of burn	3–5	up to 15% of free balance	20%	up to 3
BALANCED	6 ≤ time_runway < 12	2–3	up to 8%	25%	1–2
CONSERVE	time_runway < 6 or pool-fee revenue falls > 50% month on month	1	up to 4%	30%	0–1 (only pre-sold)

• Hard bounds in contract: per-epoch cap can never exceed 15% of free balance in any mode; mode can change at most once per epoch; Timelock delay ≥ 48h [ASSUMPTION].
• Automatic downgrade only: [EXPERIMENTAL] the contract could allow anyone to trigger a downgrade to CONSERVE if an attested runway figure falls below threshold, because becoming more conservative is safe. Upgrades always require Safe.
• AI recommends a mode each epoch, with the calculation published. The recommendation is recorded in ModeRegistry as data only.

---

9. Genesis PEPE Engine and its self-improvement

9.1 Funnel

 WIDE  ─► World Brain + proposer seats generate 30–100 concepts per season
          (traits, lore, accessories, behaviours, room tie-ins)          cost: very low
   │
   ▼    Independent reviewers (different seats) score: originality, lore fit,
        production feasibility, IP risk, duplication vs existing set        cost: low
   │
   ▼    Top 8–12 → 2D/2.5D prototypes in Swarm Dream Hall
        (visitors interact; engagement measured; forecasts committed)       cost: low–medium
   │
   ▼    Human selects 1–3 (Safe approves budget)                            decision
   │
   ▼    Tripo / premium 3D production → QA → publish as Genesis upgrade
        or new trait set, minted only through Genesis Forge                 cost: high
 NARROW

9.2 Rules

• Only Forge-minted or seat-claimed Genesis PEPE exist. No new admin mint for "special editions"; special editions are new traits/upgrades applied to existing tokens, or new Forge seasons with their own bounded caps.
• 3D upgrades are sold (revenue, §7) — not burned — to keep a clear line between demand-creation (burn) and funding (sale).
• Prototype performance in Dream Hall feeds the Learning Ledger: did the reviewers' ranking predict which concepts players engaged with?
• IP review is a mandatory reviewer criterion (AI-generated art can resemble existing IP; human sign-off required before 3D production).

---

10. Comparative case studies

Case	Verified mechanics	Lesson for EMBER
$IMD [S2]	Fixed 10M supply; sell-burns; sIMD staking; POOL4 v4 hook; community coins burn a cut of IMD per trade	Demand-side sinks work as narrative, but EMBER's baseline rejects anti-sell and staking. EMBER should create utility demand (Forge, upgrades) instead and pay the IMD Swarm for work — a complementary role.
IMD launch economics [S1]	10% to swarm (2% by accepted work, 8% per connected seat); 1.25% pool fee	A ready-made alignment and fee path; must be consciously adopted or declined (§6.4).
$ADAM, launch 720 [S10]	Public repo describes token, hook, fees, splits, oracle, NFT claim and keeper bounty, and an independent audit whose finding A-01 was "just-in-time staking" in a distributor	Evidence, inside the same ecosystem, that staking-style distributors attract JIT attacks; supports EMBER's no-staking/no-dividend baseline.
SIMD [S11]	Only name, X handle and contract address verifiable	Not used as evidence.
CLAUS, Identity Units	Not found in primary sources	Not used as evidence. [OPEN] Provide primary links if these should be analysed.

---

11. Multi-agent competition: evaluation

Dimension	Single proposer	Multi-proposer competition (recommended)	Notes / mitigation
Creativity	Narrow	High — diverse models/identities	Mix models and identity profiles across proposer rows.
Quality	Depends on one agent	Higher via selection	Review rubric fixed per epoch and published.
Cost	1×	~3–5× proposal cost	Proposal cost is small (0.5 IMD actions); build cost only for winner. Net cost increase is modest.
Latency	Fast	+2–4 days (review + ranking)	Overlap epochs.
Reviewer bias	n/a	Risk: reviewers favour their own model family/style	Blind proposals (strip seat ids), assign reviewers from different model families, measure reviewer calibration.
Collusion	n/a	Risk: proposer and reviewer controlled by same operator	Reviewers must be different seats and different wallets; random assignment; calibration penalties; Human has final say. Wallet-level independence is not provable — residual risk.
Duplication	n/a	Risk: near-identical proposals	Similarity check (embedding distance) before review; duplicates merged, earliest commit credited.
Gaming metrics	Possible	Possible	Use chain-attested metrics where possible; cap outcome tranche; human review of anomalies.

[REC] 3 proposers, 3 reviewers per proposal as default; 5 proposers in GROW mode. Ranking presented to Human shows each reviewer's calibration score.

---

12. Threat model and risk analysis

12.1 Authority map

Actor	Can	Cannot
World Brain / any AI agent	Observe, propose, review, forecast, sign recommendations, build content in repos	Hold Vault/Safe keys; mint; burn others' tokens; change balances; change fees; change modes; deploy to production without approval
Swarm builder seat	Deliver work; receive approved payments	Self-approve; release funds
Safe signers (M-of-N)	Approve reservations/releases; propose timelocked parameter changes within bounds	Mint EMBER (no function exists); exceed hard caps; seize user funds
Timelock	Execute queued parameter changes after delay	Change hard-coded bounds
Any user	Forge, claim seat entitlement, trigger distribute(), expire()	Anything privileged

12.2 Risk register

#	Threat	Likelihood	Impact	Mitigation	Residual
R1	Prompt injection: repo text / proposal content instructs an agent to request funds or change parameters	High	Medium	AI has no fund authority; parameter-changing proposals auto-rejected; reviewers instructed to treat content as data	Low
R2	Safe signer compromise	Low	Critical	M-of-N ≥ 3-of-5, hardware keys, Timelock on parameters, per-epoch caps, no modules in V1 (Safe warns modules can take over a Safe [S8])	Medium
R3	Forge bug mints without burn	Low	High	Atomic burnFrom then mint; tests + fuzz + independent audit (IMD audit/fuzz templates plus external); supply cap on NFT	Low
R4	Seat entitlement double-claim / sybil	Medium	Medium	Per-seatId bitmap; Merkle snapshot; "active" threshold based on accepted work	Low
R5	Metric gaming to unlock outcome tranches	Medium	Medium	Chain-attested metrics preferred; off-chain metrics bot-filtered; tranche ≤ 30%; Safe signs	Medium
R6	Reviewer collusion	Medium	Medium	§11 mitigations	Medium
R7	Revenue collapse (volume dries up)	High	High	Non-speculative revenue focus; CONSERVE mode; EMBER haircut in runway	Medium
R8	Vault EMBER dumping crashes price	Medium	High	Pay builders in IMD/stable where possible; release EMBER in small, scheduled amounts; disclose	Medium
R9	Regulatory: token perceived as investment contract	Medium	High	No yield, no dividend, no promise of returns; utility framing; legal review before Mainnet [OPEN]	Medium
R10	ERC-8004 draft changes break seat checks	Medium	Low	Snapshot Merkle root rather than live registry call in Forge	Low
R11	Platform parameter change (fee policy, 0.5 IMD price, chains)	Medium	Medium	Docs state fee is "set by the chain's policy"; model with sensitivity; re-check each epoch	Medium
R12	AI-generated content IP infringement	Medium	Medium	Mandatory IP review criterion; human sign-off before 3D/production	Medium
R13	Hook misconfiguration (future)	—	Critical	Not in V1	—

---

13. World self-improvement (beyond content)

Note: the brief's sentence "The system should improve not only content, but also the …" is truncated. [ASSUMPTION] It is read here as "…but also the process, the economy's parameters and the AI system itself".

What the loop improves, and how:

Layer	Improvement target	Measured by	Who changes it
Content	Rooms, residents, quests	engagement metrics	Swarm builders; Human approves
Process	Epoch length, number of proposers, review rubric	cost per accepted build, QA pass rate, latency	World Brain recommends; team adopts (off-chain)
AI quality	Prompts, model mix, identity profiles	forecast error, reviewer calibration	Team (off-chain), informed by Learning Ledger
Economics	Forge price, mode, Router splits — within bounds only	runway, revenue mix	Safe + Timelock
Security	Tests, fuzzing, audits of modules	findings count, severity	Swarm audit/fuzz jobs + external audit; Safe deploys

Proof-of-Learning record per epoch: {epochId, briefHash, proposals[], forecasts[], selected[], actuals[], forecastErrors[], ledgerHash, changesAdopted[]} → JSON on IPFS, hash in EpochManager.

---

14. Final recommended V1 architecture

14.1 Components

                    ┌──────────────── HUMAN / SAFE (3-of-5) ────────────────┐
                    │  approves every reservation and release              │
                    │  queues bounded param changes via Timelock (≥48h)    │
                    └───────┬───────────────────────┬──────────────────────┘
                            │                       │
     ┌──────────────────────▼───┐        ┌──────────▼───────────┐
     │ EpochManager v1          │        │ ModeRegistry          │
     │ commit/review/forecast   │        │ GROW/BALANCED/CONSERVE│
     │ hashes; reservations     │        │ hard bounds           │
     └──────┬───────────────────┘        └──────────┬───────────┘
            │                                       │
     ┌──────▼──────────┐   ┌──────────────┐   ┌─────▼─────────────┐
     │ BuildVault      │◄──┤RevenueRouter │◄──┤ revenue: pool fee,│
     │ caps, tranches, │   │bounded splits│   │ 3D upgrades,      │
     │ fail-closed     │   └──────────────┘   │ sponsors, items   │
     └──────┬──────────┘                      └───────────────────┘
            │ pays (IMD float / stable / EMBER small)
            ▼
     IMD Swarm jobs ──► BuildRegistry (proof-of-build) ──► WorldPulse
                                                           (IMD oracle
                                                            attestations)
     ┌───────────────────────────┐   ┌─────────────────────────────┐
     │ EMBER ERC-20 (immutable,  │──►│ GenesisForge (burnFrom X →  │
     │ fixed supply, no owner)   │   │ mint PEPE; seat free claim) │
     └───────────────────────────┘   └─────────────────────────────┘
     Off-chain: World Brain, Learning Ledger, Dream Hall, Ember World, Agent Houses

14.2 V1 decisions

Decision	V1 choice
Chain	Sepolia only (also the only launch chain open on api.imd.fun today [S1]). Mainnet: separate decision after audit, legal review, and ≥ 3 full epochs on Sepolia.
Token	Fixed supply, immutable, OZ ERC20 + Permit + Burnable; no owner.
Launch path	Prototype both IMD standard launch (Option A) and contracts-only (Option B); choose after code review. Leaning A for swarm alignment and fee revenue, provided generated token code meets baseline.
Forge	Separate contract; burnFrom + mint atomic; bounded price; seat Merkle claim.
Vault	Safe-only releases; per-job and per-epoch caps; base + outcome tranches; fail-closed expiry.
AI authority	Zero on-chain authority; recommendations recorded as data.
Distinctive mechanism	Forecast-committed proposals + outcome-graded tranches + Learning Ledger allocating proposal rights.
Competition	3 proposers × 3 independent reviewers per proposal (5 in GROW).
Modes	Three modes, Safe+Timelock, one change per epoch, auto-downgrade [EXPERIMENTAL].
Revenue	3D upgrades, sponsored rooms, collectibles, pool fee share; burns excluded from revenue; royalties budgeted at 0.
Excluded in V1	Hook, BurnReserve share > 0, ERC20Votes, Safe modules, upgradeable proxies, transfer levy.

14.3 Implementation plan (Sepolia)

1. Phase 0 – Specification (1–2 weeks): define Qualified Active Seat; write invariants (supply constant except burns; Vault outflows ≤ reservations ≤ caps; one claim per seat).
2. Phase 1 – Contracts (2–4 weeks): IMD impl_tests_review and fuzz jobs for Token, Forge, NFT, Vault, EpochManager, BuildRegistry, WorldPulse, Router, ModeRegistry; adversarial-review by different seats; external audit before any Mainnet consideration.
3. Phase 2 – World Brain MVP (parallel): Observer + Planner producing Epoch Briefs from Sepolia data and Dream Hall analytics.
4. Phase 3 – Three dry-run epochs: test-value funds; full loop including MEASURE and LEARN; publish Proof-of-Learning records.
5. Phase 4 – Review gate: decide Mainnet readiness using explicit criteria (zero critical/high open findings, runway model validated with real Sepolia-era costs, legal opinion).

---

15. Open questions

1. [OPEN] Exact definition of "Qualified Active IMD Seat" (holding vs. activity threshold; snapshot block).
2. [OPEN] Option A vs B launch path — requires reading the platform-generated token code.
3. [OPEN] Current $IMD price and expected per-build IMD spend — needed to finalise runway numbers.
4. [OPEN] Tripo / 3D production pricing and licensing terms (not researched; not a primary-source item in scope).
5. [OPEN] Primary sources for CLAUS and Identity Units, if they should be compared.
6. [OPEN] Jurisdictional legal review of EMBER utility framing before any Mainnet step.
7. [OPEN] Whether IMD's fee policy ("set by the chain's policy", "today's factories") will remain 1.25% / 1% to paying wallet.
8. [OPEN] Whether IMD oracle attestations can be verified on Sepolia contracts (EIP-712 domain includes chainId and verifyingContract [S1]; cross-chain usage needs confirmation).

---

16. Sources

All accessed 5–6 October 2026.

• [S1] Identity.md API documentation — https://imd.fun/docs/ (launch economics, trading fee, paid actions at 0.5 IMD, job shapes/templates/skills, oracle EIP-712 domain, reputation registry records, Sepolia-only launches, evm_contracts).
• [S2] Identity.md $IMD token page — https://imd.fun/token/ (10M supply, sell burns, sIMD, 2,000 seats, POOL4 hook, Community Coins, timeline). Token contract: https://etherscan.io/address/0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7
• [S3] Identity.md Explorer, agents — https://explorer.imd.fun/agents (network snapshot figures).
• [S4] Uniswap v4 Hooks concept — https://developers.uniswap.org/docs/protocols/v4/concepts/hooks
• [S5] Uniswap v4 Dynamic Fees — https://developers.uniswap.org/docs/protocols/v4/concepts/dynamic-fees
• [S6] OpenZeppelin Contracts 5.x ERC-20 API — https://docs.openzeppelin.com/contracts/5.x/api/token/erc20
• [S7] OpenZeppelin Contracts 5.x Governance (TimelockController) — https://docs.openzeppelin.com/contracts/5.x/api/governance#TimelockController
• [S8] Safe smart account modules — https://docs.safe.global/advanced/smart-account-modules
• [S9] ERC-8004: Trustless Agents (Draft) — https://eips.ethereum.org/EIPS/eip-8004
• [S10] Identity.md launches GitHub organisation — https://github.com/identity-md-launches ; $ADAM launch 720 — https://github.com/identity-md-launches/launch-720-adam-official-x
• [S11] SIMD site — https://www.si-md.xyz/

Secondary (context only, not used for mechanics): KuCoin blog on IMD history — https://www.kucoin.com/blog/id-imd-token-community-owned-ai-agents