OFAC+ Ethereum Builder Relay

Technical DocsBTCS Discord
The BTCS OFAC+ MEV-Boost Relay is an OFAC fully compliant block relay for Ethereum proof-of-stake validators and block builders. BTCS, has incorporated Forta’s (www.forta.org) AI-powered threat intelligence into its MEV-Boost Relay.

This sophisticated intelligence extends beyond merely screening wallet addresses on the OFAC Specially Designated Nationals (“SDN”) list but also screens certain other tangentially connected or associated wallet addresses to enhance compliance and the detection of suspicious activities during the block construction phase.

Forta’s threat intelligence provides early warning alerts about potential smart contract exploits. The tool uses multiple signals to identify potentially malicious smart contracts, including monitoring suspicious funding sources like Tornado Cash. By tracking all Tornado Cash deposits and withdrawals and integrating these with other data, it’s possible to assess the nature of a smart contract.

General

BTCS operates its OFAC+ relay which can be found at the locations below:

 

Holesky

https://0xaa58208899c6105603b74396734a6263cc7d947f444f396a90f7b7d3e65d102aec7e5e5291b27e08d02c50a050825c2f@holesky.relay.btcs.com

Mainnet

https://0x8c4ed5e24fe5c6ae21018437bde147693f68cda427cd1122cf20819c30eda7ed74f72dece09bb313f2a1855595ab677d@mainnet.relay.btcs.com

 

MEV-Boost Client Configuration

In order to include the BTCS OFAC+ relay in your MEV boost configuration, simply append it to the list of relays in the command line arguments.

./mev-boost -mainnet -relay-check -relays <relay>

Simply replace the placeholders <relay> with the appropriate connection URL.

Builder Integration

If you wish to use our OFAC+ Relay, please use the “Send us a message” button below, or reach out to us on our Discord.

Validator Registration

This guide details how to interact with the /eth/v1/builder/validators endpoint, including optional authentication and customising validator preferences.

If your client does not support add custom headers. Please contact us using the “Send us a message” button below or on our Discord and we can manually enable the below features for your validators.

 

Optional Authentication with the x-api-key Header

Users can obtain an api key from us and Authenticate via the x-api-key header. Validators registered with a valid authentication header will automatically skip any sleeps before get_payload is returned.

Example: x-api-key: hcDL4sdCpIDgg6rvFkdUWdNc

 

Customizing Validator Preferences with the x-preferences Header

Users can customize preferences for validators by including the x-preferences header with a JSON string of their settings.

Preferences include:

  • filtering: A string indicating which filtering policy to use (“regional” or “global”).
  • trusted_builders: Specify a list of builders whose blocks are accepted.
  • header_delay: If set to false, will disable any relay-level delays for the get_header response.
  • gossip_blobs: Setting this to true enables gossiping of blobs before payload validation, reducing orphaned slots and enhancing

Example: x-preferences: {“filtering”: “global”, “trusted_builders”: [“Titan”, “Beaver”, “Rsync”], “header_delay”: false, “gossip_blobs”: true}

 

Default Preferences

In the absence of the x-preferences header, the following defaults apply:

  • Filtering: “global” (no filtering).
  • Header Delay: true (relay-level get_header delays enabled).
  • Trusted Builders: no default (if you do not want to enforce any Trusted Builder rules, omit this key).
  • Gossip Blobs: false (blobs will be published after the block as been validated).

Specifying a single preference (e.g., {“header_delay”: false}) overrides only that setting, with others remaining at their default values.