Pectra/Callisto review, Stylus Cache Manager deployment, Timeboost Explanation Guest Post, Interview with Ben (new Arbitrum Devrel!)
Stylus Saturdays, 29th June
Hey everyone! Bayge (Farcaster) here. In this week:
🚀 Pectra + ArbOS 40 overview: Arbitrum’s new upgrade introduced.
🗄️ Deployment of the Cache Manager 💸 Cache Bid for cheaper Stylus: How to deploy the cache bid contract to have cheaper Stylus contracts for your users and more fees!!
⏱️ Timeboost explained (guest post by Erik): An explanation of how it works to entice Stylus developers to make use of it themselves.
We’ve also included an interview with Ben Greenberg from Arbitrum. Ben is stepping into a developer relations role at Arbitrum, which is especially relevant to us builders! He’s especially interested in Stylus, so I encourage you to get in touch if you need anything or just to say hi:
Ben is also the author of Vector Search with Javascript, an introduction to building search systems with AI using JS. Get notified when it releases using this link! I’m really looking forward to this, as this is definitely an area I know mostly nothing about, and looking at this example here (a fully featured Medium clone!) it seems super interesting and relevant to us builders building indexing platforms here in web3.
Read on, and as always, if you have any feedback about the newsletter, you can share it here:
To recap, Stylus is a Arbitrum technology for building smart contracts in Rust, Zig, C, and Go. Stylus lets you build smart contracts that are 10-50x more gas effective than Solidity smart contracts, with a much broader range of expressiveness from these other languages! Contracts can be written with no loss of interopability with Solidity!
Click here to learn more: https://arbitrum.io/stylus
You can get started very quickly at https://stylusup.sh or by reading the official docs at https://docs.arbitrum.io/stylus/gentle-introduction!
Review of Pectra and ArbOS 40 (Callisto)
Pectra is a upgrade to Ethereum that was taken live on the 7th of May. The Arbitrum Callisto upgrade took live the features in Pectra. Orbit chains won’t see upgrades for a while until most Rollup-As-A-Service (RAAS) providers gauge the success of the update. The upgrade includes several changes:
EOA code setting. A new transaction type was added that made it possible to set the code for the sender to set their code. You may have noticed this yourself if you’ve used Lifi and been prompted by Metamask recently to upgrade mid transaction. They’ve done this for the transaction bundling features.
Several precompiles, including several operations on the BLS12-381 curve. This is useful for signature verification, specifically for taking advantage of BLS signatures, ZK SNARKs, and KZG commitments.
A special “history” contract is being made available which contains the last 27 hours of block hashes. In practice, this could be useful for cross-chain messaging, and the creation of stateless clients.
A change is included to not cache non-existent contracts.
The set code EOA feature is really exciting! Being able to take custom signatures for your native transaction account unlocks a huge amount of possibilities for self custody with cold wallets and sending. Allowlists of transactions and custom sends could be supported using browser passkeys among other things without the need for users to move their assets elsewhere.
Imagine a private key that contains the authoritative access to a EOA without restrictions, but then a special key is able to be used that can only send a specific asset. The sky’s the limit! This is especially useful for us Stylus developers where a complicated signature or on-chain evaluation could be supported relatively cheaply compared to the classic EVM.
Owing to the compute advantages of Stylus, when a precompile is added to Ethereum for gas efficiency reasons, we could instead build this functionality without an upgrade using a Stylus contract that we deploy immediately. Indeed, for their Poseidon hashing, OpenZeppelin have been supporting BLS12 already in their crate for Stylus. It’s great being on the bleeding edge, and now Solidity programmers can leverage some of these benefits for themselves:
Deploying the Stylus cache manager to your chain
The Stylus Cache feature keeps Stylus contracts in memory to avoid the computation work of finding and loading the code on your node. We can deploy a permissionless contract frontend with a cache eviction system that lets users bid for the right to have a slot for a time, this is known as the CacheManager contract. This means cheaper contracts and more opportunities for chain owner rent extraction without being to the detriment of end users! Cobuilders are building a frontend for this as a part of their Stylus Sprint grant, and will also be releasing a webapp soon which we’re excited about.
We actually hadn’t done this deployment, as we have a higher release cadence of 9lives features, mostly adding permissioned users right now, and have been lazy to do cache management on our side. We recently took it upon ourselves to do this on our chain Superposition. These are the steps we took:
Grabbed a release of the nitro-contracts repository. We downloaded the latest release of the source from two weeks ago from https://github.com/OffchainLabs/nitro-contracts/releases/tag/v3.1.1
Grabbed the precompiles contracts using what would normally be a submodule, after navigating inside the “precompiles” directory:
cd src
rmdir precompiles
git clone https://github.com/OffchainLabs/nitro-precompile-interfaces precompiles
cd ..
npx hardhat compileI wanted to have the contract deployed, then to ask our RAAS to register the CacheManager contract. So I adjusted the deploymentUtils script to make it skip the stage of registering, so that I can ask our RAAS (Conduit) to do this themselves (this is scripts/deploymentUtils.ts):
310a311,341
> /// add CacheManager to ArbOwner
> const arbOwnerAccount = (
> await ArbOwnerPublic__factory.connect(
> ARB_OWNER_PUBLIC_ADDRESS,
> chainOwnerWallet
> ).getAllChainOwners()
> )[0]
>
> const arbOwnerPrecompile = ArbOwner__factory.connect(
> ARB_OWNER_ADDRESS,
> chainOwnerWallet
> )
> if ((await chainOwnerWallet.provider.getCode(arbOwnerAccount)) === '0x') {
> // arb owner is EOA, add cache manager directly
> await (
> await arbOwnerPrecompile.addWasmCacheManager(cacheManagerProxy.address)
> ).wait()
> } else {
> // assume upgrade executor is arb owner
> const upgradeExecutor = new ethers.Contract(
> arbOwnerAccount,
> UpgradeExecutorABI,
> chainOwnerWallet
> )
> const data = arbOwnerPrecompile.interface.encodeFunctionData(
> 'addWasmCacheManager',
> [cacheManagerProxy.address]
> )
> await (await upgradeExecutor.executeCall(ARB_OWNER_ADDRESS, data)).wait()
> }
> For good measure, since we need a Yul-compiled contract, I also grabbed a copy of forge-std in the lib directory, then ran yarn build with the forge arguments:
cd lib
rmdir forge-std
git clone https://github.com/foundry-rs/forge-std
cd ..
yarn build:forgeThis let us trigger the deployment (note that my shell doesn’t require the use of the export statement for environment variables to be available to child processes):
b % CUSTOM_CHAINID=55244
b % CHILD_CHAIN_RPC=https://rpc.superposition.so
b % CHAIN_OWNER_PRIVKEY=0xprivatekey
b % npx hardhat run --network custom src/chain/CacheManager.solAt which point, it was made available on Superposition chain at:
b % npx hardhat run --network custom scripts/local-deployment/deployCacheManager.ts
* New CacheManager created at address: 0x3d2898D2a40a9b23Da4733cb08d4FdE837E6eA3f
* New ProxyAdmin created at address: 0xd3662d66C486ef5392654C056EEe4728c2f0b21E
* New TransparentUpgradeableProxy created at address: 0xe3092C5d44BcB222B458d9212E608E0e8fE37591 0x3d2898D2a40a9b23Da4733cb08d4FdE837E6eA3f 0xd3662d66C486ef5392654C056EEe4728c2f0b21E 0xI wanted to verify our newly made contracts. I disabled sourcify in hardhat config by setting its flag to false, set the following:
b % CUSTOM_RPC_URL=https://rpc.superposition.so
b % CUSTOM_ETHERSCAN_API_URL=https://explorer.superposition.so/api
b % CUSTOM_ETHERSCAN_BROWSER_URL=https://explorer.superposition.so
b % npx hardhat verify --network custom 0x3d2898D2a40a9b23Da4733cb08d4FdE837E6eA3fWhich verified everything for me. Now, you would need your chain owner/rollup provider to execute:
cast send 0x0000000000000000000000000000000000000070 'addWasmCacheManager(address)' <your cachemanager contract here>This contract will act as a frontend for the cache management system, letting you extract fees from users trying to reduce costs for their contracts!
Guest post: Timeboost broken down
I’m excited to feature Erik from Superposition for a guest post on Timeboost! Timeboost is a new transaction ordering layer in Arbitrum that extracts extra value for the DAO by providing a short window for MEV extractors to have priority transaction sequencing. He’s written an introduction and piece below!
While Timeboost is not explicitly related to Stylus, I feel it’s important to understand as it forms a part of the broader Arbitrum execution environment and ecosystem. As dApps become more complex, the opportunities for MEV increase.
Blockchains are collectively missing out on and losing billions of revenue every year due to Maximal Extractable Value (MEV). What if they could capture some of this value and redistribute it back to its applications and users, while also protecting them from harmful MEV? This is what Arbitrum is setting out to do with Timeboost, their novel transaction ordering policy that has just been adopted.
Introduction
Since its launch, Arbitrum has been using a First-Come, First-Serve (FCFS) transaction ordering policy, meaning that transactions are processed in the order that the Sequencer receives them.
Since there is no priority fee or way to get a transaction into a block and included in the blockchain history before everyone else, a transaction submitter seeking short-term opportunities (in regular parlance, a “searcher”) must reduce latency and invest their resources in infrastructure. This infrastructure must be located in a way that has fast and reliable access to the Arbitrum sequencer.
Due to this design, FCFS already protects against harmful MEV, as there is no public mempool (memory pool, where transactions are held before being committed to the blockchain) on Arbitrum that would allow searchers to view, reorder incoming transactions, or be the first in a block. This has the benefit of excluding toxic order flow (a type of orderflow that ..) such as frontrunning and sandwich attacks. However, the chain itself is still missing out on rent extraction from searchers, as they spam the network to win the latency races against other searchers, leading to congestion.
Timeboost offers a solution to this, allowing searchers to bid for faster transaction inclusion in the sequencer through an offchain auction. It gives them the option to access an “express lane”, with the chain offering (non-toxic) MEV-as-a-Service for arbitrage, backrunning and liquidation opportunities. If you want to be first, you have the option to pay a fee to the chain owners. It replaces the existing First-Come, First-Served system with an extra layer:
This is beneficial to both parties, as the chain is able to extract rent it otherwise would’ve missed out on, and it reduces congestion and spam on the network. Searchers won’t have to invest their resources in infrastructure to reduce latency, as they can instead purchase the rights for the express lane through a simpler UX. Timeboost preserves the many benefits of FCFS like fast block times and protection from harmful MEV, all while avoiding the latency competition and allowing chains to capture more value, effectively addressing FCFS limitations.
How does it work?
Centralised timeboost is used by a single sequencer of an Arbitrum chain. Decentralised timeboost for multiple sequencers is still currently being developed by Offchain Labs in collaboration with Espresso Systems, and we won’t highlight it here further.
Timeboost is mainly introducing three new components to Arbitrum chains:
An express lane for the sequencer, an offchain auction to determine the controller of the express lane, and an auction contract to choose the winner of the auction and collect the proceeds.
The express lane is a special endpoint on the sequencer on which transactions will be immediately sequenced whenever they have been submitted.
They need to be signed by the express lane controller, which is an address set by the auction contract as the winner of the previous off-chain auction. “Normal” Transactions that don’t get signed by the express lane controller will be sent to the sequencer with a 200 ms delay on their arrival timestamp. This gives the controller of the express lane a time advantage, but it does not guarantee that their transactions will always be first.
All sequencer transactions are sorted into a single stream of transactions for node operators to post to the data availability layer and it is for controllers and searchers to estimate the MEV they can extract and if they can secure a profit on their bid. This creates an interesting economy for bidders, as they can use it for their own MEV opportunities and extract rent from searchers on MEV that they did not predict as controllers of the express lane by reselling transaction slots.
The Timeboost auction happens offchain. Each auction round has a duration of 60 seconds to determine the express lane controller for the next round. The auction is sealed-bid and second price, which means that bids are proposed privately and the winning bidder pays the amount of the second highest bid instead of their own bid.
This is also known as a Vickrey Auction and it incentivises participants to bid their true value without strategic over or underbidding. Participants can bid with any ERC-20 token, with any minimum amount, and the bid can be collected by any address. They interact with an offchain autonomous auctioneer, who accepts and rejects the bids. The bidding period lasts for 45 seconds, with the remaining 15 seconds being used by the auctioneer to verify bids, sort them into descending order, choose the 2 highest bids, determine a winner and make a call to the on-chain auction contract to resolve the auction.
The on-chain auction contract takes the deposits for bids and sets a minimum bid value, which can be changed by the chain owner. It also resolves the auction by taking the information it receives from the autonomous auctioneer in the off-chain bidding stage, deducting the 2nd highest bid from the account of the winning bidder and transferring it to the beneficiary account. The contract then sets the address of the express lane controller for the next round, giving that address the privilege to sign transactions to be included in the express lane for the next 60 seconds. If there is no express lane controller for the next round, the transaction ordering policy will fall back to FCFS.
The parameters that can be configured by the chain owner include the round duration, the auction closing time, the beneficiary of the bids, the bidding token, the delay for non-express transactions and the minimum bid amount.
With Timeboost enabled, the default block time on Arbitrum One and Nova is still 250 ms and can be adjusted to 100 ms. Because of this, regular users will experience a latency of 450 ms for their transactions to be sequenced and included in a block. It is entirely optional to enable Timeboost for chain owners, as it will also be available to Arbitrum Orbit Chains.
Opportunities for Arbitrum
Timeboost went live on Arbitrum Mainnet on the 17th of April.
During the governance vote, there was a choice to collect winning bids either in ETH or in ARB and to burn the tokens. The DAO voted to collect fees in ETH and send them to the DAO treasury for later use. This has proven successful: In the first month alone, it generated over 300 WETH in revenue for the Arbitrum DAO1. On most days, it is already driving over 50% of the network revenue, bringing the DAO closer to profitability. The long term effects of Timeboost remain to be seen, as it is still early days and it needs to be adopted by all searchers and traders on the chain.
There is the potential issue about a single entity monopolizing the express lane and depriving smaller arbitrageurs from MEV opportunities, which could lead to these smaller searchers leaving Arbitrum. There are no indications that this will happen at the moment though and it’s not very different from FCFS hardware latency races. The DAO is consistently monitoring and analysing the effects that different parameters have on the system, but so far Timeboost seems very promising to drive a huge portion of the future revenue of the chain.
For some more reading on Timeboost, we recommend the articles written by the OCL team attached to this footnote.2
Interview with Ben
Who are you, and what do you do?
I'm Ben, and I am a Senior Developer Relations Engineer at Arbitrum. I have been working in DevRel for the past seven years across both web2 and web3. My path into tech was not typical. Before I became a software developer, I spent nearly a decade working as a community organizer and educator.
My journey into web3 began where all web3 journeys begin, in a bar on the east side of Berlin, where a friend and I spent hours discussing trustless systems and how we could build a better digital common. The ethos of web3 reminded me of the early days of the internet in the late 90s and early 2000s, when people came first and data belonged to the user.
Since joining Arbitrum, I have been focused on building clear paths for developers to enter the ecosystem and for existing developers to level up. I have created workshops and talks, and we are getting ready to launch an incredible new global initiative to expand this work. DevRel sits where systems meet people, and I am grateful to be in that space.
What web3 ecosystems have you worked in?
I got started in web3 as the Lead Developer Relations Engineer at Parity, the team behind Polkadot. That introduced me to an engineering-first community with great tooling and infrastructure. During my time there, I attended the Polkadot Blockchain Academy in Buenos Aires and graduated from the second cohort. We built a blockchain in Rust from scratch, studied game theory and economic principles, and explored cryptography in depth.
Since then, I have worked in both web2 and a small Ethereum-aligned rollup project. I joined Arbitrum because I have not seen another ecosystem so well suited for builders. Stylus lets developers write smart contracts using production-grade languages like Rust, without needing to adopt niche domain-specific languages or overly complex tech stacks. Developers can show up with an idea and begin building quickly, without needing to reshape their thinking just to get something running.
What are your impressions of working with Stylus, good and bad?
Stylus was the first thing that got me excited about Arbitrum. As a backend engineer, being able to write smart contracts in standard, battle-tested languages like Rust is amazing. You get the benefit of mature tooling, and it opens the door to better thinking around performance, memory management, and interoperability.
That said, Stylus is still early in its lifecycle. The Rust SDK has not reached a major 1.0 release yet, and that means occasional breaking changes and some small rough edges. Across the entire ecosystem, including within the Foundation's DevRel team, teams are working hard on creating better examples and onboarding tools for both Rust newcomers and experienced developers. These improvements will make it much easier for more people to build and ship with confidence.
What software do you use?
I keep things pretty simple. Most of my coding happens in VS Code. For vibe coding sessions, I use Windsurf. A few months ago I switched my terminal to Warp, and I have not looked back. I appreciate that it supports agentic workflows while still keeping a person in control of the process. I am not quite ready to hand everything over to AI, even though I have a book coming out in two weeks on AI and vector search: https://www.vectorsearchbook.com!
For visual content, I use Mermaid for flowcharts and Napkin for quick diagrams. I build all my workshops in GitHub Codespaces using fully containerized environments, which means attendees can get started quickly with almost no setup.
What hardware do you use?
My main machine is a MacBook Air M4. It is more than powerful enough for everything I need, including compiling Rust projects. At home, I plug into a setup that includes one vertical monitor, a widescreen monitor, and an Elgato teleprompter display that I use for video calls and recordings. I use a Keychron keyboard and an Elgato mic for audio.
I also keep a Stream Deck on my desk to switch between apps, control my lighting, and trigger various shortcuts during demos and recordings.
How can people get in touch with you?
The easiest way is through my site, hummusonrails.com, which has links to all the platforms I use. I am also @hummusonrails on most social platforms, including X and Farcaster.
People usually reach out if they are building on Arbitrum, working with Stylus, or exploring new developer education ideas. I am always happy to chat with anyone building interesting things.
What's a piece of advice you'd give someone new to web3?
Learn how to read error messages. It sounds basic, but it's one of the most valuable skills you can develop in web3 as a builder. If you're working in Rust, you're already in good hands. Rust has some of the clearest and most helpful error messages of any language. They may be long, but they usually tell you exactly what went wrong, where it happened, and how to fix it.
The key is to start with the first error. Fix it. Then move to the next one. Do not try to solve everything at once. Most of the time, later errors vanish once the root cause is addressed.
Treat each error message like a clue. The language is trying to help you. Let it.
You can get in touch with Ben via any of the links available at his website. Be sure to follow him on X and via Farcaster! Ben will be in Cannes and Berlin for the next while, so reach out if you want to have a sit-down. You can check out his book here:
Stylus Saturdays is brought to you by… the Arbitrum DAO! With a grant from the Fund the Stylus Sprint program. You can learn more about Arbitrum grants here: https://arbitrum.foundation/grants
Follow me on X: @baygeeth and on Farcaster!
Side note: I develop Superposition, a defi-first chain that pays you to use it. You can check our ecosystem of dapps out at https://superposition.so!
Source: Entropy Advisors Dune Dashboard
https://docs.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction
https://medium.com/offchainlabs/debunking-common-misconceptions-about-timeboost-92d937568494
https://docs.arbitrum.io/how-arbitrum-works/timeboost/gentle-introduction
https://arxiv.org/abs/2306.02179
https://github.com/OffchainLabs/timeboost-design/tree/main
https://medium.com/offchainlabs/debunking-common-misconceptions-about-timeboost-92d937568494
 | A guest post by
|