However, in my case the pledge is 10 ada since I was keeping it small. Our active pledge is therefore way greater than this 10.
I therefore have a few questions.
1.) Is the committed pledge or active pledge used towards reward calculations?
2.) I noticed the owner accounts DO NOT have their delegation rewards automatically put into their associated payment addresses. This appears to be by design. Am I to assume that the reward operator is therefore responsible for, the 340ada epoch reward, the 50% margin fee from delegators AND the normal delegation rewards that the owners might have. For example I made one of the owners have 10000 ADA but it has not received any delegation rewards. I have to conclude that this was sent to the reward address?
3.)If the reward address does indeed get ALL rewards, then what is the best way to calculate what to pay out to the owners then? Should I instead put the minimum amount for a pledge in the owner account and instead have me and my friend delegate separately? My thinking here is the delegation portion of the reward would be automatically calculated this way. The only issue then is the 50% margin would have to be accounted for to make for a fair payout, since the operator reward account would get the 50% margin now from the delegation of the 10,000 ada lets say. Which should technically be paid out to my friend and me as we are both owners.
You can see how this gets really complicated and sticky really fast. What solutions/ideas do you guys have regarding this. Am I correct in my understanding of how all this works?
If my question is difficult to understand or I can post anything to help it make more sense let me know!
I’m thinking the best solution at this point is to…
1.) Have the minimum amounts of ADA for the owners to meet the committed pledge then don’t touch those owner addresses.
2.) Create 2 separate addresses to hold the bulk of the ADA and then have them delegate to the pool. I am then going to write a script to calculate how many epochs won at least 1 block since the last time a payout occurred and return back the 50% margin that was taken to return back to the owners.
Note that 50% margin is just used for experiment purposes here on preview network.
I read your question a couple of days ago but I didn’t want to answer because I am not totally sure about the intricacies and didn’t want to confuse things. This response is off the top of my head so you should double check yourself.
The committed pledge is used in the formula in relation to the a0 figure. The value in the wallet which is above the committed pledge value is still delegated to the pool but it acts like normal delegation in that you are paid rewards for it but it doesn’t produce extra rewards in terms of the a0 (pledge influence) parameter.
Rewards for the operators (owner accounts) are paid into the reward account which means that the owners need to trust each other. The owners need to divvy up the rewards paid to the reward account in accordance with their agreement on running the stake pool. The owner accounts are used to total the active pledge and this is checked every epoch to ensure it is at least equal to the “committed pledge” amount. If the amount in the owner accounts totals to less than the committed pledge then the pledge is not met and any blocks produced by the pool that epoch will receive no rewards for anyone (including the delegators).
You need to reach an agreement between the owners on however you want to divvy up the rewards. For example if one owner provides 2/3 of the pledge then maybe it is fair that she gets 2/3 of the rewards. But maybe if the owner that supplied only 1/3 of the pledge is doing all the work of running the pool then maybe that person should get most of the rewards. The agreement is up to the owners.
The advantage of having multiple owner accounts is that separate owners can maintain control over their pledged Ada and can therefore withdraw it if there is a disagreement about the running of the pool. But they need to trust each other to properly divvy up the rewards from the reward account. Presumably the owners know each other, and where they live, so they can institute legal action in the real world if the rewards are not split up in accordance with their agreement. The system has been designed this way because really the running of a pool is supposed to be by one entity. This single entity can still be a group of people but the individuals should know each other in the real world because the protocol is not going to sort out any disputes between owners.
If the owners have minimal trust then maybe it is best to split the rewards after every epoch in accordance with the agreement and transfer the values to the owner accounts. This will involve a transaction with associated blockchain fees every epoch but then the most an owner can lose if a dispute arises is 2 epochs worth of rewards (for the individuals that don’t control the reward account). If you really wanted to make the owner agreement more trustless then you could build a smart contract to manage the reward account and code the agreement into it.
I guess my biggest question is does the delegation rewards for the owner addresses ALSO go to the rewards account? I think it does from what I am seeing?
Thanks for eveything you wrote @Terminada . I plan on making tutorial videos on this later so I have been taking meticulous notes
Yes. That is my understanding. If you think about how the reward formula and pledge mechanism needs to work, then I think this makes sense. For example, imagine this scenario: Say your pool sets a pledge value of 100K Ada and one owner wallet has 50K and the other owner wallet has 150K. The pledged amount is met because the total of the owner wallets is 200K which is greater than the 100K value set in the pool certificate. But if the protocol was to pay only the value up to the pledge amount into the reward account, and the rest into the owner accounts, then how would it apportion the rewards on the extra 100K delegated by the owners? Also, the protocol knows nothing about the agreement between the different owners in terms of how they intended to run the pool and which owners were incurring which expenses. Thus, it makes sense to simply pay the total owner rewards into the one reward account and then let the owners sort out how they wanted to divvy up the rewards between themselves.
Furthermore it would be extra complexity if each wallet staking key could be associated with more than one reward address because you would need some extra mechanism to tell the protocol how you wanted rewards split between the different reward addresses.
Having things this way also makes sense in terms of the Cardano’s goal of having pools being run by one entity, because this tends to force the individuals within that one entity to behave like one entity, and trust each other like one entity. The more you look into the Cardano design the more respect you tend to develop for the IOG designers. We all tend to complain a lot, including me at times, but it is very clear that the designers have gotten a lot right.