Crypto Booth

[iamlukethedev]

Note

High Risk
High risk because it introduces new wallet-connected trading flows (Phantom signing + on-chain submission) and new server routes that proxy third-party market/quote/swap APIs, which can impact security, reliability, and user funds if incorrect.

Overview
Introduces a new Solana Crypto Room immersive screen that embeds DexScreener monitoring, shows wallet holdings, maintains a local trade ledger/PnL report, and provides a native swap UI that requests quotes from Jupiter and requires Phantom signing.

Adds new Next.js API routes under src/app/api/crypto/* to fetch DexScreener pair telemetry and to proxy Jupiter quote/swap requests with input validation and no-store caching.

Extends the retro office world to include new crypto_board/crypto_terminal furniture (with new 3D models and animated “chart” textures), a furniture migration to replace the former art room with the crypto room layout, and new persistent crypto-room state (settings, approvals, ledger) stored in localStorage.

Adds Solana client utilities (@solana/web3.js) plus RPC endpoint configuration via NEXT_PUBLIC_SOLANA_RPC_URL, including RPC failover and token metadata enrichment via Jupiter/DexScreener.

^{Written by Cursor Bugbot for commit dbdf4b1. This will update automatically on new commits. Configure here.}

[iamlukethedev]

I don't think this PR should be merged as-is.

A few blocking issues stood out in the current implementation:

1. Approval expiry only runs once on mount. In useCryptoRoomState, pending approvals are marked expired inside a useEffect(..., []), so they do not age out as time passes unless the component remounts. The UI can keep showing stale pending approvals and enabled actions well past the TTL.

2. The per-agent daily loss guard is using room-wide PnL, not that agent's own results. runAgentCycle() compares each agent's dailyLossLimitUsd against report.totalPnlUsd, so one agent can pause all the others if the combined room PnL crosses the threshold.

3. The buy-side rationale can name the wrong token. buildAgentRationale() always says the agent wants to scale into pair.baseToken.symbol, but the trading logic uses the tracked token from getTrackedToken(...), which is not always the base token.

4. The new crypto API routes are unauthenticated public proxies around DexScreener/Jupiter, and /api/crypto/swap forwards client-controlled quoteResponse directly upstream. Even if that is acceptable for an MVP, it needs rate limiting / abuse controls before merge.

I’d also want more coverage here. Right now the tests only cover PnL math, not approval expiry, agent-cycle loss guards, or the new API routes.

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Approval expiry only checked once on mount

High Severity

The useEffect that marks pending approvals as expired uses an empty dependency array [], so it only runs once when the component mounts. Approvals created after mount will never transition to "expired" status as time passes. The UI continues showing stale pending approvals with enabled approve/reject actions, and the minutesRemaining countdown will reach 0m while the approval remains actionable — allowing users to load and execute long-expired agent proposals.

 

[cursor]

Per-agent loss guard uses room-wide PnL

High Severity

In runAgentCycle, the daily loss check compares report.totalPnlUsd (the room-wide PnL across all agents and the user) against the per-agent setting.dailyLossLimitUsd. This means a single agent's loss limit is incorrectly enforced against the entire room's aggregate PnL. An agent with zero losses can be paused because the user or other agents are losing, and conversely a losing agent stays active if the room is net profitable.

 

[cursor]

Redundant ternary yields wrong buy-side notional

Medium Severity

The notionalUsd computation for draft trades uses side === "buy" ? pair.priceUsd : pair.priceUsd — both branches are identical, making the ternary dead code. More importantly, for buy-side drafts, proposedInputAmountUi is a SOL amount, so multiplying it by pair.priceUsd (the tracked token's price) produces a meaningless USD value. This incorrect notional flows into totalVolumeUsd in buildCryptoReportSnapshot, which sums all trades including drafts.

 

[cursor]

You have used all of your free Bugbot PR reviews.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.