⚡️ 200ms BLOCKS! NEAR PROTOCOL INTRODUCES 'SPICE': SEPARATION OF CONSENSUS AND EXECUTION

NEAR One has introduced SPICE.
A huge milestone with many practical improvements for users and devs

• 600ms to 200ms

• parallelization

• preparation for atomic transactions

In this video I go through what is SPICE, why the Separation of Consensus and Execution matters for NEAR Protocol users, and give an easier explanation on what happens under the hood.

⚡️ The first and must obvious improvement is transaction finality.

10-20x faster than VISA, as fast as physical limitations allow a network to be (lightspeed), from 600ms (today) to 200ms (post-SPICE).

🌐 Then, parallelization improves network efficiency and scalability, as many complex transactions can execute in the background at the same time.

One big execution (tx) doesn’t delay other transactions.

⚛️ Looking ahead, SPICE sets the ground for upcoming improvements that aim to bring atomic transactions to NEAR, solving one of the current main criticisms and security concerns for NEAR that is async cross-contract calls.

But this is a topic for another video

NEAR Protocol@NEARProtocol

SPICE is coming to NEAR. This major protocol upgrade is currently in development and will separate consensus from execution, unlocking 200ms blocks. This is the speed necessary to power what comes next: agents transacting at machine speed on the open rails of NEAR Intents 🧵

10:07 PM · Jun 22, 2026 · 192K Views

26 Replies · 62 Reposts · 498 Likes

I like to think of SPICE as this:
Imagine NEAR is a restaurant’s kitchen.

🧑‍🍳 The chef receives orders from the tables and add them to a list that will guide execution from his team, but he still needs to oversee every single dish and process.

The chef can only receive new orders and add them to the list after his team finishes what they are currently working on.

This is how NEAR is today (simplifying for how a single shard works).

What SPICE allows is that the chef can add new orders in the list while different teams are preparing, in parallel, different dishes or parts of previous orders.

He doesn’t need to check every single delivery.
Just receive the team’s confirmation that execution is done.

---

From a technical perspective, validators can continue producing blocks and agreeing in their ordering (CONSENSUS) even if a complex transaction is still executing in the background (EXECUTION).

Add that to a sharded architectures (which effectively means many kitchens working together for the same restaurant) and the possibilities are huge.

---

Other blockchains already implement some sort of parallelization (solana, sui, aptos...) and monad already has something like SPICE.

But none of them are sharded.

Sharding add some real complexities to implementing these optimizations, but when it’s done right, the benefits are much bigger as well.

Study NEAR.