Yes and CF has 2 objectives: 1. Benefit decentralisation. 2. Benefit tool builders.
In terms of how CF would assess “benefiting decentralisation”: Well maybe they should review the decentralisation index research paper that should be published soon.
The same way they vet tool builders. By doing due diligence. It might involve some work. They could even interview people in person if they want.
OK. My bad. Those were imprecisely chosen words. The pool “controls” the Ada in the sense that other people’s Ada is delegated to the pool which enables that pool to gain more “control” over the block production. You knew what I meant. That was a cheap shot.
Seriously, what is it with the straw men arguments? Nobody said anything about whether it was the main source of funding or not. CF can pay as little or as much as they deem appropriate. I am simply making the argument that forgoing some rewards is no different to directly paying someone a portion of your earned rewards.
I agree that CF could run their own pools, and directly pay the tool builders they want to support, and at any funding proportion they choose. In fact, maybe that is what they should do.
Significantly flawwed in the proclamations that it’ll help the network and interestingly absent of any indication of their pursuit of higher returns with less work.
Unless CF doesn’t actually receive rewards for delegating.
What would take for the foundation to reconsider the new delegation strategy?
There is an obvious negative response (including mine) on the decision and how it was taken.
We should not be put in the position to “trust” the Selection and Application processes (points 4 and 6), especially if there will be more rewards per pool and less pools.
The job of the foundation should be to assist in the overall decentralization of the network, and not to put itself in the middle of it.
How many wallets are used for this delegation which is currently going to 46 pools?
Which wallet, Daedalus or something else?
Now that real multi-delegation is here, you could literally triple the pools and still protect the rewards you’re seeking.
Not only does that show an act and understanding of decentralization but it also not only benefits almost 100 additional steak pools, but it really does wonders for the CF reputation which is crumbling by the minute.
That reward-seeking and not focussing is the motivation is your theory. If they would really seek profit, they would do fully pledged private pools. Seeing this drama unfold that would probably be best.
But, anyway, why do you think that Lace’s multi-delegation changes anything regarding rewards? That is not the case at all.
What Lace is doing was always possible on the command line and in manually written tools and it is actually not that different from staking to multiple pools with multiple wallets or multiple accounts (possible since forever). The only difference is the semi-automatic rebalancing (which is quite irrelevant in this case of just letting the stakes stay there for months) and confusing dApps and users by not having that neatly separated in different accounts, but presented as one account with multiple stake keys.
Be careful with relays behind DNS names with valency > 1 (multiple A/AAAA records and therefore IP addresses for a single DNS name). Adastat shows them but Cardanoscan does not.
For example IOG1 relay on-chain is just relays-new.cardano-mainnet.iohk.io:3001.
I run 4 nodes, bare-metal, cloud backups - but I only declare one on-chain - i deliberately only declare one relay on chain. Relays on-chain often get spammed by entities trying to get quick propagation for things like fast DEX aggregators… If it is a requirement I will oblige - but the registration will take two epochs to become active.
The original requirements from Cardano Foundation's New Delegation Methodology: Supporting the Architects of the Future (October 2021) remain unaffected by these changes. They could be summarized as: we aim to support pools that focus on building infrastructure, setting standards, and developing tools (ideally open source). Additionally, we prioritize those who assist others in a manner that yields a sustainable impact on the Cardano Ecosystem.
While developers are a key component, this support is not limited only to them; it extends to any entity that contributes meaningfully to the ecosystem rather than merely enriching themselves or solely promoting their brand.
One idea in case of supporting MPO is still a thing and CF will decide to move forward.
Support to MPOs should at least be restricted proportionally the inverse to the amount of relevance they already had on the network (75%).
Today 25% of the total stake on the network is represented by single SPOs, so let’s set that CF could only delegate 25% of their treasure to MPOs and the remaining 75% for single SPOs.
Not that they need or want to do those 100% delegations to MPOs, but as a limitation to force more impact on single SPOs.
Do people realise how messy and ungovernable this will become?
We are watching one of our allies get dismembered here. If we let the concept of the K parameter get killed then every multi-pool operator will say they are honorable no matter their size. We will all be going around arguing about different poorly defined metrics.
We have the K parameter now which indicates what should be the maximum size of a single pool operator receiving stake from others. Let’s adjust that value to what we think is reasonable. Hell, reduce it to 50 if that is what CF thinks is reasonable, but don’t kill the meaning of K or we will all regret it.
https://cardanofoundation.org/en/our-mission/ gives slightly different objectives. Anyway, my argument that you seem to not have wanted to take up is that these delegations are not necessarily their core business, but something they need to do anyway and want to do in a way that makes sense.
To me appreciating and supporting outstanding contributors to the community makes sense. And it then also makes sense to me to allow it to be more meaningful and focussed by being fewer, larger, and longer and not exclude applicants just because they happen to have two pools.
I’d still like to understand what you and other critics really want.
Is it enough to go back to the delegation strategy as it was before as @Adrem wrote here?
Would you (and others) also want the time extension and the fewer, larger change gone? Or even change it in the other direction and support more with smaller stakes? Even at the cost of then also supporting operators with not that impressive contributions rather randomly?
Alluded to here:
Or do you want it – in accordance with your “shouldn’t be conflated” argumentation that got some acclaim – to be modified to support (single) pools regardless if they do something else?
Would you go by “best” pools according to the RSS paper game theory – highest pledges, lowest pool costs and margins?
Or would you randomly draw from all applying single pools?
Also here: longer, fewer, larger? Or even more and smaller?
Or would you even prefer CF to just run their own private pools and not delegate to others at all?
You seem to have an unwavering belief in IOG-funded research. I do not.
But even if they come up with something remarkable (I’d expect them, e.g., to take a hard look at core development decentralisation where Cardano does not particularly shine, but that’s off-topic here) do you think that a bird’s-eye view comparing different chains will go into enough detail to derive precise guidance from it? Something else than minimum attack vector, Nakamoto coefficient?
By the way:
MAV is a quite reasonable metric. And to improve decentralisation in this metric, stake has to move from the top 50% to the lower 50% of pools or pool groups. And it doesn’t matter if those are single or multi-pools, just that they are considerably smaller than the current MAV groups.
Let’s kill it! It’s a poorly designed parameter that doesn’t do what it was supposed to do at all. And it still won’t do even if we in nerve-wracking debate fights try to adjust that arbitrary number plucked from the air by our overlords long ago.
You already used that wording earlier multiple times:
And it is one of the common misconceptions to explain to beginners: “No, you do not give up control over your ADA! They stay in your wallet! You can spend them or get more at any time! If someone asks you to send ADA to stake it’s a scammer!” And there are even sometimes “My ADA are gone! Did the pool I staked to steal them?!?” questions.
So, no, it’s not a cheap shot. I find it important to not let this gross misconception slip through! Especially if the only reason I see to employ it is to let the whole matter sound more dramatic than it is.
That was your straw man!
Those two paragraphs – which that was a direct reply to – only make sense if you are implying that this delegation shall be the main source of funding for some development. The point of my previous post was that these delegations can only be an appreciation and not finance anyone completely – even if CF makes them more meaningful by being larger and longer.
Great, then we are finally in agreement. The staking mechanism should be geared towards ensuring a decentralised set of appropriately sized stake pools where no single person “controls” too much of the block production. And what is considered appropriate in size? Well, that is supposed to be the K parameter, at least according to the research and design papers.
Yes, I said controls. And I mean controls in the sense that if a single person has too much Ada staked to their pool (or group of pools) then they will gain too much CONTROL over the block production of the Carano blockchain.
My total beef with CF’s new staking policy revolves around decentralisation, how to measure and target pool sizes, and the undermining of what the K parameter means.
Has anyone from CF asked the design architects, including Aggelos or Lars, what they think about the K parameter being deliberately undermined by our founding entity and voice of the community?
What will the CF do if the pending “Decentralisation Index” research paper highlights Cardano’s K parameter as a way to measure or target single operator pool size?
Maybe CF should check to see if it is a good idea before they kill the K parameter’s meaning.
a0 to 0.0 (High leverage is Sybil, don’t be mislead)
Let the community vote on K, honor the vote.
IOG runs 1 pool, delegates other ADA to the lowest leverage K-number of single pools.
CF runs 1 pool, delegates other ADA to the lowest leverage K-number single pools.
Community vote to HF enact minPoolMargin at voted amount (0.1 - 5% )
Community vote to HF remove minPoolCost a0 K, replace with L, maximumPledgeLeverage.
After a few years we are currently at step 0.5 of my 7-step CIP-50 recommendation. COI Disclosure: All-time ADA HODL’er, sold 0 ADA (20231018), but am architecting Egalcoin.
Then you just register two on chain and keep two private if you wan’t to be eligible…
Declaring them on chain will be necessary when p2p will become the main way anyway I thought.
