DEV Community: Arbitrum

I built my first Robinhood Chain app as an index basket

Ben Greenberg — Sun, 12 Jul 2026 15:51:24 +0000

I built a small index basket app on Robinhood Chain because I wanted to understand the developer path from the first contract deploy all the way to a working frontend.

The app is intentionally plain: a user deposits Stock Tokens, which are blockchain tokens that represent real equity exposure, and receives an ERC-20 basket share. ERC-20 is Ethereum's standard token interface, so a compatible token exposes familiar methods like balanceOf, transfer, and approve. The basket share is priced from live price feeds, and the user can redeem it back into the underlying Stock Tokens.

That's the part that made this interesting to me. The chain is custom, but the app path is not. I still wrote Solidity, deployed with Foundry, read contract state with viem, and wrote transactions from React with wagmi.

If you've built normal web apps, think of the chain's RPC endpoint as the API base URL. A wallet is login plus a signing key. A smart contract is backend code you deploy to the chain, except you should treat it like immutable infrastructure because you don't get to hot-patch it casually later.

The demo and source are here:

The custom chain still feels like the EVM

Robinhood Chain is a custom Arbitrum Chain, which means it runs as a dedicated chain on the stack of Arbitrum, an Ethereum scaling system. It is also EVM-compatible. EVM means Ethereum Virtual Machine, the runtime that executes Solidity contracts, so the tooling surface looks like the Ethereum developer flow many tutorials already teach.

An L2, or rollup, is a chain that executes transactions separately and then posts compressed proof or transaction data back to Ethereum. Robinhood Chain uses Ethereum blobs for data availability, which is a cheaper Ethereum data lane for rollups to publish the data needed to reconstruct chain state. Gas, the metered compute fee you pay to run transactions, is paid in ETH.

The first deploy looks like this:

export PRIVATE_KEY=0x<your_private_key>
export RH_RPC_URL=https://rpc.testnet.chain.robinhood.com

forge create src/MyContract.sol:MyContract \
  --rpc-url $RH_RPC_URL \
  --private-key $PRIVATE_KEY \
  --broadcast

Foundry is the contract build, test, and deploy CLI. forge create compiles the contract, sends the deployment transaction, and broadcasts it to the RPC endpoint.

This is the part I appreciate as a developer. Robinhood gets its own chain configuration, infrastructure, pricing, and product controls. I still get the contract model I know how to reason about.

Stock Tokens are ERC-20s with display accounting

Stock Tokens are ERC-20s that represent real market assets. That means contracts can read balances, request approvals, and transfer them using the same functions they would use for any other ERC-20.

IERC20 nvda = IERC20(NVDA_TOKEN_ADDRESS);

uint256 balance = nvda.balanceOf(user);
nvda.approve(spender, amount);
nvda.transfer(recipient, amount);

The wrinkle is corporate actions. Stocks split. Dividends happen. The economic relationship between one token and one underlying share can change.

Stock Tokens implement ERC-8056, the Scaled UI Amount extension. Raw token balances stay stable for contracts. A UI multiplier is how wallets and apps display the share-equivalent amount.

interface IScaledUIAmount {
    function uiMultiplier() external view returns (uint256);
    function balanceOfUI(address account) external view returns (uint256);
    function totalSupplyUI() external view returns (uint256);
    function newUIMultiplier() external view returns (uint256);
    function effectiveAt() external view returns (uint256);
}

The display conversion is:

underlyingShares = rawBalance * uiMultiplier / 1e18;

Why not just mutate balances after a split?

Because contracts depend on stable accounting. If my basket contract holds a raw token balance, I don't want a display-level corporate action to unexpectedly rewrite the reserve math inside the contract. The UI can show share-equivalent amounts, and the protocol can keep using raw ERC-20 units.

The basket contract does only a few things

The sample app has two contracts and no owner.

Contract	Role	Control surface
`BasketFactory`	Deploys and records baskets	Permissionless
`BasketToken`	Holds components, mints, redeems, prices shares	No owner or upgrade path

The factory does not custody user funds. It deploys a basket and records the address.

function createBasket(
    string calldata name,
    string calldata symbol,
    BasketToken.Component[] calldata components,
    uint256 maxPriceAge
) external returns (address basket) {
    basket = address(new BasketToken(name, symbol, components, maxPriceAge));
    _baskets.push(basket);
    isBasket[basket] = true;
    emit BasketCreated(basket, msg.sender, name, symbol);
}

Each basket stores a fixed list of components. A component is a token, a price feed, and the amount of that token backing one basket share.

struct Component {
    address token;
    address feed;
    uint256 unitsPerShare;
}

A price feed is an external data source a contract or app can read. In this app, the feeds come from Chainlink, an oracle network that publishes market data onchain. An oracle is the bridge between offchain facts, like a stock price, and onchain code.

On mainnet, the production chain where real assets move, the demo basket uses TSLA, NVDA, and AAPL Stock Tokens with their Chainlink feeds:

function _mainnetComponents()
    internal
    pure
    returns (BasketToken.Component[] memory c)
{
    c = new BasketToken.Component[](3);
    c[0] = BasketToken.Component(MAINNET_TSLA, MAINNET_TSLA_FEED, 0.4e18);
    c[1] = BasketToken.Component(MAINNET_NVDA, MAINNET_NVDA_FEED, 0.3e18);
    c[2] = BasketToken.Component(MAINNET_AAPL, MAINNET_AAPL_FEED, 0.3e18);
}

One TRIO share is backed by 0.4 TSLA, 0.3 NVDA, and 0.3 AAPL.

On testnet, which is a staging chain with no real funds at risk, the demo uses faucet Stock Tokens for TSLA, AMZN, and NFLX with mock feeds. A faucet is a service that gives you test tokens so you can build without spending real money.

Minting follows the ERC-20 approval pattern

From the frontend, minting is two steps: approve each component token, then call the basket.

await writeContract({
  address: stockTokenAddress,
  abi: erc20Abi,
  functionName: "approve",
  args: [basketAddress, amount],
});

await writeContract({
  address: basketAddress,
  abi: basketTokenAbi,
  functionName: "mint",
  args: [shares, account],
});

That writeContract call is from wagmi, a React library for wallet connections and contract writes. viem is the TypeScript Ethereum client underneath it for typed reads, writes, and transaction handling.

Onchain, the basket pulls the required component amounts and mints shares in the same transaction.

function mint(uint256 shares, address to) external nonReentrant {
    if (shares == 0) revert ZeroShares();

    uint256 count = _components.length;
    for (uint256 i = 0; i < count; i++) {
        Component memory c = _components[i];
        uint256 amount = Math.mulDiv(
            c.unitsPerShare,
            shares,
            SHARE_UNIT,
            Math.Rounding.Ceil
        );

        IERC20(c.token).safeTransferFrom(msg.sender, address(this), amount);
    }

    _mint(to, shares);
    emit Minted(msg.sender, to, shares);
}

The rounding direction matters. Mint rounds up so a user cannot underpay the basket reserves by tiny decimal leftovers.

Redeem is the mirror image. Burn first, transfer components out, and round down so the reserves cannot be overdrawn.

function redeem(uint256 shares, address to) external nonReentrant {
    if (shares == 0) revert ZeroShares();
    if (to == address(0)) revert ZeroAddress();

    _burn(msg.sender, shares);

    uint256 count = _components.length;
    for (uint256 i = 0; i < count; i++) {
        Component memory c = _components[i];
        uint256 amount = Math.mulDiv(
            c.unitsPerShare,
            shares,
            SHARE_UNIT,
            Math.Rounding.Floor
        );

        IERC20(c.token).safeTransfer(to, amount);
    }

    emit Redeemed(msg.sender, to, shares);
}

Redeem skips the price feed and the factory. It burns shares and returns the component tokens the contract already holds.

I keep pricing and redemption apart on purpose. You use the price for the UI. Redeem returns the collateral.

Local to mainnet is the path I want rehearsed

The repo gives you the whole loop.

git clone --recurse-submodules https://github.com/hummusonrails/robinhood-chain-dapp-example.git
cd robinhood-chain-dapp-example

pnpm install
anvil
pnpm run deploy:local
pnpm run smoke
pnpm run dev

anvil is Foundry's local development chain. Think of it as a throwaway local server for contracts. The local deploy creates mock Stock Tokens, mock Chainlink feeds, the factory, and a demo Tech Trio basket. It also writes apps/frontend/.env.local, so the frontend knows which addresses to call.

For Robinhood Chain testnet:

PRIVATE_KEY=$YOUR_TESTNET_KEY pnpm run deploy:testnet

One Foundry script handles local, testnet, and mainnet by checking the chainid, which is the chain's network identifier.

function run() external {
    vm.startBroadcast();

    BasketFactory factory = new BasketFactory();
    console2.log("FACTORY=%s", address(factory));

    BasketToken.Component[] memory components;
    if (block.chainid == 4663) {
        components = _mainnetComponents();
    } else if (block.chainid == 46630) {
        components = _testnetComponents();
    } else {
        components = _localComponents();
    }

    address basket =
        factory.createBasket("Tech Trio", "TRIO", components, MAX_PRICE_AGE);

    console2.log("DEMO_BASKET=%s", basket);
    console2.log("CHAIN_ID=%s", block.chainid);

    vm.stopBroadcast();
}

The testnet deployment behind the live walkthrough is:

Contract	Address
`BasketFactory`	`0xC1940D5fd58ce735A44a53f910852B12250F6a14`
`BasketToken` (`TRIO`)	`0x7633e0920Ea46A8Ec54F61C95adECD391c01Edd4`

Before spending mainnet gas, I want fork tests. A fork test runs tests against a local copy of live chain state, so you can check integration assumptions without sending real transactions.

pnpm run test:contracts
pnpm run test:fork

Here is the shape of the fork test:

function test_mintAndRedeem_withRealStockTokens() public {
    deal(TSLA, alice, 1e18);
    deal(NVDA, alice, 1e18);
    deal(AAPL, alice, 1e18);

    vm.startPrank(alice);
    IERC20Metadata(TSLA).approve(address(basket), type(uint256).max);
    IERC20Metadata(NVDA).approve(address(basket), type(uint256).max);
    IERC20Metadata(AAPL).approve(address(basket), type(uint256).max);

    basket.mint(2e18, alice);
    assertEq(basket.balanceOf(alice), 2e18);
    assertEq(IERC20Metadata(TSLA).balanceOf(address(basket)), 0.8e18);

    basket.redeem(2e18, alice);
    assertEq(basket.totalSupply(), 0);
    assertEq(IERC20Metadata(TSLA).balanceOf(alice), 1e18);
    vm.stopPrank();
}

That is the development loop I want for this kind of app: mocks for speed, testnet for wallet flow, fork tests for live integration assumptions, and mainnet only after the path is rehearsed.

A block explorer, which is basically hosted request logs for a chain, then gives you a way to inspect deployed contracts and transactions. The testnet contracts are verified on Blockscout, so you can read the source and calls after deployment.

Stock Tokens change the app assumptions

Stock Tokens still fit the ERC-20 interface, but the surrounding assumptions are different from a generic token.

For user balances, don't blindly show balanceOf. Use balanceOfUI or apply uiMultiplier so the user sees the share-equivalent amount.

For prices, read the per-token Chainlink feed on mainnet. For corporate actions, track multiplier updates and pending effective times. For valuation, remember that the feed price already includes the multiplier.

Stock market hours matter too. Crypto feeds may update around the clock. Stock feeds follow market sessions, so stale data checks need to reflect that.

The exit path is the one I care about most. If a user wants to redeem their basket share, I don't want that flow blocked because an oracle read is stale. The contract already holds the component tokens. Redemption should return the collateral.

Learn the chain later; start with the app

Robinhood Chain runs on Arbitrum Nitro, the same underlying technology as Arbitrum One, deployed as a dedicated chain. Arbitrum One is the public shared L2. A custom Arbitrum Chain gives a team its own execution environment while keeping the Ethereum-style contract model.

The mechanics under the hood are also why the fees are small. Transactions hit a sequencer, which is the service that orders transactions for the rollup, land in fast blocks, get batched, and settle back to Ethereum using blob data. The fee combines L2 execution gas with the data cost on L1, which is Ethereum itself.

That's useful context, but I wouldn't start by trying to absorb the whole chain architecture.

Start with the working system. Read a Stock Token balance. Approve a token. Mint a share. Redeem it. Check the price feed. Run the fork test. Look at the transaction in a block explorer.

Plenty of apps can live on Robinhood Chain. This basket is a good first build because it touches the surfaces most apps using market assets will need: token reads, approvals, ERC-8056 display logic, Chainlink feeds, local mocks, testnet deployment, verified contracts, fork tests, and a Next.js frontend using wagmi and viem.

What I learned from building it is where the real work sits: deciding where accounting belongs, where pricing belongs, and which assumptions deserve a test before real users and real assets touch the contract. The app stack itself is familiar.

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-807'); 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-818'); 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-676'); 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 🗽