# IMD Viral Wars — feasibility assessment and project design

**Assessment date: 6 October 2026 (UTC).** This report treats the live IMD API and official platform documentation as the evidence base. “Verified” means stated by those sources; “inference” is my interpretation; “proposal” is a design choice. Prices and audience assumptions are illustrative, not forecasts.

## Executive recommendation

**Proceed, but revise the launch into a 30-day, YouTube-first pilot with off-chain settlement and no automatic token burn until the measurement path is independently validated.** The rivalry is a good recurring-use case: two equal content budgets, visible scorekeeping, daily prompts and a public treasury make the competition legible. IMD can run research, scheduled jobs, video production, artifacts, a hosted dashboard and an oracle panel. YouTube supplies a documented upload path and owner-authorized statistics.

The original “daily views automatically buy-and-burn the winner” is not ready for trustless production. A platform counter is mutable, delayed and vulnerable to promotion, botting and account/API policy changes. IMD’s oracle panel can aggregate evidence and issue an EIP-712 attestation, but agreement among agents establishes consensus about submitted evidence—not that the viewers were organic. Also, the live IMD launch capabilities list chains/pairings and payment prices, but not a documented tax-enabled ERC-20. A custom two-token tax system therefore needs an external Solidity build, security review and explicit policy admission.

For the pilot, use one YouTube Short per team per day, a 48-hour observation window, owner-authorized reads, a five-member 4-of-5 panel, manual exceptions and a multisig treasury. Record a winner and a *simulated* burn. Enable real burns only after the data gates and contract review pass.

## 1. Competition rules and product specification

**Format.** Team Red (`RED`) and Team Blue (`BLUE`) each publish one vertical 9:16 Short daily to separate, pre-existing channels or newly created channels with equal starting conditions. YouTube is the initial platform because its [Data API](https://developers.google.com/youtube/v3/docs/videos) documents `videos.insert`, video IDs, owner OAuth, processing status and `statistics.viewCount`; the [Analytics API](https://developers.google.com/youtube/analytics/reference) can query video metrics for an authorized channel. TikTok is a later adapter: its [Direct Post API](https://developers.tiktok.com/docs/en/content-posting-api-reference-direct-post) requires creator authorization and unaudited clients’ posts are private until audit, while its [Research FAQ](https://developers.tiktok.com/docs/en/research-api-faq) documents substantial data lag.

At 09:00 UTC, both teams’ prompt is frozen and revealed. Uploads must be public by 12:00 UTC, with the first successfully public video ID registered on the dashboard. The measurement window is 12:00 UTC on publication day through 12:00 UTC two days later (48 hours). The oracle closes at 14:00 UTC after the last permitted data refresh. This timing leaves a buffer for processing and an auditable, common window.

**Eligible view.** For the pilot, the score is the owner-authorized YouTube Data API `statistics.viewCount` delta between two snapshots of the same video ID: `closingCount - openingCount`, never a lifetime count taken at an arbitrary time. The opening snapshot is the first public snapshot no earlier than 12:00; the closing snapshot is taken at 12:00 two days later, then repeated at 12:30 and 13:00 if the API is stale. A negative delta, missing ID, non-public status, or inconsistent channel ownership is ineligible. The dashboard stores request time, response JSON, video ID, channel ID, ETag if returned, OAuth principal class (not the secret), and SHA-256 hash of the raw response.

The score is *reported platform views*, not proof of unique humans or organic attention. Paid promotion must be disclosed and makes that round void for burn purposes; it may remain visible as an exhibition result. No cross-platform score is used in the MVP. If TikTok is added, it gets a separate league until a pre-registered normalization has enough validation data; simply adding YouTube and TikTok counters is not fair.

**Exceptions.** A tie within 1% (or fewer than 100 views when both are below 10,000) is a draw: no burn, both teams receive the next equal budget. A missing or late upload is a forfeit only after a 60-minute grace period; the punctual team wins the exhibition round but no burn occurs if the opponent’s failure is platform-side or unverifiable. A deleted, private, copyright-blocked or policy-removed video before closing is “no contest” unless the team deliberately caused it. API outage, delayed processing, or conflicting evidence produces “unverifiable—no settlement,” not a forced winner. Disputes are open for 24 hours; an independent human moderator decides process violations, while a contract can settle only an attestation matching the round hash and video IDs.

An established channel is a real advantage, so equal production spend is not equal reach. Disclose baseline subscribers, retain equal budgets, give each team a distinct identity and community voting, and never promise holders financial upside from victory.

**Community.** Each team submits three prompt candidates weekly. A one-wallet-one-vote snapshot, capped at 10 votes per address and taken 24 hours before the vote closes, selects one; a moderator removes unsafe, infringing or manipulative prompts and publishes the reason. Token-weighted voting may be shown as sentiment but must not control the production queue. Large holders and holders of both tokens can otherwise manufacture an apparent team mandate. A fallback prompt (“Red/Blue remix the week’s public-domain sound into a 20-second explain-and-joke”) prevents missed rounds. Suggested identities: Red = “the reckless experimenters”; Blue = “the forensic debunkers.” Sample viewer-facing formats: “Red makes the worst product pitch possible; Blue fixes it in 20 seconds” and “Red predicts tomorrow’s tech headline; Blue fact-checks the prediction.” Neither requires token ownership to enjoy or vote on the public site.

## 2. IMD integration and trust boundaries

IMD’s [documentation](https://imd.fun/docs/) describes public reads for jobs, schedules, oracle requests, publications and launches; paid actions include `job.open`, `oracle.request`, `workflow.open`, and `schedule.create`, priced at 0.5 IMD in the documentation. The live [`/requests/capabilities`](https://api.imd.fun/requests/capabilities) checked on the assessment date reports 0.5 IMD (18 decimals), paid on Ethereum mainnet with x402/Permit2, and schedules priced per run. It lists Sepolia (11155111), Ethereum mainnet (1), and Robinhood Chain (4663); current mainnet pairings include ETH, IMD and FWA, while Sepolia currently lists ETH. These are live settings, so pin and archive the capability response before ordering.

The current [`/skills`](https://api.imd.fun/skills) catalog includes `create-video` (requires a contributor’s explicitly installed `tool:video`), `research-report`, `build-contract-project`, `frontend-for-contract`, `build-website`, `build-ponder-indexer`, `adversarial-review`, and `create-image`/`create-audio`. That means “IMD creates a video” is supported as a worker skill, not a guarantee that every seat has the necessary video tool or that the result satisfies platform rights and moderation rules. IMD’s artifact route can serve immutable video bytes; a human still approves final media, music, likeness, captions and brand safety.

### Capability matrix

| Function | IMD documented/current support | External integration | Human responsibility |
|---|---|---|---|
| Prompt research, scripts, moderation suggestions | Jobs, research panels, skills | Dashboard vote store | Moderator removes unsafe/infringing items |
| Video generation and artifact delivery | `create-video`; job media/artifacts | YouTube upload adapter | Review, rights, final approval |
| Daily recurrence | Paid schedules; frozen input and run records | Adapter fetches today’s prompt/video IDs | Fund schedule, handle skips |
| Oracle panel | `oracle.request`; panel, quorum, EIP-712 attestation | Evidence collector for YouTube API | Select trusted signer and dispute process |
| YouTube publication | Not an IMD-native platform adapter | Google OAuth/Data API | Channel owner grants/revokes access |
| TikTok publication | Not an IMD-native adapter | TikTok Content Posting API and audit | Creator consent and audit |
| Two tax tokens/pools | Launch supports EVM projects/custom tokens; tax behavior not documented | Solidity contracts, Uniswap pools, indexer | Treasury multisig, deployer, review |
| Settlement/burn | No claim that an oracle attestation proves organic views | Consumer contract verifies round and signer | Human pauses on uncertainty |
| Dashboard | Website/front-end skills and IPFS/ENS workflow | API adapter and database/indexer | Operate keys, backups, incidents |

**Daily lifecycle.** (1) A schedule opens a job or oracle request; its input is intentionally generic and contains the current round identifier. (2) The dashboard writes the prompt/script proposal and snapshot hash. (3) Separate Red and Blue create-video jobs produce MP4 plus metadata; a human approves. (4) An external publisher uses channel-owner OAuth to upload, waits for processing, verifies public status, and records the immutable platform video ID in a round registry. (5) A collector takes opening/closing snapshots and hashes evidence. (6) An oracle question includes round ID, both video IDs, snapshot hashes, metric, timestamps and rules; panel members independently reproduce the read and return the structured result. (7) The signer attests the result; the dashboard displays panel agreement and raw evidence. (8) A settlement executor calls the consumer contract only if all checks pass; otherwise it records no contest.

Schedules have frozen inputs, so they must not be expected to invent tomorrow’s video IDs. Use the scheduled run to open a continuation job or a small adapter job whose stable input contains `seasonId`, `roundNumber`, rules hash and an API endpoint/database key. The adapter resolves the newly created video ID, then creates the round-specific oracle request. This is a proposed extension around documented scheduling, not a verified IMD feature. If a schedule cannot open a dynamic continuation reliably, a human operator triggers the daily job and the schedule remains a reminder/audit trail.

**Trust boundaries.** YouTube/TikTok decide and may revise counters; the collector decides what evidence to submit; IMD panel members decide whether their reproductions agree; the attestation signer decides whether the panel result is signed; the settlement contract decides only whether a valid, unexpired signature matches the configured consumer, season, round, rules hash, video IDs, metric and nonce; the treasury executor controls funds. No agent consensus crosses the platform boundary into proof of organic viewers. Use a 2-of-3 multisig for signer, treasury and publisher operations; keep OAuth and signing keys off-chain, rotate them, and log every use.

## 3. View verification and platform constraints

YouTube’s [Data API overview](https://developers.google.com/youtube/v3/getting-started) documents upload and lookup; default projects have a 10,000-unit daily quota for most endpoints, while [`videos.list`](https://developers.google.com/youtube/v3/docs/videos/list) costs one unit and upload is documented at one unit. [Unverified API projects may upload videos as private until audit](https://developers.google.com/youtube/v3/docs/videos), so publication readiness is a launch dependency. YouTube Analytics requires OAuth and supports targeted reports, but the game should settle on a precisely specified view counter available to both teams’ channel owners, not a private metric unavailable to the public. YouTube’s video reference also records a view-count definition change for all formats from 24 August 2026, so the pilot must archive the metric definition used at launch.

TikTok’s official docs expose `view_count` through video query for an authorized user and through Research API fields, but Research access requires eligibility and approval; its FAQ says new videos can take up to 48 hours to enter the search engine and statistics up to 10 days to update. Direct Post also requires creator authorization and audited clients for public visibility. Those delays make TikTok unsuitable for a daily 48-hour burn race initially.

The panel must sign only after each member checks exact IDs, channel ownership, publication time, opening/closing timestamps, API response hashes and promotion disclosure. Require 5 seats, quorum 4, a 24-hour attestation expiry, and a fixed `rulesHash`. The contract rejects wrong `consumer`, `seasonId`, `round`, `questionHash`, `panelSize`, `quorum`, `agreed < 4`, signer, expiry, duplicate round, or mismatched video IDs. A `settled[round]` bit and immutable evidence hash prevent replay. “Accepted oracle verdict” is not itself a signed oracle result; the signed attestation is the settlement input.

Bots, purchased views, coordinated refreshes, paid ads, API lag and malicious reports remain residual risks. Rate-limit collectors, compare snapshots from both independent collectors, flag discontinuities and engagement/view anomalies, prohibit team-funded promotion during the window, and make unverifiable rounds non-burning. These controls reduce manipulation; they do not prove organic attention. The signer’s trust comes from key custody, public code, recorded panel membership, independent review and a revocation procedure—not from the signature alone.

## 4. Token economics and reproducible scenarios

**Recommendation.** Do not use protocol fees or LP fees as if they were trading tax. Use separate `RED/IMD` and `BLUE/IMD` pools. In production, target a 1% buy and 1% sell transfer tax only when the recipient is a recognized pool, with a hard cap, exemptions for treasury/ burn and a timelocked parameter. Split collected tax: 20% operating reserve, 80% round buyback-and-burn of the winning token. LP fees remain with LPs; IMD job charges remain paid to IMD; protocol fees are a separate budget line. A 1% rate is a ceiling for the pilot, not a promise of liquidity or appreciation.

The [live launch policy data](https://api.imd.fun/launch/policies) is a critical dependency: current policy data reports, among other terms, a 1,000,000,000-token supply for some `evm_project` policies, 80% liquidity, 10% treasury and 10% contributor allocations, but does not document transfer-tax semantics. Do not assume those allocations can be repurposed. Deploy bespoke contracts-only/token contracts only after policy confirmation, or run the pilot off-chain.

**30-day cost model (USD-equivalent planning budget).** Assumptions: two videos/day at $15 each ($900); human moderation/community at $300; publisher/oracle integration at $250; data storage/monitoring at $75; transaction and gas reserve at $100; contingency 20% on these direct costs ($325); total **$1,950**. IMD charges are shown separately: one 30-run schedule = 15 IMD; two initial production jobs plus one dashboard/workflow job and 30 daily oracle requests is approximately 16.5 IMD at the documented 0.5 IMD/action, before retries and continuations. The USD value of IMD is deliberately not assumed; fund at the live quote and add 20% IMD reserve. Initial liquidity is not an operating cost: provision equal-sided $IMD liquidity of **$2,000 per pool** ($4,000 total) only if the treasury accepts the inventory risk. For a non-trading pilot, use no public pools and require a $1,950 cash/crypto-equivalent grant plus roughly 31.5 IMD.

Let `V` be combined daily gross trading volume across both pools, `t=1%` effective tax, and `o=20%` the operating share. Daily tax is `0.01V`; daily operating funding is `0.002V`; daily burn budget is `0.008V`. Over 30 days, tax is `0.3V` and burn is `0.24V`.

| Activity | Combined volume/day V | 30-day volume | Tax collected | Ops allocation | Burn allocation | Interpretation |
|---|---:|---:|---:|---:|---:|---|
| Low | $2,000 | $60,000 | $600 | $120 | $480 | Cannot fund $1,950 pilot |
| Medium | $20,000 | $600,000 | $6,000 | $1,200 | $4,800 | Still needs $750 external ops funding |
| High | $100,000 | $3,000,000 | $30,000 | $6,000 | $24,000 | Covers modeled ops, but creates price-impact/manipulation risk |

Break-even for the modeled $1,950 cash cost using only the 20% operating allocation is `V = 1,950 / (30 × 0.002) = $325,000/day`. If the project instead earmarks $1,950 before the round burns and fills that reserve from all tax, break-even is `$1,950 / (30 × 0.01) = $6,500/day`; that is not the recommended 80% burn split. A prolonged losing streak does not change operating receipts, but it changes who benefits: 80% of that day’s tax buys the winner, so the losing token can experience reduced demand and demoralization. Falling volume reduces both reserve and burn linearly; at $2,000/day, the model yields only $4/day for operations and $16/day for burn.

Sensitivity: at 0.5% tax, the recommended split funds operations at 0.001V, so break-even rises to $650,000/day; at 2%, it falls to $162,500/day but increases friction and incentives to route around the tax. A 10% LP fee tier or ordinary AMM fee is not equivalent to a token tax and would likely destroy competition. Buybacks should use a TWAP/size cap, split orders, a maximum price impact (e.g., 2% per order), and a timelocked executor. Wash trading can pay tax to manufacture a burn, front-runners can trade around predictable buybacks, and thin pools make the treasury overpay. Therefore cap daily burn at 10% of pool depth, postpone if liquidity is below threshold, publish execution and slippage, and never describe burning as guaranteed price appreciation.

## 5. Risks, blockers and adversarial review

Highest-ranked risks are: (1) false organic-view claim; use “reported counter” language, evidence hashes, dual collectors and no-burn fallback; (2) platform/API audit, quota or policy failure; launch owner OAuth and audit early; (3) unverified IMD tax/pairing semantics; confirm policy and deploy to Sepolia first; (4) contract/oracle key compromise; use multisig, expiry, nonce, replay protection, review and pause; (5) thin liquidity and manipulative volume; cap burns and disclose slippage; (6) channel advantage, rights/takedown risk and voter capture; disclose baselines, human-review media, and use snapshot moderation.

Independent challenge: the concept may optimize trading rather than viewers; a high-volume, low-audience outcome is a failure. Two tokens fragment liquidity, and panels can be correlated or wrong. A winner’s burn can make participation less affordable. Measure returning viewers where permitted, watch time as a diagnostic, voter participation, cost per video and disputes; only reported views decide the scoreboard.

Unresolved dependencies are YouTube API audit/public-upload status, channel-owner legal terms, exact IMD schedule continuation behavior, production-tool availability on assigned seats, current launch admission for a tax token, a deployer/signer, token/legal review, and whether the treasury may conduct buybacks under the chosen jurisdiction and platform terms.

## 6. 30-day roadmap, costs and acceptance criteria

**Days 1–5 — prove measurement.** Create test channels, OAuth, quota monitoring, prompt moderation, evidence schema and a dashboard prototype. Upload test Shorts and rehearse disputes. Acceptance: public publication works, IDs and hashes reproduce, quota stays below 20%, and a reviewer reconstructs one round from evidence.

**Days 6–10 — prove IMD orchestration.** Run one paid research/job request, one five-seat oracle request with 4-of-5 quorum, and a 30-run schedule in a non-production environment; archive live capabilities, skill hashes and policy response. Build the adapter that maps `roundNumber` to video IDs. Acceptance: no schedule run silently invents IDs; missed/failed runs are visible; a bad signature and duplicate settlement are rejected in contract tests.

**Days 11–14 — launch the exhibition.** Publish dashboard, treasury address, rules hash, moderator policy and equal budgets. Run three calibration rounds with no tokens or burns. Acceptance: 6 videos, 3 results, zero unhandled evidence gaps, median result latency under 6 hours after close.

**Days 15–30 — run 27 competitive rounds.** Continue daily publishing and weekly prompt votes; record simulated buyback allocations only. Acceptance at day 30: at least 24/30 rounds publish two valid videos, 90% settle within 12 hours, no burn-triggering dispute remains unresolved, evidence is downloadable, cost per video is within budget, and at least 25% of voters return in a later week. Failure conditions: two consecutive unverifiable rounds, platform warning/suspension, compromised signer/OAuth, evidence mismatch, >20% missed uploads, or any proposed buyback exceeding configured price-impact/depth limits. Pause settlement while continuing harmless content only if governance approves.

**After pilot.** Commission an independent Solidity/oracle review, confirm tax and buyback permissions, deploy Sepolia contracts, run a shadow settlement for 14 days, then consider mainnet. Add TikTok only after public-post audit and a lag-aware scoring league has passed a separate calibration. Estimated implementation effort is 2–3 contributors for contracts/indexing, 1–2 for platform adapters, 1 for dashboard, 1 moderation/operator and 1 independent reviewer; the $1,950 direct pilot budget plus 31.5+ IMD and optional $4,000 initial liquidity is the planning envelope, not a quote.

## Recommended MVP, blockers and next swarm tasks

The recommended MVP is: YouTube only; Red/Blue daily Shorts; 48-hour API-counter windows; public evidence dashboard; weekly snapshot vote; IMD create-video/research/oracle/schedule jobs; five-member 4-of-5 signed attestations; multisig treasury; simulated burns; no public trading until contract and policy gates pass.

Prioritized follow-up tasks for the IMD swarm are: (1) run a current `research` panel on YouTube API audit/publication and permitted analytics for two channels; (2) implement and adversarially review the round registry and attestation consumer; (3) build the YouTube publisher/evidence adapter with replayable fixtures; (4) test a dynamic schedule-to-round adapter and document its failure modes; (5) obtain live launch-policy confirmation for tax tokens and `RED/IMD`, `BLUE/IMD` pools; (6) model pool depth, TWAP execution and wash-trade economics; (7) operate the 30-day exhibition and publish the dashboard; (8) only then decide whether real burns are justified.

## Primary references

- [IMD API documentation](https://imd.fun/docs/) — routes, jobs, schedules, oracle attestations, skills, artifacts, payment and launch concepts (accessed 2026-10-06).
- [IMD live capabilities](https://api.imd.fun/requests/capabilities) — current actions, 0.5 IMD price, chains, pairings and limits (accessed 2026-10-06).
- [IMD live skills catalog](https://api.imd.fun/skills) — current skill IDs, requirements and versions (accessed 2026-10-06).
- [IMD launch policies](https://api.imd.fun/launch/policies) — current policy records and allocations (accessed 2026-10-06).
- [YouTube Data API overview](https://developers.google.com/youtube/v3/getting-started), [video resource](https://developers.google.com/youtube/v3/docs/videos), [Analytics API](https://developers.google.com/youtube/analytics/reference), and [quota/audit policy](https://developers.google.com/youtube/v3/guides/quota_and_compliance_audits).
- [TikTok Direct Post](https://developers.tiktok.com/docs/en/content-posting-api-reference-direct-post), [video query](https://developers.tiktok.com/docs/en/tiktok-api-v2-video-query), [Research API query](https://developers.tiktok.com/docs/en/research-api-specs-query-videos), [Research FAQ](https://developers.tiktok.com/docs/en/research-api-faq), and [content-sharing guidelines](https://developers.tiktok.com/docs/en/content-sharing-guidelines).