What causes owner rewards to get payed to the pool reward address?

Folks, I wanted to separate rewards that come from the active stake of the owner from the pool rewards (i.e. 340 + 1%). There is a separate pool-reward-account-verification-key that doesn’t need to get witnessed. Currently the owner rewards are redirected to the pool reward stake address. I do this in preparation for Alonzo when I want to have the pool rewards paid to a Plutus contract.

Do you know how I can possibly fix this?

2 Likes

I am also mystified by this. In the stake pool course both owner and rewards address were set to the same without explanation.

If separate addresses are used, all rewards go to the pool-rewards address and none to the pool-owner address. Using separate addresses seems pointless, at least for single owners.

My expectation was to see the fixed fees and margin go to the pool-rewards address and the delegation rewards for the address holding the pledge in the pool-owner address.

Bug or feature?

Ok, lets try this …

#1 Add an addition owner and see if those rewards get redirected too
#2 Transfer the pledge to the new owner
#3 Remove the original owner and see what happens then

It’ll be a lengthy process - I’ll keep you posted :slight_smile:

1 Like

For the record …

I moved some some funds from Ledger to a new wallet. Then, back to a new Ledger account. The network should not know that both owner stake addresses as well as the pool reward address are all secured by the same HW wallet.

I witnessed the config change like this …

Now I feel a bit stupid.
What is the difference between cardano-cli transaction sign and cardano-cli transaction witness? How do you intend to use the four .witness files generated?

I assemble and submit the Tx like this …

Remember, I don’t have payment/stake keys generated by cardano-cli that could get compromised when moving around to sign stuff. Every account that holds more funds than I’m happy to loose is secured by a HW device.

A signed Tx is the aggregate of the output from everyone who witnessed the Tx. Most folks don’t have multiple independent parties that need to witness, so they can use cardano-cli transaction sign. Much worse, they hold the signing key from multiple parties and still use cardano-cli transaction sign with multiple secret keys that they control as a single entity.

With the process above (i.e. independent witness+aggregate) I could email the raw Tx around the globe and ask everyone to “witness” the config change independently - I don’t need to have their signing keys.

Long story short, you cannot.

It is by design that owner(s) and operator should have sufficient trust between them to run a pool. Otherwise, if owner rewards were paid directly into their account, there would be a market place for pledge providers.

And even like this, it seems it has happened to some extent.

1 Like

@Psychomb Thanks for chiming in. You therefore predict that the delegation rewards from owner2 will also be redirected to the pool reward address?

If true, that would have a significant tax impact, because whoever owns the pool reward address will have to pay tax on the sum of all owner + pool rewards.

How would that work when the pool reward address becomes a Plutus script address?

You make it sound as if a pledge market were somehow not desirable. Why?

There are some risks involved where one of the party involved does not really know how to safely manage private keys. It seems that some already lost their pledge to dishonest operators …

On top of that, why delegate if you could easily pledge instead, be sure that you do not rely on the operator good will and honesty, and bump the rewards ratio of the pool ?

All owner rewards are paid to the operator address. That is exactly the behavior intended, where a real life contract should bind the two or more persons involved.

In your tax issues, a renting contract should make clear that a rent to the owner is due. Hence it becomes an operational charge to you, and an income to the owner.

Indeed why not? Whether I I pledge in my own pool or in someone else’s doesn’t make a difference globally and many people seem to be desperate for some stake, so win-win, right?

The question is not really why delegate if I can also pledge. It seems to be why delegate to a pool if I can profit more by creating my own puddle.

1 Like

Nothing prevents you from that scheme, if you think you can trust the operator to pay you and if he can trust that you won’t pull out the pledge without a heads up.

But the design specifications are clear on how it works, and there is a reason to that.

Could you please provide a reference link that backs this up?

1 Like

page 16 … https://hydra.iohk.io/build/790053/download/1/delegation_design_spec.pdf

3 Likes

Interesting, thanks for sharing. I’m not yet sure that I can follow the logic, though. The spec says

collaborating to form a stake pool should require significant trust between the owners. Otherwise, everyone could choose to become a co-owner of a stake pool instead of delegating, which would render the mechanism of pledging stake ineffective.

How does the conclusion follow from the premise? How would pledging become ineffective if everybody could do it instead of delegating?

The rationale for the existence of pledge is protection from sybil attacks.

The rewards that a stake pool gets depend on a pledge of funds that the stake pool owner(s) provide. This adds a cost to creating a competitive stake pool, and protects against Sybil attacks on the stake pool level

Thus the concern seems to be that sybil protection would somehow stop working if people could cooperate on raising pledge without also trusting each other. So the protection against this type of attack is trust?

I’m sorry, I don’t get it. Surely missing something very obvious. What is it?

1 Like

Thanks, gents - this has been very fruitful :slight_smile: