IMO I think this approach makes sense vs. scraping the forum. Scraping large amounts of information is useful for a “spray and pray” strategy. That’s not our reality in Rootstock where we have a small group of high-context delegates operating in a niche ecosystem.
I’m open to other viewpoints.
Thank you, @Raphael_Anode and you’re correct, and thank you to @Axia for your thoughts - we agree with both points. We agree and understanding that the context is more important than all unfiltered data. Our comment regarding “scrapping” was more on efficiency on how to get more data into the LLM Rootie model. If others have suggestions on how to make to easily add data to Rootie that makes it “routine”, we are open to that.
One way to do this is to use your agent to interact with the Rootie bot agent. Your agent could scrape the forum and then send you a list to review. Then either your agent posts to Rootie or you manually post so you can review first.
Hey @ChronoTrigger Congratulations on a successful kick-off. Completely agree with SEEDGov and Axia that bridging this specific educational gap is exactly why the Collective and RLabs are currently working to formalize a highly targeted, delegate-driven BD strategy. We are really looking forward to your final report in May to see how this genuine initial interest from the residency translates into deployed code and sticky ecosystem growth.
Hello @ChronoTrigger ,
Thank you so much for your initial thoughts and personal observations - these are really valuable! It’s great to see such a strong turnout of attendees and to hear that the “Sovereign Infrastructure” narrative resonated, specifically the PoW/Merged Mining aspect. Your slides are great, and maybe we should consider “templatizing” them for other grant recentants to use at their events, since they give a good understanding of Rootstock.
And it’s obvious that you and @Kaf_Anode are putting in the hard work and legwork on the ground, appreciate you doing that!
We do have a few thoughts on what we as delegates and the Rootstock team should focus on:
It’s telling that builders were surprised by Rootstock’s PoW security model. If our PoWPeg and 88% hashrate are our strongest differentiators, do we have a “Quick Start” dev guide specifically for builders coming from other EVM chains who want to leverage that security today?
We found this list of QS docs, but they are very specific and not a generalized “benefits guide” for builders who have been building on other EVM chains and are very new to RT. If it doesn’t already exist, is this something that either the RT marketing team or the delegates can create? We see this as extremely valuable for enticing more builders to RT.
We appreciate your point that the solution isn’t just “sponsoring more events.” You’ve identified this big messaging gap. The next strategic question for the Collective, is: How do we scale this awareness without relying on one-off, high-touch residencies? Events can reach a subset of the target market, but if we can build upon your experience and discover other ways that are high-value + low-touch will be the most effective way to scale.
Keep up the momentum, and we’re looking forward to seeing the builders outcome report! Tks!
Great presentation, really appreciate you both @ChronoTrigger @Kaf_Anode for putting this report together.
Agree with the takeaway that Rootstock has a unique position and strong products, but awareness is still low. We’ve done some research on Collective Rewards and found that adoption is still quite limited, out of the 1B circulating RIF, only around 2.3% is currently staked. So we’re seeing the same pattern.
We definitely should come up with a strategy plan to bring more awareness to Rootstock.
Agreed — local events tend to work well. Including a presence at local conferences, hackathons, and universities. Perhaps The Collective can allocate a small budget to delegates who want to represent Rootstock in their local geography.
@Curia what are your ideas here?
I think this needs to be discussed further.
My local crypto/web3 is very strong, with fequent crypto events, some known, strong crypto projects from here, a recent Ethereum Hub inaugurated, a Coinbase’s Base local office, events from many AI companies (Cursor, Lovable, Windsurf/Devin, Oracle, Vercel, Linear, etc. you name it, they’re here).
I participate in multiple crypto Whatsapp communities, including some very active, with over 400 participants, about 1/4 of those are builders.
And I think these initiatives tend to yield better results slow and contantly, with small mini events and presence over 1-2 years, rather than with big flashy pushes, like sponsoring expensive events.
We have a similar idea as you. Since delegates have the most context on Rootstock and are based across different regions, allocating a small budget to support local presence in each geography feels like a strong approach to drive awareness.
For example, delegates could host monthly events with a clear focus on onboarding specific user groups (e.g., developers, RIF holders, etc.), then build retention through local community channels like group chats. Over time, this can lead to more volume flowing into Rootstock and more people recognizing it —either way, a win for the ecosystem.
@ChronoTrigger Your connections will definitely be helpful here.
As far as next steps for Ipê Village, I think delegates have a real opportunity to use the builders coming out of this event to pressure-test some of our broader hypotheses about events. A lot of the discussion in this thread and elsewhere on the forum seems to point to the same issue: teams need GTM support.
In other words, it’s not enough for a team to finish a hackathon, or even complete a grant from the Collective and ship a product. After that point, they still need help getting traction. Realistically, that support often looks less like direct funding and more like routing: introductions to investors, connections to security firms for audits, social media visibility, content support, user acquisition, and general ecosystem coordination.
Since Ipê Village is ending this week, I think delegates could take a small but useful step right now by drafting a simple 1-page builder follow-up playbook that spells out:
• what kinds of support the Collective can realistically offer after the event (grants pipeline, audit referrals, tooling support, investor intros, etc.),
• who owns each part of that follow-up,
• and what timeline builders should expect.
From there, it could be circulated to @ChronoTrigger and @Kaf_Anode while people are still on-site, so it can be presented during Demo Day as a concrete answer to the question of “what comes next?” Then it could also be posted back to the forum for delegate feedback, which would make it reusable not only for future events, but potentially for Collective grantees more broadly as a form of post-grant support.
I think the important thing here is to keep it lightweight for now. We do not need a fully systematized machine on day one. We need something practical that creates a basic support layer and can later be standardized and scaled if it proves useful.
To be clear, I still think the broader strategic alignment with RLabs - and the more top-down coordination model that @SEEDGov , @Tane @Raphael_Anode @DAOstar_gov and others were pointing toward - is the right longer-term conversation. But that feels like a separate and slower-moving track. The builder follow-up playbook feels like the thing delegates could actually produce this week.
For me, the key idea is simple: the Collective does not need to solve every problem directly, but it can provide routing for grantees and builders - audit connections, intros, tooling support, visibility, and other forms of ecosystem access.
Curious how others see it, but to me this feels like the lowest-lift way to turn a recurring problem into something operational.
I think the idea of identifying recurring frictions faced by builders on Rootstock (whether they are part of Collective grants or not) is very valuable, as it allows us to target concrete solutions.
I agree that some higher-level insights will emerge from the alignment dialog I hope will begin between delegates and the RLab. However, if we can identify recurring frictions, such as connecting with potential service providers or partners, not technical support during specific stages of development, or addressing visibility needs (just to give a few examples), these are areas where the DAO could proactively contribute.
Moreover, depending on the frictions that are identified, it may not be necessary for some of them to be purely reactive. Instead, if that is the case, we could create a structured guide or resource list and pin it in the forum, allowing it to evolve over time. This would complement, not replace, the ability to respond to specific, unforeseen needs on a case-by-case basis.
This thread you’ve started and any feedback that @ChronoTrigger and @Kaf_Anode may collect during the event, could serve as a strong starting point to begin developing this approach.