Risks

Oro is running as a public testnet beta. Its core bridge and credit paths have been exercised, but it is not ready for mainnet funds until the operational and security checklist is complete.

Early-stage protocol

Oro should be treated as a controlled validation project until testing, audits, and operational hardening are complete.

Main risks

Bridge risk:

The system depends on correct message handling between EVM and Aztec. Message formats, replay protection, and Outbox consumption must stay consistent across contracts and services.

Oracle risk:

Minting depends on fresh price data. The oracle uses multiple sources and fails closed when stale, but source quality and operational security remain important.

Relayer risk:

The relayer improves UX but becomes operationally important once it submits live transactions. It needs limits, monitoring, and a clear recovery path.

Liquidity risk:

ORO targets dollar value, but early versions may have limited liquidity. A future market layer can help, but it should not replace collateral rules.

Upgrade risk:

Principal contracts should keep stable integration addresses and preserve storage layout across upgrades.

Privacy risk:

Token balances use private notes, but current CDP position ownership, collateral and debt remain public. Users must not assume that their whole credit position is confidential.

Operator and governance risk:

Critical roles are not yet protected by the final multisig, timelock, role separation, KMS/HSM and independent-operator design expected for mainnet.

RPC and infrastructure risk:

The public deployment depends on hosted Ethereum and Aztec RPC infrastructure plus a single Raspberry Pi operator host. Paid dRPC capacity improves resilience, but it does not provide full high availability by itself.

Before mainnet

At minimum, Oro still needs:

• independent audits of the EVM contracts, Aztec contracts, bridge and critical services.
• multisig/timelock governance and stronger separation of admin, guardian, oracle, relayer and liquidator roles.
• private-note CDP positions or an equally explicit production privacy model.
• multiple independent oracle reporters and production liquidation/bad-debt handling.
• deployment and public rehearsal of the versioned Inbox/Outbox migration, drain, unavailable-Inbox compensation reserve and recovery procedures. The protocol implementation and local tests are complete, but are not a substitute for testnet operations or an independent audit.
• redundant infrastructure, monitoring, backups and restore exercises.