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.

Oracle service​

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

It compares multiple sources, filters abnormal values, and updates the protocol when the price has moved enough or when a heartbeat is needed.

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.

On public testnet, Outbox waits can be tens of minutes and sometimes longer. A pending transfer is not necessarily broken while the root is still unpublished.

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.

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.