Components
Oro is made of on-chain contracts, a web app, and supporting services.
This page is the system map. It explains what each part is responsible for without going into deployment details.
Supporting services can improve the app experience, but contracts remain the source of truth for balances, messages, collateral, and safety checks.
On-chain contracts
| Component | Role |
|---|---|
| EVM vault | Locks and unlocks the underlying gold-backed token. |
| Aztec bridge | Consumes EVM-to-Aztec messages and emits Aztec-to-EVM messages. |
ZGLD token | Confidential gold-backed asset on Aztec. |
| CDP vault | Holds ZGLD collateral and controls ORO mint/repay flows. |
ORO token | Confidential dollar-targeted debt asset. |
| Oracle adapter | Stores price and freshness data used by the CDP vault. |
| Risk engine | Encodes collateral and liquidation checks. |
| Access control | Roles and pause flags for guarded operations. |
Credit and liquidation flow
The CDP vault owns the position accounting. Users deposit private ZGLD, mint private ORO, repay ORO, and withdraw ZGLD when the position remains healthy.
The Risk Engine is the dedicated risk-check component. It stores and evaluates parameters such as minimum collateral ratio, liquidation threshold, liquidation bonus, close factor, debt ceiling, and account debt ceiling.
Liquidations are permissioned in the current testnet architecture:
- the CDP vault admin approves liquidator accounts;
- an approved liquidator chooses a position, an ORO repayment amount, and a ZGLD seizure amount;
- the vault asks the Risk Engine whether the position is liquidatable;
- the liquidator's ORO is burned;
- the position debt and collateral are reduced;
- the liquidator receives ZGLD up to the configured cap.
This makes the testnet flow easier to operate while Oro and Aztec tooling are still moving quickly.
Application layer
The web app and backend are separated.
The web app is the user surface for wallet connection, bridge requests, minting, repayment, and service health.
The backend is the read and coordination layer for the app. It helps the interface stay fast and consistent by preparing the information users need before they sign an action.
The main idea is simple: the frontend presents the action, the backend organizes the relevant protocol information, and the wallet remains the place where the user approves.
Operational workers
Two support services sit beside the backend:
- the oracle operator reports gold price updates and heartbeats;
- the relayer progresses bridge transfers.
They are separate from the frontend because they are long-running system services rather than user-facing screens.
Data flow
The app presents a clear user action. The backend helps assemble the current protocol view. The oracle keeps price data fresh. The relayer helps bridge transfers progress. The contracts remain the source of truth for balances, messages, collateral, and safety checks.