1. Introduction

The history of stablecoins is the history of collateral borrowed from somewhere else. USDC trusts a bank. DAI trusts ETH's price. Algorithmic stablecoins trust market incentives that proved insufficient under stress. In each case the protocol borrows legitimacy rather than generating it, and the failure modes of the external system become the failure modes of the stablecoin.

A compute network changes this. When a network of nodes processes tasks, verifies outputs, and logs results on-chain, it produces real economic value: verified intelligence. This output is measurable, non-fungible in production, fungible in value, and permanently attested on-chain. The question INFER answers is: what happens when this economic activity is denominated in its own currency?

The answer is a stablecoin that cannot exist without a functioning compute network, and a compute network that is financially stronger because of the stablecoin. Neither is separable from the other. This tight coupling is a design constraint that forces stability (it is a weakness in many other systems): the currency is only as strong as the work backing it, and the work is only as valuable as the currency paying for it.

2. Background

2.1 The IdentityMD Compute Swarm

IdentityMD (imd.fun) is a decentralized network of AI agent nodes. Operators hold ERC-721 identity NFTs granting the right to receive and process tasks dispatched by the network's orchestration layer. Task types include smart contract implementation, security review, research synthesis, frontend development, oracle assessment, and media generation.

The network tracks operator performance via ERC-8004 bindings and an off-chain reputation registry maintained by the control plane. Per-submission metrics (attempts, accepted, rejected, failed) accumulate on each seat and are queryable via the API. The underlying seats are ERC-721 NFTs and can be transferred; purchasing a seat acquires its historical reputation. What cannot be purchased without genuine work is recent reputation: INFER's 30-day recency requirements for governance eligibility and the time-decay term in the reputation floor formula ensure that dormant or purchased history has diminishing economic weight.

2.2 IMD Token Mechanics

The network's native token, IMD, is subject to the Pool4 Uniswap hook: 85% of sell-side volume is automatically burned, with 15% distributed to long-term holders and stakers. This puts a floor under IMD's price and makes exiting large positions expensive, a property INFER inherits through IMD-backed CDPs.

2.3 Network Scale

The fourth statistic matters. Paid request submission is live but barely used — 530 paid actions across the network's entire life, from ten distinct wallets, against roughly 900,000 tasks a month of unpaid traffic. INFER is therefore designed for the network as it will be, not as it currently is. Section 7 addresses the bootstrapping problem: how to launch a stablecoin before its primary revenue source exists.

2.4 The Problem INFER Solves

When paid tasks launch, operators will earn fees in some asset. Without a native currency, earnings carry currency risk if denominated in ETH or IMD, task pricing has no unit of account, and there is no financial layer for compounding or hedging. INFER addresses all three by making the swarm's unit of account the same asset the swarm produces.

2.5 Competitive Landscape — The Denomination Problem Nobody Solved

Decentralized AI compute is an active field. The projects closest to imd.fun's territory are Bittensor (subnet compute), Olas/Autonolas (agent-to-agent marketplace), and Virtuals Protocol (tokenized AI agents). None of them have built what INFER proposes. Understanding why clarifies what INFER is actually doing.

The simplest objection: why not just use USDC? It is a fair question — Virtuals built a working AI economy on USDC in months. INFER's answer is not that USDC fails; it is that USDC is the wrong instrument for a network that wants to be its own financial layer.

When task fees flow to operators in USDC, value leaves the imd.fun ecosystem and accrues to Circle's reserve. The protocol earns no secondary benefit from the volume it enables. With imdUSD, every task fee that flows through the network strengthens the reserve, deepens liquidity, and backs more imdUSD in circulation. The protocol captures the monetary premium of its own activity. Ethereum collects gas in ETH for the same reason: endogenous currency lets the network be its own central bank.

Bittensor is not a competitor. It is a potential customer. TAO subnet operators have a genuine, unsolved problem: compute is priced in a volatile token, making SLAs and multi-month agreements economically irrational. imdUSD could serve as the stable settlement layer for cross-network compute routing (Section 9.2), denominating Bittensor subnet contracts the same way it denominates imd.fun tasks. INFER's TAM is not limited to imd.fun.

3. Design Principles

4. Protocol Architecture

INFER is composed of nine layers. Most leverage existing imd.fun infrastructure. Two layers are novel primitives that INFER introduces and that require protocol extensions: verifier staking (L4) and the Peg Stability Module (L9). The remaining layers formalize or extend mechanisms that already operate in the network.

YLD token design — issuance, supply cap, and secondary market mechanics — is an open design question deferred to community governance. See Appendix B.

Weights are governable on a 90-day review cycle with a 67% supermajority required to change any single weight. The task_volume_7d / task_volume_30d term is the most gameable: short-term volume can be inflated artificially. The 30-day rolling average and outlier clipping reduce but do not eliminate this vector; governance should monitor it.

5. Economic Model

5.1 Fee Distribution

5.2 Stability Threat Matrix

5.3 Liquidity Strategy & Demand

Supply without demand is not a stablecoin. The central question: why would someone hold imdUSD, and how does liquidity deepen over time?

5.3.1 Functional Demand — The Gas Fee Analogy

The most durable form of stablecoin demand is utility demand: you must acquire the asset to use the network. ETH commands persistent value not primarily from yield but because gas requires it. imdUSD is designed to occupy the same position in the AI compute economy.

When paid task submission is live, external users (protocols, developers, DAOs) who want the swarm to implement a contract, conduct a security review, or answer an oracle question must acquire imdUSD to fund the request. This buy pressure originates entirely outside the protocol and scales directly with the quality and adoption of the swarm's output. It is non-speculative, non-mercenary demand that does not disappear in bear markets: if the work is useful, people will keep buying imdUSD to commission it.

That is different from operators simply holding what they earn. Every external requester is a new demand source. The stablecoin's liquidity becomes a function of AI compute market size, not just operator behavior.

5.3.2 Yield — Why Hold Rather Than Immediately Swap

Functional demand explains flow-through. Yield explains holding. imdUSD offers three yield sources at different risk levels:

Verification staking yield is the most important lever. At $10 average task fee, 900k tasks a month, and a 10% allocation to the verifier pool, the pool would accrue $900k a month. Divided across staked imdUSD, that produces a competitive yield at modest stake depth, and it grows with task volume — a compounding incentive to hold. The figure is a ceiling, not a forecast: it assumes every task carries a fee, whereas today 530 paid actions sit against roughly 900,000 monthly tasks. The yield case rests entirely on the paid share rising, which is the same bet the rest of this paper makes.

5.3.3 Protocol-Owned Liquidity

Mercenary liquidity providers leave during stress, exactly when deep liquidity is most needed. INFER avoids this by deploying the protocol reserve as protocol-owned liquidity (POL) rather than letting it sit idle as a redemption backstop.

Structure: the reserve maintains three positions simultaneously:

• Primary pool (imdUSD/USDC on Uniswap v4): Seeded from the 15% task fee allocation. Concentrated liquidity in the $0.97–$1.03 range — tight enough to provide deep depth exactly where PSM arbitrage operates. The protocol earns LP fees while also backing the floor.
• Operator pair (imdUSD/IMD): Operators converting task earnings create organic two-sided flow. The protocol provides initial depth; operator activity sustains it.
• Bridge pair (imdUSD/ETH): Opened after the primary pool reaches a governance-defined depth threshold. Enables imdUSD participation in the broader DeFi ecosystem.

The 20% uncorrelated reserve requirement (USDC/ETH) is satisfied by the primary pool position itself — LP positions are denominated partially in USDC, so the protocol is simultaneously the stability backstop and the liquidity provider.

5.3.4 The Liquidity Growth Path

Liquidity grows in phases tied to network milestones, not arbitrary timelines:

Why imdUSD and not USDC? Virtuals Protocol runs an AI agent economy on USDC and it works. The case for imdUSD is not that USDC fails — it is that USDC exports value. Every task fee paid in USDC flows through Circle's reserves; the imd.fun protocol earns no monetary premium from its own settlement activity. imdUSD inverts this: the 15% task fee allocation flows into the PSM reserve, deepening the stablecoin's backing with every task completed. The protocol is its own central bank. Over time, the reserve grows with adoption rather than sitting static in a fiat account.

The honest answer on why someone holds imdUSD over USDC: In Phase 1, they don't — there is no reason to. In Phase 2, they earn verification yield and gain priority access to compute capacity. In Phase 3, they use it as productive collateral. In Phase 4, they hold it because it is the currency of AI compute, the same reason holders keep ETH for gas. The paper's job is to make Phase 2 credible enough that external capital shows up before Phase 3 requires it.

5.4 Emergency Contraction Protocol

A contraction protocol is only a stability feature if its trigger, actions and resolution are specified. The following is that specification:

Trigger: NHI falls below 0.40 and remains below 0.40 for three consecutive 24-hour epochs.

Automatic actions (no governance vote required):

• New CDP openings frozen
• Proof-of-compute minting halted
• Existing CDPs with collateral ratio below 140% receive a 7-day top-up notice before liquidation proceeds
• PSM redemptions continue uninterrupted — the floor remains active

Resolution — automatic: NHI recovers above 0.55 for five consecutive epochs. All automatic restrictions lift. CDPs remain at tightened ratios until governance votes to revert.

Resolution — governance: 67% supermajority vote with 24-hour timelock (emergency bypass). Governance may selectively resume minting before NHI recovers if the contraction was caused by a known, resolved event (e.g., a single large operator exiting).

What the protocol cannot do: It cannot force operators back online, cannot create demand for tasks that doesn't exist, and cannot substitute for lost real economic activity. If the swarm genuinely dies, imdUSD can only honor the PSM floor from accumulated reserves. This is the honest bound on the protocol's guarantees.

6. Monetary Policy & Load Management

Section 4 and Section 5 describe a stablecoin whose collateral and oracle are native to a compute network. This section argues something stronger and more immediately useful: that the same machinery is the right instrument for governing the compute network itself. A swarm that prices its own work correctly does not need a separate scheduler, quota system, or admission controller. Price is the load controller.

The argument is grounded in measurement rather than theory. Every figure below is taken from the live imd.fun network — per-seat token receipts, a census of all 134 workflows ever opened, and live model prices. The method and its limits are set out in Appendix C; this section states what the numbers mean.

6.1 What the network actually costs

Three facts set the cost base, and none of them are what a reading of the protocol documentation would suggest.

Build work runs on GPT-6 Astra, not on any Claude model. Of 1,532 build jobs dispatched network-wide, 1,439 — 93.9% — went to Codex seats, and nine of the eleven seats holding any build job at all advertise gpt-6-astra at xhigh effort. Astra is the most expensive inference in the comparison: at the token composition those seats actually produce, it blends to $2.66 per million tokens, against $0.49 for Claude Sonnet 5 on the Claude-side mix.

Almost none of the network's load is work anyone asked for. Every job carries a paidBy field. Across 55 sampled oracle requests, spanning the most recent and the oldest available, not one carries a payer; every non-oracle job sampled does. Oracle-assess is 88% of all jobs and roughly 97.6% of all tokens, and it is developer-generated calibration traffic — the questions are the year of Super Bowl I and whether WETH9 returns 18 for decimals().

The paid pipeline is small, concentrated, and unreliable. Of 134 workflows ever opened, 101 were paid and 33 were run by the developer. The 101 come from ten wallets, and one of them opened seventy on a single day in September and has not been seen since — 69% of all paid build demand in one burst. Strip it out and the real figure is 2.1 paid workflows a day from nine wallets.

6.2 What it charges, and where that breaks

Every priced action on the network costs a flat 0.5 IMD, or $3.00, whatever it consumes. Consumption across those actions spans a factor of thirty.

A flat fee across a 30× cost range is not a pricing error so much as an absent control surface. Its sharpest expression is the panel: a requester chooses panel size anywhere from 5 to 100 at no price difference, so a rational requester always chooses 100 — maximum confidence, same fee. The authors of this paper have done exactly that. Nothing but low adoption prevents it from being farmed, and a protocol cannot rule-limit its way out of an incentive it has created.

6.3 Pricing as load control

This is the connection the rest of the paper makes available. INFER already computes a Network Health Index (Layer 6) from fleet acceptance rate, uptime, demand momentum and completion rate, and already uses it to modulate protocol parameters. The same index is exactly what a compute network needs to price congestion — and the protocol that wants it is the one being described.

Three instruments follow, and none require new machinery:

A worked tariff on these lines keeps a small fixed component as the spam gate and adds a resource term:

Calibrated this way the schedule reproduces today's 0.5 IMD at a panel of twenty — the diagnostic that the current flat fee is correctly positioned for exactly one request shape and mispriced at every other. A full three-stage workflow costs 2.85 IMD, or $17.10, against a measured Astra cost of $9.50 per attempt and $24.59 per delivery. Depending on where IMD trades, that covers the attempt comfortably and much or all of the delivery, which is the right target: a tariff that fully priced in a 58% failure rate would be charging successful requesters for the platform's own validation failures.

6.4 The network pays most for the work it throws away

A census of all 134 workflows — every node of every contracts and frontend stage, at full coverage — settles what failure costs. The intuition that a blocked workflow dies early is wrong.

A failed workflow consumes 114% of what a successful one does, burning 3.5× the revisions, because blocking happens after the revision budget is exhausted rather than before it is spent. Across the 31 organic paid workflows: 292 node-runs, 111M tokens, $264 of Astra, producing twelve deliveries. One delivered workflow costs 9.24M tokens, or $24.59, against $7.75 in fees — the $3.00 sticker multiplied by the 2.6 attempts a delivery takes.

And the failures are not the agents' failures. Of the nineteen organic failures, sixteen — 84% — have every single node in the accepted state. The contracts were written, the tests were written, four audits and a judge passed them, and the workflow still produced nothing: these builds die at the manifest and launch gate after all the work is done and paid for.

That is a load-management finding before it is a pricing one. More than half of the compute the paid pipeline consumes is spent on work that is accepted and then discarded. No tariff recovers that; only a gate that fails earlier, or an escrow that stops funding it, does.

6.5 The subscription substrate

Underneath all of it sits a subsidy that no participant is pricing and the protocol does not control. Operators do not buy inference per token; they buy flat-rate consumer AI subscriptions and contribute the marginal tokens at a cost to themselves of zero. The gap is large enough to be the actual economic engine of the network.

The size of that subsidy depends on which plan an operator holds, and the plan cannot be observed from outside — only inferred from throughput. This paper's own seat is the anchor: it sustained 1.23B tokens a month on a $20 Claude Pro plan and hit the session limit, stopping the service. That places the Pro ceiling near 1.2B tokens a month, which means the two highest-volume seats on the network, at 2.0–2.1B a month, cannot be on it. High-volume operators — builders especially, running a premium model at xhigh effort — are buying the expensive tiers their demand requires.

That makes the arbitrage sawtoothed rather than uniform. It is maximal for an operator running a cheap plan to its ceiling and minimal for one who has just been forced to upgrade:

The policy consequence is sharp, and it inverts the usual reading. The subsidy is smallest for the operators doing the most valuable work. A builder on a $200 plan contributes compute at roughly fifteen times the real cost of an oracle seat running a $20 plan to its limit — and the protocol pays them identically, because the 8% bucket distributes by presence. A compute network whose reward is flat and whose costs vary fifteenfold is selecting against its own builders.

6.6 Monetary policy implications

7. Bootstrapping Sequence

INFER has two distinct deployment layers with different dependency profiles. Understanding which components require imd.fun's cooperation — and which do not — determines the realistic launch path.

v1 — Permissionless Launch Deployable today, no coordination required

v2 — Protocol Integration Target steady state, requires imd.fun coordination

v2 replaces the trust assumptions of v1 with trustless on-chain mechanisms. Each upgrade is independent — they can be adopted one at a time as imd.fun's protocol evolves. None requires a single-point permission from the team; each is a governance proposal that the imd.fun operator community can vote on once imdUSD has demonstrated value.

8. Security Considerations

What follows analyzes adversarial scenarios against INFER's architecture. Each threat is assessed on attack cost, detection probability, and protocol response. No system is fully attack-proof; the goal is to ensure every realistic attack is economically irrational or detectable at a scale that permits intervention before systemic damage occurs.

8.1 Reputation Sybil Attack

An adversary creates many nodes, maintains high acceptance rates for 12+ months, then uses accumulated reputation to open large CDPs and drain the reserve. The attack requires sustained investment: real compute infrastructure, real inference costs at commercial rates, and real time. At current inference pricing, accumulating the reputation floor for a meaningful CDP (sufficient to extract material value from the reserve) requires months of continuous operation at a cost that exceeds the expected extraction value under the 25% LTV cap.

Mitigation layers. The time-decay factor in the NHI formula degrades reputation collateral value by 5% per month of inactivity — an attacker who pauses operations to consolidate their position loses collateral credit continuously. The 25% LTV cap limits maximum extractable value per node. The global minting ceiling (Layer 1) limits aggregate extraction across all reputation CDPs network-wide. A coordinated multi-node Sybil attack triggers the outlier detection in the NHI formula (2σ clipping on task volume) before the attack reaches meaningful scale.

Residual risk. A patient, well-capitalized adversary who operates nodes legitimately for 18+ months could accumulate sufficient reputation to create a meaningful CDP at favorable terms. The protocol does not fully eliminate this possibility — it raises the cost to the point where the attack is economically dominated by simply continuing to earn legitimately. Governance should monitor the distribution of reputation scores and CDP positions for unusual concentration; a Gini coefficient threshold for CDP concentration could trigger a governance review.

8.2 Verifier Cartel

A majority of staked verifiers collude to falsely accept low-quality work, enabling unbacked imdUSD minting at volume. The attack requires recruiting a supermajority of the verifier stake — difficult because verifiers are anonymous, geographically distributed, and have conflicting economic interests (a cartel member who defects and reports earns the slashed bonds of the colluders).

Mitigation layers. Slash amounts scale superlinearly with coordinating cluster size — a 10-verifier cartel each faces 10× the standard slash, making the expected slash penalty grow faster than the expected gain as the cartel expands. Random second-pass oracle-assess sampling provides continuous audit coverage; the probability of a colluding verifier being caught in any given batch is known in advance and factors into the expected value calculation. The insurance reserve provides a backstop against unbacked minting that escapes detection; the insurance scope document defines governance's response to large-scale collusion events.

Game-theoretic note. Verifier cartels are inherently unstable. Every member has a dominant strategy to defect: defecting verifiers earn the slashed bonds of colluders, face no penalty if they report before the batch finalizes, and exit with a profit. Rational self-interest dissolves cartels when detection probability is non-zero and slash penalties are credible. Governance should maintain slash credibility by demonstrating at least one executed slash event early in the protocol's life, even against a small colluder.

8.3 Oracle-Collateral Correlation (Primary Systemic Risk)

This is the most significant structural risk in the protocol. The Mint Oracle that authorizes imdUSD issuance is operated by the same agents whose IMD holdings back CDP collateral. If IMD price falls sharply, CDP collateral loses value simultaneously with the oracle panel's economic stability — reducing both their financial capacity and their incentive to participate honestly. In a severe scenario: IMD drops 60%, CDPs liquidate, oracle panel members facing losses may collude or go offline, oracle integrity degrades, and the reserve faces claims from multiple directions simultaneously.

Why 200% collateral ratio matters. A position opened at 200% reaches the 130% liquidation threshold after a 35% IMD drawdown, and only becomes genuinely undercollateralised — collateral worth less than debt — after a 50% one. That 65-point gap between opening and liquidation is the runway the ratio buys: liquidators can clear the position while it is still over-collateralised. A 50%+ drawdown is a severe market stress event, not a routine correction. Historical precedent from comparable tokens suggests such drawdowns occur in broad crypto market crashes — events that also stress USDC (the reserve's PSM backing). The protocol is not immune to systemic market risk, and it does not claim to be.

Mitigations. The IMD collateral ratio (200%) is conservative relative to the MakerDAO ETH-A equivalent (150%) to account for IMD's lower liquidity. The POL USDC buffer provides a reserve floor independent of IMD price. The emergency contraction protocol triggers at NHI < 0.4 — a level indicating prolonged network stress that would precede a catastrophic IMD drawdown — giving governance time to reduce imdUSD supply before collateral fails. The oracle failure mode (Layer 3) switches to TWAP pricing and freezes minting if the panel goes offline, preventing the oracle-collateral correlation from producing new unbacked supply during a crisis.

Residual risk disclosure. A simultaneous severe IMD crash, oracle panel failure, and PSM USDC reserve drain is a scenario the protocol cannot fully absorb — imdUSD would de-peg. The architecture reduces this risk but does not eliminate it. Any participant holding imdUSD in large quantity should assess their exposure to this correlation.

8.4 NHI Manipulation

Operators artificially inflate short-term task volume to push the task_volume_7d / task_volume_30d ratio above 1.0, triggering favorable minting parameters during the inflated window. The most direct form is wash trading: an operator submits tasks to themselves using a separate requester address, paying imd.fun fees on both sides to make the volume appear organic.

Cost of attack. Each submitted request costs 0.5 IMD whatever the panel behind it — the panel members' own tasks are not separately billed. To move the 7d/30d ratio materially for a network with thousands of agents, the attacker must inflate a significant fraction of total network task volume — requiring thousands of wash tasks and burning IMD at spot price. The minting benefit (a marginally more favorable mint ratio) is unlikely to exceed the cost of inflating volume at the network scale required to affect the NHI.

Detection. Wash trading is detectable by correlating requester addresses with operator NFT ownership, monitoring task-requester concentration (a single requester address accounting for an anomalous share of one operator's task volume), and flagging requester addresses that submit tasks but never appear as verifiers or operators. Governance holds the authority to investigate flagged patterns and adjust NHI weights in response.

Longer-term fix. Replacing the 7d/30d volume ratio with unique-requester-count (how many distinct addresses submitted tasks in the period) makes wash trading far more expensive — the attacker must control many distinct EOAs and pay gas for each. This is flagged as an open question in Appendix B.5 and should be evaluated once the network has enough data to assess whether the current formula is being gamed in practice.

8.5 PSM Reserve Drain

A coordinated attack mints large imdUSD at the ceiling, sells into the open market to suppress price below $0.99, then redeems at the floor for $0.99 USDC — extracting the $0.01 spread at volume. The per-unit profit is small but the attack can be run at volume. A 1M imdUSD drain attempt would cost $10,000 in spread capture but requires successfully both moving the market price below $0.99 (fighting the POL's concentrated liquidity defense) and sustaining a sequence of large redemptions before the automatic pause triggers.

Defense layers. The POL's concentrated liquidity position in the $0.97–$1.03 range provides deep bid support: selling into the POL moves price minimally because the position is sized to absorb single-sided pressure. Redemptions are automatically paused when the PSM reserve falls below 10% of outstanding supply. At that point, the floor is suspended and governance must vote to recapitalize — the attack cannot drain beyond the 10% threshold without triggering a governance response. The fee on PSM minting (50 bps) means the attacker pays 0.5% on the way in; to extract the $0.01 spread they must first overcome 0.5% cost, leaving only $0.005 per unit of profit — making large-scale attacks economically thin.

Flash loan risk. A sophisticated attacker could use flash loans to mint and redeem within a single block, but the PSM's per-transaction redemption limit and the 10% reserve floor automatically enforce a ceiling on single-block extraction. Adding a minimum holding period (e.g., 1 block) before redeemed imdUSD can be minted again would eliminate flash loan exploitation entirely at the cost of fractional UX friction.

8.6 Governance Capture

A well-capitalized adversary accumulates a supermajority of governance weight by acquiring IMD tokens, operator NFTs, or a large imdUSD stake, then uses that weight to pass a malicious governance proposal: draining the reserve, disabling slashing, or changing the collateral ratio to zero.

Structural defenses. INFER governance weights three constituencies (IMD holders, operators by task volume, imdUSD stakers), each capping at 33% weight regardless of absolute size. Capturing governance requires supermajority across all three simultaneously — an attacker who buys a majority of IMD still holds at most 33% of governance weight and cannot pass proposals alone. Time-locked governance execution (minimum 48-hour delay between proposal passage and execution) gives honest participants time to observe and respond to a malicious proposal before it executes. Emergency veto power held by a small multisig (e.g., 5-of-9 respected ecosystem participants) can cancel obviously malicious proposals during the timelock window — a centralization concession justified by the early-stage trust requirements.

Gradual decentralization. The multisig veto should sunset on a defined schedule (e.g., after 24 months or after imdUSD supply exceeds $10M), replaced by a time-based lock escalation. Governance parameters should include a maximum single-proposal change limit — no governance vote can move the collateral ratio by more than 20 percentage points or the PSM fee by more than 100 bps in a single proposal, forcing large changes to accumulate over multiple voting cycles and giving the community time to exit if they disagree with the direction.

8.7 Seat NFT Acquisition Attack

ERC-8004 reputation history travels with seat NFT transfers. A high-reputation operator could sell their seat to an adversary who immediately uses the inherited reputation as collateral for a large CDP, mints imdUSD, and exits. The original operator exits with sale proceeds; the adversary exits with imdUSD and abandons the position.

Mitigation. CDP collateral is denominated in the current NHI score at liquidation time, not at origination time. A seat that ceases operating after transfer sees its NHI decay (5% per month) and task volume collapse to zero — which drops the 7d/30d ratio in the NHI formula to near zero within days. A CDP opened immediately after transfer using inherited reputation will face rapid collateral depreciation as the inactive-node NHI decay takes effect. The 25% LTV cap and the CDP minimum duration requirement (position must be open for at least 7 days before the reputation component counts at full weight) reduce the extraction window further.

Residual risk. A brief extraction window exists between seat transfer and NHI decay. Governance should monitor large CDP openings that coincide with seat transfer events on-chain, which are observable. An automatic 30-day reputation freeze on CDPs opened within 7 days of a seat transfer would close this window entirely — the position could be opened but the reputation collateral component would not count until the new operator has demonstrated continued operation.

8.8 Smart Contract Exploit

A vulnerability in the INFER reserve contract, PSM, CDP manager, or Mint Oracle contract could allow unauthorized minting, reserve drain, or collateral theft. This is the highest-severity risk category because it is binary: a critical exploit can drain the entire reserve in a single transaction before governance can respond.

Pre-launch requirements. The INFER contracts must complete at minimum two independent security audits from firms with a track record in DeFi protocol security (e.g., Trail of Bits, OpenZeppelin, Spearbit, or equivalent) before any mainnet deployment. Formal verification of the reserve accounting invariants (total imdUSD supply ≤ reserve value at PSM floor) using a tool such as Certora Prover or Halmos should be completed for the core reserve and PSM contracts. A public bug bounty program with meaningful rewards (at least $100k for critical findings) should run for 90 days before mainnet, incentivizing independent security researchers.

Operational security. The reserve treasury should be held in a time-locked multisig (not a single EOA or immediately-executable contract) to add friction to any exploit that requires owner-controlled calls. Contract upgradability, if implemented, should use a transparent proxy with a governance-controlled upgrade delay (minimum 48 hours), preventing instant backdoor deployment. Admin key custody should follow hardware wallet best practices with geographic distribution of signers.

Insurance. Protocol-level smart contract insurance (Nexus Mutual, Sherlock, or equivalent) should be purchased for the reserve contract prior to launch, providing a backstop for covered exploit scenarios. The insurance premium is a legitimate reserve expense and should be budgeted as a fixed operational cost proportional to TVL.

8.9 AI Model Provider Risk

INFER's oracle integrity depends on the AI models underlying the swarm producing consistent, honest outputs when given the same task. If a major model provider (Anthropic, OpenAI) changes their model's behavior, introduces safety restrictions that alter task outputs, or experiences a service outage, the oracle panel's unanimity assumption could fail systematically.

Provider concentration risk. If a supermajority of the swarm runs one runtime — today two-thirds run Codex — and that provider deploys a model update that changes how oracle-assess tasks are evaluated, panel unanimity breaks — not through malice but through synchronous behavioral drift. The protocol's tolerance window (toleranceBps = 200) absorbs small variance, but a systematic model behavior change affecting all Claude nodes simultaneously could push disagreement beyond the tolerance threshold and trigger oracle failure mode for all tasks simultaneously.

Mitigation. Governance should track the runtime distribution of active agents (currently 67% Codex, 33% Claude Code) and set a target maximum provider concentration (e.g., no single AI provider supplying more than 60% of oracle panel capacity). If concentration exceeds the threshold, governance can incentivize operators to onboard alternative runtimes (subsidized Codex setup grants, for example). The diversity of the panel is itself a systemic resilience property — a panel of up to 100 agents drawn across multiple AI providers is substantially more sound against unilateral provider behavior change than any small fixed panel.

Rate limit and quota risk. Sustained periods of model provider rate limiting (as observed historically: 61 rate limit events in a single hour during peak demand) can cause oracle panel members to fail task submissions, degrading acceptance rates and potentially triggering the oracle failure mode. The protocol should treat prolonged rate limiting (oracle failure for > 3 hours) the same as oracle outage and execute the TWAP grace period protocol. Operators managing provider quota risk through concurrency controls (reducing to concurrency 1 when quota is high) is an existing operational practice that mitigates this at the node level, but has no on-chain visibility — governance cannot currently observe quota stress across the fleet in real time.

8.10 Regulatory Considerations

imdUSD has not been reviewed for legal or regulatory compliance in any jurisdiction. The following analysis reflects the authors' non-legal assessment of likely classification frameworks; independent legal counsel is required before any deployment.

Security classification (US). Minting imdUSD in exchange for verified work may constitute issuance of a security under certain interpretations, particularly if holders expect profits primarily from the efforts of others (the Howey test). The key distinguishing factor is that all imdUSD minting rights flow from personal labor — the minter must personally operate a node and complete verified tasks. Passive holders who receive imdUSD in exchange cannot mint more; the minting function requires active participation. This distinguishes imdUSD from typical ICO tokens where passive investment generates returns. However, the YLD yield mechanism (imdUSD stakers receiving fee income) could be characterized as a profit expectation from others' efforts if the stakers are not themselves operators. This is the most significant regulatory exposure and should be analyzed by legal counsel with specific expertise in SEC digital asset enforcement positions.

MiCA (EU, 2024). Under the Markets in Crypto-Assets regulation, imdUSD would likely be classified as an asset-referenced token (ART) rather than an e-money token, because its value is maintained relative to the USD through reserve mechanisms rather than direct fiat backing. ART issuers face reserve, redemption, and disclosure requirements — requirements the PSM architecture is designed to satisfy. The PSM's published reserve composition, automatic redemption at floor price, and governance transparency are directly aligned with MiCA's ART operational requirements. A MiCA-compliant deployment would require a licensed issuer entity in an EU member state, ongoing reserve disclosure, and limits on ART supply if the token becomes "significant." Governance should engage a MiCA specialist early if EU market access is a priority.

CFTC jurisdiction. The compute futures market described in Section 9.1 could fall under CFTC jurisdiction as a derivatives market if imdUSD is classified as a commodity (analogous to how the CFTC asserts jurisdiction over Bitcoin and Ethereum futures). Registration, reporting, and margin requirements would follow. The spot imdUSD market is less likely to be characterized as a CFTC instrument, but the combination of a stablecoin with a futures layer increases regulatory surface area materially.

Practical path. Deploying INFER in a jurisdiction with a clear digital asset framework (Singapore MAS, UAE VARA, Switzerland FINMA) before US or EU deployment allows the protocol to establish a compliance track record and legal precedent before engaging the most complex regulatory environments. Foundation structure (e.g., a Cayman Islands or Swiss foundation holding governance keys with a clear mandate) is the standard model for decentralized protocol legal wrapping and reduces personal liability exposure for core contributors.

9. Future Considerations

10. Conclusion

imdUSD is a stablecoin whose stability mechanisms are native to the compute network it backs. The peg is maintained by a reserve-funded redemption floor and a proof-of-compute minting ceiling. Collateral is IMD tokens and ERC-8004 operator reputation. The oracle is the swarm itself. Governance belongs to active operators. The main systemic risk — oracle-collateral correlation — is mitigated but not eliminated, and is disclosed clearly.

The bootstrapping problem is real and is addressed in two stages. v1 is permissionless: IMD collateral CDPs, a USDC-backed PSM, and a trusted reputation bridge can be deployed by the operator community today without any approval from the imd.fun team. v1 proves the concept in a live environment with real capital at stake. v2 is integrated: automatic fee routing and native on-chain ERC-8004 reads replace the remaining v1 trust assumptions one by one, each requiring a governance proposal that the operator community — as imdUSD holders — has direct incentive to support. Adoption precedes integration: v1 earns the conversation; v2 closes it.

The emergency contraction protocol has a precise trigger, defined actions, and specified resolution conditions. The regulatory exposure is real — particularly around MiCA ART classification and CFTC jurisdiction over the futures market extension — and requires independent legal review before any deployment.

The monetary policy layer is the part of this paper grounded in measurement rather than design. The swarm already runs on economic incentives; it simply runs on incentives nobody chose — a flat fee correct for one request shape, a reward bucket that pays for presence, and a subscription subsidy no participant prices. Correcting those is cheaper than any mechanism in the preceding sections and does not require imdUSD to exist first.

Open questions: the YLD token design, the precise governance parameters for the insurance scope, the regulatory classification in specific jurisdictions, the ReputationBridge signing committee composition, and whether the NHI formula weights are optimal. These are questions for community governance and empirical testing. They are enumerated in Appendix B.

The core claim is modest and verifiable: a stablecoin backed by compute network revenue, with a defined redemption floor and a permissionless launch path, is more resilient than a stablecoin backed by nothing except market incentives or one that requires institutional cooperation to exist at all. The rest — reputation collateral, swarm oracles, operator governance, protocol integration — are extensions of that foundation, each adding endogenous support. Whether those layers perform as described requires building v1 and observing it under stress. That work is ahead.

Appendix A — Glossary

Appendix B — Open Questions

Appendix C — Measurement Method

Section 6 states what the swarm costs and what follows for policy. This appendix records how those figures were obtained, so that each can be checked or re-derived, and sets out what they do not establish.

C.1 Data sources

Prices are OpenRouter's published per-million rates, read live on 2 October 2026. IMD is taken at $6.00, its Uniswap v4 price at the same moment; every dollar figure in this paper that is denominated in IMD recomputes from the live price when the page is opened online.

C.2 Token accounting

One subtlety matters more than it looks. The receipts report a single cachedInputTokens figure, but Anthropic bills a cache write at 1.25× the input rate and a cache read at a tenth of it — a 12.5× spread. The 230 local transcripts show writes are 9.2% of all cached tokens, and that split is applied to every Claude figure. OpenAI's cache has no write premium, so Codex figures need no such adjustment. Ignoring this understates Claude-side cost by roughly 40%.

At the compositions the two runtimes actually produce, the blended rates are:

C.3 Recovering the build-node cost

Build-node cost cannot be read directly off any seat, because even the busiest builders spend most of their attempts on oracle work — the purest is 21% build. It is recovered by regressing tokens-per-attempt on build-share across all 414 Codex seats with at least 50 attempts, weighted by attempts. The intercept is the oracle attempt; intercept plus slope is the build attempt.

C.4 The workflow census

Every one of the 134 workflows ever opened was read in full — both the contracts and frontend job of each, with every node's role, state, attempt count and revision count — at 100% coverage. Payer attribution comes from the paidBy field on the same records. This is a census, not a sample, and it is the basis for the failure-cost and failure-mode figures in 6.4.

The endpoint sheds load under bulk reading: roughly three hundred reads in a few minutes caused the plane to return 503 {"error":"busy"} on all record reads, and an earlier attempt silently returned node data for only 17 of 134 workflows. Pacing at 1.2 seconds per request with exponential backoff gave full coverage over 268 reads in about six minutes. Any replication should pace similarly and verify coverage before using the result.

C.5 Inferring subscription tiers

Effective subscription rates are throughput divided into a list plan price, and the plan a given operator holds cannot be observed — only bounded. The anchor is this paper's own seat, which sustained 1.23B tokens a month on a $20 Claude Pro plan and hit the session limit, stopping the service. That places the Pro ceiling near 1.2B tokens a month and rules it out for the two highest-volume seats, which run 2.0–2.1B. Builders running a premium model at xhigh effort are assumed to hold the higher tiers their throughput requires. These are inferences from observed delivery against published prices, not statements about what any operator pays.

C.6 What this does not establish