Navigating the AVS Landscape on EigenLayer with $EIGEN
Understanding $EIGEN and Its Synergetic Relationship with AVS
This post was brought to you by Yield Guild Games (YGG). YGG is a web3 guild protocol that enables players and gaming guilds to find their community, discover games and level up together. Its mission is to become the leading community-based user acquisition platform in web3 gaming through fun quests that help players build their onchain reputation.
Find out more at: https://investors.yieldguild.io/
What are Actively Validated Services (AVS)?
Imagine a world where developers can seamlessly build and deploy secure and decentralized applications without having to fork out hefty capital and put in additional efforts to bootstrap their own decentralized validator networks. This is possible for projects that are launching as an AVS on EigenLayer.
EigenLayer is a shared security platform that provides cryptoeconomic security to protocols built on top of them. The stakeholders in EigenLayer include:
Restakers: Users who restake their liquid-staking tokens (LSTs)
AVS: Applications and protocols deriving cryptoeconomic security from EigenLayer
Operators: Validators that run AVS software and participate in validating the AVS
A diverse range of applications and protocols can launch as an AVS on EigenLayer, including bridges, oracle networks, data availability networks, decentralized sequencers, and many more. With EigenLayer, these AVSs can be economically secured by Ethereum in a trust-minimized manner. The pool of cryptoeconomic security made available to AVSs has grown significantly, with EigenLayer’s success in capturing the industry’s attention, having obtained over $16 billion in total value locked (TVL). To learn more about EigenLayer, check out the full Blockcrunch coverage here.
With an understanding of EigenLayer and AVSs, let’s take a deeper look into the robust AVS ecosystem:
What makes an AVS, an AVS?
Introducing the EIGEN Token and Its Role in AVSs
Exploring the AVS Landscape
The Challenges of Being an AVS
Advancing AVSs - The Road Ahead
What Makes an AVS, an AVS?
AVSs have distinct characteristics that set them apart from applications that are not built on EigenLayer.
Decentralized Validator Set
AVSs are validated by reputable operators that have opted into the EigenLayer ecosystem. These operators are responsible for performing tasks for the AVSs in a trust-minimized manner, ensuring the integrity of the AVS. By tapping on EigenLayer, AVSs do not have to issue their own token, removing the need for high upfront capital to bootstrap a decentralized validator set.
The tasks that have to be performed by AVSs can be broken down into smaller chunks, and thereafter allocated across participating operators, horizontally scaling the performance capacity of AVSs. in contrast, applications and protocols that do not rely on EigenLayer require their validators to perform the entire task. As tasks become more complex, the computational capacity required by each validator increases, making it more difficult to maintain a highly decentralized set of validators.
Secured by EigenLayer
By tapping into the vast pool of restaked ETH provided by EigenLayer, an AVS can bootstrap its own economic security from day one. This powerful feature allows developers to focus on building innovative services without getting bogged down in the complexities of managing their own validator networks.
Economic security is a crucial consideration for any AVS. Developers must carefully assess their target customer base and potential value at stake, and determine the appropriate level of economic security required to secure it. Establishing specific metrics and indicators, such as transaction volume or user growth, can help guide decisions on adjusting the AVS's requested amount of restaked ETH over time. As the protocol scales, it may need to increase its economic security to maintain optimal performance and user confidence. This is a powerful feature natively available for AVSs which non-AVS do not have.
However, it's essential to strike the right balance when it comes to economic security. An AVS should have enough security to instill trust in its users, but not so much that it hinders scalability or becomes a barrier to entry. Thus, developers must also consider the various sources of economic security available through EigenLayer, whether they are an attributable model such as single pod managers, or pooled model such as AVS node operators, and Ethereum node operating entities. Each option brings unique advantages and trade-offs that must be carefully evaluated.
To ensure operators secure the AVS, economic incentive is aligned through a slashing mechanism as mentioned earlier. For AVSs that incorporate this mechanism, clear communication is key. Developers must lay out clearly what actions would be considered a violation of the AVS's validation semantics and result in being slashed. Initially slashing will be done manually on EigenLayer as it tests out its platform, but in the future it will be automated.
AVSs built on EigenLayer also have the unique ability to inherit trust from Ethereum's battle-tested staking infrastructure. Developers get to choose the type of trust they want to inherit, whether it's the unwavering decentralized trust of geographically diverse home stakers or something more specific. It offers AVS developers a highly customizable solution catered to their needs.
By combining carefully selected trust inheritance, considerate operator workloads, transparent slashing conditions, and the unparalleled power of EigenLayer's shared security model, developers can cook up a decentralized masterpiece that truly stands out from the crowd.
Introducing the EIGEN Token and Its Role in AVSs
On April 29th 2024, EigenLayer announced its native token, EIGEN, distributed by the Eigen Foundation. EIGEN introduces the concept of inter-subjective forking, meant to complement the cryptoeconomic system provided through ETH restaking, which is EigenLayer’s primary offering. Before diving deeper into EIGEN and its role in the AVS ecosystem, here are two types of faults that EIGEN seeks to address:
Objectively Attributable Faults
These refer to faults that can be objectively proven on-chain either mathematically or cryptographically.
A real-life example would be: 1 + 1 = 3.
In the context of blockchains, one example would be the validity of a rollup execution, which can be proven on-chain by observing states.
Intersubjectively Attributable Faults
These are faults that cannot be proven on-chain, and can only be verified by agreements from observers.
One example would be if there is a claim that 1 BTC = 1 USDT. Based on the logic coded into the oracle, this is considered to be correct on-chain if all validators vote for ‘true’. However, observers would be able to identify, through off-chain sources, that this is incorrect.
Current solutions against the above-mentioned faults typically include slashing operators’ stakes (based on the presence of malicious behavior) and forking of chains. Nonetheless, these solutions are not feasible when the majority of the validator sets are malicious and are very taxing on the chain since a large amount of time and effort is required to coordinate a fork.
Enter EIGEN and bEIGEN, primed to tackle both objective and intersubjective faults.
Differences between Restaked ETH, EIGEN, and bEIGEN
Restaked ETH: A universal work token that is used to address objective faults. When a validator has been proven on-chain to be malicious, the restaked ETH held by validators will be slashed.
EIGEN: This is a wrapped version of bEIGEN that is utilized in DeFi applications. EIGEN as a token is ‘fork unaware’, and will not be affected should there be an intersubjective fault that results in a fork.
bEIGEN (backing EIGEN): Governs EigenLayer’s canonical state. bEIGEN is staked by validators to contribute to AVS security, and in return accrues rewards.
All three tokens are similar in their universal feature. ETH is a purpose-specific token, as it can only be staked to secure Ethereum L1. On the other hand, the staking of restaked ETH, EIGEN, and bEIGEN can be used to secure any types of protocols, infrastructure, or even chains that are built in EigenLayer.
Process of Addressing Intersubjective Attributable Fault
Let’s understand the dynamics of EIGEN and bEIGEN in challenging an intersubjective fault.
AVS operators (validators) stake bEIGEN tokens to secure AVSs and earn rewards
An AVS suffers from malicious validator behavior
A challenger puts up a sum of bEIGEN1 to trigger an intersubjective challenge
The sum of bEIGEN is known as CPF (commitment-per-fork) and is meant to serve as ‘collateral’ to prevent denial-of-service attacks
The challenger launches a fork-distributor (FD) contract, a new ERC20 contract, to represent the fork of bEIGEN1
The FD contract contains the details of the fork, including the specific operators who were malicious, and the reward amount to be given to challenger
This is necessary to prevent malicious operators from redeeming bEIGEN2 upon a successful challenge
In this case, we can refer to the fork of bEIGEN1 as bEIGEN2
Token distribution after challenge results
In the case of a successful challenge, bEIGEN1 stakers or holders will be able to redeem bEIGEN2 (now considered the canonical token). A portion of bEIGEN1 that was held by malicious operators will be burnt to pay for social costs of forking. A portion of bEIGEN1 will be rewarded to the challenger. EIGEN is reconfigured to be backed by bEIGEN2 instead of bEIGEN1.
In the case of an unsuccessful challenge, the CPF put up by the challenger will be burnt to pay for the social costs of forking.
EIGEN: Facilitation of Resilience in AVSs
EIGEN and bEIGEN play a key role in providing cryptoeconomic security for AVSs when it comes to addressing intersubjective faults. Given the variety of AVSs that are being built on EigenLayer, there is the possibility of increasing amounts of intersubjective faults which will warrant forking. Examples might include data withholding from operators for a data availability (DA) AVS, or false representation of asset prices from an oracle.
In addition, the dynamics of EIGEN and bEIGEN have been designed in a manner to allow users to have a seamless experience when interacting with AVSs. For example, if a user is using a DeFi protocol built as an AVS and a social fork of EigenLayer’s canonical token occurs, EIGEN can continue to be used given its fork-unaware nature.
Exploring the AVS Landscape
The AVS landscape has been growing constantly, with a myriad of verticals being built, including DA solutions, co-processors, interoperability infrastructure, and many more. This report covers two prominent AVSs in detail: EigenDA and Omni Network.
EigenDA is the first AVS to be launched, serving as a way to stress test EigenLayer. The second phase will allow for permissioned AVSs, and eventually, EigenLayer is working towards a fully permissionless AVS ecosystem.
EigenDA
What is EigenDA?
The first AVS to launch on EigenLayer, EigenDA is a secure and scalable DA layer inspired by danksharding. Data availability (DA) layers offer trustlessness by making data available for verifying the rollup’s history and the legitimacy of transactions. EigenDA aims to allow rollups to send transaction data to the Ethereum consensus layer in a cost-efficient and scalable manner by distributing the data among many participating nodes. This reduces the cost incurred by each individual node in verifying and storing the data, creating a scalable DA solution.
EigenDA addresses the lack of scalability faced by DA solutions today, where validators on Ethereum are required to download and permanently store large chunks of data, causing it to become more expensive as rollup activity increases, limiting the number of validators that are able to participate and potentially causing centralization. The recent EIP-4844 introduces a new transaction type known as blobs which can reduce the cost of committing data to Ethereum, but this comes at the trade-off of lack of data permanence.
Architecture
There are three main stakeholders involved in EigenDA’s architecture:
Operator
This refers to third-party operators that opt-in to secure EigenDA with ETH and liquid staking tokens (LSTs) that are delegated to them. Operators run the EigenDA’s node software and are in charge of storing blob chunks and providing blob data to other parties (e.g. rollup challengers) when requested.
Disperser
The disperser acts as a communication layer between roll ups and DA nodes (EigenDA operators), where it receives blobs from rollups, and generates proofs for the validity of the blobs, before passing them on to the operators for verification.
Note: EigenDA’s liveness is currently dependent on a centralized disperser. The disperser will be decentralized over time. Should EigenDA be down or censoring data, rollups can run their own disperser as a backstop mechanism.
Retriever
Stakeholders that request blob chunks from operators, reconstruct the entire original blob for verification.
EigenDA’s Mechanism
The detailed architecture and dynamics among the three stakeholders can be described as follows:
Rollups send data blobs to the dispenser after the rollup sequencer has created a block
The disperser uses the erasure encoding scheme to shard data blobs into chunks
The disperser sends the following to the operator
KZG commitment
KZG multi-reveal proofs
Data chunks
Operators verify the data chunks by comparing them against KZG commitment and proofs
Operators’ signatures are generated and sent to the disperser once they have verified and stored the data chunks
Disperser aggregates operators’ signatures into a DA attestation, which is uploaded to the EigenDA manager contract on Ethereum (in calldata form)
EigenDA manager contract verifies the aggregated signature and stores the results on-chain
Traction
EigenDA currently supports both the OP Stack and Arbitrum Orbit chains. Some of the L2s that have committed to integrating EigenDA include Celo, Mantle, Fluent, Offshore, and LayerN.
Benefits of EigenDA
Higher DA Throughput with Horizontal Scaling
There are a couple of architecture designs made by EigenDA for it to achieve higher DA throughput:
Lightweight DA Attestation
As mentioned in the architecture section above, operators on EigenDA are only required to verify and store a small amount of data. As more operators join the network, the costs incurred by each operator continue to decline with a smaller amount of data each time. Thus, EigenDA is able to decentralize at a marginally decreasing cost.
Unicast
With existing DA solutions, a peer-to-peer (P2P) network is used to transmit rollup blobs, where operators gossip and re-broadcast the same blobs among themselves.
EigenDA disperses blobs directly to operators (known as unicast), reducing the latency associated with blobs gossiping (blobs transmission process).
Increased Security
A point of failure in DA systems occurs when nodes download and verify data blobs, but do not store the data.
EigenDA addresses this by using proof-of-custody. A function is distributed to operators routinely, which can only be computed and committed by operators that have stored all the data chunks that were dispersed to them. Should an operator submit a signature to attest for verified blob chunks without showing proof-of-custody, they are at risk of being slashed.
EigenDA’s security is further enhanced through the dual staking quorum, where DA has to be attested by both the ETH quorum (with restaked ETH) and rollup’s native token quorum. EigenDA treats these two quorums independently, requiring both quorums to be reached before DA is attested. This significantly increases the cost of exploitation as users will have to take control of both pools.
Lowered Cost of Running DA Layer on EigenLayer
EigenDA’s unique position as an AVS helps it to reduce costs on two fronts.
Capital Cost: Typical DA layers are secured by stakers that require a certain percentage yield to offset the opportunity cost of staking. This requires the DA layers to put upfront capital to bootstrap stakers. With EigenLayer’s shared security model, EigenDA can tap on the available restaked ETH, which can be utilized across a variety of applications. This reduces staker’s opportunity cost and thus also decreases the capital cost for EigenDA.
Operational Cost: EigenDA utilizes the erasure encoding scheme to split rollup data into smaller chunks before dispersing them to operators. Operators are thus only required to download, verify, and store a data chunk. This is a lightweight approach that decreases the operator’s costs, and thus the yield that EigenDA has to pay out.
Competitors
The main cost that roll ups pay today takes the form of posting and retrieving data from Ethereum. Protocols and infrastructure alike have explored other DA solutions aside from Ethereum. These alternative DA solutions take a modular approach by allowing rollups to post and retrieve data in a cheaper manner.
Competitors in the DA vertical include Celestia, Near DA, and Avail DA. The key differentiation brought about by EigenDA comes from it’s high throughput of 10 MB/s and fast finality time of less than 1 second. In the future, EigenDA seeks to further increase the throughput, making it orders of magnitude higher than what both existing solutions and Ethereum Danksharding will be able to offer.
Omni Network
What is Omni Network?
Omni Network is an L1 interoperability solution aimed at addressing the incremental fragmentation experienced with the rise of rollups, which comes in the form of fragmented liquidity (assets are siloed on different rollups), complex user experience where users are required to navigate different rollup interfaces and asset bridging.
Omni Network serves as a unification layer for all rollups, offering secure and efficient cross-rollup communications.
Interoperability solutions can largely be said to have two key tasks: (a) Verify the state of the source network and (b) Relay state updates accurately to the destination network. In addition, they are expected to showcase these features:
Secure: Ensure that state or assets are relayed securely and not lost in transmission
Performant: Enable cross-chain messaging with low latency and high accuracy
Product Suite & Architecture
Omni Network: Enabling Cross-Rollup Message Interoperability with XMsg
This is the process that Omni Network relies on to carry out cross-chain messaging
A user on source rollup submits XMsg (transactions) to an xDapp that uses Omni Network
XMsg is submitted to the Portal Contract which connects the rollup to Omni Network
Omni validators that run full nodes on rollups within the Omni ecosystem pick up XMsgs
Omni Network constructs an XBlock based on the XMsgs received
Validators on Omni Network utilizes CometBFT to reach consensus and attest to the validity of XBlocks for transaction finalization
Attestation can be done by validators with restaked $ETH or staked $OMNI
Permissionless Relayers aggregate signatures and finalized block data, which are submitted to the Portal Contract on destination rollup
xDapp on destination rollup makes a contract call to the Portal Contract to execute the user’s transaction
Omni EVM: Building Natively Global Applications (NGA) on Omni Network
With the ever-expanding rollup landscape, it becomes increasingly difficult for developers to manage application deployments across different rollups due to the complexity of managing distributed states.
Omni EVM is a global orchestration layer allowing for global state management. Omni EVM serves as an abstraction layer that empowers developers to build Natively Global Applications (NGA) by deploying smart contracts and managing the various deployments through a single, unified environment.
By building on Omni EVM, NGAs benefit from the following features:
Compatibility with the broader EVM ecosystem by adopting the EVM execution environment
Sub-second finality achieved with CometBFT consensus
Low barrier to entry with support for Solidity and Vyper
The hybrid EVM and CometBFT consensus framework makes the above features possible by leveraging Omni Octane, a modular framework for the EVM.
Omni Octane: Modular Implementation of EVM
Omni Network uses a hybrid framework that combines CometBFT (Tendermint) consensus engine and the EVM. This is made possible through EngineAPI and ABCI++ which enables the separation of the execution and consensus layer. The EngineAPI reads the mempool for transactions that take place on Omni Network, and these transactions are sent to the consensus layer for validation. An ABCI++ wrapper is added to the CometBFT engine for it to be able to handle the state translation of transactions that are coming from the various execution environments.
On top of supporting Omni EVM, Octane’s modular architecture serves as a flexible framework for developers to choose their desired execution environment and consensus layer based on their needs and preferences. Octane gives developers the ability to incorporate a wide range of execution environments, including EVM-optimized execution like Monad, and even alternate execution environments like the MoveVM by Movement Labs.
Integrated Consensus
Given’s Omni Network’s product suite, it is required to validate both XBlocks (from rollups) and Omni EVM blocks. This is achieved by using ABCI++ vote extensions to append XBlock attestations onto the CombetBFT block generated from Omni EVM, where a finalized block will then be built.
Omni Network’s Benefits
With it’s novel framework, Omni Network brings about a variety of benefits:
High Efficiency and Secure Cross-Rollup Communication
With billions lost through exploits, bridges have been a source of vulnerability while serving as one of the most prominent interoperability solutions. By being secured by EigenLayer, Omni Network is able to cryptoeocnomically secure messages and assets that are being transferred cross-chain, at a lower cost than existing solutions.
Enhanced Developer and User Experience
Existing protocols can be integrated into Omni Network without requiring any modification of their deployed contracts. Instead, modifications are done to the frontend instructions, which will direct transactions to the Omni Portal in charge of processing and executing transactions on other chains. This reduces both the engineering time and cost needed for integrations.
With Omni Octane, developers are also no longer confined to building within a single execution environment. They can choose the desired execution environment based on their needs, and in the case where they decide to deploy on multiple chains, they will also be able to manage the different states in a single environment.
The user experience of interacting with rollups will significantly improve, as users will only need to interact with a single interface, without having to manouver through the complexity of moving assets or executing actions across rollups.
$OMNI Tokenomics
The chart below shows the distribution of $OMNI to the √arious stakeholders within the Omni ecosystem. Noticeably, a large proportion of $OMNI (29.5%) is being allocated to ecosystem development. In the initial phases, the allocation of $OMNI to project building on Omni will be at the discretion of the Omni Foundation, with plans to pass on this voting power to users eventually.
The following chart plots out the change in $OMNI circulating supply over time. It can be observed that there is a slightly steeper increase in circulating supply when approaching April 2025. This is due to the maturation of investors' and advisors’ vesting schedules, which have a 1-year cliff. With this unlock entering the circulating supply, it is worth keeping a look to see how $OMNI’s price will react.
OMNI Utility
OMNI is Omni’s native token that is used in these areas of the Omni ecosystem:
Universal Gas Marketplace
Given Omni’s unique proposition of being a unified liquidity layer, it also provides a universal gas marketplace by allowing users to handle gas payments in diverse assets with a pay-at-source fee model. Users can choose to settle gas payments with their choice of asset on the source network, which are then swapped into OMNI. Relayers that are responsible for facilitating the transfer of assets or messages cross-rollups will be compensated with the OMNI.
This creates a gas abstraction primitive, removing the complexity of acquiring gas tokens before being able to transact on a chain, significantly enhancing user accessibility.
Omni also makes it possible for users to obtain OMNI on any rollup within the Omni ecosystem, and settle gas with OMNI. omni supports EIP-1559 and thus has a dynamic fee mechanism where users can pay higher OMNI fees for their transactions to be prioritized.
Economic Security
Omni Network uses a delegated proof-of-stake (DPoS) mechanism and can be secured by users staking OMNI. in return, OMNI stakers are rewarded with OMNI emissions, and potentially fees accrued towards OMNI.
Omni Governance
In the future, OMNI can be used to participate in governance, where users get to decide on protocol-related parameters, including upgrades to the network etc.
The Challenges of Being an AVS
With the novelty of EigenLayer, various aspects need to be taken into account by AVSs.
Encoding Logic for Intersubjective Faults During Setup Phase
AVSs are required to go through a setup phase when they seek to be secured by EIGEN and bEIGEN. During this phase, AVSs will need to encode the intersubjective agreement rules into their protocol design, which could include slashing conditions for malicious operators or wrong challengers, the sum of DPF and CPF, and others. These rules will have to be followed when an intersubjective fault arises in the future.
The above is essential in ensuring the AVS remains secure during an intersubjective fault. The agreement rules pre-determined will be a crucial factor in determining whether malicious operators can be removed from the set efficiently.
There has yet to be a standard put forth by the EigenLayer team pertaining to the kind of agreement rules that have to be implemented by AVSs. Thus, AVSs might potentially have to experiment with the rules to find out what suits their protocol needs the best.
Management of AVS Security
There are three main areas that can potentially impact an AVS’s security.
Balancing Cryptoeconomic Security Sources
An AVS can derive cryptoeconomic security from a variety of sources: (a) restaked ETH (b) AVS native token (c) EIGEN. The AVS will have to determine how much of their cryptoeconomic security will be derived from each of these sources, and this can potentially fluctuate over time.
Managing Restaked ETH Volatility
In the case where a huge portion of restaked ETH is removed from EigenLayer, an AVS’s cryptoeconomic security will momentarily be lowered, potentially causing a period of instability. The magnitude of this decrease is dependent on the security allocation to restaked ETH.
When this happens, an AVS could be at a higher risk of being exploited. Thus, it is important to establish partnerships with liquid staking tokens (LRTs) to maintain stability in AVS security.
Voting Rights
The voting rights allocated to the various stakeholders (ETH restakers, AVS native token holders, EIGEN token holders) within the ecosystem has to be considered.
It is important to consider whether there might be possibilities of any single stakeholder or individual having a disproportionate level of influence over the AVS’s upgrades.
Yield Management
One of the key benefits received by AVSs is the lowered capital cost in building since it is possible to leverage on the cryptoeconomic security from restaked ETH. However, given the various stakeholders AVSs have to work with, the distribution of yield (either inflation or revenue) will have to be determined in a manner that ensures the longevity of the AVS.
Given the large number of LRT protocols in the market, it is important for AVSs to select strategic partners to work with. This is extremely important as the restaked ETH in these LRT protocols essentially form the supply side of EigenLayer, which is demanded by all AVSs.
Advancing AVSs - The Road Ahead
The AVS landscape is looking promising, with a growing number of projects building on EigenLayer. Given EigenLayer’s growth in the past year, AVSs have a promising supply of cryptoeconomic security (restaked ETH) readily available for them to tap on.
The diversity of AVSs being built has also been expanding rapidly, with the current landscape featuring applications from various verticals, including:
Coordination Networks: Witness Chain
Coprocessors: Automata and Brevis
Interoperability: Lagrange
Oracles: eoracle
The team at EigenLayer is active in potential applications and infrastructure that can be built on EigenLayer, with some examples being pre-confirmations for fast finality, high-performing L2s, and many more others. With a burgeoning ecosystem, it is interesting to keep track of the synergistic relationship within the AVS ecosystem, as well as the potential synergies with protocols outside of EigenLayer.
Check out https://app.eigenlayer.xyz/avs for the entire AVS landscape.
Disclaimer
The Blockcrunch Podcast (“Blockcrunch”) is an educational resource intended for informational purposes only. Blockcrunch produces a weekly podcast and newsletter that routinely covers projects in Web 3 and may discuss assets that the host or its guests have financial exposure to.
Some Blockcrunch VIP posts are written by contractors to Blockcrunch and posts reflect the contractors’ independent views, not Blockcrunch’s official stance. Blockcrunch requires contractors to disclose their financial exposure to projects they write about but is not able to fully guarantee no such conflicts of interest exist. Blockcrunch itself will not buy or sell assets it covers 72 hours prior to and subsequent to the publication of a piece; however, its directors, employees, contractors and affiliates may buy or sell assets prior to or subsequent to publication of any content and will make disclosures on a best effort basis.
Views held by Blockcrunch’s guests are their own. None of Blockcrunch, its registered entity or any of its affiliated personnel are licensed to provide any type of financial advice, and nothing on Blockcrunch’s podcast, newsletter, website and social media should be construed as financial advice. Blockcrunch also receives compensation from its sponsor; sponsorship messages do not constitute financial advice or endorsement.
For more detailed disclaimers, visit https://blockcrunch.substack.com/about
 | A guest post by
|