Maybe we should not delete the ballots as the finalized ballots help us prevent double spending (by blocking the same ballot being created again)

We do have the finalized inbounds check to stop ballot creation
https://github.com/zeta-chain/zeta-node/blob/db2c6f3ff7998c1f5f8500e853500a5d9d46adf9/x/crosschain/keeper/msg_server_vote_inbound_tx.go#L95-L97

We do have the finalized inbounds check to stop ballot creation https://github.com/zeta-chain/zeta-node/blob/db2c6f3ff7998c1f5f8500e853500a5d9d46adf9/x/crosschain/keeper/msg_server_vote_inbound_tx.go#L95-L97

Sounds great. It will be safe then. We can go ahead to clean up ballots after distribution.

Deleting older ballots would remove the possibility of querying ballots older than 100 blocks (current athens maturity period )

This can affect current way of operations

1. We wouldn't be able to query older ballots to see if directly if a particular observer is consistently missing votes
2. We allow observers to vote on ballots to receive rewards , they would not be able to vote on ballots once deleted

Proposed solutions
When deleting a ballot, we can emit a new event containing the list of observers who have added their votes to the ballot.
This should be enough, as we expect every observer to cast their vote within the maturity period (casting after that is useless as they would not get any rewards )
Additionally, we can consider increasing the maturity blocks, if we expect observers to be more than 100 blocks late in adding their votes

• The delete ballot event would be part of the BlockBeginner and not a tx_result.

• We can also consider removing the Ballot_Created if it is not being consumed right now

Changes required

• The explorer/indexer should be able to index these deleted ballot events so that they can be easily searched. This should be very similar to existing emissions events such as
  /zetachain.zetacore.emissions.internal.ObserverEmissions
/zetachain.zetacore.emissions.internal.BlockEmissions

cc @zeta-chain/fullstack , @zeta-chain/devops

If these changes come within /cosmos/tx/v1beta1/txs when querying for a specific block event, then we don't need to update anything on the indexer side 👍

I don't think it would be within /cosmos/tx/v1beta1/txs , as its not part of a tx but part of begin block instead . (Not 100% sure though )

Can you send me an example of how we index the two events I mentioned?

If it's not within /cosmos/tx/v1beta1/txs, and if it's not EVM (therefore not going through Blockscout) we're not indexing it currently

@GMaiolo We should be indexing BeginBlock and EndBlock events as well. In case we are not doing it now , it would be a good idea to prioritize this shortly

Not entirely sure how the indexer works but the Begin Block and End Block events are part of the block result
https://zetachain-rpc.lavenderfive.com/block_results?height=4799111