The higher the risk, the higher the APY should be.
I see not only the risk of holding / staking PRE to the node, but also the risk of beeing unable to close a node and sell the PRE whenever I want.
As a Presearch node runner you can’t just execute a smart contract function on-chain to remove the node stake and get the PRE tokens back. Instead you have this super intransparent and super slow withdrawl process.
Also, keep in mind that good servers are not free for node runners.
I understand.
The fact that withdrawing PRE from the system for node runners is opaque is definitely something very stupid and should have been addressed a long time ago. We would be wise to apply a lot of pressure on the team to make this as simple as a contract call in the near future. I would hope that part of the forever talked about chain migration will make this much more possible to fix.
Outside of that issue, I would simply say - show me an investment that has any kind of APY like what Presearch currently pays that isn’t either a scam by design or complete garbage headed off a cliff. There isn’t any I know of - if you know of one that isn’t that - by all means you should move your capital there.
The fact is that Presearch is not really a crypto project. A point Tim makes correctly. Presearch has a proven and viable business model, something almost no other crypto projects can claim. And, the project is extremely undervalued due to historical execution failures. This means that the upside is huge assuming the team can get enough runway to execute and delivers. Reducing node expense costs gives them that runway to get cashflow neutral/positive.
Of course there are a lot of opportunity costs and risks some of which you have defined. But the greatest risk currently is everyone giving up on PRE because the token price can’t stabilize due to inflation used to pay node runners. If that happens its game over for the project and then none of the risks you mention will matter anyway.
From what I can gather from Tim’s comments the current plan for nodes is a flat cut in $ terms to the reward pool starting 1 September, going from 20k/day down to $18,500/day. The cut will be $1500 to the reward pool in September and continue to be cut by another $1500 every month until some equilibrium is reached with searches and income to the project.
This is exactly what I described as the worst way to cut rewards for nodes. Its simple sure, but it is lazy and thoughtless.
All this method will do is reduce rewards equally for everyone. This will destroy quality and location diversity of nodes. Current node runners will stop all their quality nodes and switch to cheaper less reliable nodes. The unintended consequence being poor performance for users of Presearch just as you are trying to ramp up new users. Users will try it and some will get slow responses or failed attempts and wonder why they would ever use this search provider again. That is not how you entice people to stick with presearch.
Instead of cutting rewards the lazy way a rework of the reward system should be considered. I made a thoughtful proposal here
A scaled rewards implementation would allow the project to cut rewards by the same planned amount each month but ensure higher quality, longer owned nodes (up to a certain number), different jurisdictions, providers, diversified users (maybe initially up to 1k nodes per user are prioritized this way and any above 1k would go to the bottom of the list to ensure further decentralization and ownership of nodes), etc. This competitive model and factors would provide the fairest most competitive distribution of nodes.
Think of it like this: the factors would place certain nodes in a fully rewarded pool and the rest of the nodes in a scaled rewards pool. Of the $18,500/day in node rewards perhaps $15k is allocated to the fully rewarded pool and $3,500 to the scaled pool. The scaled pool would take the same factors and ranking into account but these nodes would be scaled in terms of rewards a few getting close to full rewards and some getting next to zero rewards with everything in between.
This would immediately show where your nodes stand and those getting next to nothing are likely the ones that will get consolidated or turned off first ensuring quality nodes remain to support the network. This approach requires backend development changes but is required moving forward for the project to maintain competitiveness and quality service.
Entities or users with over 1,000 nodes may just save their lower prioritized node keys and shutdown a bunch of nodes solving the cost problem immediately or very rapidly. These entities/users would be able to spin up new nodes with their old keys and scale with the network having their nodes easily break into the fully rewarded pool at a later date when that 1k limit is moved higher or the searches and income is able to scale.
A couple notes from the Friday update:
The yield rates at .03 PRE are fictional and have never been paid to any users. There have always been a floor price of .07 to ensure too much pre is not leaving the treasury. Also those reward yields were maybe in terms of PRE not in $ terms. In dollar terms yields would be all over the place based on your initial investment some purchased PRE at .22 + so their yields have been miserable in dollar terms.
4 PRE/day *30 days = 120 PRE/mo * .035 = $4.2 per month. Most quality nodes like Oracle, Digital Ocean, AWS, VULTR etc are $5-10/month or more most of us at these prices are already running nodes at a loss. That is a fact and under current planned flat reduction those quality nodes will be the first to go away.
The above is what I think is the best long term solution that would be able to scale with quality as the network demands.
However, another simple solution better than the planned flat cut would be to scale back the grandfathered nodes rewards. I estimate there are likely 25-50k grandfathered nodes (1k and 2k). If in September those grandfathered nodes are the ones that are cut by the $1500 it would force those users to either buy PRE to top up or begin to use rewards to stake them up to 4k for full rewards.
This approach would be much easier to implement than my above long term solution but runs a limited risk that it may or may not fully reduce the costs to an equilibrium point. As it would be uncertain how many node runners would reduce/consolidate nodes or if they would buy PRE or restake all rewards to top up their grandfathered nodes to 4k stake. Doing this in September instead of a flat cut to all might work better than a flat cut from a quality preservation perspective.
Nodes that don’t top up with PRE to 4k starting in SEP will get much less rewards 1k nodes half of what the 2k would get and if not purchased to top up it may take some considerable time to roll rewards to stake up to 4k and in the mean time those nodes would take the cost cutting hits. It seems harsh and it goes against my own interests but 1k nodes would top up to 2k first or be discontinued, then 2k to 4k would be the next prioritization. It wouldn’t end grandfathered nodes but those that don’t stake up soonest would start to lose more and more from the cuts.
But at least in this model as compared to a lazy flat cut this gives users more optionality to choose to preserve their highest quality or most expensive nodes first. Allowing them time and availability to handle the lower cost nodes in the out months.
I think the flat cut is a very bad decision.
Like I’m said I’m a node operator since the end of 2021. I started with one node. This summer I invested in more nodes, because I like the project, and I like utility nodes. My nodes have / had a reliability score between 85 - 90. I can tell you to hire an VPS with these scores is expensive. Now I scaled down to 2 nodes because in make no sense cost wise to run them. I already operated the nodes with a lose. Also thinking of searching for cheaper hosting. I think it is for starting operator hard to do breakeven or to be profitable with good quality nodes. To be honest at the moment I have mixed feelings about this project. Of course I do understand that the project must be sustainable that is in every bodies interest. I hope you don’t mind that I posted my feelings and thoughts.
Of course we don’t mind the community that is we are all having similar concerns and it would behoove Tim, Colin, Trey, and the team to hear more of our voices and concerns. They need to listen more and get back in alignment with the vision decentralization and the community.
Who do you think brings on new users? some may trickle in from ads but the vast majority come after hearing and seeing multiple times and especially from excited community members sharing with their circles of influence. If the community doesn’t feel appreciated or excited about the future there is nothing for them to share. This project needs a strong vibrant community to thrive and survive over the long run. The sooner they figure that out the better for the project.
Well, in fact, this way of doing it was quite accepted, of course, not by some people, but it is the measure that saw the most appropriate team.
we will reduce the rewards until we reach equilibrium but as monetization further improves (both from better relationships with ad publishers and from an increase in the number of searches) we will increase node rewards.
I would love to see rewards increase to more than are now — even much more.
Thank you for this explanation. It is much appreciated. It gave me some insight how it is calculated precisely.
This is all a great explanation and breakdown of theoretical rewards earnings but from my experience and the API numbers that i periodically review this doesn’t ALL hold up. Yes staking has a clear correlation with rewards example 4k earns on average higher than 2k stake but on the quality side of the equation which I think is more important there doesn’t appear to be a clear breakout.
For example my nodes with scores of 89-92 are not always higher than nodes with scores of 75-82 even when the stakes are exactly the same.
Highest rated and performing nodes and not always my highest rewarded and conversely my worst performing nodes are not always the nodes that earn the lowest as they should be.
What I am suggesting is that a flat cut to the total reward pool for all nodes is easier, yes obviously. However, because quality, decentralization, time, resilience, and other factors are not being weighed appropriately all this simple approach does is reduce everyone’s rewards forcing lower quality for the sake of economics.
The best approach would be for the system to identify characteristics that are most highly valued by the network and weighted accordingly with rewards. This is in-line with the vision which is to reward according to the value given to the network.
If the model was changed to reflect this the network would be more decentralized, more resilient, fairer, and importantly higher quality.
I get best and perfect is the enemy of good enough but this will eventually need to be done and might as well start to discuss the right factors and weighting now to start building a testnet version since this could take some time.
In the meantime the second proposal which was mentioned first by other community members should still be easy to implement but gives more flexibility than a flat cut to the whole pool and should give more flexibility to preserving quality nodes.
My assumptions:
-Most nodes are grandfathered nodes probably 25-50k of the ~73k
-Most quality nodes were likely brought on under a 4k stake although I am sure there a some not too many under lower stakes
-If the $1500 cut each month could be applied to grandfathered nodes only and not all nodes those with a 4k stake min would get a comparatively much higher reward than the grandfathered nodes because stake is obviously higher already higher rewarded on average but the cuts would not affect those 4k nodes and disproportionately affect the grandfathered nodes.
This is against my own interests because vast majority of my nodes are grandfathered. At the same time this approach would give me personally more flexibility to preserve quality and manage my consolidation of nodes more efficiently. If I know some of my lower quality nodes are coming up for renewal I could sacrifice those by not increasing their stake and taking the lower rewards for a short duration then let them go away, whereas if I have other higher quality higher priced nodes I could stake them up to 4k and may still allow them to be viable. Also longer term contracts could be staked up to 4k to ensure higher rewards for their longer duration of prepaid service. This is only a slight tweak to the currently proposed flat cuts but provides more flexibility to node runners. Otherwise all node rewards are cut across the board and makes higher priced and higher quality nodes simply not viable. This should be done in conjunction with discussions and development of a longer term rewards structure I previously mentioned. If my assumptions are all wrong this might not be the best approach
If the high number of nodes is the problem that should be solved in a fair way that ensures highest benefits to the platform.
-node considerations -this is what I am talking about when I say how you reduce node rewards and how you move forward with node rewards to incentivize things that are obviously important and necessary for the project to survive and thrive.
| Quality | Reliability score for now should play a bigger role; but eventually will need to include more things for other node roles like GPU, CPU processing power, NMVE SSD space, dedicated vs shared, etc. |
|---|---|
| Stake | gives users some say in what nodes they want higher rewarded but if min stake is on this should be less of a factor than quality |
| loyalty/ service time | If you have been running longer and all other things are equal you should be prioritized for rewards |
| Vps provider percentage | Jurisdiction of providers and number of nodes/provider should be considered because these become attack vectors or areas of risk to the project more decentralized the better especially if quality is the same. |
| Location/ Jurisdiction of VPS or node (national and state) | More counties and even down to the state level of decentralization the better |
| Number of nodes per user | Should be limited at least for now. This ensures broader spread and decentralization of the nodes and less risk of a bad actors or any one entity controlling too many nodes. |
I bet this last item alone if implemented even at a relatively high 1k node limit per user would probably bring the number of nodes drastically lower while benefiting all node runners but the .1 percent. I don’t want to limit anyone but if the average node runners just leave the .1 % that can afford to wait it out will be a much bigger portion of operating nodes instead of a fair decentralized balance of node operators. This can always be increased in the future and if loyalty/time is also a consideration those who save their node keys would easily be able to spin more up in the future and have priority over newer node runners. Until an equilibrium is reached at which time those newer node runners would begin to break into the fully rewarded pool.
How much better would this be for the project to be able to show that instead of ~50 users controlling 70-80% of the “decentralized” nodes we could show that the user distribution of the decentralized back bone of the network is very fairly decentralized?
Exactly this. If there would be a DAO, I would vote for this. 
It would be nice though to get some offical numbers from Presearch to do our calculations on.
I would prefer a relatively simple solution if it’s possible. For example if a number of people in one country using Presearch is up then more requests in the network would go to a node located closer. It would get higher rewards. Then the network regulates itself which as Adam Smith explained is usually better. The more users Presearch has in different locations the more decentralized the network would become.
I also think old nodes shouldn’t have advantage over new ones. Loyalty is important but this might create some barriers to competition and new entries. Also it’s possible that the biggest node operaters run older nodes.
Thanks for your thoughts/contributions.
A couple comments:
Agree except if the only nodes in that country or region are lesser quality why would we want to feed those nodes to those users if they could be getting better performance?
Absolutely! This would be great to incentivize and also track. Network.presearch should track this at least by the gateway general locations but eventually possibly by country as well.
I differ in opinion and perspective on your first sentence and you may as well in the future when you become an OG and there are millions of new combers competing with you for rewards. I agree this could create barriers to entry but only if the project doesn’t grow if it grows the earlier an adopter and supporter the better to a point. If you limit the number of nodes per user this opens the door tor so many more people. And as the network grows those limits can be increased proportionally to the growth. If 1k nodes per user is too high or too low we can easily adjust for a better user to node operator distribution. But I think the user limit for nodes breaks the barrier to entry concerns you have while also rewarding early adopters that have gotten the project to this stage.
I like simple allegories, sometimes a bit easy, but there you go…
Although they contributed to the expansion of the territory and the brand, and took a certain risk at the time, do the owners of McDonald’s restaurants from the 70s have a grandfather clause to no longer invest in renovations, keep the old menu, and the drive-in? I don’t think so.
What’s certain is that the former owners made their money!
No hard feelings, Ciao !
Just waiting for Colin, Tim, or the team to explain to the community why these node considerations are not a good idea to protect the project and improve performance.
Something like this might make more sense visually for people to understand what I am recommending:
This will ensure that cuts don’t degrade network quality or decentralization and ensures moving forward there will be constant competition to be rewarded for factors that are important to the project.
Assuming this will take time to implement; I figured I would put the idea out to get community/team feedback so we can come to a consensus sooner on best way to move forward. So development can start, in the meantime without changing anything with the current reward structure a simple node limit would be the most fair and best way to take the anticipated node reward cuts while getting us closer to this ultimate goal.
To reiterate - If the node runners are all going to take a cut in rewards starting 01 SEP the best way to absorb the cut without affecting 99% of the decentralized node runners is to limit the number of nodes rewarded per user!
This not only reduces the number of nodes being rewarded which accomidates the cut but still allows vast majority of node runners to continue to earn a similar reward, enough income to cover the costs. But this approach also has an added benefit in that it necessarily decentralizes the node ownership reducing centralization by limiting the amount of nodes controlled by any 1 user/person/entity.
//
For transparency to the community why not disclose the number of users running nodes? Then show the the top 5%, 1%, or .1% of those users running the most nodes? Obviously you don’t have to use usernames or anything just raw numbers. There is nothing personal about this.
I think what we will find is that 1% of the users running nodes probably make up 25-50% of the total nodes. If I am correct in this assumption why not on 01 SEP do the planned cut to $18,500 for the reward pool but just also impose a node limit on that 1% of node runners such that the decrease in the # of nodes by the 1% would allow the rewards to be maintained or even increase slightly for the 99%. Then in month 2 continue to cut the rewards down to $17,000 and impose another limit on nodes per user to retain the reward structure for the 99%… Eventually the node ownership will be either completely decentralized or equilibrium is met with income vs outflow. Keep in mind if the network scales these users with older longer running nodes would be able to spin up in the future with a prioritization as long as they are not at the increased scaled node limits. Meaning they can get back in later.
I think this is the most appropriate place to post this, which has to do with suggestions,
A simple solution to reduce the number of nodes would be to increase the number of PRE to start a node. It should be a significant amount such as 40 -50,000 PRE to start a node. Current nodes could be grandfathered making it easier to sell.
If you look at the top 500 Crypto projects, we are by far a bargain as far as the USD amount needed to start a node. Many of them would be 25-100,000 USD to start a node. As of today a Presearch node would cost 84.00 USD.
Raising the number to 40-50,000 PRE to start a node would also slow the rate of new nodes being generated by node rewards. At today’s pricing with the suggested increased fees a new node can be started @ 1000.00 USD. Still a bargain.
I definitely support an increased min stake for nodes even if only 8k for now. Bottom line the amount of nodes staked and online determines the reward for all nodes. More nodes = less rewards but possibly more search capacity; alternatively, less nodes = more rewards per node and possibly less search capacity.
I have previously proposed for Node rewards to better reflect and support the needs of the network. I also recommended the team better understand and inform the community through transparency on how many nodes are required to sustainably and reliably service x million searches per day. Since this has yet to be disclosed by the Team the potential concern in changing the node min stake to 40k is that this measure could significantly limit the amount of new nodes that are able to come online.
We know there are 339M staked (~34M on keywords/other) (~305M on rewardable stakes to include 7.7M on search and 297.7M on nodes). This means the vast majority of PRE staked is being rewarded = PRE outflows from Treasury to the tune of ~4.5M/mo + 6.5M airdrops/mo or a total of ~66M+ assuming no changes over the next 6 months. With 339M staked this also means there is a theoretic 411M PRE available to work with and an additional 250M beyond that before they reach the 1B max supply. With 411M to work with assuming a 40k new min stake that would only allow up to 10,275 additional nodes to be able to come online assuming grandfathered nodes ~67k remain and all 411M PRE was eventually staked on nodes vs search vs keywords vs other exchanges etc. As I said previously how many nodes are required to reliably sustain x million searches per day? Right now we have 67k servicing less than 1M but has also been successful up to 5M. If we wanted to grow to 50-100M searches a day would the additional 10k nodes be enough? Whereas an increase to 8K not only would be inline with the current increases so far 1k, 2k, 4k, … but also would theoretically support up to an additional 51k nodes. But again we don’t know what is optimal because the Team has either not figured it out or shared that information with the community.
Another important point: When the team described PRE outflows and inflows in this past AMA those figures only accounted for PRE leaving or coming onto the platform to/from personal wallets, this tells a story and IMHO not a very important one, that story could also change on a dime from week to week providing even less value. This inflow outflow metric is simply not nearly as relevant as the more important PRE inflows and outflows to and from the Presearch Treasury (This is the Metric that should be tracked as it has led to the near failure of PREsearch, change in leadership, the recent decision for a 1B max supply, and the recent 250M minted). To this more important metric as explained above, over the next 6months there will likely be 66M+ PRE outflows from Treasury (assuming no additional rewardable stakes which is highly unlikely) and critically important, precisely ZERO inflows to the Treasury as there are NO quality consumptive utilities. In fact, inflows to the platform as they are currently tracking if placed on rewardable stakes only increases the PRE outflows from Treasury, reducing the runway for the project. With all the reduction of rewards and increasing the available Treasury supply by another 250M PRE, I estimate there is now approximately 2+ years of runway left. Obviously, if PRE price can increase and be sustained over .07 cents this would extend the runway (due to PRE reward reductions), there would still be an additional 250M emergency PRE they could mint before hitting the 1B cap, and lastly, if they focus, develop and implement quality non-rewardable stake and consumptive utilities this could slow the treasury outflows or eventually create NET Inflows regardless of what the PRE price does. This last point is the point I have been attempting to make for the past 3 years and why I am so concerned that these are added and prioritized on the roadmap.
