Lisk Onchain Hackathon: A Guide for dApp Developers (2026)

Hackathon details change from one edition to the next, so start by confirming which event you are looking at. Lisk has run several developer events over the years, and the name of an event can be reused with different dates, prizes, tracks and eligibility rules.

Use the official event page as the primary source. Check these items before you commit time:

• The submission deadline and the time zone it uses
• Whether the event is open to individuals, teams or both, and the team size limit
• Which tracks exist, and whether a project can enter more than one
• Whether a deployed mainnet contract, a testnet deployment or only a repository is required
• How the judging is done, including any stages and any live demo requirements
• The rules on existing code, open-source licensing and intellectual property

Public reporting can point to pages from earlier events, community posts and unrelated projects that share a similar name. A repository or grant page from a previous year is useful background but should not be treated as the current rulebook. If an organiser changes a rule after you start, keep a dated copy of the version you built against.

Lisk moved its network design over time. In 2024 it announced a shift toward an OP Stack layer-2 that is part of the Optimism Superchain, and some public reporting describes Lisk attracting dApps to that network through grants. For a developer, the practical meaning is that the chain is EVM-compatible, so familiar Solidity contracts, Ethereum-style wallets and common libraries are a reasonable starting point.

Older Lisk material describes a JavaScript-based SDK and sidechain model. That material may still appear in public reporting, but it is not a safe guide to today's stack. Before writing code, read the current network documentation for RPC endpoints, chain IDs, bridge routes and block explorers.

One search result carried a headline about Lisk shutting down and asking users to bridge their funds. The results do not confirm that claim, and the snippet is not a primary source. Check the official Lisk channels and the network status before you plan a build, and avoid moving funds based on a headline alone. If you do bridge, use the official bridge and verify the destination address and chain ID first.

Read the full rules and note every requirement that affects your build. Some hackathons require open-source code, a demo video, a pitch deck, a short written description or a list of team members with contact details. Missing one of these items can disqualify an otherwise strong project.

Create a checklist from the rules and keep it visible. A simple version looks like this:

1. Confirm eligibility for every team member.
2. Note the submission deadline and the time zone.
3. List required artifacts, such as a repository, a live link, a video length limit and a README format.
4. Check whether pre-existing code is allowed and how to credit it.
5. Identify the judging criteria and the score weights, if they are published.
6. Save a copy of the rules as they stood when you began.

If the rules are unclear, ask the organisers in their official support channel and keep the answer in writing. Do not rely on a verbal reply or a comment from another participant. A short written answer protects you if a dispute arises later.

Short build windows reward focused scope. A useful test is whether you can explain the core user action in one sentence and show it working in a few minutes. For example, a single swap flow, a simple vote, a lending position view or a subscription payment is often easier to finish than a full marketplace with multiple contracts and admin tools.

When comparing ideas, score each one on four points:

• Real user need: who would use this, and why would they return?
• Technical risk: does the core feature depend on something you have not built before?
• Dependencies: does it need external data, a bridge, an oracle or an indexer?
• Demo quality: can a judge test it without reading the code?

Choose the idea with the best balance and cut anything that does not support the core flow. Keep a list of extras for after the event. A narrow project that works end to end usually earns more trust from judges than a wide project with broken pages.

Pick tools you already understand, and only add a new library if it removes a real problem. For an EVM-based dApp on Lisk, a common setup includes a Solidity contract framework, a testing tool, a frontend library for wallet connection and a block explorer for verification. Use a standard wallet connector so users can connect with the wallets they already have.

A practical layout:

• Contracts: keep them small and test each function before you link the frontend.
• Frontend: build the main flow first, then add styling and secondary pages.
• Backend: avoid one unless you need it for private data or scheduled jobs.
• Configuration: store the chain ID, RPC URL and contract addresses in one place so a network change is a single edit.

Document the setup steps in your README. Judges and other developers should be able to clone the repository, install packages and run the demo with the commands you list. Test on the network named in the current rules, and keep your deployment addresses in the repository so reviewers can verify them.

Many dApps need outside data or messages. A price feed, an indexed event history or a cross-chain transfer can each add a dependency that can fail during a demo. Decide early which of these you truly need.

Some infrastructure providers in the wider ecosystem are worth checking, depending on your project. Pyth Network offers price data for blockchain apps, which can matter for lending, trading or valuation features. Envio offers indexing and data APIs that can turn raw events into a queryable history for a dashboard. LayerZero V2 is a cross-chain messaging protocol that developers use when an app must send messages between networks. Check whether each provider supports the network you are building on before you commit, because coverage changes.

Keep a fallback for every external service. If a price feed is down during judging, show cached data with a clear label rather than a blank screen. Mock external calls in tests so your code path stays reliable even when a third party is slow.

A demo is often the first thing a judge touches, so design it for a stranger. Write a short script that walks through the main flow in the order a new user would take it. Keep it under the time limit in the rules, and rehearse it at least twice from a clean browser profile.

Prepare these items before the deadline:

1. A deployed version that loads without a local server.
2. A test account funded with testnet tokens, with the faucet source noted.
3. Seed data so the screens are not empty.
4. An error message for common failures, such as a rejected transaction or a network mismatch.
5. A short video that shows the flow, if video is allowed.

Test the demo on at least two browsers and one mobile device if the project has a mobile layout. Record the transaction hashes for the key actions so a reviewer can confirm them on a block explorer. Avoid any feature that asks users to send real funds during judging unless the rules explicitly require it.

Security is a judging concern as well as a user protection issue. A smart contract with a hidden admin key or an unchecked transfer can lose trust quickly, even in a prototype. Apply basic defensive practices from the start.

Core checks include:

• Restrict privileged functions with clear access control and document who holds each role.
• Validate all inputs and handle zero addresses, zero amounts and reentrancy paths.
• Use well-tested libraries for tokens and access control rather than writing your own.
• Run a static analysis tool and read its warnings before dismissing them.
• Write tests for failure cases, not only the happy path.
• Keep private keys out of the repository and rotate any key that was exposed.

Do not describe your project as audited unless an independent audit was completed and you can link the report. For a hackathon, it is more accurate to say the code was tested and reviewed internally and that it is a prototype. Clear language builds more trust than an overstated claim.

Before the deadline, run through a final list. Confirm that the repository is public if the rules require it, that the license file is present, that the README explains setup and that the demo link opens. Check that the video is within length and shows the actual product rather than slides.

After submission, do not stop. Keep the repository maintained with a note about known limits. Record what you learned, what you would change with more time and which parts were the riskiest. Those notes help if you apply for a follow-on grant or want to keep building.

If you do not win, ask whether the organisers share feedback. Many participants use that feedback to rebuild a narrower version of the same idea. Keep track of the contracts you deployed, because a tested project is easier to continue than one you rebuild from scratch.