fix(vesting): surface all schedules per recipient in UI (#303) - Vest…

[blockchainrafik]

Closes #303

Summary

This PR updates the vesting UI to fully support multiple vesting schedules per recipient.

Although the vesting contract has supported indexed schedules since Wave 5 (#40), the frontend always assumed a single schedule (index = 0). As a result, recipients with multiple grants (for example, follow-on allocations after a completed vesting period) could only view and claim their first schedule.

The UI now discovers every schedule for a recipient using get_schedule_count() and renders each schedule independently, ensuring all vesting grants are visible and claimable.

---

Problem

The vesting contract stores schedules using (Address, index) and exposes:

• get_schedule_count(recipient)
• get_schedule(recipient, index)
• release(recipient, index)
• revoke(recipient, index)

The frontend ignored these indexed APIs and always operated on the default schedule (index = 0).

This caused several issues:

• Only the first vesting schedule was displayed.
• Additional schedules were invisible in the dashboard.
• Users could not claim tokens from later schedules.
• Admin release/revoke flows could only target the first schedule.

---

Changes

ClaimVesting.tsx

• Calls fetchScheduleCount() when looking up a recipient.
• Fetches all schedules (0..count-1) in parallel.
• Renders one vesting card per schedule.
• Displays an independent progress bar and claimable amount for each schedule.
• Each Release button passes the correct scheduleIndex to buildReleaseTx().

PersonalDashboard.tsx

• Replaces:

vestingSchedule: VestingScheduleInfo | null

with:

vestingSchedules: VestingScheduleInfo[]

• Updates the vesting lookup flow to:
  • Fetch the schedule count.
  • Fetch every indexed schedule in parallel.
  • Store all schedules for rendering.

VestingSection.tsx

• Maps over vestingSchedules.
• Renders one VestingCard per schedule instead of assuming a single schedule.

VestingCard.tsx

• Adds a schedule badge when multiple schedules exist.
• Displays labels such as:

Schedule 2 of 4

to distinguish multiple vesting grants.

VestingForm.tsx

Adds an optional Schedule Index field to both:

• Release form
• Revoke form

This allows administrators to target a specific schedule for a recipient.

useSoroban.ts

• Exposes fetchVestingScheduleCount().
• Threads scheduleIndex?: number through fetchVestingSchedule().

useTransactionSimulator.ts

• Threads scheduleIndex?: number through:
  • checkVestingRelease()
  • checkVestingRevoke()

The underlying simulator already supported indexed schedules; this change exposes that functionality through the hook.

---

Result

After these changes:

• ✅ All vesting schedules are discovered automatically.
• ✅ Every schedule is displayed independently.
• ✅ Users can claim tokens from any schedule.
• ✅ Dashboard and lookup views support multiple grants.
• ✅ Admin release and revoke actions can target any indexed schedule.
• ✅ The frontend no longer assumes schedule 0.

The UI is now fully aligned with the indexed vesting functionality already supported by the smart contract.

[drips-wave]

@blockchainrafik Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits