Astralis runs already; what it lacks is the tooling that makes the next build cheap. Three tracks for EVM developers, MIT by default, judged on whether another builder would use it.
That is the baseline target, and it is the one that separates a hackathon producing artifacts from one producing a weekend. The rest of the numbers exist to feed it.
Three preparing, three building, two judging and wrapping up.
Each with its own prize pool, so a strong build in one is not measured against another.
Qualifying open-source repositories Astralis can fork, extend, and maintain. The primary output.
The default on every submission. No assignment beyond it.
Targets for a first event on a new chain, at the Recommended budget tier. They are meant to be agreed before launch so success is measured against a shared number rather than a feeling.
Pick one track and build for the developer who arrives after you. Each is judged on its own terms against the same five criteria.
A web tool that takes a contract address and ABI from another EVM chain and redeploys an equivalent contract to Astralis.
Judged primarily on UX quality, backend cleanliness, and whether the migration is actually correct.
Source contracts have to be verified and openly licensed. Check the licence before you migrate anything; this is a requirement of the build, not a blocker on it.
Scaffold-ETH-2-style clonable starter kits that take a newcomer from git clone to a deployed dApp.
Judged primarily on Completeness, coverage of chain-specific features, and the quality of the documentation.
The measure is whether a stranger can clone it and deploy without asking you a question.
MCP servers, developer portals, and cloneable resources that let AI agents build and deploy without a human in the loop.
Judged primarily on Practical usefulness to an agent, and whether the interaction rewards the person driving it.
This track exists because the documentation an agent needs is not the documentation a person needs.
A submission missing any one of them is screened out in week seven before scoring begins. None of them are difficult, and all of them are published now rather than sprung at the deadline.
MIT by default. Private repositories are permitted only by prior arrangement with the Astralis team, agreed before you submit rather than after.
Either a live URL with a working interface, or a working CLI or TUI with complete documentation. This proves the build runs and leaves something usable behind.
Setup, architecture, and the chain-specific configuration. The test is whether someone can pick it up without you in the room.
A video of three to four minutes at most, or a slide deck. Cover the problem, the solution, what you built, and where it goes next.
Contract addresses on the Astralis testnet, verified on the block explorer. Verification support is a hard dependency for the event, not a convenience.
The same rubric applies to all three tracks. Each criterion is scored one to five, weighted, and submitted through a shared sheet before the group review call. Ties go to the track’s lead technical judge.
| Criterion | Weight | The question behind it |
|---|---|---|
| Technical execution | 30% | Does it work? Is the code sound, tested, and maintainable? |
| Usefulness to the ecosystem | 25% | Would another builder on this chain actually use it? |
| UX and completeness | 20% | Is it finished enough to hand to a stranger? |
| Documentation and presentation | 15% | Can someone else pick it up without the author? |
| Longevity potential | 10% | Is this worth Astralis maintaining or extending? |
Eight weeks from signed engagement to winners paid. Weeks are counted from the start date, which is proposed for 18 August and not yet fixed, so the phases below are firm and the calendar dates are not.
| Week | Phase | What happens |
|---|---|---|
| 1 | Foundations | Designer onboarded, a channel opened with the Astralis dev team, an input session on tracks with the CEO and CPO, teaser posts live. |
| 2 | Build-out | Brand assets in progress, documentation portal drafted, testnet faucet confirmed, waitlist form created. |
| 3 | Launch | Docs, tracks, questions and judging criteria published, DoraHacks listing live, sponsor letters of intent secured, registration opens. |
| 4 | Build opens | The event goes live. Kickoff call and office hours begin, with daily support in the community channels. |
| 5 | Build midpoint | Mid-event check-in, builder spotlights, and technical escalation to the Astralis engineers where a team is blocked. |
| 6 | Build closes | The final seventy-two-hour push, where most of the activity is expected. Submissions close at the end of the week. |
| 7 | Judging | Eligibility screening, judges scoring independently, then a group review call and a technical deep-dive on the shortlist. |
| 8 | Wrap | Winners announced, prizes distributed, results written up, and a retrospective that sets up the second event. |
Any one of them slipping moves the launch date.
Those are the Recommended tier’s figures. Astralis has not confirmed a tier, so read every number here as the recommendation rather than the contract.
Recommended tier, unconfirmed
Unpaid hackathon prizes are a recurring and well-publicised problem in this space. Holding the full pool in reserve before registration opens removes the largest reputational risk in the program, and it is the reason the figures above can be published at all.
Serious EVM tooling developers weigh events against each other. A $1,500 track win competes for attention against events paying $5,000 to $10,000 for equivalent work, which is why the Lean tier comes with correspondingly moderate expectations on volume and quality.
Nine judges, three per track, is the ideal. Five is sufficient for a first event. The panel below is the proposal that went to Astralis; confirmation and availability are a week-two decision, so treat these as candidates.
Lead technical judge, CTO
Light-touch during the event as a support developer. At judging, reviews the code under the hood, assesses what would need to change, and decides whether the build is worth keeping.
Strategic judge, CEO
One or two briefing calls upfront to set expectations, optionally available to builders and sponsors during the event. At judging, identifies the strongest opportunities and leads the forward-looking questions for winning submissions.
Product and resources judge, CPO
The most active before and during the event, making sure development resources and documentation are in place. At judging, assesses fit with the product vision and proposes routes from hackathon project to long-term product.
Business model judge, Latam Growth
Assesses ease of use, quality, and ecosystem longevity. Also contributes to defining the tracks at the start.
Ecosystem and investment judge, Board
Subject to availability. Identifies opportunities benefiting both the chain and Strategic Exchanges, and connects promising builders to investors or launch platforms.
For a new chain’s first event, an all-internal panel invites scepticism about fairness, and that scepticism is a well-known friction point in developer communities. Adding one respected external EVM developer, or a representative from a sponsor, materially improves credibility at close to zero cost. Candidates are being sourced.
The program manager supports judging operationally, on scheduling, scoring sheets, and eligibility screening, and holds no scoring vote.
These take longer to resolve than people expect, which is why they are settled in week one rather than at payout. The rest of the open questions are below.
Registration opens on DoraHacks in week three. Until then this list is how the listing link, the track briefs, and the published rules reach you.