GET /api/transactions returns hardcoded mock data: every wallet shows the same fake history

[nanaf6203-bit]

GET /api/transactions returns hardcoded mock data: every wallet shows the same fake history

Labels / Complexity: bug · High Complexity — High

Problem

The transaction-history API serves fabricated data. src/app/api/transactions/route.ts accepts any walletAddress query parameter and returns getMockApiTransactions() — a hardcoded list from src/lib/mockTransactionData.ts whose own doc comment says:

/**
 * Mock transaction history returned by GET /api/transactions.
 * Shared by the API route and MSW test handlers.
 */

The production service src/lib/transactionService.ts (line 55) fetches GET /api/transactions?walletAddress=..., so every wallet on the platform sees the same three fake transactions ("Luxury Downtown Penthouse", fixed hashes, fixed amounts) regardless of actual on-chain activity. Consequences:

• The transaction history UI is fiction. Users reviewing their purchase/transfer history see transactions that never happened, with fabricated hashes.
• The API and the test mocks are the same code path. MSW test handlers and the production route share getMockApiTransactions(), so tests cannot catch the fakery — the "expected" data is what production serves.
• Closed issue Feature: Batch token purchase for multiple properties #79's feature is partially cosmetic. The batch-purchase flow was built (see the separate checkout-simulation issue), and this API completes the illusion by reporting non-existent results.

Root cause

src/app/api/transactions/route.ts returns getMockApiTransactions() unconditionally; src/lib/mockTransactionData.ts is wired into the route instead of a real source (on-chain indexer or PropChain-BackEnd transactions API — the backend has a transactions module and test/e2e/transaction-lifecycle.e2e.spec.ts).

Why this is architecturally hard

1. The real source must be chosen. The frontend could query PropChain-BackEnd's transaction endpoints (the backend has src/transactions/) or an on-chain indexer; the contributor must pick the source of truth, define the ApiTransaction mapping, and handle pagination — a contract decision with PropChain-BackEnd.
2. Auth and address binding. The current route serves any walletAddress to anyone; a real implementation must decide whether history is public or caller-bound, and enforce it server-side.
3. Tests must be rewritten against the real path. MSW handlers currently reuse the mock; they must instead mock the chosen backend/chain source, so the production route and the test fixtures cannot drift back together.

Acceptance criteria

• GET /api/transactions no longer returns getMockApiTransactions(); it returns data from the chosen real source (backend API or indexer) for the requested wallet.
• The walletAddress parameter is validated (checksum/format) and, if history is caller-bound, tied to the authenticated caller.
• src/lib/mockTransactionData.ts is removed from the production route (it may remain for tests only, no longer shared).
• A test covers the new route with a mocked source: real data mapping, empty history, and (if applicable) unauthorized access.
• npm run typecheck, npm test, and npm run lint pass.

Out of scope

The checkout simulation (executeBatchPurchase, tracked separately) and backend transaction-API changes are out of scope.

Getting started

• src/app/api/transactions/route.ts — the mock-serving route
• src/lib/mockTransactionData.ts — the mock data to stop serving
• src/lib/transactionService.ts — the consumer (line 55)
• PropChain-BackEnd src/transactions/ — the likely real source

Commands: npm run typecheck, npm test, npm run lint.

Good first files to read: src/app/api/transactions/route.ts, src/lib/mockTransactionData.ts, src/lib/transactionService.ts.