Skip to main content

Understanding Bundles

Bundles on MEV-Share are conceptually the same as bundles on MEV-Boost; they are an ordered array of transactions; but their structure is a bit different. There are several new parameters which control the privacy of bundles, and there's also a new endpoint to send bundles: mev_sendBundle.

Bundle Definition​

MEV-Share Bundles have the following structure:

/* 
    NOTE: optional fields are marked with a ?
    example: {
        privacy?: { ... } // privacy is optional
    }
 */
{
    jsonrpc: "2.0",
    id: string | number,
    method: "mev_sendBundle",
    params: [{ /* MevSendBundleParams */
        version: "v0.1",
        inclusion: {
            block: string,     // hex-encoded number
            maxBlock?: string, // hex-encoded number
        },
        body: Array<
            { hash: string } |
            { tx: string, canRevert: boolean } |
            { bundle: MevSendBundleParams }
        >,
        validity: {
            refund: Array<{
                bodyIdx: number,
                percent: number,
            }>,
            refundConfig: Array<{
                address: string,
                percent: number,
            }>
        },
        privacy?: {
            hints?: Array<
                "calldata" |
                "contract_address" |
                "logs" |
                "function_selector" |
                "hash"
            >,
            builders?: Array<string>,
        },
        metadata?: {
            originId?: string,
        }
    }]
}

This is the generic bundle structure used in MEV-Share. This comprehensive specification enables several exciting features, outlined in the next section.

Use Cases​

With arrays of parameters at your disposal, there are many ways to build bundles on MEV-Share. The following sections describe new features and use cases that arise from the bundle definition.

Bundle Composition​

  • Share data from your bundles with other searchers to earn MEV kickbacks.
  • Specify locations in your bundle where searchers are allowed to insert transactions to earn even more kickbacks.
  • Use other searchers' bundles in your own bundles to execute a more profitable strategy.

Pre-inclusion Predicates​

  • Specify a strict range of blocks to target.
  • Predicate is evaluated before the builder considers the bundle for inclusion in a block.

See inclusion for relevant parameters.

Post-inclusion Predicates​

  • Set guaranteed kickback for inclusion of bundle in a block.
  • Specify kickbacks per-transaction in a bundle.
  • Send kickbacks to any desired account.

See validity for relevant parameters.

Granular Privacy​

  • Specify data to share about your bundles to earn kickbacks on top of searching profits.
  • Choose your preferred builder(s), and send them your orderflow exclusively.
Note to searchers

By default, when a user specifies which builders their transactions should be sent to (by setting builders), those settings are inherited by bundles which use those transactions.

Searchers can restrict these settings by specifying builders in the bundle's privacy parameters. Specifically, by setting builders, the bundle is sent to the intersection of all builders specified by each of the bundle's transactions, and the builders specified in the bundle's builders parameter.

See privacy for relevant parameters.

Now that we know all the different ways in which we can send and share bundles, we're finally ready to send a bundle.