Published on

Introducing Mercury Light Clients: A Leaner and Open Revamp to Mercury

Authors

In web3, “light client” usually refers to a node that skips full execution and consensus yet can still verify state correctness. Mercury Light Clients are something different. They’re the next evolution of the Mercury ecosystem—a slimmer deployment model that preserves the advantages of Mercury’s runtime technology (Zephyr and Retroshades) without necessarily depending our centralized infrastructure for raw data delivery.

Why the Shift?

Over the past several months our activity in the Stellar ecosystem has been noticeably quieter. After 3–4 years building, we decided to pause high‑velocity feature work to (i) watch how Mercury behaved in the wild, (ii) validate PMF without continuously reshaping the product, and (iii) reassess the true operational cost of what we had shipped.

Early on we layered a lot of functionality into Mercury without fully pricing in the long‑term maintenance burden. Running a complex, ever‑growing backend with limited resources slowed iteration, raised failures and internal bugs that affected clients, and diluted focus—especially when the PMF signal, while present, wasn’t yet strong enough to justify heavy perpetual development and DevOps overhead. These learnings drove this redesign.

Now, with Light Clients, we confine the central dependency to a narrow, performant data feed and push execution outward. By open sourcing the runtime (which was already open source) and implementing a feature-rich light client, and most importantly reducing the operational workload, we expect to ship faster, experiment more safely, and re‑engage with Stellar research as well! Something we’re eager to get back to.

What Changes

Instead of bundling data sourcing, execution, and delivery into one tightly run service, we’re unbundling:

  • Data feeds: Pluggable, replaceable.
  • Execution tech (Zephyr + Retroshades): Reusable, openly auditable runtime components that are also modular allowing for better changes in the data feed logic.
  • Operators: Us, developers, third party infra operators, even end users.

Key Benefits

  1. Fully Open Source
    All code is public and auditable, raising quality and trust.

  2. Higher Reliability Through Redundancy
    If one feed goes down, point the client at another. The same applies to execution instances: there's no single operational choke point.

  3. Unlimited Flexibility
    We publish building blocks and reference implementations. Others can extend host functions, swap in feeds, or optimize performance.

  4. Lean Core Team Focus
    Less devops means more time writing code, shipping features, supporting builders, and contributing back to Stellar research.

Code for Mercury Light Clients is at https://github.com/xycloo/mercury-light-client.

Features

Parity with Mercury's features and more, with improved concurrency:

  • Live execution (zephyr and retroshades).
  • Zephyr and retroshades catchups: sync very fast.
  • Zephyr serverless functions.
  • Protocol 23 compatibility (new snapshot reader).
  • Full catchups through stellar core vs light catchups.

Actively Seeking Infrastructure Operators

We’re actively focusing on and looking for infrastructure operators who are willing to run Mercury Light Clients as services for their own users. If you operate Stellar (or broader blockchain) infrastructure and want to add a sandboxed execution layer with pluggable data feeds, let us know.

What’s Next

  • Operator Resources & Specs
    Clear guides and configuration standards for running light clients and feeds.

  • Infrastructure Partnerships
    Collaborations with operators to broaden the available feed and execution peers.

  • Intra‑Provider Interoperability
    Designing the pathways so multiple providers can interoperate seamlessly.

  • Towards Zero‑Trust Processed Data Feeds
    Sandboxed execution for data means simpler path towards trusted data for downstream systems.

Thanks for hanging by!