245 posts tagged with "Infrastructure"

When the SEC quietly dismissed its case against Consensys in February 2025 — no fines, no conditions, no admission of wrongdoing — it did more than end a lawsuit. It handed Joseph Lubin's 11-year-old studio a permission slip to do what no pure-play Web3 infrastructure company has ever done: walk into the New York Stock Exchange and ask public markets to price the picks-and-shovels of the Ethereum economy.

Now, with JPMorgan and Goldman Sachs running the book and secondary markets already trading Consensys shares at an implied valuation above $10 billion, the mid-2026 IPO has become the single most-watched event on the crypto capital markets calendar. But here's the uncomfortable question that Wall Street has to answer in the next 90 days: is Consensys actually the "AWS of Ethereum" its bankers are pitching — or is it three good businesses glued together, each facing credible challengers, without a single dominant moat to justify a growth multiple?

In the same three weeks that Bittensor co-founder Const proposed rewriting the network's voting rights and Covenant AI walked away from its three flagship subnets, a quieter event reshaped the protocol's future even more profoundly: on April 2, 2026, the Opentensor Foundation transferred ownership of nine core GitHub repositories — including the Bittensor Python SDK and the btcli command-line tool — to a new entity called Latent 11.

The handoff was framed as decentralization. In practice, it concentrates control of Bittensor's only client implementation in a single new organization, at the exact moment the network's governance is unraveling. It is the rare crypto story where every plausible reading — bullish, bearish, and existential — depends on what happens in the next six months.

In December 2025, after roughly 1,200 days of development and a reported nine-figure investment from Jump Crypto, the full Firedancer validator client finally went live on Solana mainnet. Four months later, the verdict is in: it works, it ships block production at speeds nothing else on the network can match, and it has already attracted more than 20% of network stake. The harder question — the one Solana's institutional credibility now hinges on — is whether the network can reach the kind of client diversity that Ethereum spent a decade building, before its first catastrophic Agave bug forces the issue.

This is the story of the largest single-client engineering effort in blockchain history, why it matters more for resilience than for raw throughput, and what the remaining concentration risk means for builders deciding where to deploy in 2026.

A Three-Year Rewrite, Built From the Network Card Up​

Jump Crypto began Firedancer in 2022 with a thesis that sounded almost reckless at the time: rewrite the entire Solana validator from scratch, in C, with a tile-based architecture borrowed from high-frequency trading systems. The team had originally targeted Q2 2024 for mainnet. They missed by roughly eighteen months.

The slip is itself instructive. Firedancer is not a fork of Anza's Agave (the Rust-based reference client) or of Jito-Solana (Agave's MEV-optimized fork). It is an independent C/C++ implementation that shares no execution code with the rest of the network, which means every consensus rule, transaction-processing path, and gossip protocol had to be re-implemented and battle-tested against live mainnet behavior before a single dollar of stake could safely run it.

Jump's intermediate solution — Frankendancer — paired Firedancer's high-performance networking stack with Agave's runtime. That hybrid quietly gathered stake throughout 2025: 8% in June, 20.9% by October. When the full Firedancer client crossed the line in December, much of that stake migrated naturally, giving the new client a credible production beachhead from day one.

What 1 Million TPS Actually Means​

The headline number is real, but the asterisks matter. Firedancer's networking layer processed over one million transactions per second in stress testing — but those tests ran in a controlled six-node cluster spread across four continents, not on production mainnet. Real-world Solana today sustains roughly 5,000–6,000 TPS at the protocol level, with stable mainnet averages closer to 65,000 TPS during peak periods in April 2026.

The realistic mid-2026 trajectory is more modest and more useful: 10,000+ TPS in everyday production, a 2–3x improvement over today, with the headroom to absorb spikes that previously destabilized the network. That is the kind of throughput that genuinely changes what is buildable on-chain.

For context on what Firedancer actually optimizes:

• Transaction ingestion: kernel-bypass networking that reads packets directly from the NIC, eliminating syscall overhead.
• Signature verification: AVX-512 vectorized ed25519 verification that can chew through tens of thousands of signatures per second per core.
• Block production: a tile-based pipeline where each validator function runs in its own pinned process, so a slow signature checker cannot starve a block producer.
• Memory layout: cache-aware data structures that match modern server CPU topology rather than assuming a generic runtime.

None of this is sexy — it is exactly the kind of work that makes a database or a market-data feed go fast. Applied to a blockchain validator, it removes the bottlenecks that have repeatedly forced Solana into degraded states under load.

The Real Story: Killing the Single-Client Failure Mode​

Throughput gets the press releases, but the more important contribution of Firedancer is structural. For the first time in its history, Solana has a validator client that shares no execution code lineage with Agave.

Consider the alternative. Jito-Solana — the dominant client by stake — is itself an Agave fork. Vanilla Agave runs on most of the rest. As of early 2026, the rough split is approximately:

• Jito-Solana: 72% of staked SOL
• Frankendancer / Firedancer: 21%
• Vanilla Agave: 7%

Eighty percent of the network shares a common code ancestor. A single critical bug in Agave's runtime — the kind that has hit Ethereum execution clients twice in the past two years — would not be a degraded-performance event. It would be a network halt.

Ethereum learned this lesson the expensive way. The Reth bug in September 2025 stalled validators on versions 1.6.0 and 1.4.8 at block 2,327,426. That was an inconvenient incident that affected 5.4% of execution layer clients. Because the other 94.6% was distributed across Geth, Nethermind, Besu, and Erigon, the network kept producing blocks. The ecosystem treats 33% as the maximum any single client should ever hold, and even Geth's 48–62% share is considered an unresolved governance problem.

Solana's current 80%+ Agave-derived concentration is significantly worse than what Ethereum considers a crisis. Firedancer is the only credible exit.

What Has to Happen Next​

The math is uncomfortable but tractable. For Solana to reach genuine multi-client resilience, two things need to occur during 2026:

1. Jito users have to migrate to pure Firedancer. Jito's MEV-extraction logic is the gravitational mass holding the current concentration in place. Until that functionality is ported into a Firedancer-compatible plugin, large staking operations have a strong financial reason to stay on Agave-derived code.
2. Agave + Jito combined stake has to drop below 50%. Once Firedancer crosses 50%, Solana can survive a catastrophic Agave bug without halting. That is the resilience floor every credible institutional custodian and ETF issuer is implicitly underwriting against.

The fact that Frankendancer adoption more than doubled in four months suggests the migration is achievable, but it is not automatic. Validator economics, monitoring tooling, and operational familiarity all favor incumbency. Jump and Anza have both signaled that 2026 is the year to push hard, but neither controls the validator set directly.

Firedancer + Alpenglow: The Combined Roadmap​

Firedancer is only one half of Solana's most ambitious technical cycle since mainnet launch. The other half is Alpenglow, a complete consensus rewrite approved by 98.27% of voting SOL stake in September 2025.

Alpenglow retires Proof-of-History and TowerBFT, replacing them with two new components — Votor for fast-finality consensus and Rotor for data propagation. The headline outcome is finality dropping from roughly 12.8 seconds to 100–150 milliseconds, a 100x improvement that targets a Q3 2026 mainnet integration.

For institutional users, the combination matters more than either piece in isolation:

• Sub-second finality makes settlement competitive with centralized exchanges, opening the door to on-chain high-frequency trading and real-world asset settlement that today still routes through traditional rails.
• High throughput with multiple clients removes the "Solana goes down" objection that has historically kept enterprise treasury and tokenized-asset issuers cautious.
• Independent code paths satisfy the diligence requirements that custodians and ETF authorized participants increasingly write into their network risk models.

The $58M daily ETF inflows and $827M in tokenized real-world assets that Solana attracted in early 2026 are a leading indicator. Institutional money does not commit to single-client networks at scale.

What Builders Should Take Away​

If you are deploying on Solana in 2026, the practical implications are concrete:

• Throughput headroom is real. The 5,000-TPS production ceiling has been a consistent design constraint for high-frequency dApps. By Q4 2026, that constraint substantially loosens, which changes the cost calculus for order books, on-chain games, and agent-driven workflows that previously had to batch or compress aggressively.
• Latency assumptions need updating. If Alpenglow lands on schedule, settlement assumptions built around 12-second finality become obsolete. Designs that wait for confirmation before triggering downstream actions can collapse multiple round-trips into one.
• Client-aware infrastructure matters more, not less. As Firedancer adoption grows, RPC providers, indexers, and monitoring tools that handle client-specific quirks gracefully will become the production-grade choice. Generic "Solana RPC" stops being a meaningful differentiator.
• The concentration risk is still real. Until Jito stake migrates, a single Agave bug can still take the network down. Treasury-critical applications should design with that scenario in mind — not by avoiding Solana, but by understanding where the network sits on the resilience curve relative to Ethereum.

The Bottom Line​

Firedancer's mainnet release is the most important infrastructure milestone in Solana's history, and it is not primarily about speed. It is about whether one of the most technically ambitious blockchains can grow up into a network that institutions can underwrite. The 1 million TPS demo is what gets the headlines, but the structural achievement is that Solana now has a credible path to looking like Ethereum on resilience metrics — provided validator economics cooperate.

The next twelve months will tell us whether Jump's $100M+ bet pays out. If Firedancer crosses 50% stake by the end of 2026 and Alpenglow ships on time, Solana enters 2027 as a genuinely different network — one with the throughput of a high-performance ledger, the finality of a real-time settlement system, and the client diversity of a credible institutional rail. If it stalls at 25–30% adoption, the headline number stays a marketing asset and the underlying single-client risk persists.

For developers and infrastructure teams choosing where to build, the read is straightforward: Solana in 2026 is more capable and more resilient than Solana in 2025, the trajectory is favorable, and the work that remains is operational rather than technical. That is a much better problem to have than the one Jump set out to solve four years ago.

BlockEden.xyz operates production-grade Solana RPC infrastructure designed for the multi-client era, with built-in support for Firedancer, Agave, and Jito-derived nodes. Explore our Solana API services to build on infrastructure that tracks where the network is going, not just where it has been.

For fifteen years, every crypto exchange has been designed for a human staring at a candlestick chart. On April 22, 2026, Kraken effectively admitted that assumption is expiring. Its open-source, single-binary Rust CLI is not a convenience tool — it is an exchange rewritten for a counterparty that does not have eyes, cannot click, and burns cash every time it re-reads an API doc.

What if the same physics that gives quantum computers their power could empty Satoshi's wallet — and an estimated $440 billion of Bitcoin alongside it? In January 2026, a small New York startup called Project Eleven raised $20 million at a $120 million valuation to make sure that day never arrives without a defense ready. Backed by Castle Island Ventures, Coinbase Ventures, Variant, and Balaji Srinivasan, the round marks the first serious capital cycle into "quantum-safe crypto" — and the moment Bitcoin's quietest existential risk becomes a fundable industry.

For years, "quantum risk" lived in academic footnotes. In 2026, it moved into venture term sheets, NIST standards, and a live BIP debate. Here's why, and what's actually getting built.

The Funding Round That Made Quantum Real​

Project Eleven's Series A closed on January 14, 2026, led by Castle Island Ventures, with Coinbase Ventures, Variant, Fin Capital, Quantonation, Nebular, Formation, Lattice Fund, Satstreet Ventures, Nascent Ventures, and Balaji Srinivasan filling out the cap table. The $20 million ticket lifted Project Eleven's post-money valuation to $120 million and brought its total funding to roughly $26 million in 16 months — the company had previously raised a $6 million seed in mid-2025.

Founder Alex Pruden, a former U.S. Army Infantry and Special Operations officer, frames the company's mandate plainly: digital assets need a structured migration to quantum-resistant cryptography, and somebody has to build the picks and shovels.

What's notable isn't just the dollar amount. It's the investor mix. Castle Island and Coinbase Ventures don't write seven-figure checks on speculative thesis. Variant, Nascent, and Lattice are crypto-native funds. Quantonation is a quantum-focused investor. Together they're signaling that quantum-safe infrastructure has crossed the line from research curiosity into a budget line item — and that Bitcoin's $1.4T+ market cap is enough motivation to fund a defense before the offense exists.

Why Bitcoin's Cryptography Is Suddenly on the Clock​

Bitcoin secures roughly 19.7 million coins with elliptic-curve digital signatures over the secp256k1 curve. ECDSA is unbreakable on classical hardware, but Shor's algorithm — a 1994 quantum algorithm — can factor large integers and compute discrete logarithms in polynomial time. The instant a sufficiently large fault-tolerant quantum computer exists, every exposed Bitcoin public key becomes a private key in waiting.

The threat sat dormant for decades because the hardware looked decades away. That window collapsed in March 2026.

On March 31, Google Quantum AI published new resource estimates showing that breaking Bitcoin's secp256k1 curve requires fewer than 1,200 logical qubits and about 90 million Toffoli gates — translating to under 500,000 physical qubits on a superconducting surface-code architecture. The previous estimate was roughly 9 million physical qubits. A 20× reduction in one paper.

A Google researcher attached a probability to the milestone: at least a 10% chance that by 2032 a quantum computer could recover a secp256k1 ECDSA private key from an exposed public key. Google's own corporate guidance now urges developers to migrate by 2029.

Today's hardware is nowhere near 500,000 qubits. Google's Willow chip sits at 105 physical qubits. IBM's Condor crossed the 1,121-qubit threshold in 2023 and the company's Nighthawk reached 120 logical qubits in 2025. But the gap between "nowhere near" and "uncomfortably close" is exactly where insurance pricing lives — and Bitcoin's exposure isn't a 2035 problem if it takes a decade to migrate.

What's Actually Vulnerable — and What's Not​

Not all Bitcoin is equally exposed. The vulnerability depends on whether a coin's public key has ever been broadcast on-chain.

• Pay-to-Public-Key (P2PK) outputs from Bitcoin's earliest years — including roughly 1 million BTC mined by Satoshi — embed the raw public key directly in the script. These are permanently exposed and offer a quantum attacker a long, undefended runway.
• Reused addresses of any type expose the public key the moment the first spend transaction confirms, after which any remaining balance becomes vulnerable.
• Modern addresses (P2PKH, P2WPKH, P2TR with key-path spends) reveal only a hash until first spend. They're safe in cold storage but lose protection during a transaction broadcast — a window an adversary with quantum capability could potentially front-run.

The aggregate is striking. Estimates suggest about 6.5 to 7 million BTC sit in quantum-vulnerable UTXOs, worth roughly $440 billion at current prices. That's not a tail risk hidden in the corner of the order book. That's the fifth-largest "asset class" in crypto, owned by an attacker who hasn't shown up yet.

Three Mitigation Pathways Now Competing​

Project Eleven's $20 million isn't being deployed in isolation. It lands in the middle of a three-way debate over how Bitcoin actually transitions, and the answers are very different.

1. Migration Tooling: Project Eleven's Yellowpages​

Project Eleven's flagship product, Yellowpages, is a post-quantum cryptographic registry. Users generate a hybrid key pair using lattice-based algorithms, create a cryptographic proof linking the new quantum-safe key to their existing Bitcoin address, and timestamp that proof on a verifiable off-chain ledger. When (or if) Bitcoin adopts a post-quantum address standard, Yellowpages users have already pre-committed to the keys that can claim their coins.

Crucially, Yellowpages is the only post-quantum cryptographic solution actually deployed in production for Bitcoin today. The company has also constructed a post-quantum testnet for Solana — quietly positioning itself as the cross-chain migration vendor while everyone else is still drafting whitepapers.

2. Protocol-Level Address Standards: BIP-360​

BIP-360, championed by developer Hunter Beast, proposes a new Bitcoin output type called Pay-to-Merkle-Root (P2MR). P2MR functions like Pay-to-Taproot but strips out the quantum-vulnerable key-path spend, replacing it with FALCON or CRYSTALS-Dilithium signatures — both lattice-based schemes considered quantum-resistant.

If activated via soft fork, BIP-360 gives users a destination to migrate to. It does not, however, automatically rescue exposed coins.

3. Coin Freezing: BIP-361​

BIP-361, proposed in April 2026, is the most controversial response: freeze the roughly 6.5 million quantum-vulnerable BTC in place — including Satoshi's million coins — preventing any movement that an attacker could front-run. Recovery would only be possible for wallets generated from BIP-39 mnemonics. P2PK outputs and other early formats would be effectively burned.

The proposal has split Bitcoin's community along its oldest fault line. One camp argues immutability and credible neutrality are sacred — even if attackers eventually claim those coins. The other counters that allowing $440 billion to migrate to a hostile actor in a single weekend would be the largest wealth transfer in monetary history, and that the integrity of Bitcoin's fixed supply model is itself a property worth defending.

There is no clean answer. Either Bitcoin accepts that 6.5 million coins may be silently stolen, or it accepts that protocol-level intervention to freeze coins establishes a precedent the network has spent 17 years avoiding.

NIST FIPS 203/204 Sets the Crypto Defaults​

The technical building blocks now exist because NIST finalized them. On August 13, 2024, the agency published three post-quantum cryptographic standards:

• FIPS 203 (ML-KEM): Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber. Replaces RSA and ECDH for key exchange.
• FIPS 204 (ML-DSA): Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium. Replaces ECDSA and RSA for signing.
• FIPS 205 (SLH-DSA): Stateless Hash-Based Digital Signature Standard, derived from SPHINCS+, providing a conservative hash-based signature alternative.

The NSA's CNSA 2.0 roadmap mandates post-quantum deployment for new classified systems by 2027 and full transition by 2035. NIST itself projects 5–10 year adoption cycles for critical infrastructure. Cloudflare is targeting full post-quantum coverage by 2029.

Bitcoin's migration timeline is supposed to fit somewhere inside that envelope. The hard part is that nation-state IT departments can mandate a deadline. A permissionless decentralized network has to convince thousands of independent actors to coordinate without a CEO.

The Optimism Comparison: How Ethereum's Superchain Is Doing It​

Bitcoin isn't alone in this race. In late January 2026, Optimism published a 10-year post-quantum roadmap for its Superchain — a useful contrast.

The OP Stack plan has three layers:

• User layer: Use EIP-7702 to let externally owned accounts (EOAs) delegate signing authority to smart contract accounts that can verify post-quantum signatures, without forcing users to abandon their addresses.
• Consensus layer: Migrate L2 sequencers and batch submitters off ECDSA and onto post-quantum schemes.
• Migration window: Dual-support both ECDSA and post-quantum signatures until the January 2036 deadline.

Optimism is also lobbying Ethereum mainnet to commit to a timeline for moving validators away from BLS signatures and KZG commitments. The Foundation is reportedly engaged.

The architectural divide is instructive. Ethereum's account abstraction roadmap (and Solana's runtime flexibility) make post-quantum migration a smart contract upgrade. Bitcoin's UTXO model and minimalist scripting language make it a soft-fork debate that requires social consensus among developers, miners, and economic nodes. The same problem produces wildly different governance challenges.

The Investor Thesis: Insurance Premium Pricing​

Why does a $20 million Series A make sense at a $120 million valuation when no quantum computer can break Bitcoin today?

The math is actuarial. If you assign a 10% probability to Q-day occurring before 2032 and apply that against $1.8 trillion of Bitcoin and Ethereum exposure, expected loss exceeds $180 billion. Even a one-percent insurance premium on that exposure is $1.8 billion of recurring revenue across custodians, exchanges, wallets, and regulated tokenization platforms. Project Eleven only needs to capture a sliver of that to justify a multi-billion-dollar outcome.

The competitive landscape is sparse. Zama is building FHE primitives, not signature replacement. Mina is post-quantum-friendly by design but is a separate L1, not a migration vendor. AWS KMS and Google Cloud HSM will eventually offer turnkey post-quantum signing — but a hyperscaler racing to ship general PQC services is not the same thing as a domain-expert team that has actually shipped production tooling for Bitcoin.

The risk for Project Eleven is the same one any "infrastructure for inevitability" startup faces: if the migration takes too long, customers don't budget for it; if it happens too fast, it gets absorbed by cloud vendors before Project Eleven can build distribution. The Series A buys the runway to be the default during the awkward middle period.

What Builders, Custodians, and Holders Should Do Now​

The practical steps are unglamorous and don't require waiting on Bitcoin governance:

1. Audit address reuse. Any address that has spent and still holds a balance is broadcasting its public key. Sweep funds to fresh addresses you haven't transacted from.
2. Avoid P2PK and legacy formats. If your custody stack still touches them, plan migration to single-use modern address types.
3. Track BIP-360 / BIP-361 progress. The activation calendar matters more than the spot price for long-horizon holders.
4. For institutions: start the discovery phase now. NIST and the Federal Reserve both recommend completing inventory and migration planning within two to four years. That includes HSM vendor roadmaps, KYT pipelines, and treasury policy.
5. For builders: design new systems with crypto-agility. Protocols that hard-code ECDSA today will pay a higher migration cost than those that abstract signature schemes behind an interface.

Most of these steps are useful even if Q-day never arrives in the form Google's paper describes. They reduce attack surface against classical threats, too.

The Bigger Picture: Quantum Migration Is the New Y2K — Except Real​

The Y2K analogy is overused, but it's structurally apt. A long-warned, technical, governance-heavy upgrade with an externally imposed deadline, where success is invisible and failure is catastrophic. Y2K cost the global economy an estimated $300–600 billion to remediate. The post-quantum migration will likely cost more, because the install base is larger and the systems being upgraded include public blockchains that no one company controls.

Project Eleven's $20 million is the first serious admission that Bitcoin can't ignore the calendar any longer. Optimism's 10-year roadmap is the first serious admission from a major L2. Google's March 31 paper is the first serious admission from a quantum incumbent that the timeline is shorter than the industry assumed.

By 2027, expect three things: at least one BIP related to post-quantum address types reaching activation status (BIP-360 is the leading candidate), every major institutional custodian publishing a quantum readiness statement, and at least two more startups closing rounds in the Project Eleven mold. By 2030, post-quantum signing will be a checkbox in every enterprise crypto procurement RFP.

Q-day may or may not arrive on Google's schedule. The migration to defend against it has already started, and the window for getting ahead of it is narrowing fast.

BlockEden.xyz operates enterprise-grade RPC and indexing infrastructure across 15+ chains. As post-quantum standards mature and chain-level migrations roll out, our nodes are the layer where new signature schemes, address types, and dual-support windows actually need to work in production. Explore our API marketplace to build on infrastructure designed for the long arc of cryptographic transition.

Sources​

• Project Eleven Raises $20M to Prepare Digital Asset Infrastructure for the Quantum Era — Project Eleven blog
• Post-quantum crypto startup Project Eleven raises $20 million in funding round — CoinDesk
• Project Eleven raises $20 million Series A at $120 million valuation — The Block
• hello yellowpages — Project Eleven blog
• BIP 360: Pay-to-Merkle-Root (P2MR) — BIP-360 specification
• BIP-361 Proposal Seeks to Freeze Quantum Vulnerable Bitcoin Addresses — Bankless Times
• Watch out Bitcoin devs: Google says post-quantum migration needs to happen by 2029 — CoinDesk
• Google finds quantum computers could break bitcoin's encryption sooner than expected — SiliconANGLE
• NIST Releases First 3 Finalized Post-Quantum Encryption Standards — NIST
• A Post-Quantum Roadmap for the Superchain — Bankless Times on Optimism
• Quantum computing risk puts 7 million BTC including Satoshi Nakamoto's 1 million at stake — CoinDesk
• "Harvest Now Decrypt Later": Examining Post-Quantum Cryptography — Federal Reserve research

In the first three months of 2026, publicly listed Bitcoin miners liquidated more BTC than they sold in all of 2025 combined — a record 32,000+ coins shoveled out of treasuries to fund a mass migration into artificial intelligence infrastructure. Marathon Digital alone offloaded 15,133 BTC for roughly $1.1 billion in March. Riot Platforms sold 3,778 BTC for $289.5 million. Core Scientific liquidated $175 million worth in January and signaled it would dump "substantially all" remaining holdings before the quarter closed.

This is not a margin call. It is a reclassification. The companies once marketed to investors as "the public market's purest Bitcoin proxy" are quietly becoming something else entirely: high-density power providers that happen to run some ASICs on the side. And the deeper that transformation goes, the louder the question becomes — what happens to Bitcoin's security backbone when the people who built it stop caring whether it survives?

For five years, "insufficient SOL for transaction" has been Solana's most expensive error message. Every consumer app that ever pitched a non-crypto user lost some percentage of them right there — at the checkout step where a stranger has to acquire a second token just to spend the first one. In April 2026, the Solana Foundation finally shipped the answer: Kora, a fee relayer and signing node that lets dApps sponsor transactions natively, pay fees in any SPL token, and outsource signing to TEEs or KMS-backed vaults. It is not a flashy launch. It is a plumbing upgrade. And plumbing upgrades are how Base and Abstract quietly captured the last twelve months of consumer onboarding.

The question is no longer whether Solana can match the gasless UX of EVM consumer chains. Kora makes that part trivial. The question is whether closing the last-mile gap is enough to win back the developers who already built somewhere else.

What Kora Actually Ships​

Strip away the marketing and Kora is three things bolted together: a transaction relayer, a remote signer, and a policy engine. A dApp constructs a transaction, sets a Kora node as the fee payer, the user signs the payload from an embedded wallet, and the Kora operator co-signs and broadcasts. Validators still get paid in SOL. The user never holds any.

What makes it interesting is the validation layer. A Kora node does not blindly relay anything users hand it. It does three checks before signing:

• Instruction validation against the associated Solana programs, so malformed or malicious instructions get rejected before they hit a leader.
• Oracle-backed fee adequacy, comparing the offered SPL token amount against current SOL price plus operator margin, so the relayer is never running at a loss.
• Allowlist and blocklist enforcement at the program and token level, so an operator running a Kora node for a single dApp never accidentally sponsors a transaction targeting some random unaudited contract.

The signing path is where the architecture gets ambitious. Kora supports remote signing through Turnkey and AWS KMS out of the box, which means the private key that pays fees never lives on the relayer's disk. For a fintech building on Solana, that is the difference between "we rolled our own paymaster and crossed our fingers" and "our key custody story passes a SOC 2 audit."

The whole thing has been audited and differentially fuzz-tested by Runtime Verification, which is the kind of detail you mention only when you expect institutions to read the line item.

Why "Native" Beats "Smart Contract" Here​

The temptation is to compare Kora to ERC-4337 and assume Solana is catching up. The architectures are doing different things, and the difference matters.

ERC-4337 is account abstraction implemented as a parallel system on top of Ethereum. It introduces a separate mempool, a UserOperation object, a bundler role, and an EntryPoint contract — none of which the base protocol natively understands. Bundlers package user operations, paymasters sponsor fees, and an on-chain contract enforces validation. It works, and it has been deployed across Ethereum mainnet and major L2s, but it is a six-year construction project to retrofit a UX feature that the protocol never anticipated.

Solana's design ate that complexity at the protocol layer years ago. Every transaction already has a feePayer field. Partial signatures are native. Programs can validate arbitrary instructions. Kora is not a bundler-and-paymaster construction; it is a node operator that fills in the feePayer slot and signs with one of the partial signatures the protocol already accepts.

The practical consequence is latency and developer surface area. ERC-4337 transactions go through a separate mempool with its own ordering rules and propagation delays. Kora transactions go through the same path as every other Solana transaction, with the same sub-400ms finality. There is no bundler arbitrage market to think about, no EntryPoint contract version to track, no UserOperation gas estimation to debug.

What this buys Solana developers is something close to "set the fee payer field, ship the dApp." What it loses is some of the optionality EVM smart accounts get for free — multi-key auth, batched calls, on-chain session policies — though much of that is being built separately on Solana through PDAs and program-controlled accounts.

The Last-Mile Gap Solana Actually Had​

For all the talk about Solana's developer momentum in 2025 and 2026, the consumer wallet layer was the part that lagged. The infrastructure stack matured fast: Pump.fun's DEX volume topped $2B in Q1 2026, Jito and Marinade dominate liquid staking, Tensor turned NFT trading into a professional terminal. But every one of those products had to ship its own answer to "the user has no SOL."

The workarounds got creative. Pump.fun routed initial token acquisitions through embedded onramps. Jito pre-funded user accounts with dust amounts. Tensor leaned on Phantom and Backpack to handle the SOL acquisition step before users ever reached the bid book. Each of these worked individually and none of them composed. A user who onboarded through Pump.fun's flow did not arrive at Tensor with a fee-paying balance.

Meanwhile Base shipped Coinbase Smart Wallet's passkey flow, free gas sponsorship through Coinbase Developer Platform, and a developer SDK that hides the entire concept of a private key behind email login. Abstract took the same idea further with embedded wallets that feel like Web2 apps. The combined pitch to a consumer-app developer in 2025 was: build on Base, your users will not know they're onchain, and we'll pay the fees while you scale.

Kora does not replicate that pitch line for line. What it does is remove the architectural reason a Solana dApp could not write the same pitch. With Kora, a Solana team can now offer:

• Email or passkey signup through Privy, Turnkey, or Coinbase Embedded Wallets.
• Zero SOL balance required to transact.
• Fees paid in USDC, BONK, or the dApp's native token if it has one.
• Sub-second finality with no bundler in the path.

The pieces existed before. Octane was the open-source ancestor. Circle's Gas Station, Openfort, Portal, Gelato, Biconomy, and a half-dozen other vendors offered fee relaying as a service. What Kora changes is that the Solana Foundation itself is now shipping the standard, audited, KMS-compatible reference implementation. That removes "which third-party paymaster do we trust" from the decision tree for every team that was previously rolling their own or paying a vendor.

The Vendor Layer Above Kora​

Where things get interesting is what happens to the embedded wallet vendors that already built around the gap Kora just closed.

Privy, acquired by Stripe in June 2025, has been the consumer-app wallet of choice for Solana dApps that want email login. Solana is officially a secondary chain for Privy — the depth is on EVM — but the embedded wallet flow extends to Solana, and Privy already supports configuring a fee payer wallet that the app manages. Kora does not replace Privy; it gives Privy a standardized backend to plug into rather than each customer running their own paymaster service.

Turnkey is the security-first embedded signer that pairs naturally with Kora's remote signing API. Turnkey explicitly does not include paymaster infrastructure, so Solana teams that want hardware-isolated keys plus gasless UX have been forced to bolt two vendors together. Kora collapses that integration.

Dynamic, acquired by Fireblocks in 2025, brings multi-chain auth to institutional teams. The Fireblocks-backed positioning makes Dynamic the natural choice for fintechs that need both Solana and EVM coverage with enterprise compliance. Kora gives Dynamic a clean Solana fee-abstraction story that does not require Fireblocks to ship a competing paymaster.

Coinbase Developer Platform is the awkward one. Coinbase has invested heavily in making Base the default consumer chain through Coinbase Smart Wallet, free Base gas, and the embedded wallet SDK. Kora narrows the differentiation Base has been selling, especially for apps that want USDC-native flows where Solana already has scale advantages.

The likely outcome is that Kora becomes the default Solana backend for every embedded wallet vendor that did not want to operate a paymaster service themselves. The vendors compete on auth UX, key management, and policy controls. Kora handles the fee relay underneath. That is healthier for the ecosystem than the prior state where every consumer Solana dApp made an independent vendor decision and had to evaluate the security of each candidate's homegrown relayer.

What This Does and Does Not Solve​

Kora closes one gap definitively and leaves several others open. Worth being precise about which is which.

What Kora solves:

• The "user must hold SOL" UX cliff for any dApp willing to subsidize fees in another token.
• The "build vs buy a paymaster" decision for teams that previously had to choose between operational burden and vendor lock-in.
• The institutional acceptability gap, since the audit and KMS support let regulated entities run Kora nodes without rolling their own.

What Kora does not solve:

• Wallet acquisition itself — users still need an embedded wallet from somewhere, whether Phantom, Privy, Turnkey, or Coinbase.
• Account abstraction primitives like batched calls and session keys, which are still being assembled separately on Solana through PDAs and other program-level patterns.
• The economic question of who pays for the SOL that Kora operators front. For a dApp with token revenue or a stablecoin float, this is fine; for a free product, gas sponsorship is just a customer acquisition cost.
• Cross-chain UX, which still requires the user to interact with a bridge or a chain abstraction layer like LayerZero, Wormhole, or Across.

The "gasless infrastructure as protocol primitive" thesis cuts both ways. Solana now has the cleanest native fee abstraction story of any major chain. It also means the differentiation moves up the stack to wallet UX, recovery flows, and account abstraction features where EVM has a multi-year head start.

The Strategic Read for Builders​

For a team picking a chain in mid-2026, the calculus has shifted. Twelve months ago, the consumer-onboarding answer was Base, Abstract, or one of the new EVM consumer chains, full stop. Solana had developer mindshare and infrastructure momentum but lost retail users to the SOL acquisition step. That is no longer true.

A consumer dApp launching today on Solana with Privy or Turnkey on the front end and Kora on the back end has functionally the same UX surface as the equivalent stack on Base. Email login, gasless transactions, fee payment in USDC, sub-second finality. The remaining differences are the runtime model, the tooling ecosystem, and the available liquidity. For an app that wants Solana's throughput and DEX depth, the UX argument for picking EVM has gotten substantially weaker.

For teams already shipping on Base, Kora does not change the immediate decision. It does change the long-term competitive pressure. If the consumer dApps with the cleanest UX start showing up on Solana because the new infrastructure is one less integration to worry about, the gravity around Base's consumer-onboarding moat starts to shift.

The honest read is that Kora is necessary but not sufficient. It removes a specific reason developers were not picking Solana for consumer apps. It does not by itself create a new reason to pick Solana. The next two quarters will show whether the embedded-wallet vendors actually default to Kora, whether new consumer dApps cite it as a reason for their chain choice, and whether the existing EVM consumer chains respond by improving their own infrastructure stories.

Either way, "user must acquire SOL before transacting" is finally a legacy problem, not a current one. That alone is worth shipping.

---

BlockEden.xyz operates production-grade Solana RPC infrastructure for teams building consumer dApps, payment rails, and trading systems. If you're integrating gasless flows or scaling a Solana product, explore our API marketplace for low-latency endpoints designed for the next generation of consumer crypto.

Sources​

• GitHub: solana-foundation/kora
• Kora — Never lose a user to 'insufficient SOL' again
• How to Enable Gasless Transactions on Solana with Kora — QuickNode
• Solana Foundation Introduces Kora — Metaverse Post
• Kora Fee Relayer Enables Solana App Onboarding And Fees — Cryptonomist
• Fee Sponsorship — Solana Cookbook
• What is ERC-4337 on Solana? — Solana Developers
• Account Abstraction: Ethereum vs Solana Explained — Squads
• How Circle's Gas Station Uses Fee Payers on Solana
• Sponsoring transactions on Solana — Privy Docs
• Best Solana Wallets for Developers in 2026 — Openfort
• Coinbase Smart Wallet — State of Wallets Part 2
• Anza outlines key developments for Solana in 2026 — Phemex

Pull 2 terabytes of training data from AWS S3 to your GPU cluster and the bill arrives before the model does: roughly $184 in egress charges, on top of storage, on top of PUT/GET requests. Do it twice a day across a dozen experiments and the surprise line item starts to rival the storage itself. For AI teams, the cloud bill has become an economics problem disguised as an infrastructure problem — and a Austin-based DePIN startup named Akave thinks flat-rate, egress-free storage is the lever that finally breaks it.

Akave raised $6.65 million in March 2026 to build what it calls "the world's first decentralized enterprise data layer for AI and analytics." Its pitch is unusually specific: $14.99 per terabyte per month, zero egress fees, S3-compatible, backed by Filecoin for archival durability, with cryptographic receipts for every write. That's it. No tiers, no request fees, no bandwidth meter ticking every time a training container pulls a dataset. The question isn't whether the pricing is attractive — it obviously is. The question is whether the architecture can hold up as AI workloads scale into petabytes, and whether enterprises will trust a DePIN-backed stack for data they'd previously only hand to a hyperscaler.

The Egress Tax That Ate AI Budgets​

AWS S3's sticker price is not the problem. Standard storage runs about $0.023/GB per month in us-east-1, which works out to roughly $920/month for a 40TB training corpus — annoying but manageable. Egress is where the math breaks. After the first 100GB free, S3 egress to the internet starts at $0.09/GB, stepping down slowly to $0.05/GB above 150TB. Pull 10TB of training data out to an external GPU provider and you're looking at $921.60 in transfer alone. Do it repeatedly — which is what AI pipelines actually do — and the "hidden" egress charge eclipses storage within a quarter.

This is not a pricing quirk. It's an architectural choice that assumes storage and compute live together inside one cloud. The moment an AI team splits them — because GPU capacity sits at CoreWeave, Lambda, or an on-prem cluster while data still sits in S3 — every epoch, every checkpoint restore, every data-parallel reread becomes a billable event. AI data fabrics multiply this problem: datasets get duplicated across preprocessing, training, validation, and analytics stages, each boundary potentially a paywall.

The industry's informal workaround has been CloudFront, because S3-to-CloudFront in-region transfer is free, so teams route data through a CDN that wasn't really designed for the job. It's a tell. When customers are architecturally twisting themselves to avoid a line item, the line item is no longer pricing — it's a tax.

What Akave Is Actually Selling​

Akave Cloud is deliberately boring in the way serious infrastructure needs to be boring. The interface is S3-compatible — same SDKs, same GET and PUT semantics — so migrating a training pipeline is closer to changing an endpoint than rewriting code. Pricing is a single flat rate: $14.99 per terabyte per month, no egress, no per-request fees, no retrieval penalties. If your container pulls 500GB or 2TB of training data, it costs exactly $0 in transfer.

Underneath the familiar API, the architecture looks nothing like S3. Data is chunked, encrypted client-side, and distributed across the Akave network using 32-of-16 Reed-Solomon erasure coding, which Akave claims delivers 11 nines of durability. Long-term archival is anchored to Filecoin, the same network that underwrites a growing share of decentralized storage economics. Every write generates an on-chain receipt, and every retrieval is cryptographically verifiable — which matters less for cat photos and a lot more for AI training artifacts that regulators, auditors, or downstream model consumers may need to verify were unmodified.

The flagship piece for enterprises is the O3 gateway, an S3-compatible front door that can be hosted by Akave or self-hosted inside a customer's own infrastructure. The self-hosted version is the tell: teams with strict data residency or sovereignty requirements run O3 locally, hold their own encryption keys, and define their own access policies while still benefiting from the distributed backend. For sectors that historically couldn't touch decentralized storage — healthcare data, defense-adjacent AI, EU-regulated workloads — that configuration is meaningful.

Customer logos already include Intuizi, LaserSETI, and 375ai running production workloads, and the cap table reads like a who's-who of protocol-aligned capital: Protocol Labs, Filecoin Foundation, Avalanche, Blockchain Builders Fund, No Limit Holdings, Blockchange, Lightshift, and Big Brain Holdings. A partnership with Akash Network bundles decentralized GPU compute at around 70% below hyperscaler prices with Akave's zero-egress storage into what both companies are marketing as "sovereign AI infrastructure."

Reading the Room: Where Akave Sits in the Storage Stack​

The decentralized storage landscape has matured dramatically. In January 2026, Filecoin launched Onchain Cloud on mainnet, positioning itself as a full-stack decentralized alternative to AWS with compute, verifiable retrieval, and automated payments. Storacha Forge, one of the earliest Onchain Cloud services, offers warm storage at $5.99 per terabyte. The broader DePIN sector has grown from roughly $5.2 billion in market cap in 2024 to over $19 billion by late 2025 — close to 270% growth — as AI demand, enterprise adoption, and DePIN infrastructure quality all crossed usability thresholds at roughly the same time.

Against that backdrop, Akave occupies a specific niche that neither Filecoin nor Arweave natively fills:

• Filecoin is brilliant at long-tail archival and economic incentives but historically required deals, retrieval markets, and tooling that don't look like S3. Akave essentially packages Filecoin's durability into an S3-compatible interface with a flat rate.
• Arweave sells permanence: one-time payment, indefinite storage, no retrieval guarantees. That's the right tool for immutable artifacts — NFT assets, on-chain documents, compliance archives — but a poor fit for the hot, mutable datasets AI training pipelines churn through.
• Cloudflare R2 already offers zero egress and is the centralized benchmark Akave's pricing explicitly targets. R2 wins on latency, ecosystem integrations, and track record; Akave counters with sovereignty, verifiability, and a trust model that doesn't depend on a single provider's uptime — a point sharpened by the global Cloudflare outage in November 2025 that exposed how many "decentralized" apps still lived on one company's edge.
• MinIO, the open-source self-hosted S3 alternative, recently shifted to a source-only model that spooked enterprises who'd built stacks assuming predictable community editions. Akave has been quietly pitching itself as a migration target for MinIO users who wanted self-host ergonomics without assuming their own operations burden.

The clearest way to understand Akave is as a pricing and interface arbitrage on decentralized storage primitives: take Filecoin's durability, wrap it in S3 semantics, put a flat-rate meter on top, and sell the result to AI teams who are already bleeding on egress.

Why Timing Matters: The Power and Data Gravity Pincer​

At NVIDIA GTC 2026, Jensen Huang described AI as a "five-layer cake" with energy forming the foundation — every unit of machine intelligence ultimately a conversion of electricity into computation. The Department of Energy and Lawrence Berkeley National Laboratory project US data centers could consume up to 12% of total US electricity by 2030, up from about 4.4% today (roughly 176 TWh). The IEA's 2026 projection has global data centers hitting 1,000 TWh this year — Japan-scale power consumption, dedicated to compute.

The knock-on effect is that where data sits increasingly determines where compute can run. Hyperscalers are supply-constrained on power. GPU capacity is popping up wherever grid interconnects allow: Texas, the Nordics, the Middle East, secondary US markets. If your training data is pinned to us-east-1 and your GPUs are in Reykjavík or Abu Dhabi, you're paying egress to move bits to the silicon. Zero-egress, compute-agnostic storage turns data into a first-class citizen of a multi-cloud, multi-geography world — exactly the world AI economics is now forcing.

That's the real reason a pricing model like Akave's lands now rather than three years ago. When compute was abundant and cheap, egress was a rounding error. In an AI-constrained grid, egress is strategy.

The Skeptical Case: What Could Go Wrong​

Three legitimate concerns temper the bull case.

First, latency and throughput at petabyte scale. AI training pipelines are bandwidth-hungry and latency-sensitive. S3 isn't just cheap storage with a nice API — it's a globally distributed edge network with decades of optimization. Akave's erasure coding and decentralized retrieval add hops. Production customers like 375ai suggest it's viable for common workloads, but teams considering multi-hundred-gigabit-per-second training feeds should benchmark carefully before committing.

Second, enterprise procurement inertia. Flat pricing is great; so is sovereignty. But enterprise security, legal, and compliance teams move on a timescale measured in quarters, and DePIN is still a novel procurement category for most Fortune 500 CIOs. Akave's self-hosted O3 gateway is partially an answer to this — "it's our hardware running their software" is easier to approve than "our data lives on a blockchain" — but the sales cycle is real.

Third, economics are only cheap if the network stays healthy. Filecoin and Akave's incentive layers assume a population of storage providers willing to underwrite capacity at the offered price. If AI demand spikes faster than supply, flat pricing either compresses provider margins or quietly gets re-tiered. Hyperscalers can subsidize; DePIN networks have to balance.

None of these are fatal. All of them mean Akave's challenge is less about whether the cost pitch lands and more about whether the operational story is boring enough for a Fortune 500 SRE to sign off.

The Bigger Pattern: Storage as a Wedge Into AI Infrastructure​

The most interesting thing about Akave isn't the $14.99 price tag. It's what the price tag is trying to accomplish strategically. Storage is a low-margin commodity, but it's also the layer with the most data gravity — whoever owns the dataset owns the default answer to "where should we train?" and eventually "where should we inference?" The Akash x Akave partnership is a clear signal of this: decentralized GPU compute at 70% below hyperscaler prices means nothing if your data lives somewhere that charges you to leave. Bundle them, and the economics become an integrated alternative to the AWS stack rather than two discounts stapled together.

Expect this pattern to repeat across the DePIN-for-AI category through 2026. Storage networks will court compute networks, compute networks will court inference gateways, and inference gateways will court agent frameworks — all trying to assemble a vertical that can quote a single, predictable price against what is still, from the customer's perspective, a single bundled hyperscaler experience. The winners will be the ones who feel like infrastructure, not like crypto.

Akave is a credible early contender because it refuses to look like crypto at the surface: S3 endpoint, flat rate, audit-friendly receipts, real customers. The decentralized bits are under the hood, where — if Akave is right — they should be.

---

For developers building the next generation of Web3 and AI-native applications, BlockEden.xyz provides enterprise-grade RPC, indexing, and API infrastructure across 25+ chains, with the reliability profile serious production workloads demand. Explore our API marketplace to build on infrastructure designed for the long haul.

Sources​

• Akave Cloud: S3-Compatible Object Storage
• Akave Raises $6.65M to Challenge Traditional Cloud Storage (BusinessWire)
• Akave raises $6.65M for compute-agnostic, egress-free cloud storage (SiliconANGLE)
• Decentralized S3 Storage for AI: Zero Egress (TFiR)
• Akash Network & Akave: Building the First Sovereign AI Infrastructure
• Akave Cloud x Filecoin: S3-Compatible Object Storage for Enterprise and DePIN
• MinIO Alternative: Migrate to Akave O3
• AWS S3 Pricing
• A 2026 Guide To Amazon S3 Pricing (CloudZero)
• Cloud Storage Egress Fees Are Costing Your AI Projects More Than You Think (Akave)
• Introducing Filecoin Onchain Cloud
• Web3 Storage War 2026: Filecoin, Arweave & DePIN Boom
• DePIN Compute Wars: AI Inference & Data Storage 2026
• NVIDIA GTC 2026: AI's future keeps coming back to energy (Reccessary)
• The AI Data Center Power Crisis (Tech Insider)

For fifteen years, Bitcoin's scripting language has been deliberately, aggressively boring. No loops. No recursion. No state. A small stack, a handful of opcodes, and a culture that treats every proposed expansion like a potential civil war. That conservatism is the reason Bitcoin has never been successfully exploited at the consensus layer — and the reason developers who wanted to build anything beyond "send coins from A to B" eventually gave up and moved to Ethereum.

That calculus is shifting in 2026. OP_CHECKTEMPLATEVERIFY has concrete activation parameters on the table for the first time since BIP-119 was drafted. OP_CAT has an official BIP number. LNHANCE is being actively discussed as a Lightning-focused alternative. And BitVM2 — which doesn't require any soft fork at all — is already live in production, powering Citrea's mainnet bridge that launched in January. After years of "covenants are coming soon," Bitcoin is finally in the phase where multiple credible proposals are running in parallel, each solving a different slice of the problem.