Amidst the proliferation of L2s, appchains, rollapps, and blockchain networks, all with different VMs, cross-chain messaging has reached a tipping point. Interoperability within these networks, whether it be bridging or cross-chain messaging, has become a significant point of concern for developers. Developers are not always aware of the security considerations and tradeoffs associated with various cross-chain messaging protocols. Security considerations include protocol and contract immutability, validator trust assumptions, liveness, and censorship assumptions. 

dApps with cross-chain messaging needs vary in security requirements. Different dApps facilitate different types and magnitudes of economic activity, and even within a dApp, transactions vary in their levels of economic value. For example, a cross-chain NFT protocol may have distinct security needs compared to a cross-chain lending protocol. Within a cross-chain NFT protocol, a $1 cross-chain NFT transaction naturally requires lower guarantees compared to a $100,000 cross-chain loan transaction. By combining various DVNs into a specified DVN set and assigning certain DVNs a privileged status, LayerZero gives dApps the flexibility to choose multiple points along a cost/security spectrum and allows developers to granularly adapt security features depending on dApp or transaction requirements.

LayerZero V2 retains its value proposition as a customizable cross-chain messaging protocol. With the plethora of cross-chain messaging solutions available today, LayerZero V2 attempts to distance itself and differentiate by providing a uniform solution that gives developers the ability to maintain control over their cross-chain messaging security stack in a customizable manner. Rather than focusing on verification and validation, LayerZero focuses on the transport of the cross-chain messages. It is possible that eventually many of these cross-chain solutions and bridges available now become DVNs within LayerZero. 
Through a base protocol represented by immutable endpoints, append-only validation contracts with the message library, fully configurable sets of decentralized verifier networks (DVNs), and permissionless executors, LayerZero V2 now decouples security and execution, providing the protocol with more extensibility, giving developers more flexibility while achieving censorship resistance and liveness.

Core Protocol Design

LayerZero V2 has four main components. The endpoint, an immutable component of the core protocol; the message library (MessageLib), an append-only collection of validation libraries; decentralized verifier networks (DVNs) that relay packets between chains; and executors, who execute any arbitrary logic. This is brought together in the OApp configuration – or Security Stack – which is defined by developers as to what DVN set, what validation library, number of block confirmations to wait, and what executor a cross-chain message should utilize.

Transaction Lifecycle

Before a cross-chain message can be facilitated by LayerZero, a dApp first has to register a configuration (Security Stack) with the LayerZero endpoint. This configuration (Security Stack) includes the specific validation library, the set of decentralized verifier networks (DVNs) it would like to use, number of block confirmations, and, if it chooses to do so, a specified executor. The DVNs are in charge of verifying message packets while the executors are in charge of executing arbitrary logic on the destination chain.
Below are the steps for a standard cross-chain message facilitated by LayerZero.

1. The sender, a dApp, would invoke a function lzSend. Within this, the dApp would specify the message payload (what they want to be sending cross-chain—could be a message, could be a set of instructions, etc.) and the path. The path comprises various addresses and IDs, including the sender dApp address, the endpoint ID, the recipient dApp address, and the receiver endpoint ID. 
2. The endpoint assigns a nonce to the message packet and forwards it to the message library (MessageLib) on the source chain for serialization. The dApp’s chosen validation library encodes the message packet and returns it to the endpoint. 
3. The encoded message packet is then emitted to be observed by the dApp’s configured Security Stack (set of DVNs) and a permissionless group of Executors. The Security Stack proceeds to verify the message packet on the destination chain by signing an attestation of the hash of the packet payload. Once a sufficient set of DVNs sign the payload, the Executor delivers the message packet to the destination chain endpoint. 
4. The endpoint will then authenticate that the payload was verified by the chosen validation library on the destination chain and by the specified DVN quorum, and attempt to deliver the message packet to the destination dApp.
5. Once delivered, any caller (e.g., the Executor) can call a function, lzReceive, on the destination Endpoint to deliver the message packet.

Message Packet

The message packet is currently generated at the endpoint level. The endpoint is an immutable contract that provides a standardized interface for omnichain apps (OApps) to send, receive, and configure messages seamlessly. The endpoint enforces censorship resistance, replay attack resistance, and OApp security stack ownership. Generating the message packet at the endpoint level allows LayerZero to standardize the message packet so that it is compatible with all verification methods in the validation library. If not, there would be a risk that a message packet is created on one validation library and then received on a different validation library that does not interpret it. Creating the message packet at the endpoint allows the message packet to be universal, enforcing a message packet standard. This is similar to how Ethernet (not Ethereum) network packets have always utilized a common semantic, such that every single network card, regardless of manufacturer or version, is able to interpret these packets.

Message Library

The MessageLib Registry is a collection of MessageLibs, and these MessageLibs are responsible for securely emitting message packets on the source chain and validating them on destination chains. Each MessageLib in the MessageLib Registry is immutable and cannot be removed. The MessageLib accepts messages from the source chain endpoint, encodes the message packet for the Endpoint to emit to DVNs and executors (and pays gas fees in the process of doing so), validates the message packet on the destination chain, and delivers the validated message packet to the destination chain endpoint.

Ultra Light Node

The Ultra Light Node (ULN) is the baseline validation library in the MessageLib Registry and implements the minimal set of features of any MessageLib. The ULN aggregates signatures from DVNs within the specified Security Stack when verifying the message packet hash. 
Any cross-chain message has to interact with two ULNs if the OApp chooses the baseline validation library in the Message Lib Registry, one on the source chain, and one on the destination chain. The sending ULN encodes the packet based on the OApp’s configuration, and the receiving ULN receives verifications from the selected DVNs. 

On the source chain, the ULN is the entity that generates the packet and collects fees and then sends the packet to executors. The ULN itself doesn’t verify the packet; it just implements an onchain mechanism to allow DVNs to verify it. The ULN collects the fees on the send side and then collects verifications for that message packet on the receipt side. 

On the destination chain, the ULN aggregates all of the DVN signatures, ensuring that the hashes that DVNs have provided when they reach consensus onchain match for a given message, thus verifying the message packet before it is committed to the endpoint. 

The main reason the ULN is not built as part of the endpoint is so that LayerZero is able to introduce new verification methods when they come out. If one were to build the ULN within the endpoint, the endpoint has to be immutable, meaning it would not be able to support new methods. LayerZero is currently on ULN V3. With this architecture, OApps are never forced to migrate to new ULN versions if they do not want to, as the ULN will exist forever. However, if dApps want to integrate with Endpoint for LayerZero V2, they will need to upgrade.

DVNs

Any entity can run a DVN. It is an entirely permissionless role that LayerZero the protocol and LayerZero Labs cannot control. There is no selection, whitelisting, or governance process for to run DVN infrastructure as a DVN for an OApp. Any entity can spin up a DVN to verify cross-chain messages. For example, if a dApp wanted to build a cross-chain governance voting mechanism without relying on any third-party infrastructure, it could create a DVN, configure its Security Stack to only require a single signature from that DVN, and then verify governance votes that way. 

An example of how one should think about DVNs is Uniswap’s front end, which maintains a list of tokens it displays through Uniswap Labs. However, the actual underlying Uniswap contracts are immutable and permissionless, and thus, anybody can list a token they want to make available for trading. Similarly, LayerZero Labs offers a list of DVNs as “defaults.” However, dApps are free, and encouraged, to utilize any DVN or threshold of DVNs. This is all defined in a dApp’s onchain configuration (Security Stack). 

One common misconception of LayerZero is that it competes with the likes of Wormhole and Axelar. The new DVN structure distances LayerZero from competition at the bridge or verification level. As such, one could interpret that LayerZero is selling a unified modular cross-chain messaging solution, while Wormhole and Axelar and other bridges/oracles/verifiers are selling trust in their validator set. As part of the V2 rollout, Axelar and CCIP will be available as DVN adapters for apps to choose from. With V2, a developer should be less inclined to build on top of a bridge or messaging standard, as that is a form of vendor lock-in. Instead, application developers may select shared security-based bridges like Axelar or Wormhole as DVN adapters through LayerZero. This gives developers the ability to combine shared security models and move away from a certain DVN if it is ever hacked. 

Each DVN supports a unique subset of the pathways in the LayerZero supported networks. Some may support every pathway, others a limited set. For example, Chainlink for LayerZero V1 doesn’t support every pathway. Polyhedra’s ZK light client also only supports certain pathways for V1. What pathways a verifier supports is solely up to the verifiers themselves, and thus, dApps need to choose a DVN set that fits their bridging needs given the pathways they want supported.

DVNs are listening for message packets in real time and then waiting for the configured number of block confirmations before sending the hash. The sent hash is the DVN attestation, announcing that this is the hash of a packet that is going to be submitted, certifying the packet hash’s validity. Once enough hashes for that packet from the correct DVNs have been received by the ULN based on the threshold, the packet is committed to the censorship-resistant channel in the endpoint. Once the endpoint enforces losslessness (censorship resistance) and exactly-once delivery (replay resistance), the executor can deliver the packet, where the real packet will be hashed and compared to what all the DVNs have submitted. If the hashes match, then it can proceed to be executed.

Pre-crime enabled DVNs are able to simulate transactions against specific invariants before a packet is submitted. If there is something wrong and the simulation fails, the verifier will be able to identify where the error derives from, communicate that with the dApp, and specify what invariants are broken. Theoretically, any arbitrary set of additional compute can be done as part of executing this arbitrary logic within a message transaction. This will not be immediately available in V2.

DVN Costs

Different DVNs carry different verification costs. For example, Polyhedra’s ZK light client DVN likely has a higher verification cost than Google Cloud’s DVN due to the ZK proof generation. Therefore, dApps will have to optimize across verifiers based on their needs. In a very simplified manner, there is a cost vs. security curve, where the amount of security increases with the cost of verification. With LayerZero, dApps can choose where they want their cross-chain app to be on this curve instead of being locked into a certain point on the curve forever. If a dApp wants to, they can move along this curve anytime they want simply by changing their config’s Security Stack.

Another aspect that a dApp could implement is conditional logic. For example, when a dApp is sending transactions that are under $100, it could choose to use a verifier with cheaper verification costs and lower security, and when it is sending transactions that are over $10,000, it could choose to use a verifier with higher verification costs and more security. However, this type of logic is fairly hard to implement today, and LayerZero Labs is looking to make this type of custom logic much easier to set up in the long term.  It is not available at launch. 

Another set of parameters that dApps must configure is the number of block confirmations DVNs must wait before the message packet is forwarded to the MsgLib on the destination chain. For example, transactions on distinct source chains with different definitions of finality will likely result in a dApp specifying a different number of block confirmations. Similarly, such conditional logic for block confirmations will not be available at launch. In addition, such conditional logic would require a dApp to deploy multiple OApp contracts.

Executors

Like DVNs, the executor is a permissionless role. Executors ensure the execution of messages on the destination chain. The executor is an optional service added on top of LayerZero involving gas abstraction. In fact, execution that is paid for via a premium by the user on the source chain is actually a social contract with the executor. It achieves this by abstracting away gas payments for users on destination chains, acting in a manner similar to an account abstraction paymaster, except cross-chain. This is a valuable service, as it eliminates the need to obtain gas tokens on the destination chain and allows for the seamless execution of the transaction.

As anybody can be an executor, and executors largely fill the same role as filling intents such as swap request-for-quotes or bridge intents, this is likely a highly competitive market with sophisticated market makers. LayerZero Labs will compete in this market by providing gas abstraction. 

Theoretically, executors are not a necessary part of the protocol, as users or application owners can execute their transactions on the destination chains themselves. That means if a transaction is stuck, an application or end-user can force it through – similar to how an L2 user can execute their transaction through forced inclusion. This can be done through LayerZero Scan similar to how one can write contracts on Etherscan. For example, LayerZero Lab’s executor is simply saying that a user has to pay a certain amount of gas on the source chain, and in turn, it will help pay a certain amount of gas on the destination chain. To date, LayerZero Labs has reference implementations of executors that external parties can use, and have released documentation on how to develop a completely independent third-party executor. There have been concerns from potential LayerZero users such as Uniswap’s bridge assessment committee regarding the fact that the LayerZero Labs’ executor is not open-sourced. However, given that the executor market is competitive and that LayerZero Labs generates profits through operating its executors, along with executors being a permissionless role, those concerns are largely unwarranted.

Executor Transaction Flow

In addition to setting their own security stack or explicitly opt-in to the defaults, specifying the MessageLib and DVN set they want to use, the number of block confirmations, dApps may also choose an executor or choose no executor. Within that config, a dApp could theoretically specify a “meta-executor,” which represents a marketplace of executors. For example, this “meta-executor” can be an onchain smart contract that queries for the best price across multiple executors and chooses whichever is best. However, this is not possible yet and will have to be something that is further developed.

When a user makes a bridge transaction, from say, Polygon to Avalanche, an executor is constantly writing quotes onchain, e.g., the price of AVAX in units of MATIC. An executor will normally add a markup to the quote offered as a buffer for gas price fluctuations on the destination chain. The executor is not aware of what the packet is, and LayerZero simply generates a message stating that a certain executor’s quote is accepted. Once the executor has been paid the quoted amount of gas, that state is attested to and now exists onchain. After waiting for the required number of block confirmations, and for the DVNs to verify the message packet, these DVNs will then produce a signature that’s a hash of the packet and write it to the destination chain’s ULN. From there, the selected executor should go and execute the transaction. However, in a scenario where an executor is malicious/slow, anybody could theoretically come in and be an executor to execute the transaction as long as the message packet has met the verification requirements. That being said, it is unlikely a random executor or end user will go ahead and execute the transaction for you, as they have not been paid on the source chain and will have to pay the gas fees for the transaction on the destination chain – meaning the app or end-user waiting for the transaction will likely have to manually execute it. 

When a dApp accepts a quote on the source chain, this doesn’t lock in the quote and executor. The dApp is locked in, in terms of having paid the executor on the source chain, but the corresponding transaction execution is purely a social contract, there is no enforcement mechanism on the destination chain. This was designed as so because in order to enforce execution, you would need to design another mechanism to verify transaction execution, and gas costs would significantly increase due to that.

Major Changes

Application Owned Security via Security Stack

dApps have the option to choose the DVN set and its quorum for a cross-chain message. At launch, DVNs such as Blockdaemon, Gitcoin, LayerZero Labs, Google Cloud, Polyhedra zkLightClient, Axelar adaptor, CCIP adaptor, and more will be available. However, dApps may create DVNs for themselves and/or build DVN adapters for other verification methods such as native bridges or other verification networks, etc. 

As part of the configuration, a dApp can configure a custom Security Stack, containing a set of required DVNs, combined with a number of optional DVNs, requiring a specific threshold to verify the integrity of the payload hash.  So for example, if a dApp were to specify a threshold of 3 DVNs, within a set of 5 DVNs, with Polyhedra’s ZK light client being a required DVN, a message packet would only be delivered if Polyhedra’s ZK light client and two other verifiers within the remaining four DVNs attest to the validity of the hash of the message packet. 

The key unlock here is that dApps can mix and match different DVNs to achieve the desired level of security. By specifying certain privileged DVNs, the dApp can specify the baseline level of security and then add on any extra DVNs to achieve Security Stack quorum. With that, dApps can choose an additive amount of cost + security, with the added benefit of not having to be restricted to a point on the cost/security curve given the different verifier sets/quorum combinations available.

Third-Party DVN Adapters

Third-party DVN adaptors enable dApps to integrate various other verifier networks into their configuration. This includes native asset bridges, middle-chains, or other verification methods. For example, Axelar and CCIP will be integrated with adapters utilizing Axelar’s generic message passing and CCIP’s arbitrary message passing to verify the message packet’s hash. In essence, developers using V2 adapters get the full security of CCIP and Axelar (on their own or combined) with the extensibility and unified messaging standards of LayerZero.

As mentioned above, DVNs can be permissionlessly included through the use of adapters. So that means Axelar, CCIP and Wormhole (and any combination of them) can all be used as DVNs within LayerZero. It is important to emphasize that LayerZero is fundamentally different from the likes of Axelar, CCIP and Wormhole. LayerZero should not be thought of as a competitor to these cross-chain messaging protocols. Instead, it should be perceived as a lower-level unified architecture for any dApp to support different configurations of verification methods depending on cost, security, and use-case needs.

Decoupling of Security and Execution

The executor is a new entity in LayerZero V2. In LayerZero V1, the relayer was responsible for both security and execution. In V2, the relayer is replaced by the executor which is only responsible for execution. Previously, the relayer forwarded the hash from the endpoint on the destination chain, which then sent any associated packets with that block hash back to the validator, which the validator could then use to match with block headers to validate the cross-chain transaction. That is why we say the relayer was previously responsible for security too. In V2, the executor only delivers and executes the message packet after a sufficient set of DVNs have signed the payload and the endpoint has guaranteed censorship resistance. Importantly, the executor role is entirely permissionless so anyone can execute the message packet. 

Verification being decoupled from execution is one of the key unlocks, as executors are permissionless and cannot compromise the security of the protocol. Executors only execute verified messages and are completely isolated from packet verification logic. This gives dApps integrating LayerZero the ability to limitlessly extend the use cases of LayerZero messages as they can execute any arbitrary logic or transactions. More importantly, since executors are only responsible for execution, malicious or faulty executors do not affect protocol security or cause liveness failures. In addition, executors being a permissionless role allows the protocol to guarantee liveness. In addition, dApps can always configure away from executors that aren’t operational/functioning as intended.

Lazy Nonce Order Enforcement

In LayerZero V2, dApps will be able to choose from two types of different nonce order enforcement: lazy nonce enforcement and strict nonce enforcement. By default, LayerZero uses lazy nonce order enforcement, however, dApps may configure their own contracts to use strict nonce enforcement. The main benefit of nonce order enforcement is censorship resistance. Nonce order enforcement means that every message that comes in must be executed exactly in the order that they are received. 

Scenarios where strict nonce enforcement is useful would include financial transactions, where a dApp would want to ensure transactions get executed in order. This would reduce frontrunning and race conditions. If an executor had the ability to hold back transactions, they would be able to arbitrarily reorder these transactions, and perhaps be able to extract much more MEV from the same set of transactions than they would previously be able to do so. Giving an executor the ability to arbitrarily reorder, frontrun, or censor transactions would be relatively catastrophic, as shown in the rampant value extraction from builders and proposers in the current MEV paradigm. Scenarios where lazy nonce order enforcement would be more logical would be governance, where a dApp would want to ensure that every vote gets counted, but does not necessarily care about the order that the votes come in, with the caveat that a dApp would want all the votes counted eventually before processing non-vote transactions. 

However, there are also scenarios where one would prefer lazy nonce enforcement. The executor, the entity that is signing transactions on the destination chain, would normally be a single wallet address or contract. However, single signers have massive throughput issues on most blockchains, even with custom code. An example of an application that lazy nonce enforcement would be logical for would be a traditional bridge, as a user would only care that they received the assets that they had bridged, less so the order that the bridge transactions get processed (with some caveat here that the user would not want their bridge transaction to take a long time to process). With lazy nonce enforcement, transactions on the source chain can be verified in the order that they were received. As long as a specific transaction has met the verification threshold, anybody can permissionlessly execute that transaction, mitigating any liveness or censorship concerns of the protocol. The way one can think about lazy nonce enforcement is that it opens up a mempool, where all the verified transactions on the destination chain lie, and anybody may execute these transactions, effectively allowing the throughput of LayerZero on that specific chain to be the throughput of the chain itself. 

This is a fairly large unlock as previously, an individual executor with strict nonce order enforcement would have a relatively slow throughput, as they would have to sign and execute a transaction, and ensure that transaction is confirmed, before executing the next transaction. With permissionless executors and lazy nonce order enforcement, any number of executors can execute transactions in any order without having to confirm previous transactions, vastly improving the throughput of LayerZero.

Horizontal vs Vertical Composability

In LayerZero V1, OApps have vertical composability, albeit outside of the protocol. In the scenario where a dApp initiates a cross-chain message on the source chain, with two sequential transactions on the destination chain for dApp 1 and dApp 2, LayerZero treats these two sequential transactions on the destination chain as one atomic leg. For example, if only the first transaction on the destination chain was executed, but the second transaction fails because not enough gas was supplied or if it was an invalid transaction, then the dApp that initiated that cross-chain message essentially is frozen in the current state because LayerZero cannot move onto the next nonce as the second transaction has not been executed. In the scenario where Stargate was the dApp that initiated the cross-chain message on the source chain, such a scenario would essentially freeze Stargate and prevent it from processing any transactions on the destination chain.

In LayerZero V2, the first transaction will execute, and the result of that will be stored in the LayerZero endpoint. From there, the second transaction will then be potentially executed using the result of the first transaction stored in the LayerZero endpoint. A dApp could theoretically nest these different transactions endlessly, with each leg independently resolving, and bundling with the next leg. This is how V2 of the protocol is able to achieve horizontal composability.

Risks

The key growth risk of LayerZero, regardless of V1 or V2, has always been that developers were not interested in a customizable modular solution for cross-chain messaging. However, it is important to emphasize this is not a security risk or anything inherently faulty with the protocol, it is simply a potential branding barrier to developer adoption. Perhaps rather than utilizing a unified system with modular security that can be swapped/stacked such as LayerZero, a developer would rather choose a single cross-chain messaging security model and “lock themselves in”. However, we believe that LayerZero is a better solution that sits at a lower part of the stack than other existing bridges or messaging solutions. It is up to the LayerZero protocol community and LayerZero Labs team to change the public perception around the security assumptions of LayerZero, e.g. the community thinking that LayerZero is just a 2/2 multisig, in order to continue growing its protocol’s adoption.

Another potential risk of LayerZero V2 is that there is no competitive marketplace of executors. Realistically, your average user will not be tech-savvy enough to execute their own transactions on the destination chain by writing smart contracts. Similarly, a dApp is unlikely to run its own automated executor as it is a fairly complex undertaking. This means that dApps seeking automatic execution will have to rely on a marketplace of sophisticated and likely limited executors. As such, having a competitive marketplace of executors is crucial for certain dApps to provide their desired UX (i.e. user transactions being automatically executed in a timely manner at a fair price). However, looking at other intents based bridging models which is the closest comparison for the executor, such as Across where relayers help to fill bridge requests on the destination chain, the executor market should remain fairly competitive. It is important to note that other intents based models such as UniswapX and Across also start off with a relatively low number of entities to resolve the intents. What is more important is that in the long term, there is a competitive executor market, which LayerZero will help with through open-sourcing reference executors.

Final Thoughts

LayerZero V2’s upgraded architecture represents a significant improvement from V1. The decoupling of security and execution gives the protocol much better liveness especially with the introduction of permissionless executors. Rather than competing with the likes of Axelar/Wormhole/CCIP, LayerZero has abstracted the cross-chain messaging primitive at a different part of the stack. With its current design, LayerZero essentially acts as the picks and shovels for cross-chain messaging, as it is a unified system with modular security for cross-chain messaging. Despite the configurable nature of the protocol in terms of different DVN configurations, the base protocol still has censorship resistance, replay resistance, and liveness guarantees due to the immutable endpoints and append only validation libraries. 

Utilizing a slightly convoluted example, if a dApp utilized LayerZero, and set its DVN quorum in its configuration to be 1/1 with the Axelar hook, the gas costs should theoretically be only slightly more than had the dApp utilized Axelar independently as its cross-chain messaging system. However, by utilizing Axelar’s general message passing security within the LayerZero framework, a dApp could easily change its configuration to add more DVNs, set a higher quorum, and specify certain privileged DVNs, allowing it to adapt its cross-chain messaging security assumptions and guarantees in a modular fashion. In addition, you would have no permanent liveness risk if Axelar were to ever shut down, and have a censorship resistance guarantee on the messaging channel. Expanding on that, for example, if one were to use Axelar/CCIP/Wormhole with a quorum of two as their DVN configuration, then even if one of the three was compromised, the dApp would still be safe as it would simply require verifications from the other two non-compromised DVNs. 

In a world where a dApp’s cross-chain messaging security needs will likely constantly change as they grow over time and user behavior evolves, utilizing a unified solution with modular security for cross-chain messaging is a clear logical progression of the space.

This research report has been funded by LayerZero Labs LTD. By providing this disclosure, we aim to ensure that the research reported in this document is conducted with objectivity and transparency.  Blockworks Research makes the following disclosures: 1) Research Funding: The research reported in this document has been funded by LayerZero Labs LTD. The sponsor may have input on the content of the report, but Blockworks Research maintains editorial control over the final report to retain data accuracy and objectivity. All published reports by Blockworks Research are reviewed by internal independent parties to prevent bias. 2) Researchers submit financial conflict of interest (FCOI) disclosures on a monthly basis that are reviewed by appropriate internal parties.

The information contained in this report and by Blockworks Inc. and related affiliates is for general informational purposes only and is not intended to provide legal, financial, or investment advice. The report should not be construed as an offer or solicitation to buy or sell any security, token, or financial instrument and does not represent any recommendation or endorsement of any investment or financial product or service. Blockworks Inc. and related affiliates are not registered as a securities broker-dealer or an investment advisor in any jurisdiction or country.

The opinions and analysis expressed in this report are independent and solely those of Blockworks, Inc. The viewpoints and analyses contained within this research report have not been influenced by the sponsoring entity, although the sponsoring entity has final determination if the report is acceptable for publishing. Readers are advised to conduct their own independent research and seek the advice of a qualified financial advisor before making any investment decisions.