Published: February 27, 2024
The following is a research report that delves into Monad’s value proposition and unique selling points, presenting a compelling case for its position in the market. As a network, it bridges the EVM’s robustness and network effects with the scalability of parallel execution pioneered by chains like Solana, Sui, and Aptos among others.
The L1 and L2 space has quickly become crowded with new participants seeming to emerge each day. On the one hand, many L2s are entering the market, settling their transactions on Ethereum. On the other hand, there are integrated chains like Solana which don’t offload any functionality to a separate layer and optimize for high speed within a single environment.
Acknowledging the network effects and robustness of the EVM, as well as the scalability and performance enhancement of parallel transactions, Monad sits at the intersection of both paradigms. This approach aims to attract the vast community of the Ethereum community and EVM developers and empower them with high-speed and low transaction costs.
The essence of Monad lies in its strategic alignment with the EVM, offering full compatibility and seamless integration for existing Ethereum codebases while introducing the transformative concept of parallelizing the EVM. This approach addresses the critical market need for higher transaction throughput without compromising on the security and developer-friendly environment that Ethereum offers.
By addressing the critical market need for higher transaction throughput without compromising on security, we believe that Monad is poised to redefine the narrative around L1 solutions and emerge as a pivotal player in the years to come.
Over the past months, there have been lots of discussions about parallel VMs and what unique capabilities they bring to the table. In each of those conversations, there is always one name looming on the horizon, and that is Monad.
Monad is an upcoming layer 1 (L1) EVM-compatible blockchain that has positioned itself at the crossroads of Ethereum and Solana, achieving 10,000 transactions per second (TPS) with 1-second block-time and time-to-finality. At the same time, it offers full EVM bytecode and RPC compatibility, supporting existing Ethereum tooling and allowing developers to port their EVM applications with no code changes.
By optimizing the EVM to allow for parallelization while retaining its core functionalities, Monad aims to attract existing EVM developers and allow them to further enhance the capabilities of their applications – offering the best of both the Solana (parallel execution) and Ethereum (robustness and network effects) ecosystems.
These unique properties position Monad in a very favorable position to solve the cold start problem of L1s, by which they struggle to attract developers due to the absence of active users.
Undoubtedly, there is a gap in the market that needs to be filled: parallelizing the EVM. Multiple teams are competing to realize that vision, each with its own distinct approach and merits.
Ethereum, like many other L1 chains, processes transactions sequentially, one after the other (instead of multiple at the same time), resulting in a bottleneck during periods of high activity. This is why modern blockchains are working to enable parallelization. However, most solutions to this problem are not EVM. As a result, they fail to onboard developers, forcing them to learn new programming languages and skills.
In the context of Monad, parallelizing the EVM refers to a technique that enables multiple transactions or smart contract executions to occur simultaneously or in parallel, rather than sequentially.
This solution is inspired by the realization that most transactions on Ethereum (or an EVM environment) don’t touch the same piece of state, and they do not conflict with each other. Since they are modifying different independent contracts, there is no reason why they could not be processed concurrently. This would allow the network to achieve higher throughput and faster transaction processing times.
Ethereum has the liquidity and network effects of a thriving community and developer environment, while Solana offers unmatched advantages in terms of speed and scalability. Therein lies a unique market opportunity to capitalize on the core strengths of both ecosystems.
The market does not need yet another L1, but there is a lot of potential that is yet to be discovered if we remove the current limitations of the EVM, the most obvious being the bottleneck caused by serial processing.
Currently, there are two solutions on the market aiming to move developers from Ethereum to Solana and vice versa. Nevertheless, this does not necessarily mean that they are merging the best of both worlds (the parallel processing of Solana, and the existing tooling and network effects of the EVM).
As an example, Neon is a developer environment that allows Solidity (the most used language in EVM environments) developers to port their applications to Solana. On the opposite side of the spectrum, Eclipse is an upcoming L2 that allows Solana developers to start building on Ethereum by leveraging the SVM for execution instead of the EVM (while settling transactions on Ethereum).
However, both Neon and Eclipse fail to tackle the main ambition, which is getting the best of both worlds: the network effects and adoption of the EVM and its tooling, and the parallelization enabled by other Virtual Machines (VMs) like the SVM.
In fact, it stands to reason that if someone had figured out how to parallelize the most adopted VM, which is the EVM, they would have done so already. However, this is an extremely complex task that involves a very deep level of expertise. To achieve that, multiple components of the tech stack need to be rebuilt from the ground up, optimizing network consensus, execution, and state access among others.
This is why the market needs Monad – it is the only active participant in the market aiming to tackle such a large problem. Other solutions either plug and play the EVM (with all the inefficiencies that come with it) or develop VMs where it gets complicated to onboard blockchain developers (most of whom are already familiar with writing code for the EVM).
It is very unlikely that Ethereum will consider pursuing parallel processing in the near future, especially when we take into account that it is going after a rollup-centric future. Based on this premise, the expectation is for teams to deploy their applications on L2 rollups, each of which will offer its own execution environment (EVM, SVM, MoveVM…).
The main differentiating factor of Monad is that it equips the EVM with parallel processing capabilities, or “pipelining the EVM”. Pipelining is a term from Computer Science that describes how a CPU can execute multiple machine instructions in parallel. This way, instructions can be broken down into successive steps that can be executed concurrently. By staging work, the network can make use of its network resources more efficiently.
Nonetheless, it is important to note that Monad applies pipelining to various aspects of its operation, not just execution. Pipelining is used for consensus, transaction execution, state access, and within consensus and execution.
Over nearly a decade, the EVM and Solidity have built a massive developer ecosystem. In the past, many Layer 1 blockchains, including BSC, Polygon, Tron, Avalanche, and Fantom, have embraced the EVM ecosystem successfully – they managed to onboard existing users and developers with cheaper transaction costs. Similarly, we have also observed explosive growth in Layer 2 solutions like Base, Arbitrum, and Optimism. Additionally, a new set of so-called “next-generation” chains has entered the market to offer higher speed and performance by not using the EVM, such as Solana, Sui, and Aptos.
Certainly, the EVM has become a core pillar for the industry as a whole, with 90%+ of the TVL. This is reflected by the sheer number of unique applications that have been deployed on it as well as by the TVL that it currently supports. We attribute this adoption to the large number of developer tools that are available for writing smart contracts on the EVM.
Solidity, Ethereum’s main smart contract language, offers a wealth of learning materials, courses, blogs, and a track record of tooling development. Despite its inefficiencies, similar to how Javascript endured and evolved in the early 2000s, the EVM has proven its resilience over time.
While chains that offer parallelization, like Solana, Aptos, and Sui, have active developers and the numbers continue to increase, the truth is that Solidity developers still make up the majority. This is why Monad is uniquely positioned to capture the attention of developers who can onboard the next generation of users into crypto.
What makes Monad stand out from other L1 and L2 competitors is that it has full EVM bytecode and Ethereum RPC compatibility, while substantially having an advantage in terms of throughput. Put simply, applications built for Ethereum can be deployed on Monad with no changes to the code, and they will be able to achieve 10k TPS and benefit from 1-second block times and 1-second time to finality.
This compatibility streamlines the process for new developers to get started on Monad. They can use familiar languages like Solidity, tools like Hardhat or Foundry, and existing Ethereum developer infrastructure such as Infure or Etherscan. This makes it easy to transition and build on Monad without a steep learning curve.
Furthermore, Monad’s lower gas costs compared to Ethereum enable developers to create more cost-effective and efficient smart contracts. This is essential because gas optimization techniques on Ethereum often introduce security risks and vulnerabilities. On Ethereum, high gas costs have led some developers to sacrifice code readability to reduce expenses. They use complex tricks like marking functions as ‘payable’ when unnecessary, employing intricate assembly code, or avoiding external libraries. While these tactics cut gas costs, they make the code harder to understand, increasing the potential for errors and vulnerabilities during updates or audits.
Monad addresses these challenges without having to make trade-offs between security and cost efficiency. Thus, betting on Monad implies believing in the vision that the EVM can be as fast, secure, and developer-friendly as other virtual machines, such as the Solana VM.
Endgame, which is one of the most popular blog posts in the history of Ethereum and is authored by Vitalik, fantasized with the idea of achieving 10,000+ TPS given powerful enough hardware. This is shown in the excerpt from the blog post shown below.
However, Monad has chosen not to build itself as an Ethereum Layer 2 (L2) rollup for three primary reasons: decentralization and censorship resistance, performance, and focus.
First, it is important to note that, in its current state, rollups lack a mechanism for decentralized block production, which is crucial for censorship resistance and genuine decentralization. Rollup blocks are produced by centralized sequencers, giving them absolute authority over transaction ordering and the ability to censor transactions. This centralization of block production, although reassured by Vitalik himself, undermines the core principles of using a blockchain. Below you can find another excerpt from Endgame, the blog post where Vitalik introduced his vision for pursuing a rollup-centric roadmap for Ethereum, explicitly acknowledging the issue of centralized block production as long as the validation of blocks remains trustless and decentralized.
Second, Monad is committed to building the most performant and cost-effective system possible. In terms of performance, building Monad as a rollup would impose limitations on its scalability. Monad’s design focuses on optimizing execution and consensus to achieve high performance and becoming a rollup would introduce constraints that hinder this goal.
Third, the Monad team believes that creating a high-performance EVM execution environment that is accessible to anyone is essential for improving the reach and utility of decentralized computation. Their current focus is on executing this vision, and they prioritize it over other considerations. While there may be opportunities in the future to combine Monad’s improvements with roll-up mechanisms, their primary focus is clear at the moment.
To put things into perspective, you should note that, by virtue of being a dedicated L1 blockchain, Monad has a built-in consensus mechanism, maintains its own state, and does not need to rely on a separate data availability (DA) layer. While this might impose slightly higher hardware resources, it can still affordably offer faster time-to-finality. And, the hardware requirements are quite affordable, as displayed in the image below.
Rollups, on the other hand, remove the consensus overhead and rely on a centralized sequencer. They maintain state in a Merkle trie and commit data to a DA layer, which can limit data capacity and result in slower time-to-finality. However, they benefit from reduced execution overhead and can run on high-end sequencer hardware.
For reference, we outline the main differences in a schematic way in the table below.
To understand the potential of Monad, we must answer the question: what are the unique use cases that the underlying technology can enable and that are not achievable in any other chain?
As mentioned above, unlike all other EVM chains, Monad applies pipelining to various aspects of its operation, including state access, transaction execution, consensus, and the relationship between consensus and execution. This aims to solve the bottlenecks that single-threaded VMs (like the EVM) face when accessing state or during execution.
To accomplish this task, Monad features the MonadBFT consensus mechanism, decouples consensus and execution, and allows for optimistic execution with a shared mempool. We will delve into each of these components.
MonadBFT is the consensus mechanism itself, where nodes (validators) agree on the validity and order of transactions within blocks. It is a variation of HotStuff and Diem BFT, and a high-performance consensus mechanism that works under partially synchronous conditions.
It operates based on voting and quorum certificates (QC), ensuring that a majority of validators approve a block. Still, this mechanism also takes a timeout certificate (TC) into account.
To achieve pipelining at the consensus level, the different stages are processed over multiple rounds. Rounds are initiated by leaders who are assigned to rounds based on a predetermined schedule that is regularly generated.
Therefore, a block takes 2 rounds to be finalized, where the first is a consensus on the transactions within the block, and the second is a validation of the consensus.
This way, when there are no network issues, Monad BFT uses a Linear Communication method. However, in the unlikely event that a validator does not receive a valid proposal in time, they produce a signed timeout message and broadcast it to all peers, resulting in a more costly Quadratic Communication pattern.
When any validator receives a quorum (2/3 of stake weight) of timeout messages, they aggregate these into a TC and forward it to the next leader. This TC also includes a reference to the highest QC that each validator has seen, which will be used later.
One significant bottleneck of Ethereum is block propagation. When a new block is proposed, it needs to be shared with all validators in the network for consensus. This means that the entire block information needs to be transmitted, including all of the transactions within it. Especially when the block is large, it can strain network bandwidth and slow down the consensus process.
As we anticipated above, Monad has the challenge of processing 10,000 TPS and, if we assume each transaction to be ~500 bytes in size, that would result in a block size of 5MB. Such a large block would have a negative impact on the network’s bandwidth.
Monad addresses this challenge by minimizing the amount of data that needs to be transmitted among validators. This is done by using the hash of the block for consensus, instead of transmitting the entire block data. This way, while a transaction might be 500 bytes in size, its hash is only 32 bytes. Validators can then reconstruct the full block using mechanisms like erasure-coding transactions and a broadcast tree.
Another problem of the EVM used by Ethereum is that execution happens before consensus. This means that validators agree on the order of transactions first (consensus), and execution occurs afterward. However, for consensus to take place, the leader of that round must compute all transactions before sharing the proposal, and validators must also compute the transactions before voting.
This approach creates complexity and tight time constraints during consensus. For instance, since the gas limit needs to keep track of both execution and consensus, the budget for execution becomes very limited. Additionally, there must be enough time to complete this full process. As a result, this limits the number of transactions that can be executed in one block, limiting stability when there is high network activity involving large amounts of complex transactions.
Those issues are caused because Ethereum relies on a single-threaded execution environment as a prerequisite for consensus. Thanks to pipelining, Monad can separate between the two, optimizing each of these steps individually. In Monad, consensus happens first, and execution next. This way, while nodes execute the transactions of block K, they can simultaneously conduct consensus for block K+1.
First, nodes agree on the ordering of transactions during consensus, but neither the leader nor the rest of the validators are required to execute transactions yet. Therefore, none of them know whether the result of those transactions will be able to be executed or whether it will revert.
Second, the entire gas limit is dedicated exclusively to execution, increasing the number of transactions that can be processed in one block, achieving higher throughput as a result.
While this separation enables a more appropriate gas budget aligned with block times, this also implies that nodes agree on the ordering of transactions before knowing whether the transactions are valid or not. They vote on block validity but they don’t have an overview of the latest state yet, and some transactions might turn out to be invalid (i.e. insufficient gas limit). This might create an attack vector in the form of Denial of Service (DoS) from spamming the network. Nevertheless, Monad introduces the concept of Carriage Cost and Reserve Balance to protect against these situations and tackle spam issues.
Carriage Cost (also known as transportation fee) is a mechanism to prevent spam and Denial of Service (DoS) attacks in a system where computation and consensus are separated. In Monad, users are required to pay a carriage cost (similar to a deposit) to include their transactions in the mempool and subsequently in a block for consensus.
Similar to how Monad decouples consensus from execution, it also differentiates between the execution cost and the transportation cost. This prevents users from continuously attempting to send transactions when they have insufficient funds. Costs are deducted from the reserve balance of each user’s account, and once transactions are successfully executed, users receive their carriage costs back. This discourages spam and maintains composability for DeFi applications.
For reference, the reserve balance is typically set to be around 200 times greater than the carriage cost. This allows honest users to submit multiple transactions concurrently, which is essential for DeFi applications.
Next, we move on to the topic of execution. Monad’s execution process combines parallelism, optimistic execution, and proactive error detection to achieve high performance while maintaining data integrity. It allows transactions to be processed concurrently and has mechanisms in place to correct any discrepancies that may arise during this process.
In Monad, transactions are still linearly ordered, but the network can execute many transactions simultaneously in parallel. Each of these transactions produces a “PendingResult.” Next, each PendingResult keeps track of its inputs and outputs. These inputs and outputs are represented as (Account, Slot, and Value) tuples, allowing the system to monitor changes to accounts and values during the transaction.
As PendingResults are generated in parallel, they are subsequently processed in the original order they were received. If all the inputs for a PendingResult are deemed valid, it is committed to the blockchain. At the same time, if a PendingResult is found to be invalid during processing, it can be quickly rescheduled. This rescheduling is typically fast due to caching mechanisms in place.
Hence, Monad can leverage parallel execution to achieve high performance and allow multiple transactions to be processed concurrently, running on different cores and threads. Additionally, the results are committed in the original order, ensuring that the outcome is the same as if transactions were sequentially executed one after another.
The way Monad solves this problem is by using a transaction memory approach combined with optimistic concurrency control. When transactions are being processed in parallel, Monad assumes all operations to be valid. First, execution takes place. Next, if any issues arise during validation, the transactions are re-executed. The outcome of this process should be exactly the same as if the transactions were processed sequentially.
One way to reason about this is to view the first pass as an I/O phase, which may yield immediately-committable results. The second pass, which is guaranteed execution, represents a small amount of work to clean up any remaining executions. The majority of the time is consumed by the initial pass.
On multiple occasions, the core team of contributors at Monad has reiterated that execution is not the bottleneck. Instead, the problem that needs to be solved is related to the speed of state access. Parallelizing execution without parallelizing access has limited performance improvements. This is why MonadDB was built as a custom Merkle trie datastore that supports parallel access.
In practice, the bottleneck of executing transactions in parallel is usually I/O latency when running on servers with limited memory. For instance, the EVM wastes most of the CPU time waiting for “sload” to fetch data from disk.
This is the reason why adding more CPU cores is not always the solution to more computing power, and why innovation is needed at the state access level. Parallel processing helps mitigate this issue by allowing the CPU to switch to another task when the current transaction is blocked on I/O. In other words, parallel processing is tremendously helpful even if there is only one CPU core because it reduces CPU stalls due to disk IO latency.
The architecture of MonadDB is tightly intertwined with the concept of optimistic execution. It is a custom database developed to store blockchain state without nesting one data structure inside another. It also incorporates some I/O optimizations, bypassing the filesystem and reducing the overhead of expensive operations.
One of the root causes of liquidity problems on Ethereum-based DEXes is the high cost of updating liquidity quotes. Ethereum’s gas fees can be prohibitively expensive, making it inefficient for liquidity providers (LPs) and market makers to update their quotes frequently.
This can result in toxic flow where passive LPs end up being the counterparty of “informed traders” who exploit market inefficiencies and profit from arbitrage opportunities.
To address these liquidity challenges and reduce the MEV opportunities arising from user losses, Monad can enable a fully on-chain limit order book environment. This solution would allow LPs and market makers to efficiently manage their quotes and liquidity without the burden of high transaction fees.
As an example, by implementing an on-chain limit order book system, Monad could enhance liquidity conditions, reduce slippage, and decrease opportunities for users to experience losses that can be exploited as MEV.
All things considered, this approach creates a more efficient and equitable trading environment than other chains. Lowering the cost of transactions benefits both liquidity providers and users, ultimately reducing user losses.
Similar to Solana, the design philosophy behind involves enabling a single unit of shared global state that maximizes the performance of all resources available. This approach favors composability across DeFi, with dApps becoming money legos that can be stacked on top of each other to augment their capabilities.
Contrast this with L2s, where the biggest fear of the Ethereum community has been the fact that they fragment liquidity across multiple L2s and break composability.
Software design for parallel computing has many pitfalls that can lead to critical bugs. Several mechanisms exist to address these challenges, with pros and cons. This is reflected in the tradeoffs made by different projects working on parallelizing VMs.
Monad’s approach to using the Ethereum Virtual Machine (EVM) in a parallel execution environment distinguishes it from other chains like Sui, Solana, and Aptos.
While these chains also aim to process transactions in parallel and maximize blockchain speed, Monad stands out for its decision to utilize the EVM ecosystem, which is renowned for its developer community and solidity-based smart contracts.
Previously we mentioned that a notable player in the field of parallelization and EVM compatibility is NeonVM. Similar to Monad, Neon enables parallel execution of EVM smart contracts. However, it requires developers to design their applications with a parallel architecture in mind from the beginning, which may not be suitable for porting existing applications 1:1.
Doing the opposite of Neon (onboarding Ethereum to Solana), Eclipse is an upcoming project that stands out for implementing the SVM as a rollup on Ethereum. The chain will use the SVM for execution, tapping into existing Solana developers, Celestia for data availability, and Ethereum for settlement. Similar to Solana, this architecture makes it possible for dApps to benefit from local fee markets, such that high activity on a specific dApp does not increase gas costs for the rest of dApps on the chain.
Nonetheless, we reiterate that there are challenges and constraints faced by L2s due to the limitations of Ethereum. One of the major obstacles is the cost of writing data to the Ethereum Layer 1 (L1) chain. Each byte of data written to L1 currently incurs a gas cost, and this cost can be prohibitive when trying to achieve high transaction throughput.
Compressed Ethereum transfers, often used in rollups, require 12 bytes of data, which contributes to the overall gas consumption. This isn’t something that proto-danksharding will solve either, since the amount of data that can be written on-chain remains roughly the same. If L2s try to get greater throughput via optimistic parallelization, they wouldn’t be able to write all of the tx data to the base layer.
Assuming that blocks have a target limit of 8 blobs/block and blobs are 4096 field-elements of 32 bytes each, Ethereum rollups will have a ~7,281 TPS upper bound since compressed transfers require 12 bytes and Ethereum block times are 12 seconds.
8 * 4096 * 32 / 12 / 12 = 7281.77777778
Sei is another L1 that can be considered a more direct competitor to Monad. Unlike Neon, Sei does not require developers to specify an access list or the state that will be written beforehand. In other words, developers can continue to write their applications as they are already used to.
Similar to Monad, Sei has also developed its own database, SeiDB, and it also follows an optimistic parallelization approach. One key difference is that Sei is already live and has iterated upon its original v1 release, enabling the EVM on Sei v2.
Nonetheless, they are still using geth as the main client, whereas Monad is tackling those inefficiencies before going live. This is not necessarily a bad thing, since geth is extremely stable (currently being used by 70%+ of Ethereum nodes on mainnet) and already supports full EVM bytecode compatibility, allowing developers to plug-and-play existing EVM-compatible contracts.
Like Monad, Sei enables parallelization at the state access level, not at the contract level. For example, if $USDC is being sent from account A-> account B and account C-> account D, then those 2 transactions will be parallelized. Similarly, if different contracts are being accessed, those transactions would be run in parallel.
In this context, one of the common misconceptions is that Sei v2 only addresses the issue of parallelizing the execution environment in isolation. This description is not accurate, since Sei v2 addresses every part of the stack, including state access, state commitment, and state storage.
Altogether, this results in 390 ms finality (already live in mainnet) and 12.5k theoretical tps.
Finally, it is also important to mention another blockchain that is often overlooked when it comes to parallelization, and that is Polygon. The Polyon PoS chain has undergone an upgrade called the Parallel EVM upgrade. This effort cannot be underestimated considering that the chain has grown to become one of the most used chains in the world, hosting thousands of dApps and processing on average more than 3 million daily transactions.
The moat for L1s relies on building an ecosystem, creating a positive feedback loop to onboard developers building applications that attract new users.
On the technical side of things, the core team behind Monad has years of experience in High-Frequency Trading and building high-performance systems intended to scale while using large amounts of data. Some of its members have worked for firms like Jump Trading, Goldman Sachs, or JP Morgan in the past, while others have been core developers for Solana, Pyth, and Apple.
When it comes to funding, Monad Labs has successfully secured approximately $19M in a seed round. The round was led by Dragonfly Capital, and it included participation from Lemniscap, Placeholder, Shima Capital, Finality Capital, and Credibly Neutral. Notably, over 70 angel investors joined in, including influential figures in the blockchain industry such as Hasu, Strategy Lead at Flashbot, and 0xMAKI, the creator of SushiSwap.
When it comes to applications, considering that the full bytecode is EVM compatible, existing dApps can simply redeploy their contracts if they want to. That being said, the idea is that new protocols will take advantage of its unique features and core optimizations, allowing applications to execute with significantly more performance.
More than 80 projects have already confirmed that they are building on Monad. This includes bridges like Wormhole, oracles like Pyth, and projects at the intersection of AI and crypto like AIT Protocol, which is an AI training protocol that will bring decentralized ML to Monad.
Despite the apparent reality that we are in an Ethereum-centric world, there are still many hurdles to overcome and that will take years to solve. Ethereum’s rollup-centric roadmap and the upcoming 4844 upgrade are not a silver bullet to solve the scalability problem, and the 12-second block time still creates many challenges that could be solved with lower latency.
The popularity of Solana brought parallelization to VMs to the center stage, and now Monad is going a step further by parallelizing the EVM. These improvements at the execution layer are a big step forward toward solving scalability in the near to mid-term.
While many rollup chains are positioned as scalability solutions for Ethereum, their scalability is constrained by Ethereum’s limited block space. Monad, as a high-performance monolithic blockchain, aims to break free from these constraints and provide high-speed transactions.
In order to put “financial superapps” on the blockchain, having a parallelized VM is a requirement for scaling and achieving a meaningful benchmark of TPS (transactions per second).
Only that will make it possible to create applications that will onboard billions of usersProvided that all security gaps are patched up, parallelized VMs have the potential to become the standard.
By supporting Solidity, Monad is uniquely positioned to ride the new wave of adoption.
Revelo Intel has never had a commercial relationship with Monad and this report was not paid for or commissioned in any way.
Members of the Revelo Intel team, including those directly involved in the analysis above, may have positions in the tokens discussed.
This content is provided for educational purposes only and does not constitute financial or investment advice. You should do your own research and only invest what you can afford to lose. Revelo Intel is a research platform and not an investment or financial advisor.
