Skip to main content

Roadmap

Oro is designed to become a useful financial primitive for Aztec users: confidential gold-backed value, optional credit through ORO, and practical payment flows around that base layer.

The early beta proves the core protocol path. The next phase is about maintaining it, decentralizing the surrounding services, and expanding the product surface so Oro becomes a reusable building block for the Aztec ecosystem.

Built first, expanded next

The strategy is to arrive with a working protocol, then extend what already exists: stronger infrastructure, deeper liquidity, and more real use cases for confidential assets.

Global Enhancement and V2

The first priority is to consolidate the full Oro experience before expanding into larger protocol features.

Planned work:

  • refine the website into a clearer V2 experience;
  • improve the app flow around bridge, mint, repay, and withdraw actions;
  • make protocol status and service health easier to understand;
  • align documentation, product language, and onboarding;
  • consolidate the full solution across contracts, services, and frontend.

Why it matters:

Oro should feel like one coherent product, not a collection of separate components. A stronger V2 gives users more confidence and gives the protocol a cleaner base for future features.

Decentralized Oracle Network

The oracle should become more robust over time.

Planned work:

  • add more independent price reporters;
  • improve source diversity and anomaly handling;
  • define clearer oracle health signals;
  • reduce reliance on any single operator;
  • prepare a path toward community-run reporting.

Why it matters:

ORO minting depends on fresh and reliable gold price data. A stronger oracle layer improves safety for users and strengthens Oro as an Aztec-native financial primitive.

Service Decentralization

The backend and relayer make the app easier to use, but they should not remain single operational points forever.

Planned work:

  • support multiple backend instances;
  • support multiple relayer operators;
  • improve failover behavior;
  • make service health easier for users to understand;
  • document a cleaner path for independent operators.

Why it matters:

A confidential protocol becomes more useful when its supporting services can be operated by more than one actor.

Multi-Asset FPC

Oro should make network fees easier to handle inside the confidential user journey.

Planned work:

  • design a Multi-Asset Fee Payment Contract for Oro flows;
  • support paying Aztec network fees directly in ORO or ZGLD;
  • define safe pricing, conversion, and settlement rules for fee payments;
  • keep fee abstraction compatible with protocol risk controls;
  • document the operator and user assumptions clearly.

Why it matters:

Users should not need to interrupt the Oro flow just to manage a separate fee asset. A Multi-Asset FPC would let ORO and ZGLD become more practical assets inside Aztec by making them usable for the network fees around the actions they enable.

Liquidity Layer

Oro needs a market layer so ZGLD and ORO can be used beyond minting and repayment.

Planned work:

  • explore AMM pools for ORO / ZGLD;
  • explore liquidity routes with other Aztec assets;
  • design liquidity incentives that do not weaken collateral safety;
  • study how confidential swaps can support ORO utility.

Why it matters:

Liquidity makes ORO more useful and gives users better paths to enter, exit, rebalance, and build on top of Oro.

Oro Launchpad

Oro could become a base layer for confidential capital formation on Aztec.

Planned work:

  • explore launchpad flows built around ORO;
  • support project funding with clear allocation and settlement rules;
  • design contribution flows that preserve useful privacy for participants;
  • connect launchpad activity with Oro liquidity and payment rails;
  • keep disclosures, risk limits, and user consent explicit.

Why it matters:

A launchpad built on Oro would give projects a way to raise funds with Aztec-native privacy while giving contributors a clearer, more structured path to participate.

Recurring Payments

Confidential recurring payments could turn ORO into a practical payment asset.

Planned work:

  • design subscription-style payment flows;
  • support user-controlled recurring approvals;
  • keep payment metadata as confidential as possible;
  • make cancellation and spending limits clear.

Why it matters:

Recurring payments are a practical bridge between DeFi and everyday usage: memberships, software, services, and creator subscriptions.

AI Agent Payments

Autonomous AI agents may need payment rails that are programmable, privacy-preserving, and easy to reason about.

Planned work:

  • explore confidential ORO payments for autonomous agents;
  • define safe spending limits and approval models;
  • design payment flows for agent-to-service interactions;
  • keep human oversight explicit where needed.

Why it matters:

As agents become more capable, they will need payment systems that are programmable, controlled, auditable at the system level, and privacy-preserving for users.

Developer and Ecosystem Tooling

Oro can also contribute reusable patterns for Aztec builders.

Planned work:

  • publish clearer integration examples;
  • document confidential collateral and debt patterns;
  • improve testnet walkthroughs;
  • share lessons from oracle, relayer, and service health design.

Why it matters:

The more reusable the patterns become, the more useful Oro is to the broader Aztec ecosystem.