Cover photo

Restaking

The role, the motivation, and the risks

Executive Summary

One of the most groundbreaking advances in the 21st century was the proliferation of open-source code. This allowed multi-faceted problems to be solved more efficiently, in part due to the transparency offered by that open-source nature. Linux, the best-known and most used open-source operating system gained popularity because it allows a high degree of customization to the core operating system, something that would not be possible while remaining safe without being open source.

That is all to say, permissionless innovation and sometimes, breaking things, is when progress is made. EigenLayer is making significant contributions to further the use of Ethereum’s security model and is reducing the barriers to entry for infrastructure and middleware projects to launch their own network. However, there are certain risks that could arise with unchecked proliferation of a primitive such as restaking. EigenLayer, and the various teams that we have performed diligence with during this research are all acutely aware of the challenges and are actively working to ensure that the benefits of restaking can be realized, while staying aware of potential risks.

This piece will explore restaking, the innovation, the role, and the risks.

Blockchain Security

The term “security” is used broadly when discussing blockchains, but we think it’s important to recognize there are multiple contexts in which security can be used. While security extends beyond consensus to encompass areas such as smart contract security, wallet and key security, upgrade security, and other layers in which security is a consideration, for the purpose of this article we will be using the term “security” to refer to network security, which is the robustness of the blockchain against attacks. We acknowledge that security and decentralization are separate but sometimes related, especially in the context of censorship resistance.

For this piece, security encompasses measures, mechanisms, and properties that ensure the network operates correctly, prevents fraudulent activities, and resists attempts to compromise its data. In practice security requires a mechanism such that coordinating an attack becomes prohibitively costly, complex, or mathematically infeasible. Historically Ethereum used Proof-of-Work (PoW) as its consensus mechanism, which ensures security because changing historical data would require redoing the work (hence "proof of work") and outcompeting the combined computational power of all honest nodes, which is infeasible. After “The Merge”, Ethereum moved to a Proof-of-Stake (PoS) consensus mechanism, where validators are chosen to propose (or submit) new blocks during a pseudo-random selection process which considers, among other things, the number of coins they hold and are willing to "stake" or lock up as collateral. Misbehavior can lead to loss of the staked coins via slashing, providing an economic incentive for honest behavior, and a robust mechanism to de-incentivize attacks.

However, features such as PoS alone are not enough to safeguard against attacks such as 51% attacks[1], or sybil attacks[2] to name a couple. The security of Ethereum, for example, relies in part on the decentralization of its infrastructure, including validator, client, or other infrastructure pieces such as proposers, which can each be susceptible to centralization (MEV oligopolies). The more decentralized the infrastructure and validator set, the more costly and infeasible a hypothetical attack becomes. A mature and decentralized token model can also help security, as access to liquidity is sufficiently distributed, and the cost of amassing enough stake makes an attack economically infeasible.

This gives infrastructure projects a lot to think about when launching their network. Seeding trustworthy validators and establishing economic security can result in poor levels of decentralization and high levels of token emissions at the very beginning of the protocol’s lifecycle. For a long time, this was an unavoidable process for middleware networks, until the concept of restaking was born.

Restaking, An Introduction

Pioneered by EigenLayer, restaking, sometimes referred to as “pooled security”, is the process of taking liquid staked ETH deposit tokens such as Coinbase’s staked ETH (cbETH), or Lido’s staked ETH (stETH) and using them to extend the security of Ethereum to the networks on top of EigenLayer.

 

With the use of EigenLayer, projects do not need to attract their own validator set to bootstrap security. These middleware protocols, known as Actively Validated Services (AVSs) will have their validator specification as a module on EigenLayer. Validators who want to operate a module on EigenLayer (Operators) can then “opt-in” to each module on EigenLayer, and in doing so will be extending their validation services to the AVSs they opt in to and will receive additional revenue for the provisioning of these services. Operator participation in EigenLayer requires setting their Beacon chain withdrawal address to the EigenLayer smart contracts, which will individually check each validator for slash-able offenses against each AVS module the restaker has opted into, before allowing for the withdrawal of stake via the EigenLayer smart contract after the withdrawal delay period has passed. AVSs can set their reward rate, denominated in the project’s token of choice, and paid out to participating validators. Delegators can then delegate their liquid staked ETH to participating operators to increase the security of EigenLayer, and to reap the additional yield gathered from providing security to these platforms[3]. The cost being the risk of slashing on the EigenLayer platform. Tying this back to our definition of network security we can observe that the pooled security model will need an attacker to corrupt a much larger pool of funds, making it economically infeasible to carry out attacks, ultimately raising the “cost-of-corruption”[4] from the minimum stake (per AVS) to the sum-of-the-stake across all AVSs and the L1.

Potential Benefits of Restaking

For AVSs and Developers

The benefits of pooled security are clear for protocols and developers. They get access to a network of proven validators, at a fraction of the cost and effort of spinning up their own validator set. Especially at the beginning of a project lifecycle. This is because AVS costs, which are primarily validator operational costs, are shared among all AVSs as one operator may operate more than one AVS.

For Validators and Delegators

EigenLayer provides validators and delegators with an additional avenue to generate yield on their already yield-generating staked ETH. This is because EigenLayer can act as an “open marketplace where AVSs can rent pooled security provided by Ethereum validators”. Furthermore, the ability to opt in or out of certain modules allows validators to retain the autonomy they currently have in choosing which networks to validate and does not force them to align with a project that they do not wish to align with. Allowing the benefits of additional yield, but without removing validator autonomy.

For Ethereum

Besides adding to ecosystem growth by bringing projects that wouldn’t otherwise be directly tied to Ethereum, EigenLayer enhances yield, making ETH, or specifically liquid staked tokens, an attractive asset to hold. However, there are some considerations that will be covered in the risks section of this paper.

For the Modular Stack

EigenLayer makes many components of a “modular blockchain thesis” possible by removing barriers to entry such as bootstrapping a validator set. Pooled security coupled with data availability (retrievability) solutions now provides the building blocks for a Cambrian explosion of AVSs.

Risks

Rehypothecation

Restaking is not rehypothecation. But it has been compared to rehypothecation in the past. Why?

Rehypothecation refers to the practice of a bank or broker using assets that have been posted as collateral by their clients, to back its own transactions and trades by accessing credit using those pledged assets. This in turn increases the leverage of the underlying assets, but with the benefit of a lower cost of capital due to the shared collateral base. Rehypothecation was a common practice until 2007, but in the wake of the Lehman Brothers collapse and subsequent credit crunch in 2008-09, the practice has been heavily scrutinized.

In finance, rehypothecation increases effective leverage, and in turn, makes the underlying asset holder more exposed to price movements on the asset. Furthermore, the toxicity of the asset at any given point is unclear, given the complicated creditor issues that arise from the fact that the rehypothecated asset is technically pledged for by another party’s debt and in the case of a custodian default, the assets are no longer in their possession.

However, with respect to restaking, instead of being susceptible to price movements against the dollar, the restaked asset is susceptible to slashing events on the base chain. Rehypothecation in the context of restaking could also increase the complexity of the tokens that come from a restaking environment. To mitigate against this obfuscation risk, itself a key driver of the 2008 financial crisis, we would propose active monitoring of the underlying at every point of restaking.

In traditional rehypothecation, if a house acts as collateral for a loan which is then used by the lender to secure another line of credit and the original lender fails, the lender who accepted the rehypothecated assets would have a claim to the original house. In the case of restaking, the lenders are the operators, and “failing” would be the equivalent of a slashing event and the node operator delegate balances decreasing as a result. This is why EigenLayer validators need to list an EigenPod address as their withdrawal address, such that there is slashing recourse available in the case of operator misbehavior.

Restaking means that the asset is being pledged to an institution/validator and is at risk of being slashed in the case of operator misbehavior, but it is the original borrower pledging the asset.

Therefore, as the user opts to participate in the repledging of the asset, restaking and rehypothecation are different. EigenLayer also directly address this in their docs:

[5]

While I agree that restaking is not the same as rehypothecation, I question the claim that stakers retain “full” control over their staked tokens. It is true that delegators retain their keys, and therefore access to their tokens, however, is it fair to say that full control is retained when the tokens exist in a non-zero risk of slashing environment? To that tune we would argue Schrödinger’s token, where the tokens are both slashed and not slashed until they have passed through the withdrawal address. While the delegators can be certain of having control of their assets, they cannot be certain that the notional amount will be available for withdrawal until the delegation has passed through the withdrawal address.

Stakers do have full autonomy over the services they wish to validate, and while they are not exposed to counterparty liquidity risks, they are exposed to counterparty risks generally if they restake via a LST.

EIP 7002

EIP-7002[6] looks to implement ‘execution layer triggerable exits’ which allows validators to trigger exits to the beacon chain from their execution layer withdrawal credentials. While this addresses a potential DDOS attack vector, it also means that their EigenPod owner (themselves or LST/LRT providers) ultimately control the assets.

The EIP explicitly states that “The withdrawal credentials ultimately own the funds”. For native stakers this is not an issue, as they own the EigenPod address and therefore full control of the tokens, but in the case of LRT restakers, the LRT issuer will own the EigenPod address and therefore technically controls the assets restaked through them.

Ultimately this is not a concern, given the role of LRT providers as risk managers providing access to increased yield while surfacing risks. The reason we call it out is because currently over 66% of TVL on EigenLayer is restaked via LRT tokens compared to ~33% natively, meaning most restakers don't retain 'full control' technically, but they do in practice as they manage the strategy manager and are presumably aware of the risk of slashing when they initially restake. It is a technicality to consider for potential ramifications for the role of validators/ LRT providers/ LST providers, and whether or not they act as asset managers.

Cascading Security

There are two main avenues security provided by the EigenLayer protocol can decrease, validator slashing, and removal of stake from the platform for any reason. While slashing risk has been discussed extensively, we have seen limited attention given to the increasing competition in the restaking market.

Slashing Risk: Node operators that sign up to be validators for a restaking protocol will naturally be performing “validating” or other actions for not only the Ethereum chain, but also every AVS that a given operator has opted-in to validate on the restaking platform. As a result, the level of slashing risk increases, but so does the yield. There are a few points to discuss further here:

-          Trust: The need for participating operators to update their withdrawal address to an EigenLayer withdrawal address is necessary for restaking to function. Without this setup, EigenLayer has no way of effectively slashing a misbehaving validator. However, this setup is also a trusted one. You must trust that EigenLayer’s AVS will act as promised and will not improperly slash you or any withheld stake. While this is unlikely, it is the trade-off that comes with a trusted setup. This dynamic exists at the base layer with crypto-economic security of AVSs depending on it. Any contentious decision made at this level could have damning ramifications for the rest of the restaked ETH on the platform, which could rush to exit if they don’t agree with the slashing decision. EigenLayer does state that a highly trusted and reputable quorum of reviewers will be able to review the slashing event and potentially avoid it, but this is very much a trusted setup.

-          Diminishing Returns: Restaking increases yield, but also increases risk. For stakers/ delegators, is the increased risk proportional to the increased yield? I would argue not proportionally. With every new AVS added to the validator’s set of chains, there is compounding risk of slashing. While it is true that there is also compounding yield, I would argue that the compounding yield would not be proportional to the compounding risk, since projects at the start of their life are less likely to have token models that are as robust as ETH, and can move independent of ETH, therefore reducing the level of compounding occurring. 

Competition: While slashing can be immediately obvious as a potential cause of cascading security, one lesser acknowledged avenue of potentially cascading security is derived from increasing competition in the restaking ecosystem.

 

[7]

Liquid Staked Tokens (LSTs) have been one of the only categories of protocol that have seen combined TVL growth during the 2023 period and are currently leading combined TVL across these categories with ~$40b in combined TVL. LSTs enable you to earn staking rewards on your tokens while receiving a traceable and liquid receipt.

With this growth in LSTs in mind, and with the expected continuation of LST restaking for additional yield, many protocols are capitalizing on this capital efficient liquidity by offering new avenues of yield generation for LST holders. What this has resulted in is an increasingly competitive environment for protocols offering yield on LST assets.

[8]

This increasing competition makes using LSTs for bootstrapping security and validator incentives a dynamic task. While EigenLayer still dominates in market share, we must expect that there will be more future competition for attracting LST volumes. We speculate that some of the LST volume that has been pledged to EigenLayer is chasing airdrop eligibility for future airdrops, while this has been vastly successful in helping bootstrap liquidity on Eigenlayer, it creates a liquidity base that could look to other opportunities when they feel the opportunity cost of giving up their LST to EigenLayer is no longer worth it, take Morpheus for example who have been able to attract over 60,000 stETH in deposits in less than a week. This can pose a problem to teams looking to build on EigenLayer and the protocol itself in evaluating what their total crypto-economic security level will be at some future point in time.

EigenLayer implements measures to safeguard against this problem and the problem of withdrawing stake from the platform more broadly. Firstly, it allows module developers to choose for themselves which tokens to accept as stake for their AVS, meaning developers have the choice to exclude a particular “modality of staking” from their AVS. For example, a module that values decentralization above all else may decide to only accept restake in the form of natively staked ETH, and not ETH LP restaking, or LST restaking.

Another safety measure they implement is the introduction of a 7-day withdrawal delay. While the team acknowledges that this is the current “maximally conservative withdrawal delay” it introduces a potential dampening on protocol growth depending on how long the withdrawal delay is kept in place for. This is due to the increasing velocity of LSTs more broadly.

While the “nation states” analogy has been made multiple times in relation to crypto networks, a basic filler for Nominal GDP for blockchain networks is the on-chain transaction volume of the corresponding crypto asset[9], and so the velocity of crypto is:

As FDV changes are on a longer timescale than transaction volume changes, we can observe that increased use of LSTs increases their velocity. Furthermore, with increased avenues of yield generation for LSTs we can expect increased rotation of assets between various venues to also increase the velocity. EigenLayer is in a position where it stands to lose market dominance because of this increasing velocity unless withdrawal delays on the platform are lower than its peers in perpetuity. Looking at other protocols that offer yield on LSTs like Prisma and Curve, we see that they implement no withdrawal delays and offer comparable yield.

This is primarily due to these competitors’ use of LSTs compared to EigenLayer’s. Where EigenLayer is using LSTs for crypto-economic security, protocols like Prisma and Curve are using them for DeFi. The risk considerations that are given to a DeFi use case of LSTs are very different to the risk considerations of crypto-economic security use cases for LSTs. This dynamic and fundamental trade-off introduces a level of opaqueness to the future of EigenLayer’s TVL, especially in the face of increasing velocity.

Projects such as Ion Protocol, and EtherFi are looking to provide solutions to these frictions. Having restaking ‘managers’ to manage risk and optimize for whatever the user wants to optimize for would allow for prudent use of restaking, ensuring that it is a sustainable endeavor. It would also allow for a far more stable base of asset provisioning to EigenLayer, as EtherFi and other LRT providers would be facilitating the liquidity access needed for adding and removing exposure to EigenLayer yield, without having to stake or unstake on the EigenLayer platform directly.

Governance and Underwriting Risk

While there will be many validators on the network, as we think about the total amount of restaking occurring on the platform, it is reasonable to expect a significant portion to originate from delegators. However, the decision that a potential delegator makes on Ethereum mainnet is a very different decision to the one they would be making on a restaking platform such as EigenLayer.

The reason is simple: On mainnet Ethereum, due diligence of a validator has clearly defined criteria. Historical uptime, historical slashing, and the scope of future work the validator will have to complete are all common metrics by which validators are judged. On a restaking platform, while historical uptime and historical slashing will be similarly available albeit with limited history, validator scope cannot be predetermined. That is due to the fact that a validator may opt to secure a new AVS, and thus implicitly passing on a series of new risks that were not underwritten by the delegator originally, or a restaker pushing a validator to support more AVSs and increase their yield, leading to the commonly referred to “principle-agent” problem. While the delegator has the ability of choosing which AVSs they opt-in to pledge their economic security to, this additional hurdle adds to the lift associated with being a delegator.

We think it is increasingly important to surface the compounding of risks for delegators and operators alike, as they will not necessarily be aware of what they are respectively optimizing for. Doing so will also provide a more scalable environment for EigenLayer as they are improving information flow to delegators who may elect to rotate their stake if they find their validator is no longer serving their best interest. A dashboard to surface risks would be a prudent feature and has been discussed before[10].

Malicious Validator and Skewed Incentive Risks: Validator Preference and MEV/ Censoring

While the success of a platform such as EigenLayer relies on a partially trusted setup at launch, to best control risk, the long-term view should always be to create a permissionless implementation of the platform to enable full realization of scaling. This prompts us to evaluate what needs to be addressed before permissionlessness is enabled.

Operator collusion is one that should be mentioned here.  EigenLayer supplies crypto-economic trust, in the form of restaked tokens, but Ethereum’s trust model does not solely rely on crypto-economic security, it is also about ensuring collusion resistance.

This is because slashing can only really protect against objective actions, e.g. double signing, it does not prevent un-slashable activities which are activities that cannot be attributed to a single party. An example is a protocol that provides a marketplace for secret sharing. If you share a secret with N parties, on the basis that they do not collude and share that secret with each other, you are not left with slashing recourse on the corruption of that secret as it is not attributable to a single party.

Solo Staker Erosion

One of the things to be cognizant of with the release of restaking as a primitive will be the second order effect it could have on the validator set of Ethereum. Ethereum’s network health lies in part with its level of decentralization. Solo stakers greatly increase the decentralization of Ethereum by distributing the power and responsibility of validating transactions across a wider range of individuals, rather than concentrating it in a few large entities or staking pools. While native restaking does allow any solo staker to participate without requiring liquid staking intermediation, it is important to also highlight how restaking could erode solo staking participation over time.

Centralization

The rise of restaking could lead to centralization if it significantly reduces the barriers to entry for large staking pools or more institutional staking groups. These groups of institutional node operators are generally able to handle running much more infrastructure than solo stakers, due to their access to more hardware and the efficiencies that result from spreading costs of hardware across the rewards they gain from validating multiple networks at once. The added incentives from validating AVSs could appeal to these institutional groups as they can easily absorb the added technical complexity and overhead associated with this additional validation, while the added technical complexity and overhead could drive the participation of solo stakers down and lead to centralization pressure on the Ethereum validator set.

Economic incentives

The enhanced rewards offered by EigenLayer to delegators might lead solo stakers, who find the increased validation requirements challenging, to exit the network. Instead, they may choose to delegate their ETH to an AVS operator in order to capitalize on these additional rewards, rather than continuing with solo staking.

Eigenlayer is clearly thinking about these issues in depth and are proactively engaging the community of solo stakers to create a working group that will help ensure that restaking can proliferate while keeping the needs of solo stakers in mind.

Dilution of Ethereum Security

One of the primary concerns with the use of restaking platforms for economic security is the possibility for skewed incentives that it provides. We covered the ability for such dynamics to alter the behavior of validators in the section above, but how are the mechanics of restaking altering incentives for potential attackers?

The AVS is secured by the value of staked Ethereum, which is about $89bn at the time of writing. To “51% attack” Ethereum you would actually need about 67% of the total stake on the network, after accounting for all of the ETH you will be staking during the course of the attack. The theory is that this attack vector is infeasible because of the prohibitive cost, however it doesn’t account for the value of the AVSs that are also secured by that same stake.

In practice this risk is de minimis and arguably impossible. Given the fact that the Ethereum staking ratio is ~24.37% and increasing it makes the task of finding sufficient liquidity and entering the validator queue without raising questions extremely challenging at best.

Needless to say, we do not think restaking poses a risk to the security of Ethereum as a result of “dilution” of the security, dilution here loosely defined as

where rewardE and rewardAVS are the maximum values that could be extracted as a result of attacking Ethereum and all AVSs (that they are able to successfully onboard in order to even attempt an attack) respectively.

However, we do think that this “dilution” could serve as a useful metric on keeping the use of restaking prudent.

Leverage

You may be wondering, why are you talking about leverage? Why does restaking need to be kept at some arbitrary level? How do you even define what level of “dilution” is acceptable?

Bear with us for a moment.

Leverage increases susceptibility to price movements traditionally. To that extend restaking is NOT increasing leverage, but it is increasing susceptibility to a loss from slashing events, and potentially layering those slashing events. This is the form of 'leverage' on EigenLayer.

Restaking increases the risk of a total loss of stake as a function of individual slashing events.

In the future of the financial systems that will sit upon Ethereum, whether existing on Ethereum L1, some L2, a sovereign rollup, an AVS or even as a scribble book that some kid computes hashes of by hand and sends the reconstruction data to Ethereum via a manual transaction (that's all he does). If they are inheriting the economic security of Ethereum, then they should be aware of how much that economic security is securing at any given moment.

Bitcoin exists in part, due to the events of the global financial crisis in 2008. The 2008 crisis was largely as a result of rehypothecation of toxic assets, which was made possible due to obfuscation. Something that Bitcoin was designed to uniquely solve for. Blockchain technology provides transparency, but without definitions of concepts such as “acceptable levels of sharing economic security”, we would argue the full promise of transparency inherent in blockchains is not realized.

These future institutions could see staking Ethereum as access to the risk-free-rate. If there are yields available for the same core concept of staking to a validator, that are considerably higher than the RFR, then it would make sense to classify that additional yield as a function of the RFR and some additional risk.

Not only would this serve as an important metric of how much work the Ethereum economic model is doing (and potentially a basis of analysis for the “real” value of Ethereum) but we believe it will be more useful within underwriting, as a continuous basis for monitoring toxicity by providing auditability.

Entropy is relentless. As a network such as Ethereum matures, the rate at which financial derivatives occur increases exponentially. Let us imagine a scenario where a newly launched AVS is offering a liquid staked version of their token in exchange for staking the protocol token to reduce early sell pressure or as a governance requirement.

While free markets usually account for the various discounts on pricing that should apply at each level of rehypothecation, using the “leverage” at any stage as a basis for underwriting would help promote more efficient markets.

Another way of approaching the problem is by applying discounts at every level of restaking, which would reflect the risk associated with the asset at that stage. For example, Lido stETH trades currently at 0.9988 ETH, meaning the free market has priced the risk of Lido failing at 0.12 basis points. If such free-market pricing were carried through each level of asset issuance, it could help accurately reflect the market priced value of the asset, regardless of what stage of ‘rehypothecation’ it is at, and in turn avoid toxicity within assets being obfuscated. However, implementing such a design is non-trivial, and currently infeasible given the frequency at which these free markets reprice.

While I was writing this paper EigenLayer published a thread which spoke about attributable security, which I find to be related to this notion of defining risk. It is encouraging to see the pioneers of this innovation take an astutely cautious approach.

Conclusion

The unique allure of blockchain development lies in its permissionless nature. The trajectory of advancement within this realm is not dictated by normative judgments of necessity, but rather by the pulsating force of demand. This demand-driven progression underscores a fundamental pillar of blockchain technology: the power of incentives.

The concept of “safe” security is subjective and evolving within the blockchain ecosystem. Notably, as restaking highlights, there's a growing push for the adoption of Ethereum’s crypto-economic security model. This paper aims to shed light on the reasons fueling this demand and to ponder the potential consequences of this shift.

We welcome further dialogue and encourage those interested in delving deeper into the themes of this paper to connect with us. Please do not hesitate to reach out, even if just to say you think we are wrong!

Many thanks to all who helped with feedback for this piece: Chunda of Ion, Bridget of Founders Fund, Clayton and Dougie of Figment, Ivan of multiVM, David Lawant of FalconX, Ian and Teddy of Kai.ros, the BWR folks, Xavier of Chorus One, and more.

References

-         https://notes.ethereum.org/@anderselowsson/MinimumViableIssuance

-          https://starrwilliam.medium.com/leveraging-staked-eth-the-good-the-bad-and-the-eigenlayer-a8112fd6b895

-          https://www.blog.eigenlayer.xyz/ycie/

-          https://eips.ethereum.org/EIPS/eip-7002

 

 



[1] https://www.coindesk.com/learn/what-is-a-51-attack/

[2] https://academy.binance.com/en/articles/sybil-attacks-explained

[3] It is worth noting that the role of delegating, and operating are disconnected. Liquid Staked Token holders tokens are deposited in proxy contracts that can be sent to a burn address by the slashing manager. An Ethereum validator can delegate their stake to the AVS operator and does not necessarily have to act as an operator too.

[4] EigenLayer WhitePaper - Section 2.0 page 4

[5] https://docs.eigenlayer.xyz/eigenlayer/risk/risk-faq

[6] https://eips.ethereum.org/EIPS/eip-7002

[7] https://defillama.com/categories

[8] Source: Defimochi - https://dune.com/defimochi/

[9] https://medium.com/@cburniske/cryptoasset-valuations-ac83479ffca7

[10] https://twitter.com/MaanavKhaitan/status/1629961751575015425

For informational purposes only, and should not be relied upon as legal, business, investment, or tax advice.  The views expressed herein are those of the author as of the time of writing and may not necessarily represent the views of CMT Digital and its affiliates. Certain information contained in the piece has been obtained from third-party sources, including from portfolio companies of CMT Digital. While taken from sources believed to be reliable, CMT Digital has not independently verified such information.

 References to any securities, digital assets, tokens, and/or cryptocurrencies are for illustrative purposes only and do not constitute a recommendation to invest in any such instrument nor do such references constitute an offer to provide investment advisory services. This content is not intended for investors or prospective investors and should not be relied upon when making any investment decision, including a decision to invest in any vehicles managed by CMT Digital. Such offerings are only made via formal offering documents. 

 Past performance is not indicative of future results. Any projections, estimates, forecasts, and/or opinions expressed in this piece are subject to change without notice.

Loading...
highlight
Collect this post to permanently own it.
CMT Digital Research logo
Subscribe to CMT Digital Research and never miss a post.
  • Loading comments...