Prizes and Bounties

Arkiv builds Web3 databases. It merges the guarantees of a blockchain with the convenience of a traditional database. Data lives in entities: records with typed attributes you can query and filter with real operators, not just a key you fetch by id. Every entity is owned by the wallet that signed it and carries an expiration date you choose; once it expires it stops showing up in queries, and you can renew it before that with a lifetime extension. Built for Ethereum, powered by GLM.

What Arkiv is not, worth reading before you pick it

It is not file storage. It does not replace IPFS, Arweave or S3, and large files do not go on Arkiv. Think of it as the index over your data rather than the place your data lives: leave the file where it is and put an Arkiv entity beside it, a hash, a URL or a CID, plus the typed attributes you actually want to search on. Your queries hit the index; the bytes stay where they belong. If you need to split something bigger across entities there is a parent-and-chunks pattern: find them on site and they walk you through it.

It is not a confidentiality layer. Entities are public and verifiable by design, so secrets and personal data stay out. Store a hash or a commitment instead, or encrypt your own data before it goes in.

Why it is worth your weekend

Arkiv is an early product and they say so: they are coming to Rome to find the issues in the docs, the faucet, the API keys, the SDK, the features and the explorer, and 40 people using all of it at once is the best test they can get. That is why every entry files a feedback report, and why it is worth a quarter of the score: what worked, what got in your way, what they should improve, with specific examples and, where it applies, the steps to reproduce. If you like being the person who finds the edge, this is the bounty for you.

Their Friday session leaves you with a draft /arkiv/schema.md for your own project. Twenty minutes, and your data model is done.

Mission 01. Decommission · $500

Done when your app answers, from Arkiv, a question it answers today through a subgraph, Ponder or a Postgres pipeline, and its read path no longer calls the indexer.

The decision that decides it: what goes in attributes, which you can query, versus what goes in the payload, which you cannot. Get it wrong and every query turns into a scan. Aim for a compound filter, not single-attribute equality.

They check: they run your query and see the question answered, and you link the commit from before the migration. You never have to prove a hosted service is switched off. If you did not arrive with an indexer already running, pick another mission rather than inventing one to turn off. If you did, that is a pre-existing project under the ETHRome rules: say so in your submission, and only the new part gets judged.

Mission 02. Built to expire · $500

Done when something in your app changes because data expired on its own, not because a job deleted it. Expiration is the feature, not an add-on.

Two patterns: let an entity lapse and treat its absence as the signal, or extend it on activity, which gives you a lease, a sliding expiry that nothing has to maintain.

They check: the same query before and after the boundary, with no delete call in between. Keep lifetimes at seconds or a couple of minutes, because nobody can wait on Sunday morning. A recording made on Saturday counts.

Mission 03. Live wire · $500

Done when your app updates from a subscription rather than from a refresh loop of your own.

Know this before you pick it: the SDK's subscribe helper only opens a real socket if your client uses a websocket transport. With an HTTP transport it quietly polls once a second and the code looks identical. Passing a start block to replay history forces polling too, so the backfill you reach for after a dropped connection is the very thing that turns your subscription back into a loop. Working that out is the mission; put what you find in your feedback report.

Where to look: the Arkiv WebSocket endpoint is in their network reference, and they point at event subscriptions with viem as the recipe: filter the events your app needs and update the UI from the stream, with no polling loop.

They check: the line where you build the client, showing a websocket transport, and your live subscription with no start block. A two-wallet demo on its own cannot tell a socket from a poll, so they need both: the code and the demo (one of you writes, the other's screen updates without a refresh), plus a few lines on what happened when you dropped the connection.

To qualify

How they score, one ranking for everything

The same four criteria apply to all three missions and to Best Use of Arkiv. Only entries that qualified get scored, and this single ranking decides Best Use of Arkiv and, within each mission, who takes its $500. Arkiv updated these weights on Saturday 12 September, on their ETHRome page.

How winners get paid

Prizes are paid directly by the Arkiv team (Golem Factory GmbH) as a grant for delivered open-source work. ETHRome handles no part of it.

Everything you need to start

Swarm is a decentralised storage and communication network run by peer to peer Bee nodes. You upload data and get back a content hash, a permanent address derived from the bytes themselves, and anyone with that hash can retrieve the content from any Bee node or public gateway. Data can be encrypted so only the people you grant access to can read it. Storage is paid for directly with a postage batch rather than rented from a platform, so the data stays yours: no origin server, no platform account, no company sitting between your users and their files.

Why it is worth your weekend

Swarm is data infrastructure, so it plugs into whatever you were already planning to build rather than competing with it. Build the project you actually came to build, then put its data on Swarm. They would rather see one thing working well than five things half built.

• Already using cloud storage? Put that data on Swarm and your users hold it rather than rent it.
• Building with AI? Put the agent's memory on Swarm, readable from any device and any app the user permits, instead of living inside one provider.
• Working on privacy? Encrypt it, grant and revoke access by key, and keep it retrievable from any node for as long as its postage batch is paid.

Directions they find interesting: portable AI memory that moves between assistants, provenance for AI output through content addressing, agent coordination over Swarm feeds, a knowledge base you own and query with an LLM, publishing that stays up. Plenty of good ideas have nothing to do with AI and are just as welcome: encrypted file sharing, a social feed, a media gallery where the uploader owns the data.

The fast path in: Swarm ID

Normally, uploading to Swarm means running a funded Bee node and buying a postage stamp, which means acquiring xBZZ and xDAI on Gnosis Chain before you have built anything. Swarm ID takes that off your critical path. It is a cross browser identity layer for Swarm apps: your users sign in with a passkey or an Ethereum account, then upload and sync across devices under one account. Crucially for a hackathon, there is no Bee node to run. Swarm ID signs postage stamps in the browser and reads batch state straight from the chain, so your app reaches Swarm through a public gateway and there is nothing to install before you write code.

To qualify

How they judge, in order

As a sketch of two different ways to win: the app they would most want to keep using, and the most inventive use of Swarm itself. Whichever two are strongest win.

After the weekend

The Swarm Foundation is interested in projects worth continuing, not just demos. If something promising comes out of the weekend they will talk to the team afterwards about how to support it, and a grant conversation is one of the options on the table.

Everything you need to start

Team1 Italy helps builders turn ideas into demonstrable onchain products. At ETHRome they are after one thing: a tight problem, a working Avalanche build, and proof that it runs. A public repo, a live demo, real onchain activity. Not a pitch.

You do not need any prior Avalanche experience. A focused project deployed on Fuji testnet is a valid submission, and both tracks are cut to fit a two day build window rather than a quarter of engineering.

Track A. Stablecoins That Do Real Work · $600

Build a stablecoin product that solves a real workflow: payments, payroll, treasury management, savings, yield or risk UX, cross-chain onboarding, automated settlement.

Your project has to demonstrate one complete user flow, from action to onchain proof. In their words, another generic swap interface will not qualify.

1st place $400 · 2nd place $200

Track B. Tokenized Assets: Rules to Settlement · $400

Build a prototype for issuing, transferring, settling or managing a tokenized financial asset, using test data and test assets. An invoice, a fund unit, a revenue share, a ticket, a collateral claim, or any other financial right with a clear lifecycle.

Your build has to show an asset rule, an eligibility or transfer policy, and settlement or payment logic. In their words, a landing page or a dashboard without an end-to-end onchain flow will not qualify.

1st place $300 · 2nd place $100

To qualify, in both tracks

How they judge

On close calls they lean towards projects that use native Avalanche interoperability, token-transfer, privacy or policy-enforcement primitives. They are explicit that these are optional enhancements and not baseline requirements, so bolting one on to chase points is not the move.

Everything you need to start

ENS is the Ethereum Name Service. This bounty is not about the ENS you already know: it is about ENSv2, the next evolution of the protocol, live in beta on Sepolia. It introduces hierarchical registries, enhanced role based permissions, per account resolvers and programmable subname infrastructure.

What to build

A functional project that uses ENSv2 as a core part of its architecture. It can go after any of the three ETHRome directions, AI, Finance or Privacy, but the ENS side of it has to run on the ENSv2 beta deployment on Sepolia.

Directions they find interesting, as examples rather than restrictions:

• A custom subname registry for users, applications or communities.
• Names and profiles for AI agents inside an agent controlled namespace.
• Rentable, permissioned or unruggable subname systems.
• ENSv2 roles used to delegate management of names, records or subnames.
• Financial applications built around named accounts, payment profiles or contracts.
• Experiments with per account resolvers, record permissions or record aliasing.
• Privacy aware identity or payment systems using custom resolvers.
• ENSv2 migration, indexing, monitoring or developer tooling.

What they are asking for, in one line: show them what becomes possible when every ENS name can operate its own programmable registry.

To qualify

How they judge, in order of weight

Prize and payment

Up to five projects take a share of the $500 pool. ENS picks the winners and the ENS team handles the payout directly, like every sponsor on this page. Tick ENS in the submission form to be considered.

Everything you need to start