The two-proof settlement model
DASHH's headline differentiator. Every paid view is bracketed by two cryptographic proofs of engagement — a baseline at join time and a final reading at settlement. Payout = the verified delta.
Why two proofs, not one?
Single-proof schemes (the obvious approach) have a fatal flaw: a creator can game them by submitting at peak views, regardless of whether those views were real over the campaign window. They can also submit immediately and then delete their post.
Two proofs solve this by anchoring both ends of the window. We pay only for views accrued between the two readings, AND we require the post to still exist at the final reading. View-bots, deletion attacks, and screenshot fraud all break.
The Join Proof
- Submitted shortly after the creator joins the campaign.
- Anchors three things: the creator's wallet ↔ social handle binding, the baseline view count, and the post's caption.
- Goes through the same 13-rule verification pipeline as the Final Proof.
- On success, the participation transitions from
awaiting_join→active.
The Final Proof
- Submitted inside the 7-day window after the campaign's
endsAt. - Reads the final view count.
- Must reference the SAME social handle as the Join Proof (handle switches are a disqualification).
- Must show view count ≥ Join Proof (a drop indicates deletion fraud).
- On success, settlement runs. On miss, the participation is forfeited.
The math
Δv = finalProof.viewCount - joinProof.viewCount payout (per_view) = min(Δv * cpv, remainingBudget) payout (top_performer) = creatorPool, if I have max Δv payout (split_top_n) = creatorPool / N, if I am in top N payout (equal_split) = creatorPool / numVerifiedCreators
Why a 7-day final window?
Long enough to absorb time-zone differences and creator availability, short enough to keep escrow capital efficient.
Mathematically: the window is the period during which the platform's on-chain liability is bounded by budget × (1 - platformFee). Beyond 7 days, residual capital should be deployable elsewhere, so we close the window.
Code references
src/lib/settlement.ts—routeProofByWindow()decides Join vs Final based on timestamp,readyToSettle()determines if a campaign is past its window.src/lib/payouts.ts—computePayoutForProof()implements the four payment models.src/app/api/v2/proofs/route.ts— the proof submission handler that drives the state machine.