Aztec and Privacy

Oro uses Aztec because the protocol needs confidential ownership and privacy-preserving user actions around gold-backed value.

Privacy does not mean everything is invisible. A useful protocol must also expose enough public information to stay safe, auditable, and operable.

Privacy boundary

Oro aims to keep user activity confidential while keeping system-level safety visible.

Privacy map

Area	Confidential	Public or operational
Gold exposure	ZGLD balances and transfers on Aztec	EVM-side bridge deposits and exits
Debt position	User position activity where supported by the Aztec design	Risk parameters and system-level solvency checks
ORO usage	ORO balances and transfers on Aztec	Global supply and protocol accounting where required
Bridge	User activity after value enters Aztec	Message commitments, bridge boundaries, and settlement events
Oracle	No user portfolio details	Gold price, update rounds, and freshness
Services	No user intent should be made public by default	Service health and availability signals

What should be confidential

These user-level details are intended to stay confidential:

• ZGLD balances;
• ORO balances;
• confidential transfers;
• user CDP details where supported by the contract design;
• the user's decision to hold, borrow, repay, or exit.

The goal is to avoid making a user's gold exposure and debt behavior trivially public.

What is public or operational

Some information is public by design:

• EVM vault deposits and unlocks;
• bridge message commitments and consumption paths;
• global supply and backing constraints where needed;
• oracle prices, rounds, and freshness;
• risk parameters such as the minimum collateral ratio;
• pause state and role-governed actions;
• service health exposed by the backend.

This public layer is what allows the system to prove that collateral, messages, and supply rules are respected.

Practical privacy boundary

The clean mental model is:

Confidential: user balances, transfers, and position actions on Aztec.

Public: system-level safety data, bridge boundaries, oracle freshness, and EVM-side settlement.