In this post:

1. 96kb contracts are coming out for the Stylus ecosystem. We all know that contract size is a huge blocker for us! There is some discussion there about codesize optimisations in the Stylus VM that may be interesting to you. I also wanted to talk about a few interesting projects I’ve seen developing.

2. Stylus at ETH Cluj! 0xjsi (Jack) will be speaking about Stylus teaching people how to build on Arbitrum. We’ll dive into the talk content, including the open source material that will be coming out as a result of this program.

3. A Huff precompile: I wrote some Huff recently to work as a gas and codesize efficient proxy using our ed25519 and sha512 “precompiles”. These contracts are available on Arbitrum One and Superposition, making this code reusable for anyone wanting to build a high performance calldata proxy.

96kb contracts and the current ecosystem

To recap, the current contract limit is 75kb. This can be quite painful, as many of us have noticed. For 9lives, some of our contracts push up against the ceiling a fair bit:

76K	contract-trading-amm-mint.wasm
72K	contract-trading-amm-price.wasm
68K	contract-trading-dppm-extras.wasm
68K	contract-trading-dppm-quotes.wasm

I know from experience that this frustrates a lot of teams. The size problem forces you to write code calling out to other contracts, offsetting the gains we get from having the Stylus contracts.

A solution that’s been thrown around a lot is implementing is to bump the ceiling to 96 kilobytes.

There has also been talk of other solutions, like replacing the native integer type with a chunk on the stack and implementing the numbers entirely in bit manipulation with software with loops, increasing the amount of external functions in the VM to support more math operations, and more.

The issues with these approaches is that don’t make sense when you consider the overhead of the translation from the WASM representation to the native machine that happens when code is compiled.

The Arbitrum node works during the activation period by using WASM as a host agnostic translation layer, and converting it to the native machine with Ahead Of Time (AOT) compilation. You upload your WASM, then it gets converted to executable code on the Arbitrum node that runs your contract. This approach isn’t possible/easy with the EVM or with other machines (for the most part, including RISC-V), due to the lack of static jumps (and other reasons).

Unfortunately, with WASM, we need to work around the fact that the native machine lacks 256-bit numbers and has little endianness, different from the big endian of the EVM. This ends us up with an unfortunate consequence: a dependency on crates and host-provided functions that we could choose to expand on, but always with an encoding overhead.

In light of this all, the simplest size solution is to increase the limit to 96kb. Presumably the codesize demands would peter out in the future since we’re all sharing the same code. We could even just keep increasing the codesize if we hit any more blockers.

My feeling is that for a future size increase, we could also look at ways of adding code to the dynamic code that the VM provides that’s relevant to application programmers, like muldiv and some approximation methods, and a way of pipelining math operations with a one-time serialisation fee. We could also have some external functions that don’t make big endian assumptions about their inputs, providing a little endian alternative that lets us provide the location of the ruint tuple of 64-bit words. This would eliminate the current problems with serialisation to and from the external functions, eliminating the codesize costs there too. Should we be careful to avoid having so many external functions that there’s no point developing them?1

Following that though, we could release a version of the SDK with API compatibility with the existing code that replaces alloy and makes less use of abstraction. Alloy is good, but it has a ton of dependencies, and it’s not as codesize efficient for our usecase is my feeling.

Looking forward: my feeling is that this size increase is really great for the ecosystem. Thank you to Srinjoy and everyone at OCL for listening to the community, and advocating for this change.

Let’s also discuss a change on the horizon: multi value returns are leaving the Stylus VM. This probably doesn’t affect you, but turn it off with compiler settings if you’re using a custom release pipeline that doesn’t implicitly use wat2wasm and wasm2wat, which I imagine might cut it out. But someone needs to prove this, since I’m not sure.

Interesting projects

I wanted to share some projects that I’ve seen building with Stylus after adding them to the Stylusup page. We now have 51 projects launched there as of this time of writing. Two projects I haven’t seen receive coverage in other Stylus media:

1. Arbitrum’s Game Of Life: an on-chain implementation of the Game Of Life for a workshop.

2. Orthonode’s Stylus Hardware Anchor: cheap hardware proof of provenance that’s verified on-chain using Stylus. A way to have proof at the hardware level of liveness that could be useful for on-chain distribution, voting, and more. I imagine that at a future conference we might see someone handing out badges that prove you’re human that you can use on-chain! Launched on Sepolia.

Stylus at ETH Cluj

I was scheduled to speak at ETH Cluj about Arbitrum and Stylus, but the situation with fuel insecurity (and the broader macro) derailed things. Jack (0xjsi) has taken up the task of speaking and organising the workshops, which run on the day of the 13th of May, 2026. The conference generally is from the 13th to the 14th.

The content will run like this:

1. Arbitrum’s Role in the New Ethereum Roadmap: some cultural and technical background on Ethereum, and how Arbitrum fits into Ethereum now and in the future.

2. Your First Smart Contract on Arbitrum: introducing everyone to building smart contracts using Solidity on Arbitrum. This workshop and open source website introduces several smart contracts that the workshop will build together, including a stablecoin, lending protocol, vault, and DEX. It explains how to build each of them, including the content and context.

3. Stylus for beginners: this workshop and site will introduce how blockchains work, the EVM, how Arbitrum works, and how Stylus differs from the EVM and its context. This step will introduce stack-based machines.

4. Deploy & Go - From Contract to App: this final step will take everything we’ve done so far, and introduce how to build a webapp from it. It will teach everyone how to work with Stylus.

Our goal is twofold:

1. Increase the amount of open source literature covering Stylus.

2. Teach students to work with Arbitrum and Stylus in person with a guided lesson-like format of Q&A. Have them walk away with the skills to work on the Arbitrum stack again.

For the first goal, we’re looking to partner with a team building a AI product atop Stylus to run a chatbot for us. If that’s you, reach out please!

I’ll be contributing online via a Telegram channel for questions during the workshop, and making available a faucet for Superposition Testnet, producing the Stylus for beginners content, and also helping create the other content where I can. Jack is doing an excellent job, and the content so far is great.

If you’re interested, grab a ticket:

A Huff calldata proxy

Tying out our content for today, I wanted to share a EVM preprocessor snippet we put out for our upcoming RFQ and RPC 9lives feature:

// LiteAccount: Simple calldata forwarder that takes an argument of the
// form WITH NO PADDING (bytes32 sigA, bytes32 sigB, uint128 nonce,
// address target, bytes... cd). Uses Superposition precompiles to
// validate the ed25519 after converting it to sha512, and the
// expectation is the signature was signed with padding.

#define constant STORAGE_ENABLED = FREE_STORAGE_POINTER()
#define constant STORAGE_NONCE = FREE_STORAGE_POINTER()

#define constant ADDR_SHA512 = 0x1f4350205a556587ff3a1f2cb627613685dacb73
#define constant ADDR_EDVERIFY = 0xc3e443be2cfa4f41a5f5e4978d012847d355b419

// [EDVERIFY] the memory, returning a yes or no word on the stack.
#define macro EDVERIFY() = takes(0) returns(1) {
	0x0 0x0 0xa0 0x0 [ADDR_EDVERIFY] gas staticcall
}

#define macro MAIN() = takes(0) returns(0) {
	0x1000000000000000000000000000000000000001 caller eq PRIVILEGED jumpi
	[STORAGE_ENABLED] sload FALLBACK jumpi
	INTERNAL_ERR:
		// InternalError()
		0xfe835e35
	REVERT:
		0x0 mstore 0x04 0x1c revert
	PRIVILEGED:
		0x0 calldataload [STORAGE_ENABLED] sstore
		0x0 0x0 return
	FALLBACK:
		0x40 0x60 0x64 dup1 calldatasize sub
		dup4 calldatasize sub dup5 0x20 calldatacopy									// Memory: ..., nonce, target, cd
		0x01 [STORAGE_NONCE] 0x0 mstore 0x11 0x1f sha3 dup1 sload INTERNAL_ERR jumpi	// [true, slot for nonce], Memory: padding <32 - 1>, storage slot, nonce
		sstore
		address 0x0 mstore																// Memory: padding <32 - 20>, address, nonce, target, cd
		0x0 0x0 0x2c calldatasize sub 0x0c [ADDR_SHA512] gas staticcall					// [success], Memory: padding <32 - 20>, address, nonce, target, cd
		returndatasize 0x0 0x0 returndatacopy											// Memory: hash A, hash B
		0x2000000000000000000000000000000000000000000000000000000000000002 dup6 mstore	// Memory: hash A, hash B, operator
		dup5 0x0 dup6 calldatacopy														// Memory: hash A, hash B, operator, sig A, sig B
		EDVERIFY()																		// [success], Memory: hash A, hash B, operator, sig A, sig B
		// Unverified()
		0xcba605a3 dup2 iszero REVERT jumpi
		dup4 dup6 0x0 calldatacopy														// Memory: cd...
		0x0 0x0 dup6 0x0 0x0 0x50 calldataload dup12 shr gas call						// [success], Memory: cd...
		returndatasize 0x0 0x0 returndatacopy											// [success], Memory: rd...
		returndatasize 0x0 dup3 SUCCESS jumpi revert
		SUCCESS:
			return
}

#define macro CONSTRUCTOR() = takes(0) returns(0) {
	0x01 [STORAGE_ENABLED] sstore
}

Have you ever worked with Huff? It’s a great macro preprocessor for the EVM. Working with EVM code is easy when you have Stylus to handle your precompiles/complex behaviour, and you can just act as a low-cost proxy. This code works calldata generated like the following:

let k = SigningKey::from_bytes(&priv_key.0);
let mut x = Sha512::new();
x.update(&contract.0);
x.update(&nonce.to_be_bytes());
x.update(&target.0);
x.update(&cd.0);
let sig = k.sign_prehashed(x, None).unwrap().to_bytes();
println!(
    "{}{}{}{}",
    const_hex::encode(sig),
    const_hex::encode(nonce.to_be_bytes()),
    const_hex::encode(target.0),
    const_hex::encode(cd.clone().0)
);

I understand why borsh is somewhat stigmatised as a calldata format (EVM conventions, zero byte rebate, etc), though I believe more developers would benefit from the nonstandard format when it comes to Stylus precompiles. It’s so flexible to create something quickly and to drop it in. This code is a good example of how it can be pretty easy I think. The precompiles here (sha512, ed25519) are available at https://github.com/fluidity-money/superposition-precompiles.

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. Check me out online: https://bayge.xyz

I develop Superposition, a defi-first chain that pays you to use it. You can check our ecosystem of dapps at https://superposition.so.

Why did January go so quickly, was it something that you said? In this week:

1. To build an Orderbookkit part 1: Some background on the implementation and the design philosophy at work in the architecture of Orderbookkit, a one-click permissionless DEX for Arbitrum chains!

2. Supporting Stylus on RISC-V part 3: Supporting RISC-V execution on-chain on Arbitrum using the new risc-runner, and the practical application of it.

3. The Wizard V2: Building a Verifiable Delay Function proof generator and verifier for a randomness beacon using The Wizard. Part 1 as we flesh out the code.

4. Interview with Burak from Runtime Verification: We had the luxury of learning more about Burak’s journey through Web3 and Runtime Verification!

I should share that once upon a time we had a competition for survey respondents to receive a Supercat and a Knower NFT for sharing their feedback about our silly little newsletter. It’s been some time, and I’ll be awarding the winners soon. Thanks for your patience.

Want to build Arbitrum dApps even faster? Are you an AI user with Claude Code? Try this!

Made by the one and only Ben Greenberg (hummusonrails), it’s a MCP and setup toolkit that simplifies creating apps on Arbitrum quickly. Give it a try!

To recap, Stylus is a Arbitrum technology for building smart contracts in Rust, Typescript, Zig, and C. Stylus lets you build smart contracts that are 10-50x more gas effective and orders of magnitude more expressive than Solidity smart contracts.

To build an Orderbookkit Part 1, orderbook structure

Readers would know that we’ve been building an orderbook for Stylus for some time. Initially, I built a simple Uniswap V3-style tick orderbook with a queue for orders, but I didn’t feel it worked very well. There was a lot of slippage and price inefficiency, and storage access worked extremely poorly. After doing some research and discovery, I settled on this architecture:

A CLOB and RFQ hybrid orderbook

Orderbookkit is a CLOB and RFQ hybrid. It functions like a tree-based Central Limit Orderbook (CLOB) with some scaling for price amounts for orders outside the current spread (a custom defined window around the last fill price). Within the spread, a Request For Quote (RFQ) “sliplane” exists for off-chain or on-chain bundling and execution of orders.

Most orderbook operations are price discovery trades from market makers, which consist of tiny order creation then filling and cancellation. An entirely on-chain contract for this use-case is a poor fit, with order cancellation costing a transaction fee. This makes price discovery for market makers challenging. An upcoming Superposition property, Longtail Pro (powered by Espresso and also built with Stylus) takes a more naive approach on this, with a rolled up calldata and a native CLOB on a validium/state channel experience. This approach differs in its native execution flexibility at the expense of a more natural trading experience, and it makes a natural fit for our other application, 9lives. Which is growing a lot by the way, and keeping me VERY busy.

A RFQ hybrid architecture enables wide price swings from retail users by supporting instant execution with an on-chain fill using the tree skipping the RFQ functionality, but for minute trades within the spread, off-chain bundling and free cancellation with the RFQ system. This architecture also enables a ton of programmability options, including turning the RFQ engine into a liquidity sidecar for applications.

This liquidity sidecar overlayed on top of the RFQ engine supports several models including the 9lives’ Dynamic Pari-Mutuel (DPM) market model, the original version of 9lives. It empowers end users of Orderbookkit to choose their bundling and execution strategy, optionally filling liquidity and RFQ orders using cross-chain sources as opposed to local liquidity. It makes applications possible to be written where the orderbook interaction is an afterthought, making it possible to add selling to models that would not have had support traditionally.

This style of opt-in architecture to sidestep the market forces also means dApps could run almost entirely inside Orderbookkit. This, coupled with a recursive calldata pattern (as we’ve developed for Longtail Pro Passport and alluded to in this post, means dApps that run as an application-specific rollup, making gas-free applications possible on Arbitrum and on any Layer 3 chain for some types of interactions.

This fundamental rethinking as the orderbook not as the vehicle for matching orders but as the vehicle for execution itself is a fun rethinking of bundling applications themselves on-chain! So Orderbookkit could be considered a fun little rollup architecture depending on how its used.

On-chain execution with a new plugin architecture

Orderbookkit supports programmability with entirely new plugin architecture leveraging RISC-V. Hooks are built not using contracts that are registered ahead of time, but instead by delegatecalling into contracts that are “jailed” using a RISC-V simulator, or submitted natively based on the calldata provided by the user.

End users or the execution bundler elect to run these programs as guests, and the programs are running inside the contract’s space, so they have access to the storage layout of a high level bundler that’s run off-chain, or Orderbookkit’s order matching engine. This means the program can import the storage layout for Orderbookkit very simply, and use it themselves, without a series of onerous callbacks. The simulator enforces a pledge(2)-style syscall restriction on contracts executing alongside a higher level programmable interface inside the guest so these plugins have no escape from their intended purpose or have any potential for collateral damage. The intended purpose of this architecture is that we can develop plugins without needing to permission or register them ahead of time, a problem with existing hooks AMMs and platforms. This approach also works nicely with privacy and other addons by supporting a private order matching engine sidecar that feeds into the same space as everyone else, making opt-in privacy possible.

bobcat-sdk has been extended to support RISC-V as a backend, and it can be used this way without any friction.

Genetic programming market makers

One of the goals of the Orderbookkit project is supporting evolutionary programming for the plugins, optionally generated using a Proof of Work algorithm, like Anubis. I can’t say whether this will actually take place, but I imagine it would be fun. Maybe someday someone could write a scalable marketplace for proof of work algorithms that run instead of captchas.

This type of generated code enables a type of “cooperative orderbook”, with limited inherent value to the book. This enables a use-case I’m very passionate about, figuring out ways to do software timeline estimation within an organisation. Google and HP tried this, and failed due to liquidity issues. We can do better!

It’s simple: define a constraint and have your program automatically find the best fit. Evolutionary programs are better at functioning in resource constrained environments as an orchestration layer. The evolutionary programs can compose multiple programs together, including machine learning helpers for example. In our context, they’re very simple, but later, as we find ways to include more information points on-chain in a way they understand, they could do things like arbitrage spread when there’s enough liquidity elsewhere.

These are useful for our cooperative orderbook use-case by enabling us to take lots of information points and combine them together in ways that fit within the code constraints of the on-chain execution. In our prediction context inside organisations, this provides liquidity in a safe way. For everyone else, this fills the gap with missing liquidity amounts.

I envision a future where end user code searches an application space of user submitted programs that automatically execute in the context of the orderbook. A client, before placing an order in the sliplane, executes a number of programs in parallel before making the order to see if they can automatically fill themselves.

Contract interactions take place not with a series of external calls out or registrations of callbacks, but as a series of pipelining that took place automatically. I envision that this community search space of execution hooks that are opted into by the user’s client pay a small premium to the application developer, making it a landscape of programs that greedily consume liquidity chain-wide. It makes arbitrage not a function of professional market makers, but instead automatic programmers who’ve algorithmically identified opportunities that they pass down to end users. This rethinking that’s fundamental to Orderbookkit makes the exchange function less as a marketplace of orders but more as a octopus that constantly expands its web of liquidity sources, until it encapsulates everything on-chain.

Where’s the code?

I’m working on it! The risc-runner guest features has made its way to bobcat-sdk (missing heap allocation features right now however). There are a few more goals I want to have hit before opening this up to the world, namely:

1. Support for extending using stylus-sdk for the matching engine for basic accounting that the plugin layer doesn’t capture.

2. A bundler with multiple signature schemes supported, including the ed25519 precompile supported by Superposition.

3. Better testing.

Keep your eyes peeled for a part 2 on this. Thank you to Pruitt, Srinjoy, and the rest of the grant committee as well as the Arbitrum DAO (the sponsors of this project) for making this development possible! The code will also need to be audited. We’ll be discussing during our part 2 the implementation, pointing to how to leverage Orderbookkit in your project. We’ll be making use of this for 9lives to support a direct to market maker feature with the CLOB functionality disabled probably. For 9lives at least, this lets us scale our architecture without setup liquidity for now.

Supporting Stylus on Ethereum RISC-V Part 3

Previous post

Part 3 of this series, the conclusion! A working running ELF-parsing example that runs on-chain, with a deployer available at a precompile address on Superposition and Arbitrum One. The code is bundled with Orderbookkit as it forms the basis of the plugin architecture. Let’s do some review:

An example program in Stylus RISC-V

Programs in RISC-V Stylus are like the following using bobcat-sdk:

#![no_std]
#![no_main]

use bobcat_sdk::prelude::*;

#[export_name = "_start"]
pub extern "C" fn _start() -> ! {
    let args = read_args_safe!(args_len(), { 32 * 2 });
    let (x, y) = read_words!(&args, 2);
    write_result_word(&(x + y));
    unsafe { exit_early(0) }
}

This program simply multiplies two numbers together after reading them off the contract’s calldata. Behind the scenes, it uses environment calls that function almost identically to the classic WASM Stylus environment, though the way the program asks for memory will be different and require a custom allocator. stylus-sdk is very similar with its RISC-V form, and you can see that in the previous post.

Deployment

Deploying is like the following once this contract’s entrypoint is called, with a CREATEX-style hub. This runs inside the entrypoint to the loader:

let src = OurLzss::decompress_heap(
    lzss::SliceReader::new(&read_args_vec(len)),
    lzss::VecWriter::with_capacity(74 * 1024),
)
.unwrap();
check_elf(&src);
// Make the contract code:
let c = make_contract(src);
// Get the sender's nonce, and use that with CREATE2 so they get
// consistent deployment addresses on every chain they do this with:
let sender = msg_sender();
let slot_key = slot_map(&U::ZERO, &sender.into());
let user_nonce = storage_load(&slot_key);
// Bump their nonce preemptively:
storage_store(&slot_key, &(user_nonce + U::ONE));
// Now we deploy the implementation, with the user's address and nonce:
let salt_pre: [u8; 20 + 32] = concat_arrays!(sender, *user_nonce);
let (impl_addr, _, _) = create2_slice_pre_keccak256::<0>(&c, U::ZERO, &salt_pre);
if impl_addr == [0u8; 20] {
    panic!("bad impl deployment");
}
// Now that we have the implementation, we can deploy the proxy contract
// that calls the loader:
let (proxy_addr, _, _) = create2_slice_pre_keccak256::<0>(
    &make_proxy_loader(impl_addr, RUNNER_ADDR),
    U::ZERO,
    &salt_pre,
);
if proxy_addr == [0u8; 20] {
    panic!("bad proxy deployment");
}
write_result_word(&proxy_addr.into());
0

The deployment takes the contract and provides the code on-chain, with a prefix to cause the code loaded under normal circumstances to junk out with an INVALID operation. The runner skips this, after beginning its entry of the code.

#[unsafe(no_mangle)]
pub unsafe extern "C" fn user_entrypoint(len: usize) -> usize {
    let args = read_args_vec(len);
    let features = u16::from_be_bytes(args[20..22].try_into().unwrap());
    libriscrunner::entry(args[..20].try_into().unwrap(), features, &args[22..]).unwrap()
}

The entrypoint for the runner is to load feature flagging that was given for what should be supported, a restriction like pledge(2)/sysjail, where the host opts into restricting the syscall surface for the guest (or the rest of the program’s life if we’re being very literal).

It loads the entrypoint, the same way we discussed in the OCaml code. The code was loosely ported over, though Rust’s types for integer types made things a bit easier.

The code differs from the OCaml code in the last post since we could use the program headers instead of section headers (I had some tooling weirdness and couldn’t use this easily).

What’s next?

I’d like to support the Linux syscall surface and riscv64imgc so we can run Linux and OpenBSD on-chain. It should be achievable, and why not as a nice show and tell? It would be interesting to support an actual operating system or… Doom(?) on-chain. I’ve never done the latter (or the former).

The commercial imperative for me right now is to support Orderbookkit’s plugin system and competition solver, so this is a future task. With the Linux syscall interface and the rest of the extension, it should be possible to simulate most programming languages where WASM support is weak. Maybe an OCaml loader could come someday, so we can run the bytecode on-chain?

I’d like to also support a stylus-sdk trait inheritance extension of the runner for the ecall interface. This means that developers could build custom extensions to the plugin architecture easily. I would like developers to have access to a script interface similar to Bitcoin, where you can send a nice transaction that includes everything you want to do using this support. It should be achievable to have an interface that does this this way, something like this:

#[public]
impl IRiscRunner for MyToken {
    type Error = permit::Error;

    fn handle_ecall(
        &mut self,
        cpu: &mut Cpu,
        sender: Address,
        ecall_no: usize
    ) -> Result<(), Self::Error> {
        // Do your handling here of anything custom!
    }
}

As a reminder, you can always sign up for Orderbookkit as it becomes generally available with a user interface at https://orderbookkit.xyz to see this in action.

The Wizard V2

The Wizard V2 came out recently! We’ve been following their journey for some time, and the newest release includes some major features we’ll highlight here:

1. Github integration! Clone repos to work on using the editor without any extra friction.

2. Deployment takes place entirely in the browser using the browser wallet. Deploy a contract using MetaMask or Rabby!

3. Multiple chains are supported with a simple RPC feature!

4. Editor user experience improvements including using multiple networks seamlessly.

These are great improvements for the major V2 release, and to test it out, I set out to create a new contract using only The Wizard.

Building a Verifiable Delay Function evaluator with The Wizard

We’re going to build a new contract, a Verifiable Delay Function (VDF) proof generator and evaluator!

A VDF is a problem that’s solved recursively in a way that can’t be parallelised, which functions well as a proxy for time and as a randomness beacon. The problem that’s solved recursively serves as a proxy for whether time has passed and as a randomness beacon, since the problem can’t be solved in parallel.

This is useful for the Superposition projects, since this way we can have randomness that’s not dependent on a randomness committee (with callbacks, a major programming hassle in my opinion) by having the resolving worker ask a service for a number. Our service will run this code constantly, and send it on request. Since our beacon is running on a non soft realtime system, it’s not perfect, but it’s a nice combination piece to be used with a random secret commitment from our infrastructure type of situation.

Setting the scene

To begin, we’ll figure out which VDF algorithm we want to implement. I chose the Pietrzak VDF algorithm depicted literally in Implementation Study of Cost-Effective Verification for Pietrzak’s Verifiable Delay Function in Ethereum Smart Contracts from 2024. There are two VDFs I’m aware of, the Wesolowski and Pietzrak VDFs, and as I understand, the latter’s prover is more efficient. The estimated gas savings in the paper we’re paraphrasing here provides us with a way to also say how much gas we’d save if we implemented the refined verification in Rust Stylus.

Ordinarily, algorithms like this would be implemented using the GNU Multiple Precision Arithmetic (GMP) library, though for our learning purposes we’ll be implementing it using Ruint for portability reasons. I imagine that GMP could be used in the WASM context, but I have no idea how. Is it even important since you wouldn’t net any performance benefits? Maybe someone can implement a “precompile” with a light scripting language for pipelined gmp operations or simply expose each function this way, I don’t know the impact on codesize for this.

We need 2048 bit numbers using Ruint (the size used in the paper), and we’ll be avoiding optimisations including Montgomery modular multiplication.

Implementing the evaluation algorithm

We’ll be evaluating all code using The Wizard. The evaluation algorithm is pretty simple. It’s y = x^(2^T) % T. The evaluation algorithm is the time consuming delay function code that we need to use to generate the proof. It’s the crux of the algorithm, we need it to consume time, since its applied recursively without known parallelism.1 The maximum size of the input we’ll use for U is the largest Ethereum word we can use, so we don’t need to adjust the number here to avoid overflowing.

The inputs to this function and the rest are (paraphrased from the paper, almost literally copied):

• x: The input for the VDF evaluation.

• N: The modulus (an RSA modulus N = p * q), where p and q are large primes.

• T: The time delay parameter, where T = 2^tau for some tau (τ).

• tau: The number of iterations needed for the proof. The higher this is, the greater the amount of time we’d have to spend.

• y: The output value, computed as y = x^(2^T) mod N. Aka, the evaluation function we just showed off.

Implementing the proof generation algorithm

Let’s implement the proof generation. This is the algorithm in the paper:

What this essentially does is split the evaluation algorithm’s chain in half (the halving protocol). The implementation looks like this:

This function is pretty ugly and leaves much to be desired with its performance and readability characteristics. The implementation here makes use of variables instead of vectors. While taking T, it will use a 64-bit number here. The reason is that T is the amount of time that needs to pass, and we want to tolerate that number being quite high. Though the wasm32 machine natively doesn’t support words of this size, it supports 64-bit operations. We’ll be pushing the higher end of the 64-bit numbers for our time spent here.

Implementing the refined verification algorithm

This ability to skip time features in the refined algorithm:

Which looks like this in The Wizard:

Since the protocol works with halving to verify the generated proof, the larger the time parameter, the larger the proof size (and therefore the calldata we send on-chain). Since we can’t afford to have a situation where this is the case, Pietrzak implemented a way to skip an amount of time in the proof. For this reason, we avoid calculating when someone enforces a time skip parameter to avoid wasteful computation.

We do bitshifting math instead of performing 2 to the power of 2 here, to save a few cycles. We use pow_mod to avoid overflowing the number. Special shoutout to Claude for doublechecking my work, Erik of Fluidity Labs for a review, and Tolga for fixing problems I ran into when using The Wizard!

In a part 2, we’ll review this code and test it properly, and do a formal comparison to the paper to understand the gas consumption differences!

Interview with Burak from Runtime Verification

Runtime Verification are working on extending their Skribe tool to support Stylus! We’ve recently been collaborating with them as they have their tool work on the 9lives repo. I can tell that Burak is a heavy dev based on the modifications they’ve been making to the 9lives repo to support Skribe.

Who are you, and what do you do?

I’m a Research Engineer at Runtime Verification. My focus is on building formal verification and property-based testing tools for blockchains, using the K framework and formal semantics as the foundation. In practice, that means trying to make strong correctness guarantees usable by everyday smart contract developers.

Most of my work revolves around Rust and WebAssembly. Recently, I’ve been working on Skribe, a property-based testing tool for Arbitrum Stylus. Skribe is intended to be the Arbitrum equivalent of Foundry’s fuzz testing for Solidity, with support for both Rust and Solidity contracts.

What web3 ecosystems have you worked in?

Most of my work has been on WASM-based blockchains. So far, that includes MultiversX, Stellar, and now Arbitrum. Across all three, I’ve worked on similar problems: building formal verification and property-based testing tools for smart contracts.

For MultiversX, we developed a tool called Kasmer, which we used for the formal verification of real-world contracts such as multisigs and AMMs. For Stellar, we built Komet, which we actively use in Stellar smart contract audits for property-based testing. More recently, I’ve been working on Skribe for Arbitrum Stylus.

What are your impressions of working with Stylus?

Rust + WASM + EVM is a genuinely exciting combination. On the EVM side, there is already a mature ecosystem that has been built up over many years. Rust complements that with a strong type system, good performance, and more explicit control over memory and correctness, things I personally care about a lot.

From that perspective, Rust fits smart contract development well: it is type-safe, predictable, and efficient. Its popularity and wide adoption can also make Arbitrum more appealing to a broader developer audience. Another nice upside is that existing general-purpose Rust libraries can potentially find their way into smart contracts, which opens the door to reusing well-tested building blocks.

What software do you use?

We mainly work with the K Framework, a formal semantics framework developed at Runtime Verification. With K, we define the semantics of a programming language in the K language, and from that definition the framework gives us, almost automatically, an interpreter and a symbolic execution engine. On top of these, we build formal verification and property-based testing tools.

Up to this point, this might sound quite theoretical and a bit intimidating. In practice, though, our focus is on using this foundation to build practical tools that regular developers can actually use. We take the underlying mathematical foundation and turn it into accessible, developer-facing tooling, rather than something that only formal methods experts interact with.

As I mentioned earlier, we work across multiple blockchain ecosystems. What makes this feasible is that semantics written in K are reusable, modular, and extensible. For example, the same WASM semantics can be shared across MultiversX, Stellar, and Stylus, instead of reimplementing everything from scratch each time. As a result, improvements made for one project often carry over to others, which lets us move faster and build on accumulated work rather than starting over for each ecosystem.

What hardware do you use?

Most of my time on a computer is spent compiling code or running large test suites. Because of that, I use a Linux desktop with the fastest CPU I can reasonably get and plenty of RAM.

CPU performance matters a lot for compilation and symbolic execution workloads, and having enough memory helps keep things smooth when running multiple tests or analyses in parallel. Beyond that, I honestly don’t care much about the rest of the hardware, and I’m not even sure what kind of GPU is in the machine.

How can we get in touch with you?

You can reach me via Telegram (bbyalcinkaya). For broader questions or collaborations, getting in touch through Runtime Verification (https://runtimeverification.com/) is also a good option.

What’s a piece of advice you’d give someone new to web3?

I’d suggest starting with a security mindset from day one. In web3, mistakes tend to be permanent and expensive, so correctness matters much more than in many other areas of software development.

It’s worth looking at the methods and practices used in the industry to write safer and more reliable smart contracts: things like testing, fuzzing, audits, and, where possible, formal verification. Even if you don’t use all of these tools yourself at the beginning, understanding why they are used helps shape how you design and reason about your code.

Just as important as doing formal verification is adopting a formal verification mindset. Thinking explicitly about the properties and invariants of the system you are building, and trying to express them as precisely as possible—even mathematically—can be very valuable, regardless of which tools you end up using.

Runtime Verification can be contacted via their website. Burak can be connected with via Linkedin. He can also be followed via Github!

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!

I develop Superposition, a defi-first chain that pays you to use it. You can check our ecosystem of dapps at https://superposition.so

In our case here, for our newsletter, we’ll be focusing back on trying new things to keep the blog fun and fresh. A goal for us is to avoid heavy technical Goliath tasks, and to focus on space recaps. I enjoy the hard tasks, but they’re time consuming and people report they can be hit and miss, unless they solve a specific technical purpose. I’m going to make more of an emphasis on interesting technical storytelling. A New Years Resolution will be to also “write something opinionated at least once in a storytelling voice”. Let’s see how that goes.

We’ll kick this year off with a freeform opinion piece on why you should take an interest in Stylus this year, and we’ll discuss StylusPort and everything they’ve been up to.

Why learn Stylus in 2026?

Why learn Stylus in 2026? You may have heard about Stylus last year, and wondered, how has the adoption been? Should I invest time into learning? In this little writeup, I’ll make the case that you should, for a few reasons. To recap: Arbitrum Stylus is a technology to build Ethereum Virtual Machine (EVM) compatible smart contracts using Rust and several other programming languages. The smart contracts are executed after a compilation to native code from WebAssembly, an alternative instruction set and execution environment than the EVM. This means natively higher performing smart contracts!

Stylus makes more ideas possible

Stylus makes it possible to do things like implement Bayesian statistics on-chain without a major compute-driven gas hit. It made Renegade possible, a fully anonymous swap with on-chain and off-chain elements. It makes our boring CPMM model possible to implement for 9lives without doing an off-chain binary search, and it supports our uniquely weird contract development process, including a vertical integration with the rest of our tool ecosystem alongside our feature flag experimentation. Teams like Fairblock are long-term bullish on Stylus, and they’re building essential privacy tools that do things from anonymous swaps to anonymous prediction markets.

For hard hitting teams, Stylus is the 10x enabler since you can implement ideas with without going “uhhh… should/can we even implement this on-chain?” You’re not caught in that philosophical trap the Ethereum developers were caught in when they built the EVM. At first, state channels and validiums were seen as the only legitimate way to build applications for users, owing to the Bitcoin philosophical history of not wanting to pollute the blockspace. This is the historical baggage of the virtual machine and language tooling we have available with Solidity and the classic EVM, including its block and codesize restrictions. Eventually, sidechains and layer 2s came around, inheriting the programmability of the base chain to provide economic guarantees to their users for more programming flexibility. Now, it’s not even a topic for debate that this method of a hub-and-spoke model of contract ecosystems is superior to a walled garden of various isolated state channels or solving graph optimisation problems for which there is no known solution.

Building on the technical opportunity of the Arbitrum L2, Stylus is the fundamental gamechanger that we can build applications with the way we do for web2. Thanks to the broader suite of languages we can choose from and the technical capabilities of the Arbitrum VM executing complex code with ten times the cost efficiency, we can express ideas more succinctly and focus more on the business logic of what we’re building. This unlocks faster development and faster ideation, and a more relentless user focus other than engineering problem solving.

We don’t need to be concerned with the discussion of “should this even be on-chain in the first place?”. We can build without needing to get our backs thrown out by being restricted to the language intended for Ethereum’s architecture and philosophical setting. Freeing ourselves from the complexities of working within the classic EVM means faster development, which means faster idea turnover, which means faster building of ideas that matter. The conversation goes from “how can we effectively compress the product story to eventually land on-chain” to “how can we implement the coolest shit?”

Stylus is positioned to grow a lot

Stylus will continue growing. My team built on Solana during the earlier days. This was before Anchor was a thing, and it was ROUGH. These were the days of before Helius, when RPC was a total nightmare. I still have nightmares about our providers going out of sync with each other. We were building a new stablecoin for Solana that would pay you for making transactions with it, and we needed live updates without interfering with the SPL token standard.

Building with Rust was a challenge for us back in those days. Despite our best efforts at the time, Solana’s ecosystem at the time was partly captured by a pair of brothers who pretended to be more than five different people. We could not get integrated with anything, nothing was documented, the entire experience was rough. Eventually the brothers got caught out in their fraud, hurting the ecosystem for a time. Nothing spells grit in this ecosystem like a Solana dev that stayed building with Solana after that period, that was a hard time.

They wash traded the transactions between their ecosystems, counting TVL several times over, and you couldn’t verify that they were actually organic transactions because Solana did not back then have an open source ecosystem like Arbitrum and Ethereum. We tried at one point to add ourselves to the most popular multisig provider, and we couldn’t! It was completely closed source (and by that same dev, we learned). If Solana can make Rust and a new programming model work in those circumstances, we can with our open source mindset and superior measurement tools. We have the major technical advantage over this with our storied open source development story and ecosystem narrative that code should be for everyone to see.

Stylus unlocks that flexibility and Solana, the closest success story, was operating on unfavourable technology terms compared to us, and they still made it work. We have the best devex as an ecosystem for building and measuring smart contracts. Stylus will succeed in combining that with one of the best language ecosystems for development.

The commercial opportunity is there

Arbitrum is the home of defi. Out of the layer 2s at the time of writing, we have the highest TVL. We have some of the most proactive supporters in the ecosystem. I’ve lost count of the number of times I’ve felt thankful to people in the space for promoting my silly lil’ projects, these people range from growth and devex (though I have an aversion to doing anything other than shipping product, so I let my guys Ivan and Shahmeer talk to people on my behalf). We have the most established and proactive DAO, with the most vocal community, the most sustainable economics owing to clever solutions instead of blasting vanity metrics like speed of block creation.

If you want support, you build on Arbitrum. You can DM me or anyone else in the ecosystem, and we’d be happy to promote and help you however we can. Arbitrum is an established player with leading defi distribution for ecosystem reasons, the airdrop was long ago. Build with Arbitrum and get the best of a great community, and the best product enabler for your ideas.

You should be nerdsniped by Stylus

Let me speak to the Miladys who should be uniquely excited by this opportunity: Why are you gas golfing the EVM? You’re finding ways to circumvent human invented rules around consumption of resources on an imaginary super computer. Why don’t you solve hard of how to implement and represent programming ideas, in ways tangible to the raw expression of your concept? Free your wetware from the constraint of the EVM tooling stack itself!

Please try Stylus! This is an open call to people, if you want to learn Stylus, I will spend time with you, I will take your complaints directly to the team building Stylus tooling, you can write for this blog, I’ll pay you to do it even (for an article). Build something, get frustrated with the type system, get frustrated with the learning curve of Rust, hit a codesize blocker, dig deeper, understand, enjoy the nearly infinite skill ceiling of this tech stack. And yes, it’s just Rust with WASM on the EVM when it comes down to it. I know money doesn’t appeal to you — I’ve seen you working with your SMT solvers, I’ve seen you posting unhinged takes on X — I know you don’t care about money like that. But please, you’re so cool doing your optimisation! Try Stylus out, see what’s about to come.

The thing is, 2026, this is only the beginning. This is the year the chickens have come home to roost from the last year of fermenting the tooling Kefir. This is the year that you can leverage arbos-foundry for on-chain testing if you must integrate with Solidity, Walnut is in a good place (if GDB is your fancy), there are a few projects that are in the scaling stage of development, and the codesize restriction will be lifted — this is the main complaint with Stylus. Come and enjoy the pleasure of working on product and computational problems instead of EVM engineering.

When you work at a high level and you program every day for hours on end, your brain forms a new section that’s a mixture of the traditional centers of math and language. Like the mirror neuron section of your brain in a nice conversation (I know this may be unknown to you autists out there), you mirror the problem of a technical exercise when you model the domain. The act of programming in Stylus unlocks your brain in the sense that the metaphor is richer, the idea is more succinct, courtesy of Rust (and the phethora of other languages Stylus supports). The higher level programmer understands that to mock the idea, you mock the context. This is why many strong programmers build DSLs and mini languages to solve their problems. The highest level programmers translate their expression to the same medium of expression and combine the pieces like a jigsaw.

This is why railway-style programming exists, why category theory is reasoned about by functional programmers, why programmers translate their ideas into units of combinators then combine them together. Why APL programmers slam their applications together into one term, even putting aside the engineering context. If any of these ideas are new to you, or even the tools I’m using to express them, open your mind! There’s a saying, if you want to think, write! Write better with Stylus. Everything I’ve just said here is foreign to the classic EVM toolchain thanks to Solidity. Play with Stylus and let us know. The domain is rich, the opportunity is massive, build bodies of financial concepts bundled in technology.

Stylusport’s handbook for Solana and MCP server

How do you convert a Solana project to run on Arbitrum?

StylusPort have been up to a lot, having written a handbook on how to port projects from Solana to Stylus! Solana’s memory model fundamentally differs from the EVM’s, with an account-based model as opposed to a contract model with key value storage. Solana’s method of storage is more akin to allocating virtual memory pages, then having a location for writing.

The reason for this stems from explicit parallelism (needing to explicitly indicate the resources you intend to contend), and providing developers flexibility to choose the serialisation method in their Rust applications.

How do you port code under these circumstances of needing to opt into what you intend to do? StylusPort have built a handbook and MCP server that you can use to guide your translation efforts.

Let’s dive in!

The handbook

The handbook introduces types in Solana from a contract-first perspective, some background of the memory approach in Solana, and the cross-program calling interface.

The key distinction in my mind between Solana and Ethereum is that in Solana, you’re mostly building programs in the present and post Unix sense that they fulfill some role with some shared storage somewhere that the calling domain has access to with permissions. A useful analogy is the way that programs on your computer access files on disk, with their varying permissions and such. EVM-compatible machines like Arbitrum have the storage of the contract revolve around the contract itself, so there’s no distinction between the contract’s storage and the application.

I felt that the handbook does a good job of explaining this difference. The handbook provides examples for transitioning a contract implemented without the Solana DSL Anchor, as well as with. The book provides a helpful exploration of the builtin types that the SDK provides, as well as an explanation of the type of storage that takes place.

I encourage you to check it out if you’re curious about bringing a Solana app to Arbitrum!

MCP

The team have actually provided a Model Context Protocol (MCP) integration that teaches a locally running LLM instance how to port Solana to Arbitrum! It actually detects context about your project, guides you through the process of making the replacement, and more!

It’s pretty comprehensive in the sense that the MCP server completely understands the handbook, as well as even having the capabilities of suggesting a path to a full migration! The example for Raydium really impressed me:

https://github.com/oak-security/stylusport/blob/main/mcp/docs/sample-plan-prompt-output-raydium-cp-swap.md

It actually breaks down the entire process including how to guarantee appropriate access control.

These are some screenshots:

Very impressive! Check it out at https://github.com/oak-security/stylusport/:

StylusPort are hosting a workshop on the 21st of this month! Check out the tweet and follow them 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!

I develop Superposition, a defi-first chain that pays you to use it. You can check our ecosystem of dapps at

https://superposition.so

1. Devconnect Argentina happened! It was amazing. WakeUp Labs organised a fantastic get together for the community, and yours truly was there! Let’s discuss.

2. Announcing RIP BOZO: A production app show and tell for bobcat-sdk. Deposit more than the last user, and be the last Bozo standing to win the prize pool! Including a silly little video.

Read on, and as always, if you have any feedback, please share it here:

To recap, Stylus is a Arbitrum technology for building smart contracts in Rust, Typescript, Zig, and C. Stylus lets you build smart contracts that are 10-50x more gas effective than Solidity smart contracts.

Devconnect Argentina recap

Devconnect Argentina happened! I headed there to give a talk on the history of Stylus including it’s on-chain penetration. Unfortunately, on the flight over, I got sick and lost my voice, so we gave my talk a miss. Thankfully Jess and the WakeUp Labs team were very forgiving. At their Stylus event, there were several speakers, including:

1. Peyman, co-founder of Fairblock spoke about Fairblock’s on-chain confidentiality with Stylus. Fairblock are super contributors to the ecosystem!

2. Srinjoy, product manager at Offchain Labs managing Stylus, reflected on the adoption of Stylus, what’s working, and what’s next.

3. Sergio, co-founder of Fairgate discussed smart contract execution on Bitcoin, and how Stylus uniquely enables the sidecar that’s needed using Arbitrum and BitVMX. This was a very engaging talk!

4. Milton, co-founder of WakeUp Labs spoke at length about their AssemblyScript (TypeScript) to Stylus compiler. We covered this in a previous post!

The rest of the event was nice, it was great to meet so many contributors from the space.

At Arbitrum Day, the mood was electric. It was great to name so many faces! WakeUp Labs spoke at a panel on Stylus, which was really great.

My talk will make a reappearance in the future at another venue, and in a recorded video for WakeUp Labs to distribute. We’re really lucky to be a part of the ecosystem, and Arbitrum at large!

Announcing RIP BOZO

RIP BOZO is a defi game of chicken where the rules are simple: be the last to deposit when the time runs out, and win everyone’s deposits. I developed this as a fun little show and tell for bobcat-sdk, and it lives fully open source in the examples directory. The code includes the graph that takes comments, the webapp, and the contract code. The game is powered by USND, the stablecoin by Nerite by CupOJoseph, a decentralised algorithmic stablecoin for the Arbitrum ecosystem.

I vibecoded the frontend with Codex after making the frontend in Figma. Each match lasts 45 minutes, with the last depositor to a growing prize pool that can only be added to if the amount exceeds 110% of the last deposit winning. The contract, despite reverting with an actual stack trace when a revert happens (using Error(string)) is only 30kb. Cool!

I’m developing this project in collaboration with Ivan of Superposition. We’ll have socials and a points program soon! The app is live on Farcaster, and we’re adding support for using Relay to buy from another chain virtually instantly into USND and a position.

The source code includes the entire webapp, the graph code, and more. It also includes the crank script that automatically resets the game and supplies it with randomness.

bobcat-panic

bobcat-panic is a crate with multiple panic-related features to make Stylus development simpler and safer. Enabling it with no_std and the feature panic, it supports the following flags:

1. panic-revert: On panic, print the full panic message. This is usually an explanation (if you were to use assert! for example), and the line that the error took place. Super helpful for understanding why something broke down.

2. panic-loc: On panic, print the filename and line that the issue took place in.

3. panic-trace: On panic, print the last register of a transient storage slot that was written to, decoding a string or number that was written there.

RIP BOZO actually uses panic-revert, and it falls under codesize anyway!

Testing with Forge Foundry (arbos-foundry)

The testing code was developed in collaboration with Bernard of the arbos-foundry team, so the end-to-end tests are a good example of how to use arbos-foundry to test your code.

The tests in the broader bobcat-sdk repo include fuzzing, with this example being testing an exotic permissionless upgradeable proxy, which we titled the metamorphic migration pattern. This is such a great tool for testing Stylus contracts in the real world!

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!

I develop Superposition, a defi-first chain that pays you to use it. You can check our ecosystem of dapps at https://superposition.so.

The standard Stylus SDK is one of the most expressive kits out there for development. It’s super user friendly, making it easy for pros and juniors alike to onboard into the world of Stylus. For us, as we’ve settled into development and figured out our own strategies, we found it interfering with our development, thanks to the sheer amount of features.

We accomplished gas savings by reducing the amount of abstractions in the SDK, using host features for checked math, not using the allocator by default, and more! As a development practice, I’m also working on aggressively regression testing feature release against a suite of examples, to avoid codesize creep. The goal with this SDK will be to mainly get the code size lower. Together, let’s do a quick overview of the features, and how to use it yourself!

No native types except for signed and unsigned 256 bit numbers

We don’t support any numbers natively except the U256 and I256 types. These are implemented simply, as a slice that’s assumed to be big endian. The default SDK leverages ruint through alloy to support EVM words, and this is can be wasteful, as there are several optimisations baked directly into ruint for performance. These result in more code being generated that we don’t benefit from (I assume), given the wasm backend.

Using the host features to do checked math

Another way we reduce codesize is by using the host provided external functions to do math. These functions are:

unsafe extern “C” {
    fn math_div(x: *mut u8, y: *const u8);
    fn math_mod(x: *mut u8, y: *const u8);
    fn math_add_mod(a: *mut u8, b: *const u8, c: *const u8);
    fn math_mul_mod(a: *mut u8, b: *const u8, c: *const u8);
}

By using these, we can implement checked math in a super codesize effective way. For example:

pub fn checked_mul(x: &U, y: &U) -> Option<U> {
    if x.is_zero() || y.is_zero() {
        return Some(U::ZERO);
    }
    if x > &(U::MAX / *y) {
        None
    } else {
        let z = x.mul_mod(y, &U::MAX);
        if z.is_zero() {
            Some(U::MAX)
        } else {
            Some(z)
        }
    }
}

For wrapping math, it’s a different story, so we provide it as a code implemented function. But, this is provided as a constant-time function, so it could be used for constant time code that’s not provided at runtime. In practice, developers developing for the EVM will likely use checked math everywhere (except for fees). Codesize-minded developers can use saturating math if they really want to save space, since that will use the checked code.

No allocator required (and many ways of doing calls)

Calls are made to be dirt simple, with plenty of different ways to make the call and access the calldata. Safe variants are available for every type of call, checking the codesize of the target before execution. There are different return types with different levels of abstraction, providing ways for programmers to reduce codesize or improve devex however they want.

No allocator is required to use bobcat_sdk, saving lots of space in the code output! All the outgoing calls can be performed using slices for the returndata, or vectors. This approach is used to let the user pick if they want to read simple boolean data, or to unpack an entire slice. This is implemented throughout the codebase.

Interfaces made easy

Several interfaces are available for operations including EIP20, EIP2612. More will be made available. It makes calling easy. This is a contract’s entire codebase:

#![no_main]
#![no_std]

use bobcat_sdk::{
    call::static_call_slice,
    entry::*,
    interfaces::eip20::make_fn_allowance,
    maths::U,
};

#[unsafe(no_mangle)]
pub unsafe extern “C” fn user_entrypoint(args_len: usize) -> usize {
    let args = &read_args_safe!(args_len, { 32 * 3 + 4 });
    let (contract, owner, spender) = read_word_slices!(&args[4..], 3);
    write_result_exit_call!(static_call_slice::<32>(
        contract.into(),
        &make_fn_allowance(owner.into(), spender.into()),
        u64::MAX,
        0,
    ))
}

This function simply calls a contract to ask for its allowance, returning the results. This contract is 4kb large!

Lots of versions of the calling interface are available:

safe_call_bool_opt(address, &make_fn_transfer(recipient, amt))
    .unwrap_or(Error::BadTransfer)

Which would check the contract’s codesize before making the call, only returning if the contract either returned nothing but code exists, or returning something but true. Good for backwards compatibility with ERC20? It should play nice with the interfaces!

Exotic types of storage accessors

Many types of storage accessor functions are made available, also with access to transient storage. These can be used to implement code that manipulates the underlying state in a way that’s more application-centric. An exchange function is also available, letting the user “check and set” like an atomic interaction. Each math operation is available over the storage.

Proxies made easy

Several proxies are made available in the SDK that make new contract deployment easy. These include a proxy that simply forwards calldata to an address in the contract bytecode, one that checks a storage slot for sending, and one that calls the implementation function on a beacon to get the address.

These were implemented in Huff to reduce the code overhead, and are simple to use:

#![no_main]
#![no_std]

use bobcat_sdk::{
    cd::{const_keccak_sel, read_word_slices},
    create::create1_slice,
    entry::*,
    maths::U,
    proxy::make_beacon_proxy,
};

const SEL: [u8; 4] = const_keccak_sel(b”deploy(address)”);

#[unsafe(no_mangle)]
pub unsafe extern “C” fn user_entrypoint(args_len: usize) -> usize {
    let args = &read_args_safe!(args_len, { 32 + 4 });
    if args[..4] != SEL {
        return 1;
    }
    let beacon = read_word_slices!(&args[4..], 1);
    let r = create1_slice::<1024>(&make_beacon_proxy(beacon.into()), U::ZERO);
    write_result_exit_create!(r)
}

This contract consumes 16kb. The macro that returns the data doesn’t work with the Result type, instead unpacking a tuple and checking a boolean flag. There are several return macros provided that work with different shapes.

Coming soon

Currently, storage access is function driven. We’ll be releasing a storage guard similar to what’s in the main SDK in the future. We’ll be porting over the examples form the Stylus SDK as well, and focusing on improving the codesize profile with inline optimisations where we can. We also need to have muldiv implemented, as well as the rounding up equivalent, for serious use. We’ll be working on supporting the example in the README, at which point, we’ll be considered complete! Stay aware of this space!

How do you test?

No testing functions are available to mock chain state. That’s why it’s important to combine it with another project, arbos-foundry, for on-chain end to end testing! We found that in practice, the only kind of development we were doing was mocking local functions. We’ll continue to do our testing development in Rust for our core algorithms. We’ll do a writeup on how this can be used in the future, though last’s post also discussed this topic.

Read the README!

Make sure to read the README to learn more! If you wind up using the SDK, drop me a message.

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!

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

1. An introduction to Scaffold Stylus 🧩, a template installing tool 📦 for getting started with Stylus 🧠, including using Chainlink’s data feeds 🔗 and VRF 🎲, and ERC20/ERC721 contracts 💰🎨.

2. OpenZeppelin 🧱 have had their contracts fully audited ✅ in their 3.0 release! Let’s do another round of discovery 🔍 of what’s available in their Stylus suite ⚙️. We’ll implement a proxy using their contract 🪞!

3. What’s next for Stylusup 🚀? Stylusup is about to see a huge change 🔄, with a new emphasis on community tooling 🤝 within the ecosystem 🌐. Stylusup will see a transition into community ownership 👥, and will be developed further with an ambition to become the community hub 🏗️ for Stylus 💫.

4. We’ve been lucky 🍀 to feature Philip Stanislaus 🎤 in an interview! Philip is the founder of Oak Security 🌳, a leading team building security tools 🔐 and performing audits 🧾. They’re working on building StylusPort 🛠️, a tool to convert Solana contracts ⚡ to Arbitrum Stylus 🌀 without friction ✨.

Read on, and as always, if you have any feedback, please share it here:

To recap, Stylus is a Arbitrum technology for building smart contracts in Rust, Typescript, Zig, and C. Stylus lets you build smart contracts that are 10-50x more gas effective than Solidity smart contracts.

StylusPort, a tool to convert Solana projects to Stylus, is looking for people to fill out a 5 minute survey. If you’re building in the Stylus and Solana ecosystem, be sure to fill out their Typeform!

Scaffold Stylus

Scaffold Stylus is a project creation tool for a number of contracts and frontends, including a simple ERC20, a ERC721, Chainlink Data Feeds, and Chainlink VRF. They also provide a block explorer for local development, and a Wagmi frontend for interacting with the contracts made using their platform!

There are several templates that you can extend from, including:

• A ERC20 contract.

• A ERC721.

• A Chainlink price oracle frontend (and skeleton contract).

• A Chainlink VRF contract.

Check out an example dApp here:

This is the default interface from creation! As you can see, it includes a block explorer built into the automatically created UI, which you can scan to see transactions that happened on the local network (or Sepolia).

It also includes a page to invoke methods on the contract you create:

Make sure to check the site out and give it a shot:

OpenZeppelin’s 3.0 release!

OpenZeppelin have made their 3.0 release, and it’s fully audited! Congratulations to everyone involved with this! I’m going to use this opportunity to recap what’s possible today, and what’s going to be possible in their future roadmap. For development, we’ll be testing using ArbOS-Foundry. ArbOS-Foundry is a fork of Foundry

In the 3.0 release

I really encourage everyone to read the release notes on this! Alisander (the dev that is powering a ton of the development on this) has introduced a TON of new contracts and features to the package. These include (and this is a selection):

1. Proxies, with a proxy supporting the beacon pattern, and a proxy supporting the transparent upgradeability pattern.

2. Sets for efficient storage, much like their Solidity equivalent.

3. Traits for various token receivers that can be used with the various token receiving specs out there! These include the function needed to be used in a callback for ERC721, which is used by any spec-conforming ERC721 implementation if your contract has code, and the one for ERC1155.

Using the new proxies

Let’s do a quick overview of how to make use of the OpenZeppelin proxies. We’ll create a new repository using cargo stylus new, and after making some hygiene changes in line with my personal preference, we’ll cargo add openzeppelin-stylus, and then we’ll begin to use Stylus trait inheritance features to build a virtual tollbooth contract in line with how I imagine this piece of Ice from the game Netrunner is like:

Netrunner is a cyberpunk asymmetric card game where a player, a hacker (“Runner”), works to breach the security of the servers of another player, a Corporation. The Corporation is able to deploy security programs called Ice to protect their servers, which the Runner must circumvent using hacking programs called Icebreakers. You can play online for free at Jinteki.net! We’re going to use OpenZeppelin’s upgradeable proxy to implement a virtual toolbooth, like the card shown above.

To invoke any method on the underlying implementation of a proxy, the user must pay 3 DAI. If the user fails to pay the 3 DAI, they will be disconnected from the contract with a revert!

We’ll be using the UUPS proxy pattern for this, which is a type of proxy pattern where the implementation contract is the one that’s responsible for its upgradeability. This makes a lot of sense, since the strong point of Stylus is its performance, which I visualise like this:

Where the blue line is Stylus, and the green line is Solidity. Source? It came to me in a fever dream. This is how I internalise my thinking with the setup and gas costs of Stylus.

For a proxy contract, you don’t want to pay that setup gas cost that you have to pay to warm the Stylus execution engine up (which is a fixed number), since your job is to send the calldata to another contract using a delegatecall, a very simple operation relatively. So upgrades might be something better supported by the implementation here, where maybe the contract observes a metamorphosis-like pattern (where the contract tears itself down when criteria is met) or something similar.

The contract

To use the new proxy code to make a proxy ourselves, we must implement several traits, and make them invokable using the public macro. These are functions to allow the user to set the owner of this contract, which we need to upgrade the proxy, and to invoke trusted functions.

We first create our contract storage like so:

#[entrypoint]
#[storage]
pub struct Storage {
    pub fee_collector: StorageAddress,
    pub token: StorageAddress,
    pub fees_collected: StorageU256,
    ownable: Ownable,
    uups: UUPSUpgradeable,
}

We have three extra storage items beyond the two that we need for OpenZeppelin. One functions as a trusted role that has the power to invoke methods to collect fees collected in DAI. One stores the token address for DAI (that we could otherwise store as a constant if we so choose), and one contains a simple counter of fees collected, for demonstration purposes. It might be better to simply check the balance of the contract using the DAI ERC20 instead of maintaining a counter ourselves, but for our discussion, we’ll do it this way.

Following setting this in the storage of the contract, we can start to implement some functions for setup of the contract. Note that this contract does not have a constructor, which the implementation contract would have called! This calls the UUPS constructor, which prevents users from the implementation contract, who might have intended to call the proxy upgrade methods instead.

We implement our first implementation:

#[public]
#[implements(IOwnable, IUUPSUpgradeable, IErc1822Proxiable)]
impl Storage {
    pub fn init(
        &mut self,
        owner: Address,
        fee_collector: Address,
        token: Address,
    ) -> Result<(), Vec<u8>> {
        self.uups.set_version()?;
        self.ownable.constructor(owner)?;
        self.fee_collector.set(fee_collector);
        self.token.set(token);
        Ok(())
    }
}

This method invokes trusted functions on the storage items for the UUPS implementation (that does the fallback method) to set storage that indicates it should be impossible to invoke the methods responsible for proxy setup. It sets a storage slot intended for the storage of the logic contract, which has a nice side effect of preventing us from calling this setup function more than once. We implement the rest of the traits:

#[public]
impl IUUPSUpgradeable for Storage {
    #[selector(name = “UPGRADE_INTERFACE_VERSION”)]
    fn upgrade_interface_version(&self) -> String {
        self.uups.upgrade_interface_version()
    }

    #[payable]
    fn upgrade_to_and_call(
        &mut self,
        new_implementation: Address,
        data: stylus_abi::Bytes,
    ) -> Result<(), Vec<u8>> {
        self.ownable.only_owner()?;
        self.uups.upgrade_to_and_call(new_implementation, data)?;
        Ok(())
    }
}

In the code that does the upgrade and call, we could implement some additional access control there. In the above, it uses the ownable code to check if the sender is the owner of the contract. We need to implement some functions that ownable expects to support it fully. These functions implement the basics in OZ contracts:

#[public]
impl IOwnable for Storage {
    fn owner(&self) -> Address {
        self.ownable.owner()
    }

    fn transfer_ownership(&mut self, new_owner: Address) -> Result<(), Vec<u8>> {
        Ok(self.ownable.transfer_ownership(new_owner)?)
    }

    fn renounce_ownership(&mut self) -> Result<(), Vec<u8>> {
        Ok(self.ownable.renounce_ownership()?)
    }
}

Following the implementation code doing access control and setting slots, we need to implement the contract that reads the slot before a delegatecall. Since the implementation manipulates the storage slots, our proxy needs to check the standard location to know where to call into.

We can implement a simple Solidity contract:

bytes32 constant SLOT_LOGIC = bytes32(uint256(keccak256(’eip1967.proxy.implementation’)) - 1);

contract Proxy {
    address private feeCollector;
    IERC20 private token;
    uint256 private collected;
    uint256 private feeAmount;

    event TollPaid(
        address indexed payer,
        uint256 indexed amount
    );

    constructor(
        address _owner,
        address _feeCollector,
        address _token,
        uint256 _feeAmount,
        address _impl
    ) {
        bytes32 slot = SLOT_LOGIC;
        assembly {
            sstore(slot, _impl)
        }
        (bool success,) = _impl.delegatecall(abi.encodeWithSelector(
            IImpl.init.selector,
            _owner,
            _feeCollector,
            _token,
            _feeAmount
        ));
        require(success);
    }

    fallback() external {
        address impl;
        bytes32 slot = SLOT_LOGIC;
        assembly {
            impl := sload(slot)
        }
        require(token.transferFrom(msg.sender, address(this), feeAmount));
        emit TollPaid(msg.sender, feeAmount);
        collected += feeAmount;
        (bool success, bytes memory data) = impl.delegatecall(msg.data);
        if (data.length > 0 && !success) {
            assembly {
                revert(add(data, 0x20), mload(data))
            }
        } else {
            require(success);
            if (data.length > 0) {
                assembly {
                    return(add(data, 0x20), mload(data))
                }
            }
        }
    }
}

This simply forwards all calldata to the implementation address at the standard EIP1967 slot (computed at the top of the contract). It also calls the init function inside the implementation during the contract’s construction. It’s the code that actually enforces the tollbooth collection during the fallback operation, using a transferFrom each time it’s called. It also emits a handy event for monitoring how the tollbooth is performing.

The issue with this code is that it’s a pain to approve before each invocation of the contract. It might be better to have a calldata forwarder, or to restructure the caldata to include a permit blob beforehand. You could imagine that this code is useful for an administrative task though, or something like those “trick the AI to send you something” challenges.

Note how during the setup, we don’t actually set any values ourselves apart from the storage slot? This is because Stylus has 1-to-1 equivalence with the EVM, down to the storage layout! So our implementation contact can be fully responsible for its upgrades, as well as how the proxy is performing.

Testing Arbitrum Stylus with Forge Foundry

In today’s post, we’ll be testing using ArbOS-Foundry, a project developed by the team at iosiro. It lets us test Solidity and Stylus side by side, as first class citizens! It’s a fork of Foundry with the hope of eventually providing that experience there. We’ll be testing that the proxy is taking fees every time someone calls the implementation. We’ll be doing a later post on this, since ArbOS-Foundry is such a great opportunity for the space.

After pulling down the repo and installing everything (I just ran make build, which created the executables arbos-forge and arbos-cast in the target debug directory), I created this test:

import {SLOT_LOGIC, Proxy} from “../src/Proxy.sol”;

interface IArbFoundry {
    function deployStylusCode(string calldata artifact) external returns (address);
}

interface IProxy {
    function upgradeToAndCall(address newImpl, bytes memory data) external;
}

interface IHello {
    function hello() external returns (string memory);
}

contract TestErc20 {
    bool public wasSpent;
    function transferFrom(address, address, uint256) external returns (bool) {
        wasSpent = true;
        return true;
    }
}

contract World {
    function world() external returns (string memory) {
        return “World!”;
    }

    function proxiableUUID() external returns (bytes32) {
        return SLOT_LOGIC;
    }
}

contract TestProxy is Test {
    TestErc20 erc20;
    address impl;
    Proxy proxy;
    address impl2;

    function setUp() public {
        erc20 = new TestErc20();
        impl = IArbFoundry(address(vm)).deployStylusCode(”oz-proxies.wasm”);
        proxy = new Proxy(address(this), address(this), address(erc20), 1e6, impl);
        impl2 = address(new World());
    }

    function testImpl() public {
        assertNotEq(address(0), impl);
        assertEq(”Hello!”, IHello(impl).hello());
    }

    function testProxy() public {
        assert(!erc20.wasSpent());
        assertEq(”Hello!”, IHello(address(proxy)).hello());
        assert(erc20.wasSpent());
        IProxy(address(proxy)).upgradeToAndCall(impl2, “”);
        assertEq(”World!”, World(address(proxy)).world());
    }
}

This tests that we can upgrade, that we can invoke the functions on the implementation, and that we can use the proxy. You might notice that we implement a function called proxiableUUID in the second implementation. OZ give us some sanity checks, and this function returns the slot that’s responsible for the logic. This is so that the UUPS proxy knows for certain that we know what we’re doing. Once we do the upgrade in this example, we can’t go back and do another upgrade!

Thanks to the implementation-led mutability of the deployment, we can have code that might mutate itself to become immutable after a release cycle or an audit for example. This code captures that phenomenon!

Before we run our tests, we’ll first create a Makefile to build our code before testing:

oz-proxies.wasm: $(shell find src -name ‘*.rs’)
	@rm -f oz-proxies.wasm
	@cargo build --target wasm32-unknown-unknown --release
	@wasm-opt \
		--dce \
		--rse \
		--signature-pruning \
		--enable-bulk-memory \
		--strip-debug \
		--strip-producers \
		-Oz target/wasm32-unknown-unknown/release/oz_proxies.wasm \
		-o oz-proxies2.wasm
	@wasm2wat oz-proxies2.wasm >oz-proxies.wat
	@wat2wasm oz-proxies.wat >oz-proxies.wasm
	@rm -f oz-proxies2.wasm oz-proxies.wat

Why do this? A step is needed before using the raw wasm output with arbos-foundry right now. The node does a processing step of using the wasm2wat/wat2wasm toolchain to compile the WASM code to a SEXP-like representation, the WAT format, then back. I’m assuming this is needed to strip some bits of code as a side effect, though it’s not known to me what the literal need is. We can make a testing script that invokes the Makefile and the tests like so:

#!/bin/sh -e

make -B

arbos-forge test $@

In our code creation pipeline, we first create the code using a Makefile that runs Cargo to compile this wasm blob. This test then picks up the file, deploys it, then constructs the Proxy. With a fake ERC20 that checks if the token was fake transferred. Cool!

What’s next for Stylusup?

Stylusup is undergoing a huge change! Stylusup will transition from being a on-ramping page for Stylus to becoming a community ecosystem landing page. The development of the new page is still in progress, but we’ve created a new community organisation to take ownership of it! You can see it here: https://github.com/stylus-developers-guild

Currently, we have the following members:

1. Alex (this author), CTO of Fluidity Labs (building Superposition), https://fluiditylabs.io

2. Tolga, Founder of The Wizard, https://thewizard.app

3. David, Senior Product Manager at Offchain Labs, https://www.offchainlabs.com/

The goal is to transition the site to a new format where we can aggregate projects from the community in one place, with a transparent listing process based on pull requests. We have something cooking, and I can’t wait to share it with you! A very appreciate thank you to Tolga and David for supporting this!

Interview with Philip Stanislaus

Who are you, and what do you do?

I’m Philip Stanislaus, co-founder and Managing Director of Oak Security.

My journey began in traditional software engineering, freelancing for over a decade and co-founding several startups. I later transitioned into blockchain, working as a developer at Centrifuge and architecting projects like Snowfork. I then co-founded Oak Security to help Web3 projects build safely and confidently by offering security audits, penetration testing, training, and other related services.

Recently, we launched StylusPort with Range, a framework that simplifies migrating Solana programs to Arbitrum’s Stylus environment. My focus is enabling developers to innovate while maintaining security, efficiency, and interoperability across ecosystems.

What Web3 ecosystems have you worked in?

I’ve worked in Ethereum, Arbitrum, Solana, Cosmos, Polkadot, and Flow. Currently, Arbitrum is a key focus because of its growing adoption, developer-friendly environment, and the ability to deploy Rust-based smart contracts via Stylus. StylusPort helps Solana developers bring their Rust projects into Arbitrum without rewriting in Solidity, bridging ecosystems efficiently.

What are your impressions of working with Stylus, good and bad?

Stylus is a breakthrough for Rust and C++ developers wanting to build without EVM constraints. Its low-cost computation, strong tooling, and Ethereum liquidity enable use cases that were previously out of reach.. Moving from another ecosystem to Arbitrum Stylus is not straightforward, though. We are building StylusPort to address that by providing clear guidance and AI-assisted tooling to reduce friction. Overall, Stylus is a vibrant, exciting ecosystem with huge potential.

What software do you use?

I primarily use Visual Studio Code with Rust and Solidity extensions. For project management and collaboration, Google Docs/Sheets and GitHub are essential. During our security work, we use numerous tools, like static analyzers, fuzzers, formal verification tools, and LLMs.

What hardware do you use?

I connect a MacBook to a remote machine using VSCode’s Remote Development using SSH. Our LLMs run on more powerful remote machines with GPU support.

How can we get in touch with you?

You can reach me on LinkedIn, X/Twitter, or via email at philip@oaksecurity.io. I enjoy connecting with developers and founders who are building cross-chain projects, securing protocols, or exploring the adoption of Stylus and Arbitrum. If you are interested in using or giving feedback on StylusPort, please get in touch!

What’s a piece of advice you’d give someone new to Web3?

Focus on both product market fit and security from the beginning. Web3 is exciting, but lasting success comes from solving real problems and prioritizing safety. Focus on creating value and keeping your users’ funds and your reputation safe, not just following trends.

To get in touch with the Oak Security team, you can check their website at https://www.oaksecurity.io/.

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!

None of this is real. If you’re reading this, you’re in a coma, and you need to wake up! We love you.

Let’s set the scene: you’re building something complex, and the lion’s share of the codesize lives in a single function. You are right up against the limit. Your boss (Ivan in this case) wants extra features (cross-chain features, anyone?) but you’re not able to push things any further.

How can we go lower? The tactic in this case might be to use a reentrant pattern within your code, and a proxy entrypoint. With this method, we can break up a function that’s quite large into small pieces that are gradually executed, until the final result is handed back to the user. This is an extremely effective method for a large chained operation! You can take any complex interaction, and break it up into contract part 1, part 2, part 3, and so forth. You store each step of the operation using transient storage, which you read like registers.

Why use transient storage instead of reusing the calldata to the contract next in the chain? Decoding is often the number one source of codesize overhead, and with a transient storage method you can completely remove the classic entrypoint, instead preferring to check registers instead.

Transient storage operation is a custom storage type similar to memory in the EVM, except that it lives for the length of the transaction. It could be used to protect a contract from reentrancy, implement role based authentication, and more. It’s accessed using the TSTORE and TLOAD functions, two functions that allow addressing with a 32 byte key, like the classic EVM storage.

This feature is not available in the SDK, but it is in the runtime. To use this feature in this context (with reentrancy), you must disable reentrancy guard using a feature, and it’s not documented, and even putting aside Stylus it’s an advanced technique.

Let’s peer behind the curtain and explore a strategy to make this work. Our contract (repo here) will look like this:

A proxy will handle dispatch into two different contracts depending on the function that’s used. The proxy will need to understand which functions go where, a method we’ll leave up to the implementor. We have implemented different approaches for proxies in the past, with explicit function matching in Longtail (our first foray into Stylus, a bit yuck in retrospect), hardcoded magic byte matching in 9lives with a beacon, and in a previous release a classic proxy, and purely dynamic matching in Passport (which serves as the impetus for this method). Superposition Passport is unique in that it leverages a Borsh decoding-style method similar to Solana entrypoints, which it uses to know when to decompress incoming calldata as opposed to a classic 4byte selector match, so we won’t elaborate on that further today.

Our contract will implement behaviour like this:

In a real world example, any interaction that’s multiple step could be broken up this way. In Superposition Passport, we do some cryptography heavy lifting, coming up with some facts about the user, then we use this method to initiate the next part of the contract chain, a function that begins a cross-chain asset transfer.

In our code, we’ll simply have some code inside the first contract generate a number, and the second step of the contract return it to the user. This is a drop-in for any complex behaviour you might implement this way. Though a serious user might prefer to avoid the entrypoint decoder (like we discussed at the beginning of this article), we’ll continue using it here to keep the discussion simple. We’ll show off how to replace the entrypoint with something way more codesize efficient in a future Extreme Codesize Optimisations post.

A refresher on reentrancy

Reentrancy is the practice of a contract calling itself. It often makes headlines in the context of an exploit that took place when a chain of contract interruption was broken thanks to a contract calling back to its original calling contract when it shouldn’t have, before the state has been persisted. We won’t be using it this way of course! Reentrancy is useful for reducing codesize and recursive patterns that would be otherwise difficult to implement in size-constrained contracts.

We can implement a reentrant contract in the Solidity context:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract Token {
    function invoke() external {
        Counter(msg.sender).kickoff(this);
    }
}

contract Counter {
    uint256 public counter;

    function kickoff(Token _invoker) external returns (uint256) {
        if (msg.sender == address(_invoker)) {
            counter++;
        } else {
            _invoker.invoke();
        }
        return counter;
    }
}

This code is visually similar to process forking and threading in the Unix context. The Counter contract is started using the kickoff function, which checks to see if the invoker address is the caller, and if it’s not, it calls the function “invoke” on the invoker. The invoker contract then calls the kickoff function again on the Counter, which then bumps the counter, which it returns. This returns 1.

Reentrancy in Stylus

To use reentrancy in Stylus, we need to enable a specific feature that disables the check for reentrancy in the contract. We do this by setting a feature in stylus-sdk to be reentrant:

// Cargo.toml

[dependencies]
...
stylus-sdk = { version = "0.9.0", features = ["reentrant"] }

This totally disables the built-in check that checks for reentrancy in the contract. The Stylus SDK developers wisely made the decision to protect us from this huge vulnerability for most contracts by default, and we’re right on the edge, so we have to disable it.

Reentrantly entering a contract again is as simple as invoking itself:

#[entrypoint]
#[storage]
struct TStoreExample;

sol! {
    function hello() external view returns (string);
}

#[public]
impl TStoreExample {
    pub fn hello() -> U256 {
        U256::from(123)
    }

    pub fn reentrant(&self) -> FixedBytes<32> {
        let addr = self.vm().contract_address();
        FixedBytes::from_slice(
            &self
                .vm()
                .static_call(&self, addr, &helloCall {}.abi_encode())
                .unwrap(),
        )
    }
}

You can see that we return a fixed bytes word instead of a Vec<u8> here. The reason is that encoding a Vec<u8> will literally encode a vector of u8 if it’s used as the Ok return type, something to be mindful of generally. Using a FixedBytes word when we’re trying to return the calldata here enables us to avoid decoding the return type.

Transient storage in Stylus

Transient storage use in Stylus is possible to use by explicitly using a hostio that’s unavailable to us ordinary SDK plebs, transient_load_bytes32 and transient_store_bytes32.

We can implement support for the missing functions like this:

#[cfg(target_arch = "wasm32")]
#[link(wasm_import_module = "vm_hooks")]
unsafe extern "C" {
    fn transient_load_bytes32(key: *const u8, dest: *const u8);
    fn transient_store_bytes32(key: *const u8, value: *const u8);
}

#[cfg(not(target_arch = "wasm32"))]
pub fn transient_load_bytes32(key: *const u8, dest: *const u8) {}

#[cfg(not(target_arch = "wasm32"))]
pub fn transient_store_bytes32(key: *const u8, value: *const u8) {}

fn tload(key: U256) -> U256 {
    let mut dest = [0u8; 32];
    unsafe {
        transient_load_bytes32(key.to_be_bytes::<32>().as_ptr(), dest.as_mut_ptr());
    }
    U256::from_be_bytes(dest)
}

fn store(key: U256, val: U256) {
    unsafe {
        transient_store_bytes32(
            key.to_be_bytes::<32>().as_ptr(),
            val.to_be_bytes::<32>().as_ptr(),
        );
    }
}

We could’ve used any type here instead of U256 (including FixedBytes) technically. This code simply uses the TSTORE and TLOAD functions. tload and tstore wrap the code by getting the array underneath the complex U256 type as a big endian array (the default endianness format for the EVM).

We can simulate it like this:

#[entrypoint]
#[storage]
struct TStoreExample;

#[public]
impl TStoreExample {
    pub fn begin(&self) -> U256 {
        let k = U256::from(123);
        store(k, U256::from(456));
        tload(k)
    }
}

The code returns 456 here, as you might imagine! This will be the case for the life of the transaction:

#[public]
impl TStoreExample {
    pub fn hello() -> U256 {
        tload(U256::from(123))
    }

    pub fn reentrant(&self) -> FixedBytes<32> {
        store(U256::from(123), U256::from(456));
        let addr = self.vm().contract_address();
        FixedBytes::from_slice(
            &self
                .vm()
                .static_call(&self, addr, &helloCall {}.abi_encode())
                .unwrap(),
        )
    }
}

Bringing the technique together for our POC

So we can start to combine the reentrancy with the transient storage pattern here. Now, what if we were to split up our contract into two contracts:

#[cfg_attr(any(feature = "contract-1", feature = "contract-2"), entrypoint)]
#[storage]
struct TStoreExample;

sol! {
    function hello() external view returns (string);
}

#[cfg_attr(feature = "contract-1", public)]
impl TStoreExample {
    pub fn hello() -> U256 {
        tload(U256::from(123))
    }
}

#[cfg_attr(feature = "contract-2", public)]
impl TStoreExample {
    pub fn reentrant(&self) -> FixedBytes<32> {
        store(U256::from(123), U256::from(456));
        let addr = self.vm().contract_address();
        FixedBytes::from_slice(
            &self
                .vm()
                .static_call(&self, addr, &helloCall {}.abi_encode())
                .unwrap(),
        )
    }
}

#[cfg(not(any(feature = "contract-1", feature = "contract-2")))]
compile_error!("contract-1 and contract-2 not enabled!");

This code uses feature flags and a Stylus trick to allow us to compile either contract 1 or contract 2 at a given time. The Stylus team are adding the ability for multiple contracts to be compiled at any time, but for now, this approach is sufficient. In Passport, we’ve discovered other techniques for this that we’ll elaborate on another time.

We need a proxy that lets us do dispatch into either contract:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.20;

contract Proxy {
    address public immutable FACET_HELLO;
    address public immutable FACET_REENTRANT;

    constructor(address _hello, address _reentrant) {
        FACET_HELLO = _hello;
        FACET_REENTRANT = _reentrant;
    }

    function directDelegate(address to) internal {
        assembly {
            calldatacopy(0, 0, calldatasize())
            let result := delegatecall(gas(), to, 0, calldatasize(), 0, 0)
            returndatacopy(0, 0, returndatasize())
            switch result
            case 0 {
                revert(0, returndatasize())
            }
            default {
                return(0, returndatasize())
            }
        }
    }

    function hello() public returns (uint256) {
        directDelegate(FACET_HELLO);
    }

    function reentrant() external returns (uint256) {
        directDelegate(FACET_REENTRANT);
    }
}

This proxy is of the kind that explicitly loads a facet for the function given. Let’s deploy everything:

#!/usr/bin/env -S rc -e

SPN_SUPERPOSITION_URL=https://testnet-rpc.superposition.so
SPN_SUPERPOSITION_KEY=`{QEP superposition}

make

contract_1=`{./deploy.sh contract-1.wasm}
contract_2=`{./deploy.sh contract-2.wasm}

forge create \
	--json \
	--broadcast \
	--rpc-url $SPN_SUPERPOSITION_URL \
	--private-key $SPN_SUPERPOSITION_KEY \
	src/Proxy.sol:Proxy \
	--constructor-args $contract_1 $contract_2 \
		| jq -r .deployedTo

In my case, the proxy contract was deployed at 0x70f694eA46a11965067aF701d5F410E314262b72 on Superposition Testnet. Testing it, we can see it works:

cast call --rpc-url https://testnet-rpc.superposition.so 0x70f694eA46a11965067aF701d5F410E314262b72 'reentrant()(uint256)'

Side note, it’s a terrible practice to take a private key as an argument. Linux (and BSD to an extent) systems have total transparency for running processes on the system by default, and I’m a repeat offending criminal for building tools that ignore this fact. It’s better to use environment variables!

I hope this very short article engages your imagination with how far you can push contracts to reduce codesize in the Stylus context! The sky is the limit with this technique.

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!

Thumbnail photo by Sixteen Miles Out on Unsplash. Thank you!

1. 🚀 CodeTracer launched their Stylus deployment! ⏳ Time-travelling debugging is now possible — interactively view your contract’s execution! Super cool! 🕹️ We’ll be testing this with a contract that generates 🏰 rooms for priories.

2. ⚡ AssemblyScript (very TypeScript-like 💻) is now live thanks to the WakeUp Labs team! 🔥 They’ve been shipping tons of cool stuff — we’ll feature them with a 🧮 test contract that runs a lightweight on-chain NFT recommendation engine 🎨.

3. 🎤 Interview with Gonza from the WakeUp Labs team 🎉 Gonza is the co-founder of WakeUp Labs! 🙌

Read on, and as always, if you have any feedback, please 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 interoperability with Solidity!

Click here to learn more: https://arbitrum.io/stylus

You can get started very quickly using a (community maintained) setup website at https://stylusup.sh, with official resources at https://arbitrum.io/stylus, or fully online, without any setup, using The Wizard at https://thewizard.app/!

StylusPort, a tool to convert Solana projects to Stylus, is looking for people to fill out a 5 minute survey. If you’re building in the Stylus ecosystem, be sure to fill out their Typeform:

CodeTracer, time travelling interactive debugging (part 1)

Wow! CodeTracer have released an extension for their time travelling debugger, which you should check out here:

This is really amazing! Time travelling debugging is the process of stepping through and backwards in your contract’s execution life to see the setting of variables, the execution of calldata, and more. Solidity developers might be familiar with Tenderly, which is a product that lets you step through your code’s execution, and this is similar, except it’s way more powerful in this author’s opinion!

This is a full on IDE-style code explorer that you can use to see line annotations as you peruse your source code, fully contextual, even letting you see inside your loop as it executes! In this post, we had some issues with the testing of the contract I wrote for CodeTracer, so this is a part one of this series, setting the scene mostly.

How to get started

I found instructions that I could’ve followed here:

Though, I noticed that it was possible for me to download a AppImage, so I grabbed that and installed it to my PATH at $HOME/.bin:

A sample contract

We will create a fictional room generator for the grounds of a religious facility called a priory. Full disclosure, I had some fun learning about the history of monasteries for this little snippet, so if you’re not interested in this, feel free to skip!

You can find the repo here.

A priory is a type of monastery that existed before a period of the Protestant Reformation in Europe, before Henry VIII dissolved monasteries between 1536 and 1541. It was a type of religious compound that was used as the administrative hub of a monastic order, so it had a practical function for administrative tasks, and scholarly research, as well as religious practice. Monasteries are interesting in that they observed isolation from their communities, despite forming the intellectual base for the community that housed them, often existing as a vehicle for the passing down of knowledge to the next generation, and this created an interesting social interplay.

Monasteries had to be mostly self sufficient, and to sustain themselves, would either receive gifts from the community, or they would farm and maintain land themselves. Farming would take time from their spiritual obligations, and monasteries were considered so essential for their societies, so it was considered commonplace for them to receive gifts and entitlements. They also had a variety of internal functions, including clothing their staff, feeding them, and maintaining their mental and physical well-being.

In communities, the monasteries would run around the clock, receiving visitors for different purposes, these purposes of which include official visits, health care, the receiving of tithes and such, and each monastery would function according to their own internal Rules and regulations, which varied from monastery to monastery.

Our fictional priory room generator will generate the following spaces, remaining mostly focused on its intended management function:

1. A place for reading, a place for the storage of scrolls, books, and derivative religious texts. The internals of this place could be a stock room with chests, bookshelfs, desks for reading, beds for napping, and desks equipped with writing material.

2. A place for financial controlling, the storage of rare grains, the storage of entitlements, original religious texts, and legal documentation relevant to the broader community. The internals of this place might be a bed for the financial controller to sleep in instead of the dormitories (for security reasons), various locked chests, desks for writing and for reading, a desk for the measurement, an altar, and samples of goods.

3. A dormitory for the monks to sleep in. The dormitory is simple in that it’s filled with prayer stools (the monks would pray before sleep), beds, wash basins, and a desk with a bell to summon the monks to Matins, a nightly service at 5am.

4. A kitchen. The kitchen should be made up of fireplaces, cauldrons, tables for the preparation of bread, and on occasion, meat, if the monks were undertaking manual labour (like maintaining some farmland). It should also include shelves for jars, and buckets and barrels.

Each of these functions will observe restrictions from the physical layout of which they were designated, inside the space we provide for the priory. We won’t include a section for the performance of the Sacraments, as in my understanding, this function is external to the space, as our focus is administration.

Our contract will take as seed a number supplied by the author during the creation of the contract (with the constructor method), and the block timestamp. This randomness seed will serve as a restriction of the dimensions of the priory, and our algorithm will generate the layout of the room of a priory as a SVG as ASCII art.

The creation of the space will be a bruteforce method of trying to insert different items inside a room. If the function fails to make the insertion, it will simply try again, so less attempts = more free space in each subsection.

One of the myriad strengths of working with Stylus is how higher level algorithms can be built succinctly in ways that would be difficult to implement in Solidity. Our choosing of the placement of the items in the room can be implemented using randomness with the ChaCha algorithm, and by combining multiple iterators together to create a generator.

Our priory generator

Our type will look like this:

pub enum ReadingRoom {
    Stocks,
    Bookshelf,
    DeskForReading,
    Bed,
    DeskForWriting,
}

pub enum FinancialRoom {
    Storage,
    Bed,
    LockedChest,
    DeskForReading,
    DeskForWriting,
    DeskForMeasurement,
    Altar,
    SampleCollection,
}

pub enum Dormitory {
    WoodenBedstead,
    PrayerStool,
    WashBasin,
    DeskWithBell,
}

pub enum Kitchen {
    Fireplace,
    Cauldron,
    TableForBread,
    TableForMeat,
    Shelf,
}

pub enum Room {
    ReadingRoom(ReadingRoom),
    FinancialRoom(FinancialRoom),
    Dormitory(Dormitory),
    Kitchen(Kitchen),
}

In breaking tradition with our usual kind of post, we won’t be discussing the implementation of the contract and the generator, but instead giving a high level description, then focusing on the testing of the contract.

Our contract will expose the following method (and constructor):

constructor(uint256 seed);

function generate() returns (string memory);

The generate function will read from the current timestamp, and the seed in contract storage, which it will use to seed a ChaCha random number generator, a fast random number generator for 32 bit word machines (like the Stylus environment). The generate function will return a SVG string. An invocation of the generate function will update the contract’s internal seed.

A generated room could look like the following:

"""""""""
Dormitory
"""""""""
|  uubbbb  |
| bbbb     |
| uubbbb uu|
|      !   |
|      !!!!|
|  bbbb    |
|  bbbb    |
|  uu bbbb |
|  bbbb uu |
|          |

Very Dwarf Fortress-like! Note that the u is means a wash basin, and b means a bed. ! means a desk. A kitchen is similar:

"""""""
Kitchen
"""""""
|ooo    hh |
|ooo       |
|          |
|     hh   |
|  hh  f f |
|   f ffff |
|   fff    |
|f f       |
|fff       |
| ttt  TTTT|

This type of code provides us with ample opportunity to manipulate its execution, so it’s a good usecase for CodeTracer I imagine.

Using CodeTracer

Diving into the repo, I can see this works using a Lisp-like language as scripting glue, a great design decision (imo) for building applications like this.

Running CodeTracer’s downloaded AppImage (and skipping the installation prompt since CodeTracer is already in my PATH at $HOME/.bin),

I started experimenting with the code, and made a deployment that will go unused to Superposition Testnet. I found that the only way to get the debug tooling into the program is to do a deployment through it, so I went to initiate a deployment using ct arb deploy.

I had some issues where the program couldn’t find some trace artifacts in the tmp directory, so I ran cargo stylus check. I found that check wasn’t finding my compiled wasm blob in the deps directory, so I set my Cargo.toml file to be a crate-type of rlib, to create a Rust dynamic library. This created a wasm blob in the deps directory for us to use.

I then used ct arb deploy to deploy to the local Nitro testode, which created the deployment. I noticed that to do the deployment, I needed to support the feature export-abi, so I added it (the previous entrypoint would simply run the generator with pre-seeded randomness). I also removed the constructor, which seemed to cause problems (and we don’t support this yet on SPN Testnet).

With the deployment out of the way, it relocated the wasm blob to the right location! So I was able to continue with development. I was a little disappointed to see that the only way for me to use my code here was to do a deployment using the tool (also that the command line argument passing for the RPC url is non-functional, so I was stuck in an offline situation), but I imagine with a later release this will change.

I went to invoke the contract:

cast send --private-key 0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659 --rpc-url http://127.0.0.1:8547 0x11b57fe348584f042e436c6bf7c3c3def171de49 'generate()'

And encountered a panic! A wasm stack trace! It seems we blew out the stack potentially. Let’s see if we can tweak the compilation of the contract to use less of it. I adjusted the stack size using a new link argument in .cargo/config.toml:

[build]
target = "wasm32-unknown-unknown"
rustflags = [
  "-C", "link-arg=-zstack-size=32768",
  "-C", "panic=abort",
]

And this unfortunately caused a out of bounds memory access in the simulator! It seems that there are some differences between the simulation of the WASM here, and what’s on-chain. We’ll revisit this in the future, so this will make up a part one of this series.

AssemblyScript on Stylus

AssemblyScript is a Typescript-like language that’s intended for WebAssembly. WakeUp Labs have been hard at work, and have brought it to Stylus! So, we can use TypeScript on Arbitrum. Very exciting!

The way the code works is with a AssemblyScript code generation pipeline that generates code with stubbed out native ArbOS functions (like keccak, getting the sender, etc), and they’ve built high level classes including types we use in the EVM (like the U256 type, Bytes, String, etc), that is then fed to an optimising pipeline, that eventually spits out WASM code we can deploy. The team have added state and visibility selectors, and have also built a online introspective tool (and eventual development webapp) at https://as-stylus-playground.wakeuplabs.link/ (featured below), which you can use to introspect your code to see the generated output of your contract development.

Using WakeUp Labs’ AssemblyScript on Stylus, you can develop code with visibility and state selectors, and do more. It’s currently in alpha! We’ll include some links for you to check out at the end of this section of the post.

Introduction

Together, we’re going to build a smart contract that helps us perform on-chain recommendations of NFTs. We can use this to make a simple on-chain NFT recommendation algorithm. Imagine we have a group of NFT influencers:

1. Hunter, from Offchain Labs.

2. Ivan, from Superposition.

3. Churro, also from Offchain Labs.

4. Marko (Blazeaster), from Superposition.

You can find the repo here!

These NFT influencers will shill some NFTs to their communities. How can you, a user, know which NFT influencer to listen to the most? Answer: we implement an algorithm that computes the similarities between points in a “preference space”, aka, a Euclidean Distance Score. This is the type of calculation that would be done at scale using a time series database, prior to the advent of machine learning at large.

Let’s pick the top few NFTs by market cap, and use Q1 to generate a random dataset of ratings out of 10:

name,CryptoPunks,Bored Ape Yacht Club,Infinex Patrons,Pudgy Penguins,Chromie Squiggle by Snowfro,Autoglyphs,Fidenza by Tyler Hobbs,Moonbirds,Lil Pudgys
Hunter,8,4,2,7,6,8,9,5,0
Ivan,3,3,1,7,6,0,3,9,3
Churro,6,9,3,3,2,5,3,5,7
Marko,9,6,9,9,0,1,5,6,3

These rankings look like this, if we display it as a scatter graph:

How do we make sense of this noise, and find a best fit situation for a would be user looking to buy a NFT per the advice of one of our influencers here? Let’s dive in!

Installation

I visited AssemblyScript’s getting started documentation at https://as-stylus.wakeuplabs.io/Getting%20Started/quick-start to create a fresh project:

npx @wakeuplabs/as-stylus generate nft-recommendation

This creates a directory called “nft-recommendation” in the local directory. I appreciated how simple it was to get started using this, I didn’t have to install any extra tools or anything!

The directory contained the following:

total 60K
-rw-rw-r--  1 user   89 Aug 25 22:31 tsconfig.json
-rw-rw-r--  1 user  578 Aug 25 22:31 package.json
-rw-rw-r--  1 user  468 Aug 25 22:31 contract.ts
-rw-rw-r--  1 user  41K Aug 25 22:31 package-lock.json
drwxrwxr-x 78 user 4.0K Aug 25 22:31 node_modules

So, I jumped into contract.ts to get started with editing. The example contract looked like the following:

 // @ts-nocheck

@Contract
export class Counter {
  static counter: U256;

  constructor() {
    counter = U256Factory.create();
  }

  @External
  static increment(): void {
    const delta: U256 = U256Factory.fromString("1");
    counter = counter.add(delta);
  }

  @External
  static decrement(): void {
    const delta: U256 = U256Factory.fromString("1");
    counter = counter.sub(delta);
  }

  @View
  static get(): U256 {
    return counter.toString();
  }
}

According to StackOverflow’s 2024 technology survey, JS ranked as the most popular programming language for developers, with TypeScript coming in fourth place, being beaten out by Python, and HTML/CSS. To WakeUp Labs are poised to onboard a TON of developers to Arbitrum with this technology!

I built the reference contract with:

npx @wakeuplabs/as-stylus compile contract.ts

Wow, it even verified the contract as well using the Sepolia endpoint! I did a test deployment to Arbitrum Sepolia (this seems to be the only supported external network right now) with:

npx @wakeuplabs/as-stylus deploy contract.ts

Which will prompt you for your private key as a argument using a TUI-like experinece (I had to use a terminal emulator here). And wow, it deployed without any issues! This has been an extremely seamless experience.

Implementing our contract

First, we’ll implement a reference function, in Python. We’ll bake our dataset and implement the following:

import math

votes={
	"Hunter": [8,4,2,7,6,8,9,5,0],
	"Ivan": [3,3,1,7,6,0,3,9,3],
	"Churro": [6,9,3,3,2,5,3,5,7],
	"Marko": [9,6,9,9,0,1,5,6,3]
}

def distance(x, y):
	# sum each nft: math.pow(votes[x][i] - votes[y][i], 2)
	return 1 / (1 + math.dist(votes[x], votes[y]))

In Python, we get a simple function inside the math library which lets us quickly get the Euclidean Distance score between a dataset. We do this operation of division to “normalise” the results, so that the numbers aren’t arbitrarily large. In the AssemblyScript code, we won’t be doing this operation to avoid floats, but also since U256 is quite large and we should be fine for space.

This code lets us determine the similarities between two datapoints in our set, for example, if we were to run this program:

>>> reference.distance("Hunter", "Marko")
0.07142857142857142

If we were to compute the Euclidean Distance score between everyone and Ivan:

>>> for n in votes:
>>>	if n == "Ivan": continue
>>>	print(f"{n},{distance("Ivan", n)}")

Hunter,0.07502535103270168
Churro,0.07844773813482285
Marko,0.07263669959755374

Which looks like this visually, with the most similar NFT influencer having the lowest score:

So we can see that Marko is the most similar to Ivan! Recommendation algorithms can use this method to sample a user’s interaction with a product, find a group that best fits them in terms of similarity scores, then recommend products that create the most conversions for them.

We’ll implement a contract that has the following functions:

function registerInfluencer(uint256 nftId, uint256 score) external;

function registerUser(uint256 nftId, uint256 opinion) external;

function getMostSimilar(address user) external view returns (address mostSimilar);

So far, the tower of operations that the U256 type supports seem to be the following, and we don’t have any power of operations available yet (the team are building the software in alpha):

So our first function will be a simple pow function using a loop. We’ll create a contract that looks like the following for the state:

@Contract
export class NftRecommendation {
  static influencerCount: U256;
  static influencerIds: Mapping<Address, U256>;
  static influencerAddrs: Mapping<U256, Address>;
  static scores: MappingNested<U256, U256, U256>;
  static opinions: MappingNested<Address, U256, U256>;
}

This contract lets us store the NFT count that our influencer group have recorded their thoughts on, record the influencer themselves, and also store the scores for each NFT, using the sender address. We need to have a count since arrays are not implemented yet here. We have a mapping for scores (per recorded influencer id), and for opinions (per end user thoughts on NFTs). We need to implement it this way until arrays are available as calldata arguments.

We add a constructor to let the user determine how many NFTs are in the recommendation set:

constructor(count: U256) {
  nftCount.set(count);
}

And we implement a function that lets us register an influencer, including a custom revert Error type, and require function:

@Internal
@Pure
static requireNftCountScore(i: U256, score: U256): void {
  if (i > nftCount) {
    TooHighNft.revert(i);
  }
  if (score > U256Factory.fromString("10")) {
    TooHighScore.revert(score);
  }
}

@External
static registerInfluencer(i: U256, score: U256): void {
  requireNftCountScore(i, score);
  if (influencerIds.get(msg.sender) == U256Factory.create()) {
    influencerCount = influencerCount.add(U256Factory.fromString("1"));
    influencerIds.set(msg.sender, influencerCount);
    influencerAddrs.set(influencerCount, msg.sender);
    InfluencerRegistered.emit(msg.sender);
  }
  ScoreSet.emit(msg.sender, i, score, influencerCount);
  scores.set(influencerIds.get(msg.sender), i, score);
}

This function counts the amount of influencers we have tracked, then increases the number each time a new influencer is added. We use a two nested mapping to make this easier. We defined the event and error type outside the scope of the contract, with:

@Event
export class InfluencerRegistered {
  @Indexed influencer: Address;
}

@Event
export class ScoreSet {
  @Indexed scorer;
  @Indexed nft;
  @Indexed score;
}

@Error
class TooHighNft {
  no: U256;
}

@Error
class TooHighScore {
  amt: U256;
}

It’s great that we can define the visibility and whether an event is indexed or not here!

We need to define some code that lets an end user define what they think about a NFT:

@External
static registerUser(i: U256, opinion: U256): void {
  requireNftCountScore(i, opinion);
  opinions.set(msg.sender, i, opinion);
}

We can keep this pretty simple.

We need to implement our pow function after setting the amount of NFTs we want to record the opinions of, so, we implement this code:

  @Internal
  @Pure
  static pow(x: U256, y: U256): U256 {
    const one = U256Factory.fromString("1");
    let acc = U256Factory.fromString("1");
    for (let i = U256Factory.create(); i < y; i = i.add(one)) {
      acc = acc.mul(x);
    }
    return acc;
  }

This code uses a loop to compute the power of results, which we need for our similarity calculation.

Finally, we can start to implement our getScore function, which will use the power of function with an accumulator to compute the similarity scores of the set of the users for the user given, then return the address that has the greatest similarity:

@External
@View
static getScore(user: Address): Address {
  const zero = U256Factory.create();
  const one = U256Factory.fromString("1");
  const two = U256Factory.fromString("2");
  let topId = zero;
  let topScore = zero;
  for (let influencerI = one; influencerI <= influencerCount; influencerI = influencerI.add(one)) {
    let sum = U256Factory.create();
    for (let nftI = zero; nftI < U256Factory.fromString("10"); nftI = nftI.add(one)) {
      const influencerScore = scores.get(influencerI, nftI);
      const userScore = opinions.get(user, nftI);
      let abs = U256Factory.create();
      if (influencerScore > userScore) abs = influencerScore.sub(userScore);
      else abs = userScore.sub(influencerScore);
      sum = sum.add(pow(abs, two));
    }
    if (topScore == zero || topScore > sum) {
      topId = influencerI;
      topScore = sum;
    }
  }
  return influencerAddrs.get(topId);
}

This code literally goes through each influencer, then compares the top most similar user against what’s stored as the current top user.

For the joy of it, let’s deploy our contract like so:

npx @wakeuplabs/as-stylus deploy contract.ts --constructor-args 9

Which prompts me again for my private key, and deploys correctly!

We can invoke the method to see if it generates the events we want (I deployed the contract to 0x605638d05aee4aeaf9bb1784b0ec0e2727b1d84b, without using the constructor feature, since SPN testnet doesn’t have this feature right now):

cast send --private-key <privatekeyhere> --rpc-url https://testnet-rpc.superposition.so 0x605638d05aee4aeaf9bb1784b0ec0e2727b1d84b 'registerInfluencer(uint256,uint256)' 0 10

Wow! I can see the generated events in my transaction receipt here! Very impressive.

Testing

To make a recommendation, we’d first ask a user to provide some thoughts on the various NFTs that we’re selling here. We’re going to ask our friend Erik what he thinks about our NFT set.

CryptoPunks,Bored Ape Yacht Club,Infinex Patrons,Pudgy Penguins,Chromie Squiggle by Snowfro,Autoglyphs,Fidenza by Tyler Hobbs,Moonbirds,Lil Pudgys
8,2,0,8,0,0,0,6,9

When I asked my friend why he rated some NFTs 0, the reason is that he hadn’t heard of them before. Let’s build a program to load our example set, and then our user into the contract. We’ll create some accounts and prefund to test the contract on-chain!

We’ll create a script that makes the recommendation for each of the accounts, and then is invoked to get the recommendation for the main user. The script uses several private keys to submit on-chain recommendations, then from the sending private key, asks the contract for the address of who’s the closest NFT recommender by address.

It was around this point that Franco from the WakeUp Labs team provided me with some online (based on the node) examples of how to write tests. You could read more based on the approach in their repository, though the approach is dependent on calls to the node, which we’ll implement ourselves using a (Plan9 rc) shell script. As time moves on, we’ll cover another article in the future on developing tests with AssemblyScript in a more enshrined/native way.

You can find the repo at https://github.com/stylus-developers-guild/nft-recommendation to see the entire package. Brave to the Wakeup Labs team for bringing AssemblyScript to Stylus!

Interview with Gonza

Who are you, and what do you do?

Hey! I’m Gonza. Most people in crypto know me as gonzacolo.eth. I’m the co-founder of WakeUp Labs, a company that helps startups, DAOs, and big corporations solve complex technical challenges, speed up their product roadmap, and experiment with new ideas through research and rapid prototyping.

Before diving into Web3, I studied Economics and taught History of Economic Thought at university. One of the main reasons I got into economics was to better understand the chaos of Argentina’s economy and make smarter decisions in uncertain environments. Funny enough, crypto felt like a natural extension of that: lots of volatility, fragmented and noisy information, and a constant need to evaluate risk.

Eventually, that curiosity turned into action. With WakeUp Labs, we wanted to share the knowledge we had, support projects we believed in, and make crypto simpler — not just for users, but for the developers and teams trying to build in this space. That’s still our north star today.

What web3 ecosystems have you worked in?

Yeah, most of our work has been in EVM-compatible chains — that’s where we feel the strongest fit. Arbitrum, in particular, has been a key partner for WakeUp Labs. We've had the chance to work closely with them on several initiatives.

We built a UI for a bridge that enables a transaction even when the sequencer misbehaves (https://x.com/wakeuplabs/status/1943730988288201157 ), worked on SDKs and libraries, and more recently, we’ve been contributing to Stylus. There, we’re making Stylus compatible with AssemblyScript, which we think is an exciting way to bring more developers, especially those outside the usual Rust or Solidity crowd, into the ecosystem.

Beyond that, we’ve collaborated with Velora (formerly ParaSwap), The Sandbox DAO, Coinbase, and some cool Argentine startups like Win investments and Num Finance. We’ve also gotten more involved in the DeFi and privacy space — contributing to Noir and experimenting with new DeFi protocols and ideas around private execution.

We’re drawn to ecosystems where we can make a real impact, technically and strategically. Right now, Arbitrum is one of those — not just because of the tech, but because there’s space to build things that matter.

What are your impressions of working with Stylus, good and bad?

We built our solution using AssemblyScript, which we ran on the Stylus VM. We really appreciate that Stylus supports building solutions in multiple languages that can compile to WASM and integrate with its ABI. When we deployed to testnet, we were particularly impressed by the execution speed of transactions

What software do you use?

WakeUp Stacks leverages Cursor as our primary development environment. For the frontend, we work with React + Vite. Our APIs are mainly built in Node.js (TypeScript), with an increasing adoption of Rust for high-performance services. Our infrastructure is hosted on AWS. In the blockchain space, we develop EVM smart contracts in Solidity. More recently, we’ve been implementing Zero-Knowledge proof solutions using Noir, a domain-specific language inspired by Rust for writing ZK circuits.

What hardware do you use?

Most of our team works on Mac, out of 20 people, 17 use macOS as their daily driver. While a few still run Windows or Linux, Mac has clearly won the race within our organization. We particularly value its development-friendly environment, reliability, and smooth integration with our toolchain.

How can we get in touch with you?

The easiest way to reach us is through Telegram — feel free to message me at @gonzacolo.

If you’d like to stay updated, learn more about what we do, or explore ways to collaborate, check out our Twitter: www.x.com/wakeuplabs and our website: wakeuplabs.io.

People usually reach out to us when they’re looking to move fast, whether that means testing an idea, building a new product, or contributing to ecosystems like Arbitrum, Starknet, Rootstock, and others. We specialize in working with DAOs, foundations, and startups. So if you’re building something ambitious and want a team that cares about the code, let’s talk.

What's a piece of advice you'd give someone new to web3?

Our advice for anyone starting out in Web3 is to treat it as a marathon, not a sprint. With new projects launching every day and technology moving fast, it’s easy to get caught up in the noise. But the people who stick around are the ones who understand the philosophy behind it and make long-term bets in long-term ecosystems, with long-term partners.

Your reasons might be different from ours, but it’s important to connect with the “why” — decentralization, privacy, ethos…

Once that clicks, your research starts to matter more. The deeper you go into projects, the more you’ll understand them — and the better your chances of building something meaningful, contributing ideas, investing wisely, or getting involved in a way that lasts.

After that first phase, a great next step is showing up in person. There are three global conferences I’d recommend: EthCC in France, ETHDenver in the US, and DevConnect, which changes location each year.

This year, DevConnect is happening in Argentina, and we’re excited to welcome everyone! :)

To get in touch with the Wakeup Labs team, follow the team at https://x.com/wakeuplabs! Be sure to read their introductory post for their project at:

This team is one of the more proactive teams I’ve had the pleasure of interacting with, so I’m really looking forward to seeing how this evolves gradually!

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!

By the way, I’ve been travelling through Japan, and recently stayed at this guest house during a period of intense rain (and flooding) in the Mount Fuji region. Satoshi has been an excellent host!

Guesthouse

nfts:`CryptoPunks,(`$"Bored Ape Yacht Club"),(`$"Infinex Patrons"),(`$"Pudgy Penguins"),(`$"Chromie Squiggle by Snowfro"),`Autoglyphs,(`$"Fidenza by Tyler Hobbs"),`Moonbirds,(`$"Lil Pudgys")
people:`Hunter`Ivan`Churro`Marko
flip (`name,nfts)!flip ({x,{(1?10)0}@'nfts}@'people)

1. 🧪 How to Verify Your Contracts with Blockscout’s API (No UI Needed!) 🚀

2. 🧱 How to Deploy Multiple Contracts in a Stylus Project – July 2025 Edition 🛠️📦

3. 💻 Stylus on RISC-V (RV32IM) – Part 2: SDK Support, Missing Simulator Features, and a Sample Contract 🧬⚙️📜

Read on, and as always, if you have any feedback, please 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 interoperability with Solidity!

Click here to learn more: https://arbitrum.io/stylus

You can get started very quickly using a (community maintained) setup script at https://stylusup.sh, with official resources at https://arbitrum.io/stylus, or fully online, without any setup, using The Wizard at https://thewizard.app/!

How to verify your contracts with Blockscout’s API

It’s possible to use the Blockscout API to verify your Stylus smart contracts. Special shoutout to Rim Rakhimov from Blockscout for graciously sharing some information on how their system works behind the scenes! I’ve slightly edited what they sent me and collected it here. Read on:

Q. How does Blockscout verify Stylus contracts?

Currently, we support verifying Stylus contracts located in public GitHub repositories. The swagger file for our API endpoint to request the verification can be found here. The endpoint accepts the following fields: deployment_transaction, rpc_endpoint, cargo_stylus_version, repository_url, commit, and path_prefix

The path_prefix is required so that repositories with several contract crates inside can be used. The repository https://github.com/blockscout/cargo-stylus-test-examples contains some great examples.

When a user visits the verification UI, they provide the cargo_stylus_version, repository_url, commit, and path_prefix values. These values, along with the address of the contract being verified are sent to an Elixir backend. The backend retrieves the deployment_transaction from the internal database, and sends the data it collected so far, and the rpc_endpoint, to a separate verification service.

The service validates the repository, clones the repo the user provided, and checks out the commit hash. If path_prefix is provided, it enters the corresponding prefix, which is calculated relative to the repository root directory.

Stylus requires the Rust toolchain version to be specified in a rust-toolchain.toml file. The file has to be located inside the working directory.

For verification, Blockscout uses the command cargo stylus verify --no-verify --endpoint {rpc_endpoint} --deployment-tx {deployment_transaction}`.

We opt out of running verification inside in-stylus docker container by adding the --no-verify flag. We opt out because cargo-stylus requires the docker daemon to be run locally, but we would like to run the service and docker daemon on different machines. We implemented our own docker container startup process which allows us to run containers on the remote docker daemon.

cargo stylus verify prints the result into console. We parse the stdout and look for the line: "Verified - contract matches local project's file hashes". If found, the verification is considered successful, otherwise the verification fails.

If successful, we also attempt to retrieve the contract ABI as it is not returned by the verify command. To get the abi, we run the cargo stylus export-abi command, and parse its result. It prints the ABIs of all included contracts, and the verified contract ABI is printed as the last one. The name of this ABI is also used as a contract name inside a response.

If you need the code, the main function is implemented here: https://github.com/blockscout/blockscout-rs/blob/main/stylus-verifier/stylus-verifier-logic/src/stylus_sdk_rs.rs#L76

An example of making a request to the Blockscout API for verification:

curl 'https://arbitrum.blockscout.com/api/v2/smart-contracts/<address_hash>/verification/via/stylus-github-repository' -H 'Content-type: application/json' -d '{"cargo_stylus_version":"v0.5.6","repository_url":"https://github.com/OffchainLabs/stylus-erc20","commit":"d109002ffff3df7589cbbc92f8f104567a84f085","path_prefix":"","license_type":"none"}'

Thanks again to Rim Rakhimov and the Blockscout team for this in-depth explanation! Be sure to let their team know if you found the explanation useful. You can follow them on X at https://x.com/blockscout, and you can check out their Github organisation at https://github.com/blockscout. Blockscout is a fully open source, and community contributions are always welcome.

How to do multiple contracts in a Stylus project, July 2025 edition

I’ve seen some discussion lately in the community, with people wondering how to do multiple contracts in one location! At the time of writing, the 1.0 version of Stylus will include a feature that manages this for you. For now, we still have two ways to do this ourselves. Let’s review!

Multiple packages/Cargo workspaces

This is an approach I don’t prefer, after experiencing the frustrations of this with Longtail, the Superposition concentrated liquidity AMM.

The trick is to use separate packages internal to the project using a Cargo workspace. An example of how this works in practice is to look at Longtail or Renegade. OpenZeppelin also take this approach with their Stylus contracts, as this method is the easiest to use if you’re vendoring dependencies for end users.

At the root of your repository, you would need a Cargo.toml file that indicates a workspace is in use, like so:

[workspace]
members = [
    "contracts-stylus",
    "contracts-core",
    "contracts-common",
    "scripts",
    "contracts-utils",
    "integration",
]
resolver = "2"

Then, inside each contract folder, you would have a separate project for the contract you’re supporting:

Most tools in the Stylus ecosystem let you set the specific package during your deployment and use of the tools! I imagine this will see the most support in the reproducible build department in an ongoing way.

Feature flagging

It’s possible to use a approach based on feature flagging to support multiple contracts! We use a method like this for our prediction market 9lives. I prefer this method since comparatively it’s a lot simpler than using workspaces. The key is to use conditional compilation to import the user_entrypoint function depending on which contract is being built at the time. This is what our lib.rs entrypoint (partly) looks like:

So, if contract-factory-1 is set as the feature flag, then the user_entrypoint function that’s generated inside contract_factory_1 is imported, setting the entrypoint to the contract. This means, that we have to set the feature flag contract-factory-1 to get the entrypoint to the contract, so the compiled wasm file is the contract for the factory!

For contract_beauty_contest, (and contract_infra_market, and contract_lockup, and contract_trading), conditionally generating the user entrypoint by checking the feature flag results in a conditionally generated entrypoint:

Which is by default exported from this file. So, our import from above where we import everything, we can import the entrypoint this way.

Though I have a preference, the ideal approach depends on your team’s DNA. My team are sophisticated shell script operators, so, we don’t mind maintaining a Makefile that orchestrates the feature flagging, moving files around where appropriate. The problem with this approach is that we can’t parallel the creation, all compilation needs to happen sequentially.

I’m interested in seeing what people prefer over time, and for the new version of the SDK to come out with a better approach for this!

Stylus on RISC-V (32IM) Part 2 - The SDK and environment calls

This is a continuation of part 1 of this series:

It’s been a month! Wow, time flies! Let’s continue our support for RISC-V with the Stylus SDK. To continue our journey, we need to do the following:

1. Get the missing features from the EVM supported in our simulator. This includes the remaining host operations.

2. Get the SDK fully updated to let us generate binaries with RISC-V! Fix the entrypoint and the rest of the storage code! Release a forked SDK anyone can use as a dependency.

To recap what RISC-V is, and what we’re up to, RISC-V is a “reduced instruction set” instruction set architecture (ISA) that’s developed as an open source standard. An ISA is a set of instructions that a processor understands that you, an end programmer, provide by compiling your code written in a higher level language down to. So when you compile your Rust code (and it’s not to be run on Arbitrum), it spits out “native code”, which is code capable of being run with the native instruction set for your processor type. If you’re on a Mac, and you have a M4 chip, then you run the ARM instruction set, which is different from the instruction set my Intel i7 processor runs.

We’re interested in running Stylus smart contracts on the RISC-V 32 instruction set (with the Integer and base Multiplication extensions) since there was some discussion last month of running the entire Ethereum Virtual Machine on RISC-V. My goal is to potentially establish Arbitrum Stylus as the main programming environment alongside Solidity and Vyper in the Ethereum space, so my ultimate goal with this exercise is to eventually simulate RISC-V on-chain inside a WASM runner.

So far, we’ve developed a testing simulator for offline development in OCaml. In this article, we’ll support missing EVM features in the simulator using environment calls (where the guest running program can indicate to the CPU that the CPU needs to step in and do something before giving back control). We’ll also patch the SDK to support RISC-V as a compilation target, and release a contract for this.

Read on!

Missing features supported in the simulator

To do this, we’ll first implement the external functions that Stylus needs:

These are implemented by the host environment to support the EVM storage trie, calldata, and the classic calling operations. These are normally provided in WASM as external functions. We need to support them in our OCaml simulator by allowing a user to trigger a environment call with the A7 register set to an offset of the function number to use! Let’s create a new file, and define a type of each external function we want to support:

Note the “enum” preprocessor: this create a function that converts a integer to one of the variant fields here, and vice versa. Note that we add a helper console function, as well as a function for reading the length of the return arguments! We need it to match dispatch to our functions here:

In line with the standard calling convention with RISC-V, we store the syscall number in the register A7. To accommodate the new supported EVM features, we need to update the amount of information available to our virtual CPU. We do so by adding a new file, which has this definition:

Note the extra fields beyond the memory that we need for the program from last time! Specifically, the “Ethereum_cd.t” type in the fields e_cd, and e_rd, which we use for the calldata and the returndata for the program respectively. We’ll service some of the external functions using these fields in the type for the CPU here.

So a function supporting an environment call would look like this:

This function would create a U256 from the integer given (currently, the default setting that SPN Mainnet has), then set it to the location of memory given, equivalent to the host features that the WASM runner would implement.

Reading the arguments is similar. We simply read from the custom type that contains the calldata:

(* Ethereum_cd.ml *)
type t = int32 Array.t

Very simple! We need a function that lets the guest RISC-V program set the returndata type:

Using the A0 and A1 registers is how we find the read pointer, and the length. This pattern will repeat throughout our implementation, in line with the standard calling convention with RISC-V.

You can read the repo to see the extent of the functions that we implemented here.

Tweaking the SDK

Now that we’ve got a reasonable implementation of some of the foreign functions that the contract needs, we can start to support RISC-V in the SDK. We need to extend the vm_hooks macro, to add branching for the RISC-V target that copies the arguments that the functions would provide to the external function as arguments to the registers, in line with the calling convention.

This means code like the following:

This code copies the arguments from the functions given after making a slice of the arguments (in their u32 type as usize type), and sets the registers with it. It invokes the associated function based on a count that increments per number. It generates functions that read the registers and reconstruct them based on the arguments.

This new macro spits out code like this for the RISC-V target:

For the above contract address, this is simply a pointer to the offset for the 20 byte address to be written. A better implementation of the macro would set the single field, as well as the syscall number, instead of setting every argument for the standard calling convention. A problem this macro has is that an argument with a u64 is simply cast to the u32 type, instead of leveraging an extra register implicitly.

We needed to also make some changes to the Cargo.toml file to accommodate the bytes package, and some dependency on arc. I also needed to upstream a patch to dyn-clone to accommodate target_has_atomic since we don’t have access to anything involving sync (RISC-V 32IM is a tier 3 target with no parallelism).

Our first (somewhat legit) contract

Having adjusted the SDK, and added features to the simulator, we can write our first contract! Inside the risc-hello-world contract, we can create the following:

// src/main.rs

#[entrypoint]
#[storage]
struct Storage {
    pub message: StorageString,
}

#[public]
impl Storage {
    pub fn hello(&mut self) -> String {
        self.message.set_str("Hello!");
        self.message.get_string()
    }
}

#[export_name = "_start"]
pub extern "C" fn _start() -> ! {
    unsafe {
        let heap_start = HEAP.as_mut_ptr() as usize;
        let heap_len = HEAP.len();
        ALLOCATOR.init(heap_start, heap_len);
    }
    let len: usize;
    unsafe {
        core::arch::asm!(
            "ecall",
            in("a7") 34,
            lateout("a0") len,
            options(nostack, preserves_flags)
        );
    }
    let status = user_entrypoint(len);
    unsafe {
        core::arch::asm!("mv a0, {}", in(reg) status);
    }
    unsafe {
        asm!("ebreak");
    }
    loop {}
}

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    unsafe {
        core::arch::asm!("mv a0, {}", in(reg) 2);
    }
    unsafe {
        asm!("ebreak");
    }
    loop {}
}

We create a simple allocator (we defined this in the previous post), and set it up in our entrypoint. We call a custom function at number 34 (args_len) to get the length of the calldata argument, and then we set the contents of A0 after the execution to the variable len.

Knowing the length lets us invoke the user_entrypoint function that the code normally generates! This will let us pick the entrypoint, in this case the function “hello()” which returns a string! Our program sets “Hello!” to the storage, and then reads it off, returning it.

The user_entrypoint function reads the contents of the arguments, using the read_args in memory it provided to our RISC-V simulator. It then returns the status, which we set to the register A0. Among our changes here, we also changed the simulator to check the value stored in the A0 register when exiting:

Any calls to the write_result(data: *const u8, len: usize) function invoked by the user_entrypoint code will set the return value for the contract. The function that sets the return data will set the e_rd field in the record that we have in the Cpu.t type. Our program then prints and returns it for us!

Running the simulator

We can run this code now! The RISC-V runner also includes a argument that we can provide that sets the sender. We can run the copy of the test code inside the simulator repo. This contract will slightly differ from the above, so that we can supply an argument of the string to set to the storage:

#[entrypoint]
#[storage]
struct Storage {
    pub message: StorageU256,
}

#[public]
impl Storage {
    pub fn hello(&mut self, x: String) -> String {
        self.message.set(x);
        self.message.get()
    }
}

First, we build:

dune build bin/main.exe

Then we run:

./_build/default/bin/main.exe test/risc-hello-world $(cast calldata 'hello(uint256)' 456)

Which returns:

0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000548656c6c6f000000000000000000000000000000000000000000000000000000

The operation $(cast calldata 'hello(string)' Hello) substitutes in the argument list the calldata for “hello(Hello)” and the argument we want, which is 0xa777d0dc0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000548656c6c6f000000000000000000000000000000000000000000000000000000! This is provided to the program as calldata by setting the e_cd field in the simulator!

What’s next?

We need to fix our simulator to not use libbinutils to read the ELF section headers, so that we can support release generated (stripped) builds. This is a problem for my system since I’ve had some issues linking against my preference library (libelf) for this, and I don’t want to roll support myself natively. For our research simulator, it would be nice to support multiple contracts, and transactions/blocks/mining. It would be nice to support the compressed and vector extensions to RISC-V as well, so we can start to support our silly little simulator as a nice research tool for the respective ISAs. We could even support a coprocessor for large words (or something)!

We also need to move our allocator to a crate, identify any problems with it (the heap being small?), and streamline the development experience of working with RISC-V this way. The ultimate goal here though is to simulate RISC-V 32IM on-chain in the WASM on-chain environment to show that the performance penalty is acceptable, and to build awareness and establish Stylus as the main programming environment in the alt EVM space!

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!

This will be a new type of game for VCs and partygoers, where players work to discover the true value of a fictional or real company. Like planning poker, but for valuations!

Planning poker is a project complexity estimation tool where developers estimate the complexity of a task privately, then revealing at the same moment. The developers repeat this game until they find consensus of the time it takes to complete a task. This makes planning poker a very useful tool for discovering misconceptions about project timelines.

In this part 1 article, we’ll be:

1. Writing state machine diagrams 📊🔄 for the user journey and technical story.

2. Creating a recursive game playing type 🔁🎯 for the contract. Since this is a state channel/validium/rollup, depending on your nomenclature use, we'll be compressing a recursive structure for submission on-chain to trigger side effects. We will use a UTXO style of optimistically consuming Layerzero 🌐⚡ on the server side, and deposits with a debt derivative 💰📈 for a frictionless user experience.

3. Building a GraphQL backend and database 🗄️🔧. We'll be building a AWS Lambda function ☁️⚡ that works with a Postgres database 🐘 to store signatures and game state.

4. Defining the contract entrypoint 📝✨. We'll be defining a high level interface with the types, then starting to build it and discussing the implementation! 🚀💻

Finally, following these steps, our next post will create the frontend and complete the contract! For now, we’ll focus entirely on the backend and broad strokes! Read on!

I’m excited to announce Valley Game, a game and tool like planning poker, but for valuations!

The game is either played in a fictional setting, with a fake company, or a real world company in a limited setting.

Users play rounds of Valley Game, and are awarded points based on how close they are to each other each round!

In the images above, the players would play 4 more rounds of this. Then a fictional token would be divided up by the points distribution!

Points are also awarded retrospectively based on how close a user was at the beginning of the game to the final outcome.

It is played entirely in a rollup using a neat state channel compression technique we’ll discuss and develop in this post (meaning zero gas fees per transaction except when onramping and offramping funds, and instant confirmation), and is optionally played with real money with some token I’ll pick from the FC community, and playable using Farcaster using Ben Greenberg’s Farcaster template, which we’ll develop with with a live video of doing so in a later post.

Users can play from any chain, including Arbitrum, Base, and Superposition, with no degradation of experience, by leveraging “satellite” contracts on the chains supported, and the state channel technique developed in this post. We’ll also be discussing support for web2 users on-ramping using Stripe.

Since no actual numbers are ever specified in this game, it’s entirely subjective based on the audience, making this a great game for repeated play! The game will never tell you what the valuation should be, the audience imagines it entirely by itself. It’s also illustrative of a unique approach to oracle design.

While the game itself is intended to be played with fictional companies, a mode is supported where real companies are used, and this could perhaps be used in an environment where . The playing team could make a prediction for a year from now, and state their estimation natively using Farcaster!

You can find the repo here:

The user story

This game is played as a state channel that’s opened after a deposit to a contract on Superposition Mainnet. The deposit of the asset on the contract triggers the creation of a spendable UTXO input. Our Stylus contract validates compressed signed calldata, and releases funds when a signature and transaction is provided to do so, all stemming from user consumption of the UTXO input. The application runs optimistically across multiple chains, validating optimistically on the server side with deterministic creation of the balance UTXO coin for users when a transaction enters the Layerzero transaction pool.

Quick interlude: What’s a UTXO? A UTXO input is a asset that can be “spent” to produce an “output". Funnily enough, we introduced coins in the last post when we discussed Sui: https://stylus-saturdays.com/i/167568457/objects-and-parallelism ← check this out for more!

To begin with, we’re going to implement a user-centric user journey without discussing the randomness and variation that would need to be injected into the game for fictional play, so just focusing on making a game that is played more than once with points allocated for how close users are. It should look like this:

So basically, a user opens the game, makes a prediction alongside everyone else, then they aggregate everyone’s predictions. The user plays back and forth inside the “Makes prediction” stage, dependent on some state, then the user withdraws their funds from the contract.

With a UTXO-style pattern of allocating a balance object then consuming it later that’s similar to what’s going to come live in Longtail Pro Passport in the near future, we can mock a user state machine like this:

Which would actually resemble in terms of a technical user story the following:

So, we allow users to deposit their asset, we mint a debt derivative that could be converted to the underlying asset at any time, and we let them play the game back and forth for a while before returning to where we started. Once the user is at square one, we consume their debt token to send them back their asset optionally, or we allow them to reenter the game. It’s important that we mint a debt token. Minting a debt token is a tool that allows you to underwrite your token with a custodial asset to support web2 users, without minting friction. This is consistent with the social goals of this project (supporting web2 users with no crypto wallets and in-browser signatures). This exposes your project to bank runs, so it’s important that you shore up your on-chain position to be consistent with what’s available in circulation inclusive of your web2 users, and that you keep your signing process for creating assets very safe.

For a UTXO-style system with compressed messages, we need to support a join operation at least for deposits (where a user has multiple games completed and they want to keep playing without leaving). We can skip implementing a split, assuming that user deposits are full of intent and that they don’t plan on reducing their allocation after making the deposit with funds.

Application pseudocode

Let’s implement some pseudocode in Python. We’ll make our game state resemble the following:

class Game:
    """
    The current round the game is on.
    """
    round = 0

    """
    Simple knowledge of who has the right to participate in this
    game.
    """
    players = {}

    """
    The predictions made by users at each step of the game for
    five rounds. The key for each round is their unique id. Stored
    privately from each player's perspective.
    """
    player_predictions = [{} for _ in range(5)]

    """
    The amount that every user invested to play the game.
    """
    fixed_buyin = 5

    """
    A fixed size circular buffer for messages. Maybe 200 items long.
    """
    messages = []

    """
    Points awarded for each bip based on how close the user is to
    the mean (1 bip = 0.1%).
    """
    bip_points = 100

Like a lot of games, there’s a lack of incentive for users to invest large amounts unless others do it first. For this game, we’ll implement a fixed buy-in from every participant, and scale the number of rounds according to the amount at stake. This lets us discover a skill level of sophistication, enriching the game structure itself through observation. For our game here, we’ll require a buy-in of $5 of our concept token.

We’ll mock this game as a evolutionary algorithm later. An evolutionary algorithm is a set of programs that run inside a shared space that each feature a fixed buffer of DNA. DNA are functions that operate on a bit of internal state to the program, which could include in this case a amount of information stored in a circular buffer, and information on whether other players have made predictions. The DNA won’t have any information extrinsic to the generated code itself except a shared buffer. The program’s performance is quantified, and at the end of the game, the top performers of a game played amongst randomly generated programs are combined together randomly to create new programs, until the top programs emerge naturally from randomness.

For our game, in the state we’ll support a broadcast layer of messages that can be sent amongst the players. In the fictional game, this could be the fake evidence list about the company (ie, their competitor was acquired by a bigger company, or their founder was embroiled in a scam, generated at random), but in the game that we’re designing where the randomness injection is outside the scope, this could be used for program messaging amongst themselves.

This will enable our generated algorithms to send tagged Lisp-style lists similar to the following amongst itself, and reuse this structure for information updates in our game:

(<topic> <message>)

Then support List accessors like this:

def unpack_last_msg(field, depth)

So that our generated programs can later unpack and understand messages that were sent inside the game, using it like a scratch pad of sorts for memory. This lets us keep our state pretty small, having the programs interrogate each other for information, and only learning by encoding their performance in their program code. However! We won’t be including this on-chain, since this isn’t relevant to the contract’s final rolling up of decision made during the course of the game.

The code gameplay loop looks like the following for the round deposit. We’ll award 100 points multiplied by a certain number of bips (how many percentage points the user is distant from the average):

exception GameOver(Exception):
    pass

class GameOver(Exception):
    pass

def merge_record(a, b):
    return {k: a.get(k, 0) + b.get(k, 0) for k in a.keys() | b.keys()}

class Game:
    ...

    def calc_points(self, avg, p):
    	return max(0, self.bip_points - abs(avg - p))

    def buyin(self, user):
        """
        Buy in an amount, only possible if the game is the first round.
        """
        if self.round > 0: raise GameStarted()
        self.players[user] = True

    def predict(self, user, value):
        """
        Lock in the prediction for this round. Bump the round if we hit
        the limit of the participants right now.
        """
        if self.round == len(self.player_predictions): raise GameOver()
        self.player_predictions[self.round][user] = value
        if len(self.player_predictions[self.round]) == len(self.players):
            self.round += 1

    def proximity_points(self):
        """
        Get the points for each user at the current round.
        """
        acc = {}
        for predictions in self.player_predictions[:self.round]:
            mean = sum(predictions.values()) / len(predictions)
            for k, p in predictions.items():
                acc[k] = acc.get(k, 0) + self.calc_points(mean, p)
        return acc

    def early_points(self):
        """
        Get the points the user is owed for how close they were at the
        beginning to the end consensus.
        """
        # Short circuit if the game isn't over yet.
        if self.round < len(self.player_predictions):
            return {k: 0 for k in self.players.keys()}
        first_predictions = self.player_predictions[0]
        final_predictions = self.player_predictions[self.round-1].values()
        m = sum(final_predictions) / len(final_predictions)
        return {k: self.calc_points(m, first_predictions[k]) for k in self.players.keys()}

    def points(self):
        """
        Get the points for each user at the current round.
        """
        return merge_record(self.proximity_points(), self.early_points())

    def allocate(self):
        """
        Return the funds each user should receive as a result of the
        game.
        """
        available = self.fixed_buyin * len(self.players)
        p = self.points()
        all_points = sum(p.values())
        return {k: available * (v / all_points) for k, v in p.items()}

This is a simple reference, reusing the bip calculation for the end of points calculation. Games will be played where the first action is the most valuable most likely, but will also create a dynamic where maybe the leading player will be targeted by the other players if they are in the lead by the end of the game, creating a interesting dynamic I imagine for adversarial play. This code is so simple we could probably implement it with a APL one liner.

State channel architecture

Since this is a game with UTXO-like on-ramping and spending of signatures, we need an approach to our database that accommodates the storage of signatures that users supply, after verifying it ourselves.

First, let’s flesh out our user journey from before with another type:

This type is literally converted to calldata. Users sign at every stage of the process. In Rust, the types would look like the following:

For signature handling in our code, we use ed25519. This lets us benefit from WebCrypto in the browser, and there is decent support in the Rust ecosystem with the ed25519_dalek package. The key can be created in the browser and remembered using cookies, then included in a signature with Permit to a contract to bond and allocate funds. This is similar to what we use for Longtail Pro’s passport frontend, and it results in a seamless experience for the most part, powered by Stylus.

There are some tools here that we’ve introduced for compression’s sake, including information on who should be signing what, and whether it was previously seen on-chain, but I’m not including this in the above screenshot. Hopefully you can see how the state machine works here! The reason for this approach is that it’s completely offline until it’s finally aggregated at the end of the user journey. In the withdraw step, we ask for the server-side signature as well as the user signature. This lets us prevent abuse from taking place, like a user withdrawing their spent balance after they’ve started to accumulate a losing position.

A note on the encoding taking place: we’ll use Borsh encoding that we’ll supply as a bytes argument to the functions here. The reason for this is to maintain some level of composability with the rest of the contract ecosystem, though this is technically a redundant action, as you could build the entrypoint to the code yourself as switching on a enum field, as we do in Longtail Pro’s codebase. It’s not necessarily the most efficient approach, since the encoding of the length will be repeated somewhat, but for our example, it’s the best way, since we don’t need to overload the entrypoint.

The backend/database architecture

In the spirit of reuse, we’ll be using Rust for the entire package of this application, but generating GraphQL code to be run on AWS Lambda. So, we need a persistent place to store the aggregated calldata to send to users on request.

A simple series of Postgres tables should suffice for storage, and we’ll add some helper types to make storage more explicit:

-- 0x + [u8; 32]
CREATE DOMAIN ED_ADDR AS CHAR(66);

-- 0x + [u8; 64]
CREATE DOMAIN ED_SIG AS NUMERIC(130, 0);

CREATE DOMAIN HUGEINT AS NUMERIC(78, 0);

CREATE TABLE valleygame_game_info_1 (
	id SERIAL PRIMARY KEY,
	created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	round_limit INTEGER NOT NULL,
	bip_points INTEGER NOT NULL,
	fixed_buyin HUGEINT NOT NULL,
	whitelisted_ids JSONB NOT NULL,
	-- This is also used externally to convert to this game's id.
	random_nonce HUGEINT NOT NULL
);

The round limit will be the amount of rounds that we can run before the game is considered finished, and the bip points (and the rest of the code) is like the reference in Python. The random nonce is needed to avoid a signature reuse situation, and whitelisted IDs are used to allowlist only a fixed set of users to play the game. These fields are stored in JSON to avoid having a one to many table relationship (and multiple insertions). We can simply read the column, then unpack it ourselves as JSON.

As a development practice, I like explicitly versioning my tables, and building views over raw event data being ingested in as opposed to mutating tables. This lets us add additional features but maintaining the ability to roll back quickly, and to support versioned APIs and versioned encoded datastructures. You can see this in the naming convention.

Let’s create some tables to accommodate the creation and spending of deposits and amounts:

-- Server-side deposits that were created from a centralised source.
CREATE TABLE valleygame_server_deposits_1 (
	id SERIAL PRIMARY KEY,
	created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	recipient ED_ADDR NOT NULL,
	amount HUGEINT NOT NULL,
	nonce INTEGER NOT NULL,
	sig ED_SIG NOT NULL
);

CREATE TABLE valleygame_mint_debt_token_1 (
	id SERIAL PRIMARY KEY,
	created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	from_deposit_ticket HUGEINT,
	from_previous_game_id SERIAL,
	from_server_id SERIAL,
	signer ED_ADDR NOT NULL,
	sig ED_SIG NOT NULL,
	FOREIGN KEY (from_previous_game_id) REFERENCES valleygame_game_info_1(id),
	FOREIGN KEY (from_server_id) REFERENCES valleygame_server_deposits_1(id)
);

CREATE TABLE valleygame_enter_1 (
	id SERIAL PRIMARY KEY,
	created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	-- We get the args from the game info when someone asks for this.
	game_id SERIAL NOT NULL,
	FOREIGN KEY (game_id) REFERENCES valleygame_game_info_1(id)
);

Here, we do have a one-to-many table relationship, as we need to record on-ramping/creation of the deposit asset. We overload the “debt token” table to have multiple, possibly null, fields that include the originating source of the token, which we convert to the serialised type that we saw earlier.

CREATE TABLE valleygame_prediction_1 (
	id SERIAL PRIMARY KEY,
	created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	game_id SERIAL NOT NULL,
	estimated HUGEINT NOT NULL,
	round_number INTEGER NOT NULL,
	signer ED_ADDR NOT NULL,
	sig ED_SIG NOT NULL,
	FOREIGN KEY (game_id) REFERENCES valleygame_game_info_1(id)
);

CREATE TABLE valleygame_withdraw_1 (
	id SERIAL PRIMARY KEY,
	created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	debt_token_id SERIAL NOT NULL,
	user_signer ED_ADDR NOT NULL,
	user_sig ED_SIG NOT NULL,
	server_sig ED_SIG NOT NULL,
	FOREIGN KEY (debt_token_id) REFERENCES valleygame_mint_debt_token_1(id)
);

You can see that this is almost one-to-one with the types we defined above!

Having defined the database types, we can start to look at setting up the repo structure for our code. Then, we’ll implement the code that does the verification and the storage of the data.

Unlike some of our previous posts, we won’t implement this in the most verbose way. We’ll instead focus on the structure and broad strokes of the implementation, then elaborate further with the video that you can see at the top!

We’ll create three entrypoints in the Rust code:

[[bin]]
name = "contract"
path = "src/contract/main.rs"

[[bin]]
name = "frontend"
path = "src/frontend/main.rs"

[[bin]]
name = "graph"
path = "src/graph/main.rs"

The contract and frontend entrypoints will run as wasm32-unknown-unknown targets. The contract will be built with the contract deployment on-chain in mind, but the latter will use exported code to access the browser APIs using wasm-bindgen. graph will be run as a Lambda function, and as such will run natively on my laptop.

Implementing the backend

We start to implement the backend by generating a GraphQL schema consistent with the type we defined above. In our game, the server functions more like a storage backend for the signatures as they’re aggregated (and some validation mixed in to save time for the client, including checking deposits when they’re spent), with the frontend dressing up what’s available to be presentable in a format consistent with a game.

We implement a schema:

enum DepositStatus {
  Unspent,
  Withdrawn,
  AfterGame,
}

type Deposit {
  lzTx: String
  ticketId: String!
  status: DepositStatus!
  amount: String!
}

type Lobby {
  randomNonce: String!
  game: Game!
  lockedInPlayers: [String!]
}

type Game {
  creator: String!
  roundLimit: Int!
  bipPoints: String!
  fixedBuyin: String!
  whitelistedIds: [String!]!
  randomNonce: String!
}

type Prediction {
  amount: String!
  addr: String!
}

type Round {
  ongoing: Boolean!
  predictions: [Prediction!]
}

type Ongoing {
  rounds: [Round!]!
  game: Game!
}

type Query {
  lobbies: [Lobby!]!
  ongoing: [Ongoing!]!
  deposits(addr: String!): [Deposit!]!
}

For brevity’s sake, this schema is lacking comments. The DepositStatus type is indicative of the state of a UTXO, whether it should be considered spent, or available to be used in its original form. It might have changed its value after a game has been played, at which point the amount in it should be rendered differently to the end user.

The Deposit includes information about a Layerzero transaction, which could be used to optimistically progress a interaction, assuming that the underlying token was successfully bridged. If the bridging does not take place, then the submission of the calldata and verification of amounts would fail on the base chain, assuming that LZ’s sending would fail. This is a nice UX hack with a degradation in a worst-case scenario of a fork or something taking place, which is not very likely in practice.

A Lobby is made available with information on the game as well as any players that committed to play. A problem with the approach of this system is that users choosing to be unavailable causes a degraded situation where the funds are stuck. We won’t be addressing this here, though a trivial solution is to include an optimistic submission stage at the end of the game, where a user can stake their token on liveliness from each player. Players that fail to submit at the time will lose their tokens to the staker, but if every user submits (all the way up to the completed game), then the staker themselves will lose the funds.

Finally, the Ongoing type is available to include information on ongoing games that the user is participating in based on their Authorization header. This includes Rounds that were played, and the predictions made by each user.

I implemented the schema manually (pain), then chatted with the database using boring raw SQL. I’m lucky that with Claude in a conversational format it handled the translation of my schema for the most part. Parts of the code look like the following:

These types resemble the schema from above. In other places, we set up a database pool that we use with Postgres, and later in the code we have the implementation for the looking up of these values. We also start to define an entrypoint inside the Lambda graph to run inside AWS Lambda:

This is some basic setup code to allow us to use the Authorization header for our schema to branch the loading of the lobbies request using the database.

Implementing the contract entrypoint

Finally, let’s define the entrypoint to our contract! Let’s define an interface like the following:

interface IValleyGame {
    function nonces(address spender) external view returns (uint256);

    function deposit(uint256 amount, address recipient) external view returns (uint256);

    function play(bytes calldata) external;
}

The first function is simple nonce management. It’s useful for optimistic depositing of funds using Layerzero messaging, by having the user simply initiate the process of the deposit, since their nonce can be combined with their address to create the deposit ticket. The second function is a simple interface for depositing the native asset using the deposit ticket. It simply takes the amount, and the creditor address. The issue with this approach is that a griefing vector lies here, but we’ll continue as-is for now.

Finally, the play function is the actual interaction with the contract. This is the bit of code that takes the Borsh-encoded data we’ve seen earlier and generates the side effects by stepping through the rolled up calldata!

We’ll have to pick this up next time! I’m out of time for now.

I like games with emergent social properties. Games like this include Nomic and Aneurism IV, where players themselves create the structure of the gameplay themselves. In the next post, we’ll build the rest of the contract, including the functions that translate the local state to side effects inside a reimplementation of the pseudocode. Maybe later we’ll even build a videogame using this method in between our usual programming, who knows? I have something in mind aside from this…

Stay tuned!

As a reminder, you can find the code 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!

1. 🗄️ A Stylus smart contract tracker: A new ingestor and web application that tracks the deployment of Stylus on several chains, and can be used to plot the growth on each chain!

2. ⏱️ Moving Stylus by Rather Labs: An in-depth overview of the taking Move to Stylus project by Rather Labs, including some discussion of Move and the team’s development.

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 C++. 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 using the official resources at https://docs.arbitrum.io/stylus/gentle-introduction!

Stylus Contract Deployments

I’m pleased to share that I’ve tracked every contract deployment of Stylus on several chains, and made it available as a TSV download using the Superposition in-house ingesting stack. You can find it at https://stylus.fluiditylabs.io! I’ll be having this keep itself up to date and possible to download at any time for everyone to use.

The networks tracked are:

1. Arbitrum One and Arbitrum Sepolia

2. Superposition Mainnet and Testnet

3. Sanko

4. Apechain

5. Corn

6. Xai Mainnet

7. Gravity Alpha Mainnet

8. Plume

9. Degen Chain

10. EDU Chain

11. SX Rollup

12. DuckChain

13. RARI Chain

It includes everything emitted by the precompile for contract activation, including the codehash, the creation timestamp, the transaction hash, the chain id, etc.

You can register a new chain easily by simply making a pull request to https://github.com/fluidity-money/stylus.fluiditylabs.io/blob/trunk/chains.tsv.

You can download the list at https://stylus.fluiditylabs.io/contracts.tsv.

There are a few interesting facts we can discuss from the data here:

More than 10,000 contracts have been deployed!

10844 contracts have been deployed at the time of writing!

The overwhelming majority of deployments took place on Arbitrum Sepolia, and following that, Superposition Testnet. Superposition Testnet saw several deployments during a period of competition for the ETH Bucharest hackathon, and our internal team regularly uses the testnet, so it would be important to examine this data in the future by examining the unique deployer addresses additionally. Excluding testnet, mainnet deployments across Superposition Mainnet, and Arbitrum One, total 842.

Arbitrum One sees a median of 8 Stylus contracts deployed a week!

Very exciting! We need a good growth indicator of developer awareness to accompany this in the future.

Arbitrum Sepolia sees the bulk of Stylus deployments

Which makes sense. Sepolia is the testing environment where developers can quickly deploy to to test their built Stylus contracts, which our friends The Wizard make very easy to deploy to (and developers have a natural interest to do so). Perhaps a good step would be to improve access to the testnet for developers?

We haven’t recorded interest within the other Orbit chains with Stylus

Stylus is still a new technology and we’re all trailblazers, and frankly, if you’re reading this newsletter, congratulations on being early! From what we’ve seen so far, none of the Orbit chains (except for Superposition) are making use of Stylus, with no deployments recorded on their mainnets. This is a shame, because Stylus’ strengths lies in its range of expressiveness once you understand the range of what you can build with it!

The end of last year was the peak of mainnet deployments per month

The beginning of this year was the peak window of deployments taking place to testnet. Interestingly enough, the last month of last year was when the most deployment activity was recorded for mainnet. I wonder why? From my perspective, our community is only growing.

Move on Stylus, an implementation overview

Rather Labs is bringing the programming language Move to Stylus! Move is a programming language invented at Facebook as a part of the Libra project. It’s a VERY secure programming language, where capabilities are expressed using UTXO-like coins, which are also used to support explicit parallelism in the Move blockchains. The compiler has a type checking stage which can be used to statically enforce access controls. This level of granularity means much safer code than we otherwise have access to!

Let’s break down these concepts:

Capabilities and coins

In a Solidity contract, permissions and ownership might look like this:

contract DogWalker {
    address public owner;

    constructor() {
        owner = msg.sender;
    }

    event IWalkTheDog();

    function walkTheDog() external {
        require(msg.sender == owner, "not the dog owner");
        emit IWalkTheDog();
    }
}

Ownership and permissions are stored in the contract storage which is read from, and compared with, the sender. But what if there were a better way? Move’s approach is to give users a “object”, a coin which can be spent to express a capability:

module dog_walker::dog_walker;

use sui::event::emit;

public struct IWalkTheDog has copy, drop {}

public struct CanWalkDogCap has key { id: UID }

fun init(ctx: &mut TxContext) {
    transfer::transfer(
        CanWalkDogCap { id: object::new(ctx) },
        tx_context::sender(ctx)
    );
}

entry fun walk_the_dog(_: &CanWalkDogCap) {
    emit(IWalkTheDog{});
}

In this example, the contract once its initialised, gives the sender the capability object CanWalkDogCap, a object that must be provided to invoke the function walk_the_dog.

Note the ampersand (&) in the function signature and the decorator denoting its an entrypoint function? This designates that the function can be called into by someone invoking the contract, and that the function is dependent on, but must not consume, the coin we received earlier, CanWalkDogCap! So imagine going to call a function, and it’s dependent on you having a token, pretty great! You could drop the & to make it that the coin must be consumed, after which the object would be considered spent, and gone from the user’s account!

You could imagine mocking a complex series of interactions this way, and implementing complex semantics using the capabilities object model. Move even supports the ability to denote that a coin cannot be destroyed by the sender, in that it must be returned to the contract, using a pattern titled the “Hot Potato”. Move has a very expressive landscape for type-annotated programming this way.

Objects and parallelism

With the Move blockchains (Aptos, Sui), spending coins like this tells the nodes how to perform a “pipelining” of operations, where it’s possible to batch execution of smart contracts and transactions in a way where they are processed as they arrive, not sequentially, making better use of the node’s execution compute and database resources. This means potentially a higher throughput when it comes to transaction processing, and it’s baked into the type system! This form of type-enabled high throughput execution is a form of “explicit parallelism”, where the nodes are explicitly told with some information users provide how to execute transactions.

It’s an open question whether ultra high high throughput chains are a victim of the problems associated with filling blocks, or “block stuffing” Block stuffing is where a block must be filled to a certain extent for the node operators to extract enough gas fee compensation to justify their ongoing operation costs. Solana suffers from this problem and subsidises its validator set by diluting the SOL token to send to their validator set on a constant inflationary schedule. Some chains that bill themselves as performance orientated use a method of optimistic parallelism, where the chains optimistically try to batch transactions together, or use a method of hinting to themselves beforehand what things should be. EVM chains like this include Monad, and Pharos.

Arbitrum has a single sequencer model, and does not feature (to my understanding) any explicit or implicit parallelism on the node level. You might argue that it’s not needed, since Arbitrum itself has soft confirmation of transactions, but not instant bundling and execution of them to have a more sustainable model of transaction inclusion, and having a single sequencer means the potential pool of rewards for transactions are maximised for the node. My mind is that OCL’s approach to scaling Arbitrum isn’t to scale the execution of the blocks coming in, but to provide developers with the ability to spin up Orbit chains with their own rules to resolve this issue themselves.

I would say that to have end user visible high throughput, we should focus on executing transactions using alt signature execution methods, and having optimistic transaction inclusion. Which is the approach we can take today with the Orbit chains, and natively on Arbitrum One in a compute efficient way, thanks to Stylus.

Rather Labs and Move on Stylus

Rather Labs are building an Intermediate Representation (IR) compiler from Move bytecode provided by the Sui Move toolchain to WASM. This way, we can deploy Move smart contracts ourselves to Arbitrum!

They’ve been so kind to write a writeup for us documenting their approach, and they’ve been writing consistent status updates, which we’ll paraphrase here.

Move Bytecode

Move Bytecode, from what I gather, in its high level form looks like the following:

Unlike WASM, some of Sui-relevant operations are natively available to the programmer in the operation set, meaning a more bespoke and potentially complex optimisation pipeline, but to the benefit of less code on-chain, assuming the optimisation pipeline does its job. Also unlike WASM, Move’s bytecode format supports static jumps, which was one of the focal points of the Ethereum EOF conversation recently. The intent behind static jumps in the EOF was to support a more obvious control flow in the smart contracts, making static analysis easier. There are some operations access gating mutable and immutable access to objects, which makes sense considering the access control that are needed for the coins we discussed above. The equivalent in a reduced instruction set might be a system call, or a call to a foreign function interface in WASM, which would be needed to perhaps load a specific register before an operation.

Move conversion code

So we’ve established here that the Rather Labs team must surely support a conversion stage that determines the location of the jumps and converts them to relative ones, one that converts some of the high level access control operations to the calling of Rather Labs written stub functions. It seems this is the case, with their pipeline looking like the following:

This approach seems solid, since the Move bytecode could be translated literally into a series of stubs and access control methods baked directly into the contract, since it’s a simple instruction set. The Move-specific functions could be replaced with the using of local functions. This approach also lets the developers build WASM-specific optimisation code themselves, and benefit from an extra optimisation pass post WASM code creation if that’s feasible.

Current status

According to their last update, they’ve supported the basic operations and the entrypoint! A reference repository lives at https://github.com/rather-labs/move-stylus-poc.

I’ve seen from reading their code that they’ve supported local conversion of the Move types to the Ethereum ABI, so the code will be compatible with any Solidity interfaces you might want to use it with.

I’m super excited for how things are going with this project! The Rather Labs team is obviously super talented and extremely qualified to be building something like this.

To stay up to date with their progress, make sure to star their repo 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!

1. 🚀 Pectra + ArbOS 40 overview: Arbitrum’s new upgrade introduced.

2. 🗄️ 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!!

3. ⏱️ 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:

1. 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.

2. 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.

3. 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.

4. 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:

https://github.com/OpenZeppelin/rust-contracts-stylus/blob/e15e5796890af819032f81aca2f7a0288642a450/lib/crypto/src/poseidon2/instance/bls12.rs#L1

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:

1. 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

2. 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 compile

3. I 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()
>   }
> 

3. 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:forge

4. This 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.sol

At 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 0x

5. I 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 0x3d2898D2a40a9b23Da4733cb08d4FdE837E6eA3f

Which 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!

1. 🕹️ Supporting Stylus on RISC-V: I’m pleased to share I’ve written a simulator for RISC-V with Ethereum environment calls, and am supporting the Stylus SDK with it for a few things! This post will share a link to the simulator without the patched SDK, which I’ll release in a part 2.

2. 🍲 Interview with Levan, Elite hackathon winner.

I’m super excited to announce that we’re collaborating with LearnWeb3 as a Stylus resource! LearnWeb3 is an educational platform to learn development. More to come soon.

Read on, and as always, if you have any feedback, 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

Congratulations to the team for releasing 0.9.0! 0.9.0 includes several meaningful improvements including trait based inheritance! I can’t wait to play with this.

1) Stylus on RISC-V (32IM) Part 1

You may have seen the news recently with Vitalik mentioning wanting to simulate RISC-V on-chain, in lieu of (and perhaps alongside or interpreting) the EVM bytecode format of today. The goal I assume is that it’s useful for completed proving with ZK tools, maybe motivated by the research of RISC Zero and the rest of the ecosystem researching proving there. I was discouraged to see that he used ChatGPT to suggest that Rust smart contracts are ugly, we know from experience here in the Stylus ecosystem that that’s not necessarily the case!

To recap how Stylus works: WASM is sent on-chain, nodes download the code, then the nodes “warm” them up (or “bake” them), and the programs are converted to native code and stored. Certain operations are unavailable, including floating points, any threading extensions, etc. I noticed that WASM’s newest spec was just ratified, and it includes operations involving scalar word and vector operations, which is quite exciting. These translate nicely into the native environment alongside the memory model, which is already familiar to most programmers outside of the Ethereum world.

I don’t believe that there is any advantage to a particular execution environment when it comes to performance between WASM and RISC-V, but the former has a storied history of execution in sandboxed and JIT’d environments (the browser), while the latter is preferred in the embedded context. With this perspective, it should be possible to build a interpreter on-chain that interprets RISC-V without any significant cost, except perhaps the storage and the loading of the executables. It should be possible to have near-native performance of execution of what you might otherwise see of a full rewrite of some node running software, since a native executable is simulating it anyway. It should be possible to reuse the existing SDK and toolchain to generate the code.

The full goal:

1. Get a RISC-V interpreter interpreting RV32IM running unprivileged code code deployed on-chain without any trap handling features. Get a program loading model in somehow, perhaps involving reading from a deployed contract with a junk preamble that gets skipped. Test that it can simulate the contract, using 9lives’ stylus-interpreter and some spooky stuff. I chose this variant because of the “riscv32im-risc0-zkvm-elf” target that Rust makes available, which is used by Risc Zero’s toolchain, which is a tweaked environment that provides some custom accelerators for some areas of cryptography. Though our end goal overtly won’t be to use their stack for proving and verifying (simply to use riscv32im on-chain), we’ll find out in this article how feasible this will be to use! This is an exploration, and this possibility could unlock some future coprocessing usecases. In this post, we’ll only be simulating it locally to see if our concept works.

2. Add some operations to the interpreter that use the available exports that we’ve grown accustomed to. These include storage accesses. Keep it simple for now to validate the concept works.

3. Release a contract somehow that transparently uses any RISC-V code when it’s called into the same way as you might a WASM contract.

4. Maybe even figure out how to prove what’s happened by receiving a receipt from a Stylus program? Risc Zero’s prover stack gives you a STARK that you can use to verify the execution of the contract on-chain. It might be redundant to do so, since we’re executing on-chain, but maybe there are other possibilities out there that could be expanded on if that’s possible? Maybe ZK coprocessing an off-chain Stylus contract that leverages some permissioned local offerings or something similar? Though, the focus of this will be using the Stylus SDK with the ISA and an interpreter, on-chain.

So, in this part 1, we’ll be building a OCaml-based simulator of RISC-V 32IM to experiment with our approach, and showing off how to load in the SDK for some EVM native numbers before later completing the SDK to use RISC-V fully in a later post. I have some development done there, but I don’t feel complete about it yet and want to release something since it’s been a while!

Setting up a project

First, let’s compile a simple hello world program, but import the Stylus SDK and use a type exported from it:

// src/main.rs

#![no_std]
#![no_main]

#[panic_handler]
fn panic(info: &core::panic::PanicInfo) -> ! {
    unimplemented!()
}

pub extern "C" fn main() -> ! {
    loop {}
}

Since we don’t have a way to return things, we need to hole out the return type for our exported main symbol. That’s what we do here. I set some other things:

// .cargo/config.toml

[build]
target = "riscv32im-unknown-none-elf"
rustflags = ["-C","panic=abort"]

// Cargo.toml

[package]
name = "risc-hello-world"
version = "0.1.0"
edition = "2021"

[profile.release]
codegen-units = 1
opt-level = "z"
strip = false
lto = true
debug = false
rpath = false
debug-assertions = false
incremental = false

Great. Seems familiar? Now, to use stylus-sdk in its basic use. I pulled emballoc off the net without thinking much about it, because I gathered from its description that it would be suitable for our target. I downloaded stylus-sdk, alloy-primitives, and disabled the default features. I went to compile and we hit our first roadblock:

error[E0432]: unresolved import `alloc::sync`
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/const-hex-1.14.0/src/traits.rs:14:5
    |
14  |     sync::Arc,
    |     ^^^^ could not find `sync` in `alloc`
    |
note: found an item that was configured out
   --> /home/user/.rustup/toolchains/1.83-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:246:9
    |
246 | pub mod sync;
    |         ^^^^
note: the item is gated here
   --> /home/user/.rustup/toolchains/1.83-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/lib.rs:245:1
    |
245 | #[cfg(all(not(no_rc), not(no_sync), target_has_atomic = "ptr"))]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

What now? I wonder what the context of this dependency is? I was under the impression const-hex was simple (just for having hex strings decoded at constant time), but perhaps something else is going on here. Let’s dip deeper. I disabled the default features, which included “alloc”, since apparently that’s implicitly enabled. I was hoping that would feature flag out alloc, but I was mistaken. Ouch, it seems that alloy-primitives has a hard dependency on const-hex having alloc enabled.

Let’s try downloading alloy-core, then patching its dependency on const-hex by removing the setting of the alloc flag:

error[E0425]: cannot find function `serialize` in crate `hex`
   --> crates/primitives/src/bytes/serde.rs:10:18
    |
10  |               hex::serialize(self, serializer)
    |                    ^^^^^^^^^ help: a function with a similar name exists: `deserialize`
    |
   ::: /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/const-hex-1.14.0/src/serde.rs:63:1
    |
63  | / pub fn deserialize<'de, D, T>(deserializer: D) -> Result<T, D::Error>
64  | | where
65  | |     D: Deserializer<'de>,
66  | |     T: FromHex,
67  | |     <T as FromHex>::Error: fmt::Display,
    | |________________________________________- similarly named function `deserialize` defined here
    |
note: found an item that was configured out
   --> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/const-hex-1.14.0/src/lib.rs:124:31

Looks like we have a battle ahead of us on this. What business does const-hex have with atomic reference counting anyway? I wonder if we can find a constant time hex that does things in a no-std environment comfortably without the alloc dependency. I found https://docs.rs/const-decoder/latest/const_decoder/… Wow, this is hard basket. Maybe another approach is needed? Why does const-hex need Arc? Answer: for a trait it implements. Perhaps we can take it out of the picture somehow. It looks like const-hex has the alloc flag for the Arc dependency, among other things. Removing the Arc FromHex impl is definitely a lot easier!

Moving along, we run into similar issues. dyn-clone, lazy-static, they all have in common a alloc::sync dependency! It seems like the complete availability of alloc (albeit, for the rest of the variants) is a hot and ongoing topic, from a cursory search: https://github.com/rust-lang/rust/issues/140042 and https://github.com/rust-lang/rust/issues/135376#issuecomment-2593558310. I learned today that MIPS is also supported as a Risc0 ZKEVM target.

I soldiered on, going full hatchetman on everything involving alloc::sync, atomic, etc. I needed to set up critical-section with portable-atomic to support some libraries, and I needed to stub out the behaviour with the critical section so my simulator wouldn’t need to implement any CSRs for this functionality.

Looks like we’re in business!

   Compiling stylus-core v0.8.3 (/home/user/Downloads/stylus-sdk-rs/stylus-core)
   Compiling stylus-sdk v0.8.3
   Compiling risc-hello-world v0.1.0 (/home/user/Documents/markov-geist-research/risc-hello-world)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.07s
% 

I had to unfortunately patch a few dependencies for this to work..

Interpreting with Spike

To interpret RISC-V using Spike, the preferred simulator for RISC-V I gather, aside from Qemu, I largely followed the instructions of https://riscv.epcc.ed.ac.uk/documentation/how-to/install-spike/, breaking from the instructions to alias gcc/ld/etc to a higher priority with my PATH, to reuse it for compilation.

I needed to install the RISC-V ELF toolchain to get the libraries and tools needed for compilation, as we need to sidestep Rust’s standard linker. On my somewhat space challenged laptop, this was a battle, because I wanted to install the toolchain at /opt/riscv per the instructions, but I was unable to, having to settle for my home instead. The tools we’d used alluded to the idea of a RISCV location, so this is exciting, as its the first time that we’re installing the actual build toolchain with GCC!

Warning: git clone takes around 6.65 GB of disk and download size

Boy did I really feel this one. It’s not like I torrent (much). I should’ve bought a Framework laptop with the disk size cranked up higher than my simple El Cheapo Thinkpad. My computer spent at least a few hours compiling everything. I built the newlib version of the RISC-V toolchain (./configure --with-arch=rv32imac --with-abi=ilp32 --prefix=$HOME/riscv --host x86_64-unknown-linux-gnu). I then followed the instructions in the repo, and compiled and set up Spike’s simulator.

I ran Spike with spike --isa=rv32im target/riscv32im-unknown-none-elf/debug/risc-hello-world. Running it seems to start things without any issue, and control-c dumps me into a prompt, which I assume is the debugging experience. Running with “r” kicks us off with spam about illegal accesses, so this is the wrong approach it seems. I went back to the drawing board, and changed the linker that Rust uses to use the one that I got earlier:

[build]
target = "riscv32im-unknown-none-elf"
rustflags = [
  "-C","panic=abort",
  "-C","link-arg=-march=rv32im",
  "-C","link-arg=-mabi=ilp32",
  "-C", "link-arg=--entry=_start"
]

[target.riscv32im-unknown-none-elf]
linker = "riscv64-unknown-elf-gcc"

This lets us compile to ELF, instead of the GNU format that we were using. I also had to point the linker to the location of a object file it couldn’t find (I must’ve made a mistake in the past or something with the prefix argument). Success:

spike --isa RV32IM target/riscv32im-unknown-none-elf/debug/risc-hello-world

I couldn’t find a way to get the symbols exported that I wanted to communicate with Spike though. I think the linker or Rust must’ve been optimising it out. But for our purposes, this seems to work! I played around a little to use different operations to see the impact to verify things were running fine, and they were. I set the layout of the ELF to be the following:

MEMORY {
  RAM : ORIGIN = 0x80000000, LENGTH = 128M
}

ENTRY(_start)

SECTIONS {
  .text : {
    *(.text.entry)
    *(.text .text.*)
  } > RAM

  .rodata : {
    *(.rodata .rodata.*)
  } > RAM

  .data : {
    *(.data .data.*)
  } > RAM

  .bss : {
    *(.bss .bss.*)
  } > RAM
}

We define a trap handler for Spike to jump into when we have a trap situation (as is the normal behaviour with RISC-V under most circumstances), and the _start section, which we’ll use to define as the program entrypoint, as well as define some program-wide NOP mutex functions that we need to be downstream users of Alloy-dependent atomics code. At this point, I needed to rip out emballoc, since I found it was spincycling when we weren’t setting the critical region in a way that it wanted. This is a simple bump allocator we’ll be using (ignore the warning messages when you use this, I’ll fix that eventually):

use core::{
    alloc::{GlobalAlloc, Layout},
    ptr::null_mut,
};

pub struct SimpleAlloc {
    heap_start: usize,
    heap_end: usize,
    next: core::cell::UnsafeCell<usize>,
}

unsafe impl Sync for SimpleAlloc {}

impl SimpleAlloc {
    pub const fn new() -> Self {
        Self {
            heap_start: 0,
            heap_end: 0,
            next: core::cell::UnsafeCell::new(0),
        }
    }

    pub fn init(&self, start: usize, size: usize) {
        unsafe {
            let self_mut = self as *const Self as *mut Self;
            (*self_mut).heap_start = start;
            (*self_mut).heap_end = start + size;
            *(*self_mut).next.get() = start;
        }
    }
}

unsafe impl GlobalAlloc for SimpleAlloc {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let next_ptr = self.next.get();
        let mut next = *next_ptr;
        let align = layout.align();
        next = (next + align - 1) & !(align - 1);
        if next + layout.size() > self.heap_end {
            return null_mut();
        }
        *next_ptr = next + layout.size();
        next as *mut u8
    }

    unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {}
}

At this point, our dependencies look like this from my off-screen exploration, mostly setting feature flags for our dependencies:

[package]
name = "risc-hello-world"
version = "0.1.0"
edition = "2021"

[dependencies]
stylus-sdk = { version = "0.8.3", default-features = false }
stylus-core = { version = "0.8.3", default-features = false }
alloy-primitives = { version = "=0.8.20", default-features = false }
const-hex = { version = "1.14.0", default-features = false }
lazy_static = { version = "1.5.0", default-features = false, features = ["spin_no_std"] }
dyn-clone = { version = "1.0.19" }
bytes = { version = "1.10.1", default-features = false, features = ["extra-platforms"] }
portable-atomic = { version = "1.11.0", default-features = false, features = ["critical-section"] }
critical-section = { version = "1.2.0", default-features = false }
spin = { version = "0.9.8", default-features = false, features = ["portable_atomic"] }

[patch.crates-io]
const-hex = { path = "/home/user/Downloads/const-hex" }
dyn-clone = { path = "/home/user/Downloads/dyn-clone" }
stylus-core = { path = "/home/user/Downloads/stylus-sdk-rs/stylus-core" }

I needed to patch these repos to remove atomic code and have them downloaded locally. I needed to also ask certain packages to use portable-atomic where it could, and then I imported critical-section, which lets us guard the program as it runs in a mutex to implement some synchronisation features without using privileged instructions (or RISC-V CSRs).

I implemented some code like below to set up the allocator:

#![no_std]
#![no_main]

#[global_allocator]
static ALLOCATOR: emballoc::Allocator<4096> = emballoc::Allocator::new();

extern crate alloc;

use stylus_sdk::alloy_primitives::U256;

#[no_mangle]
extern "C" fn _exit(_code: i32) -> ! {
    loop {}
}

#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
    unimplemented!()
}

struct SingleCoreCriticalSection;

critical_section::set_impl!(SingleCoreCriticalSection);

unsafe impl critical_section::Impl for SingleCoreCriticalSection {
    unsafe fn acquire() {}
    unsafe fn release(_token: ()) {}
}

#[export_name = "_start"]
pub extern "C" fn _start() -> ! {
    unsafe {
        let heap_start = HEAP.as_mut_ptr() as usize;
        let heap_len = HEAP.len();
        ALLOCATOR.init(heap_start, heap_len);
    }
    let x = u32::from_le_bytes(
        (U256::from(123) + U256::from(456)).to_le_bytes::<32>()[..4]
            .try_into()
            .unwrap(),
    );
    unsafe {
        core::arch::asm!("mv a0, {}", in(reg) x);
    }
    loop {}
}

#[export_name = "__trap_vector"]
extern "C" fn trap_vector() -> ! {
    loop {}
}

This compiled and ran fine inside Spike! I could verify that the a0 register was set with the results of the 123 + 456 integer sum.

Building the simulator

Now that we’ve verified we can compile Rust programs and run them in Spike, it’s time to write a simulator that interprets RISC-V code of the 32-bit IM variation.

First, for this post, I’ll implement it in OCaml since I like the typing features. I’m a huge fan of OCaml for its code generation to S-expressions and recursive datatypes (including GADTs among other things), which we’ll use as our discussion and intermediate language. Always reimplement your code twice if you can, especially if the need is to blackbox your understanding, to build a weak proof of your concept and your understanding (this is why we build specs and multiple clients and teams). For the OCaml implementation we’ll be building an intermediate representation stage that will simplify development and debugging, at the expense of performance, which we’ll term the lifted stage.

All of our code will of course be supporting loading binaries using the ELF format, which I hope we can safely encode as a EVM contract on-chain without being gated by the 24kb contract deployment restriction. If we have to, we should have enough memory inside the Stylus execution environment to do multiple copies of a program which we reconstruct (imagine yourself uploading a Solana program, now reverse that). In practice on-chain, each contract will have a stub infront to prevent loading by normal EVM contracts, Vyper standard library when you use a blueprint style.

Our interpreter will of course be a single core, and will support the entirety of the IM variant. We will not be implementing any accelerators or coprocessors, though I would like to support Risc Zero’s additions in the future if this becomes a thing that becomes useful to others, or maybe my team makes some use of it as a ZK bridge for our Longtail Pro validium. I thought about this a little, and perhaps we could get there by building some application specific sequencing with this concept. When we implement the calling interface for chatting with our on-chain state with environment calls, we’ll use the calling conventions in the RISC-V SBI (Supervisor Binary Interface). Everything will run in single hardware thread from the running code’s perspective, with no multiplexing or anything similar onto the underlying OS environment, for obvious reasons. We’ll use Spike’s convention of setting the registers at the beginning of the simulation to zero. Reiterating: for now, we’ll implement EVM operations as ecalls without trap handling and mset/etc (we’ll simply write to memory for our example).

Implementing C bindings to binutils

ELF is of course the object loading format we use daily. ELF is made up of sections, with a few having predefined purposes, including a data, junk, and executable section. We won’t be reading from program headers since I’ve had so many issues linking to libelf (which would’ve been preferable here). Program headers are a simpler way to lay out the program in memory, and the sections are more information for linkers and development tools. In our first revision OCaml simulator, we’ll be using binutils C bindings to read sections to get these. This is due to linking issues I had with libelf on my computer:

Using libffi and OCaml’s Ctypes makes this simple. This code essentially binds abstract types to definitions a C parser picks up, and we even manage the memory ourselves using the garbage collector and Bigarray with the C layout later when it asks for a memory pointer.

This lets us create downstream experiences from the bindings quite easily. The lower part is a simple application that reads sections and checks if the section exists for _start. We can use this to process the sections and symbols for the Rust code, which we then fill the gaps of to implement code like program functionality.

Implementing memory

Using the bindings, we can create a list of memory. This is an approach that doesn’t scale very well under performance (perhaps a btree, contiguous allocation, or a tree structure is better), but for our purposes of measuring and understanding the eventual implementation (and the nature of perhaps needing to store each section on-chain as a contract that we search to find) it works.

The simple type looks like such:

We need a function to construct our list of memory (and writeable, readable, and executable gaps):

Our memory needs a few functions to support accesses from within it:

The $$ infix operator is used by us to compose functions together in a Haskell style form. In OCaml, every function is “curryable”, where functions can be partially applied and made into new functions, as each function with multiple arguments is just a function taking one argument that’s composed to return another function with one argument, and so on.

This is the practice of partially applying a function like this simple math function that adds x, y, and z together:

 # let a x y z = x + y + z;;
val a : int -> int -> int -> int = <fun>

Returns another function that takes two arguments:

# a 123 456;;
- : int -> int = <fun>

Which we can apply normally later:

# let b = a 123 456;;
val b : int -> int = <fun>
# b 123;;
- : int = 702

First class functions are a neat tool we can use to build readable and reusable code. In our memory accesses, we scan the list to find the regions that we want to support.

Implementing Ethereum storage operations:

We implement some simple storage loading and storage writing operations. These are called into by the simulator when the user uses the environment calling operations.

Undoubtedly, a better approach is possible for this, probably using a driveby-style infix operator. We need to use the int32 type so can store this comfortably in our memory array later if needed.

We also implement a simple calldata type and a printing method:

We can be very flexible with the storage of this type since it’ll likely be immutable and just an array.

Implementing the simulator

We build a simulator record type that stores everything about our program.

We implement everything using a functional style, dropping into an imperative approach for our calldata and memory storage, for performance reasons. Even for our test tool we can’t support functional accesses over a bigarray quickly, and I don’t want to implement a write ahead log that we can use for this yet! Note that everything after the record field “[@default” is a hint for the syntax preprocessor which we use below, the “make” deriving preprocessor I use. The deriving fields include a generator some hypothesis testing and printing functions. In Rust, you might use:

#[derive(

We implement registers:

And some gettors and settors:

Now that we’ve implemented the basis for our machine, we must implement the higher level datatypes of the decoded words:

We need a low level decoder now!

Implementing a decoder

Let’s create a record for a decoded word in a semi-decoded environment:

We implement some code to do decoding of the word to our in-between type:

There’s some off-screen masking and unpacking I won’t delve into here. I used riscv-opcodes from the RISC-V organisation as a reference alongside the manual to find the masks for every field inside a RISC-V decoded word. We can build a later stage of the decoding pipeline here that works on these decoded singleton tags.

These convert it to the higher level type we showed off in the decoding code. Following this operation, we can develop our lifted type.

Implementing the intermediate type

We can take the compiler output to do some pattern matching over the decoded type to our lifted representation:

This code unpacks the numbers contained within the word so we can convert them to our tagged type (that we saw earlier in the registers).

Building the simulator part 2

Now that we have our higher level type, we can start to pattern match over it and actually execute the code!

This code runs operations on each higher level type:

Which actually simulates the code in an entrypoint!

As a reminder, you can try this code at my repo. A lot of the work that went into this is being glossed over, including a rich encoding/decoding test to test the decoding (always implement twice!) and all of the generated testing code. I’m trying to focus on structure!

Interacting with Rust

This code lets us load and store words from the Ethereum storage:

let mut x = U256::from(100);
x += U256::from(123818);
let x_arr = x.to_be_bytes::<32>();
unsafe {
    asm!(
        "ecall",
        in("a0") x_arr.as_ptr() as usize,
        in("a1") x_arr.as_ptr() as usize,
        in("a7") 1,
    );
}
let mut b = [0u8; 32];
unsafe {
    asm!(
        "ecall",
        in("a0") x_arr.as_ptr() as usize,
        in("a1") b.as_ptr() as usize,
        in("a7") 2,
    );
}
let s = format!("{b:?}");
let ptr = s.as_ptr() as usize;
let len = s.len();
unsafe {
    asm!(
        "ecall",
        in("a0") ptr,
        in("a1") len,
        in("a7") 0,
    );
    asm!("ebreak");
}
loop {}

This silly program stores a unsigned Ethereum word (uint256) to memory, and reads it back to a separate slice, which it then prints using the logging environment call.

If we build and run it, we can see:

% dune build bin && ./_build/default/bin/main.exe /home/user/Documents/markov-geist-research/risc-hello-world/target/riscv32im-unknown-none-elf/debug/risc-hello-world

[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 255, 255, 228, 14]

Excellent! It seems we’re loading and storing correctly!

What’s next?

Stay tuned for part 2 on this, where we’ll show off how to use the contract entrypoint and storage features, and release the patched SDK. I’ll be progressively developing the devex on this project, and my hope is that we can use Stylus as the go-to environment for ALL smart contract development, especially if Ethereum begins support for RISC-V. This simulator is the first step to having simulation on Stylus WASM today, so we can build contracts everywhere tomorrow if needed.

You can start using the repo at

2) Levan

Who are you, and what do you do?

I’m really happy to feature Levan, the winner of the hackathon we hosted in Romania for Stylus! Super impressive programmer.

I am Levan, software engineer with 14+ years of experience, focused on Web3 for the last 6 years.

I started my journey in software development when I was 9 or 10, in Georgian IT center ‘Mziuri’ - I got into the school through a local math competition. I didn’t have a PC until I was 14 and I still remember how happy I was when I had my computer classes twice a week back then. My first programming language was Pascal - which, I still think is one of the best ways to introduce a child to programming. After a couple of years, when I finished learning fundamentals - I got selected in a gifted children’s program in the same IT center and I began a 5 years of extensive journey with algorithms, data structures, international and local competitions, etc. I believe that the knowledge and training that I got during those years made a huge impact on my career success. After I got my first personal computer (which, I still keep at home, btw) - I started learning things on my own as well - e.g. got my first Delphi programs written, learnt C++, later - PHP and C#..

I got my first job as a developer after I graduated school. I applied to become an intern in a local bank - ‘Liberty Bank’ as PHP developer and got hired. That internship and early years of my career boosted my love towards programming - I remember I was staying at the workplace for days to complete tasks and experiment with new things. After a couple of job changes I landed in one of the most interesting local jobs I had - Bureau of Troubled Assets - which was a local startup by three very experienced bankers. They trusted a 21 year old me to build their internal system from the ground up and for around 4 years I believe I did a good job. Those years were the best personal growth experience that I’ve had as a developer, as a person responsible for architecture and as a person overall - I made one of the most important decisions of my life during that period - I got married.

In 2017 I had my first interaction with crypto - I started mining Ethereum and Bitcoin. In 2017 I saw some ‘cloud mining’ platforms and created a similar one for the Georgian market, while I was still working at the Bureau of Troubled Assets. Founders were super impressed with the idea and helped me a lot with the organizational stuff. Then the market crashed and mining was not profitable anymore, so after the expiration of contracts we stopped that project.

In 2018 there were lots of changes in the Georgian financial market and I at the same time got a very interesting offer - it was time to grow. It was my first remote job as well - for two years I was responsible for building the backend of Sense Chat (EOS based e2e encrypted chat with social features). Then the project stopped, however - the CEO kept the team for another project - Libre, which is an Antelope-based scaling solution (Layer 2) for BTC. We recently launched a Loan platform which is already gaining some traction and hopefully it will become a successful project.

I believe that expanding my knowledge into different directions is key to my development and securing my and my families future and well-being. In 2022 me and a couple of my friends launched a local crypto on-ramp/off-ramp platform, currently serving around 40k users in Georgia. Besides that - I discovered that I love hackathons, I am good at them - and now I am trying to use hackathons to make new connections (that’s how I met Alex and now I am writing these lines) build out new products and potentially launch them.

What web3 ecosystems have you worked in?

I have worked with BNB Chain, ICP (currently in process of launching one of the projects that I built for ecosystem during the hackathon), worked with Antelope based ecosystems (Libre chain) - and still work on it on daily basis, worked a lot with Bitcoin (including Runes / Inscriptions)

What are your impressions of working with Stylus, good and bad?

Definitely good. Using Stylus allows me to write more complex (and expensive) logic in smart contracts, which – in the end, make my overall products better with simpler architecture. On the ‘nice-to-have’ side of things, I agree with Dragoș (we met each other at ETH Bucharest =) ) - more scaffolding tools would be nice. But hey - we can work on that ourselves and bring more value to the Stylus ecosystem.

What software do you use?

• MacOS since 2019.

• Editor: VSCode, Cursor.

• I use Clickup for my day-to-day task management.

• Termius for accessing my servers

• iTerm as local terminal

What hardware do you use?

At the moment - Apple M3 Max with 64GB RAM. I upgraded from M1 max which I had for three years so.. next upgrade will be in 2027 (unless I break my current one)

How can we get in touch with you?

Say Hi, ping for potential collaborations - https://x.com/blockcraft-tech

What’s a piece of advice you’d give someone new to web3?

For anyone coming to Web3 - start thinking about the product, the value that you can create to attract new users. Web3 space desperately needs proper products.

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

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!

1. 🕹️ Introducing OrderbookKit: OrderbookKit is a one click deployment of an orderbook to any Arbitrum chain, powered by Stylus.

2. 🧢 Introducing Stylusup: https://stylusup.sh is a one liner creation and setup script for Arbitrum Stylus, including a new website for more info on the ecosystem.

3. 🍲 Interview with Dragoș, super powerful freelance software engineer.

Read on, and if you have any feedback about the newletter, I’d love to have you fill out a form sharing your thoughts. It would mean a lot to me if you filled this out:

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

1) Introducing OrderbookKit

I’m super excited to announce OrderbookKit, the second dApp funded by the Arbitrum DAO. OrderbookKit will be a one click orderbook deployment onto any chain powered by Arbitrum, implemented in Rust Stylus. The newsletter will cover the development practices of this project as it comes along! For now, you can sign up via the newsletter waitlist on the page to learn more as it approaches completion.

We’ll be publicly developing OrderbookKit! This will include sharing design decisions, how to write hooks, how to extend the code, and more. The source code will be fully audited. There will be a way to embed hooks/tools into the orderbook, and hopefully I’ll figure out a way to get liquidity and marketmaking sourced alongside the deployment of the orderbook as a service somewhere. If I don’t figure out an approach for this, maybe a simple deployment for posterity that’s a reusable tool for others is enough. The best kind of plan for something like this is to build it and to see how people react!

I’m in the process of experimenting with a custom interpreter for a special OrderbookKit S-expression-like stack-based programming language. I don’t know to what extent this will be existing in the final product, but this sort of thing excites me, so I’d love to breathe fresh air and experiment wherever possible. The few programs relevant natively to the orderbook itself built into the interpreter vehicle will be a simple AVL tree derivative, maybe adjusted to amortise the accesses somehow (a la DYDX I gather, if I can find an approach that makes sense?) on-chain.

What especially interests me is the concept of evolutionary agents that have the capacity to edit their code as they exist and trade on-chain in response to trade and liquidity depth titled “market signals”. What excites me is the possibility to open the social case for this and to allow agents to edit each others code as well, and to react to “user signals” that can be created and propogated by other agents, or by EOAs trading on the market. I hope to use this orderbook vehicle to, develop something like this! The task to build this is building these operations for this programming language additional to the orderbook itself:

1. An operation for a program to breed with a specific program with its identifier stored on a stack, to produce a randomly combined derivative.

2. The ability to introspect the orderbook and the recipients of the last received market signal or user signal.

3. Branching and basic math operations.

4. The ability to make a ask or a bid, and to be aware of the balance of the token held by the program.

5. The ability to send another program or EOA some tokens.

6. The ability to inject code after the program counter into another program or empty program “slot” (we’ll have to cap the amount of programs trading in a market at a given time given the constraints of our runtime).

7. The amount of steps that each program can take per tick before needing to return, or being exited prematurely. This should be interesting to see as a primitive that the programs themselves are aware of, so I’ll also support this as a operation for them to branch on.

8. Random copying of the surviving programs after a iteration of a market has been concluded back up to a specific quota. The random copying will of course include randomly inserted permutations at this stage.

It’s worth noting that since this is a Stylus program written in Rust, anyone could run the orderbook locally or in a distributed environment without touching what’s on-chain, then seed a deployment. So this OrderbookKit program is a sort of program generator in a sense (in it’s completed future vision form).

Maybe before beginning to have this exist I’ll simulate some programs locally on examples of wash trading for a fun quantitative finance example to show off Stylus. Maybe a simple game of trying to accumulate as much token as possible in a hundred thousand generations in games of 10,000. I’m very curious how it would be to have a game where only the top 30% of traders in a fake market left alone with a fake asset are allowed to survive. I’m curious how the interaction of the problem of a number of upper ticks that can be run interplay with program copying, whether programs running with a very high amount of steps have little NOP sleds inside their programs with a diluted stack to possibly interfere with sending (it could be implemented with a loop around buffer). In an environment where there are less steps for trading programs to run, it might be better for them to survive purely on a only functional basis. Who knows?

Any issue of doing this on-chain is the economics of transaction sending, as you must pay to simulate on-chain the trading environment and its agents and its onerous storage accesses (which are poorly equipped for the EVM’s tree approach to storage). There is also the power of a EOA to speculate and trade the behaviour of the agents themselves, which will have trading capabilities. Weird counterpoint to this: this isn’t a bad thing. The agents themselves are tools for consensus using a market format, and the burden of convincing a program could be on the EOA to cough up a fact that the program has learned is relevant to a trade it must make.

Imagine a wild situation where two EOAs are trading adversarily on the orderbook against each other and they must play the game of convincing the programs using signals to do things for them! You might say that the social signaling feature makes it possible to easily cheat, but I’m interested in seeing whether the programs will adopt a defensive mechanism of outsiders where they pair it with liquidity information, or, if they’re left alone (and don’t have so many iterations to learn and grow, which is more likely since who’s going to do this themselves), be abused.

To do all this, the business case must be married to the concept, which is to build a successful orderbook primitive on-chain, with an easy deployment on-ramp for any Orbit chain. Regardless of how this turns out, it’s my hope this is useful to the Stylus ecosystem.

2) Introducing Stylusup

I’m super pleased to share a new website to help people on-ramp into Stylus (https://stylusup.sh) and a simple to use script that sets you up with Stylus on your computer instantly:

curl -s https://stylusup.sh/install.sh | sh

Which lives at https://github.com/af-afk/stylusup.sh. It will collect information on the language used by the local system, the processor architecture, and the operating system, which will be reported at https://popcon.stylusup.sh (in the same vein as the Debian popularity contest). Users can fully opt out by interrupting at the stage where it asks you if you’re comfortable with the analytics collection if it can read a line from stdin, or with STYLUS_POPCON_OFF with no arguments.

It’ll do the following (currently it only reports the info of the host, :

1. Install Rust using Rustup if it’s not installed.

2. Install wasm32-unknown-unknown using Rustup if it’s not installed.

3. Install the Cargo Stylus subcommand.

4. Ask the user if they’d like to create the example repo, giving an example of how to do so.

My hope is this will simplify the journey of users trying Stylus! I’ve tested it on Debian, Ubuntu, and MacOS with a friend. Extra coverage is needed so far for better testing so far! If you have any issues, please direct them in the repo.

3) Interview with Dragoș

Who are you, and what do you do?

I'm Dragoș Horodnic [ˈdraɡoʃ hoˈrodnik], a software engineer, a FOSS and web3 enthusiast.

My story starts with my first hello world written in Pascal when I was 10, coupled with early internet access during the golden era of forums and IRC where I've spent countless hours learning new things, teaming up with diverse people from across the globe, working together on projects for fun. I witnessed what everyone back then hyped as web 2.0, people actively participating and interacting on platforms, the nascent of social media, and online shopping.

I was too young and naive to understand that in the end a handful of powerful entities will essentially exploit our time and attention for profit and I should probably stop before I make everything sound like a dystopian rant, but from my point of view the state of the web has been in a decline ever since. It no longer incentivizes its users to do their own research or come up with meaningful contributions but merely to consume content trapping them in doomscrolling timesinks and walled gardens. For me, web3 is a glimmer of hope that we can restore that brighter side of the internet and treat its users with respect, not like a commodity, by giving them the freedom to express and interact without bounds hidden in uncomprehensible T&Cs that they are coerced to accept. Self-governed communities through DAOs, interoperability through open standards, availability and censorship resistance through decentralization, are just a few examples of solutions towards the goal of a free space that web3 brings to the table.

For the most part I've developed web and mobile applications for startups including my own initiatives, 2020 marking the beginning of my web3 journey at Nexus Mutual which was definitely the most exciting project I've worked on. Besides freelancing, I am currently developing a permissionless web3 alternative to gig economy platforms that will offer transparent fees and competitive pricing for its users. Even though it's in a very early phase, I am exploring available layer 2 solutions which I ignored for long enough.

What web3 ecosystems have you worked in?

I've mainly worked on Ethereum but I had brief encounters with other chains, mostly EVM-based while working at Nexus Mutual to allow users to attach a proof of loss on other chains when submitting claims. I have experimented with Cardano's Plutus but the community traction of Ethereum and the plethora of available resources make me feel at ease.

For certain usecases like my own, frequent smaller transactions on Ethereum are not really feasible due to gas fees and I've postponed looking into layer 2s for a long while because of the sheer number of them, hoping that one day I'll just pick the winning one when needed, but the decisive day could be far ahead.

So for the past month I've started diving into Arbitrum after attending a hackathon at ETHBucharest where a particular track immediately drew my attention: a gas optimisation problem brought up by Alex from Superposition, designed similarily as a CTF challenge.

Not only that I've been triggered when I heard the two words put together, gas optimisation, but the contract was written in Rust using Arbitrum's Stylus SDK. All these were new to me and I thought it would be a good opportunity to try Stylus out and later use it in my projects. I had a lot of fun and the contract itself highlighted the advantages of using stylus over Solidity really well.

What are your impressions of working with Stylus, good and bad?

Stylus is very promising but like every new piece of tech, there are areas worth improving. I've started sketching an on-chain MMO RPG that I want to write using Stylus. I thought it would be an enjoyable and thorough first project for learning. I'd be more than willing to share additional insights after I am happy with the end result, but so far I've noticed few things.

The good:

• The development tools such as LSPs for Rust are much better than what's available out there for Solidity where certain errors are only brought up at compile time.

• It opens up new possibilities for expensive checks or loops that otherwise would have been implemented as offchain workers and merkle proofs.

• You can mix solidity in your codebase and call Solidity contracts from stylus.

The would be good to have:

• A CLI scaffolding tool to quickly setup multiple contracts in a monorepo.

• More examples of advanced usecases in the documentation and project structure best practices.

What software do you use?

I use Arch Linux (btw), OpenBSD and occasionally macOS. I prefer free and open source software and I like using everything in a keyboard-centric fashion because it helps me stay focused and interact faster:

• Text editor: neovim

• Window manager: dwm]

• Terminal: st

Since everyone around me can't abstain from mentioning LLMs or AI code editors every minute, I recommend avante.nvim for neovim users that feel the FOMO. I'm not a big fan of AI coding but your mileage may vary.

I also use Proxmox to self-host services at home such as VPN, CalDAV server, DNS, OMV etc.

What hardware do you use?

My main driver is a Framework laptop (AMD Ryzen 5 7640U, 32GB RAM, 2TB) running Arch.

How can we get in touch with you?

I'm always open to chat with people sharing similar interests, from dotfiles to web3.

LinkedIn: https://www.linkedin.com/in/dragos-horodnic/

Github: https://github.com/horodnicdragos

What's a piece of advice you'd give someone new to web3?

I highly recommend being able to understand what smart contracts do.

It offers you a huge advantage when interacting with web3 apps. Don't interact with unverified and unaudited smart contracts. If you want to build dapps, start playing around on a testnet and start small such as integrating with an existing contract avilable on that testnet. I also recommend going through OpenZeppelin's libraries and understanding their purpose. Don't be afraid to dive deep into how things work. Be wary of scammers and stay safe.

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

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!

I’m excited to feature Jack (0xjsi.eth) and his stablecoin using Rust Stylus on Arbitrum! Jack is a competent Swedish dev from the Matos DAO whom we introduced to Stylus for the purposes of this article. For future posts, we’ll be introducing other people from the rest of the space to author posts themselves! Jack will also be a recurring character, hopefully with another cool project as soon as something nice comes to mind. :)

To recap: Stylus is a transformative technology for writing smart contracts. It lets you write your Arbitrum smart contracts in Rust, Zig, C, or Go, which you can interact with like you would a Solidity smart contract. For the Arbitrum node (and the perspective of your users) there is no difference between a Solidity contract, and a Stylus contract, except the execution circumstances. This nets us several advantages, the main being the costs of your code (almost 90% cheaper), and a way more expressive and secure way of writing smart contracts!

Grab the Stylus: A Solidity dev’s journey through writing modern smart contracts on Arbitrum

This blogpost will be about the journey of developing and deploying my first contract on Arbitrum Stylus using Rust WASM, what the experience was like and what challenges I ran into.

Intro

First, quick intro: My name is Jack, you might see me under the pseudonym 0xjsi.eth online (say Hi if you see me, I’m always down to connect). My Web3 adventure kicked off in 2020 when I dove into Ethereum accidentally right in time for DeFi Summer, chasing yields and getting hooked on the tech behind it. That passion led me to a two-year blockchain development program at a vocational college in Sweden, and now I have spent the last two years working full time as a Solidity smart contract developer, and as of recently, a Rust backend dev. When I’m not elbow‑deep in work code you’ll find me anywhere around the world, grinding at a hackathon, jamming with my band on tour or shitposting on x dot com the everything app.

When my friend Alex (bayge.eth) nudged me to write about Arbitrum Stylus, I’ll admit—I barely knew what it was, there is just so much cool tech within this field and only so much space in my brain. I spent a day researching, expecting Stylus to be just a WASM VM with no EVM ties. Boy, was I wrong. Stylus is a dual VM powerhouse, blending EVM and WASM with shared state. Keyword here being a dual VM environment, this is way cooler than e.g. a transpiler that converts Rust code to Solidity, or a compiler that compiles Rust down to EVM bytecode, for multiple reasons. One being, both languages will be executed on the most efficient VM for the code, meaning that Rust code will run way cheaper than it would straight on the EVM, secondly, since the non EVM part is a WASM VM, this means that we are not forced to use Rust, but we have the flexibility to run any programming language which could be compiled down to WASM. Stylus doesn’t replace Solidity; it supercharges it, letting Solidity and WASM contracts call each other seamlessly. This opens endless possibilities for smart contracts that were unthinkable before.

I thought for a while about what kind of project would be interesting to develop for first getting my feet wet with Stylus development. I decided on porting shafu0x MicroStable fully to Rust on Stylus, both since it seemed like a good small project, as well as a fun opportunity to hit 2 birds with one rock, since I could also make a pull request to the MicroStable-World repository.

Building

So, let’s get started! I set up the project as instructed in the Stylus quickstart docs. After resolving some minor clunkiness regarding adding the correct WASM target I am ready to get started. Coming from a Solidity + Foundry background, I can right away tell that these Rust configs + running the dev node in a Docker container feels more clunky than just using the forge command line tool. But anyway, now I am all setup and ready to go, git repo here!

So the project will essentially consist of 3 parts;

1. The ERC20 token, a contract inheriting the ERC20 standard, and then extending it with public mint and burn functions, guarded by modifiers which will only let the “manager” contract interact with these functions.

2. The Manager, a contract that will be fully responsible of receiving collateral deposits in the form of Wrapped ETH, and based on the current price fetched from the Oracle, determine how much of our stable coin the user can mint. Will also handle possible liquidations if the users collateral is too low.

3. The Oracle, this is a contract we’re not writing. This is the Chainlink data feed contract, where we’ll only interact with a function named latestAnswer() to receive the payment.

This led me down the first challenge! How does one do inheritance in Stylus? For me as a Solidity developer, inheritance is something I heavily use, and I don’t want to unnecessarily implement the default ERC20 implementation. I read through the stylus documentation, and it looks simple enough. Following the Solidity ethos, I find, through some googling, that OpenZeppelin supports Stylus. With very little information out there about this, I went straight to their GitHub repo to see what libs and contracts they have ported so far, which had the ERC20 package I was looking for.

But then, trouble struck: there were version conflicts between Stylus’s and OpenZeppelin’s EVM alloy.rs types that threw errors. I searched for simpler ERC20 libraries, hoping for a Solady-like gem. I found a few, but most were unmaintained or buggy. I ended up copying the least broken one into my project and manually patching it—a gritty but effective fix.

Another surprise? I got compiler errors from the SDK that warned that EVM methods like msg::sender() and block::timestamp() are obsolete, replaced by self.vm().msg_sender() and self.vm().block_timestamp(). Weirdly, Arbitrum’s docs still reference the old syntax.

Once this was all ported, the actual inheritance part was rather easy, firstly, we are instantiating a new struct, which we later use to hold the constant params of the ERC20 contract:

pub struct MicroParams;


impl erc20::Erc20Params for MicroParams {
   const NAME: &'static str = "Shafu USD";
   const SYMBOL: &'static str = "shUSD";
   const DECIMALS: u8 = 18;
}

Afterwards, we’re using alloy.rs package to spin up solidity Storage, which is used to actually hold our MicroParams struct, and whatever else data we need to keep in the constant space. In our case, we need the manager address too to guard the mint() and burn() functions to only be accessible to this address.

sol_storage! {
   #[cfg_attr(any(feature = "sh-usd"), stylus_sdk::prelude::entrypoint)]
   pub struct ShUSD {
       #[borrow]
       erc20::Erc20<MicroParams> erc20;
       address manager;
   }
}

Also, for some better error handling, and since the Arbitrum docs covered this topic good, I decided to throw in some Solidity errors to show the user if they try to wrongfully call any of these methods(nothing to do with the inheritance, but figured I might as well show it):

sol! {
    error OnlyManagerCanCall();
    error ERC20MintError();
    error ERC20BurnError();
}

#[derive(SolidityError)]
pub enum ShUSDErrors {
    OnlyManagerCanCall(OnlyManagerCanCall),
    ERC20MintErr(ERC20MintError),
    ERC20BurnErr(ERC20BurnError)
}

Now that we have everything prepared, lets show the actual contract part and where the inheritance is made:

#[cfg_attr(feature = "sh-usd", stylus_sdk::prelude::public, inherit(erc20::Erc20::<MicroParams>))]
impl ShUSD {
    pub fn init(&mut self, manager_address: Address) {
        self.manager.set(manager_address);
    }

    pub fn mint(&mut self, to: Address, amount: U256) -> Result<(), ShUSDErrors> {
        if self.vm().msg_sender() != self.manager.get() {
            return Err(ShUSDErrors::OnlyManagerCanCall(OnlyManagerCanCall {}));
        }
        self.erc20
            .mint(to, amount)
            .map_err(|_| ShUSDErrors::ERC20MintErr(ERC20MintError{}))?;
        Ok(())
    }

    pub fn burn(&mut self, from: Address, amount: U256) -> Result<(), ShUSDErrors> {
        if self.vm().msg_sender() != self.manager.get() {
            return Err(ShUSDErrors::OnlyManagerCanCall(OnlyManagerCanCall {}));
        }
        self.erc20
            .burn(from, amount)
            .map_err(|_| ShUSDErrors::ERC20BurnErr(ERC20BurnError{}))?;
        Ok(())
    }
}

Notice the specific part in the decorator: [cfg_attr(... , inherit(erc20::Erc20::<MicroParams>))] . This is where we do the actual inheritance. Very simple and straight forward logic. You might be confused by my cfg_attr() and see in the arbitrum docs that the suggested way looks more like:

#[public]
#[inherit(Erc20)]
impl ShUSD {

The reason mine looks different leads us down to the next issue I ran into working with Stylus. When working with a cargo Stylus project, there is no simple integrated way to keep more than one different contracts in the same project, due to it only being possible to have one #[entrypoint] decorator. A few hours of hair pulling and head scratching, led me to asking Alex regarding this seemingly weird issue. He showed me his very impressive repo for 9lives which I found way more useful than existing Stylus docs and example codebases. Reading through the codebase, I got a feel for the true value prop of Stylus, and seeing how this wild codebase seamlessly mixes Solidity, Rust and even Huff gave me a good idea of how Stylus could enhance the smart contract experience I already know into new interesting territory.

Anyways, the solution he showed me, to be able to use multiple entrypoints, was to use Rust feature flags to conditionally compile the contract that you wanna compile, then deploy it using the raw WASM files. This throws a bit of the simplicity of using the cargo stylus commands out the window, and gives you a bit more hands on experience, but it’s a clever workaround. The alternative would be for my github repository to host multiple cargo projects with each having a Cargo.toml. While this method works, to me it feels very clunky, and I’d much rather just have one project containing everything. When talking to the Arbitrum Stylus team I’ve been told that easier multi-contract workflow is something they plan on releasing soon (it might even be out by the time you read this).

Calling other contracts

Now once the ShUSD contract is fully implemented, let’s have a look at the manager. From the Shafu repo, everything is probably simple enough to follow here, but let’s check how this is made in Rust! Firstly, in order to call the other contracts, lets set up Solidity interfaces using alloy.rs:

sol_interface! {
    interface IOracle {
        function latest_answer() external view returns (uint);
    }

    interface IErc20 {
        function transfer_from(address from, address to, uint256 value) external returns (bool);
        function transfer(address to, uint256 value) external returns (bool);
        function burn(address from, uint256 amount) external;
        function mint(address from, uint256 amount) external;
    }
}

Pretty straightforward this far, lets set up our global variables and constants:

const MIN_COLLAT_RATIO: u128 = 1_500_000_000_000_000_000; // 1.5e18

#[cfg_attr(feature = "manager", stylus_sdk::prelude::entrypoint)]
#[storage]
pub struct Manager {
    sh_usd: StorageAddress,
    weth: StorageAddress,
    oracle: StorageAddress,
    address_2deposit: StorageMap<Address, StorageU256>,
    address_2minted: StorageMap<Address, StorageU256>,
    is_initialized: StorageBool
}

Notice we set the MIN_COLLAT_RATIO as a regular rust const here, then setting dedicated storage types that we can get from the Stylus SDK. I believe in the actual contract, most notable is my init() workaround for the fact that Stylus don’t support constructors:

pub fn init(&mut self, weth_address: Address, oracle_address: Address, sh_usd_address: Address) -> Result<(), Vec<u8>> {
    assert_or!(!self.is_initialized.get(), ManagerErrors::AlreadyInitialized(AlreadyInitialized {}));
    self.weth.set(weth_address);
    self.oracle.set(oracle_address);
    self.sh_usd.set(sh_usd_address);
    self.is_initialized.set(true);
    Ok(())
}

Besides this, I found most of the syntax and logic implementing this manager contract very straightforward, given that I am reasonably comfortable in writing Rust already.

So calling another contract looked something like (This code won’t work properly for reasons I am covering right after):

pub fn deposit(&mut self, amount: U256) {
    let weth_instance = IErc20::new(self.weth.get());
    let sender = self.vm().msg_sender();
    let this = self.vm().contract_address();
    weth_instance.transfer_from(&mut *self, sender, this, amount)?;
    let previus_balance = self.address_2deposit.get(sender);
    self.address_2deposit.insert(sender, previus_balance + amount);
 }

Issue and solution

Above method is the method recommended by Arbitrum Stylus team , however, in our special context, this method for calling other contracts lacks flexibility. Since in our contract doesn’t implement the TopLevelStorage trait, passing self into the external contract calls doesn’t really do anything, and therefore these calls will revert. This took me a lot of head scratching and yapping with Alex to fully wrap my head around, so what I did for more rapid testing was that I wrote this little shell script . After some reading into the 9lives codebase I found out that they seem to use this method instead, where you setup one file for calls and import these into your contract. I scanned through these contracts for a while, and then decided to give it a go in my project. I first setup my calls.rs file:

use alloc::vec::Vec;
use alloy_primitives::Address;
use stylus_sdk::{prelude::*, alloy_primitives::{I256, U256}, call::RawCall, alloy_sol_types::{sol, SolCall}};

sol! {
    error CouldNotCall();
    error CouldNotUnpackBool();
}

#[derive(SolidityError)]
pub enum CallErrors {
    CouldNotCall(CouldNotCall),
    CouldNotUnpackBool(CouldNotUnpackBool)
}

sol! {
    function latestAnswer() external view returns (int);
    function transferFrom(address from, address to, uint256 value) external returns (bool);
    function transfer(address to, uint256 value) external returns (bool);
    function burn(address from, uint256 amount) external;
    function mint(address to, uint256 amount) external;
}

pub fn latest_answer_call(oracle: Address) -> Result<I256, Vec<u8>> {
    I256::try_from_be_slice(unsafe { &RawCall::new().call(oracle, &latestAnswerCall {}.abi_encode()).unwrap()}).ok_or(CallErrors::CouldNotCall(CouldNotCall {}).into())
}

pub fn transfer_from_call(token: Address, from: Address, to: Address, value: U256) -> Result<(), Vec<u8>> {
    unpack_bool_safe(unsafe { &RawCall::new().call(token, &transferFromCall {
        from,
        to,
        value,
    }.abi_encode()).unwrap()})
}

pub fn transfer_call(token: Address, to: Address, value: U256) -> Result<(), Vec<u8>> {
    unpack_bool_safe(unsafe { &RawCall::new().call(token, &transferCall {
        to,
        value,
    }.abi_encode()).unwrap()})
}

pub fn mint_call(token: Address, to: Address, amount: U256) -> Result<(), Vec<u8>> {
    unpack_bool_safe(unsafe { &RawCall::new().call(token, &mintCall {
        to,
        amount,
    }.abi_encode()).unwrap()})
}

pub fn burn_call(token: Address, from: Address, amount: U256) -> Result<(), Vec<u8>> {
    unpack_bool_safe(unsafe { &RawCall::new().call(token, &burnCall {
        from,
        amount,
    }.abi_encode()).unwrap()})
}

pub fn unpack_bool_safe(data: &[u8]) -> Result<(), Vec<u8>> {
    match data.get(31) {
        None | Some(1) => Ok(()),
        _ => Err(CallErrors::CouldNotUnpackBool(CouldNotUnpackBool {}).into()),
    }
}

So now, instead of natively trying to call these functions and send the full contract context like before, we will instead only do RawCalls to the contract address of the other contract. After this, I implemented these calls into my contract, so final contract ended up looking like:

use alloc::vec;
use alloc::vec::Vec;
use core::str::FromStr;
use alloy_sol_types::sol;
use crate::contracts::calls;
use alloy_primitives::Address;
use crate::alloc::string::ToString;
use stylus_sdk::{alloy_primitives::U256, prelude::*};
use stylus_sdk::storage::{StorageAddress, StorageMap, StorageU256, StorageBool};

const MIN_COLLAT_RATIO: u128 = 1_500_000_000_000_000_000; // 1.5e18

sol! {
    error Undercollateralized();
    error AlreadyInitialized();
    error CouldNotAdd();
    error CouldNotSub();
    error CouldNotMul();
    error CouldNotDiv();
    error ConversionFailure();
}

#[derive(SolidityError)]
pub enum ManagerErrors {
    Undercollateralized(Undercollateralized),
    AlreadyInitialized(AlreadyInitialized),
    CouldNotAdd(CouldNotAdd),
    CouldNotSub(CouldNotSub),
    CouldNotMul(CouldNotMul),
    CouldNotDiv(CouldNotDiv),
    ConversionFailure(ConversionFailure)
}

#[macro_export]
macro_rules! assert_or {
    ($cond:expr, $err:expr) => {
        if !($cond) {
            Err($err)?;
        }
    };
}

#[cfg_attr(feature = "manager", stylus_sdk::prelude::entrypoint)]
#[storage]
pub struct Manager {
    sh_usd: StorageAddress,
    weth: StorageAddress,
    oracle: StorageAddress,
    address_2deposit: StorageMap<Address, StorageU256>,
    address_2minted: StorageMap<Address, StorageU256>,
    is_initialized: StorageBool
}

#[cfg_attr(feature = "manager", stylus_sdk::prelude::public)]
#[cfg(feature = "manager")]
impl Manager {
    pub fn init(&mut self, weth_address: Address, oracle_address: Address, sh_usd_address: Address) -> Result<(), Vec<u8>> {
        assert_or!(!self.is_initialized.get(), ManagerErrors::AlreadyInitialized(AlreadyInitialized {}));
        self.weth.set(weth_address);
        self.oracle.set(oracle_address);
        self.sh_usd.set(sh_usd_address);
        self.is_initialized.set(true);
        Ok(())
    }

    pub fn deposit(&mut self, amount: U256) -> Result<(), Vec<u8>> {
        let sender = self.vm().msg_sender();
        let this = self.vm().contract_address();
        calls::transfer_from_call(self.weth.get(), sender, this, amount)?;
        let previus_balance = self.address_2deposit.get(sender);
        self.address_2deposit.insert(sender, previus_balance.checked_add(amount)
            .ok_or(ManagerErrors::CouldNotAdd(CouldNotAdd {}))?);
        Ok(())
    }

    pub fn burn(&mut self, amount: U256) -> Result<(), Vec<u8>> {
        let sender = self.vm().msg_sender();
        let previous_balance = self.address_2minted.get(sender);
        self.address_2minted.insert(sender, previous_balance.checked_sub(amount)
            .ok_or(ManagerErrors::CouldNotSub(CouldNotSub {}))?);
        calls::burn_call(self.sh_usd.get(), sender, amount)?;
        Ok(())
    }

    pub fn mint(&mut self, amount: U256) -> Result<(), Vec<u8>> {
        let sender = self.vm().msg_sender();
        let previous_balance = self.address_2minted.get(sender);
        self.address_2minted.insert(sender, previous_balance.checked_add(amount)
            .ok_or(ManagerErrors::CouldNotAdd(CouldNotAdd {}))?);
        let ratio = self.collat_ratio(sender)?;
        assert_or!(ratio > U256::from(MIN_COLLAT_RATIO), ManagerErrors::Undercollateralized(Undercollateralized {}));
        calls::mint_call(self.sh_usd.get(), sender, amount)?;
        Ok(())
    }

    pub fn withdraw(&mut self, amount: U256) -> Result<(), Vec<u8>> {
        let sender = self.vm().msg_sender();
        let previous_deposit = self.address_2deposit.get(sender);
        self.address_2deposit.insert(sender, previous_deposit.checked_sub(amount)
            .ok_or(ManagerErrors::CouldNotSub(CouldNotSub {}))?);
        let ratio = self.collat_ratio(sender)?;
        assert_or!(ratio > U256::from(MIN_COLLAT_RATIO), ManagerErrors::Undercollateralized(Undercollateralized {}));
        calls::transfer_call(self.weth.get(), sender, amount)?;
        Ok(())
    }

    pub fn liquidate(&mut self, user: Address) -> Result<(), Vec<u8>> {
        let result = self.collat_ratio(user)?;
        assert_or!(result <= U256::from(MIN_COLLAT_RATIO), ManagerErrors::Undercollateralized(Undercollateralized {}));
        let sender = self.vm().msg_sender();
        let amount_minted = self.address_2minted.get(user);
        calls::burn_call(self.sh_usd.get(), user, amount_minted)?;
        let amount_deposited = self.address_2deposit.get(user);
        calls::transfer_call(self.weth.get(), sender, amount_deposited)?;
        self.address_2deposit.insert(user, U256::ZERO);
        self.address_2minted.insert(user, U256::ZERO);
        Ok(())
    }

    pub fn collat_ratio(&self, user: Address) -> Result<U256, Vec<u8>> {
        let minted = self.address_2minted.get(user);
        if minted.is_zero() { return Ok(U256::MAX); }
        let deposited = self.address_2deposit.get(user);
        let price = calls::latest_answer_call(self.oracle.get())?;
        let value = deposited.checked_mul(U256::from_str(&price.to_string()).unwrap()
            .checked_mul(U256::from(1e10 as u64))
            .ok_or(ManagerErrors::CouldNotMul(CouldNotMul {}))?)
        .ok_or(ManagerErrors::CouldNotMul(CouldNotMul {}))?;
        let value_scaled = value.checked_div(U256::from(1e18 as u64)).ok_or(ManagerErrors::CouldNotDiv(CouldNotDiv {}))?;
        Ok(value_scaled.checked_div(minted).ok_or(ManagerErrors::CouldNotDiv(CouldNotDiv {}))?)
    }
}

Finally, it’s working as intended, all of my tests were passing!

Scaling tangent

In my tests, I made a mock oracle that was returning what the actual oracle was returning that day . In my shell script, I was depositing .1 weth into the contract, thinking this would approximately let me borrow 117,177 ShUSD, given that 175.76555 / 1.5 = 117,177. However, it would of course need to mint me 117,177 *10^18 in order for me to actually have the correct amount, since ShUSD have 18 decimals. But this was not the case, I could only mint 117 of the smallest denominator, equivalent to wei, of my token, leading me to believe that my scaling implementation was wrong. I rescanned the 0xShafu repo to see if my logic was mapping it 1 to 1:

function collatRatio(address user) public view returns (uint) {
    uint minted = address2minted[user];
    if (minted == 0) return type(uint256).max;
    uint256 totalValue = address2deposit[user] * (oracle.latestAnswer() * 1e10) / 1e18;
    return totalValue / minted;
} 

and my version being:

pub fn collat_ratio(&self, user: Address) -> Result<U256, Vec<u8>> {
    let minted = self.address_2minted.get(user);
    if minted.is_zero() { return Ok(U256::MAX); }
    let deposited = self.address_2deposit.get(user);
    let price = calls::latest_answer_call(self.oracle.get())?;
    let value = deposited.checked_mul(U256::from_str(&price.to_string()).unwrap()
        .checked_mul(U256::from(1e10 as u64))
        .ok_or(ManagerErrors::CouldNotMul(CouldNotMul {}))?)
    .ok_or(ManagerErrors::CouldNotMul(CouldNotMul {}))?;
    let value_scaled = value.checked_div(U256::from(1e18 as u64)).ok_or(ManagerErrors::CouldNotDiv(CouldNotDiv {}))?;
   Ok(value_scaled.checked_div(minted).ok_or(ManagerErrors::CouldNotDiv(CouldNotDiv {}))?)
}

I reread his and my code probably 100 times and couldn’t for the life of me see the potential error I was doing. As a last resort, I set up the same type of mock testing for his contract in the remix ide. To my confusion, and relief, his contract behaved the exact same way like mine:

and:

Which was enough for me to conclude my contract working as intended, at least mapping the original.

Final Words

Verdict time! My thoughts on Arbitrum Stylus is that it feels like a newborn fawn finding its legs. I am very excited about how it can enhance the EVM space, and I can really see the vision, even though as of now it’s still rough around the edges. I’m looking forward to experimenting with stylus more on this blog, and push the boundaries further, anything from trying out other WASM compatible languages, to making a more fully fledged project where Solidity and Rust both are utilized. I am also excited to see the tooling come to a more mature state. Until then, I encourage everyone reading this to try out building a small project using Stylus and please reach out to me and/or Alex and share your experiences while doing so 😎

Please follow me on x and/or on GitHub!

The repository lives here: https://github.com/jacksmithinsulander/microstable-stylus

Stylus Saturdays is brought to you by… Arbitrum! 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

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

BEFORE WE CONTINUE FURTHER, MAKE SURE TO UPGRADE YOUR CONTRACTS TO FIX A BUG INVOLVING EXTERNAL CALLS AND REENTRANCY! All versions of the Stylus SDK prior to 0.8.4 are vulnerable. INFORMATION BELOW with the header “Upgrade Info”.

Welcome back everyone!

We’ve had a super eventful month so far, taking part in organising a hackathon alongside the Arbitrum DAO for a track titled the Gas Redux Challenge. For the site, Superposition graciously sponsored several keyboards, and the Arbitrum Foundation provided a prize pool to the tune of $5,400!

PS: we’ll wrap up the Chainlink example, maybe even on the very near horizon ;) featuring an addition from a guest contributor.

I’m pleased to share we had a number of participants and submitters (a total of more than six highly skilled devs at least that I’m aware of) from different backgrounds, and we were were able to take a contract initially costing around 600,000, all the way down to 25,000 with more than 12 submissions.

Over a bloody (seriously intense) two days of the submitters leapfrogging off each other constantly (a dev would submit a solution alongside source code, a dev would see what they did then optimise it further), a few devs were able to identify a problem with the proving algorithm and figure out ways to eliminate several unnecessary checks bringing the contract down to its lowest amount. In the end, a solution made its way into becoming the winning submission.

To remind everyone, Superposition (my team outside this newsletter) manufactured five custom mechanical keyboards based on the Le Chiffre design with custom cases featuring the Superposition branding:

It was a great pleasure to introduce so many different people to Stylus. Congratulations to Levin for coming in first place here! Definitely a phenomenal dev.

Throughout the competition, I was blown away by the quality of the talent in Romania and some of the nearby attending countries. The people that attended the hackathon are some of the most humble and talented developers I’ve ever seen.

Special shoutout to Tolga from The Wizard on Stylus for collaborating closely with me to get a reference contract supplied as a template:

We had so many solutions to the Arbitrum Stylus hackathon track and the Gas Redux Competition through his platform! Be sure to follow Tolga and The Wizard here. The Wizard is a really great platform to quickly develop and deploy smart contracts. He’s been so kind to support Superposition Testnet as an option for deployment via his platform. As a team, we’re looking forward to deepening our connection to him and his team. It’s a super fantastic product!

I’m super thankful to Srinjoy from Offchain Labs for introducing us to Paulo Fonseca, DAO Delegate, who was so supportive in facilitating this as a hackathon track, and for being a great and supportive character. We worked closely with him to define the scope of the competition, and he was directly responsible for organising large parts of the entire conference in general. He also gave a banger talk! We’re thankful he saw fit alongside the eponymous Chris (also from Offchain Labs, also thankful as he was our partner in crime at this event) to allocate a part of the prize pool for our competition.

Side note: Paulo and his cofounder Andrei launched Proposals.app on Friday of the conference!

I hope you check it out. I’ll be using it to stay abreast of every development in the Arbitrum DAO space.

If you’re so inclined, you can learn more about the contest problem at https://github.com/af-afk/ethbucharest.bayge.xyz! You can see a reference implementation at https://github.com/af-afk/example.ethbucharest.bayge.xyz!

To recap: Arbitrum Stylus is a new technology for writing your Arbitrum smart contracts in Rust, C, Zig, AssemblyScript, and Go! With Stylus, you have full 1-to-1 composability with the EVM, with your code being converted to WASM and run on the node as native code. That means no distinction from a caller’s perspective of a Stylus and Solidity contract, but with Stylus, things are way cheaper and way more expressive with the type of code that can be implemented.

Upgrade info

As you may have read, Stylus SDK versions 0.8.3 and below are affected by a bug involving reentrancy and improper cache flushing:

1. Cache Invalidation: The cache was not being invalidated correctly if storage types were read before making an external call that modified those storage cells. Subsequent reads would not reflect the updated storage values, returning stale data from before the external call.

2. Reentrancy: Occurs when using Solidity and Stylus contracts together. There is a possibility of reentrancy not being properly detected if a combination of reentrant and non-reentrant contracts are used and call into each other. To mitigate the risks of this, we have changed the behavior of external calls from stylus to always flush its cache. The msg::reentrant() hostio also may be unreliable, so relying on it for safety should be avoided.

It’s very important you upgrade as soon as you can! Besides this, the newest version of the SDK has some great tools to facilitate testing and more.

Updates to the Stylus ecosystem

Wow, have we had several updates to the ecosystem that should be mentioned at length. Here are a few I’m super excited about, and what they’re up to based on their updates:

1. OpenZeppelin have added to their wizard a quick contract builder for ERC20, ERC721, and ERC1155! Cool! You can check it out here.

2. Thirdweb are racing to support Stylus with their tools. You can quickly build and debug your contracts using their CLI and SDK!

3. Syndicate MintVM is a virtual machine specifically intended for ERC20, ERC721, and ERC1155 development and minting. Syndicate are building some pretty cool rollup as a smart contract tools, I had the pleasure of meeting one of their team members once.

4. Grug Capital and crew are working on Sylow, a Rust library for working with elliptic curve cryptography. They’re expanding this to the Rust Stylus ecosystem. In their last update, they stripped the standard library from their crate and reimplemented Vec (instead of using core I gather?).

5. CodeTracer are adopting their Noir time travelling debugger to Stylus! This is a video they posted in the past showing off what they’re up to.

6. Nuffle Labs are extending EigenLayer restaking to Arbitrum, reimplementing the technology Nuffle using Stylus.

7. Ember are working on LP optimisation using contracts implemented with Stylus!

8. Duoro Labs are working on a Move to Stylus compiler! Move is the programming language powering dApps deployed for Sui and Aptos (and Movement, lol). Move is notable in its concept of ownership of assets for access, which is good in that in the Sui/Aptos (Move chain) context, it translates very nicely to UTXO-based parallelism for transactions. In their last update, they identified a technical approach to begin transpiling Move bytecode. Their plan is to translate directly to WASM. This approach sounds good to this author! What I’m curious about is whether they intend to translate literally the ownership model using perhaps some gadget contracts (or something?), or to replace it with internal contract accounting. This wasn’t obvious to me reading the update post, but this team is obviously super technically competent so whatever they’ll decide on (or perhaps my view of this problem is mistaken) will be fine.

9. Pyth are translating their oracle code to Stylus, alongside a SDK that empowers developers to use Pyth with Stylus simply and seamlessly.

10. Trail of Bits is working to build a compiler for Solang to Stylus. Trail of Bits is obviously a leader in the open source space, so this is very exciting!

11. Superposition are working on using Stylus to facilitate AI agents for their 9lives prediction market. They’re in the middle of a pivot to use a AMM model alongside their existing Dynamic Pari-Mutuel Market (DPM) model, which struggled with adoption due to the model shining mainly when supported with an orderbook. They worked with an auditor to curate a specific implementation which is currently in internal testing! The upcoming feature release also earns you yield from a lending protocol while you participate in a market, and it also has free creation of markets, alongside selling.

12. Runtime Verification are making inroads with their Stylus Fuzzer.

13. Cobuilders have concluded their first milestone! They’re building a GUI for the Stylus cache manager, which is an optional space that can be bid into to be cached on the Arbitrum nodes, resulting in a cheaper gas profile.

Expressions of interest in a Formal Verification Engine

Trebien and Certora are talking to teams to gauge interest in a formal verification tool for Stylus! If you’re interested, I encourage you to reach out via Telegram:

https://t.me/trebienxyz

Trying (and failing) to use Walnut Debugger and the tracing CLI features

Those of us working with Stylus know that at times, debugging can be a challenge. Walnut have released something pretty cool, an in-depth trace of interactions with contracts that lets you you quickly diagnose what went wrong with something that you wrote if you want. It’s a fork of some LLVM code (I gather) that you could use to inspect your contract’s interaction with calldata using their take on LLDB.

The following is a tutorial on how to get up and running with this tool. In the process of writing this, I actually failed to get this working. I had to spend some time with their engineer understanding things, and wasn’t able to find a way through. But this should be useful for developers working with Stylus and toolchain moments that need diagnosis, so I’ll leave this up for posterity reasons, and to understand my thought process. For a large part of this tutorial I suspect I was mistaken about key things, but time will tell as the Walnut team adds Linux support. Their tool is still relatively early days, but they report it works quite well on MacOS.

Installation and setup

Step one, let’s install some tools to get going. I’m on Debian, so I’ll follow the following process:

git clone https://github.com/walnuthq/walnut-dbg

First, I’ll clone the repo. This contains some instructions for MacOS and installation, so I did some work on my own to get this done. I installed the following dependencies (again, this is for Debian, so instructions may vary):

sudo apt-get install lldb-dev cmake ninja-build llvm-19-dev

After cloning, I changed the location of the installation to my home directory. I did so by using sed to edit CMakeLists.txt. This is still pretty new software, so the best of my (limited) understanding, we’re not able to change the installation directory:

cd walnut-dbg
sed -i 's@/usr/local@$HOME/.local@g' ../CMakeLists.txt

Make sure that you have ~/.local/bin in your PATH, and existing! A reminder that you can always create the directory with mkdir -p $HOME/.local/bin. There may be other directories needed, but to my (already having this location available) perspective, this is all that’s needed.

Following this, I created a new terminal and:

apt source llvm-19

This installed the source directory for LLVM. The tool installed it to /home/user/llvm-toolchain-19-19.1.7 for me at the time.

Following this, I did the following inside the repository we downloaded in the existing terminal emulator:

mkdir build
cd build

cmake -GNinja .. \
  -DLLVM_TABLEGEN_EXE=/usr/lib/llvm-19/bin/llvm-tblgen \
  -DLLVM_DIR=/usr/lib/llvm-19/lib/cmake/llvm \
  -DLLVM_SRC=/home/user/llvm-toolchain-19-19.1.7 \
  -DCMAKE_CXX_FLAGS='-Wno-deprecated-declarations' \
  -DLLVM_LIB_PATH=/usr/lib/llvm-19/lib/libLLVM.so

ninja

The flags to cmake were needed to tell the toolchain where my files are. This is based on the README they provide, but suitable for Debian. Ninja followed the generated installation script. I’ve noticed that if you don’t provide these flags in their entirety, you will encounter a runtime issue once it begins the mostly LLVM-derived code.

Following this, at the root of the directory, the following files were added:

build/bin
build/bin/walnut-dbg

So inside the build directory, we can invoke walnut-dbg. We can take this a step further by installing it like so:

./bin/walnut-dbg

Which drops us into an interactive prompt for debugging a file. But we want to test this on something of our own.

Using OpenZeppelin Wizard to test Walnut

Following our installation, we need something to test this on! We can do so by using OpenZeppelin’s Wizard tool:

Indeed, this lets us quickly create a ERC20 to play with.

Let’s create a quick repo to use the OpenZeppelin Wizard with:

cargo stylus new openzeppelin-wizard-test

Let’s make some changes to be compatible with the format that I prefer (no std explicitly across the board). This is due to codesize reasons, and I like to overload the panic handler to make it more informative:

Changing Cargo.toml:

alloy-primitives = { version = "=0.8.20", default-features = false, features = ["native-keccak"] }
alloy-sol-types = { version = "=0.8.20", default-features = false }

Now for some changes to Cargo.toml that I don’t just want, we need. Let’s add it to our dependencies:

openzeppelin-stylus = "=0.2.0-alpha.4"

Which should result in your Cargo.toml looking like this:

Following this, we must replace the content of src/lib.rs with the contents of OpenZeppelin’s suggested ERC20:

As a reminder, we just saw this in the page they have.

Now, inside our newly created contract repository, we can build this with cargo build --target wasm32-unknown-unknown, which will build a debug executable for us of the contract.

… At which point I hit a issue with OpenZeppelin’s SDK not building. It seems at some point, the deferencing pattern they were using became impossible to use with the SDK. Maybe a downgraded version would make this possible. I switched the approach to use their newest version of the SDK. Unfortunately, they’re only supporting 0.8.3, not 0.8.4, which you may remember as being vulnerable to a newly discovered issue!

So for the purposes of this article, we will be proceeding with Stylus SDK 0.8.3. To use the latest cutting edge before release to Cargo version of the OpenZeppelin contracts, you can amend your Cargo to be like so:

[dependencies.openzeppelin-stylus]
version = "=0.2.0-alpha.5"
git = "https://github.com/OpenZeppelin/rust-contracts-stylus"
branch = "build/v0.2.0-alpha.5"

And unfortunately downgrade the SDK. I want to emphasise that we should do this only for our testing purposes, and we should wait until OpenZeppelin upgrade their contracts before using this in a real-world scenario. This is what our Cargo.toml looks like now:

Following this, by repeating cargo build --target wasm32-unknown-unknown, success! We can see that the file target/wasm32-unknown-unknown/debug/stylus_hello_world.wasm. We will not be deploying this contract, we will simply use this this to run the Walnut debugger on its own now!

Let’s try to attach our debugger to our debug mode contract:

walnut-dbg ./target/wasm32-unknown-unknown/debug/deps/stylus_hello_world.wasm
(walnut-dbg) target create "./target/wasm32-unknown-unknown/debug/deps/stylus_hello_world.wasm"
Current executable set to '/home/user/Downloads/openzeppelin-wizard-test/target/wasm32-unknown-unknown/debug/deps/stylus_hello_world.wasm' (wasm32).
(walnut-dbg) b user_entrypoint

This creates a breakpoint at the user_entrypoint function, which is what will be called the moment your contract receives anyone calling it. I don’t know how to orchestrate this on its own. From here, we need another tool! We need something that can run this program for us until we understand things better. We need… https://github.com/walnuthq/cargo-stylus-walnut.

This is another tool by the same team that has some features builtin to do things like break down a transaction that took place on a network somewhere. Installing it is relatively straight forward (assuming you have all the Stylus-related tools at your disposal already):

git clone https://github.com/walnuthq/cargo-stylus-walnut
cd cargo-stylus-walnut/main
cargo install --path . --debug

I installed this in debug mode since I’m lazy. This will install the executable walnutdbg, which we can use to get deep insights into our contract’s execution. It mirrors Cargo Stylus, so in their documentation they have some extra steps to replace the executable. For our cases, we’ll leave it alone here. Note that unless you replace cargo-stylus per their instructions, you must invoke their executable like walnutdbg walnutdbg to deceive it into thinking its being called like its would-be aliased namesake.

Returning to our example Stylus ERC20 contract, let’s deploy it! We can deploy it to the Superposition Testnet using:

cargo stylus deploy --endpoint https://testnet-rpc.superposition.so --private-key <TESTNET PRIVATE KEY HERE> --no-verify

This will simply deploy your contract to the Superposition Testnet, which you can get funds for at https://faucet.superposition.so. I promise it’s always funded and ready for you to use. Alternatively, you could deploy this anywhere you want, including Arbitrum Sepolia.

It’ll spit out some info. For me, it deployed to 0x62a87650ba04f77545cfa29ab5a516649bfc3f55. Great! Let’s try to call it:

cast call --rpc-url https://testnet-rpc.superposition.so 0x62a87650ba04f77545cfa29ab5a516649bfc3f55 'balanceOf(address)(uint256)' 0xfeb6034fc7df27df18a3a6bad5fb94c0d3dcb6d5

0xfeb6034fc7df27df18a3a6bad5fb94c0d3dcb6d5 is a dev account that just deployed this contract. We can see that unfortunately our balance is ZERO based on this call. As a reminder, you can get the cast tools from Foundry. There’s a helpful installer there titled foundryup that should set you up quickly.

But what if things were different? Using Walnut, we could find out why. Let’s commit our transaction questioning our balance to the chain by signing it and submitting it (a redundant action under normal circumstances):

cast send --private-key <private key here> --rpc-url https://testnet-rpc.superposition.so 0x62a87650ba04f77545cfa29ab5a516649bfc3f55 'balanceOf(address)(uint256)' 0xfeb6034fc7df27df18a3a6bad5fb94c0d3dcb6d5

This created the transaction 0xe249739d9e0705064630bc7261a3aaeb44fa0d001c2bbd7575ac809764254b4b. Cool! Now we can simulate it with Walnut:

cargo-walnutdbg walnutdbg usertrace --tx 0xe249739d9e0705064630bc7261a3aaeb44fa0d001c2bbd7575ac809764254b4b --endpoint https://testnet-rpc.superposition.so

I was surprised to see it rebuild my contract in debug mode. Following this, I had another issue! It was not able to find my walnut-dbg executable, despite it being in my PATH! It seems that for it to be found, it must be renamed to rust-walnut-dbg. I created a stub script:

cat $HOME/.bin/rust-walnut-dbg <<EOF
#!/bin/sh

walnut-dbg $@
EOF
chmod +x $HOME/.bin/rust-walnut-dbg

This creates a file in ~/.bin, which I assume is available to you. With this, I was able to get past this block. Following this, I was unable to proceed with the program failing to find my contract! This was due to the program making assumptions about pretty-print-trace being accessible at /usr/local/bin/pretty-print-trace.

I took the pretty-print-trace.py program, which is located in walnut-dbg, and symlinked it to my user directory like so:

ln -s $(pwd)/scripts/pretty_trace.py $HOME/.bin/pretty-print-trace

I then adjusted the source code to not explicitly make assumptions about the location of this program. Hopefully by the time you read this, my patch has been accepted to make this change to the repo itself. At this point, I had another frustration to our plans!

The program expects the location /tmp/lldb_function_trace.json. I tweaked the source a little to uncover this expectation. It turns out that the debugger was not running correctly, and was not propagating up to a point where it was visible for me. Thankfully, at this point, Walnut themselves were sharing me advice on having things running.

It seems that even under normal circumstances (using the default Cargo Stylus replay subcommand), we’re missing a symbol, read_return_data.

Djordje from the Walnut team tells me this is due to a bug in upstream tools. I brought out nm and started to look at any missing symbols in the native binary, which is located as ./target/x86_64-unknown-linux-gnu/debug/libstylus_hello_world.so (this is the native compiled library). I noticed that the toolchain we’re using with Walnut interrogates Rust’s rlib format, but I started with the so to understand things. Then I stubbed out every function that’s missing. Success with the builtin tools!

So after succeeding with cargo replay, I went ahead with trying again to no avail with Cargo Walnutdbg:

% cargo-walnutdbg usertrace usertrace --tx 0xe249739d9e0705064630bc7261a3aaeb44fa0d001c2bbd7575ac809764254b4b --endpoint https://testnet-rpc.superposition.so  --enable-walnutdbg-output
warning: unused import: `IErc20`
 --> src/lib.rs:9:48
  |
9 | use openzeppelin_stylus::token::erc20::{Erc20, IErc20};
  |                                                ^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `stylus-hello-world` (lib) generated 1 warning (run `cargo fix --lib -p stylus-hello-world` to apply 1 suggestion)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.19s
(walnut-dbg) target create "user_entrypoint"
error: 'user_entrypoint' does not exist
(walnut-dbg)

Unfortunately, I still had issues! Noting that it compiled the rlib if it didn’t see it made already, I wondered what I could do to ensure that the symbol user_entrypoint is being made available to the program.

I used strace to look at which file was being invoked, then I started to question it using cargo-nm:

% cargo nm | grep user_entrypoint
(nothing here)

We can see from this table that the function we want, user_entrypoint, is not being exported. Adding to the credibility of my nuisance is that the Walnut team hadn’t previously encountered this (I’m presuming), and that their tool is explicitly for Mac users currently, and as a Linux user, I’m likely using a different configuration for this part of the toolchain. I’m sure some compiler engineer is curling their nose reading this.

I tried to explicitly export the function by making the compiler think it’s in use:

#[used]
#[no_mangle]
static KEEP_USER_ENTRY: extern "C" fn(usize)->usize = user_entrypoint;

Unfortunately that didn’t matter. At this point, I started to supply RUSTFLAGS special arguments for the build configuration. I added:

[target.x86_64-unknown-linux-gnu]
rustflags = [
    "-C","link-arg=-Wl,--export-dynamic",
    "-C","link-arg=-Wl,--allow-shlib-undefined",
]

To .cargo.config.toml, which funnily enough, contained similar flags for MacOS already existing. This exports our symbols in a dynamic environment (we’re gunning to export user_entrypoint) and lets the environment define certain symbols we need to emulate the EVM (collect*, read_return_args, etc) by allowing it to not be there during linking. In doing this though, I give up the ability to build and run native executables without branching for main-created code to link it all in. I could configure build.rs to only do this on the creation of the library however, to still run my tests.

Still no success. At this point, I explicitly disabled the dead code elimination:

[target.x86_64-unknown-linux-gnu]
rustflags = [
    "-C", "link-arg=-Wl,--export-dynamic",
    "-C", "link-arg=-Wl,--allow-shlib-undefined",
    "-C", "link-dead-code"
]

That didn’t seem to change anything. Chatting with the generated code, we can indeed see that user_entrypoint is indeed present:

nm ./target/x86_64-unknown-linux-gnu/debug/libstylus_hello_world.rlib | grep user_entrypoint

So it seems that LLDB (which this code is based on) is having issues finding my symbol with the stream of operations we give it when we call it. When cargo-walnutdbg does its thing, it calls rust-walnut-dbg with these arguments:

rust-walnut-dbg -o b user_entrypoint -o r -o "calltrace start '^(stylus_hello_world)::'" -o c -o -o q -- cargo-walnutdbg usertrace usertrace --tx "0xe249739d9e0705064630bc7261a3aaeb44fa0d001c2bbd7575ac809764254b4b" --endpoint https://testnet-rpc.superposition.so --enabled-walnet-dbg-output --child

This instructs the debugger to:

1. Breakpoint user_entrypoint.

2. Run the program cargo-walnutdbg with usertrace and some arguments.

3. Begin running the executable, but breakpointing user_entrypoint.

4. Begin calltracing every function that is preceded by “stylus_hello_world”, presumably everything we define ourselves.

5. Continues through the program.

6. Then exits.

I spent some more time on this, and deleted some content I’d written up for this blog that reflected a preconception I had at the time about the chain of invocations. At this point, I felt the need to cut my losses on this article. I’ll revisit this at a future date, and leave this up for posterity so people can follow some of the techniques you might deploy to reproduce what’s happening with a program like this.

What did we learn from this?

Some areas of the toolchain are being worked on and seeing improvement. Like any relatively new technology, building things can be a complex task, and to Walnut (and the Stylus team’s) credit, these features are still in development. I even had to build my own EVM-related functions during this program’s life to have the default CLI work with them properly. Users of 0.8.3 would be familiar with this experience, you had to define native_keccak256 yourself, just like every version pre 0.8.0.

The Walnut team are working hard! You can learn more about their product roadmap at this link. I’m super excited about this one! I’ve had the pleasure of speaking with Djordje at length (and many thanks for holding my hand through some questions about their stack), and though their tool is MacOS specific for now, I can tell once it’s more compatible with Linux, that it’ll be super useful for developers to get that Tenderly-like experience in their command line. As a religious Acme user (as many of you know), it’s important for me not to break my flow state and leave my development environment.

As soon as I have another opportunity, we’ll be revisiting this one! Until then, we’ll feature another team building with Stylus next time.

I had the pleasure of meeting Ryan while abroad in Romania. We had a great chat and we drove go-karts around Buchraest together! Ryan is a great guy, and I’m impressed by him, his team, and what he’s building. He was even kind enough to share some ideas for 9lives (as anyone would know who’s close to the team) that we’ve been working on for some time.

Interview with Ryan from Usher Labs

Who are you, and what do you do?

Hello, my name is Ryan. I'm the Founder and director at Usher Labs.

I mostly lead technical solutions architecture, and business development. I also review code. I come from a payments and fintech background, having developed code and managed developer resources for BNPL companies in Australia. Web3 and cryptocurrencies have always interested - whether for store of value, sovereign capital management, fast CBPs, or access to novel financial products.

I began developing Smart Contracts, specifically an NFT project, as a hobby project. This turned into the journey that is Usher Labs. Usher Labs provides B2B data security infrastructure and services tailored for Web3 projects, with a focus on zkTLS-driven verifiable data pipelines.

In addition to supporting businesses like Rooch Network, and Truflation, Usher Labs is extending its zkTLS solution to power a novel liquidity platform: Fiet Protocol. Fiet amplifies capital efficiency by enabling intents for off-chain liquidity to securely supply DeFi markets. This means earning crypto yield on fiat in your bank account, borrowing against your reserves, and much more.

What web3 ecosystems have you worked in?

At Usher Labs, we're building across a various chains and technologies to adopt their core value propositions.

Currently, we develop on the Internet Computer for replicated compute and succinct proof of compute. IC supports our zkTLS-driven verifiable data pipelines technology.

Fiet Protocol is a cross-chain app developed on Stylus. Arbitrum is the primary chain. IC is involved for ingesting real-world data for Fiet.

Other chains may be integrated in a hub-spoke model to facilitate integration with various DeFi protocols, and ecosystems. I submit transactions to Arbitrum and have had good experience, and also Stylus merges access to liquidity with complex applications which makes it a good fit.

What are your impressions of working with Stylus, good and bad?

Development has been quite smooth. It's new tech, so supporting libraries are nascent, specifically in testing (unit + integration tests).

What software do you use?

Cursor for IDE, Notion for Docs, Todoist for TODOs, Linear for team issues.

What hardware do you use?

MacOS for Personal and Linux/Ubuntu on the server.

How can we get in touch with you?

Follow the team on X / Twitter @usher_web3, send me a DM on X @ryan_soury, and join us on Discord https://go.usher.so/discord - I'm available.

What’s a piece of advice you’d give someone new to web3?

You're on your own with crypto, get secure. Learn about phishing scams, do not trust any random messages, and protect your keys and crypto signatures.

Stylus Saturdays is brought to you by… Arbitrum! 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

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!

Hello again! I’m excited to share in this update details of the Gas Redux Challenge at ETH Bucharest, and to feature Hamza from Enclave/Gnosis Guild. I’m also excited to share details of Superposition Passport, an on-chain solving dApp basis built using custom calldata with compression for ed25519 signatures and calldata. We’ll recap the Chainlink price feed example next time.

To recap: Stylus Saturdays is a (mostly) biweekly newsletter examining the Arbitrum Stylus ecosystem. Stylus is a WASM frontend to the EVM stack available on Arbitrum. Write your contracts in virtually any programming language, and deploy them with full composability with Solidity and Vyper smart contracts.

Introducing Bucharest PoW

In the final stage of the Stylus Saturdays Gas Redux ETH Bucharest challenge, contestants must submit gas efficient solutions for Bucharest PoW puzzles. Bucharest Proof of Work (PoW) is type of Proof of Work algorithm invented for our gas competition.

Refreshing everyone: what’s Proof of Work? Proof of Work in the traditional sense with Bitcoin, is the process of taking the hash of the block header (the combined transactions with the fee receiving address and more set), then hashing with a randomly chosen nonce, and repeating this process until discovering the amount of zeroes in the hash string for the difficulty level. This type of algorithm is known as Hashcash.

There are other Proof of Work algorithms, some “memory latency bound” like Cuckoo Cycle Proof of Work, which is used in the blockchains Grin and Mimblewimble. This Proof of Work algorithm is limited by memory latency, since it’s solution is dependent on traversing large sparse blocks of memory for finding a graph of a specific combination.

Cuckoo Cycle work is the process of taking the block header hash, then combining it with a nonce (a number) which is sequentially chosen, and using a hashing function called a keyed hashing function. From the results of the keyed hash function, a pair of edges are created in a bipartite graph. This algorithm repeats itself, until a cycle in the graph is found between the nonces given of a specific length chosen for the difficulty. This type of algorithm is possible to parallelise, but not at the cost of contention, which causes memory latency to be the main bottleneck.

Keyed hash functions are a type of hash function where instead of taking a single argument then taking a preimage (like SHA256 or Keccak256/SHA3), instead a second argument is supplied with a randomly chosen seed. The digest the keyed hashing function generates is instead created with the seed and the hashing argument. An example of this in the Cuckoo Cycle context is Siphash. Imagine that instead of database hashing in the traditional sense (having a project wide “salt”), each individual row has a seed, which is the argument to the hashing function. Siphash performs better for smaller arguments, hence its usecase. This is useful in a hashtable context, imagining that a routing table is built this way, and an attacker could try to abuse the hashing function to get packets routed the wrong way.

Cuckoo Cycle hashing is unique in the broader context for a few reasons: the main being the lack of substantial environmental impact like Hashcash. With SHA256 repeated hashing, CPUs run hot working hard to find the solution, and there is an incentive for large scale mining operations to spin up with a substantial energy impact to maximise the parallelism for solutions and to design better ASICs. Cuckoo Cycles are better for the environment by equalising the efficient opportunities for the problem. It’s not possible to spin up a superpowered dirty energy consuming farm that mines Cuckoo Cycles in its traditional form, this is due to memory latency being largely impossible to optimise for at scale, thanks to restrictions of the speed of light. In networking, throughput isn’t getting better. Our CAPACITY is, which might make people think that speed is, but this is due to the opportunities of a good connection being made more available. We’re not pushing this better thanks to problems involving the speed of light and the density of transistors, and Moore’s Law hasn’t been accurate for some time.

This isn’t to say that ASICs can’t be used with Cuckoo Cycles. Any kind of software solution could be lifted to an optimal hardware form, and with the future of LLVM IR fabbing bespoke chips for algorithms staring down the barrel at us, this is a future we should simply acknowledge and adapt to, as in our problem space it simply distorts the economics if we externalise the social impact.

You know who benefits from memory latency optimsations like a server cluster? Laptop workstations and phones. Eagle eyed readers of our silly little newsletter would be aware that Apple’s CPUs are lower on the clock rate, but still perform excellently from a user’s perspective. This is due to a mixture of optimisations in compilers and interpreters, and you might even notice that ARM itself even has a operation that Javascript interpreters use (among other things). Software developers push the hardware by tightening the distance between software and hardware, as more complex instructions do micro parallelism on the chip to solve problems faster, including the famous speculative execution bug of a few years ago (SPECTRE).

So with Cuckoo Cycle hashing, a small phone could go toe to toe with a ASIC farm, unlike a Hashcash “dirty energy” farm operating out of Mongolia hacking away with a large-scale Hydraulic energy plant. Until we solve foundational physics problems, ASICs are not a genre-defining class with this type of algorithm.

In Bucharest PoW, like Cuckoo Cycles, discoverers discover a range of nonce numbers to combine with a block header to prove they discovered the solution to produce the next block. Unlike Cuckoo Cycles, nonces are used to derive a board position for a large chess board, and a piece type. The nonce is increased until the first check is discovered of the latest placed king.

A proving function then retrospectively examines the nonces until it finds the earliest nonce used to place a piece on the board that affected the king’s checkmate. Like the Cuckoo Cycle, where a proof is simply the lowest and highest nonce that was used to construct the graph, the lowest nonce is chosen for the first piece that placed the king into check, and the highest piece. This is then transmitted as proof of finding the solution.

In our game at ETH Bucharest, submitters strive to find the most gas efficient solution for ETH Bucharest Proof of Work. There should be plenty of opportunities for optimisations with board representation, and the proving function! A submitter registers their contract with the scoring contract, which then causes an off-chain worker to randomly create several hashes, which it then simulates the contract with at the node. The median gas performance is chosen and then the transaction is committed on-chain.

Registrations to the scoring contract must be submitted with a link to a Git repository, and the hash of the revision of the repo. The repository must be made available to other participants. The code will be inspected by the judging team to disqualify bad participants. The most optimal solution at the time receives “tenancy” of the yield generated on a curve:

So, your winning solution will earn you a certain amount of revenue per second, which someone could potentially take from you by looking at your submission, identifying an optimisation, then resubmitting! The contract won’t accept revisions except those that are 5% more effective than the past submission. The submitter with the most points at the end of the game is the winner!

One of Stylus’ strengths lies in the large pages of memory you could be allocating and using relatively cheaply. I’m excited to see how people perform with this problem!

Introducing Superposition Passport

Superposition Passport is Superposition’s smart account for on-chain solving of off-chain matched trades with Longtail Pro. Superposition Passport is unique in that it’s a fully non-custodial matching and solving engine: unlike competing DEXes where amounts must be on-ramped or deposited to be used, Superposition Passport enables traders to simply sign an approval message to a smart account, which has its trades signed in the browser using ed25519 blobs generated with WebCrypto. From a user’s perspective, they simply sign once, and they can trade without any popups or notifications just like a CEX, but their money never left their wallet.

Superposition Passport is also unique in its calldata and on-chain compression: Borsh is leveraged with generated deserialisation code. Borsh is notable for its use in Solana and NEAR as the default encoding format. Borsh is a low overhead encoding format, and if used with little endian encoded blobs, massively reduces the visible size of calldata. EVM-compatible nodes price calldata with discounts for recurring zeroes, which muddles the optimisation advantages of using custom encoding formats. Owing to cheaper computation gas with Stylus (this is titled ink), we can decompress calldata generated with LZSS, a cheap encoding scheme however, and we can benefit from some gas savings. This is useful if we must aggregate signatures (which we do). Superposition Passport also facilitates backstopping liquidity with smart contracts, perhaps useful for stubbing out missing liquidity with a AMM. This compression approach is useful for optimising the calldata that includes the request leaving to the contract.

The most optimal EVM compression is often simply interpreting a bespoke stack machine with a custom calldata package. With a Borsh-heavy approach, we could do something similar, by having a recursive datatype that’s matched easily.

This code uses lzss to decompress a Borsh-encoded structure (Op below), then it matches on the enumerator type that was used. Following this, it does dispatch to the function we want. The storage type used implements storage fully. Following this, the contract returns the error type if things happened correctly. Despite the matching, we retain some EVM composability by having a error type we created using Solidity, which is encoded to something Ethereum tooling would know how to work with.

It’s very early days here with this contract, but we’re excited to share it with the community MIT licensed (like usual), and to integrate it directly with 9lives and the upcoming Superposition Pro release.

Interview with Hamza from Enclave/Gnosis Guild

I’m super lucky to have had the chance to feature a seasoned cryptographer like Hamza!

Who are you, and what do you do?

I'm Hamza Khalid, an Applied Cryptographer and Protocol Engineer at Gnosis Guild, the initial development team building Enclave. I got into web3 pretty early on when I used to lurk around Bitcoin forums since I was 14. I used to offer web dev services in exchange for bitcoin at the time, as you can imagine, since as a 14-year-old I did not have access to a bank account, so bitcoin was a game-changer for me. That early experience not only introduced me to the power of decentralized money but also set me on the path toward exploring cryptography, distributed systems, and the broader implications of web3.

Now I work on Enclave, an open-source protocol that makes secure, encrypted computation possible using fully homomorphic encryption (FHE), zero-knowledge proofs (ZKPs), and distributed threshold cryptography (DTC). It’s a mouthful, but basically, we’re making it possible to compute on private data without ever decrypting it, leveraging Encrypted Execution Environments (E3s) for verifiable, privacy-preserving computation.

I've been all over the tech map, from full-stack web development/devops/cybersecurity to cryptography, from AI to blockchain development across multiple ecosystems. I've built cross-chain bridges, NFT platforms, written ZKP circuits for identity verification, and developed federated learning ML models with FHE on the blockchain.

What web3 ecosystems have you worked in?

Before working at Gnosis Guild, I was a web3 lead at permission.io and the lead blockchain developer at 0xAuth (now David.inc). I've worked across a bunch of different chains. I started with Solana and got really into Rust-based smart contracts there. After that, I picked up Ethereum, which honestly took me a while to get used to because my brain was so wired for how Solana worked.

Since then, I've worked with Polygon, Arbitrum, Base, and even some private blockchains. I've used Soroban (another Rust-based smart contract framework) to write smart contracts for the Stellar blockchain.

Working across these platforms has given me a well-rounded perspective on the strengths and trade-offs of each ecosystem, and how they can complement each other in the broader web3 landscape.

What are your impressions of working with Stylus?

At Gnosis Guild, we are working on integrating Stylus as a compute provider for Enclave. A compute provider is essentially a service that takes encrypted or raw input data, performs specific computations securely, and outputs verifiable results that can be trusted on-chain. Currently, our process relies on zkVMs; specifically, we perform all the heavy computations off-chain inside a zero-knowledge virtual machine (like Risc0). This method involves generating a zk proof that attests to the correctness of the computation before it’s finally verified on-chain.

Working with zkVMs has given us strong security guarantees, ensuring that even though computations are done off-chain, they are still verified rigorously on-chain. However, this approach comes with additional complexity and latency due to the extra steps required to generate and verify zk proofs, and they are pretty slow as well.

By contrast, Stylus introduces an on‑chain compute provider that operates using a WASM environment. This allows us to write our smart contracts in Rust while retaining full EVM interoperability. With Stylus, computations are executed directly on-chain, meaning that the verification is inherent to the consensus mechanism, simplifying the architecture and reducing overhead. So Stylus will not only boost performance and lower gas costs but also streamline development by eliminating the need for a separate zk proof step.

Overall, my impressions of working with Stylus are very positive. Having tried a bunch of smart contract languages in Rust, Stylus has been the most fun and easiest to work with by far.

My experience with Solana and Stellar smart contracts was quite different since they're not EVM chains; the whole development flow feels different. But with Stylus, it was really easy to get started immediately.

What software do you use?

I keep it really simple with Windows + WSL Ubuntu + VSCode/Cursor AI. I've tried setting up Neovim and used it for a bit, but I always end up going back to VSCode. Neovim is awesome, but the time it takes to set things up and fix stuff when it breaks just isn't worth it for me.

I also don't bother with custom Linux distros. I've watched my coworkers struggle with dependencies, updates, and broken kernels, and decided that's not for me. I love customizing things to make them look pretty, but I always end up reverting to plain old Windows for simplicity.

One of my absolute favorite tools on Windows is PowerToys; it lets me stick to my keyboard and avoid using the mousepad as much as possible.

I also play around with a ton of AI tools — Claude, Cursor, ChatGPT, Gemini, different architectures, RAG systems, you name it. I love jailbreaking LLMs and getting them to do stuff they're not supposed to do, probably because I've always been into CTFs and see it as a fun challenge.

What hardware do you use?

My daily driver is an ASUS Strix G17 with 32GB RAM and an RTX 3070TI. It's a "Gaming Laptop," but my main use for it is to train ML models and handle Rust compilations and cryptographic experiments without melting down.

I also experiment a lot with hardware, like Arduino and ESP32 microcontrollers, courtesy of my work in embedded systems programming in Rust.

I’m also into gaming, and I’ve put more hours into Dota 2 than I’d like to admit, though these days, I'm gravitating towards single-player games like Prey, A Plague Tale, and revisiting classics like Max Payne. Multiplayer used to be my thing until I realized I preferred trolling teammates over actually winning — fun for me, maybe less so for them.

What's a piece of advice you'd give someone new to Web3?

If you’re new, it can feel overwhelming, this is a wide-open, rapidly evolving space. You’re stepping into a frontier where you can build and reimagine systems that traditional web platforms simply can’t support. Ask dumb questions, they’re often the smartest ones. Dive into communities, tinker with protocols, and embrace the cringe PFPs. Don’t be afraid to get your hands dirty; you’ll need to dive deep to uncover where your energy fits best. Experiment a lot, stay curious, stay skeptical, and remember to have fun.

How can we get in touch with you?

I’m always eager to connect with fellow developers, researchers, or anyone interested in the evolving world of web3 and secure computation. You can reach me via:

• Email: me@hmzakhalid

• GitHub: github.com/hmzakhalid

For Enclave, you can follow on*X and subscribe to the blog. For partnerships, business opportunities, and more, join the Enclave Telegram group.

Stylus Saturdays is brought to you by… Arbitrum! 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

Side note: I develop Superposition, a defi-first chain that pays you to use it. You can check our dapps out at https://superposition.so.

Welcome back! To recap: Stylus is a technology to build smart contracts with using WASM on Arbitrum. The code you write is 1-to-1 compatible with the EVM, including calling and storage.

Before we continue, Cyclone Alfred has left 16,000 homes without power, several people injured, and one person dead. Our thoughts are with the community of Brisbane and Queensland who were affected.

I’m excited to announce that at ETH Bucharest, the Arbitrum Foundation is going to be hosting a hackathon! Stylus Saturdays will be hosting a series of challenges similar to Advent of Code in one of the tracks, concluding with a competition to design the most gas efficient Stylus program for a fun problem! Yours truly will be judging and mentoring, so say hi if you’re there and you enjoy the newsletter.

There will be prizes, with the USD prize being provided by the Arbitrum Foundation, and special one-of-a-kind keyboards and (optional) testnet infrastructure sponsored by Superposition! The Wizard on Stylus will graciously be supporting custom templates for the competition.

Visit https://ethbucharest.superposition.so for more. Early days, so we’ll be updating things gradually to have more info.

Recently, Chrisco (@ChrisCo512) of Offchain Labs was able to support Zig with Arbitrum Stylus. His repo lives at https://github.com/chrisco512/wax. He gave a talk on the topic at ETH Denver, which you can watch on X here:

https://x.com/EthereumDenver/status/1895577797416087708

Being able to do this goes to show how relatively easy it is for a developer to add programming languages to Arbitrum, provided there’s a decent WASM compiler backend. Zig is a programming language known for its simplicity and safety, and a huge perk is that the codesize it outputs is way smaller than the Rust equivalent!

This recent post on Lobsters is a good example of how simple Zig can be. This is a allocator implemented in less than 200 lines of code, and I found it simple to understand.

Perhaps your next project will be in Zig?

Continuing from our previous post:

Repo here

Now that we’ve established our storage initial attempt, and our entrypoint function to store the requests, we need to build our first attempt at a function to handle the callback from Chainlink with the VRF word that we use to seed our vending machine interaction. In the post after this, we’ll test all of this more rigorously to ensure it actually works.

Before we continue, in the process of writing this function, I tweaked our storage to add more toplevel storage so we can prune our storage vectors comfortably when NFTs are consumed:

The change is that there is an extra field called nft_ids_to_send, which is simply a vector of ids that can be sent per nft address. Simultaneously, each level also includes a vector of the nft addresses. We’ll be pruning these if we run out of NFTs to distribute during this callback’s life.

The callback function that we need to use with Chainlink has the following user story:

It first (this is not included in the above diagram), takes the USD value of ETH at the time, then normalises it, using Chainlink. This follows a similar process as the previous post’s example with Chainlink (making a call), and you can read more here if you’re so inclined. The code then begins to go through each item in the queue, normalising the ETH amount in the queue item. It compares each minimum ask for the queue items in the queue to the amount asked by the user. After finding the first NFT price point that could be reasonably spent this way, it starts seeking backwards to find a NFT.

For this next part, we implement some testing affordances in the form of the Default trait for our storage:

// Default for testing purposes.
#[cfg(not(target_arch = "wasm32"))]
impl Default for StorageVendingMachine {
    fn default() -> Self {
        use stylus_sdk::testing::vm::TestVM;
        StorageVendingMachine::from(&TestVM::new())
    }
}

This simply sets up the VM for us. In the next post, we’ll be testing everything, and amending our code based on how things go.

We implement our first stab at the callback function Chainlink will use. Chainlink VRF will call a function called rawFulfillRandomWords, and Stylus’s code generator will replace snake case with camel case.

It first checks if the caller is Chainlink, and if it isn’t, it breaks. It’s important we do this to avoid providing users with a vehicle for abuse. Following this, we take the word we requested (the previous lockup function called this for us), and we seed local randomness. We use the ChaCha8 PRNG function for this, which is suitable in that we don’t need a high quality of randomness, and a simple XOR-shift strategy could suffice, but it’s a nice show of what’s achievable using Rust with Stylus (we can use virtually any Rust crate!) in this setting to do this this way.

We do a lookup to get the price of ETH at the time using Chainlink. We do this to get the USD price of ETH. We then begin going through the queue of accumulated requests and processing them.

For each element in the queue, we begin to unpack the word we created earlier as the concatenation of the address and the amount. We calculate the USD amount invested for the user by multiplying the price we got from Chainlink with the amount the user deposited. We do a local helper function to convert the type from a uint96 to a uint256.

We enter a function that helps us do a lookup to find the appropriate NFT to distribute. It does so using a binary search strategy:

We use the core library to do the search. This will search the vector in storage, looking for an instance of a NFT level that costs less than the amount of USD the user was willing to offer for it. It only selects the NFT where the next item in the storage vector is greater than or does not exist for the price point they chose. A flag is provided to only search for NFTs with liquidity, by checking the associated storage of NFTs for the level. The function searches backwards for NFTs that have liquidity this way.

In a normal setting, developers might normalise the price to a system of buckets with special numbers, like a system of sqrt price X96 numbers a la Uniswap. That approach would allow a developer to normalise the price based on a tick, which would enable them to select the price that’s appropriate for the NFT in one go, skipping the complicated series of SLOAD storage lookups. I chose this strategy to show off what’s achievable with Stylus, writing a binary search function over storage is trivial. Perhaps a developer could implement something simple like ERC20Votes of OpenZeppelin fame, which is where this approach would be more suitable.

After we discover the level we want to offer the user, we first check if we owe the user a refund. A refund is taking the fee rebate, which is the fee that was paid by every user, and adding it to the amount of ETH that the user deposited when they went to purchase a NFT.

We use this function internally here:

It might be smart for a developer of a real world application to, instead of using Chainlink and doing this calculation in the callback, have it instead store the words in storage. This way the gas costs are more understandable, since many users could submit in a short amount of time with a small amount of ETH for example, and break the entire system. This applies to the search for the NFT, since fragmentation could be so bad that the entire storage range could be cached. This code will check if the level was found, and if not, refund the user.

After picking the level, we start to pick a NFT. We use the PRNG from before (ChaCha8) to generate a u32, the native word of the wasm environment we’re in, which translates to a usize. We pick the NFT from a multidimensional array of the NFT address and the level we’re at. Once we’ve picked a NFT, we also randomly pick the ID we want to distribute.

At this point we try to send them their NFT. If we can’t (maybe they’re a contract that doesn’t implement the ERC721 callback), we then initiate a refund. Refunding can fail (maybe for similar reasons as before), so we allow that to happen to prevent griefing.

We try to send the user a rebate for the amount they sent us. This function is simple:

We op the consumed ID from the storage vector by doing a “swap and pop”.

We do the same as the ID, but we do this to check if this is the last NFT we distributed from the NFTs at that level. We use the same approach for this! Then we check in that we’ve distributed a NFT using a event.

We finally close things out by logging that we resolved the outstanding request for randomness from Chainlink.

So to recap: this function is a callback for Chainlink that receives a random word using VRF, which it then uses to seed a local random number generator (of the complex kind). It looks up the price of ETH, which it then remembers. It goes through the queue of submitted requests for NFTs, and starts to select the level to distribute the NFTs with. It uses randomness to select each. It then goes to send the user what they won!

In the next post, we’ll be testing this code at length using end to end tests of the online kind, and of the offline kind. We’ll be doing this testing using property and mutation testing. All of the code is in the repo: https://github.com/af-afk/vendingmachine.com

Interview with Tolga from Stylus Wizard

I had the time to catch up with Tolga, the founder of The Wizard on Stylus. I really recommend everyone to check this out! Great platform.

Who are you, and what do you do?

I’m Tolga, a computer engineer based in Ankara, Türkiye. I got into tech during university, doing part-time jobs in web development and internships in software testing, creative solutions, and even early metaverse projects. I discovered Web3 in my final year at university through a side project. What started as a fun experiment quickly turned into a full-time job when my classmate and I decided to go all in. Over the past three years, we’ve built a range of solutions, from Telegram bots to full-fledged products, and worked with some of the biggest blockchain protocols.

One of our favorite projects is Wizard, an online playground for building and testing Rust-based smart contracts on Arbitrum Stylus. The idea came from my struggles trying to set up Stylus locally. The whole process installing Rust, Cargo Stylus, setting up a local node, dealing with RPCs — was way too much hassle just to write a few lines of code. We figured there had to be a better way. That’s how Wizard was born — so developers could try Stylus instantly in their browser with zero setup.

The response from the community has been amazing. In just the first month, Wizard gained a lot of traction, and people love how easy it makes experimenting with Stylus. Even Chris, an Engineer @Offchain Labs, showcased a demo:

What makes Wizard awesome?

• 📝 Pro Code Editor: Built on VS Code's Monaco Editor with full support for Rust & Stylus.

• ⚙️ Secure Remote Compilation: Compile contracts in a safe, isolated environment.

• 🚀 One-Click Deployments: No need for setup—just deploy instantly with pre-funded wallets.

• 🔄 Interactive Testing: Run smart contract tests right in your browser.

• 🔗 Shareable Contracts: Create public links and share your work with the community.

• ✨ No setup, no headaches—just start coding!

Try Wizard now: https://thewizard.app/

Check out the docs: https://docs.thewizard.app

What web3 ecosystems have you worked in?

We’ve worked across multiple Web3 ecosystems, including Ethereum, Arbitrum, Stellar, Internet Computer, and Polkadot, plus many others. In the last three years, we’ve successfully built 30+ projects across 10+ major blockchain ecosystems.

Right now, we’re focusing on Arbitrum Stylus because it’s pushing smart contract development forward in a big way. By enabling Rust-based smart contracts, Stylus makes it possible for a whole new wave of developers to enter the space without needing to learn Solidity. Rust’s speed, safety, and efficiency make it an incredible choice, and we want to make Stylus development as smooth as possible with Wizard.

What are your impressions of working with Stylus, good and bad?

The Good

Rust Support: Stylus lets you write smart contracts in Rust, which is huge for developers who prefer it over Solidity.

Better Performance: Rust’s efficiency means contracts can be more optimized and cost-effective.

More Devs Can Join In: Stylus makes Web3 more accessible for Rust developers, bringing in fresh talent.

Great Community & Support: The Arbitrum team and community have been really engaged and helpful.

The Challenges

Difficult Setup: Getting Stylus running locally requires a bunch of installations and configurations, which is why we created Wizard.

Still Growing: Stylus is new, so its tooling and ecosystem aren’t as mature as Solidity’s yet.

Adoption Hurdles: Solidity still dominates Web3. Getting developers to switch to Rust will take time and good incentives.

Even with these challenges, we believe Stylus has massive potential, and tools like Wizard will help speed up adoption!

What software do you use?

• Windsurf + Claude Sonnet (IDE)

• Warp (Terminal)

• Firefox (Browser)

What hardware do you use?

• Macbook Pro (M1 Pro)

How can we get in touch with you?

• Telegram: tolga0x

• LinkedIn: https://www.linkedin.com/in/tolgayayci/

• GitHub: https://github.com/tolgayayci/

Stylus Saturdays is brought to you by… Arbitrum! 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

Side note: I develop Superposition, a defi-first chain that pays you to use it. You can check our dapps out at https://superposition.so

Hello again! A bit of a delayed post, being at ETH Denver threw my schedule off a little.

Welcome to another Stylus Saturdays post! To recap: Stylus lets you build smart contracts on Arbitrum using any programming language that compiles to WASM. Your contracts are one-to-one compatible with the EVM, even down to the storage backend.

In today’s episode, we’ll discuss how to build a vending machine with Arbitrum Rust Stylus and Chainlink VRF and price feeds, and feature Alisander Qoshqosh from OpenZeppelin’s Stylus team. I’m excited to share that I’ve been writing a book on developing Rust-powered smart contracts:

You can find it at https://rust-for-smart-contracts.com! Please help me out a lot, and if you’re interested, sign up for the waitlist at:

https://getwaitlist.com/waitlist/25549

It introduces how blockchains work from an end developer point of view (beginning with some foundational distributed thinking and cryptography skills), how a smart contract works and then finally how to build and test one from the ground up for Arbitrum, Solana, and NEAR.

It’s also a work in progress, with only the first chapter mostly written up (and needing review), but I enjoy building in public, so please interact with it by providing suggestions if you’d like. I’ll also send everyone who waitlists the book a special Superposition NFT as thanks.

I’m also pleased to share that our new domain https://stylus-saturdays.com will help with our search presence, and will afford me the chance to host a subdomain of resources.

Using Chainlink Price Feeds and Chainlink VRF with Rust Arbitrum Stylus (part 1)

Using Chainlink’s VRF with Arbitrum Stylus is super easy! Being unable to implement an interface may be confusing for some, but fear not: it’s as simple as exporting a specific function in your entrypoint code.

For part 1 of this post, we’re going to implement the entrypoint for users to call, then conclude with the callback in the next post, including some approaches for testing code which includes hard to mock behaviour with a manual gas estimation. Since this is a development journey (in contrast to our completed posts of a similar nature in the past), this code is largely untested.

I visited Japan recently (for the second time), and since middle school, I’ve had an interest that comes to life when I’m abroad looking at vending machines. Not the kind that overrides my personality and makes me a stereotype, but the kind where I take photos if I see one. I wrote a lengthy school essay that really opened my eyes at the time, there’re lots of different vending machines! Wikipedia was only just becoming a thing and we were learning how to do primary and secondary research.

Together, let’s implement a NFT vending machine contract that uses a Chainlink Verifiable Random Function (VRF) to get a random word to seed a random number generator. We’ll use the random word to pick a NFT for a requesting user after using a Chainlink Price Feed to convert the ETH supplied to USD for selecting a NFT tranche to send.

The NFTs are stored in a vector that goes one way, with no pricing from the contract itself in the form of buckets that you might see in a concentrated AMM-like structure.

We’ll take a flat fee from users who participate in this system to power our VRF using Chainlink’s 2.5 direct funding model. This lets us avoid having to set up a subscription elsewhere, and we can focus on taking a fee from users to service the requests instead. We’ll refund every user based on the share of asks and the flat fee.

The user (and technical) story is like this for funding:

So, a user goes to spend their ETH, paying a flat fee for doing so. The funds are locked up until a Chainlink VRF request is fulfilled with a callback, at which point Chainlink’s price feeds are accessed to get the value of ETH at that time. At that point, the NFT tier is chosen from the vector that was established earlier, and we send the user their NFT, or a refund. We assume that Chainlink will absolutely call this function (and that in doing so we’ve accurately predicted the uppermost ETH to spend for the callback).

Implementing some code

First, let’s establish some storage. In a production-facing application, you might prefer to use a special number pattern (think sqrt price x96 if you’re like Uniswap) based on some configuration local to the contract to bucket price ranges which you then store with a mapping, but in our usecase, we’re going to be taking a very simple view of this:

This code is a series of stored structures, loaded by a vector and map combination. Why don’t we storage tag the StorageQueue? The address and u96 combination is storeable in a EVM word. This affords us the efficiency of unpacking a word to access the amount a user has deposited, as opposed to a pair of SLOADs.

For the other fields inside this storage structure, we’re not going to attempt to pack them, as these accesses are virtual anyway. When you have a recursively stored keyed storage value (ie, a map or a vector), Stylus will keccak256 to find the location of the offset for the lookup so it won’t be implicitly loaded when you load a storage slot, only on demand.

Making requests of Chainlink is simply calling a method, which then triggers a callback. To do so, first we define a entrypoint function for users to call.

In the new version of Stylus, errorneous returns from function calls in the new Call functions return a enum type. This type is either the return data from the call, or a type that indicates a decoding failed.

We first define a macro to simplify unpacking this, and we use the sol! macro to load several error types from a Solidity file:

use stylus_sdk::{alloy_sol_types::sol, stylus_core::calls::errors::Error};

pub(crate) fn unpack_err(x: Error) -> Vec<u8> {
    match x {
        Error::Revert(x) => x,
        _ => unimplemented!()
    }
}

#[macro_export]
macro_rules! unpack_on_err {
    ($rd:expr, $conv:ident) => {{
        use stylus_sdk::alloy_sol_types::SolError;
        $rd.map_err(|x| $conv{_0: $crate::errors::unpack_err(x).into()}.abi_encode())
    }};
}

#[macro_export]
macro_rules! revert {
    ($err:ident) => { return Err($err{}.abi_encode()); }
}

sol!("./src/IErrors.sol");

pub use IErrors::*;

The sol macro lets us use:

Which we’ll bring into scope as we use this code.

With that macro sorted, we can start to write some code like:

use crate::errors::*;

sol!("./src/IVRFV2PlusWrapper.sol");

// Calls "calculateRequestPrice" from Chainlink's IVRFV2PlusWrapper.
pub fn calculate_request_price_native(
    access: &dyn CallAccess,
    addr: Address,
    callback_gas_limit: u32,
    num_words: u32,
) -> Result<U256, Vec<u8>> {
    Ok(U256::from_le_slice(&unpack_on_err!(
        access.static_call(
            &Call::new(),
            addr,
            &IVRFV2PlusWrapper::calculateRequestPriceNativeCall {
                _callbackGasLimit: callback_gas_limit,
                _numWords: num_words,
            }
            .abi_encode()
        ),
        ErrChainlinkVRF
    )?))
}

This code neatly makes a request using the calling context in the new Stylus release, then unpacks it to a vector containing bytes if something goes wrong. Before we precede any request to Chainlink’s VRF, we must estimate using their code the fee cost in the native asset. This is due to us using their native payment path, which you can read more about here: https://docs.chain.link/vrf/v2-5/overview/direct-funding

The sol macro lets us seamlessly interleave Solidity code with our Rust. This makes accessing events simple, as we don’t need to define them ourselves, and it facilitates classical EVM tooling (think Alloy). With a function that estimates the cost, we can start to request the random word itself with a function like this:

pub fn request_random_words_in_native(
    access: &dyn CallAccess,
    addr: Address,
    value: U256,
    callback_gas_limit: u32,
    request_confirmations: u16,
    num_words: u32,
    extra_args: Bytes,
) -> Result<U256, Vec<u8>> {
    Ok(U256::from_le_slice(&unpack_on_err!(
        access.call(
            &Call::new().value(value),
            addr,
            &IVRFV2PlusWrapper::requestRandomWordsInNativeCall {
                _callbackGasLimit: callback_gas_limit,
                _requestConfirmations: request_confirmations,
                _numWords: num_words,
                extraArgs: extra_args,
            }
            .abi_encode()
        ),
        ErrChainlinkVRF
    )?))
}

This unpacks the function requestRandomWordsInNativeCall.

We can start to finally build our entrypoint code for locking up users:

#[payable]
pub fn lockup(&mut self, recipient: Address) -> Result<U256, Vec<u8>> {
    require!(!self.version.is_zero(), ErrNotSetup {});
    require!(
        !recipient.is_zero(),
        ErrInvalidRecipient {
            sender: self.vm().msg_sender()
        }
    );
    let value = self.vm().msg_value();
    require!(value > U256::ZERO, ErrNoValue {});
    require!(value <= MAX_U256_VALUE, ErrTooMuchValue {});
    // Prevent people from using this if there aren't any NFTs to distribute.
    let has_nfts = (0..self.levels.len())
        .find(|i| self.levels.get(*i).unwrap().nfts_distributeable.len() > 0)
        .is_some();
    require!(has_nfts, ErrNoNfts {});
    if !self.chainlink_vrf_pending.get() {
        let fee = self.estimate_fee()?;
        self.chainlink_vrf_fee.set(fee);
        let ticket_no = chainlink_vrf_call::request_random_words_in_native(
            self.vm(),
            CHAINLINK_VRF_ADDR,
            fee,
            ESTIMATED_CALLBACK_LIMIT,
            CHAINLINK_VRF_CONFIRMATIONS,
            CHAINLINK_NUM_WORDS,
            Bytes::new(),
        )?;
        stylus_core::log(
            self.vm(),
            RandomnessRequested {
                ticketNo: ticket_no,
            },
        );
        self.chainlink_vrf_pending.set(true);
    }
    let value = value
        .checked_sub(self.chainlink_vrf_fee.get())
        .ok_or(ErrCheckedSub {}.abi_encode())?;
    // Push the user's request for the NFT into the queue.
    let ticket_no = U256::from(self.queue.len());
    stylus_core::log(
        self.vm(),
        LockedUpTokens {
            recipient,
            amount: value,
        },
    );
    self.queue.grow().set(pack_queue_item(value, recipient));
    Ok(ticket_no)
}

This payable function takes ETH, checks that we have NFTs to distribute, checks if we have a Chainlink reply pending, and if we don’t, makes the call out to Chainlink using the function we introduced earlier. It uses a hardcoded value in immutables for some of the gas fields, which we’ll expand on in the next post properly. Following that, it adds the fee to the value, breaking explicitly if a user supplied too little!

It then grows out the storage internally of the queue with a packed word and returns the location in the internal storage to the user. And that’s it for now! Completion (and perhaps some live coding) in the next post on this topic.

Interview with Alisander Qoshqosh from OpenZeppelin

I’m lucky to have had the opportunity to spotlight Alisander from OpenZeppelin! Alisander is an open source developer at OpenZeppelin, working on openzeppelin-stylus.

Who are you?

I’m Alisander Qoshqosh, Open Source Developer at OpenZeppelin.

What’s your project?

Currently I work on openzeppelin-stylus, openzeppelin-crypto and motsu crates.

OpenZeppelin’s Stylus projects are super useful for developers in the ecosystem. Their code at https://github.com/OpenZeppelin/rust-contracts-stylus supports developers in quickly bringing up standard patterns, including working with ERC20 contracts. Their contracts are fully audited, which takes the edge off developing with Stylus for the first time.

OpenZeppelin recently found that Poseidon hashing with Stylus is 90x cheaper than with the ordinary EVM environment: https://blog.openzeppelin.com/poseidon-go-brr-with-stylus-cryptographic-functions-are-18x-more-gas-efficient-via-rust-on-arbitrum

Their openzeppelin-crypto crate simplifies the process of using cryptography on-chain with the same level of security and reusability that you might benefit from with the rest of their code. I couldn’t see whether their crypto package includes the aforementioned Poseidon hashing, but it definitely supports merkle tree proving.

Could you tell us more about your background before web3?

Before web3 I was a backend developer (mostly C#, Rust and Java) for large enterprise projects in telecommunications industry.

Have you worked in other ecosystems aside from the EVM?

I haven’t worked professionally in other ecosystems aside Ethereum.

What were the opportunities for OZ with Stylus?

We want to replicate the success of our Solidity library and make sure Stylus developers have access to secure, efficient and easy to use primitives to build their applications.

What were the joys of working with Stylus?

It is always a joy to write code on Rust. And Stylus brings rust to EVM. Like it.

How do you see the Stylus ecosystem evolving?

Before Stylus, it was actually hard to work with the inheritance problem, the lack of constructors, and a lack of testing framework. But good to see, that the last issue is already addressed. And other features are coming soon in the stylus-sdk 0.9.0. So yeah, I see a big leap forward!

How can we get in touch with you?

Telegram: https://t.me/qalisander

Stylus Saturdays is brought to you by… Arbitrum! Thanks to a special grant from the foundation.

This post is powered by… Arbitrum! With a grant from the Fund the Stylus Sprint program. You can learn more about Arbitrum grants here: https://arbitrum.foundation/grants

Join the Stylus Devs DAO: https://discord.gg/eTRt3r3F

Follow me on X: @baygeeth

Side note: I develop Superposition, a defi-first chain that pays you to use it. You can check our dapps out at https://superposition.so

Hello again! Welcome back to another Stylus Saturdays post!

I’m pleased to announce we’ve been graciously funded by the Arbitrum grants committee! I’m super thankful to everyone advocated for this little newsletter, we love building on Stylus, and with this support we’re able to do the following:

Launch three major dApps

With this support, we will develop three major dApps: A fully on-chain orderbook with hooks, a gas golfing competition for an on-chain optimisation problem, and a fully on-chain NFT platform (again, with hooks)!

These three projects will be fully audited and MIT licensed, ready for any would-be developers to jump in and fork! The emphasis will be on extensibility to bootstrap projects developing with Stylus. We intend to actively support the Stylus developer experience with these projects, and having the audit component sorted will mean it’s possible for others to safely enjoy the benefits!

The gas competition will be run (mostly) on-chain, with a cash prize for finding the most efficient Stylus solution for an optimisation problem! Stay tuned for more.

Kickstart the Stylus Developers DAO

I have created an unofficial Stylus developers community hosted on Discord, with an eye for hands-on advice specific to individual projects based on mine and my team’s experience. Ask questions about anything, and hopefully get some personalised advice to your codebase! This will also be a vehicle to organise community events about alternative programming on Arbitrum.

https://discord.gg/eTRt3r3F

Release a ton of posts

Thanks to Arbitrum’s generous support, I will be releasing posts on a regular cadence and of a broader range than was possible previously!

CALL FOR STYLUS BUILDERS

Anyone, anywhere, if you’re building on Stylus, I want to know! Please drop me a line at @doggish on Telegram. I’d love to hear more about what you’re up to, and maybe feature you here! I’ll be reaching out to projects I’m aware of this week to get you included.

Using Go with Arbitrum Stylus

Stylus = WASM. This means you can use most programming languages that generate WASM (though there’s no support for WASI so be mindful)! This includes Go with Tinygo as the backend.

In a simple Go contract, we’ll define a simple counter app that lets you add and subtract from a storage variable:

package main

//go:generate stylus-go

import (
	"math/big"

	"github.com/af-afk/stylus"
)

//stylus entrypoint
type Storage struct {
	Counter stylus.StorageUint256
}

//stylus uint256
func (s Storage) Add(x *big.Int) ([]byte, error) {
	y := s.Counter.Get()
	y.Add(y, x)
	s.Counter.Set(y)
	var b [32]byte
	x.FillBytes(b[:])
	return b[:], nil
}

func (s Storage) Sub(x *big.Int) ([]byte, error) {
	y := s.Counter.Get()
	y.Sub(y, x)
	s.Counter.Set(y)
	var b [32]byte
	x.FillBytes(b[:])
	return b[:], nil
}

Reflection is difficult in the Tinygo environment, so we’ll be using code generation to generate the entrypoint/code for this to make it actually work. This is similar to Rust functionally speaking, which makes things comparatively similar and simple.

The repo where this lives is at https://github.com/af-afk/stylus. The devex needs some work, though I expect with time, this should become easier!

How to implement this yourself: writing some primitives

First, to reproduce the SDK and code generator I’ve mentioned here, we need to implement some basic primitives to do things like convert byte arrays to *big.Int and storage accesses. For all of the code below, we have some functions for hostio access using Tinygo stubs.

We implement an internal uint256 number and conversion methods:

Which we later use to implement some storage:

A simple approach to storage in this case is to have an internal counter and to simply bump it every time someone asks for a storage pointer at runtime. This is the approach implemented above.

Lastly, we implement a pair of conversion functions:

These will come in handy as we implement our code generator.

Implementing the code generator

Second, we need to implement some code that’s able to parse a pattern similar to Rust. *big.Int is a good experience (much to my researcher’s despair when he reads Go) in my opinion, so for a simple counter app, we should allow users to optionally declare the type of the arguments for their functions using a comment. For this example, we’re simply supporting uint256 and int256, as addresses could be implemented trivially at a later time.

We’re forcing the user of this Go code to return a byte slice and error, with the former being sent directly as returndata, and the latter tested to be non-nil to know whether to return an erroneous contract state (triggering a revert by the runtime). This is obviously not great devex, but it should be trivial to implement another feature later that also converts the return type in the code generator the same way we do for arguments.

Writing a code generator a la gqlgen (which we use extensively at Fluidity Labs for our backend code) is as simple as reading a number of Go files in a directory, then parsing the Go. We can do so beginning with the following:

The fully implemented form of all of the code here lives at https://github.com/af-afk/stylus/blob/trunk/cmd/stylus-go/main.go#L45-L69.

This code gives us a map with the AST for the various Go files in the current directory. Our goal is to find a struct that’s been marked as the entrypoint for the contract, then to start to read its associated functions, to check what the preferred types are, then to spit out a symbol exported entrypoint function.

The above code does some work to find a comment that’s like:

//stylus entrypoint

This clues the code in for its first pass as to which functions we’re searching for. Some more work is done to confirm that the type is, in fact, a struct, but we’re going to omit this for now for brevity reasons.

After some boring work involving confirming the struct, we’re going to emit our first bit of generated code:

This uses this function to generate code like this:

In practice resulting with the following:

For each storage unit in the struct, we bump an internal counter, and we generate code that knows how to read from the storage slot at that position.

After confirming that we’ve found the struct, we’re going to search for each function in each file with a second pass:

We’re going to confirm the following:

1. This is titled (so as to be exported under normal circumstances by Go).

2. This might have a hint as to what the types should be. Hinting the types with a comment like //stylus uint256 empowers the developer to specify specifically what the type should be for the functions.

3. That this function is associated with the struct from before that’s been marked as the entrypoint. If this isn’t the case, we need to ignore this function.

After confirming these things about the function, we’re going to begin to spit out templated code with the meat of our entrypoint.

The code explainArgs does some unpacking to determine the internal and external-facing types for users:

The type guessing takes place with the //stylus comment. There are some functions below to convert the AST human readable name to the external type, which we’ll skip for now.

The templating code spits out functions to follow the first print that takes place in the structure checking code:

This results in code like this:

Much like the generated code for the Rust SDK I imagine. This code can then be compiled with Tinygo (see here) for a good Tinygo build profile and stripping with wasm-opt. For our simple example this all results in 13 kilobytes.

I will be developing this SDK to improve its user experience in the coming few months, hopefully eventually being possible to be used at scale by individual users alongside my regular (dApp-focused) programming!

The repo lives here: https://github.com/af-afk/stylus, including the TODO list. The flexibility of WASM means we can develop smart contracts in most programming languages!

Interview with Howard from Lit Protocol

I had the opportunity to interview Howard from Lit Protocol. We’ve previously covered them here, and I’m super excited to discuss their product again! Lit Protocol is building a decentralised signing network.

Could you tell us some more about your background before web3?

I got into web3 pretty early on in my career, pretty much right after college. After obtaining my Master of Engineering at University of Oxford, I joined a startup foundry in Vancouver called Axiom Zen as a Frontend Engineer Intern. Around six months after joining, CryptoKitties, the project that was created by the same folks who were sitting by my side in the office, was really taking off, and I seized the opportunity to work on that project. That project changed my life.

I transitioned into backend engineering on the job, learning Golang, NodeJS, Solidity, which culminated to my first major achievement on that team - I wrote the set of contracts for the Offers feature and at one point in time it had held more than $3.5MM USD in escrow on chain. It was truly some wild stuff. Then, I went on to lead a team of 7 engineers to develop the Dapper Wallet and Payment Rails for the NBA TopShot project with Dapper Labs.

Have you worked in other ecosystems aside from the EVM?

Yes, I worked in the Flow blockchain ecosystem back when I was at Dapper Labs.

How did you learn about Stylus?

At Lit Protocol, we need a base chain that is cheap and fast for processing transactions, as well as one that would help us move fast as a team. We use the chain as a public consensus and data layer allows us to keep the Lit nodes stateless except for key material, which is a significantly simpler architecture than otherwise. Alternatives are not impossible but rather long winded.

A long time ago, we were on Celo. Then, we moved to the OP stack because, at the time, they had decent devX for building in the necessary precompiles we needed for our PKPs. At some point, we had reached the limits of the OP rollup and needed an even better solution, so we started to look into Arbitrum.

While OP has 2s block times, Arbitrum has almost instantaneous confirmations - this was great first signs. We also noticed that Arbitrum was even cheaper than on OP stack, another great sign. When we were using OP stack, every time we needed to add or change the precompile code, we needed to coordinate with Caldera - our OP rollup provider - for shipping the build and upgrading the chain, which was a very lengthy process especially since it involves communicating across teams and timezones.

This was also a rather involved process when developing in non-production environments, too. Every precompile code change resulted in needing to update a fork of Anvil (Foundry) before we can run our CI tests. With Stylus, we can simply deploy the contract after changing the Rust code, and we no longer need to maintain a fork of Foundry for this particular purpose. Lit dev team work in Rust, and OP stack is built upon geth and the larger Golang ecosystem - at the time, we had to spend costly cycles switching contexts from Rust to Golang to write our precompiles

With Stylus, we can just write in Rust like we normally do, and deploy that as a smart contract using the security benefits of Rust, as opposed to Golang.

What were the opportunities for Lit Protocol with Stylus?

Lit uses smart contracts to manage programmable keys (PKPs) and their permissions. Each Lit PKP has a unique public key in order to use them, and this public key is derived using Rust code that is deployed as a Stylus contract - this allows us to model the necessary logic as simply contract-contract interactions.

What were the joys of working with Stylus?

These were the benefits that I had experienced working with Stylus:

1. Interoperability between Solidity and Stylus smart contracts meant we can write simpler code.

2. Cheaper and faster execution of the WASM VM compared to the EVM (geth).

3. Good documentation and hands-on support resulting in good devX! Easy to run a dev node locally for POC and testing.

It was also easy to get started with a basic POC, there was a good amount of examples to reference, and I got as far as setting up a local Nitro testnode where I could deploy and interact with my Stylus contracts, which was sufficient to complete the development cycle.

Being able to write in Rust opens up the opportunity for us to write all kinds of precompiles in the future, and the guides for most basic operations are pretty accessible.

How do you see the Stylus ecosystem evolving?

Generally speaking, Stylus as a product will be great for helping convert more developers to develop on rollups, and for the people who prefer to work with the safety of the Rust language itself, this tool offers that option for them to deploy a smart contract without needing to learn the intricacies of Solidity.

I expect to see all verticals to grow within the Stylus ecosystem because it just makes it that much easier to work with smart contracts across the board now.

How can we get in touch with you?

LinkedIn: https://www.linkedin.com/in/itshowardtam/

X: https://x.com/itshwrdtm

Lit Protocol Discord: https://discord.com/invite/zBw5hDZve8

This post is powered by… Arbitrum! With a grant from the Fund the Stylus Sprint program. You can learn more about Arbitrum grants here: https://arbitrum.foundation/grants

Join the Stylus Devs DAO: https://discord.gg/eTRt3r3F

Follow me on X: @baygeeth

Side note: I develop Superposition, a defi-first chain that pays you to use it. You can check more out at https://superposition.so