Mint Approval Escalation & Timeout Handling

[kelly-musk]

📋 Description

In a high-stakes financial system, silence is a risk. If a mint request is submitted but stays in a PENDING state for too long, it could indicate a bottleneck, an unavailable team member, or a missed opportunity. This issue implements SLA (Service Level Agreement) timers and Automated Escalation to ensure that minting operations remain fluid while maintaining strict oversight.

🎯 Objective

Automate the progression of mint requests that have stalled. If an approver does not act within a defined window, the system must either nudge them, escalate the request to a more senior authority, or expire the request to prevent "Stale" transactions.

🛠️ Technical Requirements

• SLA Configuration:
  • Warning Level: 4 hours of inactivity (Send reminder).
  • Escalation Level: 12 hours of inactivity (Notify next-tier manager).
  • Auto-Expiration: 24 hours (Mark as EXPIRED).
• Escalation Logic:
  • If a Tier 1 operator does not approve in 4 hours, automatically grant visibility/notification to a Tier 2 manager to take over.
  • Use a background worker (e.g., Sidekiq or Celery) to check the created_at timestamp of all PENDING requests every 30 minutes.
• Stellar Timebounds Integration:
  • Every mint request sent to the blockchain must include a Stellar time_bounds parameter.
  • If the transaction doesn't hit the ledger before the timebound expires, the system must move the internal record to a TIMEOUT_FAILED state to prevent accidental late execution.
• Notification Dispatcher:
  • Integration with Slack/Email to send "Stalled Request" alerts to the relevant department leads.

✅ Acceptance Criteria

1. Approvers receive an automated reminder if a request is pending for > 4 hours.
2. Requests older than 24 hours are automatically moved to EXPIRED status and cannot be approved without a re-submission (Implement Advanced Caching Strategies #123).
3. All escalation actions (nudge, re-assignment, expiration) are recorded in the Audit Trail (Create Dockerfile and Docker Compose Setup #117).
4. Logic prevents a transaction from being submitted to Stellar if the internal SLA has already expired.

🟠 Priority: High

Labels: Workflow-Optimization, SLA, Reliability

---

[drips-wave]

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

🧑‍💻 @marvelousufelix: 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 🌊