Skip to main content

Send orderflow securely

Orderflow sent to Flashbots Protect and Flashbots Bundle Relay is shared with BuilderNet. You can also send orderflow directly to a BuilderNet node (and validate its TEE proof).

note

The instructions in this document are intended for advanced technical users with strict trust assumptions. As a regular user, you can also use Flashbots Protect to transact securely through BuilderNet and get refunds for your transactions.

Sending orderflow to a builder node​

You can send orderflow to any BuilderNet node that's publicly available or accessible to you.

Public BuilderNet node

Flashbots operates a public node:

Supported API methods​

  1. eth_sendRawTransaction
  2. eth_sendBundle
  3. eth_cancelBundle
  4. mev_sendBundle

Example Golang code​

See this example Golang code for sending a signed transaction to a builder node. The example code supports requiring a specific TLS certificate as well as skipping certificate validation.

Request authentication​

Requests need a X-Flashbots-Signature header. The signature is calculated by taking the EIP-191 hash of the json body encoded as UTF-8 bytes. Any valid ECDSA secp256k1 key (i.e. any Ethereum key) can be used to sign the payload. The address associated with this key will be used for Redistribution.

For more details and examples on signing the payload, see the documentation here.

Server TLS certificate​

The server uses a TLS certificate that's generated inside the TEE instance, which you can verify with the TEE attestation mechanism. See also "TEE proof validation" for more details.

As an alternative to pinning the specific server certificate, you can also allow self-signed certificates (i.e. with curl using the --insecure flag).

Example curl request​

A curl request to send a signed transaction looks like this:

curl https://builder_hostname:443 \
    --cacert builder-cert.pem \  # or using --insecure
    --header 'Content-Type: application/json' \
    --header 'X-Flashbots-Signature: <public key address>:<signature>' \
    --data '{
        "jsonrpc":"2.0",
        "method":"eth_sendRawTransaction",
        "params":["0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"],
        "id":1
    }'

See also this Golang code for an full implementation.

TEE proof validation​

You can verify a builder node is running the correct code and configuration, and inside a specific TEE environment, using the TEE attestation mechanism.

It works by making a HTTPS request through an attested connection. During the TLS handshake, the server proves that it's running inside a TEE with specific measurements and responds with a TLS certificate for future use. Based on the verifiable code and configuration, this provides assurances that this certificate belongs to a specific VM image with specific measurements.

You can use this tool to get the certificate with TEE attestation (along with the attested measurements):

go run cmd/attested-get/main.go \
    --addr=https://builder_hostname:7936/cert \
    --out-measurements=measurements.json \
    --out-response=builder-cert.pem \
    --expected-measurements=https://measurements.builder.flashbots.net

You can request the certificate (without attestation) using curl like this:

curl -s --insecure https://builder_hostname:7936/cert > builder-cert.pem

This TLS certificate is now provably tied to the specific VM image, and any server with the corresponding private key is verified to run the correct code and configuration and inside a TEE.

You can use this certificate to securely send orderflow to this node on port 443 (see the previous section).

Example request requiring the server to own the private key:

curl --cacert builder-cert.pem https://builder_hostname:443

See also:

Join the discussion in the Flashbots forum!