Solana Will Beat TradFi

"We're not fighting Ethereum. We're not fighting Aptos or Sui. We're fighting Nasdaq." 

-Max Resnik

When Solana launched, the vision wasn't to build yet another blockchain competing for DeFi TVL or trying to be an "Ethereum killer." The ambition was to create a blockchain capable of hosting a functioning central limit order book.

In other words, go head-to-head with the New York Stock Exchange, Nasdaq, and CME, the massive centralized trading venues that handle billions in daily volume. Solana has made significant progress on the technical fundamentals required for this mission:

Bandwidth Improvements:

• Block capacity expanded 25% this year, with plans for another 66% increase by year-end (targeting 100M compute units)
• Firedancer demonstrated 1M+ TPS in testing, 100K TPS on mainnet (Nasdaq does ~70K TPS)

Latency Improvements:

• Alpenglow will reduce finality from 12.8 seconds to under 150ms 
• Research exploring 20ms block times through pipelining consensus

The vision is yet to be fully realized. Building a decentralized Nasdaq requires pulling real volume away from centralized competitors. And professional traders don't choose platforms based on philosophical commitments to decentralization. 

Traders Choose Exchanges Based on Price

Traders don't choose venues based on decentralization philosophy or TPS benchmarks. They choose based on one thing: where do I get the best price?

Best price = tightest spreads.

The spread is the difference between the highest price somebody is willing to buy the asset for and the lowest price somebody is willing to sell the asset for. Think of it like a currency exchange:

• Good exchange: Buy USD at €0.93, sell at €0.92. Spread: €0.01
• Bad exchange: Buy USD at €1.00, sell at €0.85. Spread: €0.15

Same transaction. One costs you 15x more.

For a $10,000 trade, that's the difference between losing $100 and losing $1,500.

Current state of spreads:

• Nasdaq: Tightest
• Solana DEXs: Significantly wider

Why are Solana's spreads so wide?

Market makers provide liquidity. They're always ready to buy or sell, quoting prices like:

• "I'll buy SOL at $100.00"
• "I'll sell SOL at $100.20"

Their spread ($0.20) is their profit margin. Throughout the day, they make a little bit on each regular trade — "picking up pennies."

But prices don't stay still. News breaks. Whales move. The "fair" price of SOL jumps from $100 to $105 in an instant. The market maker's quote is still out there: "Selling at $100.20."

A race begins:

• Market maker tries to cancel their stale quote before someone exploits it
• Arbitrageurs try to snipe the stale quote before it disappears

If the arb wins, they buy at $100.20 and immediately resell at $105. They make $4.80. The market maker loses $4.80. If the market maker wins and cancels in time, nobody gets hurt.

How Centralized Exchanges Handle this

On Nasdaq:

• Sub-millisecond execution: Orders process in microseconds
• Colocation: Traders pay to place servers inside the exchange datacenter, cancels travel meters, not across the internet
• First-come-first-serve: Pure speed wins, no batching

The result? Market makers win only 13% of the time. Even with all this speed, arbitrageurs still snipe them 87% of the time (data from research on the FTSE 100).

Why Solana is even worse

On Solana, market makers win even less frequently. The problem: batching and auctions. Transactions get grouped together and sorted by priority fee, whoever pays the most wins.

Back to our example when price jumps to $105:

• Market maker sends cancel for $100.20 order
• Arbitrageur sends buy order to snipe at $100.20

Both land in the same batch. Who wins? Not who was fastest. Who paid the highest fee. Even if the market maker was actually faster, they only win if they outbid all the arbitrageurs.

The impossible choice:

Option 1: Pay huge fees ($2-3) to win the auction and cancel
Option 2: Get sniped, lose $4.80 per token

Either way, they lose money.

What is Jito? Solana's block auction system where validators batch transactions and sort by priority fee, creating a pay-to-win dynamic.

The Jito auction makes it nearly impossible for market makers to win the cancellation race fairly, because action is basically a symptom of having a single proposer controlling access to state for extended periods. The game has always been about who pays the highest bid, it wasn’t about the speed.

The Result: Market Makers Widen Spreads

Because market makers lose the cancel race constantly on Solana, they have no choice but to widen spreads to compensate:

• If they won cancel races fairly (hypothetical), their spread would be $0.20
• In current reality on Solana (constantly losing), their spread is $0.60

That extra $0.40 is market makers pricing in "I'm going to get sniped and lose money constantly, so I need to charge more on every regular trade to make up for it."

Who pays? Every trader on Solana. You're getting worse execution on every trade because market makers must protect themselves from this structural disadvantage.

Until this architectural problem is fixed, spreads will remain wider than centralized venues, and professional traders will keep choosing Binance over on-chain alternatives.

Why can't we cancel orders first?

Can't we just process cancels before takes? Change the transaction ordering. Every block, execute all cancel orders first, then execute take orders. Market makers get a head start. Problem’s solved.

It doesn't work on a decentralized blockchain like Solana. Anyone can run a validator. You can't enforce what software they run or what rules they follow.

Imagine you're a profit-motivated validator. Your slot comes up. You see incoming transactions:

1. Market maker's cancel at $100.20
2. Arbitrageur's snipe at $100.20 (worth $4.80 profit)

What do you do? 

1. You ignore the cancellation. You include the snipe. You take a cut of the $4.80.
2. The cancellation shows up in the next block, too late. The market maker got wrecked. You made money.
3. This is the core problem: Single-leader architecture gives one person monopoly control over what gets included in each block.
4. That person can censor any transaction they don't like. Specifically, cancels that would prevent them from profiting.
5. We could institute "cancels before takes" ordering on Solana today. Just change how the protocol replays transactions. But if we still have one leader controlling inclusion, that leader can choose to ignore cancels entirely.

Why traditional finance can't fix this either

Centralized exchanges face the same problem. In 2019, the Chicago Board Options Exchange (CBOE, one of the four largest exchanges globally) asked the SEC for permission to give market makers a slight timing advantage in the cancel race.

The proposal would have tightened spreads and improved prices for traders. The SEC rejected it.

The reason: high-frequency trading firms lobbied against it, arguing it was "unfair" because it would reduce their ability to snipe market makers for profit. The regulators sided with the incumbents. Innovation stopped.

Traditional finance can't solve this structural problem. The SEC blocks improvements that threaten existing players. Market makers keep losing the cancel race. Spreads stay wider than necessary. Traders pay the cost.

This is the world Solana is trying to disrupt.

The Solution: Multiple Concurrent Leaders

The fix: introduce multiple leaders per slot. If one leader censors or cancels, users can submit to a different leader.

• Currently on Solana, every 400ms one validator has monopoly control. They decide what gets in, what doesn't, and in what order.
• With Multiple Concurrent Leaders (MCL): That 400ms slot now has multiple leaders operating simultaneously. Each builds their own block independently. Then those blocks get merged.

Why does this solve the cancellation race?

If one leader refuses to include a cancellation (more profitable to let the snipe happen), market makers send it to the other leader. This becomes a repeated game. Leaders who consistently censor lose transaction flow. Leaders who provide good service get more business.
The monopoly breaks. Competition emerges.

Implementation: How it actually works

To start with, let’s consider 2 leaders for a single slot.

Step 1: Finding Your Lane
When someone sends a transaction, their wallet address automatically assigns them to one of two leaders, Leader A or Leader B.

How it works:

• The system looks at specific bits (N bits) in the fee payer address
• In a 2-leader system, one bit determines the lane
• If that bit = 0 → routes to Leader A
• If that bit = 1 → routes to Leader B

This is automatic and consistent. The same wallet always routes to the same leader. The fee payer must be assigned to an exclusive lane so the leader can verify the account is valid and hasn't already spent funds at another leader.

Want to send to both leaders? You need two different wallet addresses, meaning you pay twice. This prevents spam.

What market makers can do: Generate multiple wallet addresses. Wallet 1 routes to Leader A, Wallet 2 routes to Leader B. If Leader A censors a cancel, immediately send through Wallet 2 to Leader B.

Step 2: Building Blocks

Both leaders work simultaneously and independently. Each collects transactions assigned to their lane, sorts by priority fee, and packs them into a block.

Capacity split:

• Each leader gets 50% of total network capacity
• Leader A can use up to 50%
• Leader B can use up to 50%
• When blocks merge: maximum 100% total

If both leaders max out at 50%, the merged block is exactly 100%, then the network can handle it without falling behind.

Step 3: Spreading Blocks (Turbine)

Solana uses Turbine to spread blocks efficiently. Instead of sending entire blocks to every validator, each block gets chopped into pieces.

How Turbine works:

• Each block splits into 64 pieces using erasure coding (like how a scratched CD can still play, you don't need every bit of data)
• Any 32 of those 64 pieces can reconstruct the full block
• Block A sends its 64 pieces to 64 different validators
• Block B sends its 64 pieces to the same validators simultaneously
• Each validator receives one piece from Block A and one from Block B

Confirmation process:

Each validator collects pieces from other validators. Once they have 32 pieces from Block A and 32 from Block B, they reconstruct both full blocks and vote: "Both valid."

Those 32 pieces came from 32 randomly-selected, stake-weighted validators distributed across the network. If 32 random validators confirm they got data from both leaders, everyone probably did. The network achieves consensus.

The efficiency: Instead of sending complete blocks to 1,000+ validators (massive bandwidth), 64 pieces spread organically. MCL just handles two blocks instead of one with minimal overhead.

Step 4: Preventing Cheating (Binding & Blinding)

Leader A could peek at Leader B's block and front-run valuable transactions or cancel their own block based on what they see in the other block.

The solution: Leaders must commit to their blocks before seeing what's in other blocks.

How it works:

• Both leaders build their blocks
• They immediately start sending pieces across the network
• Validators receive pieces and send back signed confirmations ("I received piece A1 and B1")
• A consensus leader collects these confirmations and broadcasts them
• Only after confirmations are public can anyone reconstruct the full blocks

By the time Leader A knows what's in Block B, it's too late. Block A's pieces are already spreading across thousands of validators. Can't be recalled.

Binding and blinding:

• Binding: You're locked into your block once pieces start transmitting
• Blinding: You can't see other blocks until you're locked in

Result: No front-running, no manipulation based on other blocks' contents.

Step 5: Merging Blocks

Validators now have both blocks reconstructed. Time to merge them into one execution order. The merge process looks like this:

• Combine all transactions from both blocks
• Remove any duplicates (rare but possible)
• Sort by ordering fee (a new fee type paid to protocol and burned)
• Highest ordering fee executes first

Two types of fees exist now:

• Inclusion fee: Paid to the validator who includes your transaction in their block
• Ordering fee: Paid to the protocol (burned) to determine execution order after blocks merge

This separates "getting included in a block" from "executing first in the merged result."

Step 6: Protecting Market Makers

Solana adds a new tool: get_transaction_metadata. This lets smart contracts read the ordering fee of incoming transactions.

How a DEX uses this:

The DEX implements a rule: "Take orders with ordering fees above 100 micro-SOL get rejected. Only cancels can pay high ordering fees."

Imagine the scenario where the price jumps to $105. Market maker sends cancel with 500 micro-SOL ordering fee. Arbitrageur tries to snipe with 1,000 micro-SOL ordering fee (trying to execute first).

What happens:

• Global merge sorts by fee: Arb's transaction should execute first (higher fee)
• When arb's transaction hits the DEX contract, contract checks: "This is a take order with 1,000 micro-SOL fee"
• DEX rejects it: "Take orders cannot pay high ordering fees"
• Cancel executes instead
• Market maker wins

The arb's dilemma:

• Pay high ordering fee → Get rejected by the app
• Pay low ordering fee → Execute after cancel (too late, quote is gone)

Market makers get structural protection. And leaders can't censor cancels because market makers can route to a different leader through a different wallet.

Step 7: Handling Capacity Efficiently

Each leader gets 50% capacity, but usage is rarely perfectly balanced.

The problem:

• Leader A fills to 90% of their 50% → uses 45% of total capacity
• Leader B fills to 40% of their 50% → uses 20% of total capacity
• Total utilization: only 65%
• Wasting 35% of network capacity while Leader A's lane has high fees

The solution: capacity rollover.

If the merged block uses only 65% of capacity, take a portion of that unused 35% and add it to the next block's capacity limit. The next block can now use 117.5% of base capacity.

Why this works:

Solana uses asynchronous execution, validators vote on new blocks before finishing execution of old blocks. Execution happens in the background while consensus moves forward.

As long as average execution load is manageable, temporary spikes above 100% are fine. The system smooths out over time. Validators can accept new blocks while still processing previous ones. The system stays fluid.

Geographic Decentralization

Beyond solving the cancel race, MCL unlocks something centralized exchanges can never solve: the physics problem.

When the Bank of Japan makes an announcement in Tokyo, that information travels at the speed of light through fiber optic cables, 200 milliseconds to reach New York. Tokyo traders get news instantly. New York traders are 200ms behind, reacting to stale information.

Centralized exchanges like Nasdaq are stuck in one location. They can't escape this.

How MCL changes this: A leader in Tokyo receives the Bank of Japan news instantly and puts a transaction on-chain immediately. By the time that news physically reaches New York (200ms later), it's already on Solana's blockchain, processed by the Tokyo leader and merged into a global state.

No arbitrage opportunity exists between Solana and centralized exchanges because Solana ingested the information first at the source.

Market forces drive geographic distribution: If all validators cluster in AWS data centers, whoever sets up a leader in Tokyo captures all Tokyo-specific arbitrage opportunities. That's profitable, so someone does it. If everyone moves to Tokyo, whoever sets up in Frankfurt captures all European arbitrage. Natural geographic distribution emerges based on the economic importance of each region.

The competitive advantage: Centralized exchanges are limited by the speed of light to one physical location. Solana with multiple concurrent leaders can ingest market-moving information faster than any centralized venue because it captures information at the source, wherever that source may be.

‍