feat(competition): require Genesis (Level 2) for trade scoring

[biwasxyz]

Summary

Verifier now rejects competition trades from any sender below Genesis (Level 2). Previously the only sender-side check was "address in registered_wallets," which is effectively Level 1 (BTC+STX dual-sig via POST /api/register). Going forward, agents also need a verified or rewarded viral claim (POST /api/claims/viral) to score.

The intent: agents on the trading-comp leaderboard should be ones the network has already vetted twice — cryptographic identity proof and a public on-record claim. Bumps the noise floor and aligns the trading-comp gate with what the rest of the level system already calls "Genesis."

Behavior change

Sender state	Before	After
Not registered	sender_not_registered ❌	sender_not_registered ❌ (unchanged)
Level 1 (Verified Agent)	✅ scores	sender_not_genesis ❌
Level 2 (Genesis)	✅ scores	✅ scores (unchanged)

Applies to both ingestion paths: agent-submit (POST /api/competition/trades) and the SchedulerDO catch-up cron. No retroactive purge — pre-existing rows from Level 1 senders stay in swaps; only new submissions are gated.

Implementation

• New VerifyFailureCode value: sender_not_genesis
• senderEligibilityTier returns 'not_registered' | 'registered' | 'genesis' via a single D1 read joining registered_wallets + agents + claims. Predicate matches computeLevel() in lib/levels.ts:67-87 exactly — Genesis = agent row exists AND claims.status IN ('verified', 'rewarded').
• Single round-trip with a LEFT JOIN so we can produce the precise rejection code without doing two reads.
• Scheduler's CompetitionSchedulerRejectionReasons type + emptyRejectionReasons() get the new code so cron-path summaries report it correctly.

Tests

Vitest competition suite is green (68 tests):

✓ lib/competition/__tests__/d1-reads.test.ts     (18)
✓ lib/competition/__tests__/parse.test.ts        (13)
✓ lib/competition/__tests__/scheduler.test.ts    (10)
✓ lib/competition/__tests__/verify.test.ts       (27)

• D1 mock got a new genesis?: boolean option; defaults to true when registered: true so the existing happy-path tests pass unchanged
• One new test added for the sender_not_genesis path (registered: true, genesis: false → rejected with the expected code + reason mentioning Genesis)

Docs updated in the same PR

• app/llms.txt — new "Eligibility" callout in the Trading Competition section, plus the catch-up sweep note now correctly says "any Genesis-level registered wallet"
• app/llms-full.txt — new "Eligibility — Genesis Required" subsection under ## Trading Competition; the 422 response description on POST /api/competition/trades now enumerates both sender_not_registered and sender_not_genesis

Rollout impact

When this deploys, any in-flight Level 1 swap submissions will start getting sender_not_genesis. Anyone in that bucket needs to complete POST /api/claims/viral and wait for the claim to reach verified/rewarded status before their trades will score.

The catch-up SchedulerDO will also start emitting sender_not_genesis in its rejection-reason summaries — useful for spotting "how many Level 1 agents would have been counted under the old rules" at a glance.

Test plan

• Vitest suite green (68 tests; 1 new for the Genesis gate)
• After merge + deploy: submit a Level 1 agent's swap → 422 with code: "sender_not_genesis" and the Genesis claim hint in the reason
• After merge + deploy: submit a Genesis agent's allowlisted swap → 200 verified (unchanged path)
• Cron summary log includes a non-zero sender_not_genesis count if any Level 1 agents are still attempting swaps

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
❌ Deployment failed View logs	landing-page	4a4ecc2	May 13 2026, 02:19 PM

[arc0btc]

Adds the Genesis gate cleanly — upgrading from a single boolean to a 3-way tier enum is the right abstraction, the SQL is a single round-trip as promised, the test mock's genesis ?? true default keeps the existing suite clean, and the docs in both llms.txt files are unusually thorough. Agents consuming these endpoints will understand exactly what they need to do.

Two issues before merge:

---

[blocking] Multi-claim agent gets wrong tier (lib/competition/verify.ts:89–103)

The LEFT JOIN claims c ON c.btc_address = a.btc_address without GROUP BY or LIMIT returns one row per claim. If an agent has multiple rows in claims (e.g., one pending and one verified), .first() returns whichever row D1 picks — undefined order. An agent who IS Genesis could be classified as registered if a non-qualifying claim row appears first, silently blocking their trades.

Fix — aggregate with MAX() so you get exactly one row regardless of how many claims exist:

      SELECT
        1 AS registered,
        MAX(CASE WHEN c.status IN ('verified', 'rewarded') THEN 1 ELSE 0 END) AS genesis
      FROM registered_wallets rw
      INNER JOIN agents a ON a.stx_address = rw.stx_address
      LEFT JOIN claims c ON c.btc_address = a.btc_address
      WHERE rw.stx_address = ?1
      GROUP BY rw.stx_address

Alternatively, replace the LEFT JOIN with a correlated EXISTS subquery — same semantics, no multi-row risk, and arguably clearer intent. If claims has a unique constraint on (btc_address) that prevents duplicates, this is moot — but document that invariant, or be defensive either way.

---

[question] INNER JOIN on agents shifts the error code for partial-registration states (lib/competition/verify.ts:89)

The old check was SELECT 1 FROM registered_wallets WHERE stx_address = ?1. The new query INNER JOINs agents. An address present in registered_wallets but missing from agents (e.g., after a partial registration failure or data drift) previously passed the registered check and would now get a sender_not_genesis rejection — informative. Under the new query it returns null → tier = "not_registered" → sender_not_registered — misleading.

If both rows are always populated atomically by the registration flow, this can't happen. But if that invariant isn't enforced at the DB level, a LEFT JOIN agents would make the error message accurate for anyone in that state:

      FROM registered_wallets rw
      LEFT JOIN agents a ON a.stx_address = rw.stx_address
      LEFT JOIN claims c ON c.btc_address = a.btc_address

---

[nit] Cloudflare deploy just failed — the bot posted a failure comment seconds after the PR was opened. The code changes look syntactically valid and the SQL is well-formed, so this is probably infra/binding, but worth verifying before merge given the rollout impact described in the PR.

---

What looks good:

• SenderTier as a discriminated string union is the right model — cleaner than a nullable boolean pair
• Backward-compatible mock default (genesis ?? true when registered: true) keeps 67 existing tests passing untouched
• CompetitionSchedulerRejectionReasons and emptyRejectionReasons() updated consistently — the cron-path summary will report the new code correctly
• senderEligibilityTier function comment is thorough and references lib/levels.ts:67-87 as the canonical source — the WHY is documented

Operational note: We process competition trades in production. The INNER JOIN adds two table reads per submission, but D1 query latency isn't a bottleneck at this call site. The real operational concern is the rollout: any Level 1 agents actively submitting will hit sender_not_genesis immediately on deploy. The PR's rollout section is accurate — the hint message pointing to POST /api/claims/viral is the right UX for that case.

[whoabuddy]

Addressed the review blockers in 4a4ecc2:

• senderEligibilityTier now aggregates claim rows with MAX(CASE WHEN c.status IN ('verified', 'rewarded') THEN 1 ELSE 0 END) and GROUP BY rw.stx_address, so multiple claims cannot make a Genesis agent depend on arbitrary .first() row order.
• Switched the agents join to LEFT JOIN so a registered_wallets row with missing/drifted agents data is still classified as registered-but-not-Genesis (sender_not_genesis) rather than sender_not_registered.
• Added a regression assertion in verify.test.ts that the eligibility SQL keeps MAX(...), LEFT JOIN agents, and GROUP BY rw.stx_address.

Verification run in a clean PR worktree using the repo toolchain:

npm run test -- lib/competition/__tests__/verify.test.ts lib/competition/__tests__/scheduler.test.ts
# 2 files passed, 38 tests passed

Cloudflare bot has picked up the new commit and is currently in progress on 4a4ecc2.

[arc0btc]

Both blockers from cycle 1 are resolved. Approving.

What changed in 4a4ecc2:

• MAX(CASE WHEN c.status IN ('verified', 'rewarded') THEN 1 ELSE 0 END) with GROUP BY rw.stx_address — multi-claim aggregation is now correct; no more undefined row-order risk
• LEFT JOIN agents (was INNER JOIN) — a registered_wallets row with a missing agents row now correctly surfaces as sender_not_genesis, not the misleading sender_not_registered
• Regression assertions in verify.test.ts confirm the SQL keeps MAX(...), LEFT JOIN agents, and GROUP BY rw.stx_address — if the query drifts back, the test breaks

Remaining item (not blocking):
The Cloudflare bot posted a failure on the prior commit; whoabuddy's comment says a new build is in progress on 4a4ecc2. The code changes are syntactically valid and the SQL is well-formed — this is an infra/binding issue to resolve post-merge, not a code correctness issue.

On the docs:
The llms.txt / llms-full.txt updates are the right call — the 422 response matrix now enumerates both rejection codes and the eligibility prerequisites. Agents consuming the API will understand exactly what they need to do without reading source code.

This is clean work. The tier model ("not_registered" | "registered" | "genesis") is more honest than the old boolean and the single D1 round-trip is efficient. Ready to merge once the CF build green-lights.