# FLOP — public knowledge > Curated, human-authored answers about the FLOP Network. 26 pages. devnet / next (development). > Every page here is published-tier: the same text the assistant at https://ask.flop.finance > is allowed to quote, and the same text it cites. > Machine interop: https://ask.flop.finance/mcp (JSON-RPC, no auth, rate limited). - [Proof of Useful Inference (PoUI)](https://ask.flop.finance/docs/proof-of-useful-inference): PoUI replaces arbitrary hashing with real AI inference: a miner runs an agent's session and submits activation commitments plus a co-signed transcript as the proof that validators record and challengers can audit. - [SOFT and HARD: the two miner hardware tiers](https://ask.flop.finance/docs/soft-and-hard-tiers): SOFT is the default tier and needs no attested hardware; HARD is a specified but currently undeployable confidential-computing path with a governed device ceiling. - [FLOP tokenomics in brief](https://ask.flop.finance/docs/tokenomics-basics): The block reward is 96 FLOP, halving every 730 days for five halvings to a 3 FLOP floor and then constant forever; it splits 75% to miners weighted by verified G_n, 10% to the active validator set, 10% to agents and 5% to community stakers, with the last two minted to protocol accounts and not yet distributed. - [What is FLOP?](https://ask.flop.finance/docs/what-is-flop): FLOP is the proof-of-useful-inference blockchain and native currency for the agentic economy: agents pay miners in FLOP to run inference, converting currency directly into compute. - [Integrating an agent with FLOP](https://ask.flop.finance/docs/agent-integration): How an agent posts a session request, what the five request fields are, how it bounds spending with limits, proxies and escrow, and how it challenges work that was not done as asked. - [FLOP: frequently asked questions](https://ask.flop.finance/docs/general-faq): What FLOP is, why agents need it, how the network is put together, what the block reward is, and who governs it. - [Mining on FLOP: frequently asked questions](https://ask.flop.finance/docs/miner-faq): What a miner stakes, which hardware qualifies, how the 75% miner reward pool is split by verified G_n, what audit exposure the default SOFT tier carries, and why profitability is conditional. - [Running a FLOP validator: frequently asked questions](https://ask.flop.finance/docs/validator-faq): What validators do, how the capped 1,000-validator set rotates, what the 10% reward share covers, and how FIP voting works. - [FLOP glossary](https://ask.flop.finance/docs/core-terms): Definitions of the terms the FLOP project intro uses: PoUI, G_n, SOFT and HARD tiers, TOPLOC, the data-availability layer, session request, FIP, HTLC, and the challenge game. - [Agent accounts and spend control](https://ask.flop.finance/docs/agent-accounts-and-spend-control): The account-based chain gives agents transfers, delegation, staking, vesting, collaborative escrow and a declarative spend-condition layer, so an agent can operate at scale with pre-set spend limits and bounded delegated authority. - [Cross-chain swaps with HTLCs](https://ask.flop.finance/docs/atomic-swaps): Native hashlock timelocks let an agent escrow FLOP against another chain's asset and exchange it once the counter-transfer confirms, powering agent-to-agent sub-economies. - [How FLOP is governed](https://ask.flop.finance/docs/governance): Validators govern through FLOP Improvement Proposals: most FIPs need two-thirds of the active validator set to approve, and through the first halving only the FLOP Foundation may submit one. - [How blocks are built](https://ask.flop.finance/docs/how-blocks-are-built): Validators bundle miners' proof hashes into one-second blocks up to a 2 MB block size limit, and store the model weights sessions depend on in the data-availability layer. - [How an inference session settles](https://ask.flop.finance/docs/inference-session-lifecycle): An agent posts a session request pinning model hash, latency, FLOPs, confidentiality and fee; a capable miner accepts and opens a private connection, returns the proof, and validators fold the proof hash into a block on settlement. - [Provide GPU capacity for a FLOP miner](https://ask.flop.finance/docs/run-gpu-provider): Choose a Docker GPU host, preserve model and calibration identity, and operate a devnet miner safely. - [Run a FLOP miner on a GPU host](https://ask.flop.finance/docs/run-miner): Current devnet GPU miner setup, from identity and model binding to calibration and readiness. - [Run a FLOP validator, miner, or GPU provider](https://ask.flop.finance/docs/run-operator): Choose an operator role, collect the required network inputs, and follow the current validator or GPU miner setup with explicit readiness checks and launch gaps. - [Run a FLOP validator](https://ask.flop.finance/docs/run-validator): Prepare a validator host, join the current disposable devnet, and verify BABE authoring, AlephBFT finality, and DA custody. - [Staking, delegation, and slashing](https://ask.flop.finance/docs/staking-and-slashing): Miners stake 10,000 FLOP plus a capacity exposure bond and validators stake to join the capped set; holders can delegate to either, and provable fraud slashes up to 100% of stake and blacklists the identity. - [Cheating must not pay: the challenge game](https://ask.flop.finance/docs/verification-stack): FLOP never re-runs inference to trust it: sessions leave commitments that stay challengeable for about seven days, a lottery and bonded disputes re-check slices of the work, and an upheld fraud verdict burns 100% of the miner's stake. - [The airdrop and testnet conversion](https://ask.flop.finance/docs/airdrop-and-testnet-conversion): Miner airdrop grants are 25% liquid at genesis and unlock the rest one FLOP per FLOP earned serving inference; validator grants stay locked until the first halving, then release one validator per day over 1,000 days; locked agent airdrop can be spent only on compute and its release schedule is not yet set; testnet miner conversion allocates from a 1,200,000,000 FLOP pool on verified compute rather than holdings. - [Key protocol parameters](https://ask.flop.finance/docs/protocol-parameters): The headline numbers from the FLOP project intro: block time and reward, halving schedule, reward splits, validator set size, miner stake, audit rate, slash tiers, challenge window and dispute bond. - [Operator configuration reference](https://ask.flop.finance/docs/operator-config-reference): Generated CLI, environment, and documented RPC names from reviewed public sources - [Devnet network status](https://ask.flop.finance/docs/network-devnet): devnet network readiness and admission - [Testnet network status](https://ask.flop.finance/docs/network-testnet): testnet network readiness and admission - [Mainnet network status](https://ask.flop.finance/docs/network-mainnet): mainnet network readiness and admission --- # Proof of Useful Inference (PoUI) Source: https://ask.flop.finance/docs/proof-of-useful-inference FLOP · Proof of Useful Inference (PoUI) # Proof of Useful Inference (PoUI) FLOP's work is inference, not hashing. A miner earns by executing an agent's inference session and leaving behind evidence that the work happened as specified. FLOP · Proof of Useful Inference (PoUI) › What the proof is made of ## What the proof is made of Each session leaves **activation commitments** and a **co-signed transcript**. That evidence is the proof of useful inference: validators record it, and challengers can audit it later. - The model commits tiny fingerprints of its internal state during the session — TOPLOC commitments, 258 bytes per 32 tokens. - Every turn becomes a co-signed leaf under a Merkle root, and the chain stores that root at settlement. - A hardware quote is part of the proof **only** on the optional HARD tier. FLOP · Proof of Useful Inference (PoUI) › Verification does not rest on trusted hardware ## Verification does not rest on trusted hardware Every session must carry an activation commitment that a challenger can re-check, and disputes are settled by re-execution under bond. Confidential computing is an optional upgrade, not an entry requirement — see [SOFT and HARD tiers](https://ask.flop.finance/docs/soft-and-hard-tiers). FLOP · Proof of Useful Inference (PoUI) › Why this is cheap enough to work ## Why this is cheap enough to work The network never re-runs a whole session to trust it. A sampled check is one prefill — roughly 100x cheaper than generation — or a sub-cubic arithmetic check. Checking is dramatically cheaper than producing, which is what makes an audit lottery affordable. FLOP · Proof of Useful Inference (PoUI) › What the proof does and does not establish ## What the proof does and does not establish PoUI establishes that the registered work was performed as specified. It does not establish that a model's answer is correct, safe, or high quality. FLOP · Proof of Useful Inference (PoUI) › Status ## Status Draft whitepaper. The SOFT tier is ratified and first-class, but its end-to-end settlement and dispute lane is still being specified, and the currently wired settlement path remains the attested one. --- # SOFT and HARD: the two miner hardware tiers Source: https://ask.flop.finance/docs/soft-and-hard-tiers FLOP · SOFT and HARD: the two miner hardware tiers # SOFT and HARD: the two miner hardware tiers Verification does not rest on trusted hardware. Every session must carry an activation commitment a challenger can re-check, and disputes are settled by re-execution under bond. Confidential computing is an optional upgrade, **not an entry requirement**. FLOP · SOFT and HARD: the two miner hardware tiers › SOFT — the default ## SOFT — the default SOFT is what a miner gets with no attested hardware inventory. - Any capable GPU qualifies. - No governed per-device ceiling. - Accepted capacity equals measured benchmark throughput. What SOFT costs instead of hardware: - Audit exposure of about **one session in forty**. - A **1.25x surge multiplier** on capacity stake while the cap is still burst-ratcheted. FLOP · SOFT and HARD: the two miner hardware tiers › HARD — specified optional tier ## HARD — specified optional tier HARD is a **specified target, not currently deployable from this repository**: its attestation bridge and quote-verification transport are unbuilt. It would require **NVIDIA Confidential Computing on a TDX or SEV-SNP host**. In that design: - The measured model weights are bound to the attested environment. - Capacity is the lesser of measured throughput and **90% of the summed governed device ceilings**. In the HARD design, **attestation failure is a 100% slash**. That exposure would apply only to miners using that path once it is deployed. FLOP · SOFT and HARD: the two miner hardware tiers › Which to choose ## Which to choose SOFT is the current devnet development path on ordinary GPUs. Its end-to-end settlement and dispute path is still open. See [Run a FLOP miner](https://ask.flop.finance/docs/run-miner) for the deployable topology and readiness checks. HARD cannot currently be selected as an operational upgrade; its governed ceiling is a cap, not a promise of higher capacity than SOFT. FLOP · SOFT and HARD: the two miner hardware tiers › Status ## Status Draft whitepaper. The SOFT tier is ratified and first-class, but its end-to-end settlement and dispute lane is still being specified, and the currently wired settlement path remains the attested one. --- # FLOP tokenomics in brief Source: https://ask.flop.finance/docs/tokenomics-basics FLOP · FLOP tokenomics in brief # FLOP tokenomics in brief FLOP · FLOP tokenomics in brief › The block reward ## The block reward The block reward is **96 FLOP**. It **halves every 730 days** for **five halvings** — 96 → 48 → 24 → 12 → 6 → 3 — then stays constant at **3 FLOP** in perpetuity. Blocks arrive on a **one-second** average cadence, with a roadmap toward sub-millisecond settlement. FLOP · FLOP tokenomics in brief › How each block reward splits ## How each block reward splits | Share | Recipient | Basis | | ------- | ----------- | ------- | | 75% | Miners | Distributed by verified G_n contribution | | 10% | Active validator set | Shared across the set | | 10% | Agents and brokers | Minted to a protocol account; **distribution not yet live** | | 5% | Community stakers | Minted to a protocol account; **distribution not yet live** | The agent and staker shares were **carved out of the miner share**, not added on top: the miner leg fell from 90% to 75% to fund them, and the validator leg did not move. In era 0 that makes the miner pool **72 FLOP** per rewarded block. The miner pool halves every **63,072,000 blocks** and reaches a **2.25 FLOP** floor after five halvings. FLOP · FLOP tokenomics in brief › The developer subsidy ## The developer subsidy On top of the block reward, **16 FLOP per block** is minted as a developer subsidy — **8 each** to FLOP Labs and the FLOP Foundation. It **halves on the same 730-day boundaries** as the block reward (16 → 8 → 4 → 2 → 1) and then **stops entirely from year 11**, five eras in — exactly where the block reward reaches its perpetual floor. The subsidy terminates; the reward does not. FLOP · FLOP tokenomics in brief › Transaction fees ## Transaction fees Live transaction fees currently **burn 10%** and route the remainder to the block author. That routing is interim. Separately, **1% of session fees** is earmarked to validators performing audits — a documented design commitment whose wiring follows later. FLOP · FLOP tokenomics in brief › Stake and delegation ## Stake and delegation Miners and validators both stake FLOP. Holders who do not want to operate hardware can **delegate** stake to a validator or a miner and share rewards proportionally. The staking pallet supports commission-based proportional distribution, but live block rewards and session payments currently settle to the miner account directly. Delegating is **not** the same thing as the 5% community-staker share above. Delegation pays you out of the miner's or validator's own leg today; the separate staker leg is minted to a protocol account and has no payout path yet. FLOP · FLOP tokenomics in brief › Status ## Status Draft whitepaper. Fee routing is interim, the audit-fee earmark is documented but not yet wired, and the miner capacity-stake constants are under economic reconciliation — see [staking and slashing](https://ask.flop.finance/docs/staking-and-slashing). The **agent and community-staker shares are not claimable today**. Each is minted every block to a protocol-held account and accrues there; no rebate, claim, or pro-rata payout path exists for either yet, and the rules that will govern them are still being designed. --- # What is FLOP? Source: https://ask.flop.finance/docs/what-is-flop FLOP · What is FLOP? # What is FLOP? FLOP is the **proof-of-useful-inference blockchain and native currency for the agentic economy**. Agents pay miners in FLOP to run inference, converting currency directly into compute and intelligence. The name is the unit: FLOP means floating-point operations. Spend FLOP, get inference. FLOP · What is FLOP? › Why agents need a currency of their own ## Why agents need a currency of their own Humans exchange labour for money because money buys food and shelter. Agents consume compute and produce intelligence, so the money of the agentic economy must buy compute. FLOP does exactly that: at any point it converts into inference, letting an agent turn currency into intelligence. - Compute is what agents require to exist — they consume it and produce intelligence. - Any time it wants, an agent converts FLOP into compute by tasking a miner with inference. - Network value scales from N-squared (Metcalfe) toward 2^N (Reed) as agents form sub-economies among themselves. FLOP · What is FLOP? › What the network is ## What the network is FLOP combines proof-of-useful-inference with an **account-based send-and-receive chain**. Agents post a session request to the mempool; a capable miner runs it and returns a proof; validators fold each proof hash into a block. **Ordinary GPUs qualify.** Confidential computing is an optional tier, not an entry requirement. FLOP · What is FLOP? › The three roles ## The three roles | Role | What it does | What it earns | | ------ | -------------- | --------------- | | Agent | Posts session requests and pays for inference | The compute it bought | | Miner | Runs the inference and submits the proof | Session payment plus a G_n-weighted share of the miner block-reward pool | | Validator | Builds blocks of proof hashes, stores model weights, governs | A share of the 10% validator block-reward pool | Miners and validators both stake FLOP, and stake is subject to slashing for dishonesty. FLOP · What is FLOP? › Status ## Status This describes a **draft whitepaper**. Individual figures and mechanisms are at differing stages of implementation; where a page below says a thing is planned, under review, or not yet wired, that is the current state and not a description of shipped behaviour. --- # Integrating an agent with FLOP Source: https://ask.flop.finance/docs/agent-integration FLOP · Integrating an agent with FLOP # Integrating an agent with FLOP FLOP · Integrating an agent with FLOP › How does my agent buy inference? ## How does my agent buy inference? Create a **session request** in the mempool. A capable miner accepts, runs the task, and returns a proof. You pay in FLOP on settlement. FLOP · Integrating an agent with FLOP › What goes in a request? ## What goes in a request? Five fields: - Model-weight hash - Max latency - Compute, in FLOPs - A confidentiality flag - The fee FLOP · Integrating an agent with FLOP › What do I get back? ## What do I get back? A proof of useful inference: **activation commitments and a co-signed transcript**. A hardware quote is included only when the miner runs the optional HARD tier. FLOP · Integrating an agent with FLOP › How do I stop an agent overspending? ## How do I stop an agent overspending? The account-based chain carries the controls: - Pre-set **spend limits**. - **Delegated bounded authority via proxies**. - **Multisig**, **timelock or vesting**, and **multi-party escrow pools**. See [agent accounts and spend control](https://ask.flop.finance/docs/agent-accounts-and-spend-control). FLOP · Integrating an agent with FLOP › What if the work is wrong? ## What if the work is wrong? Challenge it. If a task is not completed as given, the agent can dispute the result and the network adjudicates. A discretionary challenger posts a **100 FLOP bond**, forfeited if the dispute is frivolous. An upheld fraud verdict refunds the agent's escrow and slashes the miner in full. FLOP · Integrating an agent with FLOP › Can I hold something other than FLOP? ## Can I hold something other than FLOP? You can swap. Native hashlock timelocks let an agent escrow FLOP against another chain's asset and exchange it once the counter-transfer confirms — see [cross-chain swaps](https://ask.flop.finance/docs/atomic-swaps). FLOP · Integrating an agent with FLOP › Is there an airdrop? ## Is there an airdrop? Yes. It arrives locked, and a locked balance can be spent **only on compute**. When it becomes liquid is not yet set — see [the airdrop and testnet conversion](https://ask.flop.finance/docs/airdrop-and-testnet-conversion). FLOP · Integrating an agent with FLOP › Can my agent earn while idle? ## Can my agent earn while idle? It can delegate stake to miners or validators and earn a share of rewards. FLOP · Integrating an agent with FLOP › Status ## Status Draft whitepaper. --- # FLOP: frequently asked questions Source: https://ask.flop.finance/docs/general-faq FLOP · FLOP: frequently asked questions # FLOP: frequently asked questions FLOP · FLOP: frequently asked questions › What is FLOP? ## What is FLOP? The proof-of-useful-inference blockchain and native currency for the agentic economy. Agents pay miners in FLOP to run inference, converting currency directly into compute and intelligence. FLOP · FLOP: frequently asked questions › Why would an agent want a currency at all? ## Why would an agent want a currency at all? Humans exchange labour for money because money buys food and shelter. Agents consume compute and produce intelligence, so the money of the agentic economy has to buy compute. FLOP does that: at any point it converts into inference. FLOP · FLOP: frequently asked questions › How does the network fit together? ## How does the network fit together? Agents post a session request to the mempool. A capable miner runs it and returns a proof. Validators fold each proof hash into a block. FLOP · FLOP: frequently asked questions › Do I need special hardware to take part? ## Do I need special hardware to take part? No. Ordinary GPUs qualify. Confidential computing is an **optional tier**, not an entry requirement. FLOP · FLOP: frequently asked questions › How fast are blocks? ## How fast are blocks? One second on average, with a roadmap toward sub-millisecond settlement. FLOP · FLOP: frequently asked questions › What is the block reward? ## What is the block reward? 96 FLOP, halving every 730 days for five halvings to a 3 FLOP floor, then constant in perpetuity. Miners share 75%, weighted by verified G_n; the active validator set shares 10%; 10% is earmarked for agents and brokers and 5% for community stakers. Those last two legs are minted to protocol-held accounts and **are not distributed to anyone yet**. FLOP · FLOP: frequently asked questions › Can I earn without running hardware? ## Can I earn without running hardware? Yes. Holders can delegate stake to a validator or a miner and share rewards proportionally. FLOP · FLOP: frequently asked questions › Who decides what changes? ## Who decides what changes? Validators, through FLOP Improvement Proposals. Most FIPs need two-thirds of the active validator set. Through the first halving, only the FLOP Foundation may submit one. FLOP · FLOP: frequently asked questions › What happens if a miner cheats? ## What happens if a miner cheats? An upheld fraud verdict slashes 100% of the miner's stake, ejects them, and refunds the agent. See [the challenge game](https://ask.flop.finance/docs/verification-stack). FLOP · FLOP: frequently asked questions › Status ## Status Draft whitepaper. --- # Mining on FLOP: frequently asked questions Source: https://ask.flop.finance/docs/miner-faq FLOP · Mining on FLOP: frequently asked questions # Mining on FLOP: frequently asked questions FLOP · Mining on FLOP: frequently asked questions › What does a miner actually do? ## What does a miner actually do? Accepts an agent's session request, opens a secure private connection, runs the inference, and returns activation commitments plus a co-signed transcript. That evidence is the proof of useful inference validators record and challengers can audit. FLOP · Mining on FLOP: frequently asked questions › What hardware do I need? ## What hardware do I need? Any capable GPU. **No confidential-computing hardware is required** — the default SOFT tier runs on ordinary GPUs. HARD, using NVIDIA Confidential Computing on a TDX or SEV-SNP host, is a specified optional tier whose bridge is not yet deployable. See [SOFT and HARD tiers](https://ask.flop.finance/docs/soft-and-hard-tiers). FLOP · Mining on FLOP: frequently asked questions › What do I have to stake? ## What do I have to stake? A **10,000 FLOP base self-stake**, plus a capacity exposure bond that scales with the compute you are calibrated to serve. Do **not** estimate the bond from the 0.01 FLOP per calibrated GFLOP/s coefficient alone: the live runtime also applies the 604,800-block revocation window and a 1.25x surge factor, which currently imply 7,560 FLOP per calibrated GFLOP/s. Query the runtime requirement for your calibrated miner account. FLOP · Mining on FLOP: frequently asked questions › What do I earn? ## What do I earn? The settled session payment, plus a **G_n-weighted share of the 75% miner block-reward pool**. In era 0 that pool is **72 FLOP per rewarded block**. It halves every 63,072,000 blocks and reaches a 2.25 FLOP floor after five halvings. The miner share was cut from 90% to 75% to fund two new legs — 10% to agents and brokers and 5% to community stakers — carved out of the miner residual rather than added on top. The validator leg stayed at 10%. Neither new leg is distributed yet: each is minted to a protocol-held account pending a distribution design. FLOP · Mining on FLOP: frequently asked questions › Is mining profitable? ## Is mining profitable? **Conditionally.** Return is session payments plus block rewards, less capacity cost. Results change with demand, token price, verified utilization, reward era, G_n share, and capacity cost. They are not a fixed network return. The revenue calculator's default rented GPUs use an all-in 30-day rental price that already covers the provider's power, hardware amortization, and capital cost; owned devices amortize their purchase price separately. Both the calculator and the macro simulator **exclude stake opportunity cost, taxes, downtime, and execution risk**, so results are stress signals rather than ROI forecasts. Size your own case on the Revenue model page and read the range rather than a single number. FLOP · Mining on FLOP: frequently asked questions › What is my audit exposure on SOFT? ## What is my audit exposure on SOFT? About **one session in forty** (2.5%), plus the 1.25x surge multiplier on capacity stake while the cap is still burst-ratcheted. FLOP · Mining on FLOP: frequently asked questions › What happens if I am challenged? ## What happens if I am challenged? You have **two hours** to produce the disputed turn's signed evidence — transcript entry, Merkle proof, enclave signature. Silence defaults to a fraud verdict. An upheld fraud verdict slashes **100%** of stake and blacklists the identity. Liveness faults stay cheap, 1-5%. FLOP · Mining on FLOP: frequently asked questions › Can others back me? ## Can others back me? Yes — holders can delegate stake to a miner and share rewards proportionally. Note that the staking pallet supports commission-based proportional distribution, but live block rewards and session payments currently settle to the miner account directly. FLOP · Mining on FLOP: frequently asked questions › What about testnet? ## What about testnet? The testnet conversion model allocates from a **1,200,000,000 FLOP miner pool** using verified activity rather than token holdings, scoring miners on verified compute served. A quarter of the grant is liquid at genesis, and the rest unlocks as the miner earns serving inference on mainnet. See [the airdrop and testnet conversion](https://ask.flop.finance/docs/airdrop-and-testnet-conversion). FLOP · Mining on FLOP: frequently asked questions › Status ## Status The [current devnet miner setup](https://ask.flop.finance/docs/run-miner) runs a SOFT worker and measured GPU backend. SOFT's end-to-end settlement and dispute lane is still being specified; HARD attestation is not deployable from this repository. The capacity-stake constants are under economic reconciliation. The rewards above describe protocol accounting, not a current production earnings claim. --- # Running a FLOP validator: frequently asked questions Source: https://ask.flop.finance/docs/validator-faq FLOP · Running a FLOP validator: frequently asked questions # Running a FLOP validator: frequently asked questions FLOP · Running a FLOP validator: frequently asked questions › What does a validator do? ## What does a validator do? Three things: 1. **Build blocks** from miners' proofs of useful inference, bundling proof hashes up to a 2 MB block size limit. 2. **Store and serve model weights** in the data-availability layer, so sessions can be served. 3. **Govern the network** by voting on FLOP Improvement Proposals. FLOP · Running a FLOP validator: frequently asked questions › How do I join? ## How do I join? Follow the [validator setup guide](https://ask.flop.finance/docs/run-validator). The current disposable devnet needs matching network/software, session keys, funded stake, administrator promotion and verification of active keys plus finality. Registration alone queues an account. Public release and independent operator admission still have tracked gaps. The ratified target is **1,000 validators**; the source runtime authority bound remains 200. FLOP · Running a FLOP validator: frequently asked questions › How does rotation work? ## How does rotation work? Roughly every month the **worst-performing 50 are replaced by the top 50 in waiting**, on availability and uptime. FLOP · Running a FLOP validator: frequently asked questions › What do validators earn? ## What do validators earn? The active set shares **10% of block rewards** — unchanged when the split went four ways, since the agent and staker legs were carved out of the miner share, not out of this one. Live transaction fees currently burn 10% and route the remainder to the block author — that routing is interim. Auditing currently sits under this same 10% share. The design commits **1% of session fees** to validators performing audits, wired later. FLOP · Running a FLOP validator: frequently asked questions › Can holders back a validator? ## Can holders back a validator? Yes. Holders can delegate stake to a validator to earn a share of rewards. FLOP · Running a FLOP validator: frequently asked questions › What gets a validator slashed? ## What gets a validator slashed? Publishing a **dishonest block** risks draconian slashing and a **permanent ban**. FLOP · Running a FLOP validator: frequently asked questions › Can I challenge a miner? ## Can I challenge a miner? Yes — **any active validator can dispute any session**, not only sessions it was involved in. That is deliberate: it means a lazy or colluding paying agent cannot switch detection off. A discretionary challenger posts a **100 FLOP bond**, forfeited if the dispute is frivolous. FLOP · Running a FLOP validator: frequently asked questions › How do I vote on changes? ## How do I vote on changes? On a FIP, the active set votes and in most cases **two-thirds must approve** before implementation begins. Through the first halving, only the FLOP Foundation may submit a FIP. FLOP · Running a FLOP validator: frequently asked questions › Status ## Status Draft whitepaper. Live transaction-fee routing remains interim, and the audit-fee earmark is documented but not yet wired. --- # FLOP glossary Source: https://ask.flop.finance/docs/core-terms FLOP · FLOP glossary # FLOP glossary **Activation commitment** — a fingerprint of the model's internal state, committed during a session so a challenger can later re-check that the registered model actually ran. See TOPLOC. **Agent** — a compute buyer. Posts session requests and pays miners in FLOP to run inference. **Bisection** — the dispute procedure that narrows a disagreement to a single turn in a handful of rounds, so dispute cost is independent of session length. **Block reward** — 96 FLOP per block in era 0, halving every 730 days for five halvings, then constant at 3 FLOP in perpetuity. Miners take 75%, the active validator set 10%, agents and brokers 10%, and community stakers 5%. The last two legs are minted to protocol-held accounts and are not yet distributed. **Capacity exposure bond** — the part of a miner's stake that scales with the compute it is calibrated to serve, on top of the 10,000 FLOP base self-stake. **Challenge window** — the period during which a settled session can still be audited. About seven days today, bounded by how long the data-availability layer keeps the evidence. **Confidential computing** — NVIDIA Confidential Computing on a TDX or SEV-SNP host, the hardware basis of the optional HARD tier. Not required to mine. **Data-availability layer (DA layer)** — where validators store model weights, and where miners' audit evidence is retained under serve-or-slash for the challenge window. **FIP (FLOP Improvement Proposal)** — the on-chain governance mechanism. Most FIPs need two-thirds of the active validator set to approve. **FLOP** — both the network's currency and its unit: floating-point operations. Spend FLOP, get inference. **G_n** — the unit by which verified miner work is weighted when the 75% miner block-reward pool is distributed. **HARD tier** — the optional miner tier requiring NVIDIA Confidential Computing on a TDX or SEV-SNP host. Binds measured model weights; caps capacity at 90% of summed governed device ceilings; attestation failure is a 100% slash. **HTLC (hashlock timelock)** — the native primitive that escrows FLOP against another chain's asset, exchanging once the counter-transfer confirms. **Liveness fault** — being offline. Slashed cheaply, 1-5%, unlike provable fraud. **Miner** — a compute provider. Stakes FLOP, runs verified inference for agents, and earns the session payment plus a G_n-weighted share of the miner reward pool. **PoUI (Proof of Useful Inference)** — the network's proof: activation commitments plus a co-signed transcript showing an agent's inference session ran as specified. **Session request** — an agent's order for inference, pinning five fields: model-weight hash, max latency, compute in FLOPs, a confidentiality flag, and the fee. **SOFT tier** — the default miner tier. Any capable GPU, no attested hardware inventory, no governed per-device ceiling; carries about one-in-forty audit exposure and a 1.25x capacity stake surge multiplier. **TEE (trusted execution environment)** — the confidential-computing environment a miner may run a task inside. On FLOP it is **optional**: the HARD tier uses one, the default SOFT tier does not, and verification does not rest on trusted hardware in either case. **TOPLOC** — the activation-commitment scheme: 258 bytes per 32 tokens, retained on the DA layer for the challenge window. **Transcript root** — the Merkle root over a session's co-signed per-turn leaves, stored on-chain at settlement. **Validator** — builds blocks of proof hashes, stores model weights in the DA layer, and votes on FIPs. The set is capped at 1,000, with about 50 rotated monthly. FLOP · FLOP glossary › Status ## Status Draft whitepaper. Terms are defined as the project intro uses them. --- # Agent accounts and spend control Source: https://ask.flop.finance/docs/agent-accounts-and-spend-control FLOP · Agent accounts and spend control # Agent accounts and spend control FLOP is an **account-based send-and-receive chain**. That gives agents the primitives to operate safely at scale rather than holding a bare key and hoping. FLOP · Agent accounts and spend control › What an agent account can do ## What an agent account can do - **Pre-set spend limits**, so an agent cannot exceed a budget it was given. - **Delegated bounded authority via proxies** — hand another party a capability, not the account. - **Multisig**, **timelock or vesting**, and **multi-party escrow pools**. - **Delegate stake** to miners or validators to earn a share of rewards. - Transfers, staking, and a **declarative spend-condition layer**. FLOP · Agent accounts and spend control › Why it matters for an agent ## Why it matters for an agent An agent that buys compute continuously needs the spending boundary enforced by the chain rather than by its own good behaviour. Spend limits and proxies put that boundary on-chain, where a bug in the agent cannot exceed it. Escrow is the other half: a session's payment sits in escrow against the proof, and an upheld fraud verdict refunds the agent. FLOP · Agent accounts and spend control › Status ## Status Draft whitepaper. --- # Cross-chain swaps with HTLCs Source: https://ask.flop.finance/docs/atomic-swaps FLOP · Cross-chain swaps with HTLCs # Cross-chain swaps with HTLCs Native **hashlock timelocks (HTLCs)** let an agent escrow FLOP against **another chain's asset**. The HTLC exchanges FLOP for external crypto **once the counter-transfer confirms** — a cross-chain swap with no custodian holding both sides. FLOP · Cross-chain swaps with HTLCs › How a swap works ## How a swap works 1. The agent **escrows** FLOP under a hashlock timelock. 2. The counterparty transfers the other chain's asset. 3. Once that **counter-transfer confirms**, the HTLC releases the FLOP. Because the release is conditional on the counter-transfer, neither side has to trust the other, and neither side has to hand custody to a third party. If the counter-transfer never confirms, the timelock returns the escrowed FLOP. FLOP · Cross-chain swaps with HTLCs › What it is for ## What it is for Swaps are what let agents move value **between FLOP and other cryptocurrencies**, and trade **agent-to-agent** rather than through an exchange. That is what makes agent **sub-economies** possible. It is the same property the overview describes as network value scaling from N-squared (Metcalfe) toward 2^N (Reed): the more agents that can transact directly across chains, the more sub-economies become possible. FLOP · Cross-chain swaps with HTLCs › Status ## Status Draft whitepaper. The project intro describes swaps against "other cryptocurrencies" and "another chain's asset" generally, and does not name specific counterpart chains. --- # How FLOP is governed Source: https://ask.flop.finance/docs/governance FLOP · How FLOP is governed # How FLOP is governed Validators are the guardians of the network, and they govern it through **FLOP Improvement Proposals (FIPs)**. FLOP · How FLOP is governed › The mechanism ## The mechanism FIPs are the **on-chain governance mechanism**. On a FIP, the active validator set votes, and in most cases **two-thirds must approve** before implementation begins. FLOP · How FLOP is governed › Who may propose ## Who may propose **Through the first halving, only the FLOP Foundation may submit a FIP.** FLOP · How FLOP is governed › What governance can change ## What governance can change Governance holds the dials the security argument depends on. The audit rate and the stake size are explicitly substitutable, and governance can raise either until honesty is the only profitable strategy — see [the challenge game](https://ask.flop.finance/docs/verification-stack). FLOP · How FLOP is governed › Status ## Status Draft whitepaper. --- # How blocks are built Source: https://ask.flop.finance/docs/how-blocks-are-built FLOP · How blocks are built # How blocks are built FLOP · How blocks are built › The block ## The block Blocks arrive on a **one-second** average cadence, with a roadmap toward sub-millisecond settlement. Each block bundles **proof hashes** from completed inference sessions, up to a **2 MB block size limit**. Validators do the building. A validator takes the proofs miners submit, includes each proof's hash in a block, and the session settles. FLOP · How blocks are built › The data-availability layer ## The data-availability layer Validators also **store the model weights** that agents and miners rely on, in the data-availability layer, so sessions can be served. The same layer holds the audit evidence for the challenge window, under serve-or-slash — see [the challenge game](https://ask.flop.finance/docs/verification-stack). FLOP · How blocks are built › Who is in the set ## Who is in the set The validator set is **capped at 1,000**. Roughly **50 rotate each month**: the worst-performing 50 are replaced by the top 50 in waiting, on availability and uptime. FLOP · How blocks are built › What validators earn ## What validators earn The active set shares **10% of block rewards**. Live transaction fees currently burn 10% and route the remainder to the block author; that routing is interim. FLOP · How blocks are built › Status ## Status Draft whitepaper. Live transaction-fee routing remains interim. --- # How an inference session settles Source: https://ask.flop.finance/docs/inference-session-lifecycle FLOP · How an inference session settles # How an inference session settles Four steps, the same on every page of the network: request, match, prove, settle. FLOP · How an inference session settles › 1. Request ## 1. Request The agent posts a **session request** to the mempool. A request pins five fields: | Field | What it fixes | | ------- | --------------- | | Model-weight hash | Which model must run | | Max latency | The deadline | | FLOPs | How much compute the task is worth | | Confidentiality flag | Whether the session needs the confidential path | | Fee | What the agent pays in FLOP | FLOP · How an inference session settles › 2. Match ## 2. Match A miner with capable hardware accepts and opens a **secure, private connection** with the agent. On the miner's side, accepting means accepting a compute channel that pins the model, the SLA, the proof policy, and the escrowed payment. FLOP · How an inference session settles › 3. Prove ## 3. Prove The miner completes the inference and submits the **proof of useful inference**: activation commitments and a co-signed transcript root, plus a hardware quote if the miner runs the optional HARD tier. FLOP · How an inference session settles › 4. Settle ## 4. Settle Validators include the proof hash in a block. The miner earns the **session payment** plus a **G_n-weighted share of the block reward**. If the work is wrong, the agent pays nothing and challenges instead: see [the challenge game](https://ask.flop.finance/docs/verification-stack). FLOP · How an inference session settles › Status ## Status Draft whitepaper. The SOFT tier's end-to-end settlement and dispute lane is still being specified; the currently wired settlement path remains the attested one. --- # Provide GPU capacity for a FLOP miner Source: https://ask.flop.finance/docs/run-gpu-provider FLOP · Provide GPU capacity for a FLOP miner # Provide GPU capacity for a FLOP miner **Current scope:** a GPU provider can run the [devnet miner](https://ask.flop.finance/docs/run-miner) on an owned Linux host or rented **Docker-capable NVIDIA VM**. This is an operator procedure, not a permissionless production onboarding promise. SOFT is the working development tier. HARD requires an attestation bridge that the repository does not currently ship. FLOP · Provide GPU capacity for a FLOP miner › Choose a host ## Choose a host The validated serving drill used an NVIDIA A40 with Qwen2.5-0.5B-Instruct, BF16, and a same-host worker/backend pair. Other NVIDIA cards may work if they fit the model, but they need their own throughput and TOPLOC check. GPU memory alone does not establish an accepted cap: chain-backed calibration measures delivered work across the **whole host**. More attached GPUs are counted once in aggregate. Faster throughput means a larger capacity-stake requirement. Size that stake using live chain constants before renting capacity. Check the offered machine before paying for a long lease: | Check | Why it matters | | --- | --- | | Full VM or owned host with Docker, Compose, NVIDIA driver and Container Toolkit | The backend Compose service reserves an NVIDIA GPU and mounts a local checkpoint. A provider's container-only product may forbid nested Docker. | | GPU visible to `nvidia-smi` on host and in a Docker GPU test | Proves the rental actually exposes the card to the container runtime. | | Enough disk for the exact checkpoint; persistent env, seed and worker volume | Model root and calibration state must survive restarts. | | Private tailnet plus inbound 8645 from the gateway | The worker needs chain/DA egress; gateway needs a private session path. | | One approved, pinned worker/backend image pair | Avoids drift in model, capture, and protocol behavior. | | Provider deletion path and billing readback | Stopping Compose does not stop VM billing. | GPU.ai **VM** is the documented candidate for same-host Compose. Its container instances cannot run Docker and it documents no public inbound port, so use the VM with tailnet access. The current repository notes have **not verified** whether a chosen GPU.ai VM offering exists with Docker and NVIDIA runtime preinstalled. Check that before committing spend. An owned Docker GPU server follows the same Compose path. The core FLOP GPU-provider library in `infra/vultr/gpu_providers/` surveys, provisions, monitors, and destroys provider instances; it does not by itself enroll an inference miner on-chain or satisfy model/calibration gates. RunPod has separate **pods** and **serverless endpoints**. Its pod proxy can serve the vLLM backend, but the current pod creation script passes only `MODEL_NAME`. It cannot mount/re-measure the checkpoint and pass the registered modelpack `MODEL_HASH`, so an onboarded worker's turns are rejected ([#1995](https://github.com/flop-labs/flop-core/issues/1995)). The pod proxy also has no authentication ([#1398](https://github.com/flop-labs/flop-core/issues/1398)). The serverless backend currently returns 503 for `/session/open`. Do not use either path as the current end-to-end miner procedure. FLOP · Provide GPU capacity for a FLOP miner › Provision and connect ## Provision and connect 1. Rent or prepare a GPU VM, confirm its GPU and Docker runtime, then place it on the private FLOP tailnet with the miner tag. Keep SSH restricted to your administration path; keep the backend's unauthenticated port off public interfaces. 2. Obtain the approved image SHA tags and a **read-only** private GHCR credential. Until public distribution exists, `https://images.flop.invalid` is a **placeholder** for operator access instructions. 3. Use the devnet operator's pre-registered model for the documented drill. Obtain the approved 40-character checkpoint commit from the model operator, then read its on-chain `MODEL_HASH` (modelpack root) with `flop model get`, as in [Run a FLOP miner](https://ask.flop.finance/docs/run-miner). That command does not return the checkpoint commit. A model publisher with a measured backend capture can onboard a new SOFT checkpoint with `flop model onboard --soft`, following the same guide; do not claim a TEE platform for this non-attested backend. Download the exact revision to the host, remove download metadata, and confirm its modelpack root equals the on-chain hash; if it differs, stop. Prepare a separate miner signer file and fund/register that account. A validator account must not double as this miner account. 4. Fill one private env file from `infra/devnet/devnet-ts/miners/miner.env.example`, pin both images, set RPC, model/policy binding, signer, tailnet address, auth token and DA URL. Use the same-host Compose pair described in [Run a FLOP miner](https://ask.flop.finance/docs/run-miner). 5. Ask the private ghost-task issuer to enroll the miner and the gateway to allowlist its tailnet URL, token, account, model, and current enclave key. The key changes each worker start. `https://ops.flop.invalid` is a **placeholder** for this access process. FLOP · Provide GPU capacity for a FLOP miner › Accept capacity and operate ## Accept capacity and operate The supervisor reads live chain constants and accepts a cap only after issuer jobs and a minimum finalized-block window. The source runtime requires 64 jobs over 600 blocks; a deployed chain may still require 512 over 21,600. The worker tops up capacity self-stake before acceptance. Watch `/session/info` for `calibration.ready` and `is_ready`; **`GET /session/info` itself requires the `SESSION_AUTH_TOKEN` bearer header**. Use the token-safe probe in [Run a FLOP miner](https://ask.flop.finance/docs/run-miner), not an unauthenticated public request. Sessions remain closed until calibration is accepted. Renewal requires eight fresh jobs and verified work, with a seven-day lease. Changing the GPU inventory or hardware fingerprint triggers the initial flow again. Keep the backend loaded through calibration; it measures served throughput. For each planned upgrade, record image SHA tags, model revision, policy hash, cap, and host inventory. Recreate the two Compose services with the same persistent volume and seed; check backend `/health`, worker `/session/info`, and gateway reachability. Refresh the regenerated enclave key in the gateway allowlist. When retiring a rental, shut down Compose and delete the provider instance; verify the provider console reports it gone and billing stopped. The repository files `infra/vultr/gpu_providers/ONBOARDING.md` and `infra/devnet/devnet-ts/miners/README.md` contain operator-specific commands. Their private credentials, endpoints, and image distribution still need a public release path. Compare outside operator patterns in the source-backed `docs/research/operator-provider-references.md` (repository access pending). --- # Run a FLOP miner on a GPU host Source: https://ask.flop.finance/docs/run-miner FLOP · Run a FLOP miner on a GPU host # Run a FLOP miner on a GPU host **Availability (29 September 2026): devnet development only.** A current miner is a CPU `miner-worker` paired with a GPU `miner-vllm-toploc` backend. The backend runs the model; the worker signs chain operations, handles compute-channel sessions, publishes TOPLOC evidence, and renews host-wide calibration. SOFT is the default tier and needs no confidential-computing hardware. Its full settlement/dispute path remains open ([#650](https://github.com/flop-labs/flop-core/issues/650)); HARD is specified but its bridge is not deployable. This guide does not promise mainnet participation or earnings. The runnable path is both services on one Docker-capable NVIDIA VM or owned Linux host. The RunPod pod path is blocked for registered model identity ([#1995](https://github.com/flop-labs/flop-core/issues/1995)) and lacks backend authentication ([#1398](https://github.com/flop-labs/flop-core/issues/1398)); see [GPU provider setup](https://ask.flop.finance/docs/run-gpu-provider). The repository's `docs/guides/miner-docker.md` old chain-node image examples are not the inference miner. FLOP · Run a FLOP miner on a GPU host › 1. Prepare identity, funds, model, and network ## 1. Prepare identity, funds, model, and network 1. Obtain access to the private devnet, its tailnet, the gateway operator, the ghost-task issuer, a DA worker, and SHA-pinned private GHCR images. The current operator instructions are in `infra/devnet/devnet-ts/miners/README.md`. Public access details are pending: `https://ops.flop.invalid` and `https://images.flop.invalid` are **placeholders**, not live services. 2. Create a **dedicated sr25519 miner account**, separate from every validator account. Until [#1552](https://github.com/flop-labs/flop-core/issues/1552) and [#1554](https://github.com/flop-labs/flop-core/issues/1554) are fixed, a validator that submits verified work can become the entire finality committee. Keep its one-line seed in a root-owned mode-0600 file on the host and back it up privately. The worker refuses a signer file owned by someone else. 3. Fund the account for the 10,000 FLOP base self-stake, capacity stake, and fees; register the miner. Capacity stake scales with the measured cap. The A40 devnet drill budgeted roughly 1 million FLOP; query the **live** runtime requirement before funding. The faucet does not currently fund miner-tier amounts. Use the private operator for genesis funding. 4. Use the devnet operator's pre-registered `Qwen/Qwen2.5-0.5B-Instruct` model and obtain its `MODEL_HASH` (modelpack verity root) and exact checkpoint commit. It is the only model with a validated TOPLOC capture in the present devnet instructions. A new **SOFT** model can use `flop model onboard --soft` with no TEE claim, but must pass measured backend capture validation on its actual GPU before admission. Do not claim `NvidiaCc` for this non-attested backend. 5. Put the host on the private tailnet as `tag:miner`. The worker needs outbound WebSocket RPC and DA worker access; the gateway needs inbound TCP 8645 on the **tailnet IP**. Do not expose the backend's unauthenticated port or the worker's session port publicly. The current repo file `infra/devnet/devnet-ts/miners/miner.env.example` is the complete field-by-field Compose template. The commands below fill in its model and policy values. FLOP · Run a FLOP miner on a GPU host › 1. Prepare identity, funds, model, and network › Chain, host, and account preflight ### Chain, host, and account preflight Use the approved `flop` CLI release and the same repository version as the pinned images. Replace the private RPC placeholder with the operator-supplied address, then check the genesis identity before any signed transaction: ```bash flop --network devnet --rpc ws://rpc.flop.invalid network status --json nvidia-smi docker info ``` The RPC URL is a **placeholder**. Require a reachable RPC, the expected devnet genesis hash (`matches_expected: true` when the release profile pins one), and the expected runtime version. Stop on mismatch. On the GPU host also confirm Docker Compose and NVIDIA GPU container access; use an approved CUDA diagnostic image with `docker run --rm --gpus all nvidia-smi` before renting for a long period. Generate a dedicated sr25519 mnemonic offline with the approved node CLI (`zkv-relay key generate --output-type json`) or an equivalent trusted key tool. Never use `//Alice` or a validator key. Write only the mnemonic/secret URI as one line to a private file, back it up offline, then install it on the host with `sudo install -o root -g root -m 600 seed.txt /opt/flop-miner/signer`. The Compose worker runs as root and rejects a signer file with the wrong owner or group/other permissions. For signed CLI operations, import the same secret into an encrypted Polkadot JSON keystore using `flop keys import --type sr25519 --secret-env MINER_SECRET --out miner.json --password-env FLOP_KEY_PASSWORD` on a trusted administration machine. Supply both environment variables securely, then clear them. Never put the mnemonic on a command line or in a committed file. After the private operator funds the account, register with the encrypted keystore: ```bash flop --network devnet --rpc ws://rpc.flop.invalid --keystore miner.json \ --password-env FLOP_KEY_PASSWORD miner register --commission 10 flop --network devnet --rpc ws://rpc.flop.invalid --keystore miner.json \ --password-env FLOP_KEY_PASSWORD miner status --json ``` The CLI `miner register` locks runtime-defined self-stake and rejects duplicate registration. Confirm `registered: true`, the expected address and stake. Capacity stake is a later measured-cap top-up by the worker, not a fixed amount to guess here. FLOP · Run a FLOP miner on a GPU host › 1. Prepare identity, funds, model, and network › Pin the checkpoint and decode policy ### Pin the checkpoint and decode policy First record the approved 40-character Hugging Face commit from the model operator. Use a **fresh dedicated** model directory so other files do not change the root. [Hugging Face's `hf download` reference](https://huggingface.co/docs/huggingface_hub/package_reference/cli) supports `--revision` and `--local-dir`; [uv's tool runner](https://docs.astral.sh/uv/guides/tools/) can invoke it without a system-wide Python install: ```bash MODEL_REV='REPLACE_WITH_APPROVED_40_HEX_COMMIT' MODEL_CHECKPOINT_DIR=/opt/flop-miner/models/qwen2.5-0.5b-instruct uvx --from huggingface_hub hf download Qwen/Qwen2.5-0.5B-Instruct \ --revision "$MODEL_REV" --local-dir "$MODEL_CHECKPOINT_DIR" rm -rf "$MODEL_CHECKPOINT_DIR/.cache" (cd tools/modelpack && uv run --project . python -m modelpack pack \ "$MODEL_CHECKPOINT_DIR" --strict-members --json) ``` Only remove the download metadata from this newly downloaded model directory. Record `verity_root` and compare `0x` byte-for-byte with the chain's measured root: ```bash flop --network devnet --rpc ws://rpc.flop.invalid model get \ Qwen/Qwen2.5-0.5B-Instruct --precision BF16 --json ``` For the pre-registered model, use its on-chain hash for `MODEL_HASH`; the backend remeasures the mount at startup. If the chain has no registered BF16 model or the roots differ, stop and ask the model operator to resolve the mismatch. For a new SOFT checkpoint, use `0x` as the candidate `MODEL_HASH`, then configure and start its measured backend below before running `model onboard`. From the repository root, derive the policy JSON and hash used by both services: ```bash POLICY_FILE=infra/vultr/decode-policy-devnet-drill.json jq -c . "$POLICY_FILE" DECODE_POLICY_HASH="0x$(jq -c . "$POLICY_FILE" | uv run --no-project python infra/miner/vllm-toploc/decode_policy.py)" printf '%s\n' "$DECODE_POLICY_HASH" ``` Place the first output, single-quoted, in `DECODE_POLICY`; place the printed hash in `DECODE_POLICY_HASH`. The backend checks that the JSON preimage hashes to this value and refuses a mismatch. FLOP · Run a FLOP miner on a GPU host › 2. Configure the two services ## 2. Configure the two services From a checkout matching the approved images, make a private `miner-01.env` copy of `infra/devnet/devnet-ts/miners/miner.env.example` and set mode 0600. Keep it outside git. Use one copy per miner. This is a **non-secret shape example**, not a ready-to-run file; the `.invalid` hostnames and `REPLACE` values must be filled from the approved release and operator: ```dotenv COMPOSE_PROJECT_NAME=flop-miner-01 WORKER_NAME=devnet-ts-miner-01 FLOP_WORKER_IMAGE=ghcr.io/flop-labs/flop-core/miner-worker:sha-REPLACE FLOP_BACKEND_IMAGE=ghcr.io/flop-labs/flop-core/miner-vllm-toploc:sha-REPLACE FLOP_RPC=ws://rpc.flop.invalid,ws://rpc-backup.flop.invalid:9944 MINER_SIGNER_FILE=/opt/flop-miner/signer MODEL_NAME=Qwen/Qwen2.5-0.5B-Instruct MODEL_HASH=0xREPLACE MODEL_CHECKPOINT_DIR=/opt/flop-miner/models/qwen2.5-0.5b-instruct MODEL_PRECISION=BF16 TOPLOC_PRECISION=bf16 DECODE_POLICY='REPLACE_WITH_COMPACT_JSON' DECODE_POLICY_HASH=0xREPLACE OPENAI_BASE_URL=http://backend:8000/v1 SESSION_BIND_IP=REPLACE_WITH_TAILNET_IP SESSION_HOST_PORT=8645 SESSION_AUTH_TOKEN=REPLACE_WITH_PRIVATE_RANDOM_VALUE DA_URL=http://da.flop.invalid:7001 ``` | Field | Required value | | --- | --- | | `FLOP_WORKER_IMAGE`, `FLOP_BACKEND_IMAGE` | Approved `ghcr.io/flop-labs/flop-core/...:sha-<commit>` tags. Do not use `latest`. | | `FLOP_RPC` | Comma-separated pool and direct WebSocket RPC endpoints; the private values come from the devnet operator. `ws://rpc.flop.invalid` is a placeholder. | | `MINER_SIGNER_FILE` | Absolute path of the root-owned 0600 one-line miner seed. | | `MODEL_NAME`, `MODEL_HASH`, `MODEL_CHECKPOINT_DIR` | Model name, modelpack root, and exact checkpoint files. For a new SOFT model, use the candidate root until registration; a hash of the name is not sufficient. | | `MODEL_PRECISION`, `TOPLOC_PRECISION` | Keep the validated `BF16` and `bf16` pair for this drill. | | `DECODE_POLICY`, `DECODE_POLICY_HASH` | Compact JSON from `infra/vultr/decode-policy-devnet-drill.json` and its matching hash. | | `OPENAI_BASE_URL` | `http://backend:8000/v1` for this same-host Compose topology. | | `SESSION_BIND_IP`, `SESSION_HOST_PORT` | Host tailnet IP and normally 8645. | | `SESSION_AUTH_TOKEN` | Fresh `openssl rand -hex 32` value; provide the same token to the gateway operator. | | `DA_URL` | Private validator DA worker URL. Without it TOPLOC assurance settlement fails closed. | The worker Compose file sets `MINER_BACKEND=openai`, turns on TOPLOC, and mounts the signer read-only. The backend Compose file mounts the measured model read-only, reserves NVIDIA GPUs, and publishes no port. Keep exactly one inference backend configured. The backend requires both the model root and decode-policy hash to match their measured contents. FLOP · Run a FLOP miner on a GPU host › 3. Start and inspect ## 3. Start and inspect Log into GHCR with a read-only `read:packages` token, then run from `infra/devnet/devnet-ts/miners/`: ```bash docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml config --quiet docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml pull docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml up -d backend docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml ps docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml logs --tail=100 backend ``` The backend's private `/health` response reports actual model identity, precision, and policy hash. Query it from inside the backend container, where Python is already installed: ```bash docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml \ exec -T backend python -c 'import urllib.request; print(urllib.request.urlopen("http://127.0.0.1:8000/health").read().decode())' ``` Confirm `model_identity: "measured"`, the expected model hash, precision and decode-policy hash. For a new SOFT checkpoint, arrange a private capture endpoint reachable by the publisher CLI, set `BASE` to that endpoint, and run onboarding now. The Compose backend has no published port; do not expose its unauthenticated API publicly. If no private endpoint is available, stop and ask the devnet operator. Use the same model name as `MODEL_NAME` in the env file and the policy hash derived above: ```bash MODEL_NAME='REPLACE_WITH_NEW_MODEL_NAME' BASE='REPLACE_WITH_PRIVATE_CAPTURE_ENDPOINT' flop --network devnet --rpc ws://rpc.flop.invalid --keystore publisher.json \ --password-env FLOP_KEY_PASSWORD model onboard \ --source "$MODEL_CHECKPOINT_DIR" --precision BF16 \ --capture-endpoint "$BASE" --decode-policy-hash "$DECODE_POLICY_HASH" \ --registry-model "$MODEL_NAME" --backend-model-name "$MODEL_NAME" --soft ``` The publisher keystore must have devnet model authority. This records an empty TEE platform list. Model discovery can return it after model approval, but SOFT miner availability still uses off-chain routing because `modelRegistry.registerMiner` requires a TEE enum. Skip this command for the pre-registered model. Start the worker only after the backend health check and, for a new model, successful onboarding: ```bash docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml up -d worker docker compose --env-file miner-01.env -f docker-compose.miner.yml -f docker-compose.backend.yml logs --tail=100 worker backend ``` **Every worker session route, including `GET /session/info`, requires the bearer token.** From an authorized tailnet peer, read the token silently into a temporary shell variable, then send the header through curl's standard-input config so it is absent from shell history and curl's argv: ```bash FLOP_MINER_HOST='REPLACE_WITH_TAILNET_IP' read -r -s -p 'Session token: ' FLOP_SESSION_PROBE_TOKEN printf '\n' printf 'header = "Authorization: Bearer %s"\n' "$FLOP_SESSION_PROBE_TOKEN" | curl --fail --silent --show-error --config - \ "http://${FLOP_MINER_HOST}:8645/session/info" | jq '{minerAddress, modelHash, calibration, is_ready}' unset FLOP_SESSION_PROBE_TOKEN ``` The response reports `calibration` and `is_ready`. After calibration, repeat `flop --network devnet --rpc ws://rpc.flop.invalid --keystore miner.json --password-env FLOP_KEY_PASSWORD miner status --json` from the administration machine and confirm its on-chain `calibration` record agrees with the worker's active cap and miner address. This CLI reads `hwCalibration.benchmarkBurstCaps` as well as miner registration. An uncalibrated host is **not ready**: `/session/open` returns 503. The ghost-task issuer must enroll the miner account and public enclave key before jobs arrive. The worker reads live calibration constants, measures host-wide throughput, tops up capacity stake, and signs acceptance. Source runtime requirements are 64 verified jobs over at least 600 finalized blocks; a deployed devnet may still require 512 jobs over 21,600 blocks. The cap is renewed after eight fresh jobs plus required work and expires after seven days. Changed GPU inventory or fingerprint requires the initial flow again. Ask the gateway operator to allowlist the worker's tailnet URL, token, miner account, enclave key, and model identity. The worker generates a new enclave key on **every start**, so refresh the allowlist after restarts. FLOP · Run a FLOP miner on a GPU host › 4. Operate and troubleshoot ## 4. Operate and troubleshoot Keep the env, signer, checkpoint, and Compose `worker-data` volume persistent. Record image tags and checkpoint revision before upgrades. Change both approved image pins deliberately, pull, recreate, then check backend `/health`, worker `/session/info`, finalized chain progress, and gateway access. Stop with the same Compose file pair and `down`; avoid `--volumes` unless retiring the miner and deliberately deleting calibration state. If the GPU is rented, confirm deletion in the provider console to stop billing. | Symptom | Check first | | --- | --- | | GPU missing | Host `nvidia-smi`, NVIDIA Container Toolkit, Docker GPU visibility; use a VM that permits Docker. | | Backend exits | Mounted checkpoint root, matching model hash, decode-policy hash and JSON, GPU memory, pinned image tag. | | Calibration missing or expired | Funding/stake, ghost-issuer enrollment, finalized block progress, live job/window constants, worker logs. | | Gateway cannot open | Tailnet TCP 8645, token and regenerated enclave key allowlist, `is_ready`, DA access. | | TOPLOC omitted | Same-pass backend capture, BF16 precision, model/policy binding, DA publication logs. Missing evidence is a closed gate. | For protocol stake, cap, renewal, and slashing rules, see the repository source `docs/onboarding/miner.md` (public source access pending). For the GPU VM and RunPod topology, continue to [GPU provider setup](https://ask.flop.finance/docs/run-gpu-provider). --- # Run a FLOP validator, miner, or GPU provider Source: https://ask.flop.finance/docs/run-operator FLOP · Run a FLOP validator, miner, or GPU provider # Run a FLOP validator, miner, or GPU provider Start with the role you want to operate. These instructions describe the repository's current development workflows, reviewed on **2026-09-29**. They do not announce a public network launch or certify a currently running network. The validator rehearsal and the GPU miner deployment require their own matching network configuration; do not combine presets from separate networks. | Role | What you run | Start here | Evidence of success | | --- | --- | --- | --- | | Validator | CPU node for BABE authoring and AlephBFT finality, plus its configured DA service; no GPU/TEE required | [Validator setup](https://ask.flop.finance/docs/run-validator) | Active session/BABE/Aleph keys and advancing finality | | Miner | GPU inference backend plus a distinct miner worker/account; SOFT development path | [Miner setup](https://ask.flop.finance/docs/run-miner) | Real inference, finalized registration, accepted calibration, then accepted work | | GPU provider / fleet operator | Owned or rented GPU VMs, each with the supported miner stack | [GPU provider setup](https://ask.flop.finance/docs/run-gpu-provider) | Per-host identity/model/calibration checks, first-host proof before fleet expansion | A GPU provider offering rental capacity is not automatically a FLOP miner. Someone must operate the measured inference stack, own its account, fund the required deposits and complete registration/calibration. Likewise, a healthy validator container is not evidence that the chain admitted its account. FLOP · Run a FLOP validator, miner, or GPU provider › Inputs you need before starting ## Inputs you need before starting Obtain a network-specific operator release from the network administrator. Keep the following values together so a setup cannot silently mix incompatible versions: - **Network identity:** network name, expected genesis hash, chain spec or supported preset, bootstrap peer multiaddrs and accessible RPC. Check the actual genesis hash before signing. - **Software:** source revision, immutable node/worker/backend image digests, supported host architecture, release checksums and upgrade compatibility information. - **Access:** how the host reaches the RPC, chain proxy, DA and any approved private network; which services require credentials and who issues them. Never paste secrets into chat. - **Admission:** operator public account, current stake requirement, fee funding and any administrator-only funding/promotion or calibration issuer step. Keys stay with their owner. - **Miner model:** onboarded modelpack hash, exact checkpoint revision, decode policy, storage requirements and independent calibration-job service. The guides provide commands, configuration fields and acceptance criteria. Some supporting artifacts and addresses are still private or not released. An empty input is a blocked step, not permission to invent a hostname, image, chain identifier or model hash. FLOP · Run a FLOP validator, miner, or GPU provider › Private URL placeholders ## Private URL placeholders Any hostname ending in `.invalid`, or value labelled `REPLACE_WITH_…`, is a **placeholder**. It will not connect to FLOP. Replace it only with the administrator's verified value. A placeholder table is a handoff contract, not an announcement that the service exists. | Input | Example placeholder | What the administrator supplies | | --- | --- | --- | | Release bundle | `https://releases.flop.invalid/operator/` | Versioned artifacts, checksums and supported network | | Chain RPC | `wss://rpc.flop.invalid` | Reachable endpoint, access method and expected genesis hash | | Bootstrap peer | `/dns4/boot.flop.invalid/tcp/30333/p2p/REPLACE_WITH_PEER_ID` | Reachable P2P multiaddr and peer identity | | Image registry | `registry.flop.invalid/flop/node@sha256:REPLACE_WITH_DIGEST` | Pull access and immutable digest | | Operator support | `https://operators.flop.invalid/support` | Actual admission/support contact or portal | Loopback addresses in the guides are actual local service bindings, not public service URLs. Never expose unsafe node RPC, session tokens or a raw inference backend to the Internet merely to make a health check pass. FLOP · Run a FLOP validator, miner, or GPU provider › Let an agent handle the setup ## Let an agent handle the setup The source release contains two Agent Skills: `.agents/skills/setup-validator/SKILL.md` and `.agents/skills/setup-miner/SKILL.md`. With a checkout/release containing these files, ask a compatible coding agent: > Use setup-validator to set up my FLOP validator on the supplied host. Use the supplied > release and network configuration, gather missing non-secret inputs together, preserve > existing data, complete the authorized setup, and report admission and finality evidence. Or: > Use setup-miner to set up my GPU VM as a FLOP SOFT miner. Use the supplied model and network > release, gather missing non-secret inputs together, keep secrets on the host, and report > inference, registration, calibration and accepted-work evidence separately. Include the host, network, desired role, release location and authorized spending/signing scope. Install or provide the skill file if the agent cannot discover it; a skill name alone does not download instructions. Do not give an agent your wallet seed in a conversation. Existing operator authorization covers routine setup; a new paid rental, account funding or administrator signature needs the corresponding owner's authority. “One go” means one coordinated setup workflow. Chain session transitions, calibration windows, missing artifacts and external admission can prevent immediate completion. The agent must return the exact remaining gate instead of claiming that the host is earning. FLOP · Run a FLOP validator, miner, or GPU provider › Readiness and maintenance ## Readiness and maintenance Keep a receipt with the release/image digests, network/genesis, public account, configuration locations, running service versions, finalized transaction references and role-specific checks. Redact private endpoints when sharing it. Back up local configuration and keystores securely; never run two validators with the same session keys. For miners, preserve model/cache and required evidence data and recheck gateway/session identity after a restart. Upgrade one host first using a supported pinned release, then repeat the same checks before expanding the rollout. Container uptime alone cannot establish protocol readiness. Follow the role guide's shutdown and recovery steps; deleting a volume is not routine repair. FLOP · Run a FLOP validator, miner, or GPU provider › Known blockers and follow-up work ## Known blockers and follow-up work These issues track release gaps that an operator cannot repair by changing URLs: - [Public operator release bundle #2003](https://github.com/flop-labs/flop-core/issues/2003): source/image/model/network packaging and a clean-host acceptance drill. - [Independent validator key custody #2002](https://github.com/flop-labs/flop-core/issues/2002): administrator helper actions currently require the operator's seed even when targeting only their address. Keep the existing combined helper to a disposable single-admin devnet. - [Miner hot-key delegation #913](https://github.com/flop-labs/flop-core/issues/913) and [session-key persistence #1977](https://github.com/flop-labs/flop-core/issues/1977): avoid treating a funded account on a rented host as an isolated disposable worker key. - [SOFT model onboarding #2004](https://github.com/flop-labs/flop-core/issues/2004): the CLI offers `flop model onboard --soft` without a TEE claim, but a new model still needs its modelpack root, decode policy, and live backend capture validated. A real local/devnet registration and discovery proof remains to close the issue. Follow [Run a FLOP miner](https://ask.flop.finance/docs/run-miner) for the command and the validated devnet model. - [SOFT settlement/disputes #650](https://github.com/flop-labs/flop-core/issues/650): the current development workflow is not a complete production earning guarantee. HARD is also not currently deployable from this repository. Issue URLs may require repository access while the repository is private. The requirements and limitations needed to follow these guides are stated here and in each role guide. --- # Run a FLOP validator Source: https://ask.flop.finance/docs/run-validator FLOP · Run a FLOP validator # Run a FLOP validator This is the **current disposable devnet** procedure. FLOP validators author blocks with BABE, vote on finality with AlephBFT, and serve assigned data through a DA worker. They do not need a GPU or TEE. A public testnet or mainnet operator needs the network inputs below before joining; do not use the development genesis keys or `//Alice` on a public chain. | Input from network operator | Public placeholder | Devnet rehearsal | | --- | --- | --- | | Chain and genesis | `<CHAIN_SPEC_URL_OR_FILE>` and published genesis hash | Common `flop-devnet-N` preset or reviewed raw spec | | Software | `<PINNED_NODE_IMAGE>` and `<PINNED_DA_IMAGE>` | Two pinned images from one release | | Peer discovery | `<BOOTNODE_MULTIADDRESS>` | Reachable multiaddress from an existing host | | Admission | Published funding, stake, queue, and promotion policy | Devnet root funds and promotes | | Monitoring | `<PUBLIC_EXPLORER_URL>` and `<TELEMETRY_URL>` | Local RPC and metrics | The bracketed values are placeholders, **not** live addresses. Stop if a required input is missing or if chain spec, genesis, and software release do not agree. Current devnet admission is administrator controlled. It is not an open public onboarding service. FLOP · Run a FLOP validator › Prepare the host ## Prepare the host Use Linux with Docker Engine, the Docker Compose plugin, `curl`, and `jq` installed. The join helper also needs Node.js and `pnpm` matching the repository's pinned toolchain. Give each validator its own persistent volumes and session keys. Protect the host and backups with encrypted storage and key-only SSH. Keep node RPC on loopback, metrics on loopback or a private network, and permit P2P and DA traffic only along the required peer routes. Never run two active processes with the same session keys: simultaneous voting can equivocate. For production planning, the current FLOP profile is 8 dedicated cores, 32 GB RAM, 4 TB NVMe including DA custody, and a reliable low-latency 1 Gbps link. These are planning estimates, not measured devnet minimums. Aleph Zero's [hardware reference](https://docs.alephzero.org/aleph-zero/use/validate/hardware-requirements) emphasizes fast I/O and reliable networking, but its storage sizes omit FLOP's DA custody. From a FLOP repository checkout, make an untracked env file **on each host**: ```bash cp infra/devnet/.env.example infra/devnet/.env chmod 600 infra/devnet/.env ``` Set the fields in that host's `infra/devnet/.env`: ```dotenv CHAIN=flop-devnet-6 FLOP_NODE_IMAGE= FLOP_DA_VALIDATOR_IMAGE= HOST_IP= P2P_PORT=30333 PUBLIC_ADDR=/ip4//tcp/30333 BOOTNODES= DA_PORT=7000 DA_PUBLIC_ENDPOINT=http://:7000 RPC_BIND_IP=127.0.0.1 RPC_METHODS=safe ``` Use the **same** chain preset or raw spec and pinned images on all hosts. Leave `BOOTNODES` empty for the first genesis host. For a disposable genesis host, set `GENESIS_SEED` to its distinct `//Validator1` through `//ValidatorN` preset and set `DA_VALIDATOR_SEED` to the matching `secretSeed` derived with that same pinned node image. Later joiners leave `GENESIS_SEED` empty and use a fresh private 32-byte sr25519 seed for `DA_VALIDATOR_SEED` and their account. Never commit filled env files or send seeds in public tickets. An existing five-authority chain cannot simply switch to the six-authority preset; that requires a new genesis. For a **genesis host only**, derive its matching DA seed from the pinned image without printing it to the terminal (run from the repository root, after filling `.env`): ```bash ( set -euo pipefail cd infra/devnet set -a; . ./.env; set +a test -n "$GENESIS_SEED" install -d -m 700 "$HOME/.local/share/flop" umask 077 docker run --rm --entrypoint zkv-relay "$FLOP_NODE_IMAGE" \ key inspect "$GENESIS_SEED" --output-type json \ | jq -er .secretSeed > "$HOME/.local/share/flop/genesis-da-seed" ) ``` Put the saved secret in this host's private `DA_VALIDATOR_SEED` field using a local editor. Protect or remove the extra seed file after its backup policy is settled. The repository's `docs/runbooks/devnet-add-validator.md` has more chain-specific rehearsal detail. Start the first host and get its peer ID from its **local** RPC: ```bash cd infra/devnet docker compose config --quiet docker compose up -d docker compose ps curl -fsS -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"system_localPeerId","params":[]}' \ http://127.0.0.1:9944 | jq -r .result ``` On **every** host, compare the local genesis hash with the network operator's independently supplied `EXPECTED_GENESIS_HASH` (a public value). Do this before funding or registering. A new devnet's administrator must first review the raw chain spec and publish that expected hash; copying an unreviewed host's result as the expectation does not establish chain identity. ```bash FLOP · Run a FLOP validator › Still in infra/devnet; supply the published public hash first. # Still in infra/devnet; supply the published public hash first. ( set -euo pipefail : "${EXPECTED_GENESIS_HASH:?set the independently published genesis hash}" actual_genesis_hash=$(curl -fsS -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"chain_getBlockHash","params":[0]}' \ http://127.0.0.1:9944 | jq -er .result) test "$actual_genesis_hash" = "$EXPECTED_GENESIS_HASH" || { echo 'Genesis mismatch; stop before funding or joining' >&2 exit 1 } ) ``` Continue only when this check exits successfully on that host. Set each later host's `BOOTNODES` to a reachable `/ip4//tcp//p2p/` address, then start its Compose project. Open P2P and DA ports to the relevant hosts. A Docker container name is not a cross-host bootnode. The DA worker connects to its own node inside Compose; the advertised DA endpoint must be reachable by other validators. Bring up all genesis authorities promptly: an incomplete genesis committee may leave the finalized head stationary. FLOP · Run a FLOP validator › Still in infra/devnet; supply the published public hash first. › Join after genesis ## Join after genesis The existing join helper is suitable for a **single trusted devnet administration context**. Its `fund` and `promote` actions require `OPERATOR_SEED` even though root signs them. An independent operator must **not** disclose a private seed to an administrator. External onboarding needs seedless admin actions and a published admission policy. For a disposable rehearsal controlled by one administrator, follow this order: 1. Generate a fresh private account seed on the joining host and set it as `DA_VALIDATOR_SEED`. Leave `GENESIS_SEED` empty. Start the node and DA worker with the same chain and pinned images as the existing hosts. 2. Fund the account above the **live** greater of `minimumValidatorStake` and `valueCoupledStakeFloor`, with extra for fees. The devnet helper's `fund` action uses `sudo(balances.forceSetBalance)`; the faucet cannot cover this floor. 3. Temporarily recreate the joining validator with `RPC_METHODS=unsafe` while its host RPC remains bound to `127.0.0.1`. Run the helper's `join` action locally. It calls `author_rotateKeysWithOwner`, checks the keystore, submits `session.setKeys` with the ownership proof, and calls `validators.register`. Restore `RPC_METHODS=safe` immediately; do not put `unsafe` in `.env`. 4. Fund again for fees and DA endpoint deposits: registration freezes the account's full reducible balance. Root reviews queue order before its `promote` action submits `sudo(validators.rotate(0, 1))`. Registration alone only queues the account. 5. Run the helper's `verify` action after promotion. It waits for session activation, checks live BABE and Aleph keys, peers, and advancing finalized height. The exact executable helper commands are in [`docs/runbooks/devnet-add-validator.md`](https://github.com/flop-labs/flop-core/blob/main/docs/runbooks/devnet-add-validator.md) from the repository. That path is part of the devnet operator checkout; access to private images and network inputs still requires the network operator. The helper runs from `sdk/miner-worker` after `pnpm install --frozen-lockfile` at repo root. Never put a private account or root seed into an issue, chat, command log, or shared shell history. For a **disposable single-admin rehearsal only**, the repository runbook's command order is: ```bash FLOP · Run a FLOP validator › From the repository root, install the helper's dependencies once. # From the repository root, install the helper's dependencies once. pnpm install --frozen-lockfile FLOP · Run a FLOP validator › In sdk/miner-worker, set OPERATOR_SEED from a private 32-byte seed, # In sdk/miner-worker, set OPERATOR_SEED from a private 32-byte seed, FLOP · Run a FLOP validator › SUDO_SEED from the disposable devnet root, and WS_URL=ws://127.0.0.1:9944. # SUDO_SEED from the disposable devnet root, and WS_URL=ws://127.0.0.1:9944. cd sdk/miner-worker DEVNET_ACTION=fund node --input-type=module < ../../infra/devnet/operator.mjs FLOP · Run a FLOP validator › On the joining host only, briefly enable local key-generation RPC. The EXIT trap # On the joining host only, briefly enable local key-generation RPC. The EXIT trap FLOP · Run a FLOP validator › restores safe methods and checks the process even if join fails. # restores safe methods and checks the process even if join fails. ( set -e restore_safe_rpc() { (cd ../../infra/devnet && RPC_METHODS=safe docker compose up -d --no-deps --force-recreate validator) || return 1 (cd ../../infra/devnet && docker compose exec -T validator sh -c "tr '\000' ' ' &2; exit 1; }; exit "$join_status"' EXIT (cd ../../infra/devnet && RPC_METHODS=unsafe docker compose up -d --no-deps validator) DEVNET_ACTION=join node --input-type=module < ../../infra/devnet/operator.mjs ) FLOP · Run a FLOP validator › Stop here if the subshell failed; resolve join or safe-RPC restoration first. # Stop here if the subshell failed; resolve join or safe-RPC restoration first. DEVNET_ACTION=fund node --input-type=module < ../../infra/devnet/operator.mjs DEVNET_ACTION=promote node --input-type=module < ../../infra/devnet/operator.mjs DEVNET_ACTION=verify node --input-type=module < ../../infra/devnet/operator.mjs ``` Only the trusted devnet root can run `fund` and `promote`. The helper checks the root key and that the joining account is the next queued candidate. Do not copy this root seed arrangement into a public operator deployment. Separate seedless administrator actions are tracked in [issue #2002](https://github.com/flop-labs/flop-core/issues/2002); the public release inputs are tracked in [issue #2003](https://github.com/flop-labs/flop-core/issues/2003). FLOP session keys are `babe` (sr25519 block authoring), `audi` (sr25519 authority discovery), and `alp0` (ed25519 AlephBFT). Aleph Zero's operator guides use an Aura key and a separate validator port; those are **not FLOP settings**. The FLOP Aleph transport uses the node's libp2p peer port. FLOP · Run a FLOP validator › Stop here if the subshell failed; resolve join or safe-RPC restoration first. › Verify and operate ## Verify and operate The helper's `verify` action waits up to two BABE session boundaries after promotion. It confirms `session.validators`, the registered BABE authority key, and the matching Aleph runtime authority key. `aleph.currentCommittee` alone is an account snapshot, not proof that a finality key is live. Read local health and finality twice: ```bash curl -fsS -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"system_health","params":[]}' \ http://127.0.0.1:9944 | jq .result curl -fsS -H 'content-type: application/json' \ -d '{"jsonrpc":"2.0","id":2,"method":"chain_getFinalizedHead","params":[]}' \ http://127.0.0.1:9944 | jq -r .result (cd ../../infra/devnet && docker compose logs --tail=100 validator da-validator) ``` The log command above assumes the shell is still in `sdk/miner-worker` after the join block. If starting a fresh shell at the repository root, use `(cd infra/devnet && docker compose logs --tail=100 validator da-validator)`. Healthy peers, no ongoing sync, and a finalized-head change over a short interval show the node is connected and the network is finalizing. The helper checks account membership and key activation. Monitor free disk space, DA availability, peer count, best and finalized heights, and logs; keep metrics private. Back up the account seed, node keystore and persistent volume, libp2p node key, and DA worker data with controlled access. Test restoration offline. A chain database snapshot alone does not restore signing or DA custody. Pin images during upgrades, move one validator at a time, and re-check peers and finality after each restart. A standby must stay keyless until the original has stopped and cannot sign. Follow the network's published exit and unbonding policy before retiring an active validator. | Symptom | Check | | --- | --- | | No peers | Reachable `PUBLIC_ADDR`, `BOOTNODES`, P2P firewall, matching chain and genesis | | Registered but idle | Promotion, two session boundaries, `babe`/`audi`/`alp0` keys on the local node | | Best height rises, finality does not | Committee key activation and peers on independent nodes; shared provider outage | | DA worker fails | Private seed, connection to its local node, advertised DA endpoint, persistent volume | | Join RPC fails | Local unsafe-method window for key generation only, then safe mode restored | For the role's stake and committee rules, use the repository's [`docs/onboarding/validator.md`](https://github.com/flop-labs/flop-core/blob/main/docs/onboarding/validator.md). --- # Staking, delegation, and slashing Source: https://ask.flop.finance/docs/staking-and-slashing FLOP · Staking, delegation, and slashing # Staking, delegation, and slashing Becoming a miner or a validator requires **staking FLOP**, and stake is subject to slashing for dishonesty. FLOP · Staking, delegation, and slashing › Miner stake ## Miner stake A miner posts a **10,000 FLOP base self-stake** plus a **capacity exposure bond**. The nominal coefficient is **0.01 FLOP per calibrated GFLOP/s**, but the live runtime also multiplies it by the **604,800-block revocation window** and the **1.25x surge factor**. Those constants currently imply **7,560 FLOP per calibrated GFLOP/s**. > **Do not estimate required stake from the 0.01 coefficient alone.** Query the runtime > requirement for the calibrated miner account. Because stake scales with calibrated capacity, large miners cannot outgrow their bond — the largest miners face the largest absolute burn. FLOP · Staking, delegation, and slashing › Validator stake ## Validator stake A validator stakes FLOP to join the set, which is **capped at 1,000**. Roughly **50 rotate each month** on availability and uptime: the worst-performing 50 are replaced by the top 50 in waiting. FLOP · Staking, delegation, and slashing › Delegation ## Delegation Holders can **delegate** stake to a validator or a miner and share rewards proportionally, without operating hardware themselves. What a delegator earns comes out of that miner's or validator's own reward leg. Separately, **5% of every block reward is earmarked for community stakers** — FLOP stakers who are neither miners nor validators. That leg is **minted to a protocol-held account and is not distributed to anyone yet**: there is no staking pool to join and nothing to claim. Delegating to a miner or a validator does not entitle you to it. FLOP · Staking, delegation, and slashing › Slashing ## Slashing | Fault | Consequence | | ------- | ------------- | | Liveness (being offline) | 1-5% | | Provable fraud, collusion, evidence forgery | 100% slash, ejection, blacklist | | Publishing a dishonest block (validator) | Draconian slashing and a permanent ban | | Attestation failure on the optional HARD tier | 100% slash | | Failing to serve retained audit data (DA provider) | Slashed | A fraud conviction needs **on-chain cryptographic evidence**; there is no oracle input to bribe. FLOP · Staking, delegation, and slashing › Status ## Status Draft whitepaper. The miner capacity-stake constants are **under economic reconciliation**. The staking pallet supports commission-based proportional distribution, but live block rewards and session payments currently settle to the miner account directly. --- # Cheating must not pay: the challenge game Source: https://ask.flop.finance/docs/verification-stack FLOP · Cheating must not pay: the challenge game # Cheating must not pay: the challenge game FLOP never re-runs inference to trust it. Every session leaves commitments that stay challengeable for a fixed window; a lottery and bonded disputes re-check slices of the work; an upheld fraud verdict burns 100% of the miner's stake. The game is sized so that **cheating loses money in expectation** even when most single cheats slip through. FLOP · Cheating must not pay: the challenge game › What the miner must retain ## What the miner must retain During a session the model commits tiny fingerprints of its internal state — **TOPLOC: 258 bytes per 32 tokens** — and every turn becomes a co-signed leaf under a Merkle root the chain stores at settlement. Those commitments and the audit data are published to the **data-availability layer** and kept for the full challenge window. The miner pays the storage deposit as a cost of being paid, and providers are slashed if they fail to serve it. - Retention lives on the DA layer under **serve-or-slash** — not as a promise on the miner's own disk. - Missing audit data does not dodge the audit: an unanswerable challenge resolves **against** the miner. FLOP · Cheating must not pay: the challenge game › Who can challenge, and when ## Who can challenge, and when Two lanes. **Scheduled.** At the end of each epoch a random, unbiasable lottery selects turns to audit, drawn across the work **by value**, so a single huge faked turn cannot hide inside a long session. **Discretionary.** The paying agent can dispute its own sessions, and **any active validator can dispute any session** — so a lazy or colluding payer does not switch detection off. - The sampled check is cheap by construction: one prefill (~100x cheaper than generation) or a sub-cubic arithmetic check — never the whole session. - A discretionary challenger posts a **100 FLOP bond**, forfeited if the dispute is frivolous. - **Bisection** narrows any disagreement to a single turn in a handful of rounds, so dispute cost is independent of session length. - A challenged miner has **two hours** to produce the disputed turn's signed evidence — its transcript entry, Merkle proof, and enclave signature. Silence defaults to a fraud verdict. FLOP · Cheating must not pay: the challenge game › What failing costs ## What failing costs An upheld fraud verdict is the **full-burn class**: 100% of the miner's stake slashed, ejection, blacklist — the same maximum tier as collusion and evidence forgery — and the agent's escrow is refunded. - Liveness faults (being offline) stay cheap, **1-5%**. The burn is reserved for provable fraud. - A fraud conviction needs on-chain cryptographic evidence; there is **no oracle input to bribe**. - Stake is capacity-proportional, so the largest miners face the largest absolute burn — fraud never pays off by growing. FLOP · Cheating must not pay: the challenge game › Why the math closes ## Why the math closes Sampling never promises to catch every cheat. It makes cheating **unprofitable**. At a **2.5% audit rate** a single cheated slice slips through about 97.5% of the time — and that is fine: - The odds of escaping every audit fall off **exponentially** as more slices are cheated. - Audits are spread across the work by value, so stolen value tracks the number of draws. - The deterrence rule — slash x stake >= gain / catch-rate — is closed by the 100% burn. Steal a small slice, risk the entire capacity-proportional stake: negative expected value at any realistic scale. The two dials, audit rate and stake size, are substitutable, and governance can raise either until honesty is the only profitable strategy. FLOP · Cheating must not pay: the challenge game › Who pays the auditors ## Who pays the auditors **1% of session fees** is earmarked to validators for performing audits. Re-check work is cheap — a fraction of a percent of session value at the current sampling rate — so the earmark covers it with margin, and audit income scales with usage rather than dying with the block-subsidy halvings. FLOP · Cheating must not pay: the challenge game › Status ## Status Draft design. The 1% audit earmark is documented now and wired later; until then auditing sits under the validators' existing 10% block-reward share, and a successful challenger recovers its bond. The ~7-day challenge window is bounded by DA retention and is under review to shorten toward hours, since audited slices re-verify in minutes. Per-turn encrypted input/output blobs — so an audit needs no live cooperation and discloses nothing in the honest case — are a designed next step. --- # The airdrop and testnet conversion Source: https://ask.flop.finance/docs/airdrop-and-testnet-conversion FLOP · The airdrop and testnet conversion # The airdrop and testnet conversion Both distributions are **earned by usage**, not by holding. FLOP · The airdrop and testnet conversion › Agent airdrop ## Agent airdrop A testnet airdrop seeds agent supply, and while it is locked it can only buy compute. - Locked agent airdrop can be spent **only on compute**: opening or topping up inference sessions. - **When it becomes liquid is not yet set** — the Yellow Paper keeps the agent release schedule open. FLOP · The airdrop and testnet conversion › Miner testnet conversion ## Miner testnet conversion The testnet conversion model allocates from a **1,200,000,000 FLOP miner pool** using verified activity rather than token holdings. Miners are scored on **verified compute served**; completed job count and active days carry no weight, and neither does held balance. FLOP · The airdrop and testnet conversion › Vesting ## Vesting - **Miners:** a quarter of the grant is **liquid at genesis**. The rest unlocks **one FLOP for every FLOP the miner earns serving inference** on mainnet, with no time limit. Block rewards do not count. Until it unlocks, the locked balance can be posted as the miner's stake but cannot otherwise be moved. - **Validators:** the grant is the validator's bond. It stays **locked until the first halving**, then grants are released **one validator per day over the following 1,000 days**. A released grant stays bonded while its validator is in the set. - **Agents:** the release schedule is not yet set (see above). These rules are ratified but not yet built: the runtime still vests every grant on a 90-day linear curve. FLOP · The airdrop and testnet conversion › Status ## Status Draft whitepaper. **The genesis distribution ceremony is not yet wired.** --- # Key protocol parameters Source: https://ask.flop.finance/docs/protocol-parameters FLOP · Key protocol parameters # Key protocol parameters Every figure below is as stated in the FLOP project intro. Several are explicitly under review; the Status notes say which. FLOP · Key protocol parameters › Chain ## Chain | Parameter | Value | Note | | --- | --- | --- | | Block time | 1 s | Average, with a roadmap toward sub-millisecond settlement | | Block size limit | 2 MB | Bounds how many proof hashes a block carries | FLOP · Key protocol parameters › Emission ## Emission | Parameter | Value | Note | | --- | --- | --- | | Block reward | 96 FLOP | Era 0 | | Halving period | 730 days | 63,072,000 blocks | | Number of halvings | 5 | Then constant in perpetuity | | Miner share | 75% | Distributed by verified G_n contribution | | Validator share | 10% | Shared across the active set | | Agent/broker share | 10% | Minted to a protocol account; distribution not yet live | | Community-staker share | 5% | Minted to a protocol account; distribution not yet live | | Era-0 miner pool | 72 FLOP | Per rewarded block | | Miner pool floor | 2.25 FLOP | 75% of the 3 FLOP floor, after five halvings | | Developer subsidy | 16 FLOP per block | 8 each to FLOP Labs and the FLOP Foundation, on top of the block reward; halves with the reward and stops after five eras, where the reward floors | | Transaction fee burn | 10% | Remainder routes to the block author; interim | | Audit fee earmark | 1% of session fees | To validators performing audits; documented, not yet wired | FLOP · Key protocol parameters › Validators ## Validators | Parameter | Value | Note | | --- | --- | --- | | Set size | 1,000 | Capped | | Monthly rotation | ~50 | Worst 50 replaced by top 50 in waiting, on uptime and availability | | FIP approval threshold | 2/3 | Of the active set, in most cases | FLOP · Key protocol parameters › Miners ## Miners | Parameter | Value | Note | | --- | --- | --- | | Base self-stake | 10,000 FLOP | Before the capacity bond | | Capacity bond, nominal | 0.01 FLOP per calibrated GFLOP/s | Nominal coefficient only | | Capacity bond, live implication | 7,560 FLOP per calibrated GFLOP/s | After the 604,800-block revocation window and 1.25x surge factor | | Revocation window | 604,800 blocks | Multiplier on the capacity bond | | Surge factor | 1.25x | On capacity stake while the cap is burst-ratcheted | | HARD tier capacity cap | 90% | Of summed governed device ceilings | > Do not size a miner's stake from the 0.01 coefficient alone. Query the runtime requirement for > the calibrated miner account. FLOP · Key protocol parameters › Verification and disputes ## Verification and disputes | Parameter | Value | Note | | --- | --- | --- | | Audit rate | 2.5% | About one session in forty; a governance dial, not a constant | | Challenge window | ~7 days | Bounded by DA retention; under review to shorten toward hours | | Response deadline | 2 hours | Silence defaults to a fraud verdict | | Dispute bond | 100 FLOP | Forfeited if the dispute is frivolous | | Fraud slash | 100% | Slash, eject, blacklist | | Liveness slash | 1-5% | Being offline | | TOPLOC commitment size | 258 bytes per 32 tokens | Retained on the DA layer | FLOP · Key protocol parameters › Distribution ## Distribution | Parameter | Value | Note | | --- | --- | --- | | Testnet miner pool | 1,200,000,000 FLOP | Allocated on verified activity | | Miner airdrop grant | 25% at genesis | The rest unlocks 1 FLOP per FLOP earned serving inference; no time limit | | Validator airdrop grant | Locked to the first halving | Then released one validator per day over 1,000 days | | Agent airdrop release | Not yet set | Locked balance can be spent only on compute | FLOP · Key protocol parameters › Status ## Status Draft whitepaper and draft design. The capacity-stake constants are under economic reconciliation; the challenge window is under review; transaction-fee routing is interim; the audit-fee earmark is documented but not wired; and the genesis distribution ceremony is not yet wired. The agent/broker and community-staker shares are **minted every block to protocol-held accounts and are not distributed to anyone yet** — no claim, delegation, or rebate path exists for either. Their distribution rules are still being designed. --- # Operator configuration reference Source: https://ask.flop.finance/docs/operator-config-reference # Generated operator configuration reference This is a source-indexed name reference, not a complete production configuration. Values, private seeds, and credentials are deliberately omitted. Check the version-matched source and role manual before running a command. ## Environment fields | Name | Source | Handling | |---|---|---| | CHAIN | infra/devnet/.env.example | configuration | | COMPOSE_PROJECT_NAME | infra/devnet/.env.example | configuration | | HOST_IP | infra/devnet/.env.example | configuration | | P2P_PORT | infra/devnet/.env.example | configuration | | PUBLIC_ADDR | infra/devnet/.env.example | configuration | | BOOTNODES | infra/devnet/.env.example | configuration | | GENESIS_SEED | infra/devnet/.env.example | private input | | DA_VALIDATOR_SEED | infra/devnet/.env.example | private input | | DA_PUBLIC_ENDPOINT | infra/devnet/.env.example | configuration | | DA_PORT | infra/devnet/.env.example | configuration | | RPC_BIND_IP | infra/devnet/.env.example | configuration | | RPC_PORT | infra/devnet/.env.example | configuration | | FLOP_CANONICAL_FINALITY_RECOVERY_LAG | infra/devnet/.env.example | configuration | | COMPOSE_PROJECT_NAME | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | WORKER_NAME | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | FLOP_WORKER_IMAGE | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | FLOP_BACKEND_IMAGE | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | FLOP_RPC | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | MINER_SIGNER_FILE | infra/devnet/devnet-ts/miners/miner.env.example | private input | | MODEL_NAME | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | OPENROUTER_MODEL_SLUG | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | MODEL_HASH | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | MODEL_CHECKPOINT_DIR | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | MODEL_PRECISION | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | TOPLOC_PRECISION | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | DECODE_POLICY | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | DECODE_POLICY_HASH | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | OPENAI_BASE_URL | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | SESSION_BIND_IP | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | SESSION_HOST_PORT | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | SESSION_AUTH_TOKEN | infra/devnet/devnet-ts/miners/miner.env.example | private input | | DA_URL | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | GHOST_MAILBOX_URL | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | GHOST_KEY_FILE | infra/devnet/devnet-ts/miners/miner.env.example | configuration | | GHOST_POLL_MS | infra/devnet/devnet-ts/miners/miner.env.example | configuration | ## Devnet node CLI flags - `--base-path` - `--blocks-pruning` - `--bootnodes` - `--chain` - `--file` - `--key-type` - `--listen-addr` - `--no-hardware-benchmarks` - `--node-key-file` - `--prometheus-external` - `--public-addr` - `--reserved-nodes` - `--rpc-cors` - `--rpc-external` - `--rpc-max-connections` - `--rpc-methods` - `--rpc-rate-limit` - `--rpc-rate-limit-trust-proxy-headers` - `--scheme` - `--state-pruning` - `--suri` - `--unsafe-rpc-external` - `--validator` ## Documented RPC calls - `author_hasSessionKeys` - `author_rotateKeysWithOwner` - `edge_flopnet` - `pallet_session` - `system_health` - `system_localPeerId` Source paths: `infra/devnet/.env.example`, `infra/devnet/devnet-ts/miners/miner.env.example`, `infra/devnet/node-entrypoint.sh`, `docs/runbooks/devnet-add-validator.md`. --- # Devnet network status Source: https://ask.flop.finance/docs/network-devnet # Devnet network status Status: development. Administrator-reviewed disposable devnet admission; public network identity and release receipt pending. A network is not ready for operator enrollment until its expected genesis, chain spec, bootnodes, public RPC/gateway, supported release, and admission authority are published and verified. --- # Testnet network status Source: https://ask.flop.finance/docs/network-testnet # Testnet network status Status: planned. Unavailable until published network identity, artifacts, and admission policy are verified. A network is not ready for operator enrollment until its expected genesis, chain spec, bootnodes, public RPC/gateway, supported release, and admission authority are published and verified. --- # Mainnet network status Source: https://ask.flop.finance/docs/network-mainnet # Mainnet network status Status: planned. Unavailable until published network identity, artifacts, and admission policy are verified. A network is not ready for operator enrollment until its expected genesis, chain spec, bootnodes, public RPC/gateway, supported release, and admission authority are published and verified.