Arbitrum Hackathon Concluded! Updates to the Stylus space, Walnut Stylus Debugger, interview with Ryan Soury from Usher Labs

20th April, 2025

AI is amazing! BRB, considering a career change. Just kidding. Last headline image AI generated.

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.

An audience member coming to terms with the prospect of winning a custom mechanical keyboard.

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.

Yours truly on stage explaining the concept to a very patient audience.

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.

Mysteriously, I couldn’t find any photos of our group of hackers hacking away at their solutions in the wild. This is one of the mentors supporting a developer.

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.

We picked five winners to receive Superposition branded keyboards. These guys were really impressive devs!

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!

WOW! I would consider proposals.app a DAO “operating system” of sorts, owing to how it aggregates information from so many places and distills it to be simple to interact with.

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!