1.

I think that when Prevote event comes, we do not need to call on_4f_non_nil_prevote_in_propose_step

→ parameter "round" in this function means target_round. However, on_4f_non_nil_prevote_in_propose_step’s 4f+1 condition is for vr(valid round, i.e some previous round).

So I think nothing will happen if we call this function.

2.

When I have received 4f+1 non-nil & f nil votes, Both of on_4f_non_nil_prevote_in_prevote_step & on_5f_prevote will return "non-nil precommit" and response.extend() works twice.

I'm not sure how "extend" works, so is it okay to use "extend" like this?

3.

In tendermint paper,

Some of the rules ends with ”for the first time” constraint to denote that it is triggered only the first time a corresponding condition evaluates to true.
This is because those rules do not always change the state of algorithm variables so without this constraint, the algorithm could keep executing those rules forever.

So, on_4f_non_nil_prevote_in_prevote_step should only be called once.

However, I think “executing forever” only applied for updating validValue & validRound. As vetomint’s performance does not important, I think we can leave it as it is, what do you think?
(→ Actually, I think this is not a safety issue, only performance issue.)