Is your project ready for Arbitrum Open House? A founder's self-assessment.

You’re thinking about applying to Arbitrum Open House. Maybe you’ve read about the evaluation criteria. Maybe you’ve seen all of our amazing community partners. But before you start filling out the application, there’s a more useful question: can you pass the same test the judges will give you?

This is the companion to our piece on how Open House submissions are evaluated. That article explains the framework from the reviewer’s side.

This one puts you in the chair. If you can answer the questions below with substance and specificity, you’re in good shape. If you find yourself reaching for vague answers, that’s a signal to take a step back and think a bit on it.

Can you demo your product right now?

Open your MVP, your initial idea sketch, or the rough notes on a napkin you wrote down right now. Can someone who has never seen your project understand what it does in under two minutes? That’s the test.

Judges open your repo and your demo before they read your pitch. If the demo doesn’t work, or if it only works on your local machine with a specific wallet configuration, the rest of your submission barely matters. A polished slide deck with a broken product loses to a rough slide deck with a working one every time.

What a strong answer looks like: you have a deployed contract on Arbitrum (mainnet, Sepolia, or your own Arbitrum chain) and a frontend or interface someone can interact with without your help.

If your project isn’t deployed on an Arbitrum chain, stop here. That’s a hard eligibility requirement, not a soft preference. You need to fix that before anything else. If you haven’t explored your deployment options yet, the gentle introduction to launching an Arbitrum chain is a starting point.

Can you explain why this needs to exist on Arbitrum?

This is where most teams give answers that sound reasonable but aren’t specific. “We chose Arbitrum because of low fees” may not be enough.

A strong answer connects your product’s architecture to something about the Arbitrum stack that you’re actually using. Maybe you wrote performance-sensitive logic in Stylus because Solidity couldn’t handle the precision you needed. Maybe your product composes with existing Arbitrum DeFi liquidity in a way that wouldn’t work on a chain with thinner markets. Maybe you’re using Timeboost for time-sensitive execution. Maybe you’re running your own Arbitrum chain because your use case needs a dedicated block space.

If you strip the word “Arbitrum” from your application and it reads the same, that’s a problem. Judges are looking for projects that understand the ecosystem, not just the EVM.

Does your project fit one of the focus sectors?

There are some sectors where we see the strongest builder momentum and where Arbitrum has clear technical advantages: payments and stablecoins, DeFi, RWAs, privacy, consumer products, and Arbitrum-native tooling.

Each sector comes with specific expectations. In DeFi, judges want user-facing financial products, not standalone protocols or wrapped aggregators. In payments, they want products where stablecoins feel like local money to the end user, not products that expose crypto complexity. In privacy, they want products people would actually adopt, not abstract ZK primitives without a user story.

If your project falls outside these categories, that doesn’t disqualify you. But you’ll need it show to the judges the momentum and user traction in the space you’re building. If it does fit one of these sectors, make sure your submission speaks the language of what good looks like in that specific area, not in web3 generally.

Can you articulate what’s different about your approach?

Most teams can identify a problem. That’s the easy part. The question is whether your solution offers something the market doesn’t already have, and whether you can explain that clearly.

A strong answer here: “There are three products doing X on Arbitrum. They all approach it through Y. We’re doing Z because [specific technical or product reason], and here’s why that matters for users.” A weak answer: “We’re building a better version of X.”

Judges are checking for differentiation. They know the Arbitrum ecosystem well enough to spot when a submission is a thin wrapper around an existing protocol or a feature request dressed up as a product. The strongest submissions identify a gap that’s specific to their sector and propose something concrete to fill it.

Will you keep building after the event?

This is the tiebreaker between two teams with similar execution and product quality. Judges look for evidence that your project has a life beyond the hackathon.

Ask yourself: Is your GitHub active outside of the submission window? Have you published anything about the project, a blog post, a thread, documentation? Do you have users or a waitlist? Is there a roadmap that looks like a plan rather than a wish list?

If your repo goes quiet after submission and picks up again the day before judging, that tells a story. If your commit history shows consistent work over weeks, that tells a different one. Judges are trying to predict which teams will still be building in six months. Give them something to base that prediction on.

The honest self-assessment

Here’s the summary. If you can answer all five of these with confidence and specifics, apply:

• Can you demo a working product deployed on an Arbitrum chain?
• Do you have a concrete reason you’re building on Arbitrum beyond generic L2 benefits?
• Do you understand what good looks like for a project in the sector you’re building in?
• Can you name what makes your approach different from existing alternatives?
• Is there evidence you’ll keep building beyond the event? If two or more of those answers feel shaky, that’s not a rejection. It’s a build list. Spend the time between now and the deadline closing the gaps, then submit something that actually represents your capabilities.

Open House is designed to find teams that will keep building. The application process rewards founders who show up with a clear product thesis, working software, and a reason to be on Arbitrum. If that describes you, there’s an entry point right now.

The NYC buildathon is live, the NYC Founder House is coming up, and Dubai registration is open with the buildathon running April 23 to May 14 and the Founder House May 28 to 31.

For a detailed breakdown of the evaluation criteria from the reviewer’s perspective, read the companion article here on X:

Apply at openhouse.arbitrum.io.