Figment’s Take On Ethereum Execution Layer Strategies

January 26, 2024

To reduce risks for our customers and support the overall health of the Ethereum network, Figment will substitute Geth with non-supermajority execution clients in our ongoing effort to become Geth-free.

Unlike other blockchains that rely on one singular client, Ethereum’s strength lies in its multiple, independently developed software clients.

Client diversity is considered essential for the network’s health:  this includes avoiding inactivity leaks and penalties, ensuring decentralization, and providing censorship resistance. It also mitigates the risks of centralization, such as single points of failure.

Execution client diversity on Ethereum is always top of mind

As part of Figment’s product strategy, we actively monitor client concentration throughout the Ethereum ecosystem. This move will prevent dependence on a single execution client software as a potential single point of failure for Figment and safeguard customer assets from correlated slashing events on the protocol triggered by software bugs, failures, or malicious behaviors of the client software.

What does this look like for Figment?

Figment is running multiple consensus and execution clients: Lighthouse+Geth and Teku+Erigon on mainnet

The Figment team, leveraging its extensive experience, continues to utilize less common execution clients, diligently monitoring and optimizing their performance. This ongoing commitment reflects our dedication to pioneering with diverse and efficient client solutions.

Our goal to switch from Geth to less widely used execution clients is aimed at reducing centralization risks and enhancing network health. In our extensive testing we have found varying performance across different clients and are working to find root causes. 

Figment has extensive experience in rapidly migrating from one execution client to another seamlessly and safely

Prioritizing the migration of client software over validators reduces the risk of slashing, such as double-signing or surrounding vote attestations, during the migration. This approach also improves the migration process by enabling faster execution, greater efficiency, and minimal disruptions to customer rewards. Our design philosophy has been that software client concentration is the biggest risk of correlated slashing so we designed our system to promptly be able to swap clients.

We Prioritize the Security of Customer Assets Over Performance

We continue to focus on our “safety over liveness” approach by prioritizing network safety to build trust among token holders, favoring uptime optimization over maximization to mitigate slashing risks. This strategy, contrasted with the misconception that higher uptime equals more rewards, is especially crucial in diverse Proof-of-Stake networks where the risk of slashing outweighs the benefit of slight uptime increases. 

For instance, striving for over 95% uptime on the Ethereum network can lead to increased slashing risks without substantial reward gains. Experienced staking providers who focus on slashing prevention tend to record fewer incidents than those prioritizing high uptime. This highlights the importance of careful validator selection.

Figment will continue to monitor these situations, provide updates, and strive to support diverse Ethereum clients in production and add support for more in the future.

The information herein is being provided to you for general informational purposes only. It is not intended to be, nor should it be relied upon as, legal, business, or investment advice. Figment undertakes no obligation to update the information herein. 


Meet with us

Bring the Complete Staking Solution to Your Organization


Figment respects your privacy. By submitting this form, you are acknowledging that you have read and agree to our Privacy Policy, which details how we collect and use your information.