Add Rate Limiting and Debounce on Transaction Form Submissions

[pragmaticAweds]

Context & Impact

Forms for stream creation, token distribution, and offramp transactions have no protection against rapid repeated submissions. A user can double-click the submit button or press Enter multiple times, triggering duplicate blockchain transactions. There is no debounce on submit handlers and no disabled state during transaction processing beyond a basic isSubmitting flag that may not cover all edge cases.

Why this matters: Duplicate blockchain transactions waste gas fees and can cause unintended double-payments. In the distribution flow, this could mean sending tokens twice to all recipients. In stream creation, it could create duplicate streams. These are irreversible on-chain actions.

Scope

• Disable submit buttons immediately on first click and keep them disabled until the transaction completes or fails
• Add visual loading state (spinner) to submit buttons during processing
• Prevent form re-submission via Enter key while a transaction is in flight
• Add a cooldown period after successful submission to prevent accidental rapid re-creation
• Ensure all three flows are covered: stream creation, distribution, and offramp

Implementation Guidelines

• Use React Hook Form's isSubmitting state consistently across all forms
• Disable the submit button with disabled={isSubmitting} AND add a spinner/loading indicator
• Add pointer-events-none CSS during submission as an additional guard
• For Enter key submission, check isSubmitting in the onSubmit handler before proceeding
• After success, add a 2-second cooldown before re-enabling the button
• Consider a global useTransactionGuard hook that manages submission state

Acceptance Criteria

• Stream creation button is disabled during transaction submission
• Distribution button is disabled during transaction submission
• Offramp button is disabled during transaction submission
• All submit buttons show a loading spinner during processing
• Double-clicking a submit button does not trigger duplicate transactions
• Pressing Enter rapidly does not trigger duplicate submissions
• A 2-second cooldown prevents immediate re-submission after success
• Failed submissions re-enable the button for retry

Getting Started

1. Review src/components/modules/payment-stream/PaymentStreamForm.tsx — check submit button state
2. Review src/components/organisms/DistributionForm.tsx — check submit handling
3. Review src/components/offramp/OfframpForm.tsx — check submit handling
4. Ensure all use isSubmitting from React Hook Form or mutation state
5. Add spinner component to all submit buttons during loading
6. Add pointer-events-none as CSS backup during submission
7. Test by clicking submit rapidly — verify only one transaction is created

---

PR Submission Guide

This section applies to every PR for this issue. Follow it exactly.

Before You Start

• Fork the repository first if you haven't already — all contributions must come from a fork
• Pull the latest main branch: git checkout main && git pull origin main
• Create your feature branch from main: git checkout -b feat/<issue-number>-form-rate-limiting

While Working

• Make atomic commits — one concern per commit, each commit must build
• Use Conventional Commits: feat(scope): description, fix(scope): description
• Keep your branch up to date: git pull origin main --rebase regularly

Before Submitting the PR

• Pull latest main and rebase: git checkout main && git pull origin main && git checkout <your-branch> && git rebase main
• Ensure the build passes: pnpm build
• Ensure linting passes: pnpm lint
• Record a screen recording of your implementation showing the feature/fix working in the browser. Attach it to the PR.

PR Requirements

• Link this issue in your PR description using Closes #<issue-number>
• Fill out the full PR template — Summary, What Was Implemented, Implementation Details, How to Test
• Attach your screen recording demonstrating the implementation
• Request a review from a maintainer

PRs without a screen recording or without a linked issue will not be reviewed. Failure to meet PR requirements may lead to PR rejection.

[israelolrunfemi]

@israelolrunfemi has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

I'm a versatile dev with 10+ yrs of experience

ℹ️ Repo Maintainers: To accept this application, review their application or assign @israelolrunfemi to this issue.

[drips-wave]

Congratulations, @israelolrunfemi! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on March 30, 2026.

🧑‍💻 @israelolrunfemi: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊