Anti-Cheat Precondition

An anti-cheat precondition is a plain way to describe something easy to overlook when designing a network that spot-checks work: random sampling and punishment only work as a deterrent if the party being checked has something real to lose, and can be reliably identified as the same party next time. Imagine a network that catches cheaters by re-running 5% of their jobs and comparing the answer. Against an anonymous actor who can throw away an identity the moment it gets caught and register a fresh one for free, that 5% sampling rate doesn't deter cheating at all: it just means the cheater gets away with roughly 95% of their attempts, forever, at zero cost. The spot-check only becomes a real deterrent once getting caught costs something the cheater can't walk away from: a forfeited stake, a broken legal contract, a reputation score tied to an identity they can't cheaply replace.

That's the precondition: identity that's durable and hard to fake, a stake or bond big enough to hurt losing, and, ideally, a legal agreement that adds consequences beyond the network itself. Put those in place first, and a statistical spot-check becomes a genuine economic deterrent. Skip them, and the same spot-check is closer to theater.

Where it comes from

The core mechanism this precondition supports, catching cheating in off-chain computation via random re-execution and a dispute step, rather than checking every single job (expensive) or trusting blindly (unsafe), traces to Truebit's 2017 "verification game" design, authored by Jason Teutsch and Christian Reitwiessner, one of the earliest concrete proposals for disputing off-chain computation on a blockchain. The modern DePIN and AI-compute space applies the same underlying idea: Gensyn's "Verde" protocol pairs probabilistic spot-checking with a refereed dispute for its decentralized ML-training network, and general-purpose DePIN GPU networks like io.net and Akash rely on the same optimistic-verification-plus- slashing pattern. None of this is Solidus's invention, Solidus composes it, and adds its own specific precondition list.

Solidus status

Solidus's compute network (see Verifiable Off-Chain Compute) requires four things before a GPU operator can receive a single live job: KYB (the operator is a vetted legal entity or known individual), a signed data-processing agreement (contractual consequences beyond the network), an on-chain stake bond (forfeitable on a confirmed cheat), and admission to a governance- controlled on-chain allow-list. All four are real, enforced checks in running code, not just policy documentation: an unregistered or un-admitted node is rejected outright.

What hasn't happened yet is proving those preconditions actually deter a real adversary. As of this writing, Solidus's live compute broker reports zero active registered operator nodes. The only registration this system has ever processed was Solidus's own single test node, running a mock inference backend, not an independent, adversarial third party with something real on the line. The precondition machinery is built and gated correctly; whether it holds up against a genuine bad actor trying to game it has not been tested, and that gap is stated here rather than implied away.

Proof you can run yourself: curl https://broker.solidus.network/health is live and public right now, and honestly reports the current node count: a stranger can check it directly rather than trust a claim in this entry. The allow-list gate itself, the ComputeRegister transaction rejecting any sender not already admitted, is visible in source in the public solidusnetwork/protocol repository's solidus-txns crate.