Enabling the Fastest Transactions with Shreds

Shreds enable a user experience that feels like the modern web, but on a blockchain. They generate transaction preconfirmations within single-digit milliseconds, reacting to demand in real time. Unlike traditional blockchains, which wait for discrete blocks to process, Shreds are continuous and interrupt-driven.

Not only are they significantly faster than typical L2 confirmations, they are also economically secured through signed L1 preconfirmations.

Identifying the Bottleneck

Blockchains are sophisticated decentralized networks that must reach consensus on state updates before confidently propagating confirmations to users around the globe. For users, this introduces variable delays in transaction confirmations, typically between 0 and 2 block times even with an empty mempool, depending on the consensus design.

Solana made a noteworthy attempt to address this with its no-mempool design, reducing confirmation times to 0-1 block times, though this comes with some sacrifice to quality of service (QoS). Other notable chains, like Sui and Aptos, explore consensus-less paths. However, no current solution truly matches the user experience of the modern web.

Modern Web Experience

Traditional web servers update state in a continuous, interrupt-driven manner. This means transactions are processed as soon as they arrive. When demand is high, servers implement queueing to manage the load and process requests as resources become available.

For users, this results in immediate transaction processing—no waiting for arbitrary cadences.

L2 Baggage

For various reasons, Ethereum Layer 2s have inherited the block paradigm, where consensus is reached before confirmations are propagated throughout the network. At RISE, we ran a design experiment: if you were to build an L2 from first principles, what would it look like? We realized that L2s are fundamentally different from L1s. They don’t carry the same consensus burden, presenting an opportunity to rethink the discrete block paradigm.

Speed

To respond to demand and deliver both extremely low latency and high throughput, the RISE stack features a variable shred-time mechanism. Under normal demand, users can expect 1ms or less processing times. During peak demand, the dynamic shred-time increases up to 20ms, allowing the execution engine to handle higher demand.

Implementation Details

• If the mempool is empty, transactions are processed immediately. The state is updated, and results are propagated across the network via a fast P2P layer.
• If there is significant demand and the mempool isn’t empty, transactions are collected into bundles, processed immediately and in parallel—thanks to pevm—then packaged into a shred and propagated through the network.

Security

A typical confirmation from an L2 is a soft promise from the sequencer that your transaction will be included in an upcoming L2 proposal. If the L2 chooses not to include your transaction, you have no recourse. Shreds, however, are accompanied by a signed and slashable commitment from the sequencer (and, in the future, a permissionless based-builder), economically securing your confirmation as a user.

For more on based shred confirmations, see our recent article: Road to Real-time: Preconfirmation Shreds.

Confirmation & Structure Comparison

Benchmarks

Continuous Shreds offer fast, secure preconfirmations, but how fast are they really? Accurately testing latency is challenging. Blocktime is often used as a reference point, but it doesn’t reflect the true round-trip latency experienced by users. The TL;DR: Block Time ≠ Latency.

Let’s test latency from the perspective of a power user hosting their client in an ideal geographic region.

Below are the results from a test that sends 10 sequential transactions, polling each for confirmation and measuring round-trip latency from submission to confirmation.

The result: RISE Testnet is more than 10x faster than the nearest competitor, Megaeth, and 60x faster than the next closest, Arbitrum. You can find the testing details here and even reproduce the results yourself!

Key information about the benchmark:

• 10 sequential transactions were tested; the table shows the average.
• Each transaction was sent and then polled for confirmation.
• While this doesn’t reflect typical user behavior, 3x the default gas price was used.
• We cannot confirm the precise location of each L2 sequencer, as this information is generally not public. However, our testing suggests that all sequencers are located in or near us-east-1.
• The RISE Testnet Sequencer is running at a different data centre; this is not a co-located test.

Please note: This test was intentionally designed to minimize network latency in order to isolate and compare transaction execution and processing time. While it doesn’t represent the experience of an average user, it does reflect the experience of power users such as market makers, high-frequency traders, and algorithmic trading systems.

Shred API

The Ethereum JSON RPC API wasn’t built with low latency applications in mind. That’s why we’ve developed an extended version, the Shred API, designed to unlock the full potential of Shreds.

This API is currently in an experimental phase as we gather feedback and iterate based on what developers actually need.

The full Shred API spec will be made public soon. In the meantime, if you're eager to gain a latency edge in the market, reach out to the team and we’ll make it happen.

Try RISE!

RISE testnet is now live. Builders can finally create a user experience that meets real-world expectations. It's faster than anything that came before, but more importantly, it's the first chain designed to stay fast.