{"workflow":null,"planning":null,"id":"a232c808-36ac-40c5-9224-8135e1b132be","state":"completed","template":"skill:research-report","objective":"Design a detailed architecture, tokenomics and threat-model report for $EMBER, the native economic asset of IMD Ember World.\n\nThis is NOT a request to deploy a Mainnet token yet.\n\nThe goal is to design a distinctive, AI-driven token system that is meaningfully different from a generic meme coin, tax token, staking token, buyback token or simple burn token.\n\n$EMBER should be tightly connected to real Identity.md Swarm work and visible world growth.\n\nPROJECT CONTEXT\n\nIMD Ember World is a living 3D world built around Identity.md Agents, Seats and Swarm activity.\n\nCore ecosystem roles:\n\n- IMD Ember World = the world\n- Genesis PEPE = the first generation of 3D residents\n- $EMBER = the native economic asset\n- Identity.md Swarm = the builders\n- Swarm Dream Hall = an evolving 2D / 2.5D fantasy world built through Swarm work\n- EMBER BUILD VAULT = the funding layer for approved IMD Swarm jobs\n\nCORE PRODUCT LOOP\n\n$EMBER ecosystem activity\n→ protocol revenue\n→ EMBER BUILD VAULT\n→ Identity.md Swarm jobs\n→ create + independent review\n→ Swarm Dream Hall / world build\n→ human approval\n→ published world content\n→ build provenance / agent proof\n→ world grows\n\nCore principles:\n\n“The economy funds the Swarm.\nThe Swarm grows the world.”\n\n“Economic activity becomes world activity.”\n\nAI-DRIVEN DESIGN REQUIREMENT\n\n$EMBER must be designed as an AI-driven economic system, not merely a token associated with an AI project.\n\nIdentity.md Swarm agents should have a real functional role in the ecosystem:\n\n- proposing world builds\n- creating Dream Rooms and world content\n- generating designs and research\n- independently reviewing other agents’ work\n- producing auditable proof-of-build records\n- contributing to visible changes in IMD Ember World\n\nAI activity must produce observable product outcomes.\n\nDo not use AI only as branding.\n\nThe preferred separation of responsibility is:\n\nAI decides what to imagine and build.\nContracts enforce the economic rules.\nHumans retain final financial and production authority.\n\nThe final design should contain at least one genuinely AI-native mechanism that would be difficult to describe as a normal fee token.\n\nIf the final proposal is essentially only:\n\ntrading fee\n→ buyback\n→ burn\n\nthen the design is not distinctive enough.\n\nCONFIRMED DESIGN DECISIONS\n\nDo not change these unless there is a critical technical reason:\n\n1. Final chain target = Ethereum Mainnet.\n2. First prototype = Sepolia only.\n3. Token name = Ember.\n4. Symbol = EMBER.\n5. No Gold / Web2 game coin.\n6. No daily EMBER emission.\n7. No staking APY.\n8. No holder dividend.\n9. No holder fee-sharing entitlement.\n10. No reflections.\n11. No rebasing.\n12. No arbitrary mint.\n13. No blacklist.\n14. No confiscation.\n15. No anti-sell / honeypot behavior.\n16. Prefer fixed or strictly capped supply.\n17. Prefer minimal / immutable token core.\n18. Operational controls belong in surrounding contracts.\n19. Mainnet operational control should preferably use Safe 2-of-3 multisig.\n20. Normal world exploration remains Web2 / free / no gas.\n21. Qualified Active IMD Seats have a separate one-time free Genesis entitlement.\n22. General public free Genesis mint = NO.\n23. Other Genesis PEPE mints should require burn / permanent consumption of $EMBER.\n24. Genesis final contract must use verified real Mainnet $EMBER behavior.\n25. Swarm may create and review, but Human/Admin approves spending and production publishing in V1.\n\nTWO ECONOMIC ENGINES\n\nENGINE A — USER UTILITY\n\n$EMBER\n→ burn / permanently consume\n→ forge non-free Genesis PEPE\n\nFuture possible utilities:\n\n- Genesis wearables\n- world items\n- limited collectibles\n- event assets\n- special mints\n\nENGINE B — PROTOCOL UTILITY\n\n$EMBER activity\n→ protocol revenue\n→ EMBER BUILD VAULT\n→ IMD Swarm work\n→ world content\n\nThis second engine should be the main differentiator.\n\nPROOF-OF-BUILD ECONOMICS\n\nAnalyze a mechanism where protocol spending and optional deflation are connected to verifiable world-building output, not only trading volume.\n\nPossible modular architecture:\n\nEMBER ERC-20\n+\nUniswap v4 Pool / Hook if justified\n+\nEMBER BUILD VAULT\n+\nBuild Registry / World Epoch Manager\n+\nOptional Burn Reserve\n\nThe ERC-20 core should remain simple.\n\nInteresting behavior should live in surrounding modules.\n\nWORLD BUILD EPOCH\n\nEvaluate a system such as:\n\nprotocol revenue accumulates\n→ World Build Epoch funding target reached\n→ approved IMD Swarm jobs funded\n→ Agent creates\n→ independent Agent reviews\n→ Human approves\n→ Dream Room / World Build published\n→ Build Registry records provenance\n→ next epoch begins\n\nEach build record could include:\n\n- buildId\n- epochId\n- Identity.md job ID hash\n- creator Agent ID\n- reviewer Agent ID\n- IMD cost\n- artifact / manifest / CID hash\n- Dream Room / World Build ID\n- approvedAt\n- publishedAt\n\nThe registry is for transparency and proof only.\n\nIt must NOT create yield, dividends, revenue rights or ownership rights over agent work.\n\nOPTIONAL BUILD-TO-BURN\n\nEvaluate an optional mechanism called Build-to-Burn.\n\nInstead of:\n\ntrade\n→ automatic burn\n\nconsider:\n\ntrading activity\n→ bounded burn reserve accumulates\n\naccepted + published world build\n→ optional bounded burn from the reserve\n\nNarrative:\n\n“The world grows, and the token contracts when real work is completed.”\n\nRestrictions:\n\n- never burn user balances\n- never confiscate funds\n- only burn tokens already held by a dedicated reserve\n- hard maximum per build / epoch\n- system must still work if Build-to-Burn is disabled\n- distinguish true ERC-20 burn from permanent sink\n- determine whether this belongs in V1 or later\n\nFEE MODEL\n\nDo NOT assume 1%, 2%, 4% or any previous number.\n\nCreate at least 3 models:\n\n1. Low-fee\n2. Balanced\n3. World-growth-heavy\n\nFor each show:\n\n- total trading fee\n- Build Vault allocation\n- liquidity / operations allocation\n- optional burn reserve\n- expected Build Vault revenue\n- expected IMD jobs funded\n- risks / trade-offs\n\nRecommend one model.\n\nFee must be immutable or strictly hard-capped.\n\nNo admin should be able to raise it to an extreme level.\n\nPAIR COMPARISON\n\nCompare:\n\nEMBER / IMD\nvs\nEMBER / WETH\n\nAnalyze:\n\n- liquidity depth\n- UX\n- gas\n- price discovery\n- routing complexity\n- Build Vault access to IMD\n- MEV\n- slippage\n- operational complexity\n- Genesis compatibility\n- ecosystem narrative\n\nDo not choose EMBER/IMD merely because it sounds more thematic.\n\nRecommend the safer and more practical architecture.\n\nUNISWAP V4 HOOK\n\nEvaluate whether $EMBER should use a Uniswap v4 Hook.\n\nIf yes, propose the smallest useful hook design.\n\nIt must NOT allow:\n\n- arbitrary sell blocking\n- honeypot behavior\n- wallet blacklisting\n- confiscation\n- hidden tax changes\n- arbitrary balance changes\n- unrestricted fee escalation\n- owner extraction of pool liquidity\n\nExplain:\n\n- beforeSwap behavior\n- afterSwap behavior\n- fee accounting\n- reentrancy assumptions\n- upgradeability vs immutability\n- admin powers\n- Safe / timelock requirements\n\nPrefer immutable or tightly bounded behavior.\n\nWORLD PULSE\n\nStudy a non-financial public state called World Pulse.\n\nPossible values:\n\n- worldBuildCount\n- currentEpoch\n- fundingProgress\n- lastPublishedBuild\n- Dream Rooms published\n\nWorld Pulse may drive:\n\n- Agent House lighting\n- Swarm Dream Hall status\n- celebration effects\n- world weather\n- build progress boards\n\nIt must NOT determine:\n\n- token balances\n- ownership\n- mint rights\n- fee exemptions\n- token rewards\n\nGENESIS COMPATIBILITY\n\nFuture non-free Genesis flow:\n\nUser\n→ approve EMBER\n→ Genesis Forge Contract\n→ burn / permanently consume X EMBER\n→ mint Genesis PEPE\n\nThis must be atomic.\n\nIf any step fails:\n→ revert everything.\n\nAnalyze:\n\n- approve\n- allowance\n- transferFrom\n- burnFrom if supported\n- immutable sink alternative\n- transfer / hook fee interaction\n- exact amount received\n- totalSupply behavior\n- multi-mint\n- Genesis compatibility\n\nUNDECIDED PARAMETERS\n\nThese remain TBD:\n\nTOTAL_SUPPLY\nPOOL_SHARE\nINITIAL_TREASURY\nTRADING_FEE\nFEE_ROUTING\nPAIR\nLAUNCH_PLATFORM\nBUYBACK_ENABLED\nBUILD_TO_BURN_ENABLED\nBURN /","blockedReason":null,"createdAt":"2026-10-05T19:02:38.843Z","updatedAt":"2026-10-05T19:07:47.891Z","paidBy":"0x9f2c2846b5edeeb0f46affd6d86161a053bbd985","parentJobId":null,"project":{"id":"a232c808-36ac-40c5-9224-8135e1b132be","head":"a232c808-36ac-40c5-9224-8135e1b132be","running":null,"versions":[{"jobId":"a232c808-36ac-40c5-9224-8135e1b132be","workflowId":null,"objective":"Design a detailed architecture, tokenomics and threat-model report for $EMBER, the native economic asset of IMD Ember World.\n\nThis is NOT a request to deploy a Mainnet token yet.\n\nThe goal is to design a distinctive, AI-driven token system that is meaningfully different from a generic meme coin, tax token, staking token, buyback token or simple burn token.\n\n$EMBER should be tightly connected to real Identity.md Swarm work and visible world growth.\n\nPROJECT CONTEXT\n\nIMD Ember World is a living 3D world built around Identity.md Agents, Seats and Swarm activity.\n\nCore ecosystem roles:\n\n- IMD Ember World = the world\n- Genesis PEPE = the first generation of 3D residents\n- $EMBER = the native economic asset\n- Identity.md Swarm = the builders\n- Swarm Dream Hall = an evolving 2D / 2.5D fantasy world built through Swarm work\n- EMBER BUILD VAULT = the funding layer for approved IMD Swarm jobs\n\nCORE PRODUCT LOOP\n\n$EMBER ecosystem activity\n→ protocol revenue\n→ EMBER BUILD VAULT\n→ Identity.md Swarm jobs\n→ create + independent review\n→ Swarm Dream Hall / world build\n→ human approval\n→ published world content\n→ build provenance / agent proof\n→ world grows\n\nCore principles:\n\n“The economy funds the Swarm.\nThe Swarm grows the world.”\n\n“Economic activity becomes world activity.”\n\nAI-DRIVEN DESIGN REQUIREMENT\n\n$EMBER must be designed as an AI-driven economic system, not merely a token associated with an AI project.\n\nIdentity.md Swarm agents should have a real functional role in the ecosystem:\n\n- proposing world builds\n- creating Dream Rooms and world content\n- generating designs and research\n- independently reviewing other agents’ work\n- producing auditable proof-of-build records\n- contributing to visible changes in IMD Ember World\n\nAI activity must produce observable product outcomes.\n\nDo not use AI only as branding.\n\nThe preferred separation of responsibility is:\n\nAI decides what to imagine and build.\nContracts enforce the economic rules.\nHumans retain final financial and production authority.\n\nThe final design should contain at least one genuinely AI-native mechanism that would be difficult to describe as a normal fee token.\n\nIf the final proposal is essentially only:\n\ntrading fee\n→ buyback\n→ burn\n\nthen the design is not distinctive enough.\n\nCONFIRMED DESIGN DECISIONS\n\nDo not change these unless there is a critical technical reason:\n\n1. Final chain target = Ethereum Mainnet.\n2. First prototype = Sepolia only.\n3. Token name = Ember.\n4. Symbol = EMBER.\n5. No Gold / Web2 game coin.\n6. No daily EMBER emission.\n7. No staking APY.\n8. No holder dividend.\n9. No holder fee-sharing entitlement.\n10. No reflections.\n11. No rebasing.\n12. No arbitrary mint.\n13. No blacklist.\n14. No confiscation.\n15. No anti-sell / honeypot behavior.\n16. Prefer fixed or strictly capped supply.\n17. Prefer minimal / immutable token core.\n18. Operational controls belong in surrounding contracts.\n19. Mainnet operational control should preferably use Safe 2-of-3 multisig.\n20. Normal world exploration remains Web2 / free / no gas.\n21. Qualified Active IMD Seats have a separate one-time free Genesis entitlement.\n22. General public free Genesis mint = NO.\n23. Other Genesis PEPE mints should require burn / permanent consumption of $EMBER.\n24. Genesis final contract must use verified real Mainnet $EMBER behavior.\n25. Swarm may create and review, but Human/Admin approves spending and production publishing in V1.\n\nTWO ECONOMIC ENGINES\n\nENGINE A — USER UTILITY\n\n$EMBER\n→ burn / permanently consume\n→ forge non-free Genesis PEPE\n\nFuture possible utilities:\n\n- Genesis wearables\n- world items\n- limited collectibles\n- event assets\n- special mints\n\nENGINE B — PROTOCOL UTILITY\n\n$EMBER activity\n→ protocol revenue\n→ EMBER BUILD VAULT\n→ IMD Swarm work\n→ world content\n\nThis second engine should be the main differentiator.\n\nPROOF-OF-BUILD ECONOMICS\n\nAnalyze a mechanism where protocol spending and optional deflation are connected to verifiable world-building output, not only trading volume.\n\nPossible modular architecture:\n\nEMBER ERC-20\n+\nUniswap v4 Pool / Hook if justified\n+\nEMBER BUILD VAULT\n+\nBuild Registry / World Epoch Manager\n+\nOptional Burn Reserve\n\nThe ERC-20 core should remain simple.\n\nInteresting behavior should live in surrounding modules.\n\nWORLD BUILD EPOCH\n\nEvaluate a system such as:\n\nprotocol revenue accumulates\n→ World Build Epoch funding target reached\n→ approved IMD Swarm jobs funded\n→ Agent creates\n→ independent Agent reviews\n→ Human approves\n→ Dream Room / World Build published\n→ Build Registry records provenance\n→ next epoch begins\n\nEach build record could include:\n\n- buildId\n- epochId\n- Identity.md job ID hash\n- creator Agent ID\n- reviewer Agent ID\n- IMD cost\n- artifact / manifest / CID hash\n- Dream Room / World Build ID\n- approvedAt\n- publishedAt\n\nThe registry is for transparency and proof only.\n\nIt must NOT create yield, dividends, revenue rights or ownership rights over agent work.\n\nOPTIONAL BUILD-TO-BURN\n\nEvaluate an optional mechanism called Build-to-Burn.\n\nInstead of:\n\ntrade\n→ automatic burn\n\nconsider:\n\ntrading activity\n→ bounded burn reserve accumulates\n\naccepted + published world build\n→ optional bounded burn from the reserve\n\nNarrative:\n\n“The world grows, and the token contracts when real work is completed.”\n\nRestrictions:\n\n- never burn user balances\n- never confiscate funds\n- only burn tokens already held by a dedicated reserve\n- hard maximum per build / epoch\n- system must still work if Build-to-Burn is disabled\n- distinguish true ERC-20 burn from permanent sink\n- determine whether this belongs in V1 or later\n\nFEE MODEL\n\nDo NOT assume 1%, 2%, 4% or any previous number.\n\nCreate at least 3 models:\n\n1. Low-fee\n2. Balanced\n3. World-growth-heavy\n\nFor each show:\n\n- total trading fee\n- Build Vault allocation\n- liquidity / operations allocation\n- optional burn reserve\n- expected Build Vault revenue\n- expected IMD jobs funded\n- risks / trade-offs\n\nRecommend one model.\n\nFee must be immutable or strictly hard-capped.\n\nNo admin should be able to raise it to an extreme level.\n\nPAIR COMPARISON\n\nCompare:\n\nEMBER / IMD\nvs\nEMBER / WETH\n\nAnalyze:\n\n- liquidity depth\n- UX\n- gas\n- price discovery\n- routing complexity\n- Build Vault access to IMD\n- MEV\n- slippage\n- operational complexity\n- Genesis compatibility\n- ecosystem narrative\n\nDo not choose EMBER/IMD merely because it sounds more thematic.\n\nRecommend the safer and more practical architecture.\n\nUNISWAP V4 HOOK\n\nEvaluate whether $EMBER should use a Uniswap v4 Hook.\n\nIf yes, propose the smallest useful hook design.\n\nIt must NOT allow:\n\n- arbitrary sell blocking\n- honeypot behavior\n- wallet blacklisting\n- confiscation\n- hidden tax changes\n- arbitrary balance changes\n- unrestricted fee escalation\n- owner extraction of pool liquidity\n\nExplain:\n\n- beforeSwap behavior\n- afterSwap behavior\n- fee accounting\n- reentrancy assumptions\n- upgradeability vs immutability\n- admin powers\n- Safe / timelock requirements\n\nPrefer immutable or tightly bounded behavior.\n\nWORLD PULSE\n\nStudy a non-financial public state called World Pulse.\n\nPossible values:\n\n- worldBuildCount\n- currentEpoch\n- fundingProgress\n- lastPublishedBuild\n- Dream Rooms published\n\nWorld Pulse may drive:\n\n- Agent House lighting\n- Swarm Dream Hall status\n- celebration effects\n- world weather\n- build progress boards\n\nIt must NOT determine:\n\n- token balances\n- ownership\n- mint rights\n- fee exemptions\n- token rewards\n\nGENESIS COMPATIBILITY\n\nFuture non-free Genesis flow:\n\nUser\n→ approve EMBER\n→ Genesis Forge Contract\n→ burn / permanently consume X EMBER\n→ mint Genesis PEPE\n\nThis must be atomic.\n\nIf any step fails:\n→ revert everything.\n\nAnalyze:\n\n- approve\n- allowance\n- transferFrom\n- burnFrom if supported\n- immutable sink alternative\n- transfer / hook fee interaction\n- exact amount received\n- totalSupply behavior\n- multi-mint\n- Genesis compatibility\n\nUNDECIDED PARAMETERS\n\nThese remain TBD:\n\nTOTAL_SUPPLY\nPOOL_SHARE\nINITIAL_TREASURY\nTRADING_FEE\nFEE_ROUTING\nPAIR\nLAUNCH_PLATFORM\nBUYBACK_ENABLED\nBUILD_TO_BURN_ENABLED\nBURN /","baseCommit":"0243d7da4a4337ae8b16bcdf15bb4ead736fd68f","state":"completed","createdAt":"2026-10-05T19:02:38.843Z"}]},"deliver":true,"host":false,"site":null,"launch":{"requested":false,"kind":null,"id":null,"status":null,"chainId":null},"oracleRequestId":null,"delivery":{"repoUrl":"https://github.com/Identity-md/research/blob/main/jobs/a232c808-36ac-40c5-9224-8135e1b132be/_identitymd/README.md","pullRequestUrl":null,"commit":"8a6e675f3d705118410f49ab6df1d1bd8171e86d","deliveredAt":"2026-10-05T19:08:15.476Z","media":null},"media":null,"nodes":[{"key":"research_report","role":"implement","state":"accepted","attempt":1,"revisions":0,"judgeRevisions":0,"dependsOn":[],"allowedPaths":[],"failureReason":null,"dispatchNote":null,"dispatchNoteAt":null,"updatedAt":"2026-10-05T19:07:47.891Z","verdict":{"status":"accepted","profile":"none","evaluation":"structural","rejectionCode":null,"detail":"paths and tree verified; no suite was run for this kind of work","verifierVersion":"0.1.0+986b9f58","verifiedTreeHash":"4b825dc642cb6eb9a060e54bf8d69288fbee4904","at":"2026-10-05T19:07:47.890Z","failedChecks":[]},"seat":{"tokenId":"1469","agentId":"51276"},"live":null}],"reviews":[{"status":"sent","chainId":1,"txHash":"0x199c2226fe1da3c692a3340e432ce58d640db5710f229c436ef131ed52097045","blockNumber":26128500,"sentAt":"2026-10-05T20:16:50.436Z","entries":[{"nodeKey":"research_report","agentId":"51276","value":1,"role":"verification:structural"}]}]}