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 | Private-note gold-backed asset on Aztec. |
| CDP vault | Controls ZGLD collateral and ORO mint/repay flows. Position accounting is public in the current testnet. |
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 move private-note ZGLD and ORO through private entry points, while the current position owner, collateral and debt values are synchronized into public contract state. Fully private positions are future work.
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.
The live testnet uses a 125% minimum mint ratio, a 112.5% liquidation threshold, a 3.5% liquidation bonus and a 50% close factor. The contracts, not the UI, enforce these values.
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 public protocol data, authorized account views, bridge status and wallet transaction payloads before users sign.
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
Long-running support services sit beside the backend:
- the oracle operator reports gold price updates and heartbeats.
- an EVM indexer and an Aztec indexer record finalized bridge events.
- the bridge reconciler rebuilds missed intents and plans idempotent actions.
- the relayer submits and confirms the resulting bridge operations.
- independent liquidator processes monitor and act on eligible CDP positions.
Indexers do not hold transaction keys. The oracle, relayer and liquidators use distinct accounts and wallet datastores so their workloads and authorities stay separated.
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. Indexers record chain facts, the reconciler derives pending work, the relayer executes it, and the oracle keeps price data fresh. Contracts remain the source of truth for balances, messages, collateral, and safety checks.