How Verification Works: The Two-Phase Proof System
One of the most common questions we receive is: "How do you verify that a bug report is legitimate without a human reviewer?" The answer lies in our two-phase proof system. In this post we break down exactly how it works.
Phase 1: Reproduction
When a debugger submits a bug report, they include a reproduction script—a small, self-contained program that demonstrates the bug. Phase 1 executes this script inside a sandboxed environment against the target project.
The sandbox is a locked-down container with no network access and strict resource limits. It installs the project at the pinned version, runs the reproduction script, and captures the exit code along with stdout and stderr. If the script exits with a non-zero code (indicating a failure), Phase 1 passes.
- Timeout: 120 seconds maximum execution time
- Memory: capped at 512 MB
- Network: fully disabled
- Filesystem: read-only outside the working directory
Phase 2: Validation
Passing Phase 1 only proves that something failed. Phase 2 answers a harder question: is the failure a genuine bug in the target project rather than a flaw in the reproduction script itself?
Phase 2 re-runs the reproduction script against a known-good baseline of the project (for example, the latest release that passed its own test suite). If the script passes on the baseline but fails on the target version, the system concludes that the failure is caused by a regression in the project, not by the script.
Additional heuristics are applied to guard against edge cases: scripts that depend on randomness, timing, or external state are flagged for manual review rather than auto-approved.
On-Chain Settlement
When both phases pass, the verifier node signs a proof attestation and submits it to the D2E smart contract on Solana. The contract validates the attestation, marks the bug report as verified, and transfers the USDC reward from the project escrow to the debugger's wallet in a single atomic transaction.
Because everything is recorded on-chain, anyone can independently audit the verification history for any project. Transparency is a first-class feature, not an afterthought.
Looking Ahead
We are continuously improving the verification pipeline. Upcoming work includes support for multi-language projects, longer-running integration tests, and a dispute resolution mechanism that lets project owners challenge false positives. Stay tuned for more technical deep dives.