[SOLVED] The three Tendermint application states

The three Tendermint application states

I'm currently working at a small trading platform using Tendermint but I'm not yet sure on how the Tendermint application states should be used. In the Tendermint docs under https://tendermint.com/docs/app-dev/abci-spec.html#message-types it says:

Note that messages may be sent concurrently across all connections - a typical application will thus maintain a distinct state for each connection. They may be referred to as the DeliverTx state, the CheckTx state, and the Commit state respectively.

I'll give you my understanding on how these three states should be used and hopefully you can tell me whether this is correct.

DeliverTx state: After each valid DeliverTx request message received by the ABCI application this state gets updated. In case of an invalid transaction (included by a Byzantine proposer) the DeliverTx state is reset to the CommitTx state which has previously been set on receipt of the last CommitTx message.
CommitTx state: When an ABCI application receives a CommitTx message the CommitTx state is set to be the latest DeliverTx state.
CheckTx state: Maybe used for DoS protection (by storing the number of transactions that arrived through a CheckTx request message in the last few seconds as CheckTx state and whenever the number of transactions per second gets too high, the CheckTx response denies transactions from getting into the mempool).
In addition, whenever the application is queried (through abci_query RPC endpoint) the application answers the query based on its CommitTx state

My view on the three states perhaps already implies that I'm not sure what happens when the application receives a DeliverTx request but the delivered transaction is invalid (does this case even occur?). How does the entire process of proposing, prevoting and precommitting actually relate to these message types (CheckTx, DeliverTx, Commit)?

Solution