Every payment system that has mattered (be it Visa, ACH, SWIFT, Ethereum, Solana) has earned relevance not through expressiveness, but through its ability to move value reliably, securely, at scale, under real-world constraints. This architecture matters most with stablecoins. Stablecoins need reliability, privacy, compliance, and scale for them to underpin global payments.

Bitcoin, despite being the most secure settlement layer ever created with the most value secured across blockchains, still lacks this. What’s missing isn’t another smart contract platform or a faster consensus mechanism. What’s missing is execution: robust infrastructure that can move stable value instantly, privately, and compliantly, without turning settlement into a trust tradeoff.

Lightning scales Bitcoin, but remains operationally complex and liquidity-constrained. RGB enables private, programmable assets, but inherits Lightning’s UX and coordination problems. Together they are powerful but incomplete. They work for experienced infrastructure operators, not for everyday users.

Enter Utexo

Utexo exists to close that gap by meeting users where they are and melding these complementary frameworks, rather than introducing a new chain or competing security model. For Utexo, RGB provides client-side validated assets anchored to Bitcoin while Lightning provides instant settlement. Utexo’s statechain layer coordinates liquidity (with little to no fragmentation constraints), and execution without custody, without global state, and without compromising unilateral exit. Costs and performance are consistent regardless of network congestion.

Compliance is enforced at the client layer, not on-chain. Issuers can blacklist when required, without publishing transaction graphs or turning payments into a surveillance system. Operators remain blind to transaction contents, and users retain control of their funds.

The result is a system where users can send and receive stablecoins at Lightning speed with no liquidity constraints, without running nodes, managing channels, or trusting intermediaries, all while remaining fully self-custodial. From an operator standpoint, it means more upfront visibility into cost structure for processing payments, which leads to much better guarantees on consistency in uptime and processing capabilities. 

What gives us confidence this can be built is the team behind it. The Utexo team sits at the intersection of Bitcoin infrastructure, Lightning, and real-world deployment. Viktor has been deeply embedded in the RGB and Lightning ecosystems, while Renat brings protocol-level engineering experience across client-side validation and statechain design. The broader team has already shipped production infrastructure used by wallets, exchanges, and institutional partners today: bridges, routing systems, and liquidity layers.

Most importantly, the Utexo team is not building in isolation. Utexo has direct working relationships with multi-national payment service providers, Lightning service providers, wallet teams, and stablecoin issuers, working on feedback loops that most protocol teams don’t achieve. This is execution-first engineering, informed by real transaction flow rather than whiteboard assumptions.

The Future of Payment Processing

The vision for Utexo is straightforward: to become a new kind of payment processor that is Bitcoin-native, stablecoin-first, globally interoperable, and invisible to the end user. Not a chain people think about, but infrastructure they rely on by abstracting complexity away from wallets, exchanges, and merchants. If Bitcoin becomes the settlement layer for global value transfer, something has to sit between raw settlement and real-world payments. Utexo is being built to be that layer.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/#portfolio.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/terms for additional important information.

However, significant improvements are still needed to effectively address the challenges in making crypto-based payments ubiquitous and globally accessible not only in the backend, but as an accepted payment method for merchants and consumers alike:

• Outdated Infrastructure: Stablecoins are currently operating on networks that aren’t optimized for the nuanced requirements of modern payment systems and significant UX challenges exist, such as refunds, reconciliations and analytics.

• Complex Compliance Requirements:  Crypto payment systems and stablecoins still can’t meet the compliance needs of global merchants and users. 

We have yet to effectively compete with traditional payment service providers at scale despite their ongoing challenges with high processing fees, fraud, and onboarding difficulties.

However, imagine a world where a purpose-built payments network could provide seamless solutions for merchants worldwide. What if this network was optimized for efficient stablecoin transfers and tailored to meet the specific needs of modern commerce, offering efficiency, reliability, and regulatory compliance that far surpasses existing systems? The future of money rests on the ability to redefine global payments and modernize our existing digital transaction systems.

Institutions will likely drive the next wave of adoption, but they need a compliant and scalable solution. Merchants and consumers need a payments infrastructure they can trust– one that simplifies payment processes and effortlessly integrates into existing global systems. We believe there’s never been a better time for innovation to address all this, and 1Money will make this possible. 

1Money is creating a transformative network to revolutionize how we think about global payments. They are building a purpose-built L1 explicitly designed to optimize for payments and stablecoins. This new network rivals traditional payment rails, offering unparalleled efficiency, compliance customization, and reliability for merchants and institutions. The 1Money network is poised to also include near-instant transaction confirmations, fixed or low-cost fees, native multicurrency support to support global commerce, and built-in compliance. With native features like sanctions-blocking controls and rigorous onboarding requirements for permissioned validators, the network prioritizes integrity and trust.

We're confident that there is a future where payment processing costs approach zero, chargebacks and fraud become relics of the past, and seamless merchant payments change how we do business globally. This is an ambitious vision that will take an exceptional team to implement. The 1Money team has been meticulously constructed with experts in their individual fields, uniquely positioned to execute this grand vision. We’re proud to be backing and working with Brian and the rest of the team as they continue to redefine what’s possible in the world of stablecoins and payments with 1Money.

We believe 1Money will create a better financial system for everyone. 

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

In this article, we explore the catalysts driving the growth of Distributed Validators, the direct impact of security on node operator profitability, and the performance of DVs on Ethereum mainnet. We can appreciate how DVs contribute to a more secure and efficient Ethereum network by understanding these dynamics. 

The adoption of Distributed Validators is influenced by significant developments in Ethereum’s roadmap and the evolving landscape of network participation.

The Ethereum roadmap includes several essential proposals aimed at improving scalability, efficiency, and censorship resistance. While these upgrades bring substantial benefits, they also introduce challenges for validators. 

• EIP-7251: Increase in Maximum Effective Balance of Validators 

Currently, validators operate with a maximum effective balance of 32 ETH. EIP-7251 proposes increasing this limit to 2048 ETH, allowing validators to manage larger stakes and reducing the total number of validators needed. While this change can enhance network efficiency, it further increases the importance of individual validators. 

• EIP-7547: Inclusion Lists

Inclusion Lists aim to bolster censorship resistance by enabling block proposers to specify transactions that must be included in subsequent blocks. This mechanism empowers proposers to ensure the inclusion of critical transactions, mitigating the risk of censorship by specialized block builders. However, it adds complexity to validator operations, as they need to process and manage these lists effectively.

•  EIP-7732: Enshrined Proposer/Builder Separation

Enshrined Proposer-Builder Separation formalizes the division between block proposers and builders within the Ethereum protocol. By trustlessly allowing validators to outsource block construction to specialized builders, ePBS can improve network efficiency and enhance MEV (Maximal Extractable Value) extraction. However, it introduces new roles and responsibilities, increasing operational complexity due to additional protocols and interactions.

Validators are becoming more critical as their duties are fine-tuned, and Distributed Validators allow them to operate with improved safety and liveness. DVs enhance fault tolerance and allow validators to manage increased workloads and complexities more effectively. By leveraging DVs, validators can remain resilient and performant even as the network evolves. 

The approval of Ethereum Exchange-Traded Funds (ETFs) represents a significant advancement toward broader institutional participation, further bolstered by recent political shifts in the United States favoring the industry. This favorable regulatory environment increases the likelihood that staking will become an integral feature of these financial products. Institutions have always prioritized stability and security alongside potential yields. So, when staking is introduced to Ethereum ETFs, Distributed Validators will likely emerge as candidates to meet their stringent requirements.

According to a recent Blockworks survey, over 61% of institutional respondents expressed willingness to pay a premium for the security benefits provided by DVs. With institutional interest on the rise, ensuring the security and profitability of node operations becomes even more critical; this heightened institutional involvement can inject additional capital into the ecosystem on the condition that staking infrastructure is sufficiently safe and robust.

In Ethereum staking, security, and profitability are intrinsically linked. Security breaches, slashing events, downtime, and key rotation issues immediately impact a node operator’s profit and loss statement. Robust security measures are, therefore, fundamental components of a node operator's financial strategy.

DVs are crucial in mitigating the risks of slashing and downtime, ensuring continuous operation, and maximizing staking rewards. For example, Obol’s DV clusters have maintained a perfect record with zero slashing incidents. The losses to node operators in the past three years that could have been avoided with the implementation of DVs are noteworthy: 

• Downtime: 12 incidents totaling 91 ETH

• Slashing: 5 events totaling 333 ETH

• Key Vulnerability: 2 events totaling 460 ETH of missed rewards

• Total Avoidable Lost Income: 883 ETH ($2.65M at $3k/ETH)

Source

With proposals like EIP-7251 increasing the maximum effective balance of validators, the financial impact of downtime or slashing incidents could escalate further. This emphasizes the importance of validators protecting their operations with a Distributed Validator setup.

DVs introduce fault tolerance, protecting a validator against the failure of less than one-third of nodes in a DV cluster. DVs, therefore, reduce the necessity for a DevOps engineer to be on constant standby to address unexpected downtime. This decreased reliance on specialized personnel leads to direct savings in operational expenses and increases peace of mind. 

Optimizing node operations and consolidating the node count can also reduce infrastructure costs without compromising performance. For instance:

• Traditional Setup: A system with ten nodes and three backup nodes may cost approximately $2,600 per month, assuming $200 per node for bare-metal servers.

• DV Cluster Setup: Transitioning to a seven-node DV cluster can reduce the cost to $1,400 per month.

Obol has introduced a suite of smart contracts known as Obol Splits to simplify and streamline the reward distribution process for validators. Here's how they contribute:

• Withdrawal Recipients: These contracts differentiate between the principal amount and the rewards flow, ensuring operators receive their earnings without affecting the principal amount.

• Split Contracts: They facilitate the division of Ether among multiple parties, promoting fair and transparent distribution among the node operators of a multi-party DV cluster.

• Split Controllers: These provide the flexibility to adjust reward allocations as needed, allowing for responsive management of stakeholder interests.

By automating reward distribution and reducing manual intervention, these non-custodial tools minimize the risk of errors and disputes. Operators can manage rewards more effectively, fostering trust and collaboration within validator groups. For more details, you can explore Obol's Documentation on Splits.

Having looked into Distributed Validator’s growth catalysts and their impact on security and profitability – we now turn to performance. An equitable lens to look through is Lido’s SimpleDVT Module, which battle-tests DV technology at scale on Ethereum mainnet while utilizing both Obol and SSV Network implementations.

In the table below, we look at Lido SimpleDVT’s RAVER scores across the last 30 days. Obol’s clusters have outperformed both SSV and Lido’s curated set over the time period. At a 97.96% average RAVER score, it also outperformed the network average over the same window.

Outside of Lido’s SimpleDVT module, Obol has made significant strides in adoption, with over 500 unique operators, including many independent “squad stakers”.

Obol has recently released a dashboard giving a comprehensive overview of crucial ecosystem metrics. They are currently taking in a large amount of stake from Lido and EtherFi, each of whom pledged $1 billion in Total Value Locked (TVL) to Obol. 

The progress of Obol demonstrates how DVs can enhance performance while maintaining security at scale.

The evolution of Ethereum brings both opportunities and challenges for validators. The need for robust, secure, and efficient staking solutions becomes paramount as the network grows in complexity and scale. Distributed Validators offer a compelling response to these needs by enhancing security, reducing operational costs, and improving overall network resilience.

By adopting Distributed Validators and leveraging tools like Obol Splits, node operators can navigate the increasing demands of the Ethereum ecosystem more effectively. This not only safeguards their profitability but also contributes to the health and decentralization of the network.

As we look toward the future, embracing innovations like Distributed Validators will be crucial in realizing Ethereum's full potential as a decentralized platform capable of supporting various applications and services.

***

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Certain information contained in here may have been obtained from third-party sources, including from portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

What if the user could, instead, express a desired outcome - however complex - from a single interface? What if that user was also able to express something more powerful such as a multi-step conditional request to an AI agent, and not worry at all about how it's completed - such as this scenario involving a trade:

In these cases, the user’s creativity could be leveraged instead of hampered, and we think Khalani is the key to unlocking this future.

Over the last few years, there has been a movement toward “intent-based architectures” to improve the on-chain transacting experience. With intents, users can express exactly what they wish to do across one or more hops without necessarily giving preference to a particular method of execution or source of liquidity. 

The nomenclature of an intent has taken many shapes over time, such as an RFQ or limit order, but we believe the difference is the evolution toward much more general-purpose intents beyond buying/selling an asset at a particular price. 

When you call a taxi from a rideshare service, you aren’t specifying the make and model of the car along with a specific route – you’re instead specifying your destination and selecting your most desired rate. With intents, instead of authorizing smart contracts, users instead authorize an expressed outcome as they typically do on traditional platform, and give this to a “solver” to do it for them. A “solver” is a stakeholder that competes to receive the intent, fulfill it, and charge a small fee. We can think of drivers in this rideshare example as the “solver.” Intents act as a way to remove any specificity requirements when transacting, and instead pass on the work to solve any form of request in more flexible and efficient ways, across any domain, to a specialist.

Currently, we face two emerging challenges in this new mode of operation:

• Users can’t create generalized and expressive intents, and

• Solvers face significant frictions such as capital inefficiency when serving multi-chain orders, a limited ability to service multiple intents simultaneously, and more.

What if there was a marketplace where anyone could be a “solver” by fulfilling incoming orders and get paid for it (similar to how DeFi and AMMs democratized liquidity provisioning)? What if there was a marketplace where anyone could participate in verifying these orders are correctly matched with the algorithm, and share in the fee outcome? 

We think Khalani is critical in solving these problems and unlocking the next phase of intents. 

Khalani is creating the building blocks for unifying solvers, solver networks, and intent applications

• Users of dapps can better express intents.

  For users, Khalani’s goal is to make the intents experience seamless. Users that wish to declare as expressive of an intent as they wish can now do so, and know that there is an efficient network of solvers ready and able to handle their requests. Instead of previously trying to stitch together complex transactions, users can now outsource this effort in a much more seamless way. 

• Dapps can send user’s intents to Khalani to be fulfilled.

  Dapps can now enable users to have less of a flat transaction experience and give them preference in defining their desired outcomes. These applications can also easily plug into Khalani’s platform for solver networks to help users leverage the most ideal transaction routing and execution with minimized MEV issues. This also saves them the immense effort of building and maintaining in-house specialized and custom solver offerings, and avoiding centralization pressures by signing deals with one solver at a time. 

• Solvers can coordinate to maximize matching efficiency and rewards for all parties involved.

  Anyone can participate in the network and become a solver. These entities collaborate with others in the network to share in the fees, decentralize the economy and add increased resiliency, and increase the ability to handle more expressive intents. Khalani removes the barriers to creating new solvers, and does so in a way that decreases the potential for monopolizing groups to commandeer the solver landscape. Centralization becomes less of a concern, and solvers in the network share more in the financial return provided for solving an ever-increasing amount of expressed intents. 

• Developers can become algorithm-writers to solve intents and be rewarded. 

  Solvers will have access to a much bigger pool of intents to fill, maximizing the opportunity for all. This will create a more efficient market that is simultaneously better for the user (via lower fees) and empower algorithm writers who can earn more against this consolidated order flow.

Solver networks must be collaborative instead of competitive, leaving little room for the erosion of trust in the transaction supply chain and allowing information to flow freely to the right parties to be acted upon. Any user seeking to express intents across the space across multiple dapps and multiple domains should be able to be as expressive as they wish and not encounter issues with resolution. These users should be able to tap into a collective source of solvers within any application, with all parties seeking to maximize efficiency, and with open participation at its core. 

To achieve this, Khalani is building the full stack of necessary components to power a new intents-driven world. 

The first thing to address is ensuring that any application seeking to enable intent-driven interactions can package these requests in a standard format that solvers can interpret and process. For onboarded solvers and intent-centric platforms and applications, Khalani is building an intent compatibility layer to enable applications to formally specify/platforms to bridge their intended user experience and intent formats in a manner that solvers in Khalani’s network can process and collaboratively handle. 

To both represent these intents as their own type expression and formally specify them, Khalani is also working on Axi and an associated virtual machine called the Common Knowledge Machine (CKM). Axi is a new language and runtime meant to create these modular intents that solvers in the network can handle. The CKM will not just be for hosting specifications for intents, but also will facilitate the orchestration of solutions and verify the completion of expressed intent requirements. More interestingly, this can also help create a new set of financial primitives and wrappers representing fulfilled and unfulfilled user intents, optimization problems as well as solver configurations. 

Finally, Khalani’s settlement layer will enable atomic and multi-domain settlements, completing the chain from expression to resolution. 

Intents are one of the largest unlocks in the space for all parties across the transaction supply chain; where transactions simply become requests with user-defined conditions, and outcome efficiency is maximized for all involved. 

Expressing, solving, and validating intents will continue to grow significantly as an important cornerstone of transacting, and we’re excited to support Kevin and Tannr and join them on this journey to build Khalani. They have the right combination of drive and experience to truly change how we transact and build a more collaborative foundation for an intent-driven future. 

***

Certain information contained in here may have been obtained from third-party sources, including from portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

Check out the video below to listen to the space:

***

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

Rocco has joined us as Head of Portfolio, where he will work closely with our founders and provide them with customized support based on their organizations' stage. Previously, he co-founded SpruceID, working on decentralized identity and data, and co-authored standards such as Sign-In with Ethereum. Before that, he led product for an identity team at ConsenSys.

Christian has joined us as a Data Scientist, where he will be building out Ethereal’s data pipelines and internal capabilities. Previously, he was a founder at Component building an on-chain analytics platform, and before that, he ran the sales engineering function at StackAdapt.

Both Rocco and Christian are former startup founders who continue to be passionate about building a more decentralized future in which sovereignty, freedom, and access are at the forefront of all digital interactions.

We are excited to have them here at Ethereal Ventures.

***

The views expressed here are those of the individual Ethereal Ventures Ltd. (“EV”) personnel quoted and are not the views of EV or its affiliates. Certain information contained in here may have been obtained from third-party sources, including from portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

What Are Circuit Breakers

If you’re reading this, you’re probably already familiar with DeFi. In that context, Circuit Breakers (CBs) are mechanisms integrated into DeFi protocols to temporarily halt or limit transactions, mainly token outflows, under certain conditions. These conditions are typically predefined and are triggered when unusual or suspicious activity is detected, such as an abnormally large withdrawal of funds in a short period. These circuit breakers aim to safeguard against potential security breaches or financial anomalies.

The leading advocates of circuit breakers in DeFi, as of late, argue for their implementation given the following nuances in crypto:

• UX Challenges, Custody Responsibility & DYOR: The general population, accustomed to traditional banking systems, may not be fully prepared for the responsibility of self-custody of funds that DeFi entails. In addition, the ability to invest in various financial products with little knowledge of their inner workings or proper research (DYOR - Do Your Own Research, a well-known meme in the web3 world) also poses a problem for the end-user.

  Circuit breakers could act as a safety net, providing security and trust in these systems.

• Preventing Composability Attacks: In the interconnected world of DeFi, where protocols often interact and rely on each other, circuit breakers can prevent composability attacks. These attacks occur when an entity exploits the outflows from one protocol to manipulate or attack another, potentially leading to cascading failures across the ecosystem.

I’m not a big proponent of circuit breakers, and I’m here to explain why these implementations warrant further contemplation. It is crucial to maintain a neutral tone when discussing security-improving standards for the ecosystem, and I’ll try to do so.

CBs are not a one-size-fits-all solution and come with challenges, such as potentially creating denial-of-service vulnerabilities. Let’s dig into it.

The concept of outflow limitations in banking has its roots in the early history of banking and financial regulation. These measures were typically introduced as a response to financial crises or situations where the banking system was at risk.

1. Bank Runs and Early Regulation: The most common reason for introducing outflow limitations was to prevent or mitigate the effects of bank runs. A bank run occurs when many customers withdraw their deposits simultaneously, usually due to fears that the bank will become insolvent. This phenomenon was particularly prevalent during the early 20th century, including during the Great Depression.

2. The Great Depression and Banking Reforms: The Great Depression in the 1930s led to significant banking reforms, particularly in the United States, with the introduction of the Banking Act of 1933 (also known as the Glass-Steagall Act). This act, among other things, aimed to restore public confidence in the banking system and included provisions for banking regulation that indirectly affected outflow capabilities.

3. Modern Banking Regulations: In recent times, banking regulations have continued to evolve, particularly during financial crises like the 2008 global financial crisis. These regulations often include liquidity requirements and other measures that can act as de facto outflow limitations, ensuring that banks maintain a certain level of liquid assets to meet potential withdrawal demands.

4. International Examples: Different countries have implemented outflow limitations in various forms, often in response to specific economic crises or challenges. For example, during the European debt crisis, certain banks in countries like Greece and Cyprus imposed withdrawal limits to maintain financial stability.

Wrapping up, it’s clear that outflow limits were mainly a response to bank runs. But in DeFi, things are different. Most DeFi platforms are made to have atomic settlements (i.e., settle in a single transaction). This setup naturally dodges the classic bank run issue.

These systems are made to run 24/7 settle without human interaction. So it is obvious to me that the reason “circuit breakers” were introduced in the past is not why we are touting them today.

This entire piece started based on an intuition of mine that implementing circuit breakers in the systems we have designed would turn the whole crypto ecosystem into the same infrastructure banks had created.

Gonçalo, Le Brute

@GNSPS

Got it! I think there’s a myriad of problems with that.

* Increased attack surface.
* Griefing attacks.
* Human dispute processes.
* Getting the time window right (I have no idea how you’d do this!).
* Legal issues with freezing funds and being a money transmitter, etc.
* …

4

5:26 PM • Nov 23, 2023

After careful research, I changed my views on the subject. However, the two first points still stand very valid.

CBs increase the attack surface of a project, and as we saw with the Wise Lending attack recently (read the linked thread from Daniel for an excellent deep dive into it), adding code to make things safer might do the exact opposite:

Daniel Von Fange

@danielvf

TLDR: Sophisticated attack, bypassing defenses in place for donation attacks, exploiting things that usually make a protocol safe. In the end, two different parts of the system rounded differently, resulting in a wrongly passed validation check. 20/

38

6:04 PM • Jan 13, 2024

In addition, and arguably more importantly, CBs are essentially a Denial-of-Service “feature.” Notice I am air-quoting feature because, after over seven years of reviewing the security of many of Ethereum’s significant protocols, my team and I have consistently flagged anything that could prevent the systems from executing continually as a vulnerability.

Let us take a breather before I explore my potentially biased views about this solution and look at the current implementations (with none of them being live that I am aware of).

Here is the Ethereum Magicians post discussing the ERC for the Circuit Breaker standard: https://ethereum-magicians.org/t/eip-7265-circuit-breaker-standard/14909.

And the ERC itself: https://github.com/ethereum/EIPs/pull/7265/files#diff-ecfb870fcc81bdae3f4d19e1a26384c7038345396d61751b1c0bb9bd3637588a.

For some visual context, here is the message sent with the PR to the EIP repository on GitHub:

Implementation, which is extraordinarily similar in design to @Elliot0x:

https://github.com/solidity-labs-io/zelt/tree/main

Granted, the canonical implementation is well-built and mitigates many of the issues I raised when I first started talking about CBs publicly. Mainly through the use of a buffer mechanism that accounts for inflows as well as outflows, as perfectly explained by @Philogy in the ERC docs:

L

et’s go back to the list in the tweet I presented at the beginning of the article and analyze how my perception changed!

The CBs presented are completely automated, so they generally don’t suffer from this problem. There is a dilemma at play here, though, between delayed, third-party settlement and the prevention of griefing attacks.

As a consequence of the above, I wouldn’t qualify this as an issue anymore.

This is somewhat solved in the implementations I looked at.

I say “somewhat” because the modules to be added are meant to exist in isolation and not completely intertwined with the project’s code. This means your codebase can update storage counters and then read from them, but if there is a flaw in this code, the extent of the damage is that the circuit breaker doesn’t work anymore.

The flip side to this assumption is that if you poorly implement the invariant in your code on the outflow limits and give it some other access control to your system, that might create many problems. But then again, there are reference implementations in the repositories for you to analyze, hopefully mitigating this problem.

This is openly recognized by Philogy in the docs; however, I think the importance of how these choices might impact the operations of protocols is greatly understated. In his words:

Parameter Choice

Generally these are relative subjective reasons to assign these parameters, more research is required.

I agree, but I think that the project's needs mutate too often, and the lack of proper care will hinder the protocol badly. This raises yet another problem in this vertical.

Assuming that the limits should be time-variant (e.g., they should probably start small when the project launches and increase with maturity), the algorithm to change said parameters would be another scope creep or bad-opsec door open to attackers. Not the most worrying aspect but also not the least worrying one.

And we finally get to the elephant in the room. This is both recognized in the docs and a tweet by Philogy. A tweet that recognizes the dilemma I stated above and signals a preference for a human-bound settlement mechanism, which might reopen the first two problems I deemed as solved above.

philogy

@real_philogy

there's a major trade-off between accounting for short-term inflows and being more DoS resistant.

For CBs long-term I'm more bullish on having a network of 3rd parties that can assess and take on the settlement risk, this allows u to forget about the rate limiter and just have…

1

9:20 AM • Nov 24, 2023

Now, this is where our hopes and wishes start to differ wildly. 😂

I do not believe transitioning into a settlement layer of third parties is a good solution, and whether it is an improvement is very much up for debate.

Even in CBs’ current form, legitimate inflows are effectively not protected by the limiters (for a certain period), and, more worryingly, legitimate outflows can pause the entire system!

Taking aside the implementation is hijacking the Pause state from Open Zeppelin libraries, which might be used for something other than just transfers (easily solvable); the fact a single actor can utilize a feature to globally pause in and outflows gives me the chills. 😰

As Philogy recognizes and eloquently puts in the FAQ:

Elastic-to-Main buffer time frame ratio (Tl/Tm)

This is the biggest ??? at the moment. The lower the ratio the faster new deposits are protected but the easier the protocol is to DoS by just depositing, waiting for the elastic buffer to decay and withdraw.

They are alluding to how certain parameters affect the DoS-ability of the system.

Without getting into too much technical detail (please read the docs for that; they’re really well written), I am a big proponent of a huge Tl. However, that becomes impractical as it entirely defeats the CB’s purpose.

I don’t think Circuit Breakers are inherently bad; on the contrary, I think they’re a good development. We need to work way more on their shortcomings. WAGMI, I guess, CBs included.

Well, I guess you must put your work where your mouth is.

Assuming that the biggest danger here is the legitimate inflows creating space for malicious attacks, the only idea I can come up with is to “limit” legitimate inflows at the front-end level. Making it difficult for your users to deposit money.

Don’t get me started on the commercial pains this brings. Your CMO will for sure cry. But it kinda works?

This will probably drive your users mad, but with good UX, it can be a good workaround. 🤷‍♂

Since this is a solution tailor-made for financial products being built on Ethereum, I’d argue that the imposition of a rate limiter on your product actually makes its token a derivative of its original function.

The rational markets will price in the fact that you cannot exit your positions immediately (i.e., settle atomically). This could even generate opportunities to tokenize this disparity, just like we saw with LSTs (h/t @bees_neeth).

It even prevents whales that look for liquid investments (significant upside of blockchain-related products, in my opinion) from participating entirely (e.g., a whale being unable to withdraw their money instantly and instead having to wait

seconds to take it all out.

All in all, CBs have an undesired side effect of creating a much more unstable asset than its non-CBed counterpart.

Alignment considerations Reverting from the polarizing position I assumed on this tweet:

Gonçalo, Le Brute

@GNSPS

Do me a favor, if you use circuit breakers deploy a same version of your protocol without them. Because:

Circuit breakers are banks.

21

2:14 PM • Nov 23, 2023

I do not think implementing CBs is turning protocols into the horrible mess of financial systems today. At the very least, Ethereum is a much more transparent substrate than the one banks have, and that alone is a million light-years ahead of any bank-related infrastructure.

However, the fact we are partially breaking atomic settlement is unavoidable. In the same way, CBs possibly prevent composability issues, a single CBed protocol in a chain of interactions breaks atomicity for the entire chain should the values be above what is deemed acceptable for the CBed protocol. I find this problematic because my idealized version of Ethereum and DeFi is permissionless, but we should still talk about it.

My final suggestion is still the same as the tweet above. Possibly a bit uninspired, but I gave it some thought.

Many of you will probably retort, saying that it’s even worse for a project to fractionalize reserves. In other words, if you deploy two versions of your protocol, you’d be tearing apart your TVL into two uncommunicative parts. This isn’t entirely true. We can reframe these assumptions.

If one of the parts has atomic settlement and the other doesn’t, the value fraction needn’t be absolute. The part with instant settlement can still provision the part that doesn’t; it's just that the reverse isn’t true. “Fractionalization,” in this case, is a directed edge.

You could build layers on top of both systems that take care of this bridging automatically or just let the markets do their thing and provision the CB-enabled systems with their non-CBed counterparts for a premium.

I'll try to explain it with an example.

Say you deploy a Uniswap v2 pool with a CB embedded, specifically a pool for the USDC-ETH pair. This pool might lack instant settlement for certain volume amounts, but the original pool for the pair doesn’t. So markets, doing what markets do, will arbitrage between these pools, bridging the liquidity from the non-CB pool to the CBed one, should the opportunity arise. The contrary might not be true, though, because of the limits.

In other words, what I’m saying is that the TVL for Uniswap v2 with Circuit Breakers is the sum of the reserves of all the pools with and without CBs, and the TVL for “normal” Uniswap v2 is the sum of the reserves of only the pools without CBs.

Let me draw it for y’all:

I know this has the added drawback of dispersing the team’s attention over multiple copies of the same system, but then again, if CBs are meant to be simple, this shouldn’t be too much of a hassle.

Sadly, I am not proposing a technical solution for the problem (in part because I don’t think it’s needed; markets will do their thing) but rather a reframing of the mindset of fractionalized value, and I hope it is enough to convince you, the developer of the Next Big DeFi Thing™, to at least consider giving optionality to your users and the ecosystem.

TL;DR

• Circuit Breakers are a good step forward. But it feels like we haven’t tied our laces yet, so proceed cautiously.

• The increased attack surface doesn’t seem extremely problematic with their canonical implementations.

• They still present high denial-of-service risk for projects implementing them.

• You should seriously consider deploying versions of your system with and without circuit breakers. Fractionalized reserves are not a real problem if you do.

All of this might boil down to core beliefs, and I have always been for optionality, freedom of choice, less human interaction, and less human dependence in our systems, so please think of me as you deploy your next circuit breaker. 🥹

***

The views expressed here are those of the individual Ethereal Ventures Ltd. (“EV”) personnel quoted and are not the views of EV or its affiliates. Certain information contained here may have been obtained from third-party sources, including portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

Summary

• Since the transition to Proof of Stake was introduced into the Ethereum roadmap, we have believed that the total amount of ETH staked could reach 50-80% of total supply. This thesis has positioned staking as a core theme in Ethereal’s portfolio. We led/co-led investments in Obol and Eigenlayer within this theme, both of which are innovating at the heart of staking to enable new paradigms with a security-first approach.

• The success of the Shapella upgrade has increased confidence in staking by facilitating easier outflows and inflows of staked ETH. We have witnessed a steady increase in the amount of staked ETH. One thing to note however is the dynamic nature of the activation and withdrawal queues, which could lead to periods of increased egress times and demand for ETH liquidity from staked assets.

• Only 20% of total ETH supply is currently staked compared to 80% at the top end of our thesis. This 400% growth, when compounded with an assumed 300% growth in the medium-term Ethereum price, could mean 1200% growth from the current staking market of $50 billion.

• To date, institutional stakers’ allocations to staking have been minimal. We’ve been thinking about institutional staking and what it would take to convince institutions to stake, as it is clear that existing solutions were not feature-complete.

• From our research, we learned that providing a KYC solution was only the tip of the iceberg. Institutions require superior standards of staking operators, staking integrations into trusted crypto vendors, choices between modular and integrated staking management solutions, ability to structure staking yield-centric financial products, transparent reporting and analytics, tax information, slashing insurance, and most importantly, strong levels of trust and reputation.

  Once in a while, we have the good fortune of meeting a team that checks all the boxes that we outline in our hypothesis for what a product should look like. This is where Alluvial comes in. With their ability to build a differentiated product and also create a crypto-native coalition of world-class operators, technology providers and distribution partners, we believe that this collective will pave the path towards institutional adoption of staking.

• The Merge was completed successfully, and partial withdrawals were enabled through Shapella

  Prior to the Merge, there was significant apprehension around staking. Once completed, many of these perceived risks were alleviated, and stakers can now partially withdraw their stake as they choose to. In addition, the security of the staking contract has become more battle-tested with time and increased usage, which further reduces concerns around the security risks of staking.

• Clearer opportunity cost of staking returns with idle ETH

  Ethereum is emerging as the premier smart contract blockchain. This drives expectations of increased network activity, increases expectations of higher staking yields, and results in investors staking more ETH to increase their exposure to staking rewards (which are paid in ETH). Foregone yield now becomes more costly as non-stakers forgo the receipt of block rewards. This dilutes their ownership of the network compared to those that stake.

• Liquidity concerns

  The sacrifice in liquidity as a byproduct of staking is a major concern for institutions. This arises because the network only allows a certain amount of stakers to deposit and withdraw funds at a particular point in time. If stakers want to withdraw funds over and above the limit, they are subject to a withdrawal queue that can extend days and perhaps weeks.

• Operator trust and reputation

  Institutions that stake ETH often hire operators to manage the staking process on their behalf. In many cases, institutions are unsure how to perform diligence on operators. Performing diligence requires deep technical expertise and there are no standardized benchmarks to aid the process given the nascency of the industry.

• Regulatory requirements

  Institutions require operators, custodians and other technology providers to adhere to standards seen in traditional markets, including storing auditable trail of work, standardization of diligence processes, KYB, etc. Likewise, institutions require all of the product’s users to undergo a KYC process with high pedigree. Users should not, for example, inadvertently be exposed to unlawful activity, such as pooling funds with sanctioned entities. Institutions want a staking product built to minimize regulatory risk.

• Internal risk requirements

  Institutions have different preferences for how to access staking products based on internal risk requirements. For example, some would require staking products to be integrated with their trading venue, while some may prefer API offering or an integration directly into their staking operator. A successful enterprise-grade liquid staking product should offer a comprehensive suite of choices.

Existing liquid staking solutions have catered to crypto-native retail users and have not been able to meet the enterprise-grade needs of institutions. As a result, institutional liquid staking is a blue-ocean category that no player has successfully penetrated.

Alluvial stood out as the only team that was highly experienced in the institutional domain with the capability of architecting a product to address the market need. As the institutional liquid staking market grows, we believe Alluvial, as a software development team behind the Liquid Collective protocol, will be a driving force in creating and leading the category, and will play a pivotal role in onboarding institutions to stake ETH through Liquid Collective. Liquid Collective is an enterprise-grade solution offering integration services to businesses and is the first liquid staking product that may serve both institutional and/or retail customers.

Alluvial’s challenge is to create a product regarded as the standard for institutional staking. Without any defined standards for validator operations, KYC/AML, or product delivery across the fragmented industry to begin with, Alluvial itself would have to first explore, define, and create the standards. This required ideological and operational alignment from various types of stakeholders in the industry in a near chicken-egg-like situation. Stakeholders include staking operators (“validators”), other companies that would eventually help deliver or support liquid staking products through their own services (“integrators”), Alluvial as the smart contract builder and supplier of ancillary services, and users.

The Alluvial team took the crypto-native ethos of collaboration and first-principles building to the market.

It was incorporated with the backing and design support of leading companies including Coinbase, Kraken, Figment and Kiln to lay the foundations for industry alignment. It then led social initiatives that unified ecosystem stakeholders under a common mission in support of Liquid Collective. For example, it played a key role in supporting the Proof of Stake Alliance to advocate for clear policies on the staking ecosystem and educate legislators to create a clearer path for compliance. The team is also collaborating with experts at Rated Network to create industry-wide operating standards for validators to encourage enterprise-grade security practices, and validator performance measurement.

To encourage further alignment of validators and integrators, Alluvial built upon its social initiatives by designing the economics of its liquid staking product to be inclusive and positive-sum for all participants involved. The Alluvial team continues to onboard the best-performing integration partners across all categories of the industry - from trading to custody to validators - to share in the success of the product via economic incentives. This de-risks at the bootstrapping stage of the product, builds a strong product moat, and unifies the voice of the industry.

The key distinction in Alluvial’s offering is that it appeals to institutional stakers as well as retail stakers. Alluvial includes the institutional staker by solving the concerns we noted above:

• Liquidity: The receipt token will be tradeable at major centralized exchanges such as Coinbase and supported by other major services such as custody and prime services.

• Security: Alluvial designed the enterprise-grade standards for operators in collaboration with a broad and distributed group of industry-leading providers. Liquid Collective will onboard operators that adhere to these standards to manage the staking of funds via the protocol, working with the best providers in a multi-operator, multi-cloud, multi-region, and multi-client setup.

• Operator Trust: Alluvial designed the institutional-grade standards for operators. It will onboard operators that adhere to these standards to manage staked funds in its product.

• Regulatory: The product is built to be compliant. Users will be KYC’d at the integration venues, and all validators will be held to the Alluvial standards of excellence.

• Internal risk: The product leverages integrations into major crypto-related asset management venues to increase the ease of use and elevate trust. Some examples of these venues include centralized exchanges such as Coinbase, custody providers such as Anchorage, and direct staking services such as Figment. A robust slashing coverage program including Nexus Mutual cover, is provided to every Liquid Collective participant to mitigate against slashing risk. Over time, Alluvial will build ancillary services such as performance and compliance reporting.

For the retail staker, the product employs the familiar deposit/withdrawal mechanism similar to other liquid staking services. It also allows LsETH (the receipt token) to be used on-chain as an ERC-20.

A high amount of coordination is needed at the onset of the vision to create the standards and align the industry’s key stakeholders under them. Once the foundations have successfully been laid ongoing product management can be sustained through stakeholder coordination. At this point, Alluvial’s work to set up the product will largely be achieved. If the product vision is successful, the product will custody a large amount of Ethereum’s supply and coordinate this among many stakeholders delivering the product. This collective will be a strong stakeholder in the Ethereum ecosystem. As a result, in line with Alluvial’s ethos to build with crypto-first principles, it should be governed and directed by the voices of the Ethereum community. Alluvial may hand over ownership of the product to a DAO called The Liquid Collective (“TLC”) to manage.

We’re excited about the prospects for Alluvial as it unlocks the next stage of growth for the staking industry.

***

The views expressed here are those of the individual Ethereal Ventures Ltd. (“EV”) personnel quoted and are not the views of EV or its affiliates. Certain information contained in here may haves been obtained from third-party sources, including from portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

Previously, as a security auditor at Consensys Diligence, I'd spend weeks at a time auditing clients' code. These audits would take place during a brief but crucial moment in a product's lifecycle - usually, just before a big launch. As a result, my goal was usually to catch the biggest, show-stoppiest, TVL-riskingest bugs. When you're a week away from launch, focusing on anything else would be a distraction.

Now, I'm faced with a different challenge: fitting security into something I can do in a single day.

My "clients" are different, too. Rather than auditing a completed product just before it launches, many of the portfolio companies I work with are in the early stages of development. This often means their code and documentation are rapidly changing, instead of the frozen codebase an auditor expects.

Initially, this combination of "one day per week" and "rapidly changing code" felt daunting.

One of the first portfolio companies I worked with, "Airplane," was in these early stages of development. Product launch was at least 6 months out, and nothing was set in stone. Airplane was in the middle of heavy iteration - there was lots of code being written and daily discussions around product direction.

With so much in flux, focusing on code review wasn't yielding many results. Bugs I found would become irrelevant a week later as features were added, removed, and changed. So after a few advisory sessions with Airplane, I developed a routine: spend the morning reading through small portions of new code and documentation, and spend the afternoon chatting with their engineers.

Although I wasn't doing as much code review, I was getting to know Airplane (and its engineers) through these regular conversations.

Airplane was a rare breed. Unlike many early-stage projects, Airplane's development felt more like cutting-edge research. They'd put together a team of skilled engineers and had an ambitious multi-year roadmap. My questions about product direction would spark impassioned discussion, with Airplane's engineers chomping at the bit to push all the limits of their project.

Their smart contracts were modular, upgradable, decentralized, permissionless... and highly complex.

High complexity isn't inherently wrong, but it needs to be managed properly. This is a challenge many teams face: one that's common for teams in Airplane's position.

A complex smart contract is a lot like a fighter jet: tons of interdependent parts that must function together perfectly, or risk catastrophic consequences. Deploying a protocol with several complex smart contracts is akin to putting on an air show, where your jets are flying together in unison with only a hair's breadth separating them. Also, the DPRK is throwing rocks at your planes.

As a general principle, I recommend taking your first plane out for a test flight before putting on a full air show. Here are the three main things I wish more projects would do as they launch:

1. Roll out features in stages

Your V1 launch should be a simpler, pared-down version of your final product. Additionally, capping your project's TVL can help minimize risk and allow you to identify issues and other pain points early, before they become show-stopping catastrophes.

It's much easier to develop and deploy new features once you have a solid foundation to build on top of.

2. Upgrade early and often

The road to functional DAO governance is paved with multisigs.

Upgrading early and often ensures your signers are experienced and that they understand their role in the upgrade process. Over time, you'll naturally accumulate safer upgrade procedures and testing methodologies.

And hopefully, because of this practice, you'll have a better idea of how to contact your signers in an emergency. Because above all else:

3. Prepare for the worst case scenario

It's important to acknowledge that you can't fix everything, your auditors can't catch every bug, and you'll never have the time to do all the testing you need to do. Things will go wrong, and when they do, every second counts.

If you're following the list so far, you have a multisig in place that can perform upgrades. Given how security-critical upgrades are, that multisig should require several signatures to execute a transaction. Finally, each of your signers should keep their signing key on a hardware wallet in a secure physical location.

This is all well and good, but if there's an active incident in your smart contracts, relying on this setup alone means you need 3/5/7+ people in different timezones to be at their computer at a moment's notice.

Frankly, this isn't realistic. And it's why I highly recommend implementing an "emergency pause."

The emergency pause role is held by a separate multisig. It requires only a single signature to execute a transaction, and the only ability it has is to immediately halt all activity in your contracts. Your upgrade multisig must be used to unpause the contracts.

The goal of the emergency pause is to give yourself time to calmly and correctly react and respond to an incident. Because the scope of the role is highly limited, you can allow more of your team members to hold the role, ensuring you're never caught waiting for signers when you need them most.

I worked with Airplane on these three major goals over several advisory sessions.

Although I was still getting used to working with projects for a day per week, Airplane's willingness to engage with security at an early stage of development made all the difference. It meant they were more flexible and therefore more capable of handling the type of broad feedback I'd always wanted to deliver as an auditor.

Since a code review minimized approach worked so well with Airplane, I was keen to explore even more options for working with portfolio companies. So, when "Banana" approached me with an odd request, I jumped at the opportunity.

Banana was nearing a beta release. They hadn't been audited yet, but were getting quotes from multiple firms and generally gearing up for a future push to production. Banana planned to use a whitelisted beta to onboard users onto their platform and work out any kinks in the system before going public. They were still working on a handful of small projects, but the bulk of their product had been built and wouldn't be changing too much.

Banana was unique because they were prepared with a specific request. They wanted me to interview their project leads, then prepare a report on their software development practices, vulnerability escalation procedures, and key person risk.

This was exciting: I'd never had an opportunity to advise on security solely based on interviews I'd be conducting. I spent the morning piecing together an interview template with ChatGPT, and then an hour each with Banana's project leads.

Through the lens of interviews, I formed a mental model of Banana's product and team that I've never had during an audit. By asking similar questions to multiple people, it became clear where Banana's teams differed from each other and how these differences tied into the big picture.

For example, users were relying on Banana's frontend to deploy contracts that would ultimately handle a large amount of funds. In other words, each user would get their own personal escrow: a "Banana address" to which they would send funds. This wasn't like a typical DeFi project, where users could check that they were interacting with a specific, well-known, widely-used address. Instead, they had to trust that the frontend-generated Banana address was valid.

Wanting to interrogate this trust, I asked each team member to provide details on their GitHub repository's access controls. Many repositories required multiple approvals to push updates. However, updating Banana's website required the approval of only a single developer.

Ultimately, I concluded that there were several potential attack vectors. Lenient access controls on the frontend repository meant there were multiple potential targets for a social engineeering attack. On top of this, there was always a risk that an underlying software dependency could be compromised to similar effect, otherwise known as a supply chain attack.

If an attacker was able to use these vectors to tamper with the frontend and give users a malicious Banana address, there would be no way for the average user to know. In this scenario, the attacker could wait until as many users as possible had deposited funds into malicious contracts, then make off with the funds. A "Banana split," if you will.

This risk is fairly common to projects whose frontends deploy contracts on behalf of their users. And lately, the rise in supply chain attacks, social engineering and phishing attacks, and private key compromise make it all the more important to take risks like these seriously.

For projects in this position, it can be difficult to completely mitigate the risk of a compromised frontend. There are so many variables to consider: software dependencies, access controls, DNS, and malicious links sent to users.

These variables can be addressed somewhat with stricter access policies, intense vetting of dependencies, and more.

However, I feel one of the more effective mitigations is to minimize the role of trust in the product website by educating users to perform their own verification based on chain data. The goal is to reduce the need to rely on your website to tell your users "send funds here." Here are two ideas:

1. Deploy contracts through a known on-chain entry point

When deploying a new contract for each user, the resulting address is, to the user, random data. It's not possible to determine whether the deployment was "correct" from the address itself.

To combat this, contracts should be deployed through a known entry point - a factory contract located at some existing address (preferably an ENS). This way, the user is able to go to etherscan, enter a simple ENS (e.g. deployer.banana.eth), and validate that their deployment details appear in the "Read Contract" tab.

2. Document the process for users

Of course, this wouldn't be complete without documentation. The steps above should be written down and explained in a way that even nontechnical users can follow along, e.g:

• Did I send a transaction to deployer.banana.eth?

• Can I use the ENS name to locate and query the contract on etherscan?

• If I input my address into the "Read Contract" methods, does etherscan confirm the configuration reported by Banana's website?

Bonus points if this documentation has screenshots, is supported by video, and is referenced repeatedly by your documentation, community managers, and anywhere else users might go to learn about your project.

Managing complexity, trust, and user education can't be done well at the last minute. As different as my experiences with Airplane and Banana were, they shared a common thread of identifying and mitigating these risks before they become emergencies.

Rolling out features in stages, planning versions and contract upgrades, preparing for the worst case scenario, creating comprehensive documentation - each of these requires careful consideration and foresight.

As an auditor, I've often wished I could have worked with my clients sooner, as no amount of finding bugs can change the underlying issues in development practices. The efforts Airplane and Banana put in to involve security at an early stage will surely serve them well, and I hope to see other projects follow their lead.

The views expressed here are those of the individual Ethereal Ventures Ltd. (“EV”) personnel quoted and are not the views of EV or its affiliates. Certain information contained in here may haves been obtained from third-party sources, including from portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.

Sovereignty. Freedom. Access

***

The views expressed here are those of the individual Ethereal Ventures Ltd. (“EV”) personnel quoted and are not the views of EV or its affiliates. Certain information contained in here may haves been obtained from third-party sources, including from portfolio companies of funds managed by EV. While taken from sources believed to be reliable, EV has not independently verified such information and makes no representations about the accuracy of the information or its appropriateness for a given situation.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by EV. (An offering to invest in an EV fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by EV, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Ethereal Ventures (excluding investments for which the issuer has not provided permission for EV to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://etherealventures.com/portfolio/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://etherealventures.com/disclosures for additional important information.