ORACLE: Open RAN Arbitration via Consensus Ledger Enforcement

Making the process inspectable

In an Open Radio Access Network (O-RAN), radio applications, or rApps, from different vendors may propose incompatible configuration changes. Even when a decision rule is agreed, participants may want evidence that their predictions were included and that the rule was applied consistently.

I address this with a permissioned distributed ledger: a shared record maintained by an identified set of validators. Smart contracts enforce the workflow and execute the published decision rule on recorded inputs. Participants can inspect both the inputs and the resulting decision.

This architecture is most useful where independent verification matters to the participating vendors. If everyone accepts a single trusted coordinator, a central service is simpler and avoids the extra validator infrastructure.

A shared record from proposal to outcome

The design uses three contracts: a Registry Contract for rApp registration, a Proposal Contract for proposals and prediction collection, and a Decision Contract for evaluation and outcome recording. Lightweight adapters connect rApps to contract events and transactions.

Decision-critical records are kept on the ledger. Detailed telemetry can remain outside it, with hashes or references connecting that data to the recorded outcome. Those links support later integrity checks; the measurement pipeline still determines whether the original observations were correct.

I use a simple majority selector in the reference implementation so that workflow enforcement can be evaluated separately from the quality of a particular arbitration policy. More elaborate policies, including reputation weighting, are possible extensions.

Follow a proposal through the shared record

Step through collection, an invalid early decision attempt, majority evaluation and outcome recording. The rApps express views about a proposal. Separately, validators maintain agreement on the recorded contract execution.

What the prototype demonstrated

I deployed the contracts on a four-node Hyperledger Besu network using IBFT 2.0 consensus and a two-second block period. The evaluation used seven registered rApps and included a replay of arbitration decisions generated by an ns-3 O-RAN simulation.

Source: the published paper, Section V-E to V-G, including Tables III and IV. The ten-cycle measurement and workload replay are separate experiments.

The measured workflow latency fits within the paper’s example of a 60-second or longer non-real-time control interval. It does not establish suitability for near-real-time radio control. These are ledger prototype and simulation-replay measurements, not a production network trial.

I also tested five invalid operations: late predictions, duplicate predictions, decisions before quorum, proposals from unregistered rApps, and outcome recording before a decision. The contracts rejected all five cases. Execution costs increased approximately linearly with the number of participating predictors in the evaluated setup.

What verification can establish

ORACLE makes it possible to check whether recorded inputs were processed according to the agreed workflow. It cannot establish that a submitted prediction was sincere, that a sensor reading was correct, or that the selected policy leads to the best network outcome. Strategic manipulation and collusion require additional mechanisms.

The permissioned validator set and its governance remain trust assumptions. The measured four-validator system tolerates one unavailable validator; the experiment does not demonstrate operation with an arbitrarily compromised validator population.

Replication, contract execution and validator operation add overhead. Larger deployments and higher conflict volumes need further evaluation, potentially with batching or partitioning. A comparison with centralised coordination baselines is also further work.

How ORACLE relates to TACIT

In TACIT, we study how prediction accuracy can determine an rApp’s influence on arbitration. In ORACLE, I study how the process and its records can be independently checked. The roles are complementary: a decision policy can use reputation, while an enforcement layer records and executes the agreed process.

The ORACLE experiments use majority selection, so their latency results are not measurements of TACIT running on-chain. A combined implementation would need its own validation.

Within my research on multi-agent systems and institutional design, this is a concrete example of making authority accountable through shared evidence and explicit rules. The work arose from the practical requirements of coordination between network applications.