We would like to personally thank Madhavan Malolan, Hersh Patel, Dawufi, Joshua Peng, YJ, Danilo, Vicky, Xiang, and Tracy for their valuable insights and review of this report.

The verifiable web is a new paradigm for the internet, where trust is replaced by cryptographic proof. At its core, it’s about enabling users to verify the authenticity and provenance of their own data in a decentralized way. Web proofs (aka “zkTLS”) are shaping up to be a core piece of this puzzle, offering a mechanism to cryptographically authenticate any data exchanged over HTTPS. While much has been written about the technical architectures of web proofs, the more pressing question is: What will this technology actually be used for?

This report shifts the focus from technical debates to actual use cases. Builders in this space aren’t asking for yet another breakdown of architectures – they’re asking, how can this tech solve real-world problems? How can we convince businesses to implement our web proof protocol?

So let’s focus on that.

If you’re new web proofs, you can find our primer on web proofs and their application-relevant technicalities in the Appendix.

As you might have expected, a technology for “verifying data” has a lot of potential use cases. However, it’s too early to predict which specific applications gain traction first, or fail to gain traction. Even builders in the space have been surprised by where they are starting to see demand. What’s clear is that demand is just starting to pick up, and as it grows, it’s likely to branch out in ways we may not expect.

What I can see is that broad objectives are forming across the use cases. So far, across 20+ interesting use cases I found in doing this research, I see them branching out into four general objectives:

• Credentials: Objective is to prove personal data to a third party.

• Data Integrity: Objective is to improve data accuracy and reliability.

• Data Portability: Objective is to move personal data from one platform to another.

• Data Assets: Objective is to monetize data.

There certainly is some overlap between these, as all of them share in common verifying data for others. While some use cases apply to multiple categories, I highlight them where I think they are most relevant. Organization by objective is a useful way to start to see how web proofs will be used. A few emerging use cases don’t fit neatly into any of the above categories so I’ve put them in an “Other” category as shown in the figure below.

Web proofs allow projects to expand airdrop eligibility beyond onchain activity, enabling them to target users based on offchain actions. Traditionally, airdrops have been limited to users with verifiable onchain histories, because that was the only relevant verifiable data. But, that restricts the pool of eligible participants to those already active in crypto. With web proofs, projects can now verify whatever you do or have done online–such as holding stocks on Robinhood, making purchases on Amazon, or listening to an artist on Spotify–without needing permission from these platforms. This opens up a much larger audience for airdrops, reaching users who may not yet be “in crypto” but do relevant and valuable actions on web2 platforms.

As Dan from Nascent notes in his report, “Overnight, the addressable population of airdrop recipients has gone from a few million existing crypto users to the majority of the global population.” With web proofs, projects can verify meaningful real-world behaviors like peoples’ spending habits or engagement with various services. This not only broadens the reach of airdrops but, importantly, helps distribute tokens to real users doing real things rather than Sybil attackers with big wallet farms.

For instance, let’s say Lady Gaga wants to do an open mint available only to her biggest fans. So she can use a web proof to set a criterion that “Lady Gaga” is the top artist in your year-end Spotify wrap-up page. Without web proofs, that wouldn’t be possible without getting a signed statement from Spotify (not going to happen), plus, it’s a lot harder to Sybil attack this behavior than volumes or LPing into a DeFi project.

Related example:

• Zora, but on Instagram content: Instead of asking people to post fresh content on a new app, let people bet on virality of Instagram posts. E.g., someone posts a meme token on IG, early viewers mint a web proof of their interaction with the content, and are rewarded more based on how early they are, whether they shared, how many of their friends interacted with the content, etc. Asymmetric upside if the meme goes viral.

One of the major limitations in DeFi is the absence of credit scores which could be used for lowering collateralization requirements or individualized borrowing terms for better capital efficiency. With web proofs, offchain credit data including FICO scores, income statements, and credit payment histories can be securely verified onchain in a privacy-preserving way with arbitrary disclosure, and used for onchain credit score verification. This data can also be combined with onchain credit history in a hybrid DeFi credit score algorithm. Achieving credible onchain credit for our digital identities would enable a wide range of new DeFi products around personalized lending rates, dynamic collateral requirements, and risk-based interest models. Defaults would penalize onchain creditworthiness and reputation of the digital identity and potentially its social graph.

Relevant projects: zkCredit, zkCreditScore

Expanding on the above, apps can use web proofs to enable personalized pricing based on verified user data (e.g., discounts for frequent buyers). For instance, an e-commerce platform could offer discounts to frequent buyers by verifying their purchase history on Amazon using web proofs.

In DeFi, web proofs can be used to grant exclusive access discounts or other features based on whether they’ve proven they’ve met certain criteria. For example, using Uniswap v4 or PancakeSwap’s hook feature, a user can prove they have a 30-day spot transaction volume > $500 on Coinbase or Binance and they’ve are monthly active users on Base or BNB Chain, making them a “high value” target for exclusive access pools on a DEX. Primus is building this.

Just as web proofs expand airdrop criteria beyond onchain behaviors, they also expand gating criteria in the same way. This opens up a new way to build “open but private” communities, where access is based on verifiable behaviors rather than manual invitations or complex gatekeeping. The benefits are online communities that strike the middle ground between broadcast platforms that are too open and diluted by low-quality interactions or too closed and only accessible by people who already know each other. With web proofs, anyone can join a private group chat as long as they meet specific qualifications – without needing an invite. With people increasingly using the web to find each other and form relationships, this is a promising direction. Tonk’s Speakeasy is building this.

Related example:

• Bootstrap communities based on verifiable credentials. Only people with certain credentials can receive onchain funds to start a community. Relevant project: Coordination Lab.

Automating manual verification processes is another category where web proofs have a lot of potential to cut operational costs and streamline operations. Tasks that previously required manual verification can be automated with web proofs. Daisy, for example, uses web proofs via Opacity to automatically verify influencer engagement, replacing the need for screenshots and manual checks. Similarly, on CT, many influencers fake screenshots of massively profitable trades but web proofs could parse the real trading success stories from the faked ones.

Another example would be an employment website that needs to verify resumes and match applicants with suitable jobs. Many people lie in their applications and resumes, and the current solution to this problem is very inefficient, requiring an army of checkers to call universities and former employees to verify applicant details. With web proofs, this process can be entirely automated, disrupting this industry in a good way.

Data quality is particularly important in the age of AI, where verifying data increases its value by reducing noise. All big AI companies like OpenAI, Anthropic, Meta, Google, etc. need to do reinforcement learning from human feedback (RLHF). For RLHF, it’s crucial to get high-quality labeling on images and other media to train AIs to be able to accurately detect and interpret what they are “looking” at. For instance, Scale AI is doing this at massive scale but they outsource data labeling to SE Asia and Africa and other markets where labor is cheap. For some labeling tasks, e.g., in medical or legal, they need expert labelers so it is crucial to verify that the labelers have sufficient knowledge to accurately label in these domains (e.g., by proving they are indeed an MD or JD). Web proofs are an efficient way to verify labeler quality and weed out the bad actors lying about their credentials and providing inaccurate – and potentially dangerous – training data in these high-stakes domains. Automating credential verification with web proofs not only improves the integrity of AI training datasets but also streamlines operations.

Another way to teach AIs is to collect high-quality conversation data from mature AI products like ChatGPT and feed those into a new model (e.g., customized small language model), to improve its output. Web proofs could be used to verify this data too, as well as the specific AI model used. This not only boosts the new model’s output but also reduces the costs of training a new model from scratch. Here’s a demo of using web proofs to verify a ChatGPT conversation with Primus.

Proof of Humanity. Use web proofs to verify real user data to combat bots in social platforms or other apps. For example, Equal, uses web proofs of order history on Swiggy, an Indian food delivery app, to verify humanity. Another relevant project: Humanity.

AI agents have recently taken the crypto industry by storm. But there is a real problem of proving which agents are actually autonomous. On X, all it takes to get the “Automated” badge is to post via API, but you don’t need an AI to do that. To solve this problem, web proofs can be attached to posts to verify that an agent’s output originated from a specific AI model, without the computational complexities and risk of adversarial machine learning attacks of full on-chain inference.

Web proofs can be used to gate reviewers who actually have bought a product, used a service, or visited a place. For example, Trustpilot could use web proofs to verify that reviewers have actually used a website that they are reviewing. This would help combat fake reviews and manipulation, thereby enhancing the trustworthiness of the platform.

Web proofs can bridge the gap between less reliable web3 fitness trackers and more robust web2 platforms like Strava by verifying fitness activities directly on the latter. This approach involves users generating cryptographic proofs of their fitness activity (e.g., steps per day) using a tool like Reclaim’s zkFetch, enabling them to link robust data from Strava to on-chain rewards or challenges, ensuring behaviors and rewards are aligned. Relevant project: Verifit.

Web proofs can enable verifiable resource usage and consumption in DePIN networks. For instance, Daylight is building a DePIN power plant where it is essential to accurately track energy contributions and usage across the network (see also Sourceful and Combinder). They're working with Opacity to cryptographically verify energy consumption or production data from smart meters or utility platforms, bypassing slow or manual verification. Similarly, in the carbon credit market, web proofs could improve transparency and trust in energy trading or carbon credit issuance without reliance on centralized energy providers.

Web proofs offer a solution to the “cold start problem” faced by new businesses by enabling them to verify user data from competing platforms. The cold start problem refers to the challenge of kickstarting the network effects for a new platform or service that relies on a critical mass of users to provide value. With web proofs, new platforms can attract users by enabling them to port their data from other platforms to reduce the friction of platform switching. By combining this with incentives for switching, a new platform has a better chance of reaching the critical mass to get started.

Web proofs are already starting to be used for this. Teleport is a web3 ride-sharing app that is working with Opacity to enable drivers to import their Uber ratings via web proofs, giving them instant credibility on the new platform. Nosh is a web3 food delivery app using web proofs to enable eaters to import their purchase history on DoorDash to receive discounts and other incentives on their platform.

Another way to construe this is that web proofs facilitate vampire attacks on web2 marketplaces, where new platforms lure users away from incumbents by offering attractive incentives based on the activity of top users on the incumbent platform. And there is nothing stopping web2 companies from also using web proofs to vampire another web2 company. In fact, the term “vampire attack” originated in web3 because the verifiability of onchain data by third parties enables it. By making offchain data verifiable in the same way, we could start to see web2-web2 vampire attacks like Sushiswap’s vampire attack on Uniswap or Blur’s vampire attack on OpenSea. The reason it’s rare to see that in web2 is because data silos restrict user data within individual platforms, making it challenging for users to migrate without losing their accumulated profiles, reputations, or networks. This will have important implications for competition in web2 projects, especially on how they build defensibility and compete on prices.

Web proofs break down these silos by solving this data portability problem. They allow users to permissionlessly create cryptographic proofs of their interactions with web2 platforms and share this verified data with other platforms. Think of it as user-generated APIs that bypass centralized control over your data. For example:

• A new social media platform could use web proofs to let users import their social graphs from X, LinkedIn, Instagram, TikTok etc.

• A new e-commerce platform can learn a lot about your shopping behavior by using web proofs of your purchase history on Amazon.

By empowering users to own and verify their online activity locally, web proofs make it easier for emerging platforms – whether in web2 or web3 – to attract users from incumbents. It shifts the power dynamic in favor of users and new entrants, fostering healthy competition and innovation in traditionally closed ecosystems and dismantling their walled gardens.

Related example:

• Porting reputation and social graphs: Bootstrap an onchain social product using creator reputation from existing offchain apps. For example, Drakula could use web proofs to verify crypto-relevant TikTok followers to vampire them over to Drakula.

Web proofs provide a secure and verifiable way to access high-value private data for AI model training, which is increasingly important as public datasets are exhausted. AI models, especially LLMs, need access to more personalized and diverse data to improve their performance. However, using private data, such as user behavior and transaction history, introduces challenges around data integrity and privacy. Web proofs combined with zero-knowledge proofs (ZKPs) or “blind computation” (e.g., Nillion) can address these issues by allowing AI developers to verify the provenance and authenticity of our private data without revealing privacy-compromising details. It effectively imparts more value to the data shared for training because verifiable data is more valuable – it reduces the risk of data poisoning or manipulation during training.

There are interesting economic implications. Web proofs empower the user to take control over their private data, share or hide what they wish, and sell it in a high-demand marketplace where AI model creators seek high-quality inputs to build the best models. It is win-win for the user and the AI creators, as users earn from their data while facilitating the development of new AI applications in areas where privacy is paramount like in healthcare, parenting, finance, and science.

For more information, check out Zap’s decentralized data pools and Vana’s private DataDAOs, both being built on Reclaim.

Extending the concept from “sell your data” to “pay with your data”, AdGraph is an advertising framework enabling users to exchange verified data for services instead of money. Leveraging web proofs, AdGraph allows users to securely share aspects of their data (e.g., shopping habits on Amazon, what you engage with on Instagram or TikTok), while preserving privacy. Participating brands can offer personalized pricing, discounts, or access to exclusive features for your data, creating a win-win scenario where users benefit from better deals, and companies benefit from better targeting.

The AdGraph idea can be extended to identity marketing, where users capture data from their web2 activities and then prove arbitrary statements about any slice of their internet identity to marketers. Businesses can leverage these proofs to build marketing campaigns around users’ revealed preferences. The user takes ownership of their personal data and sells it to businesses for developing their identity marketing campaigns.

A marketplace where users can monetize their personal networks by securely facilitating introductions. Seekers of a network connection attach tokens to requests for connecting with specific individuals. Connectors act as intermediaries by proving their relationships with web proofs. Connectors only earn rewards once they successfully make the introduction and verify it onchain. The result is a decentralized, incentive-driven system for leveraging social connections. Relevant project: Covariance.

Extending from monetizing connections, web proofs can also be used for monetizing expertise. This would work on a platform where members use web proofs to prove their knowledge, expertise, and connections. Those with web-proofed verifiable credentials have more earning potential in any domain their verified profiles are relevant. For example, imagine Fiverr or Upwork, but where freelancer profiles are verifiable.

There really are myriad potential use cases of web proofs. While the majority of interest and development so far can be oriented into the groupings above – I’ve also seen creative applications that don’t fit well into these categories. Here are a few that resonated with me:

In prediction markets, oracles are necessary for resolving outcomes by providing data from trusted sources. Web proofs could be a powerful oracle solution by enabling verification of offchain (“real world”) data. For instance, in the US presidential election prediction market, web proofs could be used to submit verifiable data from a trusted news source declaring the winner. The benefits over human-coordinated dispute resolution like Uma’s optimistic oracle used by Polymarket are multifold:

• Direct access to verifiable data

• No need for human intervention

• Less risk of manipulation or bias

• Less ambiguity

• Faster resolution

There’s already a working example of this in @0xsmallbrain’s TMR.NEWS, where users bet on the next day’s New York Times’ headline. The system estimates how close the user’s predicted headline is to the actual headline using an LLM, and payouts are made accordingly. Both the data from New York Times and the LLM is brought onchain using Reclaim’s zkFetch.

Web proofs can be used to bridge offchain transactions with onchain assets, enabling users to submit verifiable proof of offchain payments (e.g., through Venmo or PayPal) and receive funds from an onchain escrow. This creates a web2 onramp that allows users to use familiar web2 payment systems as a fiat-to-crypto onramp. The design could be as follows:

• Set up an onchain escrow smart contract that holds tokens (e.g., USDC, ETH) that will be released once the offchain payment is verified. The escrow is funded by a crypto-to-fiat off-ramper.

• The on-ramper initiates payment using Venmo or other web2 payments platform.

• The on-ramper uses web proofs to verify transaction details like sender, recipient, and amount.

• The on-ramper forwards the proof to the escrow smart contract, which verifies it onchain and then releases tokens to the on-ramper’s wallet.

A relevant project here is ZKP2P.

Web proofs enable traditional web2 games to augment their platforms with a web3 economic layer. Take, for example, the Fantasy Premier League (FPL), which people typically play on their phones for points and entertainment. Currently, players can set up informal betting pools with friends, where the player with the highest points wins the pool. With web proofs, players can prove they earned the most points to liquidate the jackpot in a verifiable way. This idea can be extended to all sorts of web2 games where people need to prove an offchain game outcome for onchain rewards.

This exploration of web proofs reveals their vast potential across diverse sectors, including finance, marketplaces, social media, operations, and AI – showcasing their ability to unlock a wide design space for innovative application development. Despite technical hurdles and potential legal resistance from traditional companies seeking to safeguard their data silos, these challenges are likely temporary (see Appendix for more details). Based on where we are now and where things are heading, stagnation in this space is unlikely. The future of web proofs points toward developers and businesses leveraging this technology to build better applications that automate credential verification, improve data accuracy and reliability, enable seamless portability of personal data across platforms, foster community-led data marketplaces, and much more.

If you’re building in these spaces or this post resonates with you, let’s chat!

A web proof is evidence that information came from a specific website and hasn’t been altered. Previously, this kind of verification was only possible when the website offered a specific API or signature for this service. Web proofs enable anyone to prove information received via HTTPS from any website, even if the site doesn't have a specific API or signature for this service. They are a workaround to the absence of any standardized HTTPS message signatures (see RFC9421).

There are two “must have” properties of a web proof (easy acronym: APP):

• Authenticity: The ability to prove that data hasn’t been tampered with by the user.

• Provenance: The ability to verify that the data truly came from a specific website.

And a third “nice to have” property:

• Privacy: Also called “selective disclosure” – this is the ability to reveal only necessary information but not anything else.

Think of web proofs as a tool for user-created “APIs on demand” that let you prove to others that specific data you received from a website is real and trustworthy. It empowers the user to share data received from a website with any other party in a verifiable way.

This can be useful when you want to show someone some piece of information from a website without them having to trust your word alone. Or, if you want to provide a specific piece of information without sharing others. For example:

• I can prove to a web3 food delivery service that I am a frequent DoorDash user by producing a web proof of my DoorDash purchase history page.

• I can prove to a creditor that my bank balance is over a certain amount by producing a web proof of my current bank account page showing my balance.

More formally, the web proof proves the following statement: “A user received response R from website W for request Q and response R contains the string S.” (HT Moyed).

Here’s a simple example: If I want to create web proof that I am the owner of the X account @blockhiro, this would involve creating a proof of the statement: “The user received the 'settings.json' response from x.com for request “https://api.x.com/1.1/account/settings.json” and settings.json contains the string 'screen_name: blockhiro.’”

Because settings.json requires authentication (logging in), I can’t simply go to someone else’s profile and impersonate them. So, if I prove this response is real, a third-party can trust that I am the owner of this X account (or at least have access to it).

Of course, some companies may not be happy with a technology that can break down their walled gardens. And, in some cases the legal ramifications of using this technology should be considered (e.g., when the data is IP of the company). However, for those concerned about violating the Computer Fraud and Abuse Act (CFAA), this report by Daniel Barabander concludes that web proofs are not in violation as long as the web proof browser extension does not directly control the user’s account. Power to the people.

The problem is that following the TLS handshake ceremony, the website and the user agree to use the same session key to encrypt and decrypt data during communication. After all, TLS was designed for securing communications between users and websites, not to prove the data we exchange with websites to a third party. But, this means that I could intercept the HTTPS response, modify it locally (e.g., change “screen_name: elonmusk”), and then forward the altered data to a third party. Since there’s no cryptographic proof tying the response back to the website, the third party has no way of knowing whether the data I sent is genuine or not.

To prevent that, I need some way to verify that the response was actually produced by the server – this is where web proofs come in. There are currently three main approaches, each with its own trade-offs: TEE-based, Proxy-based, and MPC-based.

1. TEE web proof (TEE-TLS): The basic idea here is to use a tamper-proof CPU (i.e., Trusted Execution Environment, TEE) to make HTTP requests. Because no one, not even the owner of the TEE can tamper with what happens in the TEE, you can verify the data communicated within the TEE. To produce “TEE-TLS,” you simply need to provide encrypted login credentials or Auth tokens to the TEE service provider, which then logs into the website and securely stores responses. The TEE then produces a signature proving data Authenticity and Provenance.

Representative project: Clique

2. Proxy web proof (Proxy-TLS): The proxy-based web proof introduces a third-party called a Proxy. The Proxy sits between the user and the website, mediating their HTTPS communication. The user sends their HTTPS request to the website via the Proxy, and the website’s response is also delivered through the Proxy. As the Proxy does not possess the decryption key and only the user has it, they cannot modify the data received. The Proxy serves two main functions:

   • Provenance attestation: The Proxy attests that the request came from the user and that the response originated from the website.

   • Encrypted data logging: The Proxy logs encrypted data, which, combined with a ZKP provided by the user, helps verify the authenticity of the data later.

Representative project: Reclaim

3. MPC web proof (MPC-TLS): The MPC-based web proof introduces a third-party called a Notary. The Notary shares part of the session key with the user, which is necessary for encrypting and decrypting TLS communications. This solves the problem of users modifying data received from a website because they no longer have full control over the session key – they have to cooperate with the Notary to decrypt or encrypt data. At the end of the session, the user creates a commitment (cryptographic hash of the data) and sends it to the Notary, who signs it without seeing the actual data (blind signature).

Representative projects: Opacity, TLSNotary, OpenLayer

Here is an overview of the trust assumptions, pros, and cons of each approach:

To adapt to use cases that require stronger security or less latency, there are also hybrid web proof protocols that adopt hybrid approaches, such as zkPass and Primus, which implement both Proxy and MPC architectures, and Pluto, which aims to combine all three approaches. The optimistic note is that aside from very high-stakes situations, the cost of attacking any of these protocols exceeds the expected gain, making Proxy good enough already for most cases.

All of these architectures have the same goal: to protect the integrity of the information communicated without exposing the shared session key, which would allow the third party to decrypt all the session data including your username and password.

• In TEE-TLS, the TLS shared key is generated and used within the TEE, so theoretically it should never be exposed outside this secure enclave.

• In Proxy-TLS, the proxy logs the encrypted data exchanged between the user and server, and a ZKP is generated by the user locally to prove that they can correctly decrypt the data without revealing the shared key itself.

• In MPC-TLS, decryption is done collaboratively between the user + N nodes, ensuring that no single party has the full shared key.

Here’s a flowchart comparing these processes:

Note that the ZKP for selective disclosure comes at the end of the process to augment data Authenticity and Provenance with the Privacy property. This is why I use the term “web proof” more broadly as actually the term could be more specifically identified as TEE-TLS or Proxy-TLS or MPC-TLS and their is no ZKP actually involved in the TLS handshake.

What is especially application relevant is the latency overhead introduced using different web proof architectures. For some use cases (e.g., influencer activity verification), latency sensitivity will be high. For other use cases (e.g., credentials), the proofs can be generated more slowly and associated with an account periodically (e.g., ENS address) and only require a signature as needed.

Right now, it is moot which approach is “best” – it largely depends on the use case and priorities (e.g., latency vs. security).

When people hear web proofs are for “verifying offchain data,” they often ask how a web proof differs from an oracle. While both aim to bridge the gap between offchain and onchain data, they serve distinct purposes and are useful in different scenarios. Here’s a breakdown of their key differences:

In short, oracles have found PMF for price feeds used in DeFi. Oracle architecture has proven effective for this specific use case and is likely to be the main mechanism for price feeds in DeFi going forward as they improve on speed and accuracy. Web proofs, on the other hand, are relevant for much broader use cases where the focus is on sharing private user data not accessible by oracles.

We live in a world overflowing with data but starved for verifiability. As AI accelerates the generation of information, cryptography becomes more essential to verify that information. Web proofs address the problem directly by expanding the scope of what is verifiable. The web right now is far from verifiable. Only a small subset of data – such as onchain transactions, JSON web tokens (via ​​OpenID Connect), emails (via DKIM), passports (via NFC), and verifiable credentials – were verifiable before web proofs. Web proofs enable a more verifiable web by enabling cryptographic authentication of any data exchanged over HTTPS, without requiring complex modifications to existing systems. Web proofs are user-controlled “APIs on demand” for the whole internet.

Building a verification layer for the internet has the potential to reshape industries. In AI, verification makes data more valuable by reducing uncertainty, which is critical for improving model training and reducing manipulation. In industries where credential verification is critical, web proofs can automate manual credential verification which is slow and expensive. In the startup industry, it’s hard to achieve network critical mass starting from zero (Cold Start Problem). Web proofs enable a “warm start” by solving the data portability problem, enabling a new entrant to siphon verifiable data from incumbents to bootstrap their initial network.

Perhaps most importantly, web proofs circumvent reliance on centralized entities that control user data. Currently, the main bottleneck preventing verifiable data from being widely available is that you need to get cooperation from the gatekeepers that control your data. For example, if you simply want to verify your bank balance, the only way to make that happen is by convincing your bank to add code to their servers to get you signed statements. This process is simply unscalable. Web proofs empower users to verify and share their data themselves, making verifiable data more accessible.

Disclaimer

This article is prepared for general information purposes only. This post reflects the current views of its authors only and is not made on behalf of Lemniscap or its affiliates and does not necessarily reflect the opinions of Lemniscap, its affiliates or individuals. The opinions herein may be subject to change without this article being updated.

This article does not constitute investment advice, legal or regulatory advice, investment recommendation, or any solicitation to buy, sell or make any investment. This post should not be used to evaluate the making of any investment decision, and should not be relied upon for legal, compliance, regulatory or other advice, investment recommendations, tax advice or any other similar matters.

All liability in connection with this article, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement is disclaimed. No warranty, endorsement, guarantee, assumption of responsibility or similar is made in respect of any product, service, protocol described herein.