$EMBER: architecture, tokenomics, and threat-model report

Status: design proposal; no Mainnet token deployment is proposed by this report.
Target / prototype: Ethereum Mainnet / Sepolia.
Asset: Ember (EMBER).
Decision posture: contracts enforce bounded economic rules; Swarm agents propose, create, and independently review; a human-controlled Safe approves spending and production publishing in V1.

1. Evidence, labels, and limits

Evidence labels

• Fact (source) is an externally verifiable technical fact, linked to a primary source.
• Constraint (brief) is a confirmed instruction supplied for this design.
• Recommendation / inference is a proposed design conclusion, not a fact or promise.
• TBD needs a governance, legal, commercial, or launch decision before deployment.

Relevant technical facts

• Fact: ERC-20 defines transfer, approve, allowance, and transferFrom; transferFrom is specifically the delegated-spend workflow. It also cautions UIs about changing a nonzero allowance directly. EIP-20.
• Fact: OpenZeppelin’s current ERC-20 implementation treats a supply mechanism as a derived-contract choice; its documented extensions include burnable and capped variants, and SafeERC20 wraps ERC-20 interactions. OpenZeppelin ERC-20 API.
• Fact: A Uniswap v4 hook is optional, is fixed in the pool key at initialization, and cannot later be added, removed, or exchanged. Hooks can run before/after swaps; their callable permissions are encoded in the hook address. Uniswap v4 hooks.
• Fact: A v4 hook does not itself cause routing/liquidity to arrive; Uniswap documents that hook developers must not assume front-end routing. Uniswap v4 hooks FAQ.

Limits: Neither market volume, IMD price, demand, legal classification, launch-platform availability, nor the precise meaning/transferability of IMD is established in this assignment. Dollar examples below are sensitivity illustrations, not forecasts. A security audit, tax/accounting review, sanctions/privacy policy, and counsel review remain required.

2. Executive design

Proposed V1

1. Deploy an immutable, fixed-supply, plain ERC-20 named Ember / EMBER, 18 decimals. Mint exactly the approved TOTAL_SUPPLY once in the constructor to a disclosed distribution executor; expose no post-deployment mint, pause, blacklist, confiscation, transfer-tax, reflection, rebase, or fee-exemption code.
2. Use a separate Build Vault whose assets are approved protocol revenue (initially preferably a stable settlement asset or WETH converted through an auditable policy), not an invisible deduction from user EMBER balances.
3. Run funding in World Build Epochs. A constrained on-chain state machine reserves a bounded job budget; off-chain Identity.md work produces artifacts; independent review and a human Safe approval are required before payment/publishing is finalized; an immutable registry publishes provenance hashes and a public World Pulse reflects only non-financial progress.
4. Deploy the Genesis Forge separately. A paid Genesis mint transfers an exact EMBER amount from the user and burns it in the same transaction before minting the Genesis PEPE. Qualified Active IMD Seats use a separate, one-time, entitlement route; there is no general-public free mint.
5. Start on Sepolia with production-like addresses, role procedures, event indexing, failure tests, and a public dashboard. Mainnet only follows independent audit, parameter freeze, legal review, and a public deployment manifest.

This is AI-native because the economic release condition is an attestable chain of Swarm proposal → creation → independent review → human acceptance → published world artifact, rather than a volume-triggered token reward. AI does useful work, but receives neither autonomous spending authority nor token-holder revenue rights.

Why it is not a generic fee / burn token

The principal economic output is a verified published world build and its permanent provenance record. Revenue is released to fund approved IMD work; users can inspect the build/job/manifest linkage. Any later burn is a small, optional consequence of an accepted public artifact, never the system’s objective and never a charge against a holder. The system functions with Build-to-Burn off.

3. Architecture and roles

Protocol revenue ──> Revenue Router ──> EMBER BUILD VAULT ──> Epoch budget
                                                     │              │
                                             Safe approves     Swarm job escrow
                                                                    │
User EMBER ──> Genesis Forge ──> ERC-20 burn ──> Genesis PEPE      │
                                                                    v
Swarm proposal → creator evidence → independent review → human acceptance
                                                        → Registry + publish → World Pulse

Epoch state machine

Draft → Funded → JobsApproved → Created → IndependentlyReviewed → HumanAccepted → Published → Closed.

Only a Safe 2-of-3 may open/close an epoch, approve a job cap, release a payment, accept a build, or record the publication attestation in V1. A creator cannot be the reviewer. The registry rejects duplicate (epochId, jobIdHash) and records:

buildId, epochId, jobIdHash, creatorAgentIdHash, reviewerAgentIdHash, imdCost, artifactManifestHash, contentIdHash, approvedAt, publishedAt, status.

artifactManifestHash should commit to a versioned manifest containing artifact CIDs, source revision(s), tool/model disclosures as policy permits, test/render evidence, reviewer findings, and human approver reference. Hash only sensitive agent/job identifiers; publish a separately governed redaction policy. An indexer/UI may make the evidence usable, but contract events and content-addressed artifacts are the canonical proof trail.

AI-native release gate: Proof-of-Build Escrow

Recommendation: reserve a job budget when the Safe approves a scoped job; release it only after all four attestations are recorded: creator submission, different reviewer approval, human acceptance, and publication hash. The Safe may reject/cancel an uncompleted job and return unspent Vault funds to the epoch—not take assets from an agent or holder.

This is deliberately a proof-of-process and publication, not a claim that a hash proves artistic quality. Human approval remains the quality and financial authority. Public metrics should measure published builds, review latency, accepted/rejected jobs, and budget committed/released—not “AI output tokens” or financial return.

4. Token supply and allocation

Constraint: fixed or strictly capped supply, minimal immutable core, no arbitrary mint.
Recommendation: fixed supply is safer than a cap: TOTAL_SUPPLY minted exactly once at deployment; the token has no role and no external mint entrypoint. Burns reduce totalSupply; no mechanism replenishes them.

TOTAL_SUPPLY, POOL_SHARE, INITIAL_TREASURY, and allocation recipients remain TBD. Before any deploy, publish a one-page allocation table where every allocation sums exactly to 100%, includes recipient/vesting/custody, and calls out the liquidity inventory. Treasury EMBER is an asset controlled under disclosed Safe policy; it is not a promise of buyback or market support. Lock/vesting mechanics must be independently audited and disclosed.

Do not allocate “daily emissions,” staking APY, reflections, holder dividends, or fee-sharing: each conflicts with a confirmed constraint and dilutes the build-oriented design.

5. Two economic engines

A. User utility: irreversible forging

Paid Genesis flow:

user approve (or permit, if implemented) → Forge.forge(qty, maxCost)
→ calculate quoted fixed/scheduled price → transfer exact EMBER → burn
→ mint exactly qty Genesis PEPE → emit Forge event; otherwise revert all

Use SafeERC20.safeTransferFrom and immediately invoke token burn from Forge’s own received balance. This works with a conventional burnable token and gives a true burn: a Transfer(forge, address(0), amount) and lower totalSupply. An alternative immutable sink (sending to an unrecoverable address) is not a true ERC-20 burn: totalSupply remains unchanged and the sink’s key-loss assumption cannot be proven. Prefer real burn.

The paid method must require post-transfer balanceAfter - balanceBefore == cost; otherwise revert. EMBER V1 should have no transfer fee, so exact-received is straightforward and future fee-on-transfer modifications are impossible. burnFrom(user, amount) is viable but combines allowance spending/burning in token code; the transfer-then-burn Forge pattern keeps the token core broadly interoperable. A single transaction is atomic: a failure in transfer, exact amount, burn, supply limit, or NFT mint reverts the whole call.

Require qty > 0, checked multiplication/no overflow, maxCost slippage protection, a global paid-mint supply cap, optional per-wallet cap only if it is publicly fixed and does not block sale, and nonReentrant. Multi-mint must charge exactly qty × unitPrice and mint all or none. The seat entitlement path should verify an immutable/Merkle entitlement of (seat, recipient, allocation=1, claimed=false) and mark it claimed atomically; it must not bypass paid inventory controls beyond its explicitly disclosed allocation.

B. Protocol utility: work becomes visible world growth

Revenue from disclosed protocol products/services, Forge-adjacent primary offerings where applicable, sponsorships, or a bounded trading mechanism funds the Vault. The Vault purchases/holds the settlement asset needed for approved work, then pays against accepted deliverables. EMBER holders receive no entitlement to Vault assets, agent output, protocol revenue, or future profits. The registry’s role is transparency only.

Important accounting inference: EMBER burned in Forge is no longer available to pay a Vault. Therefore Forge burn is user utility/deflation, not revenue. If a product wants to fund work, it must separately route payment to the Vault or use a disclosed primary-sale/revenue stream. Do not describe a burn as “Vault funding.”

6. Fee models (decision analysis)

These models describe a separately visible protocol trade levy only if a v4 hook is ultimately adopted; they are not a token transfer tax. “Total trading fee” = normal LP swap fee + protocol levy. Allocation applies only to the levy. For comparable sensitivity, monthly eligible one-sided EMBER pool volume V = $1,000,000, assumes the levy is collected successfully, and assumes an average accepted-job all-in budget J = $2,500. Actual revenue is V × levy; jobs are floor(BuildVaultRevenue / J). These are arithmetic examples, not forecasts; volume could be zero.

ops-liquidity means disclosed operational funding or liquidity-support inventory under Safe policy, not owner withdrawal from LP positions. A burn reserve accrues EMBER only after a transparent, externally executed conversion/purchase policy; it must have a separate per-epoch cap. No model may use the user’s transfer itself as a hidden tax.

Recommendation: do not activate a protocol levy in V1. Launch the plain ERC-20/Forge/Vault architecture and fund the Vault with direct disclosed protocol revenue. If Sepolia measurement and audit later demonstrate a need, the Balanced model is the maximum starting candidate, with levy immutable at 35 bps (or a contract-wide irreversible downward-only setting), 35 bps hard ceiling, 0% hook fee on paths/pools not explicitly configured at deployment, and no discretionary increase. It is less destructive than the heavy model but has enough signal to fund a whole job at roughly $1.02m illustrated eligible volume. This recommendation does not assume volume exists.

7. Pair decision: EMBER/IMD vs EMBER/WETH

Recommendation: primary EMBER/WETH pool; do not make EMBER/IMD the canonical price pair without independently verified IMD liquidity, ERC-20 behavior, oracle requirements, and actual job settlement needs. The Vault may maintain an approved, auditable conversion route to IMD if payments require it. An EMBER/IMD secondary pool can be reconsidered after liquidity and routing evidence. Never use a manipulable pool spot price to price Forge mints or release Vault payments.

8. Uniswap v4 hook decision

Recommendation: no hook in V1. A standard pool requires no hook, and v4 hooks are immutable components of a pool key, so adding one prematurely permanently couples launch liquidity to novel custom code. A hook cannot solve insufficient liquidity or manufacture routing. Use a simple pool and direct revenue routing first.

If a later hook is approved: smallest useful design

Deploy a new, explicitly labelled pool with an immutable EpochFeeHook only after audit. It implements afterSwap only (no return-delta permission) and has a deployment-time immutable pool key, settlement token, fixed levy <=35 bps, Vault address, and optional BurnReserve address. It has no owner, proxy, upgrader, whitelist, or mutable fee. The hook receives/accounting-credits the bounded levy under the v4 accounting design, emits LevyAccrued(poolId, token, amount, split), and makes accumulated balances claimable only by the immutable Vault/BurnReserve addresses. Exact implementation must follow the audited v4 core/periphery version; do not improvise callback settlement.

• beforeSwap: not implemented. Therefore it cannot inspect sender to block sells, discriminate wallets, or alter a user’s requested swap.
• afterSwap: records/settles only the predetermined levy. It must not change swap deltas, call arbitrary external contracts, swap tokens, or depend on price/oracles during the callback.
• Fee accounting: account separately per currency and pool; never assume that the input is EMBER. Vault-side conversion happens later via a Safe-approved, slippage-bounded route and public event, never inside a swap callback. Do not double-count LP fee, hook levy, and protocol revenue.
• Reentrancy: callback functions are callable only by the canonical PoolManager and use a reentrancy guard around any post-callback claim/transfer function. Follow checks-effects-interactions; ERC-20 transfers occur outside the hook callback if the accounting architecture allows. A full audit must model PoolManager lock/settlement behavior.
• Controls: no upgradeability. If a critical defect appears, communicate and migrate liquidity voluntarily to a newly audited pool; no one may confiscate LP positions or force migration. A 2-of-3 Safe may operate the Vault, but cannot mutate hook behavior. If any emergency pause exists in surrounding Vault withdrawals, it requires a disclosed timelock and must not pause EMBER transfers, Forge exits, or pool swaps.

This design excludes arbitrary sell blocking, honeypots, blacklists, arbitrary balance changes, hidden tax changes, fee escalation, and owner extraction of LP liquidity. It should be rejected if a business requirement needs any of those powers.

9. Optional Build-to-Burn

Verdict: later, disabled in V1. It is narratively coherent but increases accounting, conversion, and “burn theatre” risk before the proof-of-build system is trusted.

If activated after audit and public vote/approval procedure, the reserve must be a separate contract holding only EMBER already transferred into it. executeBuildBurn(buildId, amount) is callable only once for a registry build in Published status and requires: (1) an immutable registry address; (2) a predefined epoch budget; (3) amount <= perBuildMax; (4) cumulative epoch burn <= epochMax; (5) reserve balance sufficiency. It burns its own balance using burn(amount) and emits build/epoch/amount. It cannot transferFrom a user, pull from Forge, or receive a changing cap.

“True burn” reduces totalSupply; a permanent sink only makes tokens inaccessible by convention. Public dashboards must label the choice precisely. The protocol must remain economically and operationally sound with zero reserve and disabled burn.

10. World Pulse: public, non-financial state

WorldPulse is a read model/event stream populated from Registry accepted/published transitions:

• worldBuildCount, currentEpoch, epochFundingProgress, lastPublishedBuildId, dreamRoomsPublished, and timestamps/status.
• Clients may map it to Agent House light levels, Dream Hall boards, celebrations, weather, and progress effects.

It must never determine ERC-20 balances, ownership, mint eligibility, entitlement allocation, fee exemption, token reward, exchange rate, or payment. World clients should tolerate stale/missing indexer data and display on-chain event links. This preserves free Web2 exploration: looking at the world requires no wallet or gas.

11. Threat model and controls

12. Governance, controls, and operations

• V1 authority: Mainnet Build Vault/Epoch/Registry administration sits in a disclosed Safe 2-of-3. Signers are public roles/identities subject to an operating policy; agents have zero signing authority.
• Timelock: changes that can redirect future Vault revenue or modify Registry/Epoch policy use a public timelock. The immutable token and immutable Forge configuration should not be upgradeable. Emergency powers, if any, may stop new Vault job release only, are narrowly timed, and cannot seize, blacklist, pause EMBER, or block pool sells.
• Separation: Safe proposes/authorizes money and publication; agents make/review artifacts; human reviewers approve value; an indexer presents evidence. No single actor should author, review, accept, and pay the same job.
• Transparency: publish addresses, roles, thresholds, token supply/allocation, parameter hashes, epoch/job events, manifests, released/remaining budget, and a monthly reconciliation. Public dashboards must not imply token-holder claim rights.

13. Sepolia prototype and Mainnet gates

Sepolia scope

Deploy test-only equivalents of Token, Forge, Vault, EpochManager, Registry, Pulse, and optionally a disabled BurnReserve. Exercise: normal paid forge; free-seat claim; duplicate claim; insufficient allowance; wrong token; NFT mint failure rollback; duplicate job; creator=reviewer; rejected build; late publication; epoch cap; Safe-only calls; zero/reserve/cap burn cases; event/indexer reconstruction. If experimenting with a v4 hook, use a separate experimental pool and test callback/reentrancy/invariant cases; it does not become a Mainnet commitment.

Mainnet go/no-go checklist

1. Final supply/allocation/vesting, Forge price/caps, pair, revenue sources, and Build-to-Burn choice are public and internally consistent.
2. Real Mainnet EMBER address is hardcoded/verified by the final Genesis contract; no test token, mock, proxy swap, or symbolic address is accepted.
3. Independent audit covers every deployed module and deployment configuration; critical/high findings are remediated and published with scope/commit hash.
4. Safe signers, threshold, recovery/runbook, timelock, Vault job caps, and emergency boundaries are published and rehearsed.
5. Forge/Registry/Vault event schemas, dashboard, manifest retention, reconciliation, and incident disclosure process work on Sepolia.
6. Legal, tax, privacy, consumer-disclosure, IP/licensing, and sanctions reviews are completed for intended jurisdictions.
7. No claim is made that EMBER yields income, pays dividends, confers ownership, ensures liquidity, or guarantees world output.

14. Decisions required before implementation

15. Recommended decision record

Adopt the fee-free, fixed-supply EMBER core; atomic true-burn Genesis Forge; WETH-primary plain pool; direct-revenue Build Vault; proof-of-build escrow/registry; human/Safe V1 controls; and World Pulse limited to display. Build-to-Burn and all v4-hook trade levies remain disabled/deferred. This preserves the decisive loop—the economy funds the Swarm; the Swarm grows the world—while refusing to make market trading or automated AI authority the center of the system.