Oval Node

Inner workings of the Oval Node.

The Oval Node is designed to simplify the onboarding process of Oval for searchers. Searchers can simply add a new RPC to their list of builders they send bundles to and the Oval Node takes care of all the special logic required to backrun Oval unlocks.

In order for a searcher to backrun a oracle price update they must send their bundle payload to the Oval Node. The Oval Node acts to augment the request to make it compatible with Oval. This works by pre-pending the unlockLatestValue function call to a searchers bundle, as discussed in the #permissioned-actors-to-initiate-the-auction section of the docs. Effectively, the Oval Node is the permissioned actor that initializes the auction.

The Oval Node supports two main RPC methods for searchers:

1. eth_sendBundle, to which searchers can send standard bundle constructions as they would to any other builder.

2. eth_callBundle to which searchers can send standard simulation payloads.

Both of these endpoints behave from the searchers perspective like any other builder they might send bundles to. Note that the Oval Node is not a builder; conceptually it is like a modified version of an MEV-Share node and acts as a middle layer between a searcher and MEV-Share.

Bundle transformation

The Oval Node receives a bundle on the eth_sendBundle RPC structured as follows:

{
  "method": 'eth_sendBundle',
  "params": [
    {
      "txs": ['0x1234…', '0x4567…'], // Array of signed transactions
      "blockNumber": '0x420', // Hex of target block
    },
  ],
  "id": 1,
  "jsonrpc": '2.0',
}

The Oval Node does three things to this bundle:

1. It transforms the method from using eth_sendBundle to mev_sendBundle. Equally, it transforms the params block to use the mev_sendBundle definition.

2. It constructs an unlockLatestValue transaction that is then sent to MEV-Share via eth_sendPrivateTransaction. This is the transaction that is backrun by searchers and starts the auction. See Mechanism Description for info on how this works. This call to the Flashbots MEV-Share endpoint contains the refund percentage and address, as described in #permissioned-actors-to-initiate-the-auction.
3. It appends the unlockLatestValue transaction hash to the incoming bundle and forwards this to the MEV-Share node via mev_sendBundle method.

The transformed bundle that is forwarded to MEV-Share looks as follows:

{
  "method": 'mev_sendBundle',
  "params": [
    {
      "inclusion": {
        "block": '0x420', // Original target block, Hex encoded
        "maxBlock": 18492875, // Original target block + lockWindow for given Oval
      },
      "body": [
        { "hash": '0x420' }, // UnlocklatestValue hash, from eth_sendPrivateTransaction
        { "tx": '0x1234', "canRevert": false }, // Searcher payload 1
        { "tx": '0x4567', "canRevert": false }, // Searcher payload 2
      ],
      "validity": {
        "refundConfig": [
          {
            "address": '0x1234', // Oval kickback address
            "Percentage": 90, // How much of the block builder payment to kick back
          },
        ],
      },
      "Builders": ['list', 'of', 'supported', 'builders'],
    },
  ],
};

The kickback address used by the Oval Node is set at the beginning to a multisig controlled by UMA (see Revenue Sharing). The OEV captured in the kickback will be manually distributed to associated projects that integrate with Oval. In the future this can be updated to operate as a contract to automatically distribute OEV revenue.