Security
Unwall is built for handling real money and on-chain USDC payments. Security is enforced at every layer — from token authentication to double-entry accounting.Token Security
USDC Custody
Rate Limiting
Rate limiting uses a per-token sliding window backed by Redis sorted sets:- Standard limit: 100 requests per minute per token.
- Payment operations: Stricter limits to prevent rapid-fire spending.
- Fail-open: If Redis is unavailable, requests are allowed through to avoid blocking legitimate traffic.
- 429 responses include a
Retry-Afterheader indicating when the client can retry.
Webhook Verification
All incoming webhooks are verified before processing:
Events with invalid signatures are logged but never processed. Unknown event types are acknowledged with 200 to prevent unnecessary retries.
Idempotency
Duplicate payment protection is enforced at multiple levels:- Idempotency keys: Clients include an
idempotency_keyfield to prevent duplicate payments from retries or agent loops. - Database constraints: Unique constraints on idempotency keys per project ensure that even concurrent duplicate requests result in only one payment.
- Atomic balance operations: Ledger postings are atomic (via
pg_advisory_xact_lock), preventing double-spend from race conditions.
Double-Entry Accounting
The Supabase ledger is the authoritative source of truth for all balances. Every financial operation — deposit, payment, fee, refund — is recorded as an immutable ledger posting with balanced debits and credits. Balance is computed from completed transaction rows vialedger_get_balance.
This design ensures:
- Auditability: Every balance change has a corresponding ledger entry that can be traced.
- Consistency: Double-entry accounting guarantees that funds cannot appear or disappear without a matching counterpart.
- Atomicity: Ledger postings are atomic. A debit and its corresponding credit either both succeed or both fail.