Merge back main to dev

[Corantin]

No description provided.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
markee	Ready	Preview, 💬 5 unresolved ✅ 1 resolved	Jul 9, 2026 7:58pm

[gaston-review]

Gaston Review

Verdict: Comment

Score: ██████░░░░ 6/10

Pull Request Summary

This PR merges main back into dev, bringing in ~22,000 lines across 100+ files: new v1.2 and v1.3 smart contracts (Leaderboard, LeaderboardFactory, Markee), numerous admin KV migration endpoints, a major rewrite of the home/marketplace/owners/create-a-markee pages, new ETH price and embed APIs, network-wide view tracking, and factory address updates.

Review Summary

🟡 Warning — Markee.sol: ETH permanently locked when beneficiary is address(0)
In Markee.pay(), when beneficiary == address(0), the code sets beneficiaryAmount = msg.value but then skips the transfer (guard: beneficiary != address(0)). Meanwhile revNetAmount stays 0, so _routeRevNet is a no-op. The ETH sits in the contract with no withdraw function and no receive()/fallback(). setBeneficiaryAddress() allows setting to address(0) with no validation, so this state is reachable. Even if it requires an admin mistake, in a financial contract this is a footgun worth closing.

🟡 Warning — Markee.sol: tx.origin in event emissions is unreliable
setMessage() and setName() emit events with tx.origin instead of msg.sender. tx.origin can differ from the actual caller in meta-transaction, account-abstraction, and multi-hop contract call scenarios. This produces misleading event data. The Leaderboard contract already knows the actual caller (msg.sender in updateMessage/updateName) — the Markee should log that instead.

🟡 Warning — Reactions bulk-fetch endpoint has no pagination limit
GET /api/reactions with no params loads ALL markee addresses from KV (smembers), then fires a parallel hgetall for each one. As the dataset grows, this will hit memory and timeout limits. Should add pagination or a cap on the number of markees loaded.

The architecture direction is solid — centralizing RevNet config at the factory level is a good move. But the Markee.sol payment logic has a latent fund-locking bug when beneficiary is address(0), and the use of tx.origin in events is a code smell that should be cleaned up. The frontend rewrites are massive but largely cosmetic. For a merge-back PR of this size, the real risk is in the contracts — those deserve focused scrutiny before deployment.

📌 6 inline comments
🟡 Warning: 3 · 🔵 Suggestion: 3

---

_{🔍 Reviewed by Gaston}

[gaston-review]

🟡 Warning: When beneficiary == address(0) and revNetEnabled is true, the entire msg.value is assigned to beneficiaryAmount but the transfer is skipped (line 108 guard), and revNetAmount remains 0. ETH is permanently locked. Consider: (1) require beneficiary != address(0) in pay(), or (2) route 100% to RevNet when beneficiary is unset, or (3) add a zero-address check in setBeneficiaryAddress().

[gaston-review]

🟡 Warning: tx.origin is used here and in setName() for event emission. This is unreliable under account abstraction, meta-transactions, and EIP-3074. Since the Leaderboard's updateMessage() already validates msg.sender == markee.owner(), pass the caller as a parameter to setMessage() instead of relying on tx.origin.

[gaston-review]

🔵 Suggestion: If offset >= markees.length, end - offset underflows (Solidity 0.8 reverts with a generic panic). Add if (offset >= markees.length) return new address[](0); for a cleaner caller experience. Same issue in LeaderboardFactory.getLeaderboards().

[gaston-review]

🔵 Suggestion: setBeneficiaryAddress allows setting to address(0) without validation, which would trigger the fund-locking scenario in Markee.pay(). Consider adding require(_newBeneficiary != address(0)) to match the pattern used for setAdmin.

[gaston-review]

🟡 Warning: This bulk-fetches ALL reactions across ALL markees in parallel with no pagination. As the dataset grows, smembers returns unbounded results and Promise.all(hgetall...) fires unbounded concurrent KV calls. This will eventually hit Vercel function timeouts or memory limits. Consider adding a limit parameter or paginating the index.

[gaston-review]

🔵 Suggestion: The origin stored in KV comes from new URL(request.url).origin in the connect route. In standard Vercel/Next.js deployments this reflects the server's own origin, so it's safe. But if the app ever sits behind a reverse proxy that rewrites Host headers, this becomes an open redirect. Consider validating siteOrigin against an allowlist of known deployment origins before redirecting.

[gaston-review]

Gaston Review

Verdict: Comment

Score: ██████░░░░ 6/10

Pull Request Summary

This is a massive merge-back from main to dev, pulling in cumulative production changes: new v1.2 and v1.3 contract versions (Leaderboard, LeaderboardFactory, Markee) with factory-level RevNet routing, all frontend and API routes migrated to v1.3 addresses, a Superfluid Season 6 system with boosted 5x multipliers, gamed-leaderboard filtering, multiple one-shot admin migration endpoints, USD price computation, embed widget rewrite, and extensive UI overhauls across the account, ecosystem, marketplace, and create pages.

Review Summary

🟡 Warning — ETH locked when beneficiary is address(0) and revNet is enabled
In Markee v1.2 and v1.3 pay(), when revNetEnabled == true and beneficiaryAddress == address(0), the condition !revNetEnabled || beneficiary == address(0) is true, so beneficiaryAmount = msg.value and revNetAmount = 0. Then the beneficiary transfer is skipped (guard: beneficiary != address(0)), and _routeRevNet receives 0 and does nothing. The ETH is stuck in the Markee clone with no receive(), fallback(), or withdrawal function. The v1.3 factory doesn't enforce non-zero _beneficiaryAddress in createLeaderboard(), and setBeneficiaryAddress() also has no zero-check. Admin-only blast radius, but still a path to permanent fund loss.

🟡 Warning — Duplicated GAMED_ADDRESSES set across two API routes
The same 13-address gamed-leaderboard blocklist is hardcoded identically in ecosystem/leaderboards/route.ts and superfluid/leaderboards/route.ts. When a new gamed address is discovered, both files must be updated in lockstep. This will drift — extract to a shared constant.

🟡 Warning — Track endpoint trusts client-supplied leaderboardAddress for boost multiplier
POST /api/superfluid/track now applies a 5x points multiplier based on the leaderboardAddress field in the request body. This value is entirely client-supplied and not verified on-chain. An attacker can submit any boosted leaderboard address alongside their real txHash to inflate their points by 5x. The cron job has the same multiplier logic but derives the leaderboard address from on-chain event logs, making it accurate.

🔵 Suggestion — tx.origin used in Markee events
Both v1.2 and v1.3 Markee contracts emit MessageChanged and NameChanged events with tx.origin as the changedBy parameter. While not a security issue (it's only in events, not access control), it can be unreliable with account abstraction and meta-transactions. Consider using a parameter passed from the Leaderboard instead.

The contracts are well-structured with proper access controls, and the migration from per-leaderboard to factory-level RevNet config is a sound design. I see one edge-case fund-locking path in the Markee payment logic, duplicated gamed-address lists that will drift, and the track endpoint accepting unverified boosted multiplier claims. Since this is a merge of already-deployed code, these are worth tracking rather than blocking.

📌 5 inline comments
🟡 Warning: 3 · 🔵 Suggestion: 2

---

_{🔍 Reviewed by Gaston}

[gaston-review]

🟡 Warning: When revNetEnabled == true and beneficiaryAddress == address(0), this condition routes the full msg.value to beneficiaryAmount but then skips the beneficiary transfer (line 108 guard). revNetAmount stays 0, so _routeRevNet is a no-op. The ETH is permanently stuck — this contract has no receive(), fallback(), or rescue function. Consider: (1) requiring non-zero beneficiary in createLeaderboard and setBeneficiaryAddress, or (2) when beneficiary is zero and revNet is enabled, route everything to RevNet instead.

[gaston-review]

🔵 Suggestion: If offset >= markees.length, then end gets clamped to markees.length, and end - offset underflows (Solidity 0.8 will revert). Safe but confusing — add if (offset >= markees.length) return new address[](0); before the subtraction.

[gaston-review]

🟡 Warning: The leaderboardAddress is taken directly from the client request body and used to determine the 5x boosted multiplier. Nothing stops a caller from submitting a boosted address that doesn't match their actual transaction. The cron job correctly reads the address from on-chain event logs. Consider either verifying the leaderboard address on-chain against the txHash, or removing the boost from this endpoint and only applying it via the cron.

[gaston-review]

🟡 Warning: This gamed-addresses set is duplicated verbatim in superfluid/leaderboards/route.ts. Extract to a shared module (e.g. lib/gamed-addresses.ts) to avoid the two lists drifting when new entries are added.

[gaston-review]

🔵 Suggestion: Same getMarkees offset-underflow edge case as v1.3: when offset > markees.length, the array allocation underflows and reverts. Add an early return for offset >= markees.length.