⚡ Pre-launch honesty: RocketForge Pay core service is in preview — XRPL invoice MVP is building, later rails are planned. This page tracks what we run today (site + waitlist API) and the public networks we rely on. "Network healthy" ≠ "rail live."
Website & waitlist API
Operational
rocketforgepay.app availability, waitlist signup backend, HTTPS/TLS validity, failed-request rate.
Latency ~120msUptime 24h 100%
XRP Ledger
Healthy
Public ledger advancing normally; node endpoints reachable; ledger close time & propagation within norms.
Last ledger close ~4s
Flare network + FTSO
Healthy
Chain progressing; FTSO price endpoints responding with current data.
Oracle freshness ok
XRPL invoice rail (RocketForge)
Building
Our XRPL invoice MVP: create → hosted page → destination tag → payment matching → receipts. Under active development for the first merchant cohort.
Expected with XRPL MVP
RLUSD / USDT0 rails
Planned
Token settlement through RocketForge invoicing rails — roadmap. (Token may exist on a public network while our rail is not yet enabled.)
Status Planned
Bank rails via partner
Planned
Card / ACH / Interac settlement through a partner — referral model, partner terms apply.
Status Planned
Status definitions
- Operational — service or network responding normally for its current role.
- Degraded — mostly reachable but checks failing, slow, or inconsistent; payment behavior may be unreliable.
- Down — unavailable or unable to meet its current role.
- Maintenance — planned work underway; temporary interruption expected.
- Not live / Planned — not enabled for RocketForge settlement yet. Pre-launch default for roadmap rails.
What we check & how often
| Check type | Frequency | What it confirms |
| Website uptime | Every 5 min | Public site responds correctly over HTTPS. |
| Waitlist API health | Every 5 min | Endpoints reachable, returning expected responses. |
| On-chain ledger checks | Every 5 min | XRP Ledger / Flare advancing; public endpoints healthy. |
| Oracle (FTSO) checks | Every 5 min | Price endpoints respond, current data, acceptable freshness. |
| Rail availability | On deploy/config change + 5-min cycle | Whether XRPL, Flare, RLUSD, USDT0 can be accepted through RocketForge Pay today. |
| Incident correlation | Continuous | Repeated failed checks trigger an incident or status change. |
Checks are designed to monitor availability without requiring RocketForge to take custody of funds. Some on-chain/oracle checks run only in dev or staging contexts before production rails are live.
Incident log
DateComponentStatusUser impact / resolution
No incidents logged. — entries appear here automatically when checks fail.
About this page
- Generated automatically from monitoring checks; updates may lag a few minutes.
- If a component is missing, it is not currently publicly monitored or not enabled as a RocketForge settlement rail.
- Public status is for operational transparency and does not replace confirmation inside an invoice flow.
- For status questions or incident reports: contact email TBD