With the advent of any new technology, it is difficult to imagine what kinds of applications it could enable. AI continues to globally captivate businesses, developers, and consumers in every category. While AI continues to find its place in every aspect of life, there are two areas it hasn’t quite found its stride: crypto and consumer.

Through Onchain Labs, we’re committed to fostering innovation in blockchain applications. Today, we’re excited to announce our collaboration with a team that continues to impress:

Simcluster

@Simcluster is a parallel digital society at the intersection of AI, crypto, gaming, and social media, created specifically to embrace the era of AI slop. Widespread access to AI models has triggered a surge of slop across social media feeds. It’s easy to see that it will be difficult to discern slop from reality very soon. Webster selected “slop” as the 2025 word of the year, further cementing this phenomenon into culture.

Simcluster takes a maximalist position on slop — instead of fighting it, they believe that “the only way out is through.” The app offers a gamified social experience where the goal is simple: create engaging AI-generated content to climb the leaderboard and earn clout. Simcluster utilizes its own in-app content studio to enable users to seamlessly create and edit text, images, video, and music. The scope of studio output will expand dramatically as AI continues to evolve, where Simcluster will be a dedicated tool for the creation of new worlds, programs, games, and agents.

Simcluster utilizes a “hyperprompting” system, enabling users to efficiently mold model outputs without prior prompting experience. Hyperprompting is to prompting as vibecoding is to programming. It lets users create masterpieces without requiring Altman-levels of prompting experience.

Sound easy? There’s a catch.

Simcluster limits content to the output of its concept system.

Simcluster is built on three fundamental components: concepts, content, and clout. Users can create concepts out of anything. These concepts are composable building blocks that enable users to create content. Concepts can best be compared to LLM prompts. All info within a concept’s definition will be directly used to generate content. Whenever a concept is used, the creator of that concept earns virtual currency, known as clout. Clout is both an in-game currency and social credit engine that inspires users, known colloquially as “simulants,” to keep playing, or “clusting.”

To create concepts or content, users must spend clout. The more clout a user has, the higher they are on the leaderboard. The higher a user is on the leaderboard, the easier it is to earn more clout. Users also earn clout anytime somebody engages with their content. Clout is not a tradable asset, has zero monetary value, and exists solely for *pun intended* social clout.

These gamified mechanics create an engaging virtual world for players to participate in, where a variety of play styles can be used depending on their preference. Concepts serve as an innovative spin on tokenized IP, especially when considering how they are key inputs into content.

We’ve chosen to collaborate with Simcluster to embrace an emerging app in consumer AI. Blockchain games and consumer crypto apps often fail because they over index on speculation. We’ve seen that speculation as a product often loses its fun after all the value leaves, as evidenced by previously popular crypto apps left for dead.

Harvey (@npceo_) and the team have an unrelenting curiosity and drive to create an entertaining, dystopian digital world that keeps users returning for more. Crucially, Simcluster is very different from prior crypto gaming or social ventures, which often suffer from cold start problems due to requiring users to have risk tolerance from day one. Simcluster keeps it simple — play the game, climb the leaderboard, have fun.

It’s important to note that Simcluster has no blockchain elements live today. Although clout is a non-transferrable, free-to-earn virtual currency, we’ve seen that some of the most successful gaming companies in web2 often employ a two-tiered in-game currency model. Simcluster plans to bring its composable concept registry and creator reward system onto Arbitrum. We’re excited to watch the platform grow from an emerging gamified social platform to something much bigger.

For the curious, use our referral code ARBITRUM to jump to the front of the line and start using Simcluster today.

Through Onchain Labs, our team will be involved in advisory capacity, assisting with GTM, partnerships, and protocol design. If you’re a hungry founder building something novel in crypto, apply for Onchain Labs here: https://forms.gle/QTWcbZWFYUaoknqN7.

*Disclosure*

Onchain Labs is a collaboration between The Arbitrum Foundation and Offchain Labs, either of which may have a financial interest in Simcluster through investments and/or other commercial arrangements.

Welcome to Arbitrum, Simcluster was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Arbitrum’s New Architecture

Ethereum has long faced scalability challenges that have hindered its ability to handle the ever-growing demand for decentralized applications. As the leading and most secure smart contract platform, Ethereum’s main bottleneck has always been its ability to process transactions quickly and at a low cost without compromising on its inherent security. To address these limitations, various L2 solutions have emerged, with Arbitrum standing out as the most successful and widely adopted rollup in the Ethereum ecosystem.

Arbitrum, having been a pioneer in scaling Ethereum with optimistic rollups, is now advancing its exploration of Zero Knowledge (ZK). This multi-prover approach sets Arbitrum chains apart from single-prover rollups, offering flexibility and ensuring the ecosystem isn’t tied down by one proof system but can also evolve as ZK tech matures.

Arbitrum chains will be able to tap into this technology in early next year with a DAO proposal to discuss the potential integration into Arbitrum One expected in 2026. The introduction of ZK can help create an even more customizable stack, giving developers even more opportunities to create chains that precisely address their scaling needs.

The incorporation of multi-prover technology introduces a unique model that can strengthen Arbitrum’s scalability and furthers trust-minimized solutions. ZK, in combination with fraud proofs and trusted execution elements (TEEs), reduces the vulnerabilities typically associated with single-prover solutions. This new approach can allow Arbitrum to strengthen each technology, creating a more secure and resilient ecosystem. This added protection can benefit high-value chains that handle sensitive or critical transactions, giving users and developers more confidence in their applications.

Multi-Proving as Flexibility

While ZK technology will be a powerful addition to Arbitrum’s infrastructure, it doesn’t replace the existing optimistic rollups model. Instead, it works in tandem with it to offer a multi-prover approach that allows for greater flexibility and adaptability. This intended solution combines the strengths of both technologies, offering developers a wider range of configurations to optimize their chains based on their unique needs.

The flexibility inherent in this multi-proving architecture, if adopted, means that Arbitrum can support a broader array of use cases, from gaming and high-throughput consumer applications to enterprise-level privacy solutions. By giving developers the option to choose from a diverse set of security configurations, Arbitrum can enable applications to be both scalable and secure, without being tied to a single technology stack. This approach can help Arbitrum remain a versatile and future-proof platform as decentralized applications continue to evolve.

If Arbitrum integrates ZK, it is likely to reduce settlement times, unlocking new levels of efficiency and improving the user experience. Faster settlement and reduced costs, enabled by the hybrid use of fraud proofs, ZK and TEEs, mean that applications on Arbitrum can operate at scale without the traditional overhead associated with other L2 solutions. This integration can help push up effective gas limits — contributing to overall throughput goals of 1 Gigagas per second and 100ms block times, further solidifying Arbitrum’s capability to handle large-scale applications across industries.

In addition to scalability and speed, privacy is another significant area where Arbitrum’s approach excels. With optional privacy through ZK technology, Arbitrum apps and chains will have more ways to offer enterprise-level confidentiality while maintaining full auditability. This is especially important for industries like finance, where privacy isn’t just desirable, it’s a regulatory requirement. Arbitrum’s AnyTrust technology allows businesses to balance privacy needs with compliance, supporting applications in meeting industry-specific regulatory standards without compromising on security.

Future of Ethereum and Arbitrum

The future of Ethereum and Arbitrum looks promising as both continue to evolve and adapt to the changing needs of decentralized applications. Arbitrum’s multi-prover approach, which combines the strengths of optimistic rollups and ZK technology, will offer developers the flexibility to scale their applications while maintaining high levels of security. With the ability for Arbitrum stack chains to upgrade and configure their security models at will, Arbitrum provides an adaptable and developer-driven platform ready to support the next generation of decentralized applications.

As Ethereum grows and matures, Arbitrum has positioned itself as a key player in the ongoing evolution of scalable and secure blockchain infrastructure. With its customizable approach, Arbitrum is paving the way for a future where enterprises, institutions and developers can build high-performance applications while maintaining the trust, privacy and security that blockchain technology requires.

Want a chain that plays by your rules? Learn more about launching on Arbitrum here.

Scaling Ethereum with ZK and the Road Ahead for Arbitrum was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

For those of you who are plugged into the Ethereum world, you would be aware that Pectra has recently shipped. And, like every major fork in the past, this is a good time to look back, not just at what went into this major upgrade but also at how Prysm got here in the first place.

Prysm has existed since 2018. Its initial purpose was to support Ethereum through sharding. This was pre-merge, and back when sharding was still at the center of Ethereum’s scalability roadmap. As priorities shifted toward Proof of Stake, so did Prysm’s direction and the many iterations of its codebase.

Since then, Prysm has grown to become one of the most widely used consensus clients. In 2020, it helped bring the Beacon Chain to life, then later in 2022 (the same year Prysm joined Offchain Labs), it successfully assisted in shipping the Merge. Most recently, with Pectra, the Prysm team helped ship one of the most complex forks since the Merge. This latest upgrade is packed with new features and structural improvements, which the blog will delve into in more detail.

Eight years down the road, Prysm’s mission has remained the same. That is, to help scale Ethereum, improve validator infrastructure, and continue to push the boundaries of possibilities of what blockchains can do.

Bringing the Pectra Hard Fork to Life

Shipping Pectra

As previously mentioned, Pectra was one of the largest forks since the Ethereum Merge. Over a year of development work went into making it happen, and Prysm was right in the middle of it all. So what happened behind the scenes?

Around 37 unique contributors helped bring Pectra to life across 12 different releases, from versions 5.1 to 6.0.2. This effort resulted in over 3,100 file changes, with nearly 700 commits. This was a massive effort, with roughly half of the EIPs included in the fork implemented directly in the Prysm code base.

These weren’t minor features either. The Prysm team handled some significant consensus logic changes, such as onchain validator deposits (EIP-6110), execution triggerable withdrawals (EIP-7002), and raising the validator max balance (EIP-7251). The Prysm team also helped bring in generalized requests from the execution layer (EIP-7685) and boosted blob throughput (EIP-7691). Pectra was rather unique in its breadth, as it touched nearly every part of the system. For the Prysm team, this upgrade was a chance to demonstrate deep technical understanding and deliver meaningful improvements across the board.

The Invisible Work That Made Pectra Possible

Considering the scope of Pectra, the upgrade was relatively seamless, but that isn’t to say everything was clean. Take EIP-7549, for example. This EIP was proposed to make onchain attestations more compact, fitting up to eight slots’ worth of votes into a block instead of just two today and drastically improving Ethereum’s ability to maintain liveness even in scenarios where there was only a small fraction of proposers online. Although this looked like a small change, where all that needed to be done was just reordering some attestation data, in practice, this touched hundreds of files and required a lot of internal rewiring.

That said, Pectra did unlock some real quality-of-life improvements, such as its significant improvement to validator UX. By reducing deposit inclusion time, Prysm could begin the cleanup process of legacy logic from the merge era, which basically translates to less fragile, bug-prone code in the long term. This improvement enabled validators to compound their earnings without having to redeposit manually. And, with EIP-7002 now in place, smart contracts can directly trigger validator actions.

Of course, ample testing is part of any new upgrade. The Prysm team participated in six devnets and three public tenets, Holesky, Sepolia, and Hoodi, in collaboration with over 200 engineers and researchers across the Ethereum ecosystem.

The team also participated in the Nyota interop, Ethereum’s largest coordinated client testnet event for the Pectra upgrade, ran interop suites using Kurtosis Ethereum package from eth pandaops, and helped write and review spec test coverage across more than 16 test versions.

In addition to all this, a lot of time was spent testing edge cases, catching consensus mismatches, and ensuring that external infrastructure such as MEV-boost was compatible with Web3Signer.

So, What’s Next For Prysm?

Although the Pectra days may be over, Ethereum is not planning to slow down. In fact, the next upgrade currently underway is Fusaka, which will ship this same year. Fusaka is notable not only for its technical goals, but also because it will be the first time that Ethereum has attempted to ship two hard forks within the same year.

Fusaka is focused on scaling blob space and improving data availability. The main feature to watch for here is EIP-7594, which will introduce PeerDAS (peer data availability sampling). Today, on Ethereum, every node must download every blob, which isn’t scalable in the long run. PeerDAS is designed to change this by enabling nodes to sample blob data and verify it using erasure coding. This will allow Ethereum to increase blob throughput safely, a necessary step for scaling.

Prysm is also preparing for Blob Parameter Only (BPO) forks, which can safely increase blob count without requiring a massive consensus upgrade. This will make Ethereum much more responsive moving forward.

Eight years following its inception, the Prysm team continues to play a foundational role in its mission to scale Ethereum with Offchain Labs. Prysm is still here, building, and we don’t plan to slow down anytime soon.

Eight Years, One Mission: Shaping Ethereum with Prysm was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

In collaboration with The Arbitrum Foundation, we are excited to announce Onchain Labs, a new program aimed at accelerating innovative onchain experiences on Arbitrum.

Offchain Labs (OCL) revolutionized Ethereum in 2021 by launching Arbitrum One, one of the first optimistic rollups. Since then, we’ve consistently pushed innovation boundaries—launching an AnyTrust chain, creating Orbit for permissionless chain deployment, enabling development in familiar languages like Rust, strategically acquiring Prysm in 2022 to advance the Ethereum ecosystem, and growing the Tandem partner studio and venture capital arm.

Our ongoing work focuses on scaling throughput with an alternative client, enhancing Arbitrum with ZK integration, and improving the Ethereum experience through our Universal Intents Engine. These contributions have positioned Arbitrum as one of the most performant ecosystems in the space — and we’re just getting started.

As others play catch up, we now have a unique opportunity to empower the Arbitrum application layer.

As original builders of the chain and active users of Arbitrum applications, we have both a deep technical understanding of how to fully harness Arbitrum’s technology and crucial insights into what users truly want. We’ve generated plenty of ideas for game-changing apps — similar to how we continue to push boundaries on the infra level — but recognize we can’t build all of these ourselves. Through Onchain Labs, we’re dedicating resources to support developers looking to rapidly expand the application layer by ideating with them from the ground floor to bring the best user experiences to Arbitrum. As we do with many Arbitrum teams, we’ll provide certain product, IT, and GTM support to these early-stage projects, collaborating closely to help their applications thrive on Arbitrum.

Arbitrum boasts both the best technology and the best talent. With Offchain Labs’ support, we’re confident we’ll see industry-leading applications that are uniquely possible on Arbitrum. We’re excited to roll up our sleeves and work alongside the community to make this happen.

But building infrastructure and applications is only one part of the puzzle. Alignment is equally important. We’ve seen how extractive ecosystems create zero-sum games, where only a few profit at the expense of others. This stands in stark contrast to the core ethos of crypto.

As an industry, we can — and must — do better.

Onchain Labs will only support projects that commit to fair and equitable launches. This is essential for fostering community alignment. There’s no reason why all participants in an ecosystem can’t succeed together.

Projects supported by Onchain Labs will be experimental and volatile. We encourage all participants to do their own research (DYOR) before purchasing any tokens affiliated with Onchain Labs projects or interacting with them. Our role will be focused strictly on product and go-to-market advice. Tandem may or may not purchase associated tokens in public markets.

The first Onchain Labs project will soon emerge from stealth. If you’re a talented team interested in receiving Onchain Labs’ support, fill out this form, and we’ll be in touch.

See you in the trenches 🫡

Onchain Labs — Accelerating the App Layer of Arbitrum was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Authors: @0x_allan (Allan), @0xgodzillaba (Henry), @yahgwai (Chris)

The rollup ecosystem is expanding at a remarkable rate and coalescing around Ethereum for its security and data availability properties. However, most of these Layer 2 or Layer 3 chains have their own state and finality guarantees. While this multi-chain world enables faster and cheaper transactions, it also introduces fragmentation. As a result, users and applications rely on Crosschain communication that is not always secure, standard, or seamless.

In this blog post, our team introduces the Crosschain Broadcaster Standard — a smart contract system that aims to solve a piece of this puzzle. This standard is built on the idea that all data needed to prove a particular message is already onchain somewhere, accessible via storage proofs. For context, a storage proof is a cryptographic proof that a certain piece of data really does exist in a given blockchain’s state at a specific block. Broadcaster enables rollups that share a common ancestor–like Ethereum–to authenticate messages on each other’s chains without additional trust assumptions.

In this blog post, we’ll explore what the Crosschain Broadcaster Standard is, what problems it solves, and how it works, including:

• Why Crosschain messaging is difficult and why the ecosystem needs a standardized solution
• The major components of the Crosschain Broadcaster Standard: Broadcaster, Receiver, BlockHashProver, and Pointers
• An example of a burn-and-mint token bridge built on top of the Crosschain Broadcaster Standard
• A high-level look at how messages flow through the system

Let’s jump in!

Why Crosschain Messaging Matters

Imagine an application that’s deployed on multiple chains, like Arbitrum One and Base. A user wants to take some action on Arbitrum One that triggers a response on Base. Maybe a user wants to prove they locked some collateral on Arbitrum One to borrow something on Base. Today, crosschain actions like these often rely on third party bridging solutions that introduce several issues, such as:

1. Trust: Many existing crosschain solutions rely on a small set of centralized parties (ex. validators, oracles, relayers) to confirm that data from one chain is valid on another. Trusting those parties to do the right thing with your message or your funds is a prerequisite for users.
2. Complexity: Different rollups have different ways of achieving and recording finality. Consequently, Crosschain developers must create custom integrations with each chain to access finality data and stitch it together with other, dissimilar chains.
3. Maintenance: Rollups undergo upgrades. During these upgrades, chain owners may change finality conditions or update storage mechanisms. A Crosschain application that worked previously may break if the rollup changes where finality outcomes can be found.

The Crosschain Broadcaster seeks to solve this by providing a trustless, flexible messaging standard that is rollup agnostic. Rather than trusting offchain actors, Broadcaster utilizes onchain storage proofs for rollups rooted in Ethereum. As a smart contract standard, Broadcaster can provide standardized interfaces for messaging across any EVM-compatible chain. It is also upgradeable by design, anticipating rollup evolution while providing immutable endpoints for continuous integration. No trust assumptions, no complex customizations, no core protocol requirements.

How Crosschain Broadcaster Works

The Crosschain Broadcaster standard builds on the idea that all data needed to prove a particular message is already onchain somewhere. If a chain can figure out the correct block hash information for another chain, it can verify the existence of any piece of data in that chain’s state. Put another way, if the block hash of a given chain is final, then so is the existence of any messages stored at or before that block.

Let’s walk through a simple scenario:

1. A user on Arbitrum One submits a message to the Broadcaster contract on Arbitrum One.
2. The Broadcaster contract stores that message in a unique slot on Arbitrum One.
3. On Base, someone wants to confirm that message indeed exists on Arbitrum One; they call the Receiver contract on Base and provide:

• a “route” of Pointer addresses that leads from Base (L2) to Ethereum (L1) to Arbitrum One (L2)
• the necessary storage proofs for verification

4. The Receiver on Base works through each Pointer/Prover in the route, eventually obtaining Arbitrum’s block hash and reading the Broadcaster’s storage.

5. If the message is found, the Receiver returns success plus a timestamp. This result can trigger an arbitrary action in a smart contract that is subscribed to the Receiver

Now let’s go through a practical example: intents-based bridging. Intents-based bridging–like Across–allows users to move assets faster than they can through canonical bridges. Today, many intents-based bridges do this in four main steps:

1. User deposits funds into an Escrow contract on Base
2. A solver sends funds to the user through a Fulfillment contract on Arbitrum One
3. The Fulfillment contract sends a message to the Escrow contract saying “solver X sent Y tokens to user Z at time T”
4. The Escrow contract receives and validates the message from the Fulfillment contract, releasing the user’s funds to the solver on Base

In this example, a message is sent and received in Step 3 and Step 4; depending on the solution, this message may be relayed and verified offchain or sent via a slow message onchain. Instead, an intents system could easily use the Crosschain Broadcaster to store and verify these messages in a transparent, trustless way.

1. User deposits funds into an Escrow contract on Base
2. A solver sends funds to the user through a Fulfillment contract on Arbitrum
3. The Fulfillment contract calls the the Broadcaster contract on Arbitrum and publishes a message saying “solver X sent Y tokens to user Z at time T”
4. Back on Base, the Escrow contract calls the Receiver contract and validates the message in the Broadcaster on Arbitrum One; user funds are then released to the solver

In this case, the Fulfillment contract plugs into the Broadcaster on Arbitrum while the Escrow contract plugs into the Receiver on Base. Messaging pathways like this could be created in any direction using the same standardized set of Broadcaster contracts.

Breaking Down the Core Contracts

Broadcaster Contract

Broadcaster is one of, if not the simplest concept: it’s a contract that stores messages on a particular chain. Any user, called a Publisher, can submit a bytes32 message. After verifying it hasn’t seen the same message from that user before, the contract stores the message in its own storage slot. As soon as the message is stored in the Broadcaster, it has been “broadcast”.

When another chain wants to check if a given message was indeed broadcast, it just has to read that slot in the Broadcaster’s storage on the home chain and confirm the metadata.

BlockHashProver Contracts

To figure out the state of a remote chain, one must verify its block hashes. However, each rollup might store finalized block hashes using different methods. The job of a BlockHashProver is to get block hashes of a target chain from its home chain. It can accomplish this with two functions:

• getTargetBlockHash(…): when called on its home chain, it directly fetches the final block hash of its target chain from that chain’s state
• verifyTargetBlockHash(…): when called on a non-home chain, it uses a storage proof to check that a given homeBlockHash implies a specific targetBlockHash

A BlockHashProver effectively creates a one-way link between two chains. BlockHashProvers can also be daisy chained together across L2s and L3s, enabling robust routing between rollups.

BlockHashProverPointer Contracts

Because rollups are upgradeable, the hardcoded methods in a BlockHashProver may break if rollups change where they store block hashes. A BlockHashProverPointer can solve this by:

• storing the code hash of the current, correct BlockHashProver for a chain pair (i.e. home chain, target chain)
• updating the Pointer to a new version of the BlockHashProver that incorporates the rollup changes

The BlockHashProverPointer contract simply holds the code hash of the real BlockHashProver. That way, references to the Pointer address remain stable even if the underlying Prover changes. It is the responsibility of the chain owner to maintain the BlockHashProverPointers on their chain.

Receiver Contract

The Receiver contract on a local chain is responsible for verifying that a Broadcaster contract on a remote chain truly contains a message. To do so, it takes the following steps:

1. The user provides a list of Pointer addresses (i.e. the “route”) that leads from the local chain back to the remote chain in question along with the corresponding storage proofs
2. The Receiver contract calls or references each Pointer in turn, using the Provers they point to to verify block hashes hop-by-hop until it obtains the final block hash of the remote chain
3. Armed with that final block hash, the Receiver checks a proof that the remote Broadcaster’s storage slot indeed holds the user’s message

If all is well, the Receiver returns a confirmation along with the original broadcast timestamp.

Routes and IDs

Because every chain can reference many others, there must be a standardized way to identify which chain is being read from. The Crosschain Broadcaster Standard accomplishes this via a route-based “accumulator” method:

• Suppose you have a route: [PointerA, PointerB, PointerC]. At each hop, the local chain references that Pointer’s code to read or verify the next block hash.
• If the actual account you want to prove is address D, the combined remoteAccountId is keccak256(keccak256(keccak256(keccak256(0,A),B),C),D).
• This method guarantees a unique ID for any contract address given the exact route taken to get there.

So if different routes exist that eventually point to the same chain, that’s fine: they just produce different IDs. But from the local chain’s perspective, each route is an unambiguous path to verifying message data.

Conclusion

As the Ethereum ecosystem grows, so does the need for reliable, trustless Crosschain communication. The Crosschain Broadcaster Standard is a potential stepping stone towards that goal:

• It defines a simple interface for broadcasting 32-byte messages on any rollup chain
• It provides a universal way to verify those messages on chains with a common ancestor
• It is built around storage proofs rather than external relays, eliminating trust assumptions
• It provides forward-looking flexibility for rollups that are expected to evolve

These properties also align with Arbitrum’s vision for interoperability, which prioritizes interoperability building blocks that are:

1. Trustless: Crosschain communication should not introduce any new trust assumptions, or it risks undermining the core value proposition of blockchains today.
2. Cheap: Crosschain communication should not result in high fees that restrict accessibility.
3. Fast: Crosschain communication should occur much faster than L1 finality to help ensure practical functionality.
4. Accessible: Interoperability should be a feature available to everybody. Developers should have a clear path toward enabling Crosschain communication, with no vendor lock-in, politics, or boundaries.

While Broadcaster meets the criteria for trustless, cheap, and accessible, it is worth noting that the speed is limited by the finality of chains in a given route. If the Ethereum L1 anchors a route, then it cannot be faster than L1 finality; however, if an L2 anchors a route between L3s, then it can be faster than L1 finality. The latter is especially relevant for the Universal Intent Engine vision, which seeks to enable crosschain swaps and transfers for all Arbitrum chains (L2s and L3s) and EVM chains more broadly. For example, a full intents stack could enable fast fulfillment for end users while using Broadcaster for trustless settlement for solvers.

Whether or not the Crosschain Broadcaster Standard progresses is up to you, the community! If there is sufficient demand, Offchain Labs will set its sights on building out the complete implementation in collaboration with the Ethereum ecosystem. So if you’re looking to build crosschain applications with strong security guarantees, or if you’re just enthusiastic about multi-chain design, share your thoughts on the Eth Magicians post or contribute to the standard directly!

Introducing the Crosschain Broadcaster was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain applications today provide a robust foundation for an onchain economy. It has never been easier for a developer to launch an application or chain while benefiting from Ethereum’s security and composability. But as adoption grows, so do its challenges.

Today, developers and users live in a fragmented blockchain landscape. Applications operate on isolated networks, limiting the ability to interact and transact seamlessly. The dream of a decentralized, global supercomputer is within reach, but only if these networks can operate in harmony. Vitalik’s blog post on scaling highlights this challenge as well, among other emerging focus areas for Ethereum L1. Solving this challenge requires not just innovation but also a commitment to openness and collaboration.

We at Offchain Labs believe that Arbitrum can and will lead the way, and developers will have access to a suite of interoperability solutions in two distinct phases:

1. Intent-Based Interoperability: Targeting the end of Q1, Arbitrum chains will have access to crosschain token transfers and swaps in less than three seconds.
2. Crosschain Operations: Targeting the end of Q3 and pending approval from the Arbitrum DAO, we will enable crosschain operations in a fast, cheap, and trustless manner.

These developments are just a few of several foundational improvements that will unify the Arbitrum ecosystem. By establishing seamless connectivity and liquidity sharing, users and developers will experience Arbitrum chains as a unified whole — a platform where true interoperability is achieved without compromising on security, UX, and the freedom to build anything you want.

While these innovations will elevate the Arbitrum ecosystem, the impact extends far beyond a single network. By making these developments available across all EVM-compatible chains. Offchain Labs is doing more than just improving Arbitrum — we’re weaving a seamless fabric of connectivity throughout the entire Ethereum landscape. This universal approach to interoperability marks a significant step toward a truly unified blockchain ecosystem.

Arbitrum Interoperability

Offchain Labs, the initial builders behind the technology used by Arbitrum, will work closely with the Ethereum Foundation, interoperability protocols, and leading L2s to align with industry standards, research improvements and ensure the broad adoption of these tools and protocols. While interoperability standards are important, we recognize that true interoperability will only come through actual selection and implementation of standards, turning ideas into reality.

Offchain Labs believes that it is crucial for interoperability to maintain several key properties:

1. Trustless: Crosschain communication should not introduce any new trust assumptions, or it risks undermining the core value proposition of blockchains today.
2. Cheap: Crosschain communication should not result in high fees that restrict accessibility.
3. Fast: Crosschain communication should occur much faster than L1 finality to help ensure practical functionality.
4. Accessible: Interoperability should be a feature available to everybody. Developers should have a clear path toward enabling crosschain communication, with no vendor lock-in, politics, or boundaries.

This means Arbitrum’s interoperability modules would provide functionality allowing crosschain communication and chain abstraction without cascading security risks or unspoken tradeoffs.

A Universal Intent Engine

Supporting the vision of a unified Ethereum, at the heart of Arbitrum’s interoperability vision is a universal intents engine. This engine will power crosschain swaps and transfers for all Arbitrum chains and EVM-based chains in less than three seconds, eventually allowing users to initiate complex actions with a single wallet prompt. The components outlined below are just the first step we are taking toward the vision outlined above. As we work to improve on the most critical properties for cross-chain operations — being fast, cheap, and trustless — the engine’s core components will change.

Intents are a rapidly growing connective layer well-suited for the multi-chain world. By allowing users to express crosschain intentions for their assets, solvers can compete to find the most cost and time-efficient path to the desired state. Users and apps get their assets fast while handing off the complexities of routing and chain management. Many different teams have laid the groundwork to make intents possible today.

The technology layer that powers intents is still nascent, and we plan to deliver upgrades on the protocol and application layer to improve trust, cost, and UX. Our initial intents engine consists of four components:

• Message Standard: All Arbitrum chains will be able to adopt a standardized message format for intents. Several standards show promise, including ERC-7683, 7786, and 7841. Note that these are not mutually exclusive and the combination of these standards can offer a powerful experience. Standardizing the message layer will reduce friction for solvers and intent solutions.
• Broadcast Standard: All Arbitrum chains will have standard contracts that ensure trustless communication, guaranteeing a secure message-passing connection between Arbitrum chains and the broader EVM ecosystem.
• Fast Settlement: Arbitrum chains will have access to various fast settlement solutions, including the already live Fast Withdrawals, third party fast bridges, and an upcoming native ZK integration. A shorter settlement time lowers the capital requirements for solvers and fast bridges to rebalance funds, meaning savings can be passed on as reduced user fees.
• Intent Dissemination Feed: Arbitrum chains and applications will have access to a universal feed to publish users’ intents. Initially, this component will depend on third parties, but Offchain Labs is exploring trustless solutions that seamlessly integrate with all available setups. This will allow users, developers, and solvers to have a frictionless experience in crosschain transfers and swaps.

Wen Interop?

Arbitrum’s Universal Intents Engine will launch in Q1 on an initial set of chains, making seamless cross-chain asset transfer a reality. This rollout will expand to encompass all chains and key applications on Arbitrum One, enabling secure, fast, and efficient intent execution ecosystem-wide. Offchain Labs is collaborating with other L2s and interoperability protocols in an EF working group to develop smart contracts that comply with ERC-7683.

To ensure a smooth expansion to new chains, The Arbitrum Foundation has confirmed that it will run a Solver Loan Program (SLP). The SLP will provide the capital to solvers willing to support intents across the Arbitrum ecosystem. The SLP will begin by bootstrapping ETH and USDC routes between chains, with plans to expand to additional tokens later in the year. Through this program, Arbitrum chains can also loan their own funds to establish routes for their custom gas and governance tokens.

On Our Radar

• Fast Settlement Solutions: Expanding on the live Fast Withdrawals feature, additional solutions, including a native ZK integration and support for 3rd-party pre-confirmation products, are being developed to accelerate settlement, pre-confirmation and optionality for chains.
• Developer Tooling: Expansion of the intent design space, including the enablement of complex interactions beyond simple transfers and swaps.
• Crosschain Standards: Establishing compatibility with widely accepted EVM standards, including ERC-7683, ERC-7785 and ERC-7828, to help ensure seamless interoperability across chains.
• Refining the UX: Exploring EIP-7702 and account abstraction to offer single-signature crosschain transactions.

By combining immediate advancements with long-term innovation, Arbitrum is delivering a cohesive and forward-looking ecosystem for users and developers alike. Offchain Labs is committed to continuously refining the intents stack — in tandem with many ecosystem partners — so that fast, trustless, cheap interoperability is available to all.

The Road Ahead

Through the Universal Intent Engine, the Arbitrum ecosystem will have access to crosschain token transfers and swaps in less than three seconds, but such improvements can’t stop there. Offchain Labs is committed to making crosschain operations better. Developers should expect to hear more about these plans soon.

Through these primitives, developers will have access to a comprehensive interoperability suite, enabling them to build applications that interact across chains without compromising security, decentralization, or speed. Users stand to benefit the most, where any action will be just one wallet prompt away. Upon completion and DAO approval of the interoperability suite, a user will gain access to any chain(s) of their choice, regardless of where their assets are.

Users will have access to any EVM chain or application on Arbitrum.

A unified Ethereum would not be possible without the contributions of others, including L2s, the EF, Espresso, Uniswap, Across, LayerZero, Chainlink, Polymer Labs, Open Zeppelin, Caldera, Reservoir, Li.Fi, Everclear, and many more. If you are building interoperability solutions or standards, we invite you to join us in shaping the next iteration of both Arbitrum and Ethereum. Together, we can make a trustless, decentralized future a reality.

If you are in the Arbitrum ecosystem and want to enable interoperability today, please refer to this document for more technical details.

Bringing Interoperability to Arbitrum and Ethereum was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Offchain Lab’s partner studio and venture capital arm, Tandem, has invested in Camelot, an Arbitrum native decentralized exchange (DEX), solidifying its position as a native DEX in the Arbitrum ecosystem.

Originally launched without VC funding and entirely bootstrapped by the Arbitrum community, Camelot has become the largest protocol exclusively native to Arbitrum, exemplifying the strength and potential of community-driven development.

Iron Boots, a cofounder of Camelot, said that when DeFi first gained traction, a lot of the relationships built around it were short-term and yield-focused. Camelot, however, took a different approach.

“One of the key aspects of our vision has always been to build long-term relationships. It’s not just about the rewards we exchange; it’s about working together to create something for the future,” Iron Boots said.

From its inception, Camelot has been driven by a clear mission: to foster innovation, collaboration, and sustainable growth within a thriving blockchain ecosystem. This vision led the team to focus exclusively on building a decentralized exchange tailored to the unique needs of Arbitrum.

For the first six months from its inception, Camelot spent time and resources to convince users to join Arbitrum, this was because Camelot recognized Arbitrum as a network beyond its technical capabilities, offering an organic and vibrant ecosystem for developers and projects. The team also aligned with Arbitrum’s core mission of making blockchain more scalable and secure for everyone.

This fundamental alignment of values between Camelot and Arbitrum served as a cornerstone for the DEX’s approach. Rather than chasing short-term gains, Camelot prioritized structuring itself to fully commit to long-term, sustainable goals.

“Camelot has become a cornerstone of the Arbitrum ecosystem, providing a robust decentralized exchange and a hub for innovation and collaboration. Their commitment to supporting builders, fostering community growth, and aligning with Arbitrum’s vision has played a critical role in the network’s success,” A.J. Warner, Chief Strategy Officer at Offchain Labs said. “Camelot’s presence strengthens our ecosystem, and their focus on sustainability and long-term value creation continues to drive meaningful progress for all participants.”

Today, Camelot is not only a liquidity hub on Arbitrum but also a launchpad for new projects and a community-driven platform for builders. The DEX has over 75 partners and $46 billion in volume traded, generating over $48 million from fees and a TVL of $120 million. Additionally, Camelot was one of the first protocols to expand beyond Arbitrum One and Nova and has now been deployed on over 14 different Arbitrum chains.

Tandem’s investment in Camelot highlights Offchain Labs’ confidence in its mission and potential. “We are committed to supporting projects that push the boundaries of what’s possible in DeFi. Camelot’s approach to creating sustainable, community-driven solutions in the Arbitrum ecosystem made it a natural fit for our portfolio,” Ira Auerbach, Head of Tandem, said.

As Arbitrum expands, Camelot will be at the forefront. Although initially focused on Arbitrum One, Camelot now extends its reach to other Arbitrum chains. This shift has broadened Camelot’s role in the Arbitrum ecosystem, becoming a unifying force for liquidity across various networks.

“It’s not just about building technical bridges between chains; it’s about making all these different chains feel like an integral part of Arbitrum. A key part of our vision moving forward is figuring out how to create a cohesive and aligned ecosystem across all of them,” Iron Boots said.

Tandem by OCL Invests in Camelot, the Largest Native DEX on Arbitrum was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Offchain Labs is committed to building and innovating in ways that will enhance scalability, performance, and usability across the Arbitrum ecosystem. Over the past year, we have been carefully listening to the ecosystem’s feedback on the value of natively enabling vertical scaling and throughput capability increases.

As detailed in our latest technical roadmap, Offchain Labs’ recent focus has been bringing exciting, value-differentiating technologies, such as BoLD, Stylus, and Timeboost, to life. However, we wanted to assure the community that we are also actively working towards relieving throughput constraints and scaling to meet the demand for EVM blockspace through vertical scaling.

Future-oriented scalability: A focus on alt-clients and beyond

Nitro, the tech stack that powers all Arbitrum chains today, is engineered to be opinionated and purpose-driven. It is explicitly tailored to meet the needs of Layer-2 solutions. Nitro’s architecture is intentionally designed to allow for faster blocktimes, cheaper transactions and a more efficient EVM. This enables the unique customizations Orbit teams are making today and is the reason why Offchain Labs was able to ship Arbitrum with fraud proofs on day one.

At present, hardware and software optimizations enable blockchains to handle high transaction volumes with speed and reliability. But as Layer 2 (L2) demands evolve, our engineering approach is evolving right along with them. Offchain Labs is now in the process of testing the reorientation of Nitro’s development to support alt-client solutions — as stated in the technical roadmap.

Our objective in this work is straightforward: Alt-client development will be a top priority for 2025 as Offchain Labs continues to contribute to the expansion of Arbitrum’s capacity and capability to support the growing ecosystem of projects. We are excited to work with client teams to build the path for an ultra-high-throughput future for Arbitrum chains.

Currently, the Offchain Labs engineering team is evaluating Reth, Erigon, and Nethermind as alt clients — in parallel with Geth optimizations and improvements. Although we are still in the early stages of this process, we intend to keep the following objectives in mind:

• Performance improvement (i.e., throughput increases)
• Customizability opportunities
• Reduced node operating costs
• Alignment with the broader Ethereum ecosystem
• Enhance ecosystem security and client diversity

From what we have gathered so far, our engineering team is leaning towards a Reth implementation, but we are approaching this decision with careful due diligence to determine what is the optimal long-term choice.

Erigon remains an appealing option, particularly as a more accessible solution for immediate archive node optimizations. If our evaluations show that Reth is the right path forward, we will share the data and reasoning behind our decisions transparently.

Meanwhile, we have reviewed publicly published benchmarks from the Nethermind team showing that their client is highly performant.

This update reflects Offchain Labs’ intent to stay agile, adaptable, and future-ready. Whether through Reth, Erigon, Nethermind or a combination, we are committed to creating solutions that can enhance Arbitrum’s throughput and efficiency and aligning with Ethereum’s evolution. As always, we will keep the ecosystem informed and engaged as we continue this journey.

High throughput scaling: today and tomorrow was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

A recently published research paper, whose authors include Akaki Mamageishvili and Ed Felten from Offchain Labs, as well as Robin Fritsch, Maria Inês Silva, and Benjamin Livshits, explores the idea of auctioning off a time advantage for transaction inclusion on Layer 2 (L2s) Ethereum scaling solutions and examines the potential profitability of the arbitrage strategy, compared to other types of transaction ordering policies.

Investigative methodology, simplified

The research paper outlines and compares the potential advantages through arbitrage for a profit-seeking, rational actor using a time-advantage transaction ordering policy with other transaction ordering policies. The authors analyzed the following scenarios in terms of arbitrage:

1. First Come, First Serve (FCFS)

In the first scenario, the FCFS analysis refers to taking an arbitrage opportunity as soon as it appears and calculating total profits. This means that no user has any information advantage outside the market. Users cannot pay a premium for faster inclusion. Instead, users who value fast transaction inclusion are motivated to invest in latency infrastructure to improve their latency to the sequence.

2. Priority Gas Auction (PGA)

In this second scenario, transactions are bundled into blocks created at regular intervals. Traders will compete to be first or earlier in the queue through what is called a Priority Gas Auction or PGA, where traders will add a monetary tip to the block builder, which inflates the amount the traders are willing to pay to get earlier access to the opportunities with “optimal times” within a block. This setup reduces the advantage of fast transaction submissions. Whichever trader offers to pay the highest tip will have a higher likelihood that their transaction will be processed earlier in the block, potentially allowing them to capture arbitrage profit before others.

3. First Come, First Serve (FCFS) with a time advantage actor

In the third scenario, users can place bids ahead of time to gain priority in transaction ordering for a specific period in the future. It is assumed that these users who bid for the fast pass also use a “smart chart” (referred to as dynamic programming) to determine the best moment to execute a trade based on how long the arbitrage opportunity has existed. This smart chart can also tell how much profit is left and how much profit can potentially be made based on current price and time differences. The research paper suggests that the favorable strategy would be to delay trade execution up to the purchased time advantage.

The researchers then ran simulations to see how much profit searchers could make under these three market conditions.

Findings

The research paper shows that the type of transaction ordering policy can influence arbitrage profits. Based on the simulated results, FCFS, with a time advantage, shows favorable results over other transaction ordering policies (from the searcher’s perspective). For a detailed breakdown of the findings, please refer to the research paper.

Breakdown of Research Paper Findings

The research paper suggests that the transaction ordering policy will significantly impact certain MEV extraction operations onchain:

1. The design of transaction sequencing mechanisms significantly affects how arbitrage profits are distributed among participants. According to the research paper, a favorable strategy for time-advantaged arbitrageurs is to delay their trades as long as possible within their time window to maximize profits.
2. An area of ongoing research is how AMM pools can retain and recapture MEV, alongside any downstream effects and implications. Various strategies exist for applications to capture and retain MEV under time-advantaged transaction ordering policies. One approach involves labeling the time-advantaged arbitrageur, allowing AMMs to apply different fees, adjust the market-making function, and even limit the number of transactions the arbitrager can send per interval. This results in a sequential game where the AMM seeks to capture the MEV, and the arbitrageur maximizes their returns. In equilibrium, the paper suggests that if AMM pools attempt to recapture/retain MEV, then the AMM can expect to retain at least 25% of the maximum arbitrage profits while the time-advantaged arbitrager will retain 50%, leaving the remaining 25% unrealized for potential capture.
3. As the research paper shows, FCFS, with Time Advantage, can generate the highest potential profits compared to FCFS (Scenario 1) and PGA (Scenario 2). This is especially true for high-volatility, highly liquid traded pairs like ETH-USDT. The simulation analyzed an ETH-USDT pair in a liquidity pool with $100 million of active liquidity and a 0.05% fee and saw that FCFS with Time Advantage generated profits that were 47.7% more than those of PGA and 86.77% more than FCFS. These figures represent the average minute-by-minute arbitrage profits from CEX-DEX arbitrage, based on data from March 2024, assuming that arbitrageurs are using the FCFS with Time Advantage strategy and the advantage is 200ms (which is the nominal delay proposed in Timeboost.)
4. Negative autocorrelation in price movements can favor FCFS over FCFS with Time Advantage since immediate exploitation of price reversals is beneficial. In the specific simulation mentioned in the research paper (with $100M in active liquidity, 50ms autocorrelation delays, and a constant product AMM), higher negative autocorrelation supposedly leads to greater profits for FCFS arbitrage than FCFS with Time Advantage (FCFS yields 12.79% more). However, FCFS arbitrage and FCFS with Time Advantage remain more profitable than PGA in these conditions, with FCFS with Time Advantage outperforming PGA by 3.67%. Higher profits are associated with more volatile trading pairs (e.g., ETH-USDT) and lower fee pools. In contrast, pairs with lower volatility or higher fees yield less profit under FCFS.

Transaction Ordering Policy Impacts on Arbitrage was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

Timeboost is a transaction ordering policy protocol designed for Arbitrum chains, which allows anyone to bid for the right to have their transactions sequenced faster than other transactions.

When it comes to Layer 2 scaling, various moving parts work together to help ensure that transactions are cheap, can be confirmed quickly, and remain secure from harmful forms of Maximum Extractable Value (MEV) while avoiding reorganization after confirmation. While some forms of MEV can negatively impact users, other types of MEV can contribute to market efficiency, generating profits without necessarily harming regular users.

For example, MEV can help ensure that token prices across DEXes accurately reflect market demand and allow validators to execute rapid liquidations, helping ensure that lenders are repaid when a borrower’s collateral falls below the required ratio. Though not the case for Arbitrum, on some blockchains, such as mainnet Ethereum, block producers that follow a block-building methodology can maximize their profits through MEV by ordering transactions based on the highest gas prices.

A key component of the Arbitrum transaction lifecycle is the sequencer. In most L2 solutions, the sequencer is responsible for aggregating incoming transactions and batching transactions offchain before posting the compressed version of the data to an immutable parent chain like Ethereum. This process is crucial for increasing transaction speed and reducing costs because the L2 can rely on the parent chain’s immutability for security.

On Arbitrum today, the sequencer applies a First-Come, First-Serve (FCFS) policy for transactions in a block. This policy is unique to Arbitrum and was an intentional design choice made by the original developers behind the technology: Offchain Labs. FCFS enables fast blocktimes of up to 100ms and protects users from harmful types of MEV. This method is currently the default for all Arbitrum chains, with Arbitrum One and Arbitrum Nova operating at 250ms block times.

On the flip side, FCFS can lead to latency races, where arbitrageurs spam the sequencer to get their transactions in as soon as possible. This is because opportunistic traders, or “MEV Searchers,” want to be first in a transaction to execute a liquidation opportunity or make an arbitrage profit across exchanges. These latency races place stress on chain infrastructure, contributing to congestion and incentivizing searchers to invest wastefully in hardware.

A proposed solution to this issue is “Priority Gas Auctions,” which will allow entities to bid against one another through gas fees and re-prioritize the order of their transactions. However, this approach can expose Arbitrum users to harmful types of MEV. This is because allowing entities to control transaction ordering opens the door for exploitation, as it provides opportunities to manipulate the sequence for unfair gains. Additionally, it will slow down block production times, as allowing users to reorder transactions fully will be more time-consuming compared to the current FCFS method. This extra step will negatively impact the amazing UX that Arbitrum chains are known for.

Timeboost, however, is intentionally designed to be different. The tool preserves fast block times, reduces spamming on the network, and allows MEV protection to remain on-chain while allowing the chain owner to capture MEV.

What is Timeboost, and how does it work?

Timeboost is designed to balance the various complex tradeoffs, such as speed, security, and decentralization, in the MEV space. It retains the benefits of FCFS and simultaneously reduces network spam.

With Timeboost incorporated, users will be offered two different ways to submit a transaction to the sequencer. One will be the normal path transaction (unchanged from today), and the other path will be to submit transactions to a special “Express Lane” endpoint on the sequencer. Control over the Express Lane is determined by an auction using a smartcontract alongside an autonomous auctioneer.

The autonomous auctioneer is a piece of software that runs in isolation from the sequencer. It operates by receiving bids, validating the legitimacy of the bids, then sorting the bids into descending order before calling an endpoint on the sequencer to resolve the auction using the on-chain auction contract.

Once an auction is won, the winning bidder can take control of the “Express Lane” for a time advantage of 200ms. Transactions signed by the express lane controller will be sequenced as soon as the sequencer receives and verifies their transaction. The bid itself is not designed to determine whether or not the transaction should be included in the block; rather, it is designed to determine who will control the Express Lane for an upcoming round.

The express lane controller will have the sole right to control the Express Lane for one minute — including transferring those rights and signing transactions for others to gain the time advantage afforded to those who wish to use the Express Lane. Although transactions signed by the Express Lane controller will have a head start, the Express Lane controller does not have the right to re-order transactions, nor will the sequencer guarantee that their transactions will always be first in a block. This is similar to buying concert tickets for a famous artist. For example, having a slight time advantage over others does not guarantee that you will be able to purchase the ticket. A similar analogy could be made for competing in a sports race. You and other competitors are all participating in the same race. After you win a bid, only you will have 200ms subtracted from your finish time. Only one athlete will win the race, but this “200ms advantage” does not guarantee that you will be the athlete who always wins.

The Arbitrum DAO will vote on whether or not to collect Timeboost auction bids in ETH and impose a “speed bump” of 200ms on non-Express Lane transactions. The exact setup is subject to change based on the Arbitrum DAO’s decisions. It is important to note that Timeboost’s design allows for bids to be made using any ERC20 token and at any minimum.

Who is Timeboost made for?

For the majority of users, transactions will be submitted through the normal path. Express Lane transactions will likely only be used by a handful of sophisticated actors. These include:

• On-chain traders — The primary goal of these traders would be to make a profit from onchain financial activities and
• Sophisticated MEV actors — These sophisticated actors may or may not have specific hardware and software designed to execute these trades.

Private bids are submitted to the autonomous auctioneer up until the auction closing time, which is set to 15 seconds before the start of the next round. Once the deadline for bid submission has elapsed, the autonomous auctioneer will automatically sort the bids and submit the top 2 highest bids on-chain to the auction contract to determine the winner. The highest bidder will pay the second-highest bid amount and will be declared as the Express Lane controller for the upcoming round.

Traders and searchers will not be the only ones who benefit from Timeboost.

Orbit chain owners will also be able to adopt the technology at their own discretion.

If Orbit chain owners choose to implement Timeboost, they can use Timeboost to generate potential revenue from express lane bids, add utility to their token, and reduce spam. This is because sophisticated actors and searches can choose to spend their resources on buying rights for the Express Lane rather than allocating them to winning latency races that congest and spam the network.

What’s Next?

There are various ways in which Timeboost can be implemented, and the team at Offchain Labs is currently exploring the different specifications for each of these setups:

• Centralized sequencer: This spec exists, and engineering is underway. This is also known as centralized Timeboost.
• Decentralized sequencer: This spec was recently published with Espresso. This is called Decentralized Timeboost, where the “decentralized” part refers to the sequencer.

For the time being, if Timeboost is approved to be implemented, it will first be available for a centralized sequencer setup. Engineering for the centralized sequencer is currently well underway and publicly available for review, and implementation subject to DAO’s approval on Arbitrum One and Nova.

As mentioned above, Offchain Labs is working closely with Espresso Systems to make Timeboost compatible with decentralized sequencers. Offchain Labs and Espresso Systems recently released the full specification for a Decentralized Timeboost, which researchers, developers, and community members are highly encouraged to review and provide feedback on.

As Timeboost is still in its foundational period, extensive monitoring, analysis, and potential corrective action are required to ensure that the tools are effective in the near term. In addition, Timeboost upgrades are also being explored to ensure its long-term sustainability.

We would love to hear from you if you are interested in assisting Offchain Labs and the Arbitrum ecosystem in building Timeboost and the Timeboost ecosystem. Participants are encouraged to comment on DAO forums, propose alternative design solutions based on our published specifications, and ask questions in forums.

Timeboost for beginners — Offchain Labs’ latest transaction ordering policy protocol was originally published in Offchain Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.