api: surface fees_spent_today_stroops in GET /v1/wallets/:id/sponsorship so dashboard consumption bar can render

[Senorespecial]

Problem

PR #14 (open upstream as PR #31) shipped the dashboard wallet-card "Gas Sponsor" cell with the dot + Enabled/Off status indicator on the wallet home. The issue title also asked for a "daily budget consumption progress" fill-bar, but that bar cannot render today: GET /v1/wallets/:id/sponsorship does not return how much of the daily budget has been spent. The frontend already reserves the slot -- SponsorshipConfig.fees_spent_today_stroops?: number is typed as optional in frontend/src/lib/sponsorship.ts, and the cell in frontend/src/app/dashboard/page.tsx carries an inline comment explaining it will swap the cap-label for a fill-bar the moment the API exposes the value.

This issue tracks that backend change.

What the API should return

Extend crates/api/src/routes/sponsorship.rs::SponsorshipResponse with a field:

• fees_spent_today_stroops: i64 -- actual stroops the sponsor has paid today (UTC day boundary) for this wallet, summed over rows in sponsored_transactions where status = 'confirmed' and created_at >= today_utc. Use 0 when no rows exist (cheaper than Option<i64> and easier to consume).

The store crate already exposes Store::sum_sponsored_fees_today(wallet_id) -- reuse it inside get_sponsorship to populate the new field. The migrations gas_sponsorship_configs and sponsored_transactions continue to flow through unchanged.

Acceptance criteria

• SponsorshipResponse gains fees_spent_today_stroops: i64, defaulting to 0 when no rows exist today.
• Store::sum_sponsored_fees_today(wallet_id) is invoked from get_sponsorship and the result is plugged in.
• An integration test inserts a confirmed sponsored_transaction for the wallet, calls GET /v1/wallets/:id/sponsorship, and asserts the new field equals the inserted fee_stroops. A pending row should not be counted.
• Verify the sponsored_transactions query plan does not fall back to a full table scan -- the existing wallet_id, status, created_at covering index should serve the SUM.

Frontend change needed

After this lands, a PR #31 followup can simply replace the cap-label in frontend/src/app/dashboard/page.tsx:

{typeof dailyBudget === "number" && dailyBudget > 0 && (
  <p className="mt-0.5 text-[10px] text-muted">
    {formatXlm(dailyBudget)} XLM/day cap
  </p>
)}

with a small fill-bar showing min(100, spentToday / dailyBudget * 100)% width plus a fees_spent_today / dailyBudget XLM today label, gated on typeof spentToday === "number". Drop the optional ? from the type in frontend/src/lib/sponsorship.ts at the same time.

References

• PR feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 (open upstream): feat(dashboard): add gas sponsorship status indicator to wallet cards (#14) #31 -- frontend that already reserves the slot.
• crates/api/src/routes/sponsorship.rs::SponsorshipResponse -- current response shape (no consumption field).
• crates/store/src/lib.rs::Store::sum_sponsored_fees_today -- primitive already present; just call it.
• crates/store/src/models.rs::SponsorshipConfig -- store-side row model.
• frontend/src/lib/sponsorship.ts -- reserved fees_spent_today_stroops?: number.
• frontend/src/app/dashboard/page.tsx -- the cell + inline comment about the future fill-bar.

[Silver36-ship-it]

I would love to work on this professionally, please assign it to me

[Hassanmovic98]

The dashboard reserves space for a progress bar showing how much of the sponsor's daily budget has been spent, but the API doesn't return that data yet. The frontend is waiting on fees_spent_today_stroops.

I'll extend SponsorshipResponse with a single field: fees_spent_today_stroops as i64. In get_sponsorship, call Store::sum_sponsored_fees_today(wallet_id) and plug the result in. The field defaults to 0 when no rows exist. Only confirmed transactions count, only from today (UTC boundary).

The store method already exists. The query uses the existing covering index on wallet_id, status, and created_at, so no full table scans.

One integration test: insert a confirmed sponsored_transaction for the wallet, call GET /v1/wallets/:id/sponsorship, assert the new field matches the inserted fee amount. Verify a pending row doesn't get counted.

The frontend can then render the fill-bar against this value — min(100, spentToday / dailyBudget * 100)% width plus a label showing stroops spent out of the daily cap.

[Menjay7]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. Thank you!

[DTriple-p]

Hi there, I'd like to work on this issue.

[Dayz-tech-co]

Hello Maintainer, Can you pls assign this to me ?

[happyboy24]

CAN I WORK ON THIS PLEASE