x/gov: remove querying deposits from events

[aleem1314]

Summary

Remove querying deposits from events in cli.

Problem Definition

#9288 comments

Currently in SDK every proposal's deposits are being removed once after it is completed(completed in the sense either passed or rejected)

• in case of passed proposals all the deposit amount will be refunded to the depositors and then deposits state will be prune after refunding the deposit amount. (see here)
• for rejected proposals all the deposits amount are burn and state is pruned. (see here)

Those proposals which did not meet minimum deposits are being removed from proposals state along with it's deposits. In this case deposits are not required to keep in the state since the proposal data itself being removed from state.

• doubt 1: if we have to keep all the deposits in state, do we need to keep passed proposals deposits as well? (I think we should)
• doubt 2: currently deleteDeposits function is being used to delete deposits, but along with that it is burning the deposits for removed, rejected proposals (I think we need to separate the logic to two separate functions 1.deleteAndBurnDeposits, 2.burnDeposits)
  • incase of burnDeposits only the deposit amount will get burnt but the deposits for the proposal won't be pruned from state.
  • incase of deleteAndBurnDeposits all the deposits burnt and deposits will be pruned for the proposal.

problems for splitting proposals deleteDeposits:

• invariants will break. here
• simulations of genesis import export for x/gov fails. here

if we stop burning tokens for failed proposals there are no changes required in invariants and genesis (but I don't think this is the fix).

problems if we remove query events for deposits:

• querying initial deposits may not work well(not sure where we need to query the initial deposits) and deposits[0] is not always same if we query the deposits(not sure why)
• if the same proposer(who created the proposal) deposits again that will be added to the existing deposit amount in the state.

Proposal

• Update the Proposal deposits record handling logic - to not remove deposits for rejected proposals
• make a migration to recover deposit records

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[amaury1093]

Is this actually blocking v0.43, or just a nice-to-have?

[atheeshp]

Is this actually blocking v0.43, or just a nice-to-have?

Not a blocker, nice to have