Exernal
Enable a split of the payout of owners pledge rewards and operator pool fees to different stake keys
By design a pool can have multiple owners and an operator. Each entity has its own stake key associated.
Currently the pledge rewards of multiple owners and the pool fees of the operator are accumulated in the same stake key. While there is no simple way to compute the exact contribution of the pledge rewards and the pool fees after the fact.
When a pool is run as a business and the pledge is provided by an outside entity then the problem arises that there is no clear cut separation of 1) the income generated by the rewards for the pledge and 2) the income generated by the pool fees.
Since the pledge is not owned by the company there are also tax implications transfering the rewards to the outside entity.
Additionally there is no simple accurate way to compute the exact amount that belongs to the outside entity.
Even in the case where the pledge is owned by the company a clear cut distinction between income generated as interest from pledge and income generated from pool fees is highly desirable from a tax perspective.
Proposed solution
A simple solution is to pay the pledge rewards directly to the owners stake keys and pay the pool fees to the operator rewards stake key at the protocol level.
this is interesting! thank you for starting this discussion!
This continues down the same path again of your other FR, removing the trust required for pledge which removes its core function. Pledging is a security mechanism designed to protect the network yet people keep suggesting ways to remove this security by easing the hurdles in place such as trust and knowing the people you pledge with that make it function. You may not see this however it leads down the same slippery slope. We should not be reducing network security and turning "Stake" pools into "pledge pools as a service" this opens the door for 51% attacks and suggestions like this make steps in that direction.
How does fee calculation and distribution lead to this?
How does being able to pledge from the wallet do this?
Simple it takes it out of the operators hands and makes the protocol function the same as Staking so the Pledge members on a multi pledge pool no longer have to worry about getting their rewards distribution this removes the trust element, which opens the door for pools just to offer pledging as a service. Without that needed trust what stops pools from attacking the pledge system by marketing pledge only pools with very little investment of their own to take over majority control of the network the very thing pledge is designed to protect against.
There should be steps taken to strengthen the security features like pledge before they get undermined for simplicity.
While I understand @glitch40's point, it is "my understanding" since a middle man is needed to distribute funds, that the entity that controls the rewards account would need a money transmitter license
It is a deliberate choice that the delegation design involves a bi-directional trust relationship between pool operators and pool owners. This is needed with the current design of the game theory that does not have separately modelled agents for owner and operator. The game theory only has a single pool owner/operator agent. We can (and do) split the roles provided that they still have a bi-directional trust relationship. If we naively removed the trust relationship then there would be no risk difference between pledging as an owner and delegating normally, and that would destroy the game theory and the Sybil attack prevention mechanism.
So that's why we must currently have such a trust relationship. A mechanism we use to ensure that owners have to trust the operator is that owners do not get paid their rewards directly and automatically as ordinary delegates do, but that all rewards are pooled into a single reward address that the owners and operator have to agree on.
Feel free to propose some new comprehensive scheme as a CIP, but be aware that you will need to look into the game theory aspects very closely to be able to convince people that you have a scheme that is sound.
Most helpful comment
This continues down the same path again of your other FR, removing the trust required for pledge which removes its core function. Pledging is a security mechanism designed to protect the network yet people keep suggesting ways to remove this security by easing the hurdles in place such as trust and knowing the people you pledge with that make it function. You may not see this however it leads down the same slippery slope. We should not be reducing network security and turning "Stake" pools into "pledge pools as a service" this opens the door for 51% attacks and suggestions like this make steps in that direction.
How does fee calculation and distribution lead to this?
How does being able to pledge from the wallet do this?
Simple it takes it out of the operators hands and makes the protocol function the same as Staking so the Pledge members on a multi pledge pool no longer have to worry about getting their rewards distribution this removes the trust element, which opens the door for pools just to offer pledging as a service. Without that needed trust what stops pools from attacking the pledge system by marketing pledge only pools with very little investment of their own to take over majority control of the network the very thing pledge is designed to protect against.
There should be steps taken to strengthen the security features like pledge before they get undermined for simplicity.