[#885] Add points API endpoints

[realproject7]

Summary

• GET /api/airdrop/status — campaign overview: dates, pool, milestones, mcap, total points/participants
• GET /api/airdrop/points?address= — user breakdown by action, streak info, referral info, estimated airdrop per tier
• GET /api/airdrop/leaderboard?address= — top 50 by total points, optional user rank lookup
• GET /api/airdrop/snapshots — weekly campaign stats from pl_weekly_snapshots

Files Changed

• src/app/api/airdrop/status/route.ts
• src/app/api/airdrop/points/route.ts
• src/app/api/airdrop/leaderboard/route.ts
• src/app/api/airdrop/snapshots/route.ts

Test plan

• GET /api/airdrop/status — returns campaign config + milestone status
• GET /api/airdrop/points?address=0x... — returns breakdown, streak, referral, estimates
• GET /api/airdrop/points without address — returns 400
• GET /api/airdrop/leaderboard — returns top 50 sorted by points
• GET /api/airdrop/leaderboard?address=0x... — includes userRank
• GET /api/airdrop/snapshots — returns weekly snapshots (empty array if none)
• All endpoints handle empty state gracefully

Fixes #885

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Apr 21, 2026 1:46am

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The endpoint set is close, but the campaign overview response currently reports incorrect summary data in at least two cases.

Findings

• [medium] totalParticipants is counting point rows, not unique participant addresses. As soon as one user earns multiple pl_points entries, /api/airdrop/status will over-report participant count relative to the ticket's campaign overview requirement.
  • File: src/app/api/airdrop/status/route.ts:40
  • Suggestion: count distinct addresses (or aggregate unique addresses first) instead of using a raw row count on pl_points.
• [medium] timeElapsedPercent is not capped at 100, so once the campaign end date passes the endpoint can return values above 100. That makes the status response internally inconsistent for the ended-campaign state.
  • File: src/app/api/airdrop/status/route.ts:20
  • Suggestion: clamp elapsed time to totalMs before computing the percentage, or explicitly cap the returned percent at 100.

Decision

Requesting changes because /api/airdrop/status currently returns incorrect campaign summary values for participant count and post-end elapsed percent.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The participant-count issue is fixed, but one of the two correctness problems from my previous review remains unresolved.

Findings

• [medium] timeElapsedPercent is still computed from unclamped elapsed time, so after CAMPAIGN_END the endpoint can still return values above 100.
  • File: src/app/api/airdrop/status/route.ts:19
  • Suggestion: clamp elapsed time to the campaign duration (or cap the returned percentage at 100) before serializing the response.

Decision

Requesting changes because /api/airdrop/status can still return an invalid elapsed percentage after campaign end.

[project7-interns]

Verdict: APPROVE

Summary

The /api/airdrop/status fixes are now in place: participant count is based on unique addresses and timeElapsedPercent is capped at 100 for post-campaign responses. The endpoint set otherwise matches the ticket scope.

Findings

• No blocking findings in the updated patch.

Decision

Approving from a code-review standpoint. The blockers from my previous reviews are resolved, and I do not see a remaining PR-specific code issue.