Proof Standards
ShipLock defines "proof" as evidence, not "truth." The protocol doesn't judge proof quality directly — watchers decide whether it's sufficient. But there are clear standards for what makes evidence credible.
Philosophy
A check-in should contain proofs that are hard to fake at scale. The community evaluates evidence, but the system is designed so that:
- Strong proof gets endorsed quickly
- Weak proof fails to reach threshold
- No explicit "reject" vote is needed — non-endorsement is rejection
Strong Proof Examples
These are the types of evidence that typically earn endorsements:
| Type | Examples |
|---|---|
| Release artifacts | Versioned deployments, tagged releases, changelogs |
| Demos | Video walkthroughs + timestamp + live URL |
| Code | GitHub commits, PRs, merged branches with diffs |
| Documentation | Spec updates, API docs, architecture diagrams |
| On-chain evidence | Transaction links, deployed program IDs, state changes |
| Benchmarks | Performance results with methodology and reproducible setup |
| Screenshots | Timestamped UI screenshots showing new features |
Weak Proof Examples
These rarely earn endorsements and signal low effort:
| Type | Why it's weak |
|---|---|
| "We're working on it" | No verifiable evidence |
| Vague screenshots | No context, could be from any time |
| "Coming soon" statements | Future promises, not delivered work |
| Unverifiable claims | No links, no artifacts, no way to check |
| Recycled content | Same evidence submitted in previous cycles |
Best Practices for Builders
- Be specific — "Deployed v2.1 with new routing engine" beats "Made progress on DEX"
- Include multiple proof types — A commit link + a demo video is stronger than either alone
- Make it verifiable — Live URLs, public repos, on-chain transactions
- Show diffs — What changed since last check-in
- Timestamp everything — Screenshots should show dates, deploys should have version numbers
How Watchers Evaluate Proof
Watchers endorse based on their judgment. The protocol encourages honest validation through:
- Economic incentives — Rewards only for endorsing accepted check-ins
- Diminishing returns —
sqrt(stake)prevents whales from rubber-stamping - Minimum diversity — Multiple endorsers required, not just one
- Public transparency — Every endorsement is on-chain and auditable
What the Protocol Does NOT Do
The protocol does not:
- Score proof quality on a scale
- Use AI to evaluate deliverables
- Allow admin overrides on proof sufficiency
- Penalize watchers for not endorsing
The subjective decision — "Is this good enough?" — is always human, but always backed by stake.