Yes, conditionally. Taking the stated IMDSTR fee policy as the premise, the loop is: trades generate fees → fees buy identity.md NFTs → their holder pairs devices and puts seats to work → those seats may earn income or influence work that attracts further activity. An NFT is an access right, though, not an automatically running worker: IMD’s pairing flow requires authorization from the wallet holding the seat, and its records distinguish owners from online workers and completed work. I could not establish IMDSTR’s current NFT holdings from the sources reviewed, so this is a model of what could happen, not a measured ownership share. IMD API docs

Let (s=N/2{,}000) be the share acquired, (fV(s)) the trading fees per period, (R(s)) any seat earnings reinvested, (a) the fraction actually spent on NFTs, (P(s)) the price per NFT, and (\delta s) the share lost through sales or other attrition. A useful approximation is

[ \dot s=\frac{a[fV(s)+R(s)]}{2{,}000P(s)},L(s)-\delta s, ]

where (L(s)) falls as purchasable NFTs become scarce. Fixed points satisfy purchases equal attrition. With no attrition, continuing fee income and available sellers, holdings keep rising; there is no interior resting point. Zero is stable if activity cannot fund the first purchase. A positive, self sustaining fixed point requires the extra fees and reinvested earnings caused by one more active seat to fund its replacement faster than seats are lost. As supply tightens and price rises, growth slows or stops. These are model conditions, not contract guarantees. The collection has 2,000 NFTs. Identity MD collection

What breaks the loop: trading volume or the fee allocation falls; NFT prices outrun fee income; holders decline to sell; proceeds are distributed instead of reinvested; or acquired NFTs are not paired with funded, eligible, online devices. Independent reruns and reviews can also prevent a bloc of seats from turning ownership into accepted output. IMD API docs

Behavioral threshold: count active, eligible seats under common direction, not NFTs in a wallet. At 200 NFTs (10% of supply), the position is economically meaningful, but 10% alone gives no control of a uniformly sampled panel: in an illustrative five seat panel requiring three agreeing members, its chance of supplying three is about 0.86%. At 500 seats (25%) that chance is about 10.35%; above 1,000 (50%), it exceeds 50%. IMD documents configurable research panels of one to nine members and a quorum, so those figures illustrate the mechanism rather than describe every IMD job. The practical threshold can arrive much earlier if most other NFTs are offline or selection favors the bloc: control depends on its share of the eligible pool, while any formal blocking or approval threshold depends on the actual quorum rule. IMD API docs

---

Sources offered but not confirmed by this machine:

• https://imd.fun/docs/ — does not contain the quoted text
• https://imd.fun/docs/ — does not contain the quoted text
• https://imd.fun/docs/ — does not contain the quoted text
• https://web3.okx.com/nft/collection/eth/identitymd-1 — does not contain the quoted text

I could only partly check this, so here is what is and isn't confirmed. The IMDSTR contract is real and does what you describe. I could not find the 2,000-seat total in any source, so it is taken from your question. Nothing I read says whether the seats IMDSTR holds send their earnings back to it. The model below leaves that as a variable instead of assuming it.

What the sources show

• The contract. 0x0000198C…7d2F is a verified contract named IMDSeatStrategy, token IMDSTR. It has buyTargetNFT, sellTargetNFT, addFees, a priceMultiplier, setDistributor, authorizeWorker (device key plus wallet) and registerAgent(tokenId, agentURI). So it can buy seats, resell them and run them as workers. When I looked, about 21 hours after it was created, it held 1 identity.md NFT, had made one "Buy Target NFT" for 1.95 ETH, and held 0.598 ETH (Etherscan). That is roughly 2.5 ETH of fees in under a day, during launch hype.
• The design it copies. TokenWorks' NFTStrategy (PunkStrategy) puts a tax on token trades. It "purchases the cheapest CryptoPunk", relists it (first at 2×, later 1.2× the purchase price), and uses the sale proceeds to buy back and burn the token. The explicit aim is to "buy and sell in perpetuity, fueled by token swap volume" (tpan). So the design is a pipeline that keeps turning seats over, not a vault that hoards them.
• How seats work. One NFT is one seat, and "One NFT authorizes one device" (node guide). Seat owners "run daemons that claim jobs", paid work costs 0.5 IMD per action, and a verifier re-runs the work to judge it (writeup). The swarm assigns jobs, and a deep review job uses six seats (launch-131).
• How many seats are actually active. The writeup counted 270 seats enrolled. When I loaded the explorer it showed 395 seats online and 93 working (explorer). So only about 15–25% of the 2,000 seats are live. This turns out to be the most important number in the whole question.

The model

Notation:

• N = 2,000 seats; S = seats the strategy holds; x = S/N.
• P(x) = floor price of a seat. It rises as the strategy removes cheap listings: P(x) ≈ P₀ / (1 − x/ℓ), where ℓ is the fraction of seats their owners would ever sell. P₀ is about 1.7–2 ETH today.
• F = φ·V = fee inflow in ETH/day, where V is IMDSTR trading volume and φ is the share of the tax that goes to buying seats.
• r(x) = what one active seat earns per day. If paid demand D is fixed, r ≈ D / (A₀ + xN), where A₀ is the number of other active seats (about 400). Every seat the strategy switches on dilutes everyone, itself included.
• σ = fraction of the strategy seats' earnings routed back into buying more seats (unknown; 0 if not routed).
• τ(x) = average time a seat is held before a relist at price × m sells (m = 1.2 in the TokenWorks design).

How the share changes over time:

dx/dt = [φV + σ·r(x)·xN] / (N·P(x)) − x/τ(x)

The first term is buying (from fees, plus from the seats' own earnings); the second is seats leaving through relist sales.

Fixed points

1. x = 0. This is where things settle when trading volume dies and no earnings are recycled (V → 0, σ = 0). It is the default end state for strategy tokens, because hype volume fades.

2. Fee-driven equilibrium: x* ≈ φV·τ / (N·P(x*)). Buying falls as the price rises, and selling rises with inventory, so the two lines cross once and the point is stable. The strategy owns roughly what the fees buy during one holding period. At the launch rate of about 1 seat per day, with a hold of a few weeks, that is 20–60 seats (1–3%). If volume falls tenfold, it drops below 0.5%. If the strategy never relists (τ very large), it accumulates at about 1 seat/day: roughly 5% after 100 days, and slower in practice as P(x) rises.

3. Self-funding equilibrium (only if σ > 0). The loop sustains itself without traders only if its gain g = σ·r·τ / P is at least 1, meaning a seat earns back its price before it is sold. But the market sets P by capitalising a seat's expected earnings, which keeps g near yield × holding time, well below 1. If g did exceed 1, the growth would stop at the x** where σ·D·τ / ((A₀ + x**·N)·P(x**)) = 1: the dilution term and the price term shut it down. So the swarm cannot buy itself with its own earnings. Reinvesting just means buying at the market's yield, like any other holder. The only fuel that isn't priced in is speculators' trading fees on IMDSTR. Ownership lasts only as long as that volume does.

4. Hoarding corner (priceMultiplier set very high, so no sales). The share only ratchets upward. It is limited by total fees collected and by how many holders will sell (ℓ). This is the only path to a large share, and it needs sustained volume.

What breaks the loop

• Volume decay. Fees are proportional to trading volume, and strategy-token volume is front-loaded. Once volume drops, fixed point 2 collapses toward 0, while relists keep draining inventory.
• Rising floor. The contract has already paid 1.95 ETH for one seat. Removing cheap listings from a thin float pushes P up faster than linearly, so each seat costs more fees.
• Relisting by design. At 1.2× the seats flow out again, so the strategy holds inventory, not ownership.
• Earnings dilution. Switching on idle seats raises the active count, which lowers r for everyone, so self-funding weakens as the strategy grows. If the strategy buys seats and leaves them idle, it changes nothing about how the swarm behaves.
• Protocol checks. The swarm assigns jobs itself, there is a per-worker standing check, and a verifier re-runs work. Poor or colluding seats earn nothing, and the operator can cap how many jobs go to one wallet or operator.
• Single key-holder. authorizeWorker and setDistributor are privileged. One compromised or careless admin key controls every strategy seat at once.
• Reflexive downside. A falling IMDSTR price means lower volume, then relist sales, which lowers the floor, which weakens the IMDSTR story. The same flywheel runs in both directions.

Threshold: when does it change how the swarm behaves?

Share of the 2,000 seats is the wrong denominator. What matters is q = the strategy's share of online seats, because only those get jobs. All strategy seats likely run under one operator, with one model, one prompt and one set of servers, so they fail together and could collude.

With about 400 other seats online, q = S / (400 + S):

Strategy seats	Share of 2,000	Share of online (q)	Effect
~20	1%	~5%	Just another fleet operator; no change.
~80	4%	~17%	About one strategy seat in every 6-seat job on average. With random assignment, about 5–6% of 5-seat jobs get a strategy majority. Independent review starts to lose its independence.
~200	10%	~33%	Chance of a strategy majority in a 5-seat job: about 20%. About 11% of worker–verifier pairs are the same operator (q² ≈ 0.11), so the verifier re-run stops being independent. If the strategy's servers go down, a third of live capacity disappears.
~400	20%	50%	Strategy seats are half of all online seats: effective control.

My threshold: about 4–5% of the 2,000 seats (roughly 80–100 active seats) is where behaviour starts to change: every job tends to include a correlated seat, and the ability to take part in jobs is concentrated in one key. About 10% (roughly 200 seats) is where it becomes a governance and verification risk.

Two things move this:

• If idle holders come online because seat prices rise, the online count grows and the threshold rises toward the nominal figure (a third of 2,000 is about 667 seats).
• If jobs are capped per operator, the threshold rises roughly by the size of the cap.

Bottom line: at the observed fee rate, the fee-driven equilibrium is 1–3%, and it falls as volume fades. Getting past the 4–5% threshold needs months of sustained IMDSTR volume, or turning relisting off, and it is never self-sustaining.

---

Sources offered but not confirmed by this machine:

• https://etherscan.io/address/0x0000198C940D8cD70Cb9ACeC5E3af8216ac57d2F — did not return a page

I have enough source material. Here is the model.

What the loop actually is

The contract at 0x0000198C…7d2F is a verified minimal proxy named IMDSeatStrategy, issuing the ERC-20 "Identity.MD Strategy (IMDSTR)" with 38 holders, and it already holds one identity.md (IDMD) NFT bought for about 1.95 ETH (Etherscan token page, Etherscan address page). The ABI is the TokenWorks strategy template (buyTargetNFT, sellTargetNFT, burn, processTokenTwap, buyIncrement, priceMultiplier) plus three functions the template does not have: registerAgent, authorizeWorker and workerAuthorizationDigest (implementation). Those three are the "run the NFT as a seat" half of the loop.

The template economics, per Bankless: "Trades of that token skim a 10% fee, with the bulk of it (8%) pooling into ETH." and "Once the pool reaches the price of that collection's lowest floor NFT, the protocol buys it and relists it at a 20% markup." (Bankless). The target collection is capped: max total supply "2,000 IDMD", 782 holders (Etherscan IDMD). Each seat binds to one machine: "One identity.md NFT per node. One NFT authorizes one device." (imd-node-guide).

So the loop has two channels feeding one stock:

• Fee channel. IMDSTR volume V per period, fee capture φ (8% in the template), floor price P. Seats bought per period ≈ φ·V / P.
• Earnings channel. Each contract-owned seat that is dispatch-eligible earns IMD payouts and launch allocations (Swarm Ledger tracks "every IMD payout the developer sent to that wallet's seats for running the daemon" per swarm-ledger). Call the per-seat yield y = E/P per period. If reinvested, this adds y·N seats per period.

Stock equation, hold mode (contract keeps seats and runs them):

dN/dt = φ·V(t)/P(N) + y·N        with P(N) rising in N (thin floor)

Stock equation, template mode (contract relists each seat at 1.2x and burns IMDSTR with the proceeds): the seat is inventory, not a holding, and N is the number currently unsold.

Fixed points

1. N = 0, V = 0 (dead token). Strategy tokens live on volume. Launch-decay fee curves (95% falling to 10%) front-load volume, and volume decays afterwards. If V → 0 before the treasury clears the floor, the contract sits with dust. This is the attractor for most strategy tokens and, with 38 holders and 0.6 ETH in the treasury today, the most likely one here.

2. Inventory equilibrium (template mode). If sellTargetNFT is used as designed, N oscillates around the number of seats listed at 1.2x that have not yet sold. Steady-state holdings are one to a handful of seats, so the share of the swarm is well under 1% and never compounds. The earnings channel is irrelevant because seats are flipped before they earn much.

3. Liquid-supply saturation (hold mode). If the operator never sells, N is monotone and stops only when P(N) has risen enough that φ·V/P is negligible. The binding cap is not 2,000 but the liquid subset: the tranche of holders willing to sell near floor. With 782 holders and 24-hour volume of about 95 ETH, roughly 15 to 20 seats change hands per day at the current floor. A price-insensitive buyer with a public buyIncrement schedule is the easiest counterparty to front-run, so P(N) is convex. Rough volume required with a flat floor of about 2 ETH and 8% capture:

Target seats	Share of 2,000	Treasury needed	IMDSTR volume needed
20	1%	40 ETH	500 ETH
100	5%	200 ETH	2,500 ETH
400	20%	800 ETH	10,000 ETH

Those numbers are lower bounds because the floor rises under the contract's own demand. For scale, all TokenWorks strategies together have accumulated about 7,860 ETH of buyback fees, and the largest single strategy bought 1,271 NFTs of a much cheaper collection (Dune). A 5% stake is reachable for a hot token. A 20% stake would require IMDSTR to be one of the largest strategy tokens ever while buying into a collection whose floor is over 5,000 USD.

4. Self-funding (earnings channel dominates). The loop is only "the swarm owning itself" if seat income, not trader fees, buys the seats. That requires y·N ≥ φ·V/P, i.e. seat yield high enough that doubling time (ln 2 / y) is short. Paid requests cost "0.5 IMD each" (imd.fun/docs), and payouts are per seat per daemon-run. At a 5,000 USD seat price, even a generous 10% annual yield gives a 7-year doubling time. This fixed point exists mathematically but is unreachable on any horizon that matters. The honest description is: traders fund the seats, the swarm's payouts are a rounding error on top.

What breaks the loop

• Signature path. The IMD API authenticates wallet actions with an "EIP-712 signature from the wallet that holds the seat" (imd.fun/docs). A contract cannot produce an ECDSA signature. The strategy's workerAuthorizationDigest is the workaround, but it only works if the IMD control plane accepts contract-held seats via that digest or ERC-1271. If it does not, every seat the contract buys is idle, earns nothing, and hurts nothing. That is a single protocol-side switch that reduces the loop to a plain NFT treasury.
• Operator, not swarm, controls the seats. authorizeWorker hands a device key to whoever the operator (creator 0x35dA…a059) chooses. The swarm does not "own itself"; one operator runs N seats with token holders as passive financiers. Standing is per seat and "Bad reviews do" hurt it (imd-node-guide), so a poorly run fleet loses dispatch eligibility and the earnings channel dies first.
• Sell side versus hold side conflict. Token holders need NFT resales to fund buybacks ("All ETH from NFT resells go into buying and burning that particular strategy token" per Bankless). Holding seats to run them starves the burn, the token price sags, volume sags, and the fee channel weakens. Hold mode and template mode are mutually exclusive, and the operator must pick one.
• Reflexivity on a thin floor. Sellers see a public floor buyer with a rising buyIncrement and list into it. Each purchase raises the next price, so seats per ETH fall as N grows.
• Upgrade and compiler risk. The proxy points at a single implementation with no audit submitted, compiled with a version Etherscan flags for known bugs. Whoever controls the implementation controls both the treasury and the fleet.
• IMD-side monetary policy. IMD's own pool burns most excess: "sells push IMD into the protocol-owned Uniswap v4 pool" and a hook burns 85% above the cap (awesome-imd). Seat payouts denominated in IMD are therefore not a reliable ETH income to reinvest.

The threshold

The denominator that matters is not 2,000. Dispatch runs against online, eligible seats, and the public API lists "one entry per paired device" (swarm-watch). If a few hundred seats are online at a time, 100 contract-owned seats is 5% of the collection but plausibly 25 to 35% of the active pool.

Two behaviors change at specific concentrations of the active pool, call that share s:

• Review independence. Adversarial review is "Review, read-only, by a different seat" (imd.fun/docs), and in structured jobs "Seats cannot see each other while they work" (launch-131-fren-review). Both assume different seats have different operators. The chance that implementer and reviewer share one operator is about s, so at s ≈ 1/3 one in three reviews is self-review.
• Oracle quorum. Panels are "2–10 on the paid route" with quorum "Matching answers needed, 2 to panelSize" (imd.fun/docs). For a panel of 3 with quorum 2, one operator forces an answer with probability about 3s²(1−s)+s³. At s = 0.1 that is under 3%. At s = 1/3 it is about 26%, and blocking a unanimous panel needs only one seat, which happens with probability 1−(1−s)³ ≈ 70%. That is where oracle outputs stop being independent evidence.

Translating back to the collection: the swarm's behavior changes materially at roughly 100 seats, or 5% of the 2,000, because that is the point where one operator plausibly holds a third of the online pool and becomes the largest single dispatch participant. Anything under about 20 seats (1%) is noise. Reaching 100 seats needs on the order of 2,500 ETH of IMDSTR volume with a flat floor, more in practice, and it only matters at all if IMD's control plane honors contract-held seats through the worker digest. Today the contract holds 1 of 2,000, or 0.05%.