Planning for new subgraphs on mainnet

I would like to raise the suggestion that curators and indexers should be made aware of subgraphs to be added to the network prior to them being launched (a subgraph roadmap of sorts), as this will allow them to be assessed by curators and allow for planning for allocation by indexers.

Currently the cost to open and close allocations is prohibitively expensive (in ETH terms) to make frequent changes with for indexers, it would be helpful for us to know when subgraphs would be added to the network so that we can budget costs accordingly as well as leave stake free for additional subgraphs that we wish to allocate on.

Additionally I’d like to suggest that subgraphs be added to the network in a ‘batched’ fashion, allowing us to stake new subgraphs in a group rather than shuffling stake to accomodate as they are added sporadically.

Understandably this request isn’t realistic in the long-term but at this phase of the network it would be helpful for us indexers who are running with costs coming out of our own back pocket.

Hopefully we have a way to extract our rewards prior to more subgraphs being added!

Thanks,
Dan

4 Likes

@dancube Thanks for bringing this up!

I think once the testnet is in place, that could also be a way to implement this sort of roadmap for this phase of the network.

1 Like

Let’s please keep the conversation related to the topic of the thread, which is about planning and roadmap of new subgraphs on mainnet. No need to add a destructive/negative comment on the status of the network.
As a community member I’m seeing that there are new indexers joining (several of them in the past few weeks) which correlates with the Indexer bootstrapping phase stated by the Foundation here.

3 Likes

Oh come on! I’m being hidden for “off topic?” Look at the name of thread, look at the question I ask. Pretty dang on-topic if you ask me.

From the doc provided:

“For several weeks following mainnet launch, Indexers will continue to stress test and improve performance, before supporting real query volume. This is to ensure that all Indexers feel comfortable with their setup and the quality of services they’re offering.”

The original post is a month old. We are nearing 3 months into the bootstrapping phase. This is absolutely not an unreasonable question to ask! Get an answer out to people. The only thing “negative” here is the fact that a legitimate question has no legitimate answer.

Indexers are not the only one who need to plan for new subgraphs. Subgraphs on mainnet impact delegator earning potential, and it also impacts whether or not we ought to commit to keeping our funds locked when VC wallets come unlocked in May.

If the team doesn’t provide a clear answer, it’s entirely possible they themselves don’t know exactly when the migration is happening. This isn’t unusual – in fact, most projects are vague about the “when” when it comes to development, simply because work like this requires a lot of testing (and perhaps coordination with other projects as well), and as such, many unforeseen problems to solve. I believe the team said Q1 for curation (this implies partial migration I think). Even if it lingers a month into Q2, I wouldn’t be worried.

1 Like

I would support the idea with the caveat that the subgraph roadmap would not just be made available in advance to curators and indexers exclusively, but rather to everyone. While I recognize that there is a more pressing need from a planning perspective for indexers and curators, I don’t see why the view to such a roadmap should only be restricted to these two groups. Future and current delegators would also benefit from such insights.

Stretching this out a bit further, many indexers and curators are also delegators themselves. Having an exclusive view to the roadmap could provide them an inside track to maximize short term APYs by favorably shifting delegations. I would be against introducing an incentive to promote such a behavior.

2 Likes

I agree with the above, especially as it would cost nothing to make the roadmap available to everyone. I also agree on the related matter that a current updated status/roadmap of migrating subgraphs to mainnet wouldn’t hurt anyone now that we’re three months into mainnet. I recognize it’s up to the team whether you all want to keep this under wraps until it’s actually about to happen, but communication rarely hurts and can often help keep everyone interested and invested.

3 Likes

I would like to know about the subgraph migration strategies. Will be there migration waves with some subgraph batches? I agree that’s important to know in anticipation which subgraphs will migrate first, and maybe test the scenarios on testnet. As a curator/delegator we need information in order to be prepared, indeed with unlocked GRT to participate in the marketplace.

So- is there a roadmap? Or like, anything that could offer some clarity on when subgraphs will start migrating? Surely there’s something to report, anything?

Hey, just want to let you know that we’re listening. Things are getting closer but with a community this large and a system this complex it’s difficult to communicate publicly until all the pieces are in place. We want to be sure that everyone hears the plan at the same and that once we offer a plan, the community can confidently execute on it. We are getting close. Thanks for your patience!

6 Likes

I think having a public subgraph onboarding roadmap can further allow the teams that are looking forward to developing a subGraph for their app and launching it on main-net to involve the subGraph developers community for contract based work.

This implies that there will now be a one-stop solution for these teams to hire subgraph developers for developing their subgraph, involving the curators community to curate these subgraphs, which will further signal the indexers to allocate resources for indexing these subgraphs on the mainnet.

This will not only ease out the curation and indexing of the new subgraphs from the curators / indexers perspective, but will also be really helpful for teams who are looking forward to add the subgraph to their protocol but are unaware of the Graph’s subgraph onboarding process (curation / signalling etc) or need a developer to develop the needed subgraph.