Inspiration
Most programming submissions show only the final code. They leave out the part that explains how the work actually happened: failed runs, corrections, environment changes, meaningful checkpoints, and the exact code state used for each test.
Proofline started from a simple question: what if that process could be packaged as portable, verifiable evidence without recording every keystroke or uploading private source code?
This can be useful for technical interviews, code review, and education, where teachers and students may want to inspect how a solution evolved—not only whether the final answer works.
What it does
Proofline is a local desktop app that creates tamper-evident process passports for programming work.
A creator can define a signed challenge with custom files and structured execution profiles. A solver opens it locally, edits the code in Monaco, saves meaningful checkpoints, runs controlled commands, fixes failures, and finalizes the session.
Proofline records:
- semantic-save checkpoints;
- file changes and reconciliations;
- successful and failed runs;
- exact executables, arguments, working directories, outputs, exit codes, and durations;
- profile adaptations made for the solver’s local environment;
- privacy-preserving focus, paste, and large-insertion signals;
- the exact workspace state used by every run;
- a signed final checkpoint.
The finalized session is exported as a portable .proofline passport. It can be verified completely offline and inspected through its timeline, runs, code states, diffs, profiles, provenance signals, and cryptographic details.
How I built it
Proofline is a Tauri 2 desktop application with a React and TypeScript frontend, Monaco for code editing, and Rust for every security-sensitive operation.
The Rust core handles canonical serialization, BLAKE3 commitments, Ed25519 signatures, event-chain replay, content-addressed workspace objects, SQLite-backed sessions, structured command execution without a shell, artifact export, offline verification, and passive checkpoint inspection.
The frontend communicates with Rust through a narrow typed command boundary. It does not receive broad filesystem, shell, clipboard, or network permissions.
Codex helped me implement and debug the Rust/Tauri architecture, protocol, verifier, tests, and UI. GPT-5.6 helped shape the product direction, privacy boundaries, threat model, documentation, and demo flow. I reviewed and tested the generated work throughout development.
Challenges I ran into
The hardest part was designing evidence that was useful without turning Proofline into surveillance software. Paste events record only counts, ranges, and timing—not clipboard contents, external applications, URLs, or individual keystrokes.
Another challenge was making focus and provenance events deterministic across restarts. A real runtime bug exposed a one-millisecond timing mismatch, followed by a focus-state issue caused by restarting while the durable session was still unfocused. I fixed both by introducing canonical monotonic timing, idempotent observation IDs, a serialized focus queue, and durable focus state reconstructed from the authenticated ledger.
Building a passive verifier was also challenging. It had to reconstruct trusted checkpoints, code states, and diffs without extracting or executing passport content.
Accomplishments that I’m proud of
- Fully offline challenge and passport verification.
- Arbitrary challenge files and structured multi-step execution profiles.
- No-shell execution with exact argv recording.
- Signed local profile adaptations.
- Intermediate code checkpoints with read-only code and diff inspection.
- Exact links between runs and the workspace state they used.
- Privacy-preserving provenance signals.
- Tamper rejection for modified, removed, or reordered evidence.
- A complete native Linux workflow.
What I learned
I learned that cryptographic integrity and human trust are not the same thing. Proofline can show that a recorded history is internally consistent and has not been modified undetectably, but it should not claim to prove identity, authorship, originality, or the absence of AI assistance.
I also learned how important deterministic representations are. Small differences in timing, serialization, path handling, or event order can invalidate an otherwise correct evidence chain.
What’s next for Proofline
The next steps are:
- stronger isolation for executing untrusted code;
- Windows and macOS support;
- support for more trusted executable families;
- portable continuation sessions;
- easier packaging and installation;
- optional public timestamp anchoring;
- integrations with development environments and educational workflows.
Log in or sign up for Devpost to join the conversation.