DEV Community: Ben Greenberg

Quick tip: canonical URLs prevent silent SEO damage

Ben Greenberg — Fri, 03 Apr 2026 11:00:16 +0000

Quick tip on SEO:

If your site is accessible at both https://example.com and https://www.example.com, Google sees two different sites and splits your ranking signals between them.

Fix: add a canonical tag to every page:

<link rel="canonical" href="https://example.com/page" />

Check if yours is set correctly — the free audit tool at https://audit.hummusonrails.com/free checks canonical tags along with 4 other key issues.

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.

The readability scores your content tool is missing

Ben Greenberg — Tue, 31 Mar 2026 06:00:28 +0000

The Readability Scores Your Content Tool Is Missing

Most readability tooling stops at a single score. That is a problem if you are building a documentation pipeline, a content linter, or any system that needs to catch unreadable text before it ships.

Here are the four metrics worth tracking, what each one actually measures, and what your targets should be.

Flesch-Kincaid Grade Level

This score maps text to a U.S. school grade level based on two inputs: average sentence length and average word length in syllables. A score of 8 means a typical 13-year-old can read it without friction.

Target: 6 to 9 for most technical docs.

If your score is above 12, sentences are too long or you are leaning on polysyllabic jargon. Users will skim past dense paragraphs instead of reading them. If your score is below 5, you are likely oversimplifying to the point where context is missing.

Flesch Reading Ease

This uses the same inputs as FK Grade Level but outputs an inverse score on a 0 to 100 scale. Higher means easier. It weights sentence length more heavily than syllable count, so it punishes run-on sentences hard.

Target: 60 to 70 for technical documentation.

Below 50 and you are in academic or legal territory. Most readers will not finish the section. Above 75 and you may be losing precision, which matters in technical writing where exact phrasing carries meaning. The 60 to 70 range is the practical sweet spot where clarity and accuracy coexist.

Automated Readability Index (ARI)

ARI takes a different approach. Instead of counting syllables, it counts characters per word. This makes it faster to compute and less sensitive to syllabification edge cases. It outputs a grade-level score similar to FK but often diverges on technical content, where long words are common but not necessarily difficult for the target audience.

Target: 7 to 10 for developer docs.

Where ARI earns its place is as a cross-check. If FK says grade 8 but ARI says grade 14, you likely have a cluster of long technical terms inflating the character count. That is worth reviewing even if the content reads fine to a subject matter expert, because new users will not have that context.

Sentence Length Variance

Most tools report average sentence length and stop there. Variance is the signal they miss. Text where every sentence is roughly the same length reads as monotonous and is harder to parse. Alternating short and long sentences creates rhythm, which keeps readers oriented.

Target: Standard deviation of 8 to 15 words across your sentence lengths.

Below 5 means your writing is flat. Above 20 means sentence structure is inconsistent in a way that will confuse automated parsers and human readers alike. This is especially relevant in procedural docs where scannable short sentences should anchor longer explanatory ones.

I built a TextAnalytics API that returns all of these scores in a single call -- useful if you are building a linter, a CMS plugin, or just want to quality-gate your content pipeline: https://rapidapi.com/ben-eI6jno4PU/api/textanalytics

Quick tip: Flesch-Kincaid Grade Level 8 is your target

Ben Greenberg — Fri, 27 Mar 2026 11:00:05 +0000

Quick tip on writing docs and content:

Flesch-Kincaid Grade Level 8 = readable by a 13-year-old. That's your target for most technical documentation.

Not because your readers are 13 — but because shorter sentences and common words reduce cognitive load. Even senior engineers read faster at grade 8.

Most enterprise docs sit at grade 14-16. That's why people skim them.

The TextAnalytics API returns FK grade level (plus 4 other readability scores) in a single call: https://rapidapi.com/ben-eI6jno4PU/api/textanalytics

I built a link preview API — here's what I learned about Open Graph

Ben Greenberg — Tue, 24 Mar 2026 07:01:41 +0000

I Built a Link Preview API — Here's What I Learned About Open Graph

Link previews seem simple until you actually build something that generates them reliably. I spent weeks digging into how platforms parse Open Graph metadata, and I kept running into the same category of problems: missing images, wrong fallbacks, cached bad data. Here is what surprised me.

What Link Previews Actually Are (And Why They Break)

When you paste a URL into Slack or Twitter, the platform fetches that page, reads the <meta> tags in the <head>, and renders a card. The Open Graph protocol, originally developed by Facebook, defines the standard tags most platforms follow: og:title, og:description, og:image, and og:url.

The reason previews break so often comes down to a few recurring patterns:

The og:image tag is missing entirely
The image URL is relative instead of absolute
The image dimensions are wrong and the platform rejects it silently
The metadata exists but the page blocks crawlers with a bad robots.txt or a JavaScript render wall

That last one is brutal. If your content is rendered client-side and you have no SSR or prerendering, most crawlers will fetch an empty shell and your preview will be blank.

The og:image Requirements Most Devs Skip

I see this constantly. Developers add an og:image tag, the preview still looks broken, and they cannot figure out why. The requirements are stricter than the documentation implies:

Dimensions should be 1200x630 pixels. Facebook and LinkedIn will downscale, but if you go too small (under 200x200) they ignore the image completely.
File size should stay under 1MB. Larger images may time out during the crawl window.
The URL must be absolute. /images/preview.png will not work. https://yourdomain.com/images/preview.png will.
No SVGs. Almost no platform will render an SVG as a preview image. Use PNG or JPEG.

How Twitter Cards Differ From Open Graph

Twitter does read OG tags as a fallback, but it has its own system called Twitter Cards, and the twitter:card type changes how everything renders.

The two types you actually care about are summary and summary_large_image. If you use summary, Twitter shows a small thumbnail beside the text. If you use summary_large_image, you get the full-width banner image. Most developers want the large image but forget to set the tag, so they get the small thumbnail and wonder why it looks wrong compared to LinkedIn.

You also need twitter:title and twitter:description even if you already have the OG equivalents. Twitter will use OG as a fallback, but being explicit is more reliable.

The og:description Fallback Chain

When og:description is missing, platforms do not just leave it blank. The fallback chain typically goes:

og:description meta tag
Standard meta name="description" tag
First paragraph of visible body text

Knowing this means you can usually ensure something reasonable shows up even on pages that have not been fully optimized.

The One Gotcha That Bit Me Hard

If og:url does not match the canonical URL of the page, platforms will cache the preview against the wrong URL. I had a staging URL leak into production metadata once and spent an embarrassing amount of time wondering why the preview was showing old content. Always set og:url explicitly to the canonical version.

Parsing all of this reliably across different platforms, redirect chains, and malformed HTML is exactly the kind of work that sounds quick and turns into a week of edge cases. I use what I built in production at LinkPreview API. It handles the messy parts of parsing OG data so you do not have to: https://rapidapi.com/ben-eI6jno4PU/api/linkpreview1

5 things your website is getting wrong (and how to check for free)

Ben Greenberg — Sun, 22 Mar 2026 21:51:15 +0000

Most websites fail basic technical hygiene checks. Not because developers don't care, but because these things are easy to miss when you're focused on shipping features. Here are five common issues worth fixing today.

1. Missing or Wrong Security Headers

Headers like Content-Security-Policy, X-Frame-Options, and Strict-Transport-Security (HSTS) protect your users from clickjacking, XSS attacks, and protocol downgrade attacks. Skipping them leaves real attack surface open. Browsers and security scanners will flag these absences, and some enterprise clients actively check before integrating with your API.

How to check: Run curl -I https://yourdomain.com and scan the response headers. Or paste your URL into securityheaders.com for a free graded report.

2. Open Graph Tags That Break Link Previews

When someone shares your link on Slack, LinkedIn, or Twitter, the platform reads your Open Graph meta tags to build the preview card. If og:title, og:image, or og:description are missing or misconfigured, the preview looks broken or empty. This tanks click-through rates on content you spent real time creating.

How to check: Use the OpenGraph.xyz previewer. Paste your URL and see exactly what Slack or LinkedIn will render. Fix any missing tags in your <head>.

3. No Canonical URL

If your page is reachable at both https://example.com/page and https://example.com/page?ref=newsletter, search engines may treat these as separate pages competing against each other. Over time this splits your ranking signals and can suppress both versions. A canonical tag tells crawlers which URL is the one that counts.

How to check: Open DevTools in Chrome, go to Elements, and search for canonical in the <head>. You should find something like <link rel="canonical" href="https://example.com/page" />. If it is missing or pointing to the wrong URL, fix it in your template.

4. Images Without Alt Text

Alt text is not optional. Screen readers rely on it for users with visual impairments, and search engine crawlers use it to understand image content. A page full of images with empty or missing alt attributes is both an accessibility failure and a missed SEO opportunity.

How to check: Run document.querySelectorAll('img:not([alt])') in the browser console. Any results mean you have untagged images. Axe DevTools (free browser extension) will also flag these automatically.

5. Missing Viewport Meta Tag

Without <meta name="viewport" content="width=device-width, initial-scale=1"> in your <head>, mobile browsers will render your page at desktop width and then scale it down. The result is a tiny, unreadable layout that frustrates users and tanks your Core Web Vitals scores.

How to check: Open DevTools, toggle the device toolbar (Ctrl+Shift+M), and load your page. If it renders like a shrunken desktop site, the viewport tag is probably missing. Check the Elements panel to confirm.

These five checks take maybe 15 minutes to run manually. If you want to do all of them in one go, I built a free tool that runs 5 key checks instantly, no signup, no waiting: https://audit.hummusonrails.com/free

Quick tip: your og:image should be 1200x630px

Ben Greenberg — Fri, 20 Mar 2026 12:00:10 +0000

Quick tip about link previews:

Your og:image should be 1200x630px. Most sites get this wrong — either wrong dimensions, an SVG (which many platforms reject), or a relative URL instead of absolute.

Check yours:

curl -s https://yoursite.com | grep 'og:image'

If you're building something that reads og:image from other sites, the LinkPreview API handles all the edge cases: https://rapidapi.com/ben-eI6jno4PU/api/linkpreview1

Quick tip: check your security headers with curl

Ben Greenberg — Wed, 18 Mar 2026 21:51:11 +0000

Quick tip for checking your security headers:

curl -I https://yoursite.com | grep -i 'x-frame\|content-security\|strict-transport\|x-content-type'

If you get no output, you're missing all of them. HSTS is the most important one to add first — it forces HTTPS on all future visits.

Want a full breakdown? Run a free check at https://audit.hummusonrails.com/free

I got tired of building the same link preview function, so I made it an API

Ben Greenberg — Sun, 15 Mar 2026 18:01:45 +0000

Every app I've built in the last few years has needed the same thing: paste a URL, show a preview card. Slack does it. Discord does it. Every CMS does it. And every time, I end up writing the same cheerio scraping code, handling the same edge cases with Open Graph tags, and debugging the same issue where Twitter Cards use name instead of property and half the internet gets it wrong.

A little while ago I finally extracted all of that into a standalone API and put it on RapidAPI. Figured other people are writing the same code too.

What it actually returns

You pass a URL. You get back structured metadata across six layers:

Open Graph (title, description, images with dimensions, article metadata)
Twitter Cards (card type, site, creator; only tags that are actually present, no fallback guessing)
HTML meta (title tag, meta description, canonical, theme color)
Icons (auto-selects the highest quality favicon with a priority chain)
Feeds (discovers RSS, Atom, and JSON Feed links)
JSON-LD (parses all script blocks, prefers Article/Product over BreadcrumbList)

The response gives you both a merged top-level view (where the title comes from whichever source has it; OG first, then Twitter, then the title tag) and the raw parsed layers, so you can do your own logic.

Here's what GitHub returns:

{
  "title": "GitHub · Build and ship software on a single, collaborative platform",
  "description": "Join the world's most widely adopted...",
  "image": {
    "url": "https://github.githubassets.com/images/modules/site/social-cards/campaign-social.png",
    "width": 1200,
    "height": 630
  },
  "favicon": "https://github.githubassets.com/favicons/favicon.svg",
  "siteName": "GitHub",
  "type": "website",
  "themeColor": "#1e2327",
  "openGraph": { ... },
  "twitter": { ... },
  "feeds": [],
  "jsonLd": { "@type": "WebSite", ... },
  "responseTime": 234
}

The parts that were annoying to get right

A few things I ran into while building this that I suspect anyone writing their own scraper will hit too:

OG tags use property, Twitter uses name. The Open Graph spec says <meta property="og:title">. Twitter Cards say <meta name="twitter:card">. But a surprising number of sites swap them. The parser checks both attributes for both prefixes.

Multiple og:image tags are valid. The OG spec supports arrays by repeating the tag. Structured properties like og:image:width apply to the most recently declared og:image. Most scrapers just grab the first one and ignore the rest.

JSON-LD blocks are a mess. A typical news article page has three or four JSON-LD blocks: a BreadcrumbList, an Organization, and then the actual Article buried in the third one. You need to parse all of them and pick the right one.

Favicons have a priority order. Apple touch icons at 180x180 are usually the highest quality. Then standard icons at 32x32, then the generic /favicon.ico fallback. Most implementations just grab the first <link rel="icon"> they find.

Relative URLs everywhere. OG images and feed links are often relative paths. You need the effective URL (after redirects) as the base to resolve them correctly.

The technical approach

It's a Fastify server running on a VPS, using cheerio for HTML parsing. No headless browser, no Puppeteer, just fetch the HTML and parse it. This keeps response times under 500ms for cache misses and under 5ms for cache hits.

SSRF protection was the part I spent the most time on. Since the API accepts arbitrary URLs from users, you need to prevent people from using it to probe internal networks. The server resolves the hostname first, checks the IP against a blocklist of private ranges, then connects directly to the resolved IP to prevent DNS rebinding attacks.

I also built a text analytics API while I was at it, using the same infrastructure but for a different purpose. Pass in text, get back readability scores (Flesch-Kincaid, Coleman-Liau, SMOG, and three others), keyword density, bigrams, trigrams, and reading time. All pure math on strings, sub-10ms responses. Useful for content optimization tools and writing assistants.

Try them

Both APIs are on RapidAPI with a free tier (500 requests/month):

LinkPreview — URL metadata extraction
TextAnalytics — readability scores, keyword density, text metrics

The free tier is enough to test and prototype with.

If you run into any edge cases the parser doesn't handle well, I'd genuinely like to know. Parsing the wild HTML of the internet is a forever project.

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.

OpenClaw Is Incredible. Setting It Up Shouldn't Require a CS Degree.

Ben Greenberg — Mon, 09 Feb 2026 17:29:54 +0000

If you've heard of OpenClaw, you know it's one of the most capable personal AI assistants available. It's open source. It runs on your own infrastructure. It's proactive: it reaches out to you with reminders, follow-ups, and check-ins instead of waiting for you to type a prompt. It has persistent memory, autonomous background tasks, and a growing skill ecosystem.

It's also a pain to set up if you're not technical.

Cloning repos. Managing API keys. Configuring Docker. Setting up Telegram bots. Provisioning a VPS. Maintaining security updates. For developers, that's a weekend project. For everyone else, it's a wall.

The gap between capability and accessibility

OpenClaw's target audience is technical users comfortable with CLI environments. That makes sense for an open-source project. But the people who would benefit most from a proactive AI assistant are often the people least equipped to deploy one.

Busy professionals who need an AI that checks in on their schedule. Freelancers who want accountability nudges. People who keep paying for ChatGPT but forget to open it. These aren't power users. They're the mainstream.

TapnClaw: managed OpenClaw in 5 minutes

I built TapnClaw to bridge that gap. It's a managed deployment layer for OpenClaw that reduces the entire setup to three steps:

Sign in with Google, pick a plan
Choose your AI model (Claude or ChatGPT)
Connect Telegram

Five minutes later, you have a dedicated server running OpenClaw with your chosen model, communicating through Telegram. No terminal. No config files. No documentation.

Everything OpenClaw does, zero infrastructure work

Your TapnClaw instance is a full OpenClaw deployment. That means you get:

Proactive messaging: This is OpenClaw's killer feature. Your assistant doesn't just respond to you. It reaches out on its own. Mention needing to book a flight? It checks in the next day. Tell it about a deadline? It follows up with an offer to help. It uses OpenClaw's heartbeat and cron system to learn your patterns and act on them.

Persistent memory: It remembers what you've talked about across every conversation. Context doesn't reset. It builds a profile of your preferences, goals, and patterns over time.

Autonomous tasks: Background task execution means it can work on things even when you're not actively chatting.

Private infrastructure: Each user gets an isolated, dedicated server. Not multi-tenant. Your conversations never leave your machine. Daily backups, automatic security updates, and full data deletion on cancellation.

What the experience actually looks like

Here's a real interaction pattern:

Assistant: You mentioned wanting to call the dentist this week. Remind you tomorrow?

You: Yes please, 10am!

Assistant: Done! I'll message you at 9:45am so you have time to prepare. Also, your flight to Denver is in 3 days. Check you in?

That proactive follow-up happens because OpenClaw's memory system retains context and its scheduling engine acts on it. TapnClaw just makes sure you never have to think about the infrastructure running it.

What it doesn't do

Being direct about boundaries:

Telegram only for now. Discord, WhatsApp, and Slack are on the roadmap.
Personal use, not designed for teams.
Managed hosting means no SSH access and no self-hosting option. If you want full control, deploy OpenClaw directly.

Pricing

$19.99/month or $14.99/month on quarterly billing. No AI markup. Setup fee waived on quarterly.

The thesis

OpenClaw proved that a proactive, memory-rich AI assistant is transformative. TapnClaw's bet is that removing the setup barrier makes that transformation accessible to everyone, not just the people comfortable with Docker and shell scripts.

Five minutes. Three steps. Your own private AI assistant.

tapnclaw.com

TapnClaw is powered by OpenClaw.

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.