How Aruvi Works
Aruvi is a thin, auditable smart-contract layer - the AruviPaymentGateway - on top of Arc's native USDC.
The flow of a payment
- Approve once. The first payment grants the gateway a USDC allowance. Every later payment is a single signature.
- The gateway moves USDC directly from sender to recipient - it never holds your funds.
- A payment record is created on-chain: a unique
paymentId, the parties, the amount, timestamp, and your memo (in the event log). - Arc finalizes the block deterministically - the payment can never be reorged or reversed by the network.
What the gateway adds over a raw transfer
A plain USDC transfer moves money. The gateway turns transfers into payments:
| Capability | Raw transfer | Aruvi gateway |
|---|---|---|
| Payment ID for receipts/verification | ❌ | ✅ |
| On-chain memos | ❌ | ✅ |
| Refunds tied to the original payment | ❌ | ✅ |
| Payment requests (links, QR, expiry) | ❌ | ✅ |
| Subscriptions | ❌ | ✅ |
| Batch payouts (up to 100) | ❌ | ✅ |
| Lifetime sent/received totals | ❌ | ✅ |
Requests, subscriptions, refunds
- Requests are stored on-chain with an optional fixed amount and expiry. Anyone with the link can pay; the contract enforces the amount and marks the request fulfilled, linking it to the resulting
paymentId. - Subscriptions record an authorization: subscriber, recipient, amount, and interval (minimum 1 day). When a charge is due, either side can execute it - the merchant pulls or the subscriber pushes. Cancel any time.
- Refunds can only be issued by the payment's recipient, only once, and only for the full amount - back to the original sender.
Trust model
- The gateway is non-custodial: funds move peer-to-peer inside a single transaction.
- Settlement tokens are allowlisted (USDC, EURC) so malicious tokens can't forge payment history.
- The contract is pausable by the owner for emergencies, but a pause can never take funds - it only stops new payments.
Next: Why Arc?