Streamr Network Hackathons: Building Real-World Data Apps

Streamr is a decentralized network for real-time data. Its core idea is that people, companies and devices can publish a stream of data, such as sensor readings, market prices, traffic feeds or video, and other parties can subscribe to it without depending on one central server to relay everything. The network is run by independent node operators, and the project uses the DATA token as part of its ecosystem, which is why you will still see DATA mentioned in older announcements.

For hackathons, this matters because the network gives builders a ready-made way to move live information between a source and an application. A team does not need to build its own message broker or data pipeline from scratch just to show a working demo. Earlier Streamr calls for builders were often framed around open data, so many projects were data-heavy and aimed at public audiences.

The Streamr 1.0 mainnet went live in March 2024, according to the project's blog. That milestone is a reason older guides about testnets or early network versions may no longer match what you see today. If you are reading an old event page, check which network version and tooling it expects before you write any code.

A hackathon on Streamr is therefore best understood as a time-boxed challenge to build something that uses real-time data flows in a useful way. The network is the infrastructure. The judged part is the application you build on top of it and whether it solves a problem someone actually has.

Streamr uses a publish and subscribe model. A stream is a named channel of messages. A publisher sends messages into the stream, and any subscriber who is allowed to read it receives them as they arrive. This is different from a database you query on demand. The data moves to the people and programs that need it.

The main parts you will work with are:

• Streams, which carry the messages and can be public or restricted by permissions.
• Publishers, which are your scripts or devices that send data in a defined format.
• Subscribers, which are your applications, dashboards or alert services that react to incoming messages.
• Nodes, which relay and store messages across the network. Node operators are a separate group from your team.

The project provides client libraries and tools for creating streams and sending data from code. The exact commands and function names change over time, so use the current developer documentation rather than copying snippets from older posts.

For a hackathon, the practical question is latency and reliability. Ask how quickly your subscriber needs to see new data, what happens if the publisher goes offline, and whether a subscriber that connects late can catch up. Answer these in your README. Judges often reward teams who test a failure case, such as a dropped feed, because it shows the project will still work outside a demo.

Looking at earlier calls helps you understand what organisers tend to value. Streamr has run several community programs, and the details of each one are documented on its blog. The table below summarises the general focus of a few, based on the public posts found for this topic. Check each post for its own rules, because the terms of past events do not carry over to new ones.

Program	What it asked for	Lesson for builders
StreamTeam (2022)	A monthly bounty competition rewarding help with finding users, builders and new use cases	Adoption work and clear community contributions count as much as code
Open Data Challenge (2023)	Developers streaming open data sources to The Hub in real time	Real, public data feeds with a clear use case stand out
Data challenge roundups	Summaries of submitted projects and what worked	Judges look for documented, reproducible results

The common thread is a preference for live data, visible usefulness and documentation that other people can follow. Past calls rewarded projects that could be explained in a few sentences and demonstrated quickly.

If an event you are considering has no written rules, judging criteria or prize terms, treat that as a warning sign. Ask the organisers before you start. A well-run challenge publishes its scope, timeline and eligibility rules clearly.

Streaming networks are most useful where information changes often and many people need to see it at once. Good hackathon problems usually share three features: the data is produced continuously, more than one party benefits from seeing it, and a delay of minutes or hours makes it less valuable.

Some areas that fit this pattern include:

• Environmental monitoring, such as air quality or river level sensors shared with a community
• Transport and logistics, such as vehicle position feeds or delivery status updates
• Energy, such as local metering data or grid alerts for small operators
• Public-sector open data, such as traffic counts, weather or transit timetables
• Supply chain tracking, where batches or shipments need timely status signals
• Community safety or civic alerts, where verified updates need to reach many subscribers quickly

Areas that fit poorly include problems where the data is static, rarely changes, or cannot legally be shared. A project that streams a dataset once a year is a file transfer with extra steps, and judges will notice.

When you compare ideas, ask who the user is, what decision they make with the data, and how their life gets better if the information arrives faster. A problem with a named user and a clear decision is easier to judge and easier to demonstrate than a general platform.

Most hackathon projects fail because the scope is too large for the time available, not because the idea is weak. Use the following steps to choose a problem you can finish.

1. Name one user. Write a single sentence describing who would use the output and what they would do differently.
2. Identify one data source. Confirm that you can access it legally and that its terms allow republishing or demonstration use.
3. Define one output. This might be a live chart, an alert, or a map that updates. Avoid planning more than one main output.
4. Set a test plan. Decide how you will generate test data if the live feed is slow, expensive or unavailable during the event.
5. Write what you will not build. A short list of excluded features protects your deadline.

Check whether the source has usage limits or costs. If a feed requires a paid key, budget for it or choose a free alternative. Do not plan a demo that depends on a service you cannot keep running after the event.

Finally, test your idea with a rough sketch. If you cannot draw the flow from source to stream to subscriber on one page, the scope is still too wide. Cut until the diagram fits on one page and every box has a reason to exist.

The build usually follows a simple path. The steps below describe the general approach rather than exact commands, because tooling changes and you should follow the current official documentation.

1. Set up an account and the development environment described in the project's current docs.
2. Create a stream for your data source. Give it a clear name and description so other people can understand it.
3. Define the message format. Use consistent field names, units and timestamps. Document the format in your README.
4. Write a publisher. Start with test data that matches the real format. Once it works, connect the live source.
5. Write a subscriber that reads the stream, handles missing or late messages, and performs one useful action.
6. Add a simple interface, such as a dashboard, a table or an alert, so a judge can see the result without reading code.
7. Record a short walkthrough that shows the data moving from source to subscriber.

Keep the publisher and subscriber in separate scripts. This makes it easier to test each part and to explain the architecture. Log timestamps at both ends so you can measure how long messages take to arrive.

Run the whole setup from a clean environment before submitting. If a judge cannot reproduce your demo from the README, the project will be scored as incomplete even if it worked on your own machine.

Judging criteria differ between events, so read the official rules first. Across most data challenges, the same qualities tend to matter.

• A working demo that runs from start to finish without manual fixes during the presentation
• A real problem with a named user and a specific benefit
• A legitimate data source with clear permissions and attribution
• Clear documentation, including setup steps, architecture and known limits
• Reliability thinking, such as what happens when a feed drops or a subscriber reconnects
• Honest claims. Say what the prototype does and does not do
• A realistic plan for what happens after the event, including who maintains the feed

Teams often lose points by overstating. A demo that claims to serve thousands of users when it has been tested with one feed will not impress experienced judges. A smaller project with clear measurements of latency and accuracy is more convincing.

Submit a short written summary that a non-technical reader can follow. Include the problem, the user, the data source, the stream design, the result and the next steps. Keep the summary under a page so it can be read quickly.

If your project uses a token or prize mechanism, say how it works in plain terms. Judges will look for evidence that the project's value comes from its use, not from the token itself.

Because public reporting and third-party listings can go stale, verify any event directly with the organiser. A checklist helps you avoid wasting time on closed or unofficial calls.

• Look for an announcement on the official Streamr blog or the organiser's own channels, and confirm the dates and rules there.
• Check that the event names Streamr Network explicitly and states how submissions are made.
• Read the eligibility section. Some events limit participation by country, age or residency, and some have restrictions on how prizes are paid.
• Look for a clear judging panel or method and a published results page from an earlier round if one exists.
• Be wary of messages that ask you to send funds, share private keys or connect a wallet to a site you have not verified. Legitimate hackathons do not need access to your funds to take part.

If a prize is paid in a crypto token, check whether receiving or trading that token is allowed where you live, and whether you need to report it for tax. Rules on crypto vary by country and change over time, so check current local guidance.

If you cannot confirm an event through official channels, treat it as unverified and do not share personal details or credentials.

Several mistakes appear again and again in data-network hackathons. Avoiding them will save time and improve how judges see your work.

• Starting with the token. A project that opens with price talk rather than the user's problem is hard to judge as a product.
• Over-scoping. Trying to combine several data sources, dashboards and features in one submission usually leaves each part half finished.
• Ignoring data rights. Republishing data without checking its licence can make a demo impossible to show publicly.
• Relying on a single live feed. If the source goes down during judging, the project looks broken. Prepare recorded or simulated data as a backup.
• Hardcoding keys. Put credentials in environment variables or a secrets manager, not in the code you publish. If a key is exposed, revoke it and create a new one.
• Skipping latency tests. Real-time claims need measurements. Record how long messages take to travel from publisher to subscriber.
• No reconnect logic. Subscribers that cannot recover after a dropped connection are a common failure in live demos.
• Unclear documentation. A README that assumes knowledge the judge does not have will count against the project.

A practical rule is to make the project boring to run and interesting to use. Reliable setup, clear steps and a single convincing outcome will do more for a submission than a long list of features.