Security Overview
Contract security
The AruviPaymentGateway is deliberately small and built on audited primitives:
| Measure | Implementation |
|---|---|
| Reentrancy protection | OpenZeppelin ReentrancyGuard on every state-changing entry point |
| Safe token transfers | OpenZeppelin SafeERC20 |
| Ownership | Ownable2Step - ownership transfers must be accepted, preventing fat-finger loss |
| Emergency stop | Pausable - the owner can halt new payments; a pause can never touch funds |
| Token allowlist | only owner-vetted stablecoins (USDC, EURC) can settle payments |
| Checks-effects-interactions | state is updated before external token calls |
| Custom errors | precise, cheap revert reasons for every failure mode |
Non-custodial by construction
The gateway never holds user funds. Every payment is a direct transferFrom(sender → recipient) inside one transaction. There is no vault, no pooled balance, no withdrawal function - and therefore no honeypot.
What you approve
Using Aruvi means granting the gateway a USDC allowance. The gateway can only use that allowance in ways its code permits:
- moving funds from you when you call send/fulfill/execute
- moving a subscription charge from you to your chosen recipient, only when due, only for the authorized amount, and only if you haven't cancelled
- moving a refund from you back to the original sender, only when you call refund
You can revoke the allowance at any time with any token-approval tool.
Chain-level guarantees
Arc adds properties most chains can't offer a payments app:
- Deterministic finality - a settled payment cannot be reorged away
- Permissioned validators run by Circle's network partners - no 51% mining attacks
- Native USDC - no bridge-wrapped token risk on the settlement asset
Known trade-offs
See Threat Model for the honest list - including what the owner role can and cannot do, and what's public on-chain today.