Time travelling debugging with CodeTracer, AssemblyScript on Stylus, interview with Gonza
September 12th, 2025
Hello everyone! Bayge here, once again. A LOT slower on the draw with this post, we have some MAJOR catching up to do to make our usual cadence. Covered in today’s post:
🚀 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.
⚡ 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 🎨.
🎤 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!
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:
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.
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.
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.
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:
Hunter, from Offchain Labs.
Ivan, from Superposition.
Churro, also from Offchain Labs.
Marko (Blazeaster), from Superposition.
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,3These 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-recommendationThis 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_modulesSo, 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.tsWow, 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.tsWhich 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.07142857142857142If 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.07263669959755374Which 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 9Which 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 10Wow! 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,9When 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!
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)