As part of testing the platform, I voted in favor of this proposal.

(I'm pretty familiar with the proposal, so I will not provide my opinion until others chime in)

First of all: great initiative from Dean and NNT here 💪 Lunar strategy put together a solid plan for engagement in Europe here. Love to see it!

I do have some quesion posted below, that I not understand form the proposal description or the deck/presentation.

1. What is required from the committee members?

Do we need to provide some support for the hackatons? Show up physically? Help out with dev support Discord? Mentorships? Just some questions that pops into my mind when I see the pitch deck.

2. Are we set on the hackaton tracks?

The current tracks seems to force developer into a "small box" in my opinion. Are there any particular reasons why these tracks were chosen?

I would love to have one track instead: build something that can be used on Neo N3 mainnet on launch. Then we get laser focus and the bright minds participating are able to dream up whatever they want 🚀

If we only have one track then obviously prize categories needs to be changed.

3. Who pays?

Who is going to pay the bill here? The committee? Neo foundation? A mix?

Thanks for the questions Adrian!

On the first one - I think there are a few roles people might play. Some who are closer to Lisbon might be asked to show up for pre-events or the hackathon itself. I also think it would be valuable to set up some kind of dedicated office hours in Discord during the hackathon or workshops, just to make ourselves available for support. More broadly, it’s important that we show up as real people and help make the ecosystem more welcoming. So, different roles will suit different people depending on location, availability, and skillset. I think that Lunar can also act as a kind of concierge to get connect people with those of us in the ecosystem that needs specific kinds of support.

On the tracks - nothing is set in stone yet. These are just suggestions. There were a couple of reasons for the ones currently listed. First, if we’re going to do a hackathon, the proposal was made we should anchor it around topics that are hot in the wider industry to attract more interest. RWAs is one of them. Second, we wanted to highlight areas where Neo has something unique or strong to offer, hence NeoFS and anti-MEV. Personally, I’d prefer to focus on N3 related technologies - but that's just my own bias.

In general, there was a sense that if we make the hackathon too broad, it becomes difficult to support effectively and onboard people well. That’s part of the reason we we’re leaning toward focusing just on Go, for example, rather than trying to also support Python, C#, Java, etc. Supporting multiple languages requires more resources, more documentation, and a lot more coordination. By narrowing the scope, we can focus our energy and hopefully deliver a much better overall experience.

But again, open to suggestions!

In terms of funding — my proposal is that the Council pays for it collectively. The budget is around $60K, so split across 21 nodes, it’s not a huge ask considering how much GAS Council members receive in the wider scheme of things. Moving forward, if the pilot proves to be successful, then maybe we can make a proposal to split the cost with the Foundation or something like that. But I think it's really important that we demonstrate to ourselves and everyone else that the Council can step up and do some of these larger initiatives. Centre Point is a great starting point, but we need to do more.

Speaking of Centre Point, we could consider aligning the culmination of this pilot with Eth CC, and possibly do Centre Point around the same time. That way, we might have more people traveling into the region already, and we could reduce Centre Point costs by hosting this as one of big event. It would also help connect the developer community we’re trying to grow in Europe with some of the most experienced people in the Neo ecosystem.

One final point I want to make (and I mentioned this on the Council call, but I think it’s worth repeating here for anyone reading) is that the purpose of this pilot isn’t just the hackathon. The hackathon is just one part of it. What I really want to do is start building a new culture around welcoming people into our ecosystem and forming relationships. Because at the end of the day, that’s what matters most: relationships. From there, we can figure out how, as a Council and as a community, we can support them, help them grow within Neo, and set them up for success. So while the hackathon is definitely the centerpiece, what excites me more is the opportunity to lay the groundwork for a stronger, more connected ecosystem through on-the-ground presence and relationship building.

As long as there is a clearly defined goal for this endeavor and a promise from the facilitators to do their best to follow up, I'm a strong proponent. We have had a lot of success with hackathons/workshops in the past (as a technical-first community) as long as they are structured to deliver on goals instead of being generic initiatives.

I think Europe is a great pilot location and like the idea of stacking this initiative with other regional activities for the ecosystem.

As somone who has benefitted from a NEO hackathon in the past (Greenfinch / Neo Polaris) - I welcome the proposal and think it's a valuable step forward. Also pleased to see Lunar Strategy involved.

The only thing I would add is the support provided to promising projects post-hackathon needs to be incredibly well thought through - irrespective of whether a winning entry or not. I've seen the outline in the proposal, but would suggest a slightly longer term opportunity (12 month) to help a project establish a foundation (to continue building) and then a support system to help them navigate the real world 'startup' ecosystem (if not known already to participants). Building on blockchain with an idea is very different to building a startup business. If we want these projects to grow (and that is 100% the best outcome of an event like this) - we all need to think longer term. Happy to provide extra clarity/ideas here, because it's where Cassette is right now.

We supportive of this pilot and want to add a perspective from the broader industry trends we’re seeing going into 2026.

Across the ecosystem, three areas are emerging as clear long-term growth drivers: RWA, next-generation DeFi, and AI-driven agent/robot automation. These aren’t just narratives — they are becoming the new building blocks of on-chain activity. A European Developer Hub is well-positioned to align Neo with these trends in a practical way.

RWA: Europe is quickly becoming a regulatory leader for tokenization. Having an on-the-ground presence in Lisbon gives Neo a strong advantage to attract teams building real-world financial infrastructure.

Next-Gen DeFi: Developers in this region are already experimenting with intent-based execution, MEV-resistant architectures, and new settlement layers. This fits naturally with Neo’s strengths if we provide focused technical support and clear pathways from prototype → mainnet.

AI + Autonomous Agents: One of the fastest-growing categories for 2025–2026. Agents need reliable, low-cost execution and deterministic environments for coordination. If Neo can show strong support and tooling here (even starting with Go), it positions the ecosystem on the frontier of where builders are moving.

From this angle, the Hub shouldn’t be viewed only as a hackathon venue, but as a strategic foothold that attracts developers who are already building in these categories. If we shape the tracks and post-hackathon support around these emerging sectors, the ROI of this initiative could be significantly higher.

Overall, I support the pilot and believe aligning with these upcoming trends can help ensure the Hub becomes not just an event series, but a sustainable engine for long-term developer growth in the Neo ecosystem.

Thanks everyone for the comments and support so far. I want to clarify a couple of things about scope and then drill deeper into the “what happens after” part for discussion.

First, this is intentionally framed as a three-month pilot, not a finished 12-month program. As there are costs that are associated with this (costs that are on us) I was wary of putting forward something so large that it either gets blocked outright or becomes too heavy for us to execute well. The idea was to start with a contained pilot, show that we can actually attract and support builders on the ground in Europe, and then use real results to justify a longer commitment.

That said, a lot of the feedback here is about exactly what comes next, and I think that’s fair. The ecosystem has had many hackathon in the past - it's the part afterwards we really need to improve upon.

Goals and success for the pilot

As long as there is a clearly defined goal for this endeavor and a promise from the facilitators to do their best to follow up, I'm a strong proponent. We have had a lot of success with hackathons/workshops in the past (as a technical-first community) as long as they are structured to deliver on goals instead of being generic initiatives.

The primary goal of the pilot is to prove that a Council-funded, on-the-ground hub in Europe can:

• Attract a meaningful number of serious developers and teams into the Neo ecosystem.
• Get them to a point where they have working prototypes that are realistically on a path to mainnet.
• Establish ongoing relationships that we can continue to build on after the initial three months.

In the proposal, the pilot already has the following KPIs defined:

• Hackathon participation: 40–60 total (onsite + online).
• Projects/MVPs submitted: 10–15 viable prototypes.
• Social traction: 500k+ impressions across X and media during Month 1.
• Community growth: +500 new members in the Neo Europe channels.
• Press coverage: 5–6 media articles.
• Tooling stress-test KPIs: (Bugs identified, SDK issues solved, Developer feedback cycles)
• Post-event engagement: 50%+ of builders join Discord or future bounties.

Part of the work of this pilot is not just running a hackathon and some events, but also testing model for developer outreach and follow-up that we could extend to beyond months if the Council agrees.

Post-hackathon support and longer runway

I've seen the outline in the proposal, but would suggest a slightly longer term opportunity (12 month) to help a project establish a foundation (to continue building) and then a support system to help them navigate the real world 'startup' ecosystem (if not known already to participants).

From this angle, the Hub shouldn’t be viewed only as a hackathon venue, but as a strategic foothold that attracts developers who are already building in these categories. If we shape the tracks and post-hackathon support around these emerging sectors, the ROI of this initiative could be significantly higher.

I agree with the above points from @centisox and @HashKeyCloud

The proposal so-far includes a high-level builder retention plan for the three months after the hackathon:

• Light 3-month follow-up program: Regular check-ins to keep teams progressing after the hackathon.
• Deliverable-based incentives (funded/approved by Neo Council): Small incentives tied to demos or feature updates so we reward concrete progress, not just attendance.
• Ongoing mentorship: Direct access to Neo contributors plus the Lunar team for guidance.
• Continued activities: Workshops, ideathons, meetups, and technical sessions to keep momentum going.
• Visibility and growth support: Help with marketing, storytelling, and introductions to partners.
• Clear pathway forward: Teams understand how to move from MVP → grant → potential incubation.

But it is true that how we implement these is not yet clear. These are open open questions, which I think we should solve together with the Council and existing builders, including:

• Who exactly will make up the mentorship pool (by topic / expertise).
• How we want to structure the cadence and size of deliverable-based incentives (and what those incentives are).
• What a more extended path looks like beyond this initial retention window (for the most promising teams).

Rather than pretending that’s fully designed, I’d prefer to treat this as something we co-design with the Council and current ecosystem projects.

Ask to the Council and ecosystem

A few specific things I’d like to invite feedback and contributions on:

• Mentors and advisors
  If you, your team, or your company would be willing to act as mentors or “office hours” for selected teams, please say so. Having a list of people we can route builders to by topic (infra, DeFi, RWA, agents/AI, product, fundraising, etc.) will make a big difference.

• Connections into the startup ecosystem
  If you have relationships with accelerators, VC funds, or other founder support networks that could be relevant in Europe (or globally for remote programs), those would be extremely valuable for the post-pilot phase.

• Input on a 6–12 month path
  Suggestions of a 12-month support window is very aligned with where we want these projects to end up. I’d love to discuss what that 6–12 month path realistically could look like from “hackathon project” to “real product or startup.”

• Comfort level on duration (for Council members)

• If you’re a Council member, it would be helpful to know your preference here:

  • Are you open, in principle, to signing off on something longer than three months from the outset (for example, a 6–12 month extended support phase), so we can better plan the post-hackathon support model?
  • Or do you prefer to keep this strictly as a three-month pilot first and then revisit any extension once we’ve seen the results?

One thing I want to avoid is running a good pilot, then spending months debating what to do next while everyone drifts away. Perhaps one thing we can do is agree on a small set of success criteria in advance (for example: number of active teams at the end of three months, quality of projects, level of ongoing engagement, etc.). Then, we define a lightweight decision path where, if the pilot meets or exceeds those criteria, the Council already has a draft framework for extending support into a 6–12 month phase without starting from zero.

Finally, I’d like to invite Lunar into this part of the conversation as well. They have a better sense than anyone of what an extended program could look like based on their previous experience, and what is realistic for them in terms of recurring events, ongoing community management, and deeper incubation. I'll send Luka a message and ask him to join us here.

A few specific things I’d like to invite feedback and contributions on:

Mentors and advisors

Flamingo would be willing to mentor in "office hours" but we would not like for this mentorship to be a guranteed "prize" for participants. We would only give such a mentorship if we have "boots on the ground" in Lisbon to find a team or individual who shows promise as a builder. In other words: we would like to do tallent scouting rather than give a "prize of mentorship".

Input on a 6–12 month path A 6 month path should be enough for a an idea to get enough momentum for the commitments on both sides to extend beyond those inital 6 months. A short duration should also incentivse hard work.

Comfort level on duration A a three-month pilot makes most sense. It is better to get some feedback and then extend rather than over-commmiting to something unknown.

For now, Flamingo has switch the vote to NETURAL beacause:

We need more time to discuss if we are aligned on the hackathon part of the initiative (not the hub itself); spesifically about the tracks. For now we do not want to contribute focusing on industries or tech that we see we cannot offer support or are not connected to Neo N3 (not Neo 4 or where N3 miannet is in 2 years).

Nash generally supports this. Lisbon is a great spot for a European foothold right now, and doing this as a strict 3-month pilot seems appropriate to test the waters.

That said, we have to agree with Flamingo regarding the Hackathon Tracks. While we understand the desire to showcase unique tech like NeoFS or anti-MEV, the concern is that forcing these specific "niche" tracks might alienate generalist builders who just want to deploy solid dApps on N3. If the goal is "ecosystem growth," we shouldn't create friction by narrowing the scope too much. Let them build whatever they want, as long as it runs on Neo.

Also, looking at Lunar’s operational role—$10k/month is a fair chunk of the budget. I’d expect this to cover fairly aggressive "boots on the ground" work (getting universities involved, physical meetups) rather than just digital community management, which we can arguably do ourselves.

Questions:

Re: The "Go" Language focus: The roadmap mentions a pre-technical workshop for "Go + NeoFS." Are we exclusively targeting Go developers here? I feel like ignoring the Python/C# support (which is a huge selling point of Neo) might be a missed opportunity for a general hackathon.

Re: Post-Pilot Grants: The budget lists "Micro Grants" as "TBD." If a team builds something amazing in Month 3, do we have a fast-track mechanism to fund them immediately after the pilot ends, or will they be stuck waiting for a new Council vote? Momentum kills projects.

Hello everyone, pleasure to tune in here!

For those who don’t know me - I’m Luka, Partner & Head of BD at Lunar Strategy, a growth agency with a track record of 6 years in space and more than 300 supported projects. We’ve been collaborating with Neo since April, initially on the content creator side, amplification, and social support, and we also co-hosted the event together in Dubai.

Thanks a lot to everyone for the thoughtful feedback so far, it’s extremely valuable. Let me address the main points raised and add more context and clarity.

From this angle, the Hub shouldn’t be viewed only as a hackathon venue, but as a strategic foothold that attracts developers who are already building in these categories. If we shape the tracks and post-hackathon support around these emerging sectors, the ROI of this initiative could be significantly higher.

Absolutely – and this is exactly how we’ve been thinking about it as well.

The idea is not to build a single hackathon, but a Europe-based Neo Hub that consistently attracts, nurtures, and supports developers through multiple entry points.

The hackathon is just one component. Alongside it, we envision:

• recurring meetups,
• ideathons,
• technical workshops,
• university engagements,
• and an ongoing builder community anchored in Lisbon.

The Hub is meant to function as a long-term developer engine, not an event venue. Our goal is to create a steady flow of contributors who discover Neo through these activities and stay engaged and taken care of well beyond the pilot period.

Flamingo would be willing to mentor in "office hours" but we would not like for this mentorship to be a guranteed "prize" for participants. We would only give such a mentorship if we have "boots on the ground" in Lisbon to find a team or individual who shows promise as a builder. In other words: we would like to do tallent scouting rather than give a "prize of mentorship".

Fully aligned with this.

Mentorship shouldn’t be a boxed-in reward, and in practice, the best outcomes always come from selective engagement, not guaranteed slots.

For us, the purpose of a hackathon + hub is:

• teams demonstrate what they can do,
• experienced ecosystem members see them under “real conditions”, and
• then decide who they actually want to support.

Our role is to:

• host office hours and touchpoints where those interactions can happen
• facilitate introductions, and
• create the environment where high-potential teams / talent become visible.

This talent-scouting approach is healthier for both mentors and builders, and aligns with how we’ve run ecosystem programs in the past. Bottom line, we would not package “X hours of Flamingo/any other team mentorship” as a hard, guaranteed prize.

We need more time to discuss if we are aligned on the hackathon part of the initiative (not the hub itself); spesifically about the tracks. For now we do not want to contribute focusing on industries or tech that we see we cannot offer support or are not connected to Neo N3 (not Neo 4 or where N3 miannet is in 2 years).

That said, we have to agree with Flamingo regarding the Hackathon Tracks. While we understand the desire to showcase unique tech like NeoFS or anti-MEV, the concern is that forcing these specific "niche" tracks might alienate generalist builders who just want to deploy solid dApps on N3. If the goal is "ecosystem growth," we shouldn't create friction by narrowing the scope too much. Let them build whatever they want, as long as it runs on Neo.

This is very valid feedback, and to be clear, as Dean said: nothing about the tracks is set in stone. Having this discussion here is exactly what we hoped would happen, so we can steer it in the right direction together. :)

A structure that seems to reflect what several of you have raised could be:

1. Open N3 Track (core)

• “Build something that can realistically run on Neo N3 mainnet.”
• Any dApp / infra / tool is welcome, as long as it deploys to N3.
• This is where the majority of builders should feel at home, and where general DeFi / dApp use cases fit naturally.

2. Optional Spotlight Themes (co-designed with ecosystem projects) Examples could include:

• NeoFS + storage use cases
• RWA / regulated finance (where Europe is strong)
• Next-gen DeFi or agents/automation, if we know there is mentor and infra capacity on the Neo side

Prize categories would mirror this structure (Best Overall N3, Best NeoFS use, Best RWA/DeFi, Ecosystem choice, etc.), but none of it is meant to force anyone into a narrow box.

So: Open N3 is the foundation, and any more specific theme should only be added where the ecosystem can realistically support it. If there’s no bandwidth or conviction around a given niche, it doesn’t go into the first pilot.

Also, looking at Lunar’s operational role—$10k/month is a fair chunk of the budget. I’d expect this to cover fairly aggressive "boots on the ground" work (getting universities involved, physical meetups) rather than just digital community management, which we can arguably do ourselves.

That expectation is absolutely fair – and we agree.

To clarify, for the pilot, what Lunar is committing to is much more than digital community management. Concretely, this includes:

On-the-ground presence in Lisbon

• Using our office as a hub space for meetups, workshops and occasional co-working days
• Organizing and hosting 1–2 in-person events per month (meetups, ideathons, builder sessions)

Local outreach

• University & local dev outreach
• Leveraging existing relationships with Lisbon universities, dev groups and coworking spaces
• Actively promoting the hub + hackathon through those channels, not only online

Program coordination

• Handling registrations, onboarding, communication with all participants
• Coordinating with ecosystem mentors and making sure builders reach the right people
• Keeping a clear view of who is building what, and where follow-up makes sense

Content & visibility

• Producing recaps, project spotlights, and funneling them into Neo’s comms so good work doesn’t disappear after the weekend

Re: The "Go" Language focus: The roadmap mentions a pre-technical workshop for "Go + NeoFS." Are we exclusively targeting Go developers here? I feel like ignoring the Python/C# support (which is a huge selling point of Neo) might be a missed opportunity for a general hackathon.

The Go + NeoFS mention in the draft reflects our initial thinking after the first calls, again - not set in stone.

To clarify how we see it now:

• For workshops and starter templates, it’s pragmatic to start Go-first – so that newcomers have a clear path with solid examples and we don’t spread resources too thin.
• The hackathon itself is not meant to be Go-only:
  • Experienced Neo devs should be able to build in Python, C#, TS, Java where it makes sense.
  • The key condition is: we can provide at least some support or point them to people who can.

So the messaging going forward would be something like:

“Go is the best supported path for newcomers in this pilot (workshop + templates), but existing N3 devs are welcome to use the language they’re productive in – Python, C#, etc.”

If there’s appetite from the community to co-host a Python-first or C#-first workshop in the same window, we’d be happy to help coordinate that as well.

Re: Post-Pilot Grants: The budget lists "Micro Grants" as "TBD." If a team builds something amazing in Month 3, do we have a fast-track mechanism to fund them immediately after the pilot ends, or will they be stuck waiting for a new Council vote? Momentum kills projects.

In our last call, we also discussed the idea of a micro-grant fast track so strong teams don’t hit a hard stop after the pilot.

One way this could work in practice is:

• A Council-approved micro-grant pool that can be used without a full new proposal each time, within a clear framework.
• Several small tickets (for example, 3–5k per team for 3–5 teams), each tied to concrete milestones such as:
  • deploying to N3
  • completing a specific integration
    • hitting a simple adoption metric, etc.

Lunar’s role here would not be to manage the funds, but to:

• help identify which teams are ready for this,
• help them phrase realistic milestones, and
• report back to the Council on whether those milestones were hit.

The “TBD” label in the budget reflects that the exact size and governance rules of this pool should be owned by the Council, not pre-decided by us. The intention, though, is clear: to create a fast lane from hackathon → early grant, instead of letting the pilot end with a hard stop.

I hope this helps clarify how we’re thinking about the hub and the pilot. If I’ve missed anything or misinterpreted a concern, please call it out.

Looking forward to continuing the conversation and, bringing the Neo Europe Hub to life together. 🙂

Hello everyone, pleasure to tune in here!

For those who don’t know me - I’m Luka, Partner & Head of BD at Lunar Strategy, a growth agency, with track record of 6 years in crypto space, and more than 300 clients during that time. We’ve been collaborating with Neo since April, initially on the content creator side, amplification, and social support, and we also co-hosted the event together in Dubai.

Thanks a lot to everyone for the thoughtful feedback so far, it’s extremely valuable. Let me address the main points raised and add more context and clarity.

From this angle, the Hub shouldn’t be viewed only as a hackathon venue, but as a strategic foothold that attracts developers who are already building in these categories. If we shape the tracks and post-hackathon support around these emerging sectors, the ROI of this initiative could be significantly higher.

Absolutely – and this is exactly how we’ve been thinking about it as well.

The idea is not to build a single hackathon, but a Europe-based Neo Hub that consistently attracts, nurtures, and supports developers through multiple entry points.

The hackathon is just one component. Alongside it, we envision:

• recurring meetups,
• ideathons,
• technical workshops,
• university engagements,
• and an ongoing builder community anchored in Lisbon.

The Hub is meant to function as a long-term developer engine, not an event venue. Our goal is to create a steady flow of contributors who discover Neo through these activities and stay engaged and taken care of well beyond the pilot period.

Flamingo would be willing to mentor in "office hours" but we would not like for this mentorship to be a guranteed "prize" for participants. We would only give such a mentorship if we have "boots on the ground" in Lisbon to find a team or individual who shows promise as a builder. In other words: we would like to do tallent scouting rather than give a "prize of mentorship".

Fully aligned with this.

Mentorship shouldn’t be a boxed-in reward, and in practice, the best outcomes always come from selective engagement, not guaranteed slots.

For us, the purpose of a hackathon + hub is:

• teams demonstrate what they can do,
• experienced ecosystem members see them under “real conditions”, and
• then decide who they actually want to support.

Our role is to:

• host office hours and touchpoints where those interactions can happen
• facilitate introductions, and
• create the environment where high-potential teams / talent become visible.

This talent-scouting approach is healthier for both mentors and builders, and aligns with how we’ve run ecosystem programs in the past. Bottom line, we would not package “X hours of Flamingo/any other team mentorship” as a hard, guaranteed prize.

We need more time to discuss if we are aligned on the hackathon part of the initiative (not the hub itself); spesifically about the tracks. For now we do not want to contribute focusing on industries or tech that we see we cannot offer support or are not connected to Neo N3 (not Neo 4 or where N3 miannet is in 2 years).

That said, we have to agree with Flamingo regarding the Hackathon Tracks. While we understand the desire to showcase unique tech like NeoFS or anti-MEV, the concern is that forcing these specific "niche" tracks might alienate generalist builders who just want to deploy solid dApps on N3. If the goal is "ecosystem growth," we shouldn't create friction by narrowing the scope too much. Let them build whatever they want, as long as it runs on Neo.

This is very valid feedback, and to be clear, as Dean said: nothing about the tracks is set in stone. Having this discussion here is exactly what we hoped would happen, so we can steer it in the right direction together. :)

A structure that seems to reflect what several of you have raised could be:

1. Open N3 Track (core)

• “Build something that can realistically run on Neo N3 mainnet.”
• Any dApp / infra / tool is welcome, as long as it deploys to N3.
• This is where the majority of builders should feel at home, and where general DeFi / dApp use cases fit naturally.

2. Optional Spotlight Themes (co-designed with ecosystem projects) Examples could include:

• NeoFS + storage use cases
• RWA / regulated finance (where Europe is strong)
• Next-gen DeFi or agents/automation, if we know there is mentor and infra capacity on the Neo side

Prize categories would mirror this structure (Best Overall N3, Best NeoFS use, Best RWA/DeFi, Ecosystem choice, etc.), but none of it is meant to force anyone into a narrow box.

So: Open N3 is the foundation, and any more specific theme should only be added where the ecosystem can realistically support it. If there’s no bandwidth or conviction around a given niche, it doesn’t go into the first pilot.

Also, looking at Lunar’s operational role—$10k/month is a fair chunk of the budget. I’d expect this to cover fairly aggressive "boots on the ground" work (getting universities involved, physical meetups) rather than just digital community management, which we can arguably do ourselves.

That expectation is absolutely fair – and we agree.

To clarify, for the pilot, what Lunar is committing to is much more than digital community management. Concretely, this includes:

On-the-ground presence in Lisbon

• Using our office as a hub space for meetups, workshops and occasional co-working days
• Organizing and hosting 1–2 in-person events per month (meetups, ideathons, builder sessions)

Local outreach

• University & local dev outreach
• Leveraging existing relationships with Lisbon universities, dev groups and coworking spaces
• Actively promoting the hub + hackathon through those channels, not only online

Program coordination

• Handling registrations, onboarding, communication with all participants
• Coordinating with ecosystem mentors and making sure builders reach the right people
• Keeping a clear view of who is building what, and where follow-up makes sense

Content & visibility

• Producing recaps, project spotlights, and funneling them into Neo’s comms so good work doesn’t disappear after the weekend

Re: The "Go" Language focus: The roadmap mentions a pre-technical workshop for "Go + NeoFS." Are we exclusively targeting Go developers here? I feel like ignoring the Python/C# support (which is a huge selling point of Neo) might be a missed opportunity for a general hackathon.

The Go + NeoFS mention in the draft reflects our initial thinking after the first calls, again - not set in stone.

To clarify how we see it now:

• For workshops and starter templates, it’s pragmatic to start Go-first – so that newcomers have a clear path with solid examples and we don’t spread resources too thin.
• The hackathon itself is not meant to be Go-only:
  • Experienced Neo devs should be able to build in Python, C#, TS, Java where it makes sense.
  • The key condition is: we can provide at least some support or point them to people who can.

So the messaging going forward would be something like:

“Go is the best supported path for newcomers in this pilot (workshop + templates), but existing N3 devs are welcome to use the language they’re productive in – Python, C#, etc.”

If there’s appetite from the community to co-host a Python-first or C#-first workshop in the same window, we’d be happy to help coordinate that as well.

Re: Post-Pilot Grants: The budget lists "Micro Grants" as "TBD." If a team builds something amazing in Month 3, do we have a fast-track mechanism to fund them immediately after the pilot ends, or will they be stuck waiting for a new Council vote? Momentum kills projects.

In our last call, we also discussed the idea of a micro-grant fast track so strong teams don’t hit a hard stop after the pilot.

One way this could work in practice is:

• A Council-approved micro-grant pool that can be used without a full new proposal each time, within a clear framework.
• Several small tickets (for example, 3–5k per team for 3–5 teams), each tied to concrete milestones such as:
  • deploying to N3
  • completing a specific integration
    • hitting a simple adoption metric, etc.

Lunar’s role here would not be to manage the funds, but to:

• help identify which teams are ready for this,
• help them phrase realistic milestones, and
• report back to the Council on whether those milestones were hit.

The “TBD” label in the budget reflects that the exact size and governance rules of this pool should be owned by the Council, not pre-decided by us. The intention, though, is clear: to create a fast lane from hackathon → early grant, instead of letting the pilot end with a hard stop.

I hope this helps clarify how we’re thinking about the hub and the pilot. If I’ve missed anything or misinterpreted a concern, please call it out.

Looking forward to continuing the conversation and, hopefully, bringing the Neo Europe Hub to life together. 🙂