[BOUNTY: 15 RTC] Implement /wallet/history endpoint (fixes #775, #886)

[Scottcjn]

Implement the /wallet/history Endpoint

Reward: 15 RTC

Background

The /wallet/history endpoint is documented in the API spec but returns 404. Multiple bug reports have been filed (#775, #886). Time to fix it.

Task

Add a /wallet/history endpoint to rustchain_v2_integrated_v2.2.1_rip200.py that returns transaction history for a given wallet/miner ID.

Expected Behavior

GET /wallet/history?miner_id=dual-g4-125&limit=50

Response:
{
  "ok": true,
  "miner_id": "dual-g4-125",
  "transactions": [
    {"type": "reward", "amount": 0.297, "epoch": 424, "timestamp": 1733..., "tx_hash": "..."},
    {"type": "transfer_in", "from": "founder_community", "amount": 10.0, "timestamp": ..., "tx_hash": "..."},
    ...
  ],
  "total": 42
}

Data Sources

• ledger table: all transfers
• epoch_rewards table: mining rewards
• balances table: current balance

Requirements

• Query both ledger and epoch_rewards tables
• Return unified, sorted-by-time response
• Support limit and offset pagination
• Handle unknown miner_id gracefully (empty list, not error)

Tags: api, bug-fix, flask, sqlite

[kalilynux655]

Proposal for /wallet/history Endpoint (fixes #775, #886)

I've reviewed the API spec gap and both bug reports. The fix requires implementing the missing /wallet/history route in rustchain_v2_integrated_v2.2.1_rip200.py with proper SQL queries across the ledger and epoch_rewards tables.

Approach: I'll add a Flask route that runs two parameterized SQLite queries — one against ledger for transfers (typed as transfer_in/transfer_out based on direction) and one against epoch_rewards for mining rewards — then merges and sorts results by timestamp before returning the unified JSON response. Pagination via limit/offset will be applied post-merge, and unknown miner_id values return an empty transactions array with "ok": true rather than a 4xx error, matching the spec.

Technical specifics:

• Parameterized queries to prevent SQL injection
• Input validation on limit (default 50, cap at 500) and offset
• tx_hash sourced from existing hash fields in both tables

Deliverable: Single commit adding the endpoint, with a brief test showing the three cases (known wallet, unknown wallet, pagination). Closes #775 and #886.

Timeline: Delivered within 24 hours. The 15 RTC reflects roughly 1-2 hours of focused work for a contained, well-scoped bug fix.

One question: does epoch_rewards store the miner_id directly, or is it joined through another table to resolve the wallet address?

[ApextheBoss]

PR submitted: #911

The existing endpoint only queried pending_ledger. My fix merges epoch_rewards (mining rewards) into the response, adds offset pagination, and wraps everything in the documented {ok, miner_id, transactions, total} envelope. Each transaction gets a type field (transfer_in, transfer_out, or reward) so callers can filter by source.

Unknown miner_id returns an empty array with ok: true rather than a 4xx, matching the spec.

[i010542]

I've implemented the changes in PR #913.

The fix extends the endpoint to include epoch mining rewards, adds offset pagination, and wraps the response in the standard {ok, miner_id, transactions, total} envelope.

[i010542]

Hi @Scottcjn! Quick question about payout for PR #913 — I don't have an RTC wallet yet. Could you create wallet i010542-rtc for me? I'll update the PR description with the wallet ID once it's set up. Thanks! 🌰