Launch contest with a leaderboard
Launch challenges — leaderboard, tiered rewards, and points that can be defended
Runs a time-boxed launch competition: a leaderboard people check twice a day, and rewards paid out in tiers when the clock runs out. Kept apart from affiliate tracking because the two fail in different ways.
A feature of the Playground
This is a feature of the Vibe Coder Playground. It runs inside the Playground, with its audit record and its caveats beside it.
The mistake it removes
The one that decides whether any of this is worth running: WHERE A POINT CAME FROM. The obvious source is the analytics pixel, and the pixel cannot do this job — it is bring-your-own-database (see the workbench's ANALYTICS.md), so the business owner controls the store the events land in and can manufacture points for whoever they like, with no way for a promoter to tell. So `source` is a stored column and `trust` is derived from it in exactly one function, never accepted from a caller. Scoring reports verified and unverified totals separately rather than folding them together. Two more that bite quietly: reward tiers come in two shapes that must not be mixed — top-N tiers NEST, so a third-place finisher is owed the Top 10 rewards and the Top 50 rewards and the base reward, while rank RANGES partition the board and are refused if they gap or overlap — and under-delivering to your best promoters is the worst available mistake; and delivery must be idempotent, because a retried delivery run that re-sends a perpetual license grant cannot be undone by apologizing.
What you still have to do
The feature cannot own your secrets, your host or your legal obligations. This is the part it deliberately does not claim.
- THE VERIFICATION MODEL IS NOT SETTLED. `trustOf()` currently trusts a platform-run redirect and a payment-processor webhook, and distrusts the pixel and manual entry. Whether you run that redirect is a hosting decision nobody has made yet (workbench roadmap ph68tsk20). Until you do, the honest position is that prize-carrying positions get a human check before delivery — which is what `prizeEligibility()` returns rather than silently passing.
- Nothing here delivers a reward. `pendingDeliveries()` tells you what is owed; sending the file, the link or the license grant is your host application's job, and it must record the delivery so the idempotency constraint has something to bite on.
- Auto-verifying that a promoter's video actually meets the brief is NOT in this block. Transcript checking is only reliable where a platform exposes captions, and a model's read of tone is assistive rather than authoritative — see the workbench's ph68tsk19.
- Nothing here ANIMATES the finale. `podiumData()`, `chartRaceData()` and `vaultData()` return the data each of the three celebrations needs and not one pixel of motion; the reveal order, the frame budget and which chest a person is in are decided here so the renderer holds no rules, but the screens themselves are your host application's job (the workbench tracks its own as ph68tsk11's remainder). `MODES` is the list to build against, and 'none' is a real mode — an owner who turns the animation off still gets a results page.
What lands in your project
node
- node/index.js
- node/terms.js
- node/tiers.js
- node/points.js
- node/leaderboard.js
- node/profiles.js
- node/offers.js
- node/marketing.js
- node/compliance.js
- node/evidence.js
- node/celebration.js
- node/redirect.js
- node/selection.js
- node/actions.js
- node/waves.js
Pure functions over injected data — no store is assumed, no external package is imported, and every function is callable with plain objects. The only imports are relative and inside the block: leaderboard.js, celebration.js and points.js take the rank-window rule from tiers.js so "is rank 11 in this tier" has ONE answer rather than four. index.js is a barrel; take the whole thing or just the module you need. Every file the barrel re-exports is listed here, because block-check copies exactly this list into a bare directory and a barrel importing a file the manifest forgot fails on the first import.
sql
- sql/challenge.sql
Five tables. point_events stores source AND trust so a historical row keeps the trust it was scored under; the UNIQUE on reward_deliveries is what makes a retried delivery run safe.
What you supply
- termSingular — what this business calls one promoter (default 'affiliate')
- termSlug — the URL segment — chosen once, then locked, because promoters have shared the links
- pointSources — which sources are allowed to score; points.js trustOf() is the authority and leaderboard.js mirrors it byte-for-byte because a block cannot import across its own files — change BOTH, and the kit's structural test fails if you don't
Get it
Download the Playground See pricing
A feature of the Vibe Coder Playground.
Questions
- Is Launch contest with a leaderboard audited?
- No. No full audit has been run against this block yet, which is not the same as a pass. What is verified about it is listed on this page, and what is not is listed beside it.
- What do I still have to do myself?
- THE VERIFICATION MODEL IS NOT SETTLED. `trustOf()` currently trusts a platform-run redirect and a payment-processor webhook, and distrusts the pixel and manual entry. Whether you run that redirect is a hosting decision nobody has made yet (workbench roadmap ph68tsk20). Until you do, the honest position is that prize-carrying positions get a human check before delivery — which is what `prizeEligibility()` returns rather than silently passing.
- How do I get this?
- It is a feature of the Vibe Coder Playground. Download the Playground, and see the pricing page for what each plan includes.
All Playground features · Free code blocks · Learn to build from zero · The coding guide