Decentralization and self-sovereignty are imperative to the future of web3, but these ideals are not always practical for every project or application. Users who strictly prioritize security over convenience in tools like non-custodial wallets and bridges can opt to run a full node, but the amount of time and hardware required drastically limits the kinds of users and devices that can interact directly with blockchain data. The very recent evolution of more efficient “light” clients, such as Helios (a16z crypto) and Telepathy (Succinct Labs) presents compelling solutions to these issues; users can now interact with blockchains directly from their devices, and trustlessly bridge assets and messages between blockchains.
Despite this recent progress, light clients aren’t a new concept; they were first proposed in the form of Simplified Payment Verification (or SPV) in Satoshi Nakamoto’s 2009 whitepaper to allow less powerful clients to interact with the network with as many security guarantees as possible. Since then, the techniques that light client protocols use have advanced quickly to support new blockchain protocols. We can also now go beyond SPVs security: using the latest research, it will soon be possible to efficiently validate consensus, execution, and data availability, making light clients as secure as their less efficient counterparts: the full nodes.
In the near future, light clients have the potential to obviate tradeoffs between efficiency and security that face users and developers alike. And with the advent of new blockchain designs, zero-knowledge proofs (zkps), and increasing interest in bridging and secure self custody, now is an ideal time to explore, develop, and adopt light clients. In this post, we start with the basics: What are light clients, why they matter, and what their core use cases are today. We then evaluate a number of the design considerations developers must take into account as they build with (and on) light clients.
Let’s start with a basic definition: light client protocols allow clients (applications, devices, blockchains, etc) to interact with blockchains, and efficiently verify state on that blockchain using cryptographic methods, without processing the entire blockchain state, usually with some security assumptions.
Breaking this down further…
In web3, users often need to trade some degree of access and experience to prioritize security and trustlessness. For example, running a resource-intensive full node to interact with dapps is far from ideal; it’s also not currently possible to access secure bridged assets without intermediaries. But this is starting to change: new clients can improve user experience without intermediaries while maintaining very high security.
In this section, we’ll take a look at how light clients are achieving this, through two core use cases: high security wallets and blockchain bridges.
Not all self-custodied wallets are equally secure.
The status-quo for self-custody wallets is connecting to the wallet company’s server. The server handles all blockchain interaction and lookups and runs a full node, either on the wallet company’s infrastructure or using a third-party provider. The user never interacts with the blockchain nodes directly – only through intermediaries. While convenient, this experience comes with tradeoffs; for example, if the wallet company or any of the intermediaries it depends on are hacked, incorrect balances and other misleading information can trick users into making transactions they otherwise wouldn’t. A more nefarious party could even misrepresent DEX prices intentionally, force users to accept very bad prices, or hide or censor their transactions.
While web2 apps usually rely on centralized intermediaries without an issue, we can’t do the same in web3, which lacks some of the expected safeguards that provide additional protections for users:
Unlike traditional finance, however, the cryptographic nature of blockchains gives us the ability to verify the correctness of state and prevent these attacks and other worst-case scenarios. It’s possible to take these precautions by running a full node, but (but for the reasons we discussed above) most users will not choose to. Light clients can present a more practical alternative when embedded into a wallet’s mobile app: If the company’s server provides invalid data to the light client wallet, the wallet will not accept it – ensuring secure, permissionless access to balances, prices, NFTs, and execution of any blockchain operation.
The increasingly important blockchain bridging space, which commonly relies on multi-sigs between a small number of parties, has been riddled with hacks. Light clients can help make bridges more secure.
We can think of blockchains as low-powered computers, like mobile devices, which can theoretically run code to verify other blockchains. Gas fees would make running a full node impractical, but verifying a Bitcoin light client (as well as some Proof-of-Stake protocols) is actually very efficient: it comes down to performing a few SHA256 hashes.
This is an interesting opportunity for bridges, which rely on one or more trusted parties that can be targeted by hacks, accept bribes to sign invalid data, or experience other safety failures. Further, any liveness issues or delays in finality can significantly impact user funds. Light clients can address these issues as long as anyone can relay the data. First, a relayer creates a proof that a certain transaction and block are finalized on the source chain; for example, a signature by ⅔ of the source chain validators on the block header, and a Merkle proof of the transaction with respect to the header. Then the relay submits the proof to a contract on the destination chain. The contract verifies cryptographically that the data is correct, resulting in a highly secure bridge. Examples of this include the Rainbow bridge on Near, IBC on Cosmos, and Axelar.
Bridging with light clients prevents an entire class of attacks. Even if intermediaries get hacked, bridged funds and data remain safe.
Before we dive deeper into the details of different light client designs, we’ll discuss the different ways users can interact with blockchains and their various tradeoffs. From least secure (trusted) to most secure (trustless), these are: (1) Trusted intermediaries, (2) light clients, (3) stateless clients, and (4) full nodes. Relying on trusted intermediaries is the more convenient option, but it introduces significant risks. Running a full node is the most secure method, but it’s inefficient.
| Client type | Efficiency | Security | Description |
| Level 1: Trusted intermediary | A | F | The client relies on an intermediary to tell them what is and isn’t on-chain. For example, a mobile wallet connected to a backend server, or a blockchain bridge which relies on a multisig oracle. |
| Level 2: Light clients | B | A–C | Light clients only download small proofs from full nodes/RPC nodes and transactions that are relevant to the client. These allow a client to at least validate the data they are receiving has been attested to, either by a subset of validators or by the full set. Some light clients also verify proofs of correct execution and data availability, resulting in even higher security. Light clients can sync in seconds or minutes on low-powered devices. |
| Level 3: Stateless clients | D | B | Stateless clients download all transactions from full nodes, and verify that the state transitions of the blockchain are valid according to the consensus rules. Unlike full nodes, stateless clients do not store the entire state of the chain. Each transaction must include a proof of inclusion verifying the relevant data being read or written.
Stateless clients aren’t as efficient as light clients because they download and execute all transactions. They can, however, serve as a replacement for full nodes, since they can detect invalid state transitions. The tradeoff is that a blockchain with only stateless clients forces users to stay online to update their local data, or requires users to rely on third parties to store it. Ethereum has considered implementing them to reduce storage requirements for users, but Verkle trees are a prerequisite upgrade. |
| Level 4: Full node | F | A | Full nodes download and execute every transaction (some from the genesis block), and store the entire state in an accessible place. They also connect to other full nodes (peers), and broadcast transactions to the network. It’s not practical to run a full node using mobile devices or bridges, since they must store the entire state (GB to TB usually), and use a lot of bandwidth, IO, RAM, and CPU, especially on high throughput chains like Solana. Full nodes can optionally be archive nodes, which store the blockchain’s entire transaction history, so that other nodes can later sync up. This process can be slow, so full nodes must remain online 24/7. |
For a more comprehensive landscape of light clients and their current capabilities, see this SoK paper. Light clients are generally seen as a middle ground between running full nodes and relying on trusted intermediaries. Near-instant syncing and support for many blockchains makes light clients a useful alternative to stateless clients, which provide even more guarantees at the expense of significantly higher resource usage.
Engineers building light clients will have to choose which properties to support in their protocols, and application developers will have to choose which light clients are the best fit for their use case. This section will explain how the most basic light client protocol works (SPV), and then dive deeper into the various properties of light clients protocols and their tradeoffs in security and performance.
SPV clients, considered the first light clients, were introduced with the invention of Bitcoin. They were defined in the original white paper to decouple client functionality, so that less powerful clients could interact with the network with as many security guarantees as possible. The approach is quite simple: Instead of downloading entire blocks with hundreds of transactions, as a full node would, an SPV client only downloads the 80-byte header for every block (10 mins per block, 800K blocks in total), and then asks a full node for transactions to/from the client’s addresses. Each transaction also comes with a Merkle proof, whose Merkle root is committed to in one of the block headers.
The client verifies the proof of work on each header to see that it’s the heaviest chain (the chain with the most proof of work on it), and thus that their transactions are actually on the canonical blockchain.
Bitcoin Whitepaper (Satoshi Nakamoto), SPV visualization
This approach is very secure, since it verifies objectively that real work was performed. Creating an alternate chain that looks real to a light client would require performing a similar number of hashes as all Bitcoin miners since the genesis block, or controlling close to half of the current Bitcoin hashpower. But SPV isn’t a fit for newer blockchain protocols for a few reasons: First, no real work is performed in PoS systems, so alternate blockchains can be created instantly. Second, SPV requires that every single header is validated, which is not especially efficient for newer protocols that have larger, faster blocks. And finally, the approach is not private, since all addresses are sent to the server.
The following sections explain some variations in light clients which help with these issues, and improve light clients more generally.
With Proof-of-Work (and Proof of Space and Time, or PoST), clients can easily distinguish a fake chain from the real chain by cryptographically verifying that validators allocated a real resource for a certain amount of time. The honest chain objectively performed more work than the fake one. The same does not apply to PoS systems, where no real work is performed. Since Ethereum’s move to PoS, the genesis block and the Ethereum codebase are no longer sufficient to verify the blockchain. Now, checkpoints (or social information) are also necessary the first time a new client syncs. This is referred to as weak subjectivity.
Naive PoS algorithms are thus susceptible to “nothing-at-stake” attacks, where old staking keys with no current stake can be used to generate alternate histories at little or no cost and create long alternate chains. Attackers can also execute invalid state transitions to give themselves more stake, and create more fake blocks. To avoid these attacks, it’s necessary for light clients to rely on one or more trusted parties to report which chain is real. When syncing, a light client can start syncing objectively from a checkpoint, as opposed to the genesis block (weak subjectivity). Checkpoints can also be posted to a more secure chain like Bitcoin for transparency.
This approach has its challenges and benefits: Light clients would need to trust that the checkpoint is valid; however, even objective light clients that sync with the genesis block already introduce trust via the syncing application, the nodes they connect to, and more. Syncing objectively from a checkpoint is more efficient, since clients aren’t required to download all headers stored within the blockchain
There are other potential solutions to the nothing-at-stake attack that don’t require weak subjectivity. Some of these include key-evolving signature schemes (Cardano Ouroboros), VDFs (Solana, Chia), and timestamping on a separate chain (Babylon Chain).
Running a light client requires validating the consensus algorithm (and thus validating block headers). For some blockchains, including Ethereum, this means tracking and validating the signatures of hundreds of thousands, or even millions, of validators – a process that makes clients drastically less “light”, since these proofs can take tens of minutes to download and validate. This is why Ethereum has developed a sync committee, a set of 512 randomly chosen validators that changes every 27 hours and signs block headers in a quickly verifiable way (Helios is one example). Since signatures are BLS, they can get aggregated for verification efficiency.
While sync committees are much more efficient for light clients, the Ethereum blockchain does not currently have a penalty for sync committee members that sign invalid block headers. So it’s possible for validators on the sync committee to accept bribes, or act maliciously by tricking light clients, without the consequence of the blockchain slashing their stake. Although Ethereuem does enforce an inactivity penalty for not signing anything at all, it’s not a meaningful percentage of the full stake. Even if there were penalties, they might not add sufficient security, since the sync committee can represent a small proportion of the stake (i.e. 512 vs. 800k validators in Ethereum).
Other systems do not rely on committees; for example, Cosmos IBC is an interchain protocol that defines a standard for chains to communicate with each other. These chains run light clients (verifying the entire validator set’s signatures, or at signatures representing 67% of stake, which can be very efficient if there is a significant long tail).
One barrier to the broader adoption of light clients is the need to manually validate each block header and their consensus. This process requires clients to download a significant amount of data, which costs time, CPU cycles, and battery life. To improve efficiency, clients can instead validate a SNARK (zk) proof that a block header is valid. Instead of validating each header and consensus signature, SNARK light clients validate a proof that someone else knows a header chain and the signatures that are required to make a block header that hashes to block hash H. For some types of SNARKs, validation is constant time and can be under 100ms.
These proofs are ideal for bridge light clients, where resource constraints are restrictive, and a full light client might be too expensive. The proofs are also much faster and cheaper than downloading tens or hundreds of MBs of data to sync up.
There are several SNARK libraries currently in development that aim to verify both sync committee light clients and full consensus light clients, which makes it even faster to sync to the Ethereum blockchain. For certain blockchains like Bitcoin, Near, or Cosmos, these proofs are already practical to generate; several companies, including Succinct, Polyhedra/LayerZero, and Electron, are making significant progress.
Although this work has come far in recent years, it’s not yet practical in production for all blockchains. SNARKs proving consensus takes tens of minutes, even with hundreds of GPUs, so progress in this area is important (and happening quickly).
The complexity of current SNARKs introduces a few different layers of risk for light clients. Critically, a bug in a SNARK’s circuit, math, or software, could be catastrophic for bridges, which are often part of financial infrastructure and trusted with user funds. Also, some SNARK proof systems have additional cryptographic assumptions or trusted setup, which does slightly increase the risk surface. For example, zkSync’s system assumes that at least one member in the setup ceremony behaved honestly and threw out the keys. Also, SNARKs do not guarantee that the proved header is on the longest chain (we’ll talk about this below).
Finally, SNARK consensus proofs do not reveal the signatures within the block headers to the verifier (the light client in this case), which makes it difficult to penalize bad actors. If validators sign invalid blocks to create a fake proof, the light client would not be able to submit evidence of this to the source chain; and the source chain would not be able to slash the validators’ stake. With no economic incentives for signers to be honest, light clients are significantly less secure. Data availability (DA) committees can help here by ensuring that the signatures are posted somewhere at a cheap price and allowing the system to punish bad actors.
SNARKs, as we’ve described above, can make validating each block header more efficient, but validating millions of headers is still impractical (if not impossible) given bandwidth, CPU, and time constraints. With some PoS systems, light clients can start syncing at a checkpoint near the tip of the chain in order to validate fewer headers and therefore drastically reduce the time it takes to sync.
Furthermore, in most PoS protocols there are limits to how quickly the validator set can change, which is another way to make validation significantly more efficient. In one of these protocols, the client can fast-forward enough blocks such that no more than n% of the stake weight could have possibly withdrawn. If the block at that point has more than 67+n% of the stake-weight, it is guaranteed to be valid even if the n% of stake has withdrawn. From there, the client can download the new validator set (assuming there is a commitment to it) and verify it, to refresh.
There are also several protocols such as FlyClient, Non-Interactive Proofs of Proof-of-Work (NIPoPoW), and succinct non-interactive argument of chain knowledge (SNACKs) that work well for the PoW/PoST objective ecosystems. These only have to download and verify O(log(N)) headers, where N is the height of the chain. Flyclient clients (for example on Chia) work by sampling block headers throughout the chain based on their difficulty, and use a Merkle mountain range (MMR) to commit to headers in the past. If the prover tries to fake a non-negligible number of blocks from the real chain without having a correct proof of work, one of the sampled headers will fail to validate.
PoPos is a solution that enables light clients to sync with the finalized header chain in Ethereum and PBFT-style PoS protocols succinctly by downloading only logarithmic (in the number of blocks) amount of data from the full nodes. Compared to the sync committee construction of PoS Ethereum, software like Kevlar that implement this can improve communication by 180x when syncing after 10 years of consensus execution.
Three things need to be proved in order for clients to verify state: Consensus (validators selected a block), execution (the block transactions were applied correctly), and data availability (nodes are storing the block data).
Even with light clients that verify consensus proofs (covered in the previous section), the validators still need to be trusted to execute transactions correctly and have block data available. This is not safe to assume in systems with large blocks: If the client doesn’t validate execution and DA, a malicious validator set could claim that invalid state is valid.
One way to reduce these assumptions is for someone to create SNARK proofs of the entire transaction validation and execution logic, proving to the light client that applying transactions to the state hash of block N results in the state hash of block N+1, and the corresponding block header. It is worth noting that the creation of these execution proofs is even more computationally intensive than SNARKS of block headers, and this field is still early. These proofs can take tens of minutes to generate, even using data centers with hundreds of GPUs.
Some systems, like those pioneered by Celestia and EigenDA, leverage DA proofs, which allow the client to sample and verify a few random pieces of data, ensuring that validators have not deleted the data. These DA light clients can provide statistical guarantees that the whole block is available. Why this is important: In certain blockchains with high data throughput, lazy nodes might not store any data at all, since they are not incentivized to do so. This means that a light client could receive data for an invalid (non-existent) block. This is especially important for validiums that process a large amount of data, like zkPorter, and don’t want to make it available in a secure L1 (too expensive) or in a centralized provider (too insecure).
Mina is one example of a system which provides proofs of correct execution, and it goes even further, by creating a recursive SNARK that compresses the entire blockchain into a small, tens-of-KB-sized data structure. Other examples include zk-rollups like zkSync Era, Polygon zkEVM, Scroll, and Zeth, which prove execution using SNARKs. While these L2s can be verified with light clients without verifying the L1, using a more decentralized L1 as an additional settlement layer reduces trust assumptions.
With all the previous techniques, light client proofs can be both extremely secure and efficiently verified. However, there is still the question of who is providing the proof to the client, since this party can potentially hide information.
If a light client wallet simply connects to the wallet company’s server, the client must trust that the company isn’t hiding the latest blocks. This can lead to several types of attacks, like censoring data or providing incorrect state. In PoW and some non-slashing PoS protocols, the company can provide a proof of a valid fork of the blockchain which is not recognized or seen by others. Verifying that a certain blockchain is valid is not the same as verifying that it is the longest. This leads to even worse attacks, which can be mitigated with slashing and Merkle exclusion proofs.
Ideally, a wallet or bridge contract would receive proofs from multiple parties; for example, from multiple companies’ hardcoded server addresses, or even from random RPC nodes in the network. As long as one of these parties is honest, the client will receive the valid canonical proof, and lying or censoring become difficult. This assumption (that at least 1 of N parties is honest) is called the existential honesty assumption. Another way to phrase this is that a client needs to resist eclipse attacks, where the client is connected to only dishonest nodes and cannot access correct information.
It’s also worth noting that wallet developers must take care when using untrusted RPC nodes in the network to fetch proofs. These nodes have no performance guarantees, and could affect the user experience of a developer’s application. Instead, the client could opt to rely on a central server, and also fetch signatures from other nodes in the background to attest to the results. This approach (currently taken by Kevlar) can help bolster a light client’s security, without sacrificing user experience.).
In PoS systems where signers don’t get slashed for creating fake blocks, there is a risk that dishonest validators will sign invalid headers or data and provide them to light clients. As a worst-case scenario, a 51% attack on a network where light clients don’t verify execution would be catastrophic. This is especially true in the context of a bridge, since an attacker could mint fake assets. Developers can discourage this sort of attack by writing a smart contract (or core L1 feature) that slashes the stake of nodes that sign invalid data – see this interesting proposal from Etan (Nimbus team), which talks about slashing for the Ethereum Sync Committee.
As explained in previous sections, light clients that verify both execution and DA, as well as consensus, are less vulnerable to dishonest validators. That said, slashing can still provide additional security by preventing certain attacks.
Finally, let’s quickly cover one last consideration for some users: The privacy of the light client itself. Although using a light client can reduce reliance on centralized company servers, doing so can also expose the link between the user’s blockchain addresses and their IP to multiple random nodes instead. Some light client protocols like Neutrino (Bitcoin) can hide a user’s addresses when fetching data, but this might be harder for EVM systems and systems with a large amount of state. It’s possible that privacy infrastructure like Tor or Nym can help here, by hiding the user’s IP.
One potentially more secure way of providing privacy for light client wallet users is through the use of trusted execution environments (or TEEs) on the wallet server. The wallet server can encrypt the blockchain state’s data with a key that is only accessible from the TEE. When making a request, the user encrypts that request with the TEE’s key, delivers the message to the server, and the TEE processes the request without revealing the result to the server. This is not easy to do securely, and an efficient encrypted memory scheme is required, such as ORAM.
The Merge brought about efficient light clients for Ethereum via epochs and sync committees, along with renewed interest in building Ethereum light clients – including Lodestar, Nimbus, Kevlar, and a16z-developed Helios. Let’s take a quick look at some of their properties:
Sync committee and weak subjectivity. Ethereum’s consensus algorithm uses weak subjectivity, and therefore the protocol allows for extremely fast syncing – just two seconds in the case of our Ethereum light client Helios. We explain our approach in much more detail in this post, including how the sync committee, BLS signatures, and weak subjectivity can speed up syncing.
Verifying execution. Although Ethereum light clients do not yet verify execution, there is a path to add this in the future with zkEVM provers like zeth, making light clients even more secure.
Verifying state in an L2. Since L2s are becoming more popular, a natural question to ask is whether light clients can access state in Ethereum L2s? The short answer is yes. The longer answer: To verify state in an L2, the application must run light clients for both the L1 and L2. The L2 light client would verify the L2 “consensus”, which can be signatures from a centralized party, or something more complex like tendermint. Another option, explored by StarkNet light client Beerus, is to have an L1 light client with an L2 stateless client verifying the actual SNARK and optimistic proofs that are created by the L2. This increases security, but adds complexity and reduces performance.
One problem to address is that commitments for L2s can take quite a bit of time to get posted onchain. A SNARK proof in a rollup could feasibly take tens of minutes to get posted, and the same applies to optimistic rollups. An interesting approach to increasing efficiency, described by a16z crypto engineer Noah Citron, is to allow anyone (e.g. the sequencer and other L2 nodes) to make commitments to L2 state hashes. If these parties see the posted data on L1 and know that it will result in a certain state hash, they can stake on it and stake their funds. When the proof is finally finished and posted, parties will get slashed if the resulting state corresponding to the proof is different. This would provide some cryptoeconomic guarantees that can almost immediately give users more confidence in the posted state.
Even as the technology improves, most crypto wallets don’t use light clients (and many are still custodial). Most bridges rely on multisigs (or centralized blockchains) of anywhere from 1 to 30 parties, many of which are closely related companies or individuals, and do not secure their messaging with light clients. So why aren’t light clients seeing broader adoption?
There are many reasons why this could be the case, and they differ between wallets and bridges. A few:
For wallets in particular, the incentives to add light clients don’t currently outweigh the drawbacks. Self custody is generally thought of as the path to truly owning crypto; this commonly held belief, though it is not necessarily the case, is what many users value, not light client security. Light clients don’t currently make it easier for developers to comply with laws and regulations; they can also complicate development, lengthen engineering time, and potentially detract from customer experience.
For bridges, on the other hand, users and developers want to upgrade to light client security, but there are other roadblocks. The efficiency of these protocols is not there yet, and blockchains are not yet powerful enough to verify the proofs. This is evolving quickly on both fronts, through more compute on the destination side (Solana, Sui, Aptos, Ethereum L2s like zkSync and Optimism), and protocol support on the source side (Ethereum sync committee).
Light clients still have a long way to go, both in theory and implementation. Despite that, it’s clear that light clients can enable the future of secure bridging and wallets, while remaining extremely efficient. Blockchain protocol teams can push the web3 industry forward by standardizing and releasing light client protocols to access state, and wallet and bridge developers can level up the security of their applications using light clients.
A few areas for potential exploration:
In the last five years, significant progress has been made by academic researchers, blockchain designers, and engineers, in light client protocol design, deployment, and SNARK proving.
Over time, we can start to increasingly rely on this infrastructure, and hopefully live in a world where everyone can permissionlessly access and interact with global crypto networks.
***
With thanks to: Noah Citron, Nusret Tas, Guy Wuollet, Joseph Bonneau, Valeria Nikolaenko, Eddy Lazzarin, and Stephanie Zinn
***
The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the current or enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.
This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investment-list/.
Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures/ for additional important information.
