DEV Community: Arbitrum

Your backend code is a black box. It doesn't have to be.

Ben Greenberg — Wed, 01 Apr 2026 09:07:54 +0000

Your API takes inputs and returns outputs. The logic in between? Nobody outside your team can verify it. Regulators read documentation you wrote about it. Partners call your endpoint and trust the response. Users don't even get that.

This has worked for decades. But there's a growing category of backend logic where "trust us" isn't enough. Scoring algorithms, compliance checks, eligibility rules, validation pipelines. Anywhere someone needs to independently confirm that your code does what you say it does.

You don't have a code problem. You have a verifiability problem.

The case for publicly auditable code

Most backend engineers don't think about code auditability because most code doesn't need it. Your CRUD endpoints, your auth flows, your data transformations, those are internal concerns. Nobody outside your org needs to verify them.

But some functions carry weight. A scoring algorithm that determines loan eligibility. A validation pipeline that checks regulatory compliance. A pricing engine that partners depend on. For these functions, the standard answer is documentation: you write a spec, maybe you share pseudocode, and everyone agrees to trust that the running code matches the paper.

That's not verification. That's trust with extra steps.

Publicly auditable code means anyone can call the same function with the same inputs and confirm they get the same outputs. The logic is visible. Execution is deterministic. And the code can't change silently after deployment.

This isn't a new idea. Open source gives you code visibility. But open source doesn't prove that the code running in production is the same code in the repo. You need a runtime where the deployed code is the source of truth, and where every execution is independently reproducible.

That runtime exists. And you don't need to learn a new language to use it.

Rust in, verifiable execution out

When most engineers hear "deploy code onchain," they picture learning Solidity, memorizing gas optimization tricks, and rewriting working logic in an unfamiliar language. That's a reasonable reason to stop listening.

Arbitrum Stylus skips that detour. You write Rust, compile to WASM, and deploy it to a blockchain that's optimized for low-cost computation. Your existing toolchain, your existing crates, your existing mental model. The contract runs alongside Solidity smart contracts with shared state, but you never need to touch Solidity yourself.

This isn't about converting you to crypto. It's about giving you a deployment target where execution is publicly verifiable by default.

Three properties matter here:

Every execution is independently auditable. Anyone can call the contract with the same inputs and confirm they get the same outputs. No trust required.

The logic is immutable. Once deployed, the code can't change silently. If you push an update, that's a new deployment with its own address and its own history. No "we patched it last Tuesday but forgot to tell you."

Execution is deterministic. Same inputs, same outputs, every time, on every node. No environment-specific drift, no floating point surprises across hardware.

What the architecture looks like

I built a scoring engine to test this pattern. The architecture splits cleanly between what stays in your infrastructure and what moves onchain:

Your backend stays exactly where it is. An Axum API server handles business rules, authentication, request routing. Normal backend work. The only difference is that when the API needs a computation verified, it calls an onchain contract instead of a local function.

The onchain piece is a Stylus contract. It takes parameters, runs the calculation, and returns results. No state storage, just pure computation. Think of it as a function you deploy instead of host.

A shared Rust crate holds the type definitions and compiles for both environments. The contract uses no_std for WASM. The API server uses std for native. Same types, both sides. The compiler guarantees they match. No serialization mismatches, no type drift between your API and your contract.

One language across the entire stack. The chain boundary becomes a function call, not a language barrier.

The performance question

The first objection any backend engineer raises: what's the overhead?

Fair. Onchain computation has historically been expensive. That's the whole reason Solidity exists. It was designed to minimize execution cost on the EVM.

Stylus changes the math. WASM execution on Arbitrum is dramatically cheaper than EVM execution for compute-heavy workloads. The scoring engine used over 90% less gas than the equivalent Solidity contract doing identical work:

Environment	Score	Gas Usage
Offchain Rust	953	n/a
Onchain Stylus (WASM)	953	76,048
Onchain Solidity (EVM)	810	1,027,635

Storage operations cost the same either way, but iterative math, weighted calculations, and loop-heavy logic is where WASM pulls ahead.

This isn't a contrived benchmark. RedStone, an oracle provider, published similar results after porting their verification logic to Stylus. Compute-intensive work is where this architecture pays for itself.

Where auditable code matters

Not every function belongs onchain. But some backend logic sits in a category where "trust me" isn't good enough:

Scoring and risk calculations, where regulators want to audit the exact computation, not a description of it. Eligibility determinations, where partners want to verify outcomes independently instead of trusting your API response. Compliance validation, where auditors want proof that the logic running today is the same logic approved last quarter. Data pipelines, where counterparties want to confirm their data passed through agreed-upon rules.

If you've ever written documentation explaining how your algorithm works so someone else could trust it, that's the function that belongs onchain. Let them verify the code instead of reading your summary of the code.

The scoring engine I built is one example of this pattern. But the pattern is the point, not the example. Any pure function where independent verification adds value is a candidate.

What you'd actually do on a Monday morning

If you write Rust, the learning curve is smaller than you think.

Install cargo-stylus, which handles compilation and deployment. Write your function with #[entrypoint] and #[public] macros. Compile to WASM. Deploy to a testnet. Call it from your existing API using an RPC endpoint.

#[entrypoint]
#[storage]
pub struct ScoringEngine;

#[public]
impl ScoringEngine {
    pub fn score(&self, factors: Vec<Factor>, rules: Vec<Rule>) -> u32 {
        // Your computation logic here
        // Publicly verifiable, deterministic, immutable
    }
}

Your database, your auth, your business logic, none of that moves. You add one function that runs somewhere verifiable instead of somewhere trusted. Everything else stays the same.

The scoring engine repo has working code, setup instructions, and benchmarks comparing three execution paths: onchain Stylus, onchain Solidity, and offchain Rust. It's a concrete starting point, but the approach applies anywhere you need auditable computation.

You're adding a deployment target, not adopting a lifestyle

The shift is smaller than it sounds. The same way you might deploy a function to Lambda for serverless execution or to a TEE for confidential computing, you deploy to Arbitrum for verifiable execution.

Your Rust skills transfer directly. Your toolchain stays the same. The only thing that changes is who can verify your logic: everyone.

If you've been dismissing onchain as irrelevant to backend work, spend thirty minutes with the repo.

hummusonrails / stylus-scoring-engine

Verifiable credit/risk scoring engine: Stylus (Rust/WASM) vs Solidity on Arbitrum with three-way gas benchmark

Verifiable credit/risk scoring on Arbitrum with a three-way gas benchmark: offchain Rust vs onchain Stylus vs onchain Solidity.
Quick Start · Architecture · Report a Bug

What it does

Benchmarks the same scoring algorithm across three execution environments with real gas numbers
Scores entities against configurable weighted rules with iterative convergence and cross-factor correlation
Demonstrates Stylus gas savings on compute-heavy workloads (over 90% cheaper than Solidity)
Shares Rust types between the onchain contract and offchain API server from a single crate
Stores scoring rules in SQLite with full CRUD via REST endpoints

Quick Start

# clone and install
git clone https://github.com/hummusonrails/stylus-scoring-engine.git
cd stylus-scoring-engine
pnpm install

# start the local arbitrum devnode
pnpm devnode

# in a new terminal, deploy both contracts
pnpm deploy:all

# start the api server (reads .env written by deploy)
pnpm api

# in a new terminal, run the three-way benchmark
pnpm benchmark

Prerequisites

Rust 1.88+ with…

View on GitHub

The gap between "interesting in theory" and "I could actually use this" is shorter than you expect.

What winning Arbitrum Open House teams do differently

Ben Greenberg — Tue, 17 Feb 2026 14:13:22 +0000

tl;dr You can also watch a quick 60-second animated video covering all these details:

// Detect dark theme var iframe = document.getElementById('tweet-2023756279282589847-592'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2023756279282589847&theme=dark" }

Most hackathon judging is a black box. You submit, you wait, you get a number. Maybe feedback, maybe not. Open House does it differently, and if you're applying, knowing the framework gives you an edge.

We evaluate every Open House submission on execution, problem-solution fit, and traction. No mystery categories, no subjective vibes. Here's what the judges are looking at and why it matters.

Execution is the first filter

The first thing judges open is your repo and your demo. Not your pitch deck. Not your Twitter bio.

A strong execution score means you shipped a functional MVP with decent code structure, some docs and tests, and a demo that actually works. That's the baseline for being taken seriously. Below that, you're showing an idea, not a product. Above that, you're showing a team that can build under pressure and keep building after the event ends.

In India, the first Open House cohort, here's what the team that won the highest execution score did. They implemented a high-precision math layer in Stylus using Q96.48 fixed-point arithmetic, added trade segmentation for large orders, and had the whole thing running on Arbitrum. That's not a weekend sketch. That's a team demonstrating they can ship production-grade work on a deadline.

What judges are actually checking: Does the repo match the demo? Is the code structured like someone plans to maintain it? Is there a deployed contract on an Arbitrum chain? Does the team's background (GitHub history, prior work) support the claim that they can keep going?

Problem and solution is where most teams lose points

This is the criterion where most submissions land in the middle of the pack. Most teams can identify a problem. Fewer can explain why their solution is the right one, and fewer still can articulate why it needs to exist on Arbitrum specifically.

Scoring well here requires strong differentiation or an ecosystem-first approach, plus a roadmap that supports continued execution. Generic DeFi dashboards and "blockchain for X" pitches without clear user value sit near the bottom.

Right now, the sectors where we see the strongest builder momentum and clearest Arbitrum fit are payments and stablecoins, DeFi, RWAs, privacy, consumer products, and Arbitrum-native tooling around Stylus and Timeboost. Judges know what good looks like in each of these areas, and the bar is specific.

In DeFi, for instance, we care about user-facing financial products, not standalone protocols. In payments, we want products where stablecoins feel like local money, not products that expose crypto complexity to end users. In privacy, we're looking for privacy-enabled products people would actually adopt, not abstract primitives.

The difference between a mid-range and a top score here? A top score is a first-of-its-kind idea for Arbitrum with a well-articulated case for why the problem, the solution, and the chain all fit together.

Traction or potential is the tiebreaker

Two teams with similar execution and problem-solution scores get separated here. This criterion looks at whether there's evidence the project will continue to exist after the event.

Judges look at GitHub activity beyond the hackathon commits, social presence, community engagement, and whether there's a defined path forward. A roadmap alone isn't enough. Judges want to see signals that the team is building something they intend to ship to users, not just something that wins a prize.

In India, the first Open House cohort, many of the winning teams advanced to the mentorship program after the Founder House. Several of those teams are continuing their progress toward mainnet launch. That's the kind of trajectory this criterion is trying to predict.

At the bottom of the range: dormant repo, no socials, no roadmap. At the top: demonstrated adoption or strong momentum with an engaged community, partnerships, repeat builders, or a credible launch plan.

The eligibility rule nobody should miss

Before any scoring happens, there's one binary check: your project must be deployed on an Arbitrum chain. Not "plans to deploy." Not "could work on Arbitrum." Deployed. This eliminates a surprising number of submissions.

That chain can be Arbitrum One, Arbitrum Sepolia, or your own Arbitrum chain. If you haven't explored launching your own, the gentle introduction is a good starting point. And if you want to test on infrastructure purpose-built for builders, Robinhood recently launched a testnet on Arbitrum and backed Open House with a $1 million investment in supporting builders in the ecosystem.

// Detect dark theme var iframe = document.getElementById('tweet-2021600209524969824-289'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2021600209524969824&theme=dark" }

What this means for your project

The NYC buildathon is live right now. The NYC Founder House is coming up and registration is open. Dubai registration is open too, with the buildathon running April 23 to May 14 and the Founder House May 28 to 31. Wherever you are in the pipeline, the scoring framework tells you where to spend your time.

Ship working software. A polished pitch deck with a broken demo loses to a rough pitch deck with a working MVP every time. Get your contracts deployed on Arbitrum Sepolia at minimum, Arbitrum One if you can.

Know what good looks like in your sector. If you're building in DeFi, that means a user-facing product with clear financial utility, not another protocol wrapper. If you're building in payments, that means an experience where stablecoins feel invisible to the end user. Judges evaluate submissions against specific expectations for each category, so make sure your project speaks directly to what matters in yours.

Show evidence of continued building. Active GitHub commits, a defined roadmap, social engagement, and pilot users all contribute to the traction score. If your repo goes silent after submission, judges notice.

Build on the Arbitrum stack with intention. Using Stylus, leveraging Timeboost, composing with existing Arbitrum DeFi protocols, or scoping an Arbitrum chain for your use case are all signals that you understand the ecosystem, not just the EVM.

Open House is designed to find teams that will keep building. The scoring reflects that. If you're serious about shipping a product on Arbitrum, the evaluation criteria work in your favor.

The NYC buildathon is live, the NYC Founder House kicks off soon, and Dubai registration is open. If you're building in payments, DeFi, RWAs, privacy, consumer, or Arbitrum-native tooling, there's an entry point for you right now at openhouse.arbitrum.io.

How I Built a Claude Code Skill That Scaffolds Complete Arbitrum dApps

Ben Greenberg — Thu, 05 Feb 2026 10:11:48 +0000

There is a gap in Web3 developer tooling that has always frustrated me. On one side, you have hello-world tutorials that deploy a counter contract and stop there. On the other, you have production codebases with thousands of lines of configuration that took months to evolve. The space in between -- where you need a working dApp with contracts, a frontend, a local chain, and a deployment pipeline -- is where most developers get stuck.

I work in DevRel at Arbitrum, and I kept seeing the same pattern: developers would ask Claude Code to help them build on Arbitrum, and it would produce plausible-looking code that used outdated SDK versions, wrong RPC endpoints, or patterns that simply do not work on Stylus. The model has general Solidity knowledge, but it lacks the specific, opinionated context needed to scaffold a real Arbitrum project from scratch.

So I built a Claude Code skill to fix that.

What Are Claude Code Skills?

Claude Code skills are structured markdown files that you drop into ~/.claude/skills/. When Claude Code starts a session, it reads these files and treats them as domain-specific knowledge. Think of a skill as a system prompt, but modular and version-controlled.

A skill has two parts. First, a SKILL.md file at the root that defines the core knowledge: what tools to use, what decisions to make, and what patterns to follow. Second, a references/ directory containing deeper documentation that Claude loads on demand. This two-tier approach keeps the context window lean -- Claude reads the decision tree up front and only pulls in detailed reference material when the conversation heads in that direction.

The key insight is that skills are not code generators. They do not template out files. Instead, they give Claude the structured knowledge it needs to generate correct code itself, tailored to whatever the developer actually asks for.

Architecture of the Skill

The arbitrum-dapp-skill is organized around a decision tree and six reference documents.

The decision tree lives at the top of SKILL.md and handles the first question any Arbitrum project faces: Stylus Rust, Solidity, or both?

Need maximum performance and lower gas costs? Route to Stylus Rust, load references/stylus-rust-contracts.md.
Need broad tooling compatibility and rapid prototyping? Route to Solidity, load references/solidity-contracts.md.
Hybrid project? Use both. Stylus and Solidity contracts are fully interoperable on Arbitrum -- they share the same address space, storage model, and ABI encoding.

Below the decision tree, the skill defines an opinionated project structure:

my-arbitrum-dapp/
├── apps/
│   ├── frontend/            # React / Next.js app
│   ├── contracts-stylus/    # Rust Stylus contracts
│   ├── contracts-solidity/  # Foundry Solidity contracts
│   └── nitro-devnode/       # Local dev chain (git submodule)
├── pnpm-workspace.yaml
└── package.json

This is a pnpm monorepo. The apps/ directory separates concerns cleanly. The nitro-devnode directory is a git submodule pointing to the official Offchain Labs devnode, which gives you a local Arbitrum chain running in Docker on localhost:8547 with pre-funded accounts ready for deployment.

The six reference documents cover the full development lifecycle:

stylus-rust-contracts.md -- Stylus SDK patterns, sol_storage! macros, #[public] methods, events, error handling
solidity-contracts.md -- Solidity 0.8.x on Arbitrum with Foundry workflows
frontend-integration.md -- viem + wagmi setup, hydration safety, contract reads and writes
local-devnode.md -- Docker setup, pre-funded accounts, CORS proxy for browser access
deployment.md -- Testnet (Arbitrum Sepolia) and mainnet (Arbitrum One) deployment
testing.md -- Unit testing strategies for both Stylus and Solidity contracts

Why These Tech Choices

Every choice in the stack is deliberate.

Stylus SDK v0.10+ because earlier versions had breaking API differences in storage macros and entrypoint attributes. Pinning to 0.10+ means Claude generates code that actually compiles.

Foundry over Hardhat for Solidity because Foundry's forge is faster, its testing framework uses Solidity itself (no JavaScript test wrappers), and cast provides a clean CLI for chain interaction.

viem over ethers.js because viem provides strict TypeScript types for contract interaction. When Claude generates a readContract call with the wrong function name, TypeScript catches it at compile time rather than failing silently at runtime.

wagmi because it wraps viem in React hooks with built-in state management for wallet connections, transaction confirmations, and contract reads. The skill includes hydration safety patterns for Next.js, which is a common stumbling block.

pnpm because workspaces let the frontend import ABIs directly from the contract directories, and pnpm's strict dependency resolution avoids the phantom dependency issues that plague npm in monorepos.

A Concrete Walkthrough

Here is what it looks like in practice. You install the skill, start Claude Code, and type:

Build me an NFT contract using Stylus Rust with a React frontend that lets users mint tokens.

Claude reads the skill, routes to the Stylus path, and starts scaffolding. It creates the monorepo structure, generates a Stylus contract using sol_storage! for the token state, implements mint and balance_of as #[public] methods, and emits a Transfer event using alloy_sol_types:

sol_storage! {
    #[entrypoint]
    pub struct NftContract {
        mapping(uint256 => address) owners;
        mapping(address => uint256) balances;
        uint256 total_supply;
    }
}

#[public]
impl NftContract {
    pub fn mint(&mut self) -> U256 {
        let token_id = self.total_supply.get() + U256::from(1);
        self.total_supply.set(token_id);
        self.owners.setter(token_id).set(msg::sender());
        self.balances.setter(msg::sender()).set(
            self.balances.get(msg::sender()) + U256::from(1)
        );
        evm::log(Transfer {
            from: Address::ZERO,
            to: msg::sender(),
            value: token_id,
        });
        token_id
    }
}

On the frontend side, Claude sets up the wagmi provider, creates a mint button using useWriteContract, and wires up a display component with useReadContract -- all with proper hydration guards for Next.js. It exports the ABI from cargo stylus export-abi and places it where the frontend can import it.

The entire project is configured to run against nitro-devnode out of the box. You start Docker, run the devnode script, deploy with cargo stylus deploy, and the frontend connects through a CORS proxy route.

Install It

One command:

bash <(curl -s https://raw.githubusercontent.com/hummusonrails/arbitrum-dapp-skill/main/install.sh)

This clones the skill into ~/.claude/skills/arbitrum-dapp-skill. The next time you start Claude Code, it picks it up automatically. You can also install via ClawHub:

npx clawhub@latest install arbitrum-dapp-skill

Or if you prefer manual installation:

git clone https://github.com/hummusonrails/arbitrum-dapp-skill.git ~/.claude/skills/arbitrum-dapp-skill

To see it in action before installing, there is a demo video on YouTube that walks through the full workflow.

I also wrote a deeper technical thread on X covering the design decisions in more detail.

// Detect dark theme var iframe = document.getElementById('tweet-2019337368033992833-712'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2019337368033992833&theme=dark" }

What's Next

The skill covers the core development lifecycle, but there is more to build. Token bridging patterns between L1 and Arbitrum, integration with Orbit chains, and more advanced Stylus patterns like precompile access are all on the roadmap.

If you are building on Arbitrum and run into a pattern the skill does not cover well, open an issue or submit a PR on the GitHub repo. The whole point of packaging this as a skill rather than a tutorial is that it evolves with the ecosystem. As the Stylus SDK ships new versions, as viem adds new features, the skill updates and every developer who installed it gets the improvements on their next git pull.

Skills are a new primitive for developer tooling. Instead of writing documentation that developers read and then translate into code, you write structured knowledge that an AI agent consumes directly. The developer describes what they want, and the agent applies the knowledge to generate a working implementation. I think this pattern is going to reshape how we think about developer education in Web3 and beyond.

You can find the full source, documentation, and installation instructions at hummusonrails.github.io/arbitrum-dapp-skill.

Open House NYC

benjamintan.eth (💙,🧡) — Mon, 26 Jan 2026 17:37:06 +0000

Open House first started out in India. Now in 2026, it’s back - with its first stop in NYC 👉🏻 Register Now 👈🏻

// Detect dark theme var iframe = document.getElementById('tweet-2010698393157574780-223'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2010698393157574780&theme=dark" }

Open House NYC consists of a 3-week Online Buildathon (Feb 5 – Feb 26, 2026) and an IRL Founder House (Mar 6 - Mar 8), designed to help experienced builders go from prototype to something that actually ships onchain.

This isn’t about rushing demos; It’s about building with intent and follow-through.

What to expect

Deep technical sessions on the Arbitrum stack
Live coding demos and hands-on workshops
Founder-focused sessions on GTM and shipping post-buildathon
Mentorship from builders in the Arbitrum ecosystem
$60,000 in prizes and grants to keep teams building // Detect dark theme var iframe = document.getElementById('tweet-2015007731724525872-286'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2015007731724525872&theme=dark" }

Join Open House NYC

If you’re looking for a structured, builder-first way to take your project further, this might be for you.

Apply here

See you at Open House 🗽