FAQ: Miner & Validator Economics

Walk me through the miner economics for one H100, including the cost basis, the time to breakeven and the unpaid testnet period.

Miners take 75% of the block reward — more than half of every block — because they do the most work.
The unit sits in the provider's data centre and you get root access to install the FLOP software. On the cost line, read quotes carefully: the $1,800 reference is a bare GPU-hour rate annualised over 730 hours and does not include hosting, power, bandwidth or operator time. Some providers bundle those and some bill them separately, so compare on a fully-loaded basis.
H100 rent: about $1,800 a month for a PCIe unit at current spot — an average of publicly quoted rates, not a negotiated or contracted price — up to $2,500–3,000 depending on platform, variant and term, with no long-term commitment. Term quotes for H100 SXM clusters seen in October 2026 have run about $2.85–3.90 per GPU-hour ($2,100–2,850 a month), so a reserved multi-month node costs more than the reference figure. Purchase price about $25–30k; one October quote for an H100 with co-hosting was about $41,600 per unit. The projection model uses $1,800 a month.
On the rental assumption: short-term, no-commitment capacity is scarce. Providers are quoting twelve- to thirty-six-month terms with deposits of roughly 25–30%, and hyperscaler capacity comes as spot, a three-month renewable term, or three years with little in between. Budget on the term you can actually secure rather than on a spot rate, and treat the ability to walk away after one month as something to verify with your provider rather than assume.
Model assumptions: 60% utilisation; open-weight workload; 85/15 inference split; $100M starting market cap rising to $600M by end of year one; network supply about 1,000 H100-equivalents at end of testnet and about 1,200 at mainnet start.
Inference revenue: about $1,000 a month — roughly half of rent at today's open-weight pricing. Block reward: about $15,000 a month in month one, easing to about $11,000 by month four as network supply grows, which is where the return comes from — so total revenue runs at roughly 8–10x rental cost at the start and about 6–7x by month four. Stress case at a $50M market cap still returns about 5x rental cost.
How that block-reward figure is built, because it is the number the whole return rests on: miners take 72 of the 96 $FLOP issued each second, which is 189,216,000 $FLOP a month to the entire miner cohort. Your share is that pool divided by total network capacity. At about 1,200 H100-equivalents and a $100M market cap it is roughly 157,700 $FLOP a month per unit. It scales down as the network grows — double the capacity and it halves — which is the honest decay path rather than a fixed figure.
Both streams are paid in $FLOP; inference income is USD-anchored through market pricing.
Testnet months are not unpaid in expectation: they accrue the miner airdrop, calibrated to what the same capacity would have earned on mainnet. Unlock is 25% at TGE plus one token per token earned on mainnet — roughly four months to full.
Cash curve for one rented H100: about three months of rent (about $5,400–7,500) at risk during testnet, recovered in the first weeks of mainnet as the airdrop unlocks alongside live block rewards. Cumulative breakeven including testnet rent: early in mainnet month one in the base case; around month two if market cap comes in at half.
The full assumption-level model and a miner economics calculator are available to applicants so the assumptions can be stressed directly.

Is inference revenue really a stable, fiat-indexed hedge for miners? Why are rewards modelled in fixed dollars rather than a fixed quantity of $FLOP, and what if the $FLOP price collapses or liquidity is thin?

Rewards are modelled in dollars because compute is priced in dollars everywhere else, and the buyer is an agent that compares prices continuously. FLOP has to sit at or below the going rate in dollar terms at the moment of the request. If the reward were a fixed quantity of $FLOP, the dollar price of an inference would swing with the token and that comparison would break every time the token moved.
So the model expresses miner revenue in dollars and lets the $FLOP quantity float. The emission is a subsidy rather than the product: the dollar price is anchored externally, and the block reward is what makes that anchored price attractive to supply.
The hedge that falls out of this is real, but state it precisely. If $FLOP falls 10% while market compute prices are unchanged, FLOP compute becomes 10% cheaper in dollar terms, demand routes in, and agents pay proportionally more $FLOP — so inference income is roughly USD-stable with respect to $FLOP price moves.
First limit: this hedges $FLOP price risk, not compute price risk. The open-weight price war has cut dollar inference revenue to roughly half of rental cost in the current model. Inference income today is partial cost recovery, not full downside protection.
Second limit: realised economics depend on $FLOP liquidity. Miners sell through native HTLC atomic swaps against USDT and BTC at launch and DEX listings after; until real depth exists, the liquidity concern is legitimate.
Block reward remains the overwhelming majority of early revenue and is fully exposed to the $FLOP price — that is the upside leg, not the hedge.

If returns are 8–9x, miner influx will compress them. What is the honest decay path, and is there a scenario where we contribute 50 H100s and earn nothing?

Correct, and the model already assumes it. Compute supply grows over mainnet year one, so any single unit's share of a fixed emission falls continuously. Rewards are earned period by period, so what a fleet earns while supply is thin is not diluted afterwards by capacity that arrives later — the advantage is in joining early.
The block-reward multiple compresses from roughly 8–10x inference income at launch to roughly 3x by year two, and further after the first halving.
The relationship is two-sided: if supply floods in far beyond the model, that implies real traction, in which case the market-cap assumption is also too low. Returns are a function of both variables.
The downside: the ~10x story is a month-one-to-four story. From month five the airdrop unlock is finished and net per unit falls materially, decaying further through the halving.
Earning nothing is theoretically possible: if your capacity is never matched, or you price above market, you earn nothing. Rewards track compute actually delivered, not capacity offered, so idle capacity earns nothing by design.
In practice selection is the buyer’s and region-aware, miners set their own price, and rate decay clears unmatched supply: if demand does not clear, prices fall until it does or providers exit.
There is no testnet cap, and no published onboarding threshold either — what self-selects is the measured performance score that decides ranking (uptime, block production, accuracy, latency and geographic spread for validators, with no published weighting; delivered compute for miners), not a pass mark at the door. Take the raw model and stress it yourself.

Are H100s required? Can consumer cards like a 4090 or 5090 mine, do they dilute H100 rewards, do they support TEE, and how are rewards scaled across hardware?

H100s are not required. The minimum miner spec is any GPU with at least 16GB of VRAM. The H100 80GB PCIe is the reference unit the model normalises to, not a floor. There is no whitelist of approved models: any card meeting the 16GB floor is calibrated and credited on the compute it delivers, with the normalisation factors below as the published reference; for an enterprise purchase, H100 or newer is the recommendation.
One distinction: 16GB is the participation floor, not the specification behind the headline economics. Those are built on a reference model of about 117B parameters at 4-bit quantisation — roughly 61GB of weights before any key-value cache — which needs an 80GB-class card. A 16GB card participates by serving smaller models and earns on the compute it actually delivers; its economics are not a scaled-down copy of the H100 case, and per-card throughput figures below the 80GB class are used for capacity normalisation rather than published throughput.
There is no minimum cluster size or GPU count — a single card at or above the 16GB floor is a valid miner, and demand already ranges from one consumer card serving a ~20B-parameter model to 8–16× B200 clusters serving 1–2 trillion-parameter models. For an institution deciding what to buy, NVIDIA enterprise parts — H100, B200 or RTX PRO 6000 Blackwell — earn the most per unit. Alongside the hardware, each miner posts a stake of 10,000 $FLOP plus a capacity-scaled component that is still being finalised.
A cloud instance with a single 16–24GB card — an NVIDIA L4, for example — is enough to prove the setup end to end on devnet: it serves models in the roughly 20-billion-parameter class and earns in proportion to the compute it delivers, so it is a way to validate the configuration rather than the economics. Which models the smallest configurations serve well is still being tested.
Consumer hardware does not dilute enterprise hardware: rewards are proportional to actual GFLOPS capacity delivered as a share of the network — not hardware cost and not token output. GFLOPS is also the right cross-model unit, because a million tokens from a 20B model and from a 1T model consume vastly different compute.
Rough throughput relative to an H100 PCIe: an H100 SXM or H200 about 1.5, an RTX 5090 about 0.46, an RTX 4090 about 0.36, an RTX 5080 about 0.25, a Mac Studio M3 Ultra about 0.09, a B200 about 3.5 and a B300 about 5.4. Older datacentre cards also qualify and are credited the same way — an A100 80GB about 0.48 and a V100 32GB about 0.19 — so they work, just less efficiently per card than Hopper or Blackwell parts. A card earns in proportion, and costs far less than proportionally.
Recommended build for one or two RTX 5090s (guidance, not a protocol requirement — setup guides are being published): Linux first (Ubuntu 24.04, NVIDIA driver 570 or later), Windows to follow; a 16-core CPU for two cards (about 8–11 cores per card, so an 8-core machine serves a single card); 64GB of system RAM for one card, 128GB for two; a 2TB NVMe drive; a 1200W ATX 3.1 power supply for one card, 1600W for two; at least 500 Mb/s down and 250 Mb/s up with under 100 ms latency; no ECC memory and no TEE needed. Two 5090s give 64GB of VRAM, enough for mid-sized open-weight models in the 20–30B class, and earn roughly twice one card.
This is not a big data-centre game. Some institutions are coming with dozens of units, but the network is not targeting hyperscalers with hundreds or thousands; it is designed so that anyone with a capable GPU can participate and earn.
Consumer GPUs do not support TEE, and TEE is optional by design — an optional higher-assurance tier rather than a requirement, with a verification floor that does not depend on it. The end-to-end settlement lane for non-TEE work is designed and not yet fully wired, so consumer-GPU mining is supported in specification while that path is still being completed. An activation commitment is required on every job regardless of tier.
Validators are a different case entirely: they need no GPU and no TEE device at all, and never execute inference. Their constraint is disk, to hold the top 20–30 open-weight models.
GPU-driven boxes such as DGX Spark suit mining rather than validating.
AMD, Huawei and Intel accelerators carry normalisation factors in the hardware table and are credited on delivered compute like any other card — AMD Instinct MI300X, MI355X and the 16GB-plus Radeon consumer parts among them, alongside NVIDIA Blackwell parts including the B200 (3.470), the B300 (5.398) and the RTX PRO 6000 Blackwell 96GB (0.661). The rule is the 16GB VRAM floor and the GFLOPS the card actually delivers, not the brand. Whether the miner software supports AMD accelerators from the day testnet opens, or from a later release, is still being confirmed.
Normalisation factors exist for 50 device classes and are being published with the miner specification. A miner economics calculator lets applicants enter popular chips and see the economics. Whether hardware weights can change after launch is not yet finalised.

What are the validator economics and hardware requirements? Is entry permissionless, and what happens to the bond if a validator is rotated out?

Validators earn 10% of the block reward plus 15% of inference fees, paid liquid.
The bond is 1,200,000 $FLOP per validator, granted free rather than purchased, and sized so that the cost of corrupting the validator set exceeds the value of corrupting it.
Validators require no GPU and no TEE device at all. This is normative in the published specification: a validator authors blocks, runs BFT finality on the sampled committee, stores and serves data-availability shards under serve-or-slash, and attests miners’ proofs — it never executes inference, and committee eligibility must not require holding a GPU or a TEE. Liveness rests on verification duties rather than on mining. The runtime enforcement of that liveness gate is still being wired, so it is accurate to describe the requirement as ratified and published, and the enforcement as in progress.
Remaining hardware follows the reference profile in the published specification: eight physical cores at 3.4GHz or better with SMT off, 32GB ECC RAM, 4TB of enterprise NVMe covering chain state and data-availability custody, and a 1Gbps symmetric unmetered link. Storage is the one demanding line, because it holds the top 20–30 open-weight models so the validator can direct model loads. Budget 4TB; 64GB of RAM is comfortable rather than required.
Each validator unit is one validator running its own full node; a node does not host several validators. Separate physical machines are the recommendation because of the bandwidth and storage each node carries, but a dedicated, unthrottled virtual machine per validator is acceptable.
Cost: about $300 a month to rent a node with redundancy, or about $4,000–5,000 to buy outright.
Return: the bond is granted rather than bought, so there is no capital outlay to compute a yield against — the meaningful figure is return on operating cost. The 10% block-reward leg is 25,228.8 $FLOP per validator per month (9.6 $FLOP per block across the 1,000-validator set) plus roughly $200 a month from the 15% inference share in the early months, against roughly $300 a month of node rental. With no GPU capex there is nothing else in the cost base. That is 8–10x operating cost in the early months and broadly holds until the first halving; halve the market-cap assumption and it is still 4–5x.
Testnet entry is open — no whitelist and no restrictions. The first mainnet validator set is 1,000, seeded directly at genesis from the testnet cohort on the published criteria below, and each seeded validator is granted the 1,200,000 $FLOP bond free — the stake is airdropped, not delegated from a foundation. The bond is fully locked for 24 months; from the start of year three one validator is fully unlocked per day, in a random order drawn and published before the first release, until the whole set is released, about 1,000 days.
Ongoing selection is systematic, never hand-picked: rotation runs roughly every 30 days, with about 50 ejected and 50 promoted from a queue of validators in waiting, and an ejected validator waits about 7 days before rejoining. A proposal in the specification would replace the fixed bottom-50 ejection with a performance floor, ejecting only validators that fail it, up to 10% of the set per rotation; it is pending ratification. Unbonding is about 21 days. If a validator is rotated out, the incoming validator assumes its bond.
The bond belongs to the seat, not to the operator, and a seat is held only by running: a validator that stops, or that is rotated out for performance, loses the seat and the incoming validator assumes its bond — there is no keeping the bond while idle. The bond is locked for 24 months from genesis; from year three one validator per day has its bond released in full, in a random order drawn and published before the first release, so clearing the whole set takes about 1,000 days. Voluntary exit from an active seat takes about 21 days of unbonding. What a validator whose bond has been released must keep staked to go on holding the seat — and therefore to go on earning — is not yet finalised: the published specification requires every active validator to hold at least the minimum stake (1,200,000 $FLOP at genesis, rising 9% a year), which would mean a released validator keeps its seat only by keeping that balance bonded, and reconciling the release schedule with that floor is an open item. The seat earns for as long as the validator runs and stays bonded.
Selection is scored, published in advance and carries no discretion — nobody is hand-picked and nothing is negotiated. The criteria are uptime, block production, accuracy, latency and geographic spread, measured across the whole testnet; no weighting between them is published. Where operators finish effectively level, the tie is broken on geographic distribution and network diversity and, within a group that is effectively indistinguishable, by random draw, applied again at each rotation rather than only at cutover. The cutover rubric is being finalised for publication before testnet ends; it will be published in advance rather than applied privately, so that anyone spending money to compete can see the standard before they commit.
Of the 1,000 registered validators, 100 are active in consensus at any time, on a rotating committee sampled by stake.
We are looking for institutional operators spread across regions (North America, APAC, Europe); the aim is a decentralised set, so a single operator coming in for several hundred or a thousand units is not what we are after. An operator may run several validators, and each validator that makes the set holds its own seat and its own 1,200,000 $FLOP bond — there is no pooling of several validators into one seat. On unit counts, the published specification currently says this: it carries a limit of five validator slots per operating entity, self-declared and not yet enforced in the runtime, and a proposed cap of 10% of the set — by validator count and by stake — for any one hosting provider, metro or operating group. The working commercial guidance of roughly 10–100 units per institutional operator is under review against that limit and has not been reconciled with it; an operator planning more than five units should discuss it with us before committing hardware.
Risk profile: lower absolute upside than mining, but commodity hardware and stable costs, so arguably a better risk-adjusted return. For firms already running validators on other chains it is the natural on-ramp.
Detailed validator documentation — per-operator caps and setup — is being published ahead of testnet. Institutional partners do not need the public application form.

How flexible is mining — do I need fixed contracts or a 24/7 commitment?

Completely flexible, and this is one of the sharper structural differences from the rental marketplaces.
FLOP pays per inference or inference session, so you run the miner daemon when you have spare capacity and stop whenever you like.
No lease, no take-or-pay, no minimum term — unlike Akash or Aethir, where hardware is let by the hour, day or week.
For a data centre with a partially contracted fleet, FLOP monetises idle hours you currently write off. For someone renting, the worst case is a single month's rent if the economics disappoint.
The trade-off for a provider used to fixed contracts: FLOP cannot guarantee forward cash flow the way a two-year take-or-pay does. What it offers instead is materially higher expected yield during the emission-heavy first two years, with no lock-in on either side.
There is no uptime requirement and no minimum availability: a miner that is offline, or does not pick up a job, simply earns nothing for that period — being offline is never penalised, and the only cost of downtime is the revenue forgone.
The only penalty risk is operational, not availability-based: a miner that accepts work and then fails to deliver it as agreed is paid only for the turns both sides signed, rebates co-signed latency breaches, and faces proportionate penalties if it does so repeatedly; stake is slashed only for fraud — a substituted model, a forged proof, a faked timing or withholding evidence in a live dispute. A miner that is simply switched off is never slashed.

Which GPU configurations have you actually tested? What are the observed performance, latency and uptime numbers, what weight does each GPU get — and can those weights change after launch? Which cloud providers are tested and approved?

There is no concrete test data to share yet.
What can be stated: the floor is 16GB of VRAM, and weights are normalised compute capacity rather than hardware cost, so reward tracks measured compute contribution. Consumer cards sit well below datacentre parts: an RTX 5090 is about 0.46 of an H100 PCIe, an RTX 4090 about 0.36 and an RTX 5080 about 0.25.
Benchmarks — throughput, latency and uptime by configuration — will be shared when they exist and will be part of the miner and validator documentation.
Whether hardware weights can be changed after launch is not yet finalised.
A list of tested rental providers with live availability, and a rental-tracking site, are being prepared.
Hardware beyond the H100 is already accommodated. Each part is credited as an H100-PCIe-equivalent on sustained dense FP16 throughput: an H100 SXM or H200 about 1.5, an RTX PRO 6000 Blackwell about 0.66, a B200 about 3.5, a B300 about 5.4, a single Rubin GPU about 6.2, and a full Vera Rubin NVL72 rack (72 GPUs) about 444. Credit tracks delivered capacity rather than a card's name, list price or rental cost, and the table is extended as new parts are characterised.

What hardware is needed beyond H100s — how is storage sized, are jobs pinned to one validator or do they need multi-host access, and is a cluster wanted or a single GPU?

Miners: any GPU with at least 16GB of VRAM. A miner runs a single model at a time, so a single standalone GPU participates; a cluster (8–16 units) is what lets you serve larger models. About 20% of forecast supply is expected to sit in clusters.
Where you have the choice, clusters are the recommendation, because they buy flexibility rather than a higher rate. Eight 80GB cards can be addressed as one unit to run a large model when the network wants one, or run a smaller model at roughly eight times the throughput when it does not. The trade is close to linear either way, and credit follows verified floating-point operations delivered in both cases.
Hardware does not need to sit in one location, and distribution is preferred. Buyers select miners on region as well as on price, and demand is expected to be heaviest in North America and Asia-Pacific, so capacity in both is worth having.
Validators: commodity server hardware — eight or more physical cores, 32GB ECC RAM (64GB is comfortable rather than required), a 1Gbps symmetric unmetered connection — plus enough NVMe storage for the top 20–30 open-weight models. Budget 4TB; 2TB is the absolute floor and is not recommended.
Networking: a miner has to be reachable by agents, so each miner — or a group of miners behind one endpoint — needs a public IP address; running a miner purely behind NAT is not supported today. A tunnelling option that would let miners sit behind someone else's public endpoint is under consideration and not yet available. How a load balancer can front a cluster, and the protocol layer the agent-to-miner connection runs on, are covered in the miner manual.
Storage sizing rationale, job pinning versus multi-host access, and the CPU clock requirement relative to block time will be specified in the miner and validator manual.

What happens when a large provider pulls capacity mid-flight for a long-term contract elsewhere? How do you think about network stability if you are effectively selling spot instances?

Selection is the buyer’s and region-aware, and miners carry no take-or-pay commitment — the same flexibility that lets a provider monetise idle hours also means capacity can leave.
FLOP deliberately targets small-to-medium data centres and corporates with dozens to about a hundred units, rather than hyperscalers that need three-to-five-year fixed contracts FLOP cannot underwrite, because everything is paid per block.
There is no uptime requirement for miners, so interruptible capacity — including cloud spot instances with roughly two minutes' notice — is workable on the miner side.
Validators are selected and retained on uptime, latency and accuracy, so the coordination layer is held to a higher standard than the compute layer.
A miner is never slashed for being offline. Committed work that is not delivered is paid only for what was completed and acknowledged, with rebates on co-signed latency breaches and proportionate penalties for a miner that repeatedly fails to deliver what it committed to; stake is slashed only for fraud.

Can we transfer our unused cloud credits to you, or otherwise put them to work on FLOP?

Cloud credits themselves generally cannot be transferred between organisations.
The working structure is for the counterparty to run miners inside its own cloud account — for example on prepaid reserved instances — and either use them directly or have FLOP help administer the setup. Pre-committed spend that would otherwise lapse can be pointed at mining.
Indicative cloud pricing for an 8xH100 instance (p5.48xlarge class): spot around $15,000 a month, interruptible; three-year reserved around $17,000; on-demand around $40,000. Per H100 that is roughly $1,875 spot, $2,125 reserved and $5,000 on-demand, against the model's $1,800 assumption.
Check the discounted cloud rate against the open rental market before committing: if it is well above market, the credit is worth less than its face value as mining capacity.

Do you acquire the compute yourselves to seed the network and keep the $FLOP, or would we participate in exchange for $FLOP as any other market participant would?

Counterparties participate as ordinary miners and validators and keep what they earn. An operator with its own GPUs — owned or colocated — registers them as miners, stakes, serves inference and is paid block rewards and inference fees directly by the protocol; FLOP does not buy access to the machines, resell it or sit between the operator and demand. There is no allocation and no side deal.
FLOP Labs will not run validators on the network. Whether FLOP Labs or Maelstrom will operate miners of their own is not finalised; if they do, they take part as ordinary participants under the same published rules — no allocation, no side deal — and it will be disclosed. FLOP Labs' role is developer of the open-source software: it does not provide compute, run the validators that set the network's rules, see the data passing between agents and miners, or conduct inference.
Where a specific capacity partnership is discussed — for example FLOP buying rented capacity from a provider for an upfront fixed fee — that is negotiated case by case and any conflicted party recuses from the decision.
FLOP does not build, buy or lease data-centre capacity of its own and does not act as a renting intermediary. Supply comes from independent miners; where a miner is short of hardware, we refer it to providers already in the network.

Does FLOP support a mining pool concept — can an operator aggregate participants into a pool, or run nodes on their behalf?

There is no mining-pool concept in the protocol. Miners rent and run individual units or clusters and are rewarded on the verified inference they actually serve.
A single GPU with at least 16GB of VRAM participates on its own. A cluster is only needed to serve larger models — 8×H100 gives 640GB of VRAM, enough for semi-frontier models — and about 20% of forecast supply is expected to sit in clusters.
There is no cap on the number of miners and no whitelisting, so aggregating hardware under one operator carries no protocol advantage: rewards follow delivered compute either way.
A third-party operator may run miners or validators on behalf of an investor that has capital but no operations team. The network sees only the registered identity and the compute or validation it actually delivers, so who owns the hardware and who operates it is a private arrangement between the two of you. FLOP does not run a managed-mining or staking-as-a-service programme itself; where an investor asks, we can introduce operators that have told us they offer it, and the terms are between you and them.
Validators work the same way. The top 1,000 are selected on testnet uptime, block production, accuracy, latency and geographic spread, and each is granted the 1,200,000 $FLOP bond free. Selection happens on-chain and in public, so no pool or intermediary is needed to take part.

If we run validators through the whole testnet but do not finish in the top 1,000, do we get any airdrop at all?

No. The 1,200,000,000 $FLOP validator pool is the aggregate of the 1,000 individual bonds, and each bond goes to a validator that is actually selected. A validator outside the top 1,000 at cutover receives nothing from that pool.
Selection is on measured testnet performance — uptime, blocks produced, latency and accuracy. There is no whitelist and no cap on how many validators may compete.
There is no separate consolation allocation for unselected validators and no commitment to create one.
Two things reduce the risk of running and getting nothing. Performance is scored per validator, so every unit an operator runs that performs can be selected — subject to the published specification's per-entity limit of five validator slots and its proposed 10% per-provider cap, both of which are still being reconciled with the institutional unit guidance. And the set rotates roughly every 30 days once live, with validators promoted from a waiting queue, so a near miss at cutover is an entry point rather than a closed door.
The same operator can also mine. Mining is scored separately on delivered compute, has no set size and no cap, and carries a separate 1,200,000,000 $FLOP pool.
The validator grant, its lock until the first halving and the one-per-day release are in the published specification; the order of release is still an open item, and no grant is released until it is fixed. The set size — 1,000 — is not what is open.

Are your H100 benchmarks and “H100-equivalent” figures based on PCIe or SXM cards? Cloud providers sell the SXM class, so the multiplier may not be the same.

The reference unit is the H100 80GB PCIe, normalised to 1.000. Every “H100-equivalent” figure FLOP publishes or quotes is denominated in that unit.
The H100 80GB SXM normalises to 1.525 — about 52.5% more delivered capacity than the PCIe part. GH200 and the H200 141GB sit at the same 1.525.
That matters when comparing against a cloud quote, because the major providers sell the SXM class. A given count of SXM cards is worth roughly half as many again in H100-PCIe-equivalent terms, so the two numbers are not interchangeable and the basis should be stated every time.
Worked example on a 240-GPU Blackwell fleet of 80 B200 and 160 B300: B200 normalises to 3.470 and B300 to 5.398, so the blend is 4.755 and the fleet is about 1,141 H100-equivalents.
Rewards are paid on delivered GFLOPS capacity as a share of the network, so the normalisation factor is what determines the share — not the card’s name, its list price or its rental cost.
Normalisation factors exist for 50 device classes and are available on request; the full table is being published with the miner specification.

Is there a difficulty adjustment on block rewards, so that rewards fall as more compute joins the network?

There is no difficulty adjustment in the Bitcoin sense. The block reward is fixed at 96 $FLOP per one-second block and steps down only on the halving schedule — every two years, five halvings, then a constant tail emission of 94,608,000 $FLOP a year, about 0.5% annual inflation.
What does adjust is your share of it. The miner portion of each block is divided across miners in proportion to the inference actually delivered and verified in that period, measured in normalised GFLOPS — not by installed capacity, not by hardware cost and not by token output.
So the economic effect of a difficulty adjustment is present without the mechanism: as more compute joins, the same 96 $FLOP is divided more ways and per-unit rewards fall. That is precisely why early participants earn more per unit.
An idle machine earns nothing. Registering capacity does not entitle a miner to a share; only delivered, verified inference does, and capacity that is never matched to demand earns nothing at all.
The in-block split itself is fixed and does not vary with participation: miners 75%, validators 10%, agents and brokers 10%, stakers 5%. Inference fees are separate and split 85% miner / 15% validator.

How is delivered compute credited — verified FLOPs actually delivered, a benchmark taken at registration, or simply GPU count?

Credit is based on inference actually delivered and verified, expressed as normalised floating-point operations per second (GFLOPS). It is not GPU count, and it is not a one-off benchmark taken at registration.
A calibration at registration is used only to establish a registered miner’s peak capacity so heterogeneous hardware can be compared on one scale (it is also what the capacity-scaled part of the stake is sized on). It sets the rate at which delivered work converts into share; it does not by itself earn anything.
Every device class carries a normalisation factor against the H100 80GB PCIe at 1.000 — for example B200 at 3.470, B300 at 5.398, and H100 80GB SXM, H200 141GB and GH200 all at 1.525. Factors exist for 50 device classes and are published with the miner specification.
Reward for a period is your share of verified delivered work across the network for that period. Placement and price matter, because capacity that is never matched with demand delivers nothing to be credited for.
Verification is randomised sampling backed by stake: an activation commitment on every job, and full re-execution of a sampled share of turns — the published non-TEE spot-check rate is 2.5%, one in forty — by independent bonded checker miners, so the quantity being credited is checked rather than self-reported. A trusted execution environment is an optional higher-assurance tier, not a requirement.
Block rewards do not vary by GPU model as such: they follow the compute actually delivered, so a lower-end card serving the same work delivers a fraction of the GFLOPs of a higher-end card and earns that fraction. Which card is chosen for a given job is the buyer’s decision, so hardware that fits the models agents actually want to run is selected more often.

We would rather deploy RTX PRO 6000 Server (Blackwell) nodes than H200s. How is that part credited, and is the verification stack tested on it on a standard host?

One institutional participant has ordered 160 of these cards, roughly USD 2.5–3m at market prices, buying rather than renting on an explicitly long-term view of the network. At the 0.66 normalisation that is about 106 H100-equivalents, so one counterparty is roughly a tenth of the 1,000 H100-equivalents expected across the whole network at the end of testnet.
The RTX PRO 6000 Server (Blackwell) normalises to 0.66 against the H100 80GB PCIe at 1.000, so about two thirds of a baseline H100 on sustained delivered capacity. Treat it as provisional: it is derived from the vendor’s published figures rather than measured on our own stack.
Its 96GB clears the memory threshold needed to host the reference model, which makes it the first GDDR part in the table to carry real prefill and decode ceilings rather than being held for capacity normalisation only.
For sizing against other parts, the H200 141GB and the H100 80GB SXM both sit at 1.525, so it takes roughly 2.3 of these cards to match one of those on credited capacity. A B200 normalises to about 3.5 per GPU against the same H100 PCIe baseline, and a B300 to about 5.4.
Whether it is the better buy is a procurement question rather than a protocol one. Near its list price the delivered throughput per dollar is ahead of an H200; at the elevated street prices seen during the GDDR7 shortage it is behind.
The card carries Blackwell Confidential Computing, so the optional higher-assurance tier is available on it in principle. What has not happened is validation of proof generation and the trusted-execution path on that part on a standard host, and that is stated rather than implied either way.
Rewards are paid on delivered capacity as a share of the network, so the normalisation factor determines the share — not the card’s name, its list price or its rental cost.

Is a miner identity per node or per GPU? How does stake scale across a fleet, and can a third-party operator run it on our behalf?

A miner identity is a registered wallet: one wallet, one calibrated capacity, one stake, one slashing and blacklisting scope. How much hardware sits behind one identity is the operator’s choice at registration: an eight-GPU server, or a whole NVL72 rack serving a very large model, can be registered as a single miner, or each GPU can be registered as its own miner. Each registered miner is a separate unit to the network, and ten servers registered separately are ten miners, each with its own stake. Splitting is usually the right operating choice, for fault isolation and for regional placement against demand; registering a cluster as one miner is what lets it serve a model too large for one card.
Stake scales with registered capacity: a flat base self-stake of 10,000 $FLOP per registered miner, plus a component that scales with the miner’s calibrated peak capacity in GFLOP/s. The base figure is settled; the capacity-scaled component is still being finalised, so there is no firm total for a given card yet and any number quoted for one today would be provisional.
Stake is collateral at risk rather than a cost, and it is returned on unbonding absent a fault.
Miner unbonding is about 7 days, and is frozen while any session or dispute involving that miner is open.
Third-party operators are supported. Nothing requires the registering party to own or physically operate the hardware, which is how most institutional participants intend to come in — taking rented capacity and having an operator run it.
A 1,000-GPU fleet can be operated and paid out from one key. Registered as one miner it is calibrated as one fleet and posts one stake for the whole fleet; registered as many miners, the operator generates the miner wallets from a single seed, each with its own stake and exposure, and all of them pay out to one address. A separate payout address for rewards and the airdrop, distinct from the operating key, is being added so the receiving wallet can sit in a multisig. Monitoring across many miners is done by the operator’s own tooling. Institutional partners validate their fleet setup on the devnet before testnet opens.

When should we start renting GPUs relative to your schedule, and who should we be renting from? Six-month leases need a deposit and lead time, so we do not want to pay for idle machines.

Do not contract at scale early. One unit is enough to validate the setup end to end on the private devnet, which is admitting its first external miners and validators now and runs through October ahead of testnet; bring roughly ten toward the end of devnet to prove the configuration holds at scale, then commit the bulk of the fleet for the testnet target of 3 November. Hardware landing in late October still leaves time on devnet. Setup is documented for agent-assisted configuration and should take about an hour per machine.
The market is the binding constraint rather than the schedule. Short-term and spot rental is scarce right now: twelve-month minimums are common, six-month terms are available from some providers, and hyperscaler capacity is offered as spot, a three-month renewable term, or a three-year commitment with little in between. The three-month option prices at roughly 30% above spot or three-year rates.
Expect rental pricing to firm up as testnet approaches. A large share of applicants intend to rent rather than to use hardware they already own, so demand for rentable capacity will concentrate into the same few weeks. Securing a medium-term source ahead of that is the way to avoid the squeeze, and it also removes the price risk from a spot exposure.
Before comparing any two offers, confirm whether a quoted hourly rate is per node or per GPU. On a multi-GPU node those differ by roughly the GPU count, which is large enough to invert the ranking of two otherwise similar quotes.
Blackwell-class capacity from the large decentralised providers is quoting 36-month terms with 25–30% prepayments and go-live dates in late November and December, so it is a mainnet supply route rather than a testnet one. If you need machines live for a testnet targeted for 3 November, the realistic sources are hyperscaler three-month renewable terms and providers who already hold idle inventory.
Compare offers per H100-equivalent rather than per node or per card. Normalised that way, a B300 node at $4.70 an hour is about $0.87 per H100-equivalent-hour, roughly $640 a month, while an RTX PRO 6000 node at $1.50 an hour is about $2.27 — the shorter twelve-month term costs about 2.6x the compute price, which is a trade to price deliberately.
Where a B200 or B300 provider will only lease on a three-year term, buying is usually cheaper than the lease over that term, so compare the lease against a purchase rather than against spot. RTX PRO 6000 Blackwell is markedly easier to source at short notice than H100, B200 or B300 and is a sound mining part (about 0.66 of an H100 PCIe per card); H100 SXM and H200 capacity on reserved multi-month terms is currently quoting around $2.85–3.90 per GPU-hour.
FLOP holds no inventory, does not resell compute and takes no margin on rentals. gpus.flop.finance aggregates what the major neoclouds publish, a vendor list with live availability is being published, and where a provider is already in the network we will make the introduction.
For a long-term miner, owning beats renting. Enterprise-grade rental supply is short and most terms are spot or three-month, so a renter carries both availability risk and price risk; an owner-operator carries neither. Expect a split on the network: consumer cards are almost all owner-operated; on the enterprise side some miners own units or reach them through portfolio companies, and a sizeable share needs to rent. Second-hand enterprise cards are fine — credit is on delivered compute, not on the age or purchase channel of the card. Where capacity is short, FLOP can refer miners to data-centre and GPU providers already in the network, and gpus.flop.finance tracks live availability across the major neoclouds.
Location matters commercially, not by rule. The protocol neither restricts nor routes on geography: the buyer — an agent or the broker acting for it — selects the miner, and it selects on price, latency, model and region, so capacity close to where demand runs is matched more often and capacity far from it competes on price for latency-tolerant work. An agent specifies the model and the latency it needs per request, and the range is wide — from batch work that can take minutes to answers needed in a second — so the network wants both kinds of supply: low-latency capacity near the agents, which today means mostly North America and Asia-Pacific with Western Europe next, and cheap-power capacity for batch work. Credit is still earned only on compute actually delivered, wherever the card sits; market pricing by latency class, not a central plan, sorts miners between the two, and the geographic mix will keep changing through testnet and mainnet.

We have run validators for new chains before — as a top-ten Monad validator we earned about $5,000 a month, which did not make economic sense, and Citrea was similar. Why would FLOP be different? The devil is in the detail of the economics.

The difference is what the reward is paid for. On most new Layer 1s a validator is paid a share of inflation for producing blocks whether or not anyone is using the chain, so the return is set by the token price and the size of the validator set and nothing else. On FLOP a validator is paid 10% of the block reward plus 15% of every inference fee, and the fee leg only exists because an agent paid for work that was actually delivered.
The block-reward leg is fixed and knowable: 9.6 $FLOP per one-second block to the validator cohort, which is 25,228.8 $FLOP per validator per month across a set capped at 1,000. The bond is granted rather than bought, so there is no capital outlay to compute a yield against — the meaningful measure is return on operating cost, and the node is a roughly $300 a month machine with no GPU.
The fee leg is the part that did not exist on Monad, and it is also the main risk. It scales with demand rather than with the number of validators, so if inference demand does not arrive you are left with the block-reward leg alone. That is the bet, and it is why the demand side is worth diligencing at least as hard as the economics.
The set is capped at 1,000 and it rotates: roughly every 30 days the bottom 50 on uptime, block production, accuracy, latency and geographic spread are replaced by the top 50 in the queue. Returns therefore depend on staying in the set, not only on getting into it.
Two different things are locked and liquid, and both matter when you model it. Validator earnings — the 10% block-reward leg and the 15% inference-fee leg — are liquid on issue, with no lockup. The 1,200,000 $FLOP bond itself is bonded for the first 24 months from the token generation event, after which one validator's allocation is released at random each day until the whole set is out.