Since the launch of the Graph Explorer app last week, we have witnessed tremendous activity in the curator community to organize around becoming more effective in their role as a network group.
There has been a good amount of feedback being shared in various channels around the curation experience. This thread aims to consolidate that feedback and share early impressions gained from curation as well as gaining a pulse from the community on what is viewed as most important.
Below you find polling on feedback items that you have an opportunity to rank with regards to what you feel is most important (5) or least important (1). The aggregate ranking is meant to provide a signal from the curator community on their priorities. None of the below items are any proposals, but it’s rather meant to measure the pulse of the community. Also, any examples provided are purely for illustration purposes aimed to provide context. Anyone is welcome to create a new thread to suggest a more detailed improvement proposal in a separate forum post.
I recommend being differentiated in your assessment and avoid ranking every item with a 5. That will improve the signal strength on what the community should prioritize to have deeper discussions on at this point. Also feel free to make additional suggestions to add to the poll in this thread, which I can update in the main post. Check back in routinely here to vote on new items and to see updated polling numbers.
More efficient collaboration space to exchange feedback on individual subgraphs. Example: create chat function for each subgraph in Graph Explorer
1
2
3
4
5
0voters
Subgraph verification. Create a signal mechanism that provides confidence in the utilization of a deployed subgraph. Example: create a Will-this-subgraph-have-query-volume? snapshot voting for each subgraph that active curators can vote on
1
2
3
4
5
0voters
Tied to prior question: Create signal mechanism for curator experience. Example: Add checkmark for each (curator) wallet in subgraph snapshot vote indicating whether wallet is recipient of Curator Program POAP
1
2
3
4
5
0voters
Create ability to deploy-and-signal subgraphs, so that whoever deploys subgraphs in Graph Explorer is the first one to signal
1
2
3
4
5
0voters
Create ability by subgraph owner to permanently remove subgraph from Graph Explorer when specified conditions are met, such as nobody signaling on the subgraph
1
2
3
4
5
0voters
Address situation of curation front-running bots that instantly auto-delegate newly deployed subgraphs systematically. Example: introduce sliding scale thawing period, where early curators have a comparatively longer commitment to stay on the bonding curve.
1
2
3
4
5
0voters
Review bonding curve algorithm to enhance mission-alignment. Example: Introduce logic for share price to be influenced by query fee volume
1
2
3
4
5
0voters
Create ability to transfer subgraph ownership to minimize number of duplicate subgraphs listed in Graph Explorer
1
2
3
4
5
0voters
Create ability to signal on a subgraph using a mobile device (vs. desktop/laptop) to maximize access to curation market for network members
This is why the Graph will succeed. The most underrated project on the network, working to fix the first shaky steps of the curator experience. I would say onward to the moon, but we’re projected past Pluto at this point.
Graphtronauts know there is space beyond the moon.
Regarding deploy and signal, there’s a few items here which would be important. If a project is deploying their own subgraph, they likely won’t utilize this function. This is really to benefit subgraph devs who are either doing contract work for DApps or for curators who are assisting with onboarding DApps.
Personally I think this item and the transfer of ownership items are likely tied. I think curators who are actively assisting DApps with their deployment to the mainnet should be rewarded and given the chance to take the first position. They will need to be able to grant ownership to the project though. Onboarding is particularly active right now due to the recent mainnet launch, but it will create a market for subgraph contract work for devs moving forward.
Alternative proposal that solves a couple of the above stated issues:
Problem: The way the bonding curve currently works means that the person who signals first to a subgraph has the highest reward with the lowest risk - irrespective to legitimacy of the subgraph. This has results in bots jumping in while skipping the process of verification.
Solution: Subgraphs are deployed to the mainnet in 2 stages.
Stage 1 - Show Room:
For 2 days a subgraph is listed in the show room for curators to inspect and verify. DApps are informed of this stage and have incentive to confirm to the community that they are the legitimate source of the deployment. After 2 days, a subgraph will calculate the total signal and each curator who signaled during the show period will receive the a common value and shares proportional to the GRT they signal.
Stage 2 - Production:
Now that everyone Show Room participant has a proportional seat in position 1. From there we move on the bonding curve. Later signal is rewarded less but has greater confirmation of query traffic.
@DataNexus, thanks for posting this idea! I came to a similar conclusion. Essentially all deposits within some initial period go into a bootstrapping pool, and this pool is then used to make the first buy into the curation bonding curve. All pool depositors get an equal price for curation shares.
One issue is that this potentially creates a much larger initial buy size, which slightly heightens an economic attack vector (which exists anyway): if initial pool depositors can add their funds to the pool, and then withdraw those funds immediately after the pool bootstraps the bonding curve (at 1:1, since immediately after the conversion, the bonding curve is at the 1:1 redemption floor), then that creates an opportunity for initial pool depositors to influence the subgraph’s curation economics (i.e. the point at which the bonding curve kicks in) with minimal cost outside of the curation tax. It’s a griefing attack of sorts. This may not be a big issue though given the curation tax.
In terms of the wider protocol, even while the subgraph curation is in bootstrapping pool phase, both signalled tokens and signal shares (key datapoints) can still be reported and relied upon, they’d just imply an equal share price for all depositors, rather than the typical bonding curve dynamics which would only kick in after conversion to the curve. So even in the initial period (e.g. 2 days), indexers can rely on reported signal to begin indexing the subgraph and serving queries.
Definitely not an expert on these things though, so looking forward to other folks weighing in.
I would like to offer my support for DataNexus’s show room idea. I feel like this is the only true way to counteract the bot whose only advantage is speed. Whatever the final decision to address the issue, I believe it has to remove rewarding being absolutely first with no knowledge of what you are even curating. Devs have a deploy and signal being first is okay because they know what they are curating, but there shouldn’t be rewards waiting for whoever blindly gets in next.
Another major issue that I have encountered is Pickle Finance (Polygon) deleting their subgraph. This effectively burned all the GRT curated on the subgraph? This was a subgraph confirmed to be legitimate by the devs. This puts curators in a position to have to have 100% trust in the developers not to do something I am not sure they know could potentially burn thousands of GRT with a few clicks.
I am an full time investor, which is another way of saying I measure risk vs reward for a living and I unfortunately have to say with the current state of affairs there is absolutely no way I could justify investing any meaningful capital to curating.
Create Curator reputation score:
Some good thoughts in this thread so far trying to address the “good behavior curator” catch 22 (the system now allows short term profit taking and somehow punishes the desired long term curation).
In this sense a “curator score” system could be useful.
A few examples:
You will not able to cash out quick until you reach a certain score where you’ve shown to be a long term player. This would limit bots and newly created bot wallets from “rug pulling”.
If you cash out quick a few times quick then your score lowers, whereas protocol positive behavior gets incentives in the score. This would continue to allow all curators to take profit but not 5 times in a row.
A higher score could provide privileges with new subgraphs and a lower score would put you in a waiting room for example.
A lot of ways to make this work, a lot of ideas here.
Let me know your thoughts.
An initial questionnaire could check the basic knowledge, eliminate bots and create risks awareness.
I like the idea of having curator reputation too, although to me the bonding curve itself is the issue since it incentivizes people to get in as quickly as possible. My view is that a reputation score that drives the number of shares you get per grt solves this problem directly. I think the idea of lockups/thawing periods could work too, I just personally like changing the shares per grt mechanism rather than putting fixes on top of it, but that might be easier given the bonding curve already exists
That being said, I think anything that gives some people more shares per grt than other people is something like a skewed democratic protocol (which maybe is fine or even ideal) versus something that gives everyone an equal amount of shares per grt (which seems more purely democratic but potentially less optimized for the goal)
I would just like to update that the GRT is NOT burned. Shoutout to Bondsmith and everyone who helped me! Thank you! If this happens to you the solution that worked for me was the following.
Step 3: Put the graph account as 0xacfe4511ce883c14c4ea40563f176c3c09b4c47c with subgraphNumber = 1 (Note this is for Pickle Polygon, it would change if it’s a different subgraph I believe)
Step 4: Write the txn (you can connect Etherscan to your metamask wallet)
Whenever a Subgraph is deprecated by the owner, all the signal is sold back for tokens. By using the withdraw function you can take back your tokens deposited under the subgraph.
Definitely in favor of better tools for Curators to verify subgraphs, and perhaps for deployers or projects to provide more assurance they are legitimate, will be maintained, or are experimental, etc. In addition to a communication channel with subgraph developers, I believe there are automated ways of determining activity in github that could be useful. Of course, that is only an indication, and it seems common for a subgraph to appear and not be updated for long periods, but perhaps the surrounding activity in github is useful? No substitute for direct communication, however. Perhaps the developers/deployers need to be encouraged to communicate with curators?
