Speedrunning isn’t just about beating a game; it’s about proving you beat it in a way that’s clean, reproducible, and auditable. For decades, communities have trusted human observers, forensic analysis, or careful study of game rules to decide whether a run is genuine. But as speedruns migrate online, into cloud play and automated replays, the question becomes sharper: can we cryptographically prove that a speedrun happened as claimed, even when the game runs on someone else’s hardware? A paper from City College of New York, led by Hayder Tirmazi, dives into that problem with the blunt honesty of a security audit and the stubborn curiosity of a gamer who won’t settle for handwaves.
The authors wave a running example in front of us: a small, open-source game they call lilypond. Mano, the game’s avatar, can walk, sprint, jump, and squish enemies; there are coins to collect and traps to avoid. The point isn’t to build the slickest game, but to create a testbed where the authors can explore how you might cryptographically certify that a particular sequence of inputs and game states really occurred. They don’t just ask whether a signature could be attached to a run; they ask how that signature could survive the realities of interactive play, web browsers, cloud servers, and the messy reality of human behavior. The paper’s core claim is almost paradoxical: you can, in a precise sense, attach authenticated evidence to a speedrun by encoding information into the very pixels that a viewer sees, but doing so raises deeper questions and stubborn open problems about what security guarantees really mean when humans are in the loop.
To set expectations clearly: this work comes out of the City College of New York and is authored by Hayder Tirmazi. It uses the lilypond project as a concrete, transparent example and dogs the thorny boundary between cryptography and live, interactive human play. The goal isn’t to declare victory over fraud in speedruns, but to map the terrain where cryptographic ideas can help, and to chart the gaps where they cannot yet reach.
What makes the paper compelling is not just the clever tricks, but the admission of limits. The authors walk us through a spectrum of fraud techniques—splicing together perfect-jump footage, tweaking the game’s logic or memory, simulating inputs with frame-perfect precision, or manipulating timers to slow down or speed up perceived actions. Each cheat targets a different layer of the system: what the viewer sees, what the game processes, or what the clock counts. The central ambition is to build a system that can cryptographically certify authenticity under some realistic constraints, while honestly acknowledging where the constraints loosen and where the guarantees fray. It’s not a fairy-tale of perfect proofs; it’s a map of where proof-of-play is possible, and where it isn’t, given the messy reality of untrusted hardware and human behavior.
What it means to “prove” a speedrun in a world of machines
The paper begins with a helpful reframing: what counts as a speedrun is a stream of timestamped inputs and rendered frames. The authors formalize a game G as something that receives keystrokes, evolves its internal state, and outputs a sequence of screenshots. In their notation, a speedrun is a set of timestamped pairs (time, image) that capture the player’s progress. If a run is to be proven authentic, you need to trust the relation between the inputs, the internal state, and the recorded frames. That, in turn, is where cryptography promises a sheen of certainty: a digital signature attached to a log of play that becomes hard to forge without detection.
Two architectural worlds—the thin client and the thick client—frame how much control an attacker might have over the system. In a thin client, the game runs on a server and the player’s device only sends inputs and receives video. That makes tampering with the game’s binaries or memory harder for an attacker; they don’t get to poke at the game’s interior. In a thick client, the game runs locally, and the attacker can, in principle, manipulate timers, memory, or the very keystrokes that the game uses. The paper formalizes these two environments as security games, a style of synthetic test that helps us reason about what a cryptographic construction can and cannot guarantee under different adversarial capabilities.
One of the paper’s most vivid moves is to treat the proof of authenticity as something you prove against an oracle—a black-box that represents either the thin-client or the thick-client reality. In the thin-client world, the only thing an attacker controls is the input stream; the server handles rendering and internal state. In this setting, the authors show that you can modify the game’s transition function to produce a fixed, signed record that can be checked after the run. They sketch a trick: you encode signatures about the game’s trace directly into the pixels of the screenshot. A verifier then checks those pixel-embedded signatures. It’s a clever, almost photographic approach to authentication: you stamp a run’s evidence into the very image that accompanies it, making it hard to repurpose a fraudulent log without breaking the signature’s math.
But the authors don’t pretend this is a silver bullet. They prove a conditional theorem: if you’re dealing with a thin client and you’re allowed to modify a small number of pixels per frame (think of it as a tiny, controlled fingerprint embedded in each screenshot), you can achieve a form of (t, negl(λ))-secure authentication, assuming standard cryptographic primitives like one-way functions. It’s a meaningful step, but it also reveals the fragility of the idea: the more you constrain what you can alter, the more you rely on the robustness of the fingerprinting scheme. And crucially, a key caveat remains: this kind of security does not cover the more insidious threat of simulated inputs, where an attacker replays or fabricates input streams entirely, a problem the authors explicitly call out as open and unsolved.
From signatures in pixels to the hard limits of the battlefield
The heart of the matter, as the authors remind us, is not just about clever encoding but about where the security model ends. The paper presents four concrete fraud techniques that anyone designing a speedrun verification system should worry about: splicing, where you surgically cut and paste only the shard of footage that looks perfect; logic modification, where you alter the game’s code or memory to change physics or scoring; simulated input, where every keystroke is synthetic rather than human; and timestamp skew, where the clock used by the game or the system is manipulated to distort the cadence of actions. Each technique lives at a different layer of the stack—from the viewer’s eye to the game’s engine to the hardware and operating system—and each challenges a different security assumption.
Here the lilypond running example becomes a lab bench for showing what an authenticated run could look like and, just as important, where it fails to cover the messy realities of human play and untrusted hardware. The authors’ experiments are honest: they try to detect dishonest runs by analyzing the keystroke logs, the interarrival times of inputs, and the entropy of input streams. They find that even with sophisticated logging, a clever attacker could produce a dishonest run that passes inspection by reordering or pruning inputs to mimic a human’s improved performance. In other words, empirical indicators that seem plausible—timing patterns, input distributions—can be simulated, especially when an attacker has access to honest runs to study and imitate. The paper uses this as a reminder that empirical detection is not the same as cryptographic proof.
And then there’s the thick client, the most permissive and dangerous environment. If an attacker controls the game binary, memory, timers, and input devices, meaningful guarantees become exceptionally hard, if not impossible, to achieve. The authors candidly label this an open problem in the security literature: can you ever truly prove a speedrun is authentic when the player’s machine could be lying to you at every level? Their conclusion is both sobering and perfectly human: the more power you grant to the attacker, the less likely a cryptographic proof of play will be, at least with current techniques and reasonable assumptions. The paper doesn’t deliver a final answer; it maps the boundary lines where a proof of play might exist, and where it simply cannot hold up without a radical shift in trust assumptions or hardware integrity guarantees.
What this does—and does not—mean for the future of verified play
So what should readers take away from this exploration? First, the work is a thoughtful reminder that “proof of play” is a much more nuanced concept than it might appear. A speedrun isn’t just a timeline of clicks and frames; it’s a complex interplay of human behavior, software design, hardware performance, and the environment in which the game runs. You can imagine a spectrum: on one end, a fully trusted, tamper-proof box that runs the game; on the other end, a casual browser-based run that could be hacked in minute ways. The paper positions cryptographic verification as a tool that can operate in the middle ground—where you trust some components, constrain others, and embed evidence into verifiable structures like signed logs or pixel fingerprints. It’s not a panacea, but it’s a principled way to raise the bar for fraud in a world where the line between “play” and “processing” is increasingly blurry.
Second, the work anchors a crucial conversation about cloud gaming and online competitions. If we want fair esports or credible speedrunning communities in a future where games are streamed from distant data centers, we’ll need ideas that are both practical and robust against a range of threats. The thin-client approach shows one path forward: limit what an attacker can influence by moving the game’s critical work to a server you control. But even there, the authors acknowledge, simulated inputs remain a stubborn loophole. The reality is that a robust ecosystem for verified play will likely require a mix of cryptographic tactics, trusted hardware, and transparent auditing—none of which alone suffices.
Finally, the work invites humility. It is, in the authors’ own words, a kind of proof of work without a full proof of play. They present a clever construction, prove what they can, and then lay out a clear set of open problems. The hope is not to close the door on verification but to widen the doorway—provide a scaffold that future researchers can build on, refine, or even overturn with a new idea. In that sense, the paper is less a final verdict and more an invitation: a map for researchers who want to bridge cryptography and human-in-the-loop gaming, a reminder to guard against assuming security where there is only hope, and a nudge toward a future where integrity tools keep pace with the way people actually play games, on real machines, in real time.
As readers, we’ll watch the field with the same curiosity that fuels speedrunning itself: a careful eye for the loopholes, a readiness to adopt clever new tools, and a willingness to redefine what counts as a fair finish line. The authors—at CCNY—offer a thoughtful, sometimes wry, but always rigorous look at the frontier where cryptography meets play. They show us that the dream of a perfectly verifiable speedrun is not just about signing a log or embedding a signature in a pixel. It’s about asking the harder questions: what do we mean by authenticity when humans are part of the system, and how much security can we reasonably demand before the bar becomes unreachable? In that tension lies the real drama of verified play—and the reason this work matters beyond the pages of an academic preprint.
In the end, the lilypond project and its peer-in-the-lab spirit reflect a broader truth: we’re still figuring out how to trust digital records of human action. The paper’s careful exploration, honest admission of limits, and invitation to the community to push further are exactly what makes it engaging—not just for cryptographers or game designers, but for anyone who cares about fairness, transparency, and the tiny, imperfect ballet of players and machines that define modern gaming.
