Rewards for a pool are paid into a single rewards account controlled by the pool operator. If the pool operator and pool owner(s) are different people, we need to properly calculate a way to split rewards between all the owners.
How can we calculate the total overall rewards a pool made in the last epoch? How do we calculate the delegated stake of each owner for that epoch? How can this be calculated retroactively if we need to look back at past epochs to see what the delegated stake was?
There are many complexities to ensure rewards get paid properly. For example, one owner might want their rewards sent to a separate account while another might want theirs re-invested in the owner’s pledge account.
If possible, this information should be available from cardano-cli. Running a heavyweight server like db-sync just to get some payment numbers is problematic.
What you’re asking for requires knowing the state of the chain, which the CLI inherently can’t know (it just knows the current ledger state, not the history). You should be able to use cardano-db-sync to get this data, or write your own blockchain crawler that tracks this information for you using the node protocol either in memory, a sqlite database, etc…
I am not sure I really get your question.
If you are in a multi-owner setup, my first go would be this one :
The reward account of the pool gets the ada rewards for the past epoch.
The operator takes back the fixed cost from this pot.
The rest is distributed to the owners following the % of their participation in the total pledge, minus whatever agreement that was in place (a special cut for the operator).
It sounds fairly easy to monitor epoch after epoch what should be done with the reward account.
Is there something that I am doing wrong here ?
Why should the protocol care about all these specific agreements you are mentioning ? Owners can do whatever they want with their rewards and the contract that binds operators and owners is happening off-chain, so …
you need the exact amount of stake for each owner at the moment the chain made the snapshot for the rewards in the next epoch. so, where to get this information the easiest way? also to get the amount of the poolMargin you need the total rewards the pool gets.
to make a nice report we would need:
real blocks created in epoch x
rewards earned for these x blocks
rewards for delegators
rewards for owners
rewards from poolCost and poolMargin
and than a list with the owner stake amount for that epoch (-1) and the rewards for each owner. the automated payout of these owner rewards is the smallest part
The problem mentioned in the first post results from a complex scheme that does not need to be that way in the first place. For example, why accept a pledge from a person that would not make a clear distinction between his/her pledge wallet and his/her normal shopping wallet. I mean here that the delegated amount of pledge should be fixed and stay constant - as long as the off-chain contract that binds operator and owner(s) stands. That way, the % are very easy to calculate after each rewards payments.
I would not feel safe to engage with an owner that would not understand the difference.
If the owners want to delegate extra ada to the pool but not as part of the pledge, fine. But I don’t see why they would be entitled to anything more than normal delegators for that specific portion. They can always use a wallet for which they control the rewards, as everyone else.
That is not true. I have for example a pledge delegator that wants the rewards on a different address, because of the tax laws in his country! Thats the reason he wants to use the pledge scheme instead of just delegating. And than i have 2-3 other pledge delegators, the want to re-stake automatically. But the payout of the rewards is also after the next epoch start. so the paid out rewards will count only for the epoch after the next epoch. So, the % of the pledge owners is not fixed at all.
Your owner wants the rewards to go in a different account ? Well great, since you have to do it manually, he/she can provide you with that address.
Some want to re-delegate automatically ? Awesome, you can pay them on the address of their choice, that would delegate to your pool anyway. Even when rewards are paid automatically, they will only be taken into account for the pool’s stake with the same lag phase as the first delegation. So I don’t really see any issue here.
Do you plan to dynamically arrange for owner(s) arrival and departure ?
Anyway, my point is this one: the protocol has no business in the arragements you want to construct in the real world. Otherwise that would undermine the requirement for off-chain trust in pledging.
Edit : Explorers and chain analysis are therefore your friends
I think you understand me wrong here. Yes, the pledge owners are stable, no plans for new arrivals or departures. But the amount of each pledge owner varies from epoch to epoch, because of the re-stake. And becasue of the “not” re-stake. This has nothing to do with trust, of course you need to have trust. But the percentage between the owners are not a fixed value.
A simplified version:
Start: Owner1 has 10000, Owner2 has 25000, Owner3 has also 25000 (but payout to an extra address)
Epoch x: Owner1 has 10010, Owner2 has 25025, Owner3 has 25000
Epoch y: Owner1 has 10020, Owner2 has 25050, Owner3 has 25000
Epoch z: Owner1 has 12300 (because he added some ADA to his fund), Owner2 has 25075, Owner3 has 25000
hmm, ok. so version 1 is to build a complicated chain analysis tool to get all the states. version 2 is to freeze the pledge amounts and not re-stake it directly to the pledge account. ok, version2 sounds more useful. also a monitoring tool for the pledge is needed. let me think about it…
So what you are saying is to not allow re-pledging from rewards. That will leave this pool at a disadvantage to others that are single owner/operator and just have the rewards re-delegated as additional pledge automatically.
This is a really tough question, but depends only on the agreement between the operator and owner(s).
It’s very hard to calculate it properly when you have multiple owners and they want handle their pledge’s reward differently.
The easiest is just have some agreement on their pledge share and op will send the rewards to some non pledge address based on those shares.
Example:
1st owner pledged 20% of the declared pledge in the cert to its pledge address(es)
2nd pledged 30% to its pledge address(es)
3rd pledged 50% to its pledge address(es)
And the op, after the reward distribution, sends out the rewards to different non-pledge owner addresses based on their shares (20%, 30%, 50%).
Cos, it will became a nightmare anyway, when they can add different amount of additional pledge, or just one wants take the reward (i…e. send to some non-pledge address) and the other want it to count as some additional pledge (i.e. sends it to the owners pledge addresses). It would be very hard to track these changes.
i’d have assumed the simplest solution (this would be done automatically programmatically keeping in mind all of those variables) would be what would make sense? our hand coded in marlowe …
This is a good topic. So what’s the latest understanding/method about handling the multiple pledges and their contributions. I would like to hear what kind of framework do you plan to put in place to track everything and pay.
I think the pledge amount should be updated only periodically after talking to your co-owners.
For myself, I’ve decided to go with simplicity. I’ll charge a flat fee to operate the pool and then the rest gets split among owners based on their amounts staked. In my case, I’ve also decided not to do multi-owner pools, so it’s just a simple transaction of 1.) flat fee to me and then 2.) the rest to the owner.
Of course, all of this is moot until we get a way for owners to pledge that they can trust. Dealing with CLI for an owner is out of the question in most cases. They would want to see their funds in Daedalus or Yoroi.
?
