funding: issue delegation token rewards

[erwanor]

To do this, we can:

1. Extend the ranked voter state key to track the IdentityKey that corresponds to the delegator's voting notes (no group element decoding overhead since the underlying struct is bytes)
2. Include it the stream of votes
3. Fetch the current validator rate for the correspond IK
4. Apply it to the unbonded amount
5. reward_to_voter takes a Value where the amount is rate * unbonded_amount and the asset_id is DelegationToken::new(IK).id()

We don't need to adjust the rates at all, since they are independent issuance events. The rate are determined by the chain native issuance rate schedule.

[hdevalence]

How does the staking component learn about the newly issued delegation tokens?

[erwanor]

We are adding a new inter-component API to increase the validator delegation pool, and outsource it the conversion of unbonded rewards to a Value which is the delegation token equivalent.

This is done after the validator powers are ratified for the epoch, and after the cometbft update is built. So those changes take place at the next epoch boundary. Prototyping a PR.

[hdevalence]

Hmm, shouldn't the newly minted delegator rewards happen before the end of the epoch in which they are issued, so that they are reflected in the validator voting power and available for voting / staking etc in the following epoch?

[erwanor]

They are available immediately to the user, but the downstream effects of increased VP are only taking effect in the following epoch.

We are at epoch e, on the last block h:

• staking: processed delegations/undelegations, tallied VP, adjusted rates
• funding: mint delegation tokens, increase validator delegation pool

this means that, at block h+1, when we enter a new epoch e+1:

• voters: have increased LQT VP from their rewards (because minting happened in e)
• validators: have bigger delegation pools but no increased VP yet (as if the user had just delegated) (because consensus view update happens at the end of e+1)

at the end of the epoch, the staking component will refresh the chain's view of the active set and actualize the VPs.

[hdevalence]

Yeah, what I'm saying is shouldn't it be made so that there is not a one-epoch offset? Wouldn't that be better?

[erwanor]

I think it's conceptually cleaner and better, which is a lot, but worse in terms of lift because of how we decided to structure the component stack.

In retrospect, LQT should have its own component that executes ahead of staking, so that pool/cometbft VP stay aligned. But when we drafted the ADR, we did so with staking token rewards in mind so doing work in funding seemed sufficient.

[erwanor]

Discussed out of band, picking the smaller lift