This page documents the current Arc Testnet MVP controls, known limitations, and the production-readiness work required before broader public use.
Current Arqis MVP invoice actions are routed through backend functions for user lookup, invoice creation, invoice retrieval, submitted payment marking, payment verification, and Telegram alert handling. This is stronger than direct client table writes, while still remaining testnet-only and not audited.
Public table reads are restricted from the previous open-read posture. Invoice data should be accessed through purpose-specific backend paths and participant-scoped lookups rather than broad public database reads.
Current MVP: backend function creates invoices for the connected seller flow. Production requirement: authenticated seller session with signed wallet binding.
Current MVP: invoice lookup is handled through scoped app actions. Production requirement: strict participant-only RLS, audit logs, and abuse monitoring.
Current MVP: backend verification flow handles paid-state updates. Production requirement: full chain, asset, recipient, amount, expiry, finality, and duplicate-use checks.
Current MVP: wallets register Arqis names for addressing invoices. Production requirement: stronger signed-message or SIWE-style proof for wallet ownership.
Current MVP: bot validation and alerts go through backend functions. Production requirement: encrypted token storage, rotation, disconnect/delete flow, and delivery monitoring.
Arqis remains an Arc Testnet MVP. It is not audited, should not receive mainnet funds, and still needs stronger wallet-auth binding, finalized RLS policy review, monitoring, and broader test coverage before public beta.
Add signed wallet authentication, finalize participant-only invoice access, ensure only backend verification can mark invoices as paid, add alerting for failed verification, and document failure/retry/refund handling.
