> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aropay.aro.media/llms.txt
> Use this file to discover all available pages before exploring further.
# How AroPay works
> The architecture of the AroPay sandbox: accounts, wallets, the two money rails, the operator, and mint modes.
AroPay orchestrates confidential payments on public ledgers: sealed, private
transfers whose amounts never appear in cleartext on-chain. It runs on the
**Aro Confidential Rails**, built on **Zama Protocol FHE**.
The current deployment is an **MVP sandbox for B2B users** that pairs a web
dashboard with a versioned JSON API at `/api/v1`. Both surfaces drive the same
backend, and every on-chain action executes for real on the environment's
ledger: **Ethereum Sepolia** (chain ID `11155111`) during development, with a
Mainnet deployment to follow.
## The building blocks
| Concept | Meaning |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Sandbox user** | An enterprise account created by an Aro Media admin (email + password). |
| **Custodial wallet** | A per-user EOA generated server-side. The private key is AES-256-GCM encrypted at rest and used server-side to sign; this is what makes API-key-driven mint, transfer, and redeem possible. |
| **External wallet** | A watch-only address you register. It can receive and be monitored, but can never spend through the sandbox. |
| **Normal balance** | Public ERC-20 balance of the sandbox test stablecoin. |
| **Confidential balance** | cAROUSD (ERC-7984) encrypted balance. Decrypted server-side for custodial wallets; shown as encrypted for external wallets. |
| **Operator** | The platform wallet that faucets funds, mints in float mode, and settles redemptions. |
## Two rails, one API
Money in the sandbox lives on two rails that stay 1:1 with each other:
The test stablecoin, a standard ERC-20. Balances and transfer amounts are
visible to anyone on a block explorer, exactly like production stablecoins.
cAROUSD, an ERC-7984 confidential token. Amounts are encrypted with fully
homomorphic encryption (FHE), so the chain records *that* value moved, never
*how much*.
You move between rails with [mint](/guides/mint-carousd) (stable → cAROUSD) and
[redeem](/guides/redeem-carousd) (cAROUSD → stable). Within the confidential
rail, [private transfers](/guides/send-transfers) keep amounts encrypted
end-to-end. See [Confidential transfers](/concepts/confidential-transfers) for
how the encryption works.
The money behind the rails is environment-specific: in production, cAROUSD is
designed to be backed 1:1 by liquid USDC and USDT held at the Aro Liquidity
Commitment; on the Sepolia sandbox, a test stablecoin stands in and a faucet
provides funds. The rail mechanics are identical in both.
## The dashboard is an API client
Every dashboard feature (funding, minting, transfers, receipts, settings)
calls the same `/api/v1` endpoints you integrate against. That has two
practical consequences:
1. **Parity is guaranteed.** If the UI can do it, your integration can do it
with the same request shapes.
2. **You can mix surfaces freely.** Kick off a mint from a script, watch it
confirm in the dashboard, download the receipt from either.
## The operator
The **operator** is a platform-owned wallet that does the work your integration
shouldn't have to:
* pays out faucet requests (test stablecoin + a gas top-up),
* mints cAROUSD in float mode,
* settles redemptions by paying stablecoin back to your wallet.
If the operator runs low on gas or stablecoin, faucet and settlement operations
fail with explicit error codes (`faucet_failed`, `redeem_settlement_failed`);
see [Troubleshooting](/support/troubleshooting).
## Mint modes: backed vs. float
Deployments run in one of two mint modes. The API is identical in both; only
the on-chain mechanics differ.
| | `backed` (product flow) | `float` (default) |
| ----------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Mint** | Your wallet approves stable and calls `commitDeposit` (stable in, encrypted cAROUSD out) | Operator calls `confidentialMint` for your wallet |
| **Redeem** | Wallet requests redemption; operator publicly decrypts the burned amount and finalizes payout from reserves | Wallet confidential-transfers cAROUSD to the operator, which pays stable 1:1 |
| **Backing** | Every cAROUSD is collateralized by stable held in the commitment contract | Operator float covers payouts |
Which mode your deployment uses is an operational setting. In `backed` mode a
mint requires the custodial wallet to actually hold stablecoin; in `float` mode
the operator mints directly. Either way you call `POST /mint`.
## Server-side FHE
Confidential operations (encrypting mint amounts, decrypting custodial
balances, publicly decrypting redeem burns) run server-side through the Zama
Protocol relayer against its public Sepolia deployment. Two things follow:
* **You never handle FHE keys or ciphertexts.** The API takes and returns plain
decimal strings.
* **The first confidential call after a deployment restart can be slower**
while FHE keys are fetched. Subsequent calls are faster.
## Host isolation
The sandbox runs on its own hosts (`aropay.aro.media`). Sandbox routes only
resolve there, and admin routes 404 on sandbox hosts; the two surfaces are
isolated at the proxy layer.