Recent Progress on Bitcoin STARK Verifier

Bitcoin Scaling Solutions in a nutshell

Sep 19, 2024

In June 2024, StarkWare and L2 Iterative announced partnership and collaboration on scaling Bitcoin with STARK. Since then, a lot of progress has been made. This article is intended to be a mega thread that summarizes some recent developments on Bitcoin STARK verifier and shares some of our thoughts.

Scalability problems of Bitcoin

Bitcoin, like Ethereum, also has a scalability issue when it comes to sudden uptick of network activity, as shown by the high fee rate on the Bitcoin network. Here are a handful of examples this year.

Babylon (a portfolio company) opened for staking on August 22, 2024, with a cap of 1000 BTC in total (~USD $58M). Since the cap is first-come-first-serve, this both causes an uptick of network activity as well as an unforeseen competition between the eager stakers (see the news coverage #1, #2, #3). The Bitcoin mainnet fee rate went from 2-5 sat/vByte to, at the peak, 1058-5000 sat/vByte, with one transaction paying ~USD $1760 of transaction fees. The network quickly returned to normal after the cap was met, so the impact was well under control. But, this is an example why Bitcoin itself is not scalable for a one-time “crowdsourcing” of USD $58M. On Ethereum, the largest staking in-flow happened on May 23, 2023, which amounts to about USD $500M in a single day.

Ordinals have been popular since 2023. In the entire year of 2023, ordinals have contributed to two peaks of transaction fees, even surpassing 2000 sat/vByte. A close relative of ordinals, Runes, also gained a lot of fame since its launch. In two months, ordinals cost 2500 BTC in fees. Note that in comparison, Ethereum normally spent 10 BTC in fees per day. Fees provide a basic utility and enable tokenomics to work in a way that captures values or reduces selling pressure, such as incentivizing miners to mine as in Bitcoin or incentivizing holders to stake as in Ethereum.

These applications and use cases came to Bitcoin in recent years for many reasons.

Ethereum and the many altcoins, as well as their infrastructure, has been somewhat overwhelming to developers and users. Yet another EVM compatible chain, or even another Ethereum-aligned or -compatible layer-2, is no longer something new or novel, and people want applications or infrastructure that can unlock unprecedented applications. This can be exemplified by the pivot away from shared sequencers or rollup-as-a-service (RaaS) projects, as they find product-market fit challenging.

In contrast to altcoins whose price often falls after the enthusiasm or airdrop expectation disappears, old tokens, including Bitcoin, Ethereum, and Solana, appear to be more attracting crypto assets that are safe to hold for long-term passive investment. Even if their price goes down, they seem to often come back (not investment advice). This draws a lot of market attention into Bitcoin and Ethereum, especially from the consumers and now, also from institution players since the approval of BTC and ETH ETFs by the SEC.

Even though Ethereum and Solana have a lot of functionality and fun stuff on their blockchain ecosystem, their FDV is still incomparable to Bitcoin. Ethereum is only 24% of BTC, and Solana is merely 5% of BTC. If without an ecosystem BTC can already perform this well, it seems to suggest that a token that is truly decentralized and without a foundation that sells tokens on and off to pay for its cost (#1, #2) have some unique potentials and market positions.

Bitcoin might be able to do whatever Ethereum and Solana can do. Recent upgrades on Bitcoin, SegWit and Taproot, have enabled some interesting use cases, although fairly simple, on the Bitcoin network. They do have tradeoffs and limitations, and often have to cut corners to work with the current Bitcoin protocol, but they do show us that Bitcoin is not a cold, ossifying blockchain that can only be useful for token transfer, but it can do many things. In particular, the rise of layer-2 technologies makes it natural for people to solve the problem or limitation of layer-1 through layer-2.

The demand from these applications and use cases, however, started to be controversial.

On the one hand, people worry that these applications and use cases may bring altcoin culture from Ethereum to Bitcoin and change the belief system and culture of Bitcoin, and more concretely, worry that they take up too much of the Bitcoin network resource and are somewhat “spamming” the Bitcoin network. This includes, for example, OCEAN Mining, which is a mining pool that implements a filter to remove all transactions that are involved in ordinals or BRC20, wanting to conserve the traditional impression of Bitcoin.

On the other hand, there are also sound arguments that Bitcoin needs to welcome these applications and use cases. The strongest reason is that Bitcoin’s base block reward (a fixed amount) has already halved a few times and will continue to halve in the future. If the block reward becomes fairly low but the BTC price does not go similarly higher to make up the difference in real-world-currency block reward, then miners may slowly quit until the cost of mining (e.g., electricity) goes down to meet the lower block reward. This would be a self-destructing situation for Bitcoin price. There are only two solutions. One is to increase the non-base block reward, i.e., transaction fees. Another one is to create more demand and interest on the BTC tokens itself, such as finding more utility or increasing the circulation of BTC tokens. There have been some financial analysis articles (#1, #2) that suggest, for example, that ordinals and others may be net positive for Bitcoin economy.

From a technical point of view, the major restriction on Bitcoin’s scalability has to do with the block production rate as well as the block size. Both parameters, however, cannot just be simply increased, as they are inherent to the network security and liveness, and adjustment would require careful study to see if it is safe to do so.

If one wants to significantly increase the block production rate, it may increase the risk of selfish mining.
If one wants to significantly increase the block size, it may lead to higher storage requirements and network overheads for full nodes.

Even if we, based on the development of Internet and computer computing power, decided that it is safe to increase, getting the network consensus to proceed with it would take a lot of the time, as a change in block production rate or block size would be a “hard fork” that makes the chain forever incompatible with the previous implementation. Although this may eventually happen one day, it is not a permanent cure, and it would be a heavy way to fix it.

How to scale up Bitcoin?

A sidechain would not work because it would not be very different from an existing EVM-compatible chain that uses wrapped BTC on Ethereum through an EVM-based bridging system, for which we already have many. To really capture the uniqueness of the Bitcoin as a decentralized network and the Bitcoin token itself as a unique type of asset, this scaling solution must be “based” on Bitcoin. Doing so also allows these projects to stand out from the many Bitcoin “layer-2” projects (many of which would be, per the standard by Bitcoin Layers, considered as just sidechains, not rollups) rather than being a copycat.

To think about what a Bitcoin-native solution would be, we should learn from a notable example, Lightning Network. The core idea of Lightning Network is that many routine micropayments happening in the real world, such as buying a coffee, can be handled in an off-chain approach that batches the payment between a customer and a merchant and only settles after a certain billing period. This is in essence similar to the “bar tab” in the real world. To do so, two users who expect to have frequent transactions in Lightning Network can create a payment channel between them, serving as a “bar tab”. If two users do not have a payment channel with a desired payee, they can find if they can go through several payment channels.

Lightning Network has been used in production and actually has been supported by many major centralized exchanges as a way to deposit or withdraw Bitcoins. It is useful to note that Lightning Network also offers some notion of privacy, as only the final settlement amount of the payment channel is revealed on the public network.

The downsides of Lightning Network, which are why the scaling problem of Bitcoin is not solved yet, are therefore worth a careful look.

To prevent another party of the payment channel to maliciously close it with an outdated balance, each party needs to either, by themselves, carefully look over the Bitcoin blockchain and challenge the closure before it is completed, or find third-party services, called watchtowers, to witness the Bitcoin blockchain on behalf of the user. This somehow increases the overhead of the Bitcoin network, adds some burdens to the users, and often makes the Lightning network not fully trustless for many users who cannot watch the Bitcoin network themselves. This has been the main limitation because a failure to detect malicious closure and stop them within the prescribed time will end up simple money loss.

Routing through multiple payment channels is sometimes easy, sometimes difficult, and is based on public nodes and their channels. This already implies another fundamental limitation—one cannot send the payment to another user who does not have any active payment channel with one of the public nodes, which likely constitute the majority of the Bitcoin users. The necessity for a user to “register” in the Lightning Network in order to receive payments (and do not forget the need to watch over the blockchain) may already exclude users who do not have any demand to set up Lightning Network.

If two users are unlikely going to make repeated payments, but the payment is in nature a one-time thing, it may be easier for the two users to just complete the transfer on Bitcoin directly, as setting up the payment channel itself takes time when they do not have existing channels between them.

Lightning Network, by design, is limited to the BTC tokens itself, and it is limited to sending money between real people who are running nodes or watchtowers. This excludes the current architecture of Lightning Network from handling staking, bridging, “smart contracts” like dApps, BRC-20, Ordinals, and Runes.

These give us some ideas about what a Bitcoin scaling solution with real demand and utility should look like.

Like Lightning Network, it should be based on Bitcoin and the Bitcoin network.

It should try to be user-friendly and relieves the users from the need of becoming, for example, an active Bitcoin full node.

It should try to do whatever Bitcoin mainnet itself can do, and ideally more than what Bitcoin mainnet can do, rather than realizing just a smaller subset of the functionality with some restrictions that may hinder user experience.

So far, we know three approaches that are getting close to achieving these goals.

Merged mining. The idea of merged mining dates back to 2010 and the idea is to have Bitcoin miners to also secure smaller networks at the same time while earning some reward. You can imagine this to be a version of Babylon but instead of staking BTC tokens, it is the miners who stake their “mining power”. The limitations of merged mining are also quite well studied. First of all, since Bitcoin mining centers around a few mining pools, whether a network can get meaningful support from the miners can be reduced into the problem of whether they can get meaningful support from the mining pools. Otherwise, the small network may only get a small group of miners who may not be able to mine a block on Bitcoin mainnet for days or weeks. There is also the need to convince the mining pools that merged-mining A is better than merged-mining B, as doing merged mining itself brings in overhead to the mining pools. Other than these factors, it is also important to make sure that miners follow the consensus protocol of the additional chain rather than mining on a block that violates the consensus rules and should be considered invalid. The amount of reward given to the mining pool needs to be sustainable and long-term, and it would eventually be a problem on how to find such reward for the miners to continue engaging with the blockchain—it basically returns to the classic problem of how to boost and manage a PoW token.

BitVM, or more generally, optimistic rollup. An idea started last year by Robin Linus is BitVM, which can be roughly described as the optimistic rollup or off chain computation with fraud proofs. We can see it as an extension of Lightning Network with new technology: in the Lightning Network, users need to watch over the Bitcoin network to detect and stop malicious channel closures or recruit watchtowers to do so in a timely manner, and the same concept applies to optimistic Rollup as well as BitVM. Here, BitVM allows some operators to run arbitrary off-chain computation and commit the execution trace on the Bitcoin network. If someone believes that the operator is being dishonest, it can challenge the operators on the Bitcoin network, where the operators are required, by the protocol, to respond to the challenges. BitVM can be launched on today’s Bitcoin mainnet with the use of a trusted setup by multisig, or the multisig assumption can be removed with OP_CAT. The main limitation of BitVM is that, for the current implementation, the challenge period can sometimes be a bit long especially if the operators are not very collaborative, and we are still waiting to see a full-fledged implementation that has all the fraud proof mechanisms in place. This may not be easy—think about Optimism, with the token listed in June 2022, only has the fraud proof systems deployed on mainnet in early 2024.

STARK, or more generally, ZK Rollup. The natural alternative to optimistic rollup is ZK Rollup. Instead of doing fraud proofs, we can avoid the challenge-response complexity all at once if we verify the entire offchain computation on Bitcoin. However, this can meaningfully scale up the Bitcoin network only if the cost of verification is significantly smaller than computation itself. We saw positive results from Ethereum, from Polygon, StarkWare, and zkSync, that ZK Rollup is mature enough to support arbitrary computation and the verification cost for settlement on the layer-1 does not grow with the size of the offchain computation. There have also been positive signs that the settlement latency for ZK Rollup tends to be much shorter than optimistic rollup. The main issue about ZK Rollup on Bitcoin is that it fundamentally requires OP_CAT, and a full proof verification is going to be probably USD $1000 in transaction fee every time and cannot be done too often (this is acceptable as some ZK Rollup on Ethereum does the proof verification every 10 hours), and it might be more sensitive to fee spike.

Note that these solutions are not exclusive to each other, and there are various ways to combine and mix them. To start with, merged mining is almost orthogonal to either BitVM or STARK. One can use BitVM or STARK as an additional mechanism to prevent malicious miners and sustain even if miner participation is suboptimal, and BitVM and STARK can use some sort of merged mining to get some alignment with the Bitcoin miners. Then, BitVM and STARK can also be combined together. For example, while STARK is more expensive to verify, BitVM has the benefit that it usually doesn’t require a significant overhead to post the commitment on chain, so a ZK rollup can do many small BitVM throughout the day and, at the end of the settlement period, post a STARK for final settlement. Another way to combine is to use BitVM to verify a STARK (or a SNARK, as is in the current BitVM 2 implementation), with the reliance of enough public watchtowers that look over the correctness of the broadcast proofs that are pending for verification. One should see that some of the infrastructure of Lightning Network can be repurposed and reused here. A finishing note is that combining and mixing has its downside, as it would also bring in the problems and issues of these solutions (as we discussed above already). For example, merged mining does fundamentally change the tokenomics and how network consensus changes can be made.

Researchers and engineers from L2 Iterative, Weikeng Chen (Research Partner) and Pingzhou Yuan (Research Engineer, now working at Bitlayer), have been working on both BitVM and STARK—we contributed a lot of code toward the first Bitcoin script implementation of the prototype fflonk verifier for BitVM, which is the strawman version that a number of companies, including Bitlayer, Zulu, and Fiamma, built over and optimized (and ended up significantly overperformed this first version), while later, our attention has been mostly focusing on Bitcoin STARK verification, using OP_CAT.

How Did We Get Here?

Our work in Bitcoin STARK verification is a partnership and collaboration with StarkWare, who is also a limited partner (LP) of L2 Iterative.

It started when we were researching what would be the ZK proof system that has the lowest overhead on Bitcoin (aka, Bitcoin-friendly) when we are helping Polyhedra (a portfolio company) to find solutions for a cross-chain bridge between Bitcoin and the other chains. There are many ZK proof systems, but we need a ZK proof system that only involves smaller integers, since Bitcoin Script only supports signed 32-bit addition and subtraction (no native multiplication).

This reduces to two kinds of proof systems.

FRI based on the BabyBear field. This is the type of proof system that RISC Zero (our portfolio company) is using. It uses a 31-bit integer, 15 * 2^27 + 1, as the modulus, which permits enough native FFT space necessary for the FRI protocol to work.

FRI based on the M31 field. This is the type of proof system that StarkWare and Polygon are heading to (in their corresponding libraries, stwo and plonky3). It uses a Mersenne prime 2^31 - 1. This prime does not have a native FFT space, but one can use the circle curve x^2 + y^2 = 1 and use points on the curve to form the FFT space necessary for the FRI protocol to function. Working with M31 has the benefit that the modulus 2^31 - 1 has a nice structure that allows one to use efficient vectorized instructions on CPU. The research paper of Circle STARK shows that this nice structure can lead to a speed up of like 40%.

We had a good conversation with Francis Corvino from StarkWare, and later old friends Louis Guthmann, Victor Kolobov, and Abdel Bakhta, as well as Eli Ben-Sasson and Avihu Levy. At the time, StarkWare already had the token listed, and they have been actively looking to expand their L2 to also work on Bitcoin.

An initiative, called Bitcoin Wildlife Sanctuary, was created, aiming for non-profit, public-good projects that accelerate the development and technology adoption in the Bitcoin ecosystem. There are three ongoing projects:

Bitcoin STARK verifier, with code contribution mainly from L2 Iterative
Raito and Shinigami, two projects that aim to use Cairo to verify Bitcoin mainnet, thereby enabling trustless light client, bridge, and co-processing
OP_CAT Bitcoin Bridge, by sCrypt, using their domain-specific language and covenant framework

We will focus the rest of this article on the Bitcoin STARK verifier. Earlier this year, we had already achieved some progress and you might have already heard about them from the media.

These articles were from mid-July when we released the first STARK verification on Bitcoin Signet. This verifier verifies a simple Circle STARK proof on a squared Fibonacci sequence, and it takes about 790k vBytes to be executed on the Bitcoin Signet. If we assume that the Bitcoin mainnet also has OP_CAT and the fee rate is 2 sat/vByte, verifying this proof would cost USD ~$950. For comparison, the current Starknet, as a ZK Rollup on Ethereum, spent about $300 to $500 to verify a proof on Ethereum mainnet every time. This is, however, already an exciting note, as it shows the potential of the STARK verification.

Starting from August, we have been focusing on a few things.

Avihu Levy from StarkWare, based on some prior discussion on the lookup table based method (with Liam Eagen and a few people), designed a new algorithm to do M31 multiplication. This significantly cuts down the cost. L2 Iterative implemented this algorithm and has integrated with the STARK verifier. The new STARK verifier has already been tested on Bitcoin Signet and Fractal Mainnet (discussed later). This is likely going to reduce the per-proof verification cost to be below $600.

Many teams have been building ZK circuits from Circom and R1CS toolchains. We want to build a STARK verifier that can accept these R1CS circuits as well as Plonk circuits. This is based on Shahar Papini’s work on the simple Plonk implementation in Stwo. We are currently finishing the Bitcoin verifier for Plonk, and when it is done, users can transpile existing Circom and R1CS circuits into Bitcoin.

Reusing Bitcoin consensus for security in FRI (formally, grinding) has been an important topic of study (this is related to merged mining, but it doesn’t require mining pools to collaborate). It has the potential of lowering the cost of proof verification on Bitcoin while achieving the same level of security, likely from the $600 above to somewhere between $300. We already have an implementation of the Simple Payment Verification (SPV) protocol necessary for this technique of Bitcoin in the Bitcoin script, and it is a matter of integration to have it with the Plonk verifier.

And now we want to share with you a demonstration of the new verifier implementation with Avihu Levy’s design on Bitcoin Signet and Fractal Mainnet. For the several topics above, we will elaborate on more detail, likely in a more technical favor, in subsequent articles.

Testing the STARK verifier on Bitcoin Signet and Fractal Mainnet

One can find the transactions used in the demos from the Bitcoin Wildlife Sanctuary repositories.

On Bitcoin Signet:

https://github.com/Bitcoin-Wildlife-Sanctuary/rust-bitcoin-m31-acc/tree/master/demo

On Fractal Mainnet:

https://github.com/Bitcoin-Wildlife-Sanctuary/rust-bitcoin-m31-acc/tree/master/demo-fractal

We want to thank the Signet maintainer (we don’t know who this person is for sure) who sent us 2 Signet BTC that enables us to do these testing, and we also want to thank Fractal to giving us about ~USD $700 worth of Fractal BTC for testing this on Fractal.

One can find those Signet transactions from the mempool explorer through this address:

https://mempool.space/signet/address/tb1pnpxhs2syr62zkxgry0xv44zn84jg9dwg8jhp4gjefv9gh3ysmmssjxlyqy

The address is the STARK verifier. The entire verifier is split into 74 transactions, where each of them is small enough and many transactions are likely going to be accepted in the same block. (Theoretically, it is possible for all these 74 transactions to appear in the same block). One can also easily catch our blocks from the explorer, as shown in the following screenshot, on block 212869.

The ten blocks that are not present on the left but present on the right, and of the blue color, are our blocks. The mempool explorer doesn’t expect these blocks mainly because it has not been upgraded into a version that accepts OP_CAT, but the Signet operator will include them in the actual block. There is indeed still plenty of space in this block to host the rest of the verifier.

We spend about 0.0055 Signet BTC to complete this test, at the standard Signet fee rate of 1 sat per vByte.

We then went ahead to test the same verifier on Fractal Mainnet. When we were doing the test on Fractal Mainnet, it was also the time when they had a lot of community members mining the CAT-20 NFTs, and as a result, we ended up sending transactions at a rate of 3000 sat per vByte to get enough priority over all the CAT-20 minting transactions. The fee has since cooled down to 350-450 sat per vByte (over the Fractal BTC token, not BTC).

One can follow the following address to see how the transactions are completed on Fractal Mainnet (note: it takes time and might sometimes fail to load).

https://mempool.fractalbitcoin.io/address/bc1pnpxhs2syr62zkxgry0xv44zn84jg9dwg8jhp4gjefv9gh3ysmmss9wft6t

A benefit of Fractal is that since it has a much shorter block time, and the major miners are professional mining pools of Bitcoin, transactions that pay the market rate fee are likely going to be accepted within the next minute. We feel that Fractal can be a good “beta” for Bitcoin mainnet as it involves some market-trading tokens (unlike the signet who is designed to prevent the creation of tokens with real-world values) and also has the support of OP_CAT for people to test the new covenants and new generations of applications.

We may, in subsequent articles, present more detail about how these transactions look like, such as their structure, but keep in mind that we are actively making new developments (as we briefly mentioned above) and many technical details are changing very quickly.

Applications and use cases

Why do we think the Bitcoin STARK verifier is going to be really useful rather than just being a new narrative? It has to do with:

Whether the current Bitcoin infrastructure has limitations that prevent certain applications and use cases to appear
Whether the new infrastructure can unlock applications and use cases that could not be easily deployed before

A few criteria are useful when we are thinking about this issue.

If a new infrastructure is meaningfully different and better than without it, we would have the “aha” moment in which we do not want to come back to the old days without it. Think electricity. Think airplanes. Think roller coasters. And in the Bitcoin ecosystem, Lightning Network is such a new infrastructure that, even with all the limitations, is something that makes Bitcoin better, and it does unlock cheaper payments with fast settlements. Fractal Mainnet also has its unique position because Bitcoin Mainnet doesn’t have OP_CAT and although Signet has OP_CAT, it doesn’t have a token that carries real-world values and cannot be used for DeFi, and Fractal Bitcoin, despite not using the BTC tokens for the native gas, does enable many applications and use cases to test itself on Fractal before Bitcoin mainnet has OP_CAT. The SegWit and Taproot upgrades of Bitcoin also are things that we enjoy today.

This is similar to Ethereum having data blobs (proto-danksharding), account abstraction, and intents—and in the near future—pre-confirmations. We have invested into a few companies working on these modules, one reason of which is that they do create something useful for Ethereum.

It is important to think about alternatives, especially, whether there exist solutions that sort of already solve the problem in a way meaningful or indistinguishable enough for the majority of the users. For example, Rollup on Ethereum is a mostly solved problem after Arbitrum came into being and established connections with many crypto exchanges, and for most users, it suffices for them to just simply use Arbitrum and CEXs (and this is why Arbitrum has a significant portion of Uniswap market cap). One can also see that data blobs serve as alternatives to data availability layers like Celestia, Avail, and Zero Gravity. Lastly, CEXs pose competition to DeFi for major tokens, though leave the space for some meme coins. The existence of alternatives effectively limits the comparative utility, as with it or without it no longer makes a significant difference for users.

There are a few solid applications and use cases on Bitcoin that we would want to see.

Privacy payments. Bitcoin provides pseudonymity but not anonymity. And it has been well studied nowadays that from the transaction graph, it is possible to link many Bitcoin addresses together. There have been many attempts to build privacy payment solutions with some of them being fairly successful, some of them not so. But among these privacy payment projects, a recurring issue is that if the base token itself does not have a stable value (or a positive forecast that it would grow in value), people are less likely to keep a lot of those tokens, and this would make privacy payments much less powerful if people are only using them for transient payments. A Bitcoin-native privacy payment solution would be a nice addition and fulfill the needs of a lot of Bitcoin users. How to walk a careful line with the regulators, however, would be a separate discussion.

More advanced miner compensation distribution. A large amount of mining reward is still being distributed over the Bitcoin mainnet, but this year, there have been a few mining pools (#1, #2) supporting miners to receive the reward from the lightning network, as it does noticeably reduce the cost. Francis Corvino from Starkware has been discussing with me on whether a scaling solution can make it simpler for mining pools to distribute the reward in the cheapest and automated way possible. This may save the block space used by miner compensation distribution on the mainnet (which is sometimes significant) and encourage miners to move their treasury management into an off-chain system while retaining the security.

Order books and AMMs. A scaling solution is going to enable stateful and programmable transactions that may lead to the rise of order books and AMMs, and it can enhance the user experience when trading BRC-20 and NFTs on Bitcoin. This no longer allows BRC-20 and NFT exchange and trading to be based on Bitcoin itself, but it may also remove the blockers that prevent mainstream adoption of BRC-20 and NFT—a simple question that we can ask is that, since BRC-20 and NFT only requires very simple functionality from the blockchain, why would a token or an NFT have to be on Ethereum? They, including new projects’ coins, can be launched on Bitcoin as a token that is natively minted on Bitcoin mainnet and then be bridged to their corresponding network or other chains (such as Ethereum), and given the total market cap of Bitcoin and the unique position of Bitcoin in comparison to Ethereum, this seems to be the correct way to do things to launch altcoins natively on Bitcoin first.

We are closely working with a few companies in this space to move Bitcoin forward into being the home of many Web3 applications and use cases. Stay tuned for more articles about Bitcoin STARK verifier, covenants, and smart contracts.

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Weikeng Chen, Research Partner, L2IV

Disclaimer: 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 advisors 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.

L2IV Research

Discussion about this post