Staking Pallet: Tax Friendly Rewards

[shawntabrizi]

The current staking pallet in Substrate is not optimized for annual tax returns.

I propose that we make some "superficial changes" to the staking pallet which may have very large positive impact to Substrate token holders and stakers.

Specifically, there is issue that the staking pallet directly pays out tokens to users when claiming a reward. Many countries treat that payout extrinsic as a taxable event for anyone who received tokens. This behavior may vary depending on how the tokens are paid out (for example locked vs unlocked), but in general, there is no control by the end user when this event happens.

Instead, I suggest we use a "point" system for staking. When you initially lock your balance for bond, we will give your account a proportional number of Staking Points. You then use those points just like before, making nominations, validating, etc...

Instead of paying out DOTs during each reward cycle, we will increment the number of staking points you have. Staking points are NOT transferable and thus have no value. Modification of these points should not be seen as a taxable event.

When a user chooses to unbond their funds, just like before, there is an unbond period where the user needs to wait. At the end, when the staking points are unbonded, a user can then call fn convert or a similar function to then convert their staking points into tokens, minting any new tokens they have earned all at once in a single transaction, and a single taxable event.

Problems to solve:

• Slashing probably needs to happen directly to the user's balance in addition to their staking points.
  • In general, handling changes to a users balance which may affect their staking points needs to be taken into account. Increases in balance should probably do nothing, but decreases in balance should not be game-able.
• This mechanism probably only makes sense if a user is re-staking their rewards. Probably makes sense to have this be a completely separate staking method in parallel to the existing system for backwards compatibility.

[shawntabrizi]

It would be good to get more feedback from the community about how best the staking pallet (or even the balances pallet) may be modified to make taxes in your country easier / better.

Please include lots of details as you must assume most people have NO IDEA how taxes in your area work.

[xlc]

I am not sure if we want to implement is in Polkadot layer. As soon as parachain is ready, it is relatively easy to build a smart contract / runtime pallet that achieve this. In fact Acala is already building a product that may solve this issue.

[shawntabrizi]

Can you elaborate on how you will achieve this? You are saying you would keep all of your funds in a smart contract which you will control to nominate / validate, and have rewards get paid out there as is?

In any case, we know that Smart Contracts will not be on Polkadot directly, so having such functionality be dependent on some 3rd party chain is probably not for the best.

[xlc]

I think there is a plan to have system parachain with smart contract functionality. And then combined with XCM in ink! & polkadot-fellows/xcm-format#11 it shouldn't be hard to implement what you described.

[nuke-web3]

Instead of paying out DOTs during each reward cycle, we will increment the number of staking points you have. Staking points are NOT transferable and thus have no value. Modification of these points should not be seen as a taxable event.

I am not a lawyer, but I think that it would be good to verify this with tax pros in the US, EU, China, etc. Specifically, is a "point" that is claim redeemable for tokens enough to not generate a taxable event? The analogy here is likely close to getting an option contract with no expiration date... Where would the funds in question be held before? Or rather would these "point" be used to mint new DOT into existence at the time of redemption?

When a user chooses to unbond their funds, just like before, there is an unbond period where the user needs to wait.

So you are proposing that the only way to claim rewards would be to stop nomination and wait the full unbonding period before you could claim them? For me, having the flexibility at anytime to decide to claim rewards and distribute them more dynamically would be preferred. For example, I may want to initiate an (taxable) income event while not stopping actively nominating. If I must unbound and await for rewards, the opportunity costs are quite high (effectively a rewards claim tax), and if there is an event that triggers many to want to take the rewards at the same time, we may see a large loss of nominations on the whole network.

[shawntabrizi]

Or rather would these "point" be used to mint new DOT into existence at the time of redemption?

Yes. In my head the new DOTs would be minted as you redeem the points. A very clear taxable event afaik.

For me, having the flexibility at anytime to decide to claim rewards and distribute them more dynamically would be preferred.

It seems possible, but may be more a more complex implementation to allow this. None the less, good feedback 👍

[kianenigma]

I am not living somewhere where this type of event is taxable anyhow, so not an expert. But from what I have heard: The points can virtually have a 1→1 relation to DOT or Planck. The other side of the issue IMO is the event that gives the reward to you, regardless of the name of the utility being exchanged. Perhaps some tax authorities can then argue that this "Point", if it is controllable by you, is equal to the token already. Therefore, I think a mechanism that delays and aggregates these, even in DOTs, would also work out?

[laboon]

Agree 100%, staking is a pain from a taxation standpoint. For anyone doing it, I recommend https://github.com/w3f/staking-rewards-collector - this lets you enter in your Kusama and Polkadot accounts and shows you all staking rewards as well as current market value in a nice CSV.

[laboon]

I had a similar idea: tokens which guaranteed you X% of some account which does the staking, with rewards sent to itself. So let's say I have 100 DOT, I could buy 1% of the account which has 10'000 DOT in it and is staking, and get a token (RDOT - "removed DOT", I don't know what would be a good name). After a year, I haven't had a taxable event but my RDOT tokens are now worth, say 110 DOT since they controls 1% of the 11'000 DOT in the staking account after 10% growth due to staking rewards.

Users could then either sell these RDOT tokens or directly redeem them for the % of DOT that they own.

This other account could be run by a separate business or some sort of smart contract / pallet etc. which automatically stakes according to some rules.

[xlc]

@laboon you are essentially describing a simpler version of the staking derivative protocol of Acala. Just we call it LDOT instead of RDOT.

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.

[kianenigma]

There's still ongoing discussion about this here and there.

[TriplEight]

This "point" might be named "nominators rating" and refer to the staking account. There, the rating is an amount of points (apparently equal to its value in xDOTs whether locked or vested) the system might pay out to the owner of that account or their attorney via some staking proxy per request or schedule.

[ggwpez]

We have the NIS pallet that achieves this.