Oracle’s Besu Platform: EVM Code, Different Permissions

A release announcement with a limited scope

On October 27, 2026, Oracle published an overview of Blockchain Platform Enterprise Edition release 26.3.1. The announcement describes an integrated stack for permissioned digital-asset applications and states Limited Availability in October 2026. It is a product announcement with a restricted availability label, not evidence that the described applications have already gone live at particular financial institutions.^[1]

The release number also matters when reading the headline. Oracle’s earlier 26.2 documentation already lists Besu validators using QBFT, Ethereum JSON-RPC access and a custodial wallet service. Besu, QBFT and custodial signing should therefore not be presented as first appearing in this announcement. The useful question is how the platform’s documented controls fit together.^[3][1]

Compatible instructions, a separate ledger

The 26.3 architecture runs Solidity contracts in the Ethereum Virtual Machine, or EVM. It exposes Ethereum-style interfaces through an RPC Proxy, the service through which applications submit requests. But the same documentation describes permissioned, private Ethereum networks, with their own Besu instances and node roles.^[2]

Execution compatibility and network membership are different properties. Using the EVM does not, by itself, place a transaction on public Ethereum. In this design, the transaction goes to the configured Besu network. To understand the application, a reader needs to know who operates that network and who may participate, as well as which contract language it accepts.^[2]

Signing a request is not agreeing on a block

Oracle separates the jobs. The RPC Proxy resolves the caller’s organization and applies platform access controls. Universal Wallet as a Service, or UWaaS, provides custodial wallet and policy services; an instance-level wallet service handles Besu-specific signing and broadcast operations. The signing service manages keys on behalf of users rather than requiring the application to handle private keys directly.^[2]

Besu validators then use QBFT to agree on blocks. Oracle describes approved organizations sharing validation and deterministic finality for committed transactions, within the protocol’s fault-tolerance limits. A valid signature, permission to make a request and agreement on its place in the ledger are distinct parts of this path. Calling the result “EVM-compatible” does not identify who controls any of them.^[1][2]

Contract release has its own approval path

The announcement describes a governed deployment mode in which contracts start inactive. They become active after the configured approvals have been recorded on-chain through a Governance contract. The same approval path applies to upgrades. This is a mode and policy that an organization selects and operates, not a claim that every Solidity contract automatically receives these controls.^[1]

The contract registry keeps versioned artifacts such as the ABI, bytecode and storage layout. These describe how software calls a contract, what code is deployed and how its state is arranged. They give reviewers a specific implementation to approve and help interpret historical state. That release approval is a separate decision from the validators’ agreement on blocks.^[1]

SQL history is a view of the ledger

Rich History can copy and index blockchain transactions, events, traces and state in Oracle Database or MySQL. Administrators can query the data with SQL and combine it with off-chain business records for reporting or reconciliation. The 26.3 overview explicitly makes Rich History and archive nodes optional.^[2][4]

The architecture distinguishes this historical view from execution and consensus: validators agree on blocks; Rich History components consume ledger information. Consortium members may share a database provided by the founder or keep separate databases connected to their own nodes. A SQL result is therefore a query of captured history, not a new round of validator agreement.^[2][4]

Read the controls, not just the compatibility label

Oracle’s announcement is useful as a concrete example of several independent choices around familiar contract code: network participation, key custody, contract release approval and historical queries. Its documentation explains the intended platform behavior. Neither the availability statement nor the architectural description establishes a particular institution’s production rollout, and neither makes these private networks part of public Ethereum. Those boundaries are essential to understanding what was announced.^[1][2]