Architecture
Aruvi is four packages sharing one contract at the center.
Components
| Package | What it is | Stack |
|---|---|---|
contracts/ | AruviPaymentGateway + tests | Solidity 0.8.27, Hardhat, OpenZeppelin 5 |
frontend/ | The Aruvi web app | React 19, Vite, wagmi v2 + viem, Tailwind 4, framer-motion |
sdk/ | aruvi-arc for merchants | TypeScript, Rollup (ESM/UMD/React builds) |
docs/ | This site | Docusaurus 3 |
Design decisions
Non-custodial gateway. The contract never holds funds; every operation is a direct transferFrom between the parties within one transaction. There is nothing to drain.
ERC-20 interface only. Arc exposes USDC natively (18 decimals) and as ERC-20 (6 decimals) over one balance. Aruvi uses the ERC-20 interface exclusively - standard allowance flows, standard decimals, no dual-interface pitfalls.
Events as the data layer. PaymentSent carries token, amount, and memo, and Arc never reorgs, so logs are trustworthy at one confirmation with zero reorg handling. The app reads them through the ArcScan (Blockscout) indexer - full history and block timestamps in a single request - because the public RPC caps eth_getLogs at a 10,000-block range; a chunked RPC scan remains as fallback if the indexer is unreachable.
Allowlisted settlement tokens. Only owner-vetted stablecoins (USDC, EURC) move through the gateway, so payment history can't be spoofed by malicious token contracts.
Privacy-ready. The gateway is standard EVM bytecode with no chain-specific tricks, so it can be redeployed inside Arc's confidential execution environment (APS) when Circle ships it. See Privacy Roadmap.
Payment lifecycle
- App calls
send/multiSend/fulfillRequest/executeSubscription - Gateway validates, moves USDC, stores the
Paymentrecord, updates totals PaymentSent(+ flow-specific events) are emitted- Arc finalizes deterministically in <1s - the app treats the receipt as settled truth