diff --git a/docs/rfc/rfc-003-performance-questions.md b/docs/rfc/rfc-003-performance-questions.md
index b850e1a02..82fac59fc 100644
--- a/docs/rfc/rfc-003-performance-questions.md
+++ b/docs/rfc/rfc-003-performance-questions.md
@@ -120,13 +120,15 @@ transaction delivery in Tendermint occurs asynchronously and therefore appears u
 form a bottleneck in ABCI.
 
 After delivering all transactions, Tendermint then calls the `Commit` ABCI method.
-Tendermint [locks all access to the mempool][abci-commit-description] while `Commit` 
-proceeds. This means that an application that is slow to execute all of its 
-transactions or finalize state during the `Commit` method will prevent any new 
-transactions from being added to the mempool.  Apps that are slow to commit will 
-prevent consensus from proceeded to the next consensus height since Tendermint 
-cannot validate validate block proposals or produce block proposals without the 
-AppHash obtained from the `Commit` method.
+Tendermint [locks all access to the mempool][abci-commit-description] while `Commit`
+proceeds. This means that an application that is slow to execute all of its
+transactions or finalize state during the `Commit` method will prevent any new
+transactions from being added to the mempool.  Apps that are slow to commit will
+prevent consensus from proceeded to the next consensus height since Tendermint
+cannot validate validate block proposals or produce block proposals without the
+AppHash obtained from the `Commit` method. We should add a metric for each
+step in the ABCI protocol to track the amount of time that a node spends communicating
+with the application at each step.
 
 #### ABCI serialization overhead causes slowdown