Voting for default data feed providers

In thinking about how to set up an election for default data providers, I start from the point that what we need in the client is a list of data feed providers, along with URLs, signature URLs, address and the percentage of the votes the provider received.

To derive the percentage of votes for each provider I suggest that all data feed providers submit a motion that represents their candidacy to be a default data provider. It might say something like this:

Voting for this motion will increase the probability that provider A will be chosen as a default data feed provider upon a specific installation of B&C Exchange version 5. This represents the candidacy of provider A to become a default data feed provider.

While data feed providers will likely want to say why shareholders should vote for them, that shouldn’t be a part of the motion in my opinion.

The date at which votes should begin to be counted will be April 25th UTC. This means @Cybnate, @Cryptog, @crypto_coiner and any other candidate will need to post their motion well in advance of that so it can be added to clients and data feeds. And yes, of course each data feed provider will vote for itself and no other. That works to accurately reflect the real popularity of each feed. Voting will end when the 5.0 release is otherwise code complete. A minimum of 5000 blocks and a maximum of 20000 blocks of votes will be counted, starting on April 25th. Individual shareholders may vote for none, one, some or all of the competing default data feed motions.

A hypothetical example will clarify how votes are to be counted:

The release is code complete except for the default data feed voting results 12,000 blocks after the start of April 25th. Within those 12,000 blocks, provider A received 6000 votes while provider B received 4000 votes for their respective motions. This means that 60% of the time running through the client install, provider A will be selected as the default data feed provider while the other 40% of the time provider B would be selected initially by default.

Any data feed provider who receives even a single vote will be included in the 5.0 release as a default data provider.

For any release that occurs more than 90 days from the release of 5.0, a new vote will be held for default data feed providers.


Can there be any incentive for data feed providers? something like an extra minting reward?

1 Like

My B&C Exchange data feed thread:

1 Like

Rewards for data feed providers would be difficult to automate. It could be done easily manually (by just giving funds to a custodian who distributes them to the data feed providers), but we now have 4 data feed providers without providing any compensation. Compensation does not appear to be necessary to provide incentive to do the job. Being a data feed provider places people in a powerful and influential position and that seems to be sufficient incentive.


I posted this in another thread, but it might be something other shareholders need to know…

Wouldn’t default feed provider control almost half of the voting power? is there any way to prevent him/her from abusing this power other than shouting for -the already not paying attention- shareholders again to change their data feed provider?
This sounds too dangerous, what I am missing here?

Providers. There will be at least 4 default providers. Probably more, as i intend on throwing my hat in the ring. They will be chosen stochastically each time the client is downloaded.


I don’t know. To me being a datafeed proovider means haviing to read and really try to understand every motion and proposals in time, then read followup posts and come up own decisions. That is a lot of effort given the amount of complex / overlapping motions we have. That is the main reason I don’t apply for anyway.

That just provides a test for datafeed providers: every new motion gives a test question at the end and every datafeed provider send his/her answer by PM to a test manager who knows the correct answer from the author. Those feed providers who got a lot of wrong answers get low grades.

1 Like

Just like to say that this is certainly not my main driver, although a nice perk of the job. My key driver is ensuring a healthy ecosystem by providing shareholder support and setting an example and making it easier to own NuShares 24/7 when you are not 24/7 following all the discussions. When there are more than 5 datafeeds, I would consider withdrawing mine enabling me to have a bit more focus instead of having my attention spread out widely.


Data feed providers can save a lot of LAZY shareholders time.

1 Like

How would it work if you wanted or even needed to withdraw? Would a new version of the client need to be released, removing you as a default feed and moving other shareholders that are subscribed onto a different feed?

There should probably be a way for data feed providers to exit without requiring a new version release, removing them as an option. Like maybe the feed provider could enter in some setting, which triggers a pop up window in all subscribed clients letting them know that they need to select a new feed provider from the list because the one they are currently subscribed to is retiring.

The list would need to be able to auto-update as well. Maybe the setting you entered in above also triggers the removal of you as an option in everyone’s clients. I don’t know. I’m just trying to give ideas to the dev team so they can figure something out.

The simple answer would be:
implement frequency voting instead of default data feeds.
But I suppose implementing frequency voting is more complicated than implementing default data feeds.

1 Like

Can data feeds and frequency voting coexist?

Oh very much so. Frequency voting would allow you to subscribe to multiple data feeds at once. Also, you can let it find datafeeds that agree with the votes you manually set and partially subscribe the them automatically.

I could argue that data feeds are one of the best use cases for frequency voting. It’s like what JL is doing with the stochastic client downloads, but instead doing it every time someone mints a block.


When a datafeed retires it’s percentage of default installations would naturally lower to close to zero as soon as shareholders stop voting for it. So a retired datafeed wouldn’t be installed on new clients at least.
I agree it would be good to have a way to remove a datafeed, but to prevent abuse or undesired centralisation of power it will probably need to be by motion votes.

Here, you can find my application for being a default feed provider, btw.

1 Like

The voting is a one off thing. Dead data feeds are indeed a serious issue for this kind of hard coding of the providers.

1 Like

@crypto_coiner, @Nagalim, will you be applying as well?


1 Like

An idea: by default the wallet votes for any motion/grant that 2/3 or more of available feeds vote for. Weighting can still be used. Nu needs to make sure available default feeds are independent and reputable.
Or put the urls in nu.conf and update it in the distribution tar file when default feeds change. This might not be compatible with current design that feeds are stored in the wallet.