to many ppl, rpc config probably seems like the dryest + most boring topic imaginable

that ends NOW

my new rpc config standard will drastically boost the interoperability of the crypto tooling ecosystem

rpc config megathread ⬇️

data @ paradigm

https://github.com/sslivkoff

a major painpoint becomes clear to anyone that has used or built lots of crypto tools: rpc config sucks

there isn’t any good solution for juggling all the different rpc endpoints you need for interfacing with L1’s, L2’s, testnets, chainforks, proxies, and private relays

what’s the solution?

MESC: the Multiple Endpoint Shared Configuration standard

MESC allows all of the tools on your system to share a single rpc configuration. this maximizes interoperability and minimizes all maintenance burden related to rpc

MESC is composed of 3 parts:

1. an abstract specification for how to store rpc configuration data + metadata

2. libraries for interfacing with MESC for every popular programming language

3. a rust-powered cli tool for creating + managing MESC configurations

MESC makes it easy to track lots of info about lots of rpc endpoints, including chain_id’s and JSON metadata

MESC can also set a default endpoint for each network

here I’m using MESC to track 23 endpoints across 8 chains. MESC shares this info across all the tools on my system

the goal is to make rpc config completely frictionless:
- simple for users: single source of truth, set it and forget it
- simple for tool builders: access config data using just a couple lines of code
- bulletproof+idiotproof: It Just Works, and it works identically everywhere

MESC is an opt-in spec: it only becomes an enabled via specific environment variables

this makes it easy for existing tools to incorporate MESC in a backward-compatible way: if a user hasn’t opted in, just fallback to the non-MESC config approach

ideally there will be a MESC implementation for each common programming language so that MESC data can be queried by any tool in any computing environment with just a couple lines of code

so far we have MESC implementations for rust 🦀, python 🐍, and cli 📟

the biggest challenge when designing MESC was coming up with a schema + UX that works well across programming languages, OS’s, and runtime environments

the design of MESC carefully navigates many subtleties related to how different languages represent + manipulate data

each MESC implementation provides an identical interface with identical behavior

each implementation has been thoroughly tested using the same language-agnostic test suite

most tools can add the full functionality of MESC to their codebase with just a couple lines of code

MESC is designed to be a coherent superset of the rpc configuration features used by popular crypto tools like Foundry, Ape, checkthechain, Heimdall, and others

the design of MESC draws heavily from these different configuration approaches

MESC can store metadata about each endpoint including things like ratelimits, api keys, and whether an endpoint is a private mempool

MESC can also define endpoint groups for load-balancing infra

you can try MESC out today:
- 📟 cli: `cargo install mesc_cli`
- 🐍 python: `pip install mesc`
- 🦀 rust: `cargo add mesc`

implementations for other languages are still a WIP

the MESC cli client makes it very easy to manage a large number of endpoints

allow me to share 3 badass features of the cli client:

(1/3) the mesc setup subcommand

typing `mesc setup` opens an interactive UI for creating and modifying configurations

this makes it very low friction to get started

(2/3) mesc ping

using `mesc ping` will ping all of your endpoints, obtaining such information as: latency, node version, chain_id, active namespaces, geographic location, and more

(3/3) the MESC cli client is ultra compostable

- can use `mesc url [query]` to output endpoint url’s. this mixes well with bash’s $(...) syntax for chaining

- can use `--json` to export the output of each command as JSON

that’s all I have for now

MESC is still a WIP. check out the current specification here https://github.com/paradigmxyz/mesc/blob/main/SPECIFICATION.md

that repo also contains all of the reference rust/python/cli implementations

in summary: configuring multiple RPC endpoints for each tool on your system is a PITA

this is especially true when you have many endpoints

it’s not practical to separately configure lots of endpoints for each tool on your system and keep configs sync’d as they evolve over time

open standards are the bedrock that tooling ecosystems are built upon...designing good standards today is how we enable tomorrow's ecosystems to flourish

if you have ideas for how to improve MESC please reach out 🫡🫡

thanks for reading

MESC is the final entry in Advent of Crypto Data

each day from Dec 1 to Dec 25 there was a shiny new release of data content from your favorite builders in the data space

calendar tracker here https://paradigmxyz.github.io/advent-of-crypto-data

thanks to everyone who participated ❤️ it was super fun

a lack of standards has required every crypto tool to develop its own custom approach for configuring which rpc endpoints to use

as a user, if you have multiple endpoints + multiple tools, creating all the configs + keeping them sync'd can quickly become a maintenance nightmare