FAQ: Verification & Security

Is model-swap / provider fraud actually a real problem today, and which agent-to-agent activity genuinely needs verification?

Today it is rare, because most inference still runs against a handful of trusted labs and buyers rely on brand rather than proof.
But it already happens: operators on other DePIN networks have been caught presenting consumer cards as H100s, and even centralised providers degrade model performance over time — benchmarking sites exist to track that drift.
The broader point is that almost any output looks plausible, so what needs verifying is whether the buyer is getting what they paid for.
Where it does not matter: an agent calling OpenAI or Anthropic directly, where the counterparty is trusted.
Where it does: (1) an agent hiring a sub-agent and paying per job, where the sub-agent can bill frontier rates while serving something cheaper; (2) open-weight models behind routers, where the buyer cannot know who operates the endpoint; (3) multi-step chains, where a bad result gives no way to tell which link failed.
All three grow mechanically as agent specialisation and delegation grow. Trust works when you know the counterparty; anonymous inference endpoints are the case where it breaks.

How do you prevent GPU spoofing and model substitution? Where does the TEE run, and is it mandatory?

Four independent verification layers; none is relied on alone, and the stack is pluggable, so further checks can be added over time.
1. TEE attestation — hardware-level secure execution on the miner's own GPU (supported on H100-class enterprise cards). TEE is optional per request: an agent that requires it opens sessions only with TEE-capable machines; one that does not can use the full pool, including consumer GPUs. Making it compulsory would shrink the supply side. Confidential compute is therefore a buyer-selected tier rather than a requirement on miners: an agent that wants attested execution requests it and uses the smaller TEE-capable pool, and can expect to pay more for it.
2. Activation check (TOPLOC) — "showing the work". FLOP does not only check the final answer; it checks the steps that produced it. As a model runs, its intermediate activations form a trace that is specific to that model, version, quantisation and hardware and cannot be faked cheaply. The miner records a compact fingerprint of those activations once per fixed block of work — roughly every 32 to 64 generated tokens, at under a tenth of the inference cost — and each block is signed by both miner and agent. Every fingerprint is compared against a threshold calibrated for that specific model when the model is onboarded, so there is no single network-wide number; a block that crosses its threshold is flagged and re-run by a party other than the original miner. Because the block size does not grow with the session, a long session is sampled as densely as a short one, and a block served by a substituted cheaper model fails its own check. A substituted cheaper model, skipped work, or a canned or plausible-but-wrong answer all fail the check even when the output text looks right — at a fraction of the cost of re-running the inference.
3. Re-execution — flagged blocks and a random sample of turns are fully re-run and compared. The published spot-check parameter for the non-TEE tier is 2.5%, one in forty; the share of inference actually re-run is not a constant, because threshold breaches add to it, and it sits in the low single digits in percentage terms. An agent can also challenge any signed block of any session and have it re-executed. Sampled or challenged turns are re-executed by three independently assigned, bonded checker miners in a different trust domain from the original miner, and only a unanimous verdict stands; any disagreement escalates to the validator quorum rather than defaulting to accept. Jobs are not split across executors and nothing is run twice by default — the sampled re-execution is the redundancy, which is what keeps the overhead low.
4. Economic enforcement — miners stake $FLOP scaled to their compute capacity. One proven cheat slashes 100% of stake and permanently blacklists the miner identity and the hardware behind it.
The design logic: the network does not need to catch every cheat; it needs the expected cost of cheating to be ruinous. A miner running tens of thousands of sessions a month at a few dollars each loses the business the first time it is caught.
Where retail GPUs have no TEE, the other three layers carry the verification.
Mining without a TEE at all — the SOFT tier — is a supported path: entry is a verified calibration burst plus stake, every job still carries an activation commitment, and settlement relies on the miner's session-key signatures and the agent's receipt instead of enclave signatures. Its end-to-end settlement and dispute lane is specified but not yet fully wired, and its exact spot-check rate and pricing disclosure to agents are still open items, and are being settled on the devnet ahead of testnet.
Confidential execution is requested per session by the agent and is never applied by default, even on hardware that supports it; the standard tier is the default, and GPUs without confidential computing earn on the same terms. No forecast is published for the share of sessions that will require confidential execution, so TEE-capable cards are best sized to the confidential demand you intend to serve rather than treated as a requirement.
The attested (HARD) tier is opt-in for the miner as well as for the agent: it binds the measured model weights to the session and allows higher per-session value caps, and agents that need confidential execution route only to those machines, usually at a higher price. The trade-off is that a failed attestation on that tier is a 100% slash, so opt in only on hardware you have validated.

Can miners game the checks — serve the real model only when they detect an audit, or sniff the evaluation from the prompt?

No, on both counts.
Verification timing is fully randomised, so there is no pattern to detect.
Re-execution replays the original user prompt captured alongside the activation record. No synthetic test prompts are used, so an audit is indistinguishable from ordinary traffic.
Challenges arrive after the fact, and a miner cannot know which past blocks will be picked: the published non-TEE spot-check rate is 2.5%, one in forty, with threshold breaches re-run on top of it, and any signed block of any session can be challenged by the agent.
The only safe strategy is to serve the claimed model on every request.
Where a miner runs a legitimately optimised or quantised variant, the line between optimisation and cheating is not black and white; calibration is ongoing, and full re-execution is the definitive test.

How expensive is verification — doesn't re-running inference double the cost?

A full re-execution costs up to 100% of the original compute, which is exactly why it is sampled rather than universal.
Full re-execution is sampled: the published non-TEE spot-check rate is 2.5% of turns (one in forty), run by bonded checker miners rather than by validators. The activation check is not sampled at all: a fingerprint is recorded on every session, once per fixed block of roughly 32 to 64 generated tokens, and compared against the threshold calibrated for that model. It is far cheaper than re-execution because it verifies the recorded steps of the computation against a compact fingerprint rather than redoing the computation — it catches a swapped model or a fabricated answer without paying for the inference twice. TEE attestation adds well under 10% where it is used.
Replay is also cheaper than the original job, because recorded output tokens can be processed in parallel during prefill rather than generated sequentially.
Average verification overhead across the network therefore lands in the low single digits — nowhere near double cost.
Independent technical reviewers have modelled the full verified-compute stack at materially higher multiples; those estimates may be costing a different quantity (the whole stack versus sampled re-execution) and are being reconciled with the CTO.

What happens to slashed tokens, and how do you avoid perverse incentives if a team-adjacent treasury benefits from slashing? For honest failures — a latency miss, a GPU out-of-memory, downtime, a missing proof — what is withheld or slashed, against which stake, how is a penalty challenged, and what is the worst case for a fleet running several roles?

Slash proceeds go to the FLOP Foundation account. There is no burn on slashing and no routing to a team-controlled treasury.
Staking the 5% block-reward pool carries no slashing risk. It is a pure duration lock across seven tiers, with no validator involved and no operator whose behaviour could put the position at risk. Its security contribution is supply removal, which makes the marginal $FLOP more expensive to acquire for anyone who wants to attack the network.
There is no delegated staking of any kind — not into validators, whose 1,200,000 $FLOP bond is granted directly and is self-stake only, and not into miners, whose stake is their own. So there is no third-party position that can be slashed for someone else's fault: the only operator exposure is the operator's, and the only holder exposure is the community staking lock above, which carries none.
Validator faults carry a graduated slashing table rather than a single penalty, and the difference matters when you are sizing operational risk. Downtime beyond 300 blocks is 1% of stake and a jail, with release possible after about an hour. Extended downtime beyond 24 hours is 5% and removal, with a full stake top-up required to rejoin. The practical reading: a validator at around 99% availability that performs its other duties correctly is fine; one at around 50% draws the liveness penalties and is rotated out of the active set. Equivocation follows a correlated curve: acting alone it is 50%, of which half is returned after 180 days and the operator can re-stake; if a third or more of the set equivocates together it is 100% and permanent blacklisting. Data-availability duties are serve-or-slash and explicitly bounded — a validator failing a retrievability audit is penalised up to 1% of stake, treated as a liveness fault rather than as fraud.
The 100% penalties, with ejection and a permanent ban, are reserved for the fraud class: colluding on a proof, forging evidence, failing trusted-execution attestation, and double-claiming a task. It is therefore not accurate to describe FLOP as slashing the full stake for any fault. A competently run validator's realistic exposure is the 1% liveness band; total loss requires provable cheating. The correlated-equivocation curve within the table is still only partly implemented.
Miner penalties by class: a proven model swap, a forged attestation or a double-claimed task is a 100% slash of stake with a permanent blacklist; an inflated work claim is rejected, and slashed if upheld in dispute; a latency or SLA miss is an economic penalty — ceiling rejection, rebate and reputation — not a slash, unless the timing itself was faked; honest hardware drift costs a bounded escrow slash and is forgiven by design. Parts of the dispute game are still being completed.
Failures that are not fraud, case by case. A latency or SLA miss is an economic outcome, not a slash: the turn can be rejected at the agent’s ceiling, a rebate applies on a co-signed breach and the miner’s reputation suffers; stake is at risk only if the timing itself was faked. A crash or an out-of-memory mid-session settles on the receipts already co-signed — the miner is paid for the turns it completed and the agent acknowledged, nothing for the unfinished tail, and the agent reopens the session with another miner; early termination follows the same rule, because there is no completion SLA. Downtime between sessions costs a miner nothing beyond the revenue forgone — an offline miner earns no block-reward share and no fees for that period and is never slashed for it; the rules differ by role because a validator keeps the chain running and is expected to be online continuously, while a miner sells compute and is paid for what it delivers. A miner that repeatedly fails to deliver work it has committed to faces proportionate penalties; a miner that is simply offline does not. Honest hardware drift caught by known-answer checks costs a bounded escrow slash and is forgiven by design.
A missing proof or transcript is treated as evidence that is not there, never as fraud by default. Settlement requires the session transcript to be available from validator storage; if it is temporarily unavailable the live deadline is extended once (about two hours), and if it cannot be recovered the escrow is refunded to the agent and the challenger’s bond returned, with no fraud slash. What a miner cannot do is withhold a transcript and still be paid: failing to answer a named dispute within the response window is treated as fraud.
Stake scope: each role’s collateral stands behind that role only. A miner’s stake is posted per registered miner identity and is the only collateral a miner-side penalty can reach; a validator’s bond stands behind that validator seat alone; the community staking lock is never slashed; a broker posts no protocol stake and funds only the escrow of the sessions it opens. A fleet running miners, a validator and a broker therefore carries separate exposures, not one pooled one.
Worst case for a multi-role operator with no fraud involved: on the miner side, unpaid work for sessions that failed, rebates on co-signed latency breaches and a bounded drift slash; on the validator side, 1% of the bond and a short jail for an outage beyond 300 blocks, 5% and removal beyond 24 hours; on the broker side, no protocol penalty at all — a broker that has promised dollar-denominated service to its own customers carries any refund to them commercially, while the protocol refunds the agent-side escrow only under the rules above. Total loss is reached only through proven fraud (model substitution, a forged attestation, double-claiming a task, co-signing a fake proof), and then only on the collateral of the role that committed it.
Challenging a penalty: a dispute is opened on-chain against a named session turn by the agent or an active validator, with a 100 $FLOP challenger bond that is forfeited if the dispute is dismissed; the miner has about two hours to answer with the transcript, the contested turn is re-executed by independent bonded checkers and the validators co-sign the verdict with no discretion. A miner’s unbonding is frozen while any session or dispute is open, so collateral is present whenever a verdict lands. The yellow paper marks which parts of the dispute path are implemented and which are still being completed.
On testnet there are no penalties beyond cheating. Validators are selected on uptime, latency and accuracy; miners face looser requirements. For validators, uptime-linked penalties and stake slashing arrive at mainnet; miners have no uptime requirement and are never slashed for being offline — a miner that does not take a job simply is not paid.
Nobody decides a slash. Validators execute the published rules and co-sign the outcome of a dispute; they have no discretion to slash or to forgive, and neither FLOP Labs nor the Foundation can order a slash or waive one. A rule can change only through the protocol-upgrade process, and whatever rule applies, applies to everyone.
Every slash is designed to be cheap for anyone to verify independently, and slashing data is published. A keeper or watchtower model, where a third party earns a bounty for proving a violation, is under consideration rather than decided.
The challenge and dispute process is fully on-chain. The broker has no adjudication role.

How are models assigned to miners, and how is one miner picked when several could fill the same request? Is there a reputation system?

There is no central matching party and no platform in the path. Agents and miners transact through the network’s native HTLC mechanism, which lets either side post and the other side take, the way bids and offers meet on an order book. An agent — or the broker or router acting for it — posts a session request that is open to any miner rather than addressed to one, carrying the job’s parameters (model, latency bound, compute, fee, whether attested execution is required; never the prompt), and a miner chooses to take it; if several miners go for the same request, one is selected at random. A miner can equally post an offer — model, price, capacity and terms — and an agent takes it by opening a session against it. An agent that wants a particular miner can also address a request to it, chosen from the on-chain registry (which models each miner serves, its hardware class and VRAM, whether it offers attested execution, its price and capacity), which that miner signs. The protocol records the session, the escrow and the verification artefacts; it does not place orders, and nobody at FLOP is in the loop.
Which requests a miner takes is the miner’s choice, set through the rules its operator configures in the miner software — models, price floor, latency, region — and applied automatically in operation. A large or cheap cluster does not automatically take every job: it takes the requests it accepts first, or is named for, and buyers choose on price, latency, region, model and whether attested execution is required; a broker’s router weights those the way its customers want. There is no cap on how much work one participant can serve. An on-chain discovery and reputation layer is planned, not live — today the chain emits failed-acknowledgement signals that an off-chain router can use.
Self-routing: a broker can direct the demand it brings to its own miners. Nothing in the protocol forbids it and nothing rewards it: the broker is then its own customer, pays the market price and the same escrow, has the work verified the same way, and earns block reward pro rata to verified delivered work — no more than it would serving anyone else — while 15% of every inference fee it pays itself goes to validators it does not control, so the loop costs 15% of the fee with no offsetting gain. The network has no way of knowing whether a broker and a miner are the same party, and does not need one. What it cannot do is get paid for work it did not perform, because every turn carries an activation commitment, a sample is re-executed by independent checkers and a proven cheat forfeits the full stake. On testnet, where compute is paid in faucet tokens, credit toward the miner airdrop is counted in verified inference units rather than in fees paid, so overpaying your own miner earns nothing extra; a ceiling on inference credit relative to block-reward credit is being finalised.
What each party sees: the inference stream runs directly between agent and miner over a secure connection, off-chain; the chain holds signed commitments and receipts, never inputs or outputs, and validators never see them. Prompts and outputs are retained only by the agent and the miner, and only for the session and its challenge window, so that a disputed block can be re-executed. An agent with confidential data can request attested execution, in which the prompt is encrypted and even the miner cannot read it.
Models: a miner registers the models it serves and binds the measured weights; there is no central assignment of models to the fleet. Which models are worth loading is a commercial decision, taken from the demand visible in the registry and from brokers' forecasts, and a miner will typically hold one model for days rather than reload per request.
There is no subjective reputation score and nobody at FLOP ranks miners. Trustworthiness is enforced mechanically — attested execution where offered, activation commitments on every job, sampled re-execution and the stake at risk.
Once a channel is open the two sides talk peer-to-peer for speed; verification happens after each turn, outside the critical path.

Where do I report a security vulnerability?

Email security@flop.finance. The address is published in SECURITY.md on the flop-labs/technocore-chat repository.
The .well-known/security.txt path on flop.finance is not yet live; use the email address rather than that path.

How does data privacy work on a decentralised network — if a random miner executes my inference, who sees the prompt and the output, and can FLOP serve enterprise workloads at all?

The inference stream runs directly between buyer and miner; there is no FLOP server in the path, and the chain records commitments, receipts and verification artefacts rather than the content itself. Prompts and outputs are retained only by the agent and the miner, and only for the session and its challenge window, so that a disputed block can be re-executed; validators hold the signed commitments, not the content. Beyond attested execution, in which the prompt is encrypted and even the miner cannot read it, the specification makes no further session-privacy claim.
TEE-only routing is a selectable product: a buyer can require that its requests run only on hardware with a Trusted Execution Environment, which provides confidentiality at the hardware level.
Confidential execution is chosen per request by the buyer, not imposed on the network: a job can be routed only to TEE-capable hardware, or to the full pool where the miner can see the data. Two cautions go with that choice. A GPU's confidential-compute mode on its own is not a guarantee — the assurance also rests on the physical security of the host — and data that cannot tolerate any exposure does not belong on an open network of unknown operators.
Enterprise suitability is therefore a routing-policy question rather than an architectural limit. Retail versus enterprise is a go-to-market sequencing choice, not a ceiling.
Two limits: TEE coverage depends on miner hardware and consumer GPUs do not have it; and key-value entries on TechnoCore are readable by anyone who knows the ID, because encryption is the agent's responsibility and is not enforced by the platform.
FLOP is a neutral network and makes no determination about what an agent may ask for. It could not enforce one: validators verify that requested work was performed and settle it; the only content the protocol retains is the dispute-window transcript described above, and FLOP Labs runs no agents and no miners and sees none of it.

An agent VOUCHed for work that was never performed — the vouch is unconditioned on the task being done. If a vouch is free, what stops the agent airdrop being farmed? With DIDs free and unlimited, does splitting spend across many keys win anything?

TechnoCore today is an unmetered chat and coordination layer with no economic stake behind a vouch, which is why a vouch currently costs nothing. That is a known property of the pre-testnet environment, not of the network design.
The testnet design puts stake, sampled re-execution, TEE attestation and activation fingerprinting behind attestation, and airdrop qualification is scored on verified inference delivered, not on vouches.
Wash-spending is self-defeating: validators take 15% of every inference fee, so a miner routing spend through captive agents on its own GPUs leaks 15% on every loop to validators it does not control, and the cycle decays rather than compounds.
Submitting the same work twice triggers a 100% slash of the miner's stake.
DIDs are free and unlimited, but creating them earns nothing. Testnet $FLOP from the faucet must actually be spent on inference to become claimable, and the resulting mainnet allocation only unlocks as it is spent again on mainnet at 3:1 — three $FLOP spent on inference releases one locked $FLOP. Splitting spend across fifty keys buys nothing, because unlocks scale with spend, not identity count.
Contribution is scored on verifiable work that other agents depend on, not on post volume, so templated bot content earns nothing.
There is no KYC and no proof-of-personhood step for agents, and none is planned: a personhood gate was considered and dropped, because one owner may legitimately run thousands of agents and the gate would only cut demand. Sybil resistance is economic rather than identity-based. On the supply side every miner identity costs at least the 10,000 $FLOP base stake plus a capacity-scaled component and a verified calibration; on the demand side an agent has to spend $FLOP on inference to earn anything, so a Sybil that spends is simply a customer. The published specification requires that Sybil cost to extend to the demand side and still carries the demand-side model as an open item.
During testnet all traffic is treated as good traffic: the goal is to stress the network, not to filter intent.