I’ve been working on consumer products for about a decade, having contributed to teams that have built and scaled apps to hundreds of millions of users. For the last six years I’ve been 100% focused on crypto. A large part of that has been working on scaling solutions for large-scale, consumer-crypto products.

I’ve been part of teams that have built and launched products on Ethereum, Stellar and Solana, and have evaluated most of the other major blockchains and layer 2 scaling options, which has included spinning up basic proof-of-concepts. In particular, I’ve looked deeply at the benefits and tradeoffs of Polygon – the dominant scaling option for Ethereum today.

Web2 developers planning to jump into Web3 often wonder which blockchain they should start with. Most of these discussions end up focusing on Solana and Polygon. It’s a debate that’s only grown more heated in the weeks since Sam Bankman-Fried’s crypto trading empire collapsed, given he was one of Solana’s most prominent supporters.

Although many see the downfall of FTX as a potential death knell to Solana, the network remains a promising technological solution to blockchain’s scaling issues. Even Ethereum co-creater Vitalik Buterin has noted the strength and gumption of developers building on Solana. And, developer activity is one of the best leading indicators of value creation over time.

Given this I thought it would be helpful to share my perspective as someone experienced in different crypto networks on the pros and cons of Solana and Polygon. Note: This article primarily focuses on Polygon POS (proof-of-stake), the dominant product within the Polygon product suite, with which I have direct experience. This article also contemplates other Polygon products currently in development, based on the information I’m able to gather publicly, which will be noted when referenced.

There’s three criteria I think are both critically important and materially different between the two chains: performance, approach to scaling and security.

1. Performance

It might be an unpopular opinion to say that transactions-per-second (TPS) is a bad metric. What really matters is seconds-per-transaction (SPT). These are not the same; let me explain.

Transactions-per-second is calculated by taking the number of transactions in a block and dividing that by the time it takes for validators or miners to produce a block, a.k.a. block time. This method misses an important nuance in how block time feels for crypto users.

Let’s say a blockchain produces a block once every hour, but that block contains a billion transactions. This blockchain would technically boast 277,000 TPS, but anyone using it wouldn’t think so. The median seconds-per-transaction (assuming normal distribution of transaction submission across the hour) would be 30 minutes. This is why block time matters.

On Solana, the block time (referred to as “slot time”) is ~0.4 seconds. On Polygon the block time is ~2 seconds. This might seem like splitting hairs but the difference between 2 seconds and a half second is a big deal. When a user experiences more than a second of latency in an app (the brain processes information it sees at <0.15 seconds), it can feel like an eternity. I’ve seen this phenomenon first hand while working on consumer apps. Moreover, every millisecond counts when price discovery and execution are so tied for financial applications.

Another technical consideration when comparing block times is that Polygon (like other EVM chains) uses a mempool where transactions are indexed before being added to a block. Solana takes a different route, where transactions are submitted directly to the leader in the validator set. So while block time on Polygon is ~2 seconds, there is no guarantee a transaction will make it into the next block since it could get stuck in the mempool – especially in times of high volatility.

This phenomenon of getting “stuck” or “delayed” is a result of the block size. Imagine Venmo ran an app on-chain and needed to fill dozens of orders per second, if it chose a blockchain with 0.01-second block times that could only fit one transaction in a block, the observed SPT would be sluggish.

On Solana, blocks can theoretically reach a maximum size of 128MB. The Solana Turbine protocol breaks a block into 1280 byte packets called shreds. Through Solana’s Tower BFT protocol, these can be verified concurrently by separate validators, enabling parallelized computation.

On Polygon, the block size for the POS chain is currently between 50-120KB. There is a product in development called Polygon Avail that should increase this capacity. Avail is a data availability protocol that sits on top of the Polygon POS chain to increase storage. It is currently spec’d at 2MB per block with a 20 second block time though may scale to 128MB (with a theoretical minimum block time for a block that size of 5 seconds).

Block capacity manifests in fee markets, which we can see today. The average transaction fee on Polygon is ~$0.02 whereas Solana is ~$0.0002. According to 0x, when block utilization approaches 80%, the fee markets start increasing substantially, and as block utilization approaches 95%, it starts increasing exponentially.

Polygon is designed to scale through parallelized sidechains, which opens up the option to increase total block capacity through more chains, so that could bring the fee markets down. Although, this approach to scaling carries bigger systemic risks that, depending on what you’re building, may make building on Polygon challenging.

This is where I believe the biggest divergence in the two chains is, and is the subject of the next section.

2. Approach to scaling

A one sentence summary of how Solana and Polygon differ on their approach to scaling would be: Solana is built to keep everything on a single chain and Polygon is built to add more concurrent chains that merge state periodically.

To expand on this, a Solana cluster (set of validators contributing to consensus) has a leader schedule. This leader schedule enumerates which validator will be verifying each block (a.k.a. a slot on Solana). With a predefined leader schedule, transactions are forwarded to the scheduled leader, cutting down on unnecessary coordination.

In the near future, Solana should also see multiple block leaders which will improve performance and mitigate downtime. All of this is uniquely enabled by Solana’s proof-of-history consensus protocol that aligns the network around a shared clock. Without a shared time-keeper, the network has to be reactive to emergent leaders in the validation schedule.

Proof-of-history combined with the Turbine protocol enables fast streaming of large amounts of data that all lives on one chain.

Polygon has a similar system of defining a block leader through its Bor protocol, but the approach to scaling is different. Polygon is set up to scale by adding more sidechains running in parallel and merging state periodically through a commitment to Ethereum. That’s why you may see Polygon POS and Plasma referred to as a “commit chain.” Multiple, parallel sidechains may mean it’s possible for two users to be on separate sidechains using the same app, which would mean users are beholden to the latency of the state merge between chains and developers have to build for complexity.

This way Polygon scales may also introduce the risk a blockchain could see a “re-org” (where transactions are rolled back) since a user cannot reliably consider their transaction “final” until block height reaches a certain threshold. There’s no magic number for this, but as an example, stablecoin issuer Circle waits for 372 blocks to pass on Polygon (~20 minutes) before they consider a transaction “final” and 1 block (~0.4 seconds) on Solana.

Polygon’s variant  finality is a substantial drawback, and may impact what type of apps could be built on it. For instance, crypto apps might put a user’s funds on hold until a transaction is considered final or allow users to transact immediately and accept the risk of a double spend exploit (like accepting credit card chargeback risk). This is a step backwards from crypto’s supposed elimination of financial counterparty risks.

A single chain will always be better than a collection of sidechains, assuming the single chain can scale. A single chain has less coordination complexity, less aggregation latency and less surface area for attack.

The question is, can Solana support the same scale that Polygon claims to? Based on a recent demo from Kevin Bowers at Jump Crypto, it seems it can. The team at Jump Crypto has built a new validator client for Solana called Firedancer that demonstrated 1.2 million transactions per second, while maintaining the sub-second slot time. To put that into perspective, if you counted every Twitter, WhatsApp and Instagram interaction as a transaction, they could all run concurrently on Solana without any performance degradation.

Polygon also has a substantial set of technical improvements in development. Specifically, the investment in zero-knowledge (zk) rollups should result in substantial performance improvements. However, zk rollups must settle on the layer 1 (currently Ethereum) to be considered valid – meaning while they open up capacity they also add latency.

3. Security

It’s one thing to be high performing and scalable, but we also need confidence in the network. Both Solana and Polygon have had significant soak time, so the chance of a critical bug lying in plain sight is diminishing (although not impossible).

Given this, potential blockchain developers should focus on a network’s resiliency to bad actors trying to influence state. This is most objectively measured by the Nakamoto Coefficient (NC), a metric that quantifies the number of validators that would need to collude to corrupt a network.

At the time of this writing the Solana NC is 32 and Polygon is 4. Both are proof-of-stake networks so distribution of stake matters. Solana has approximately 1,900 validators and Polygon has roughly 100. What the Nakamoto Coefficient says here is that the top 32 validators on Solana and the top four validators on Polygon could take down the network.

Both networks would do well to increase security on this vector, and I think they both will, and both Polygon and Solana have seen an increase in their NC over the last year. As more validators come online, Polygon’s NC will grow, and other technical improvements in development like zk rollups will improve security.

It’s argued that Polygon has higher security because it commits state periodically to Ethereum. This is a bit misguided though because the Polygon network is the one updating state to Ethereum, so if four validators colluded to corrupt the ledger, in theory a commitment could be made to Ethereum with the corrupted ledger. This is a solvable problem the Polygon team and broader ecosystem are working on.

While I do think there is a divergence in security today, I think both blockchains will see big improvements here over time and we may see some convergence coming from a mix of technical and social advancements. This is probably the hardest one to project.

4. Bonus: community

While not a technical criteria, community is nonetheless an important variable in the success of a network. Polygon has an advantage in being connected to Ethereum where there is an objectively larger developer and consumer community than Solana. Further, the Polygon Foundation has done a good job cultivating brands and developers to build on its network – I would expect this to continue.

And given Polygon plans to bridge to multiple blockchains, they’ll be able to leverage existing communities bringing even more developers and consumers into the fold.

This isn’t a moat, however. It’s early in crypto with most of the world still on the sidelines, I think performant applications will bring them in, and the developer, creator and consumer communities will congregate where the best apps and the most users are. That’s why I think the technical criteria above are a leading indicator of future community development.

While Solana had to overcome a cold-start problem, in less than three years it has grown to one of the most active developer, creator and consumer communities. There is a diverse set of developers making the core more performant and robust, while others are adding services and tooling to make the developer experience better.

That foundation has enabled talented teams to build strong consumer experiences across the major categories in crypto. I would expect this cycle to continue, bringing more talented people into the ecosystem as the talent density compounds.

I do think both Polygon and Solana serve important needs in the broader crypto ecosystem, but I do think it is important for developers to understand the pros and cons. I hope this helps.