Skip to main content

Supporting Services

Oro uses supporting services to make the protocol easier to use.

These services do not replace the contracts. They help the app read state, keep price data fresh, and make bridge transfers easier to follow.

Backend service​

The backend is the service that keeps the app responsive.

It gives the interface a prepared view of protocol state, user position data, bridge status, and service health. This avoids forcing the frontend to rebuild every protocol view directly from the chain.

From a user perspective, the backend should feel invisible: screens load faster, warnings are clearer, and actions are easier to understand before signing.

On testnet, the backend can also expose a limited mXAUT faucet when an operator configures a dedicated faucet signer.

Public protocol reads do not require a funded backend wallet. Account-specific reads and transaction preparation are authorized separately and fail closed when authorization is missing.

Oracle service​

The oracle keeps the protocol's gold price reference fresh.

It requires at least three independent sources, filters outliers around their median, and updates the protocol when the price has moved enough or its absolute price age approaches expiry. A heartbeat proves reporter liveness but does not make an old price current, so the worker submits a fresh price report before the absolute freshness deadline when needed.

The testnet worker normally samples once every 24 hours. The on-chain testnet freshness window is 25 hours, with earlier reporting used to preserve margin before expiry.

If the price feed becomes stale or unreliable, minting should stop rather than relying on old information.

Relayer service​

The relayer helps bridge transfers move between Ethereum and Aztec.

It does not define whether a bridge message is valid. That remains a contract and protocol responsibility. Its job is to reduce friction and keep transfers progressing.

Bridge timing is not instant:

  • L1->L2 Inbox actions usually need the Ethereum transaction, confirmations, Aztec indexing, and then an Aztec claim.
  • L2->L1 Outbox actions need the Aztec transaction to be included in an epoch, then the epoch root must be proven and published on Ethereum before the EVM unlock can run.

The current app displays an approximate 1 hour 30 minute testnet window for either direction. This is a user-facing estimate, not a finality guarantee. A pending transfer is not necessarily broken while confirmations, an Inbox claim, or an Outbox root are still unavailable.

Bridge intents and worker progress are stored transactionally in SQLite. The relayer uses a separate Aztec account and datastore from the oracle. Existing transfers can be reconciled and retried from their last safe persisted state. Users should not repeat the original asset transaction.

Two read-only indexers scan finalized EVM and Aztec events with persistent cursors and a reorg overlap window. A separate reconciler can recover deposits and burns even when the browser callback never reached Oro. Transaction submissions use durable idempotency keys; a timeout remains frozen until a canonical chain event proves its outcome. Pending bridge preimages are encrypted at rest with an operator key stored separately from the bridge database.

Liquidation operators​

Liquidations are currently performed by approved liquidator accounts rather than by any arbitrary caller.

The liquidator repays unsafe debt by burning ORO and receives capped ZGLD collateral if the CDP vault and Risk Engine agree that the position is liquidatable. The protocol rejects healthy positions, stale-oracle liquidation decisions, excessive repayment, and excessive collateral seizure.

On the current testnet, liquidation starts below 112.5%, a single liquidation can repay at most 50% of the debt, and the configured bonus is 3.5%.

Service health​

The app should clearly show whether the system is ready for user actions.

For early users, the important states are:

  • protocol data is available.
  • the oracle is fresh.
  • bridge progress is active.
  • the app can reach the services it depends on.

The public status page reports backend, oracle, relayer and Aztec RPC health. The protected operations view additionally tracks both indexers, reconciliation, deferred events, ambiguous actions and durable cursors. Health data is operational evidence, not a substitute for on-chain checks or independent monitoring.