diff --git a/content/posts/cip-118.md b/content/posts/cip-118.md
index ddca032..d89ead4 100644
--- a/content/posts/cip-118.md
+++ b/content/posts/cip-118.md
@@ -188,23 +188,29 @@ much easier and cheaper mechanism for broadcasting state in this sense. The
 transaction referencing the input pays in fees and bytes only a fraction of what
 it would otherwise cost, particularly with CIP 32.
 
-CIP 32 purports to address the inconvenience caused by the former design's
+CIP 32 purports to address an inconvenience caused by the former design's
 support only of datum hashes at tip. Quote: "This is also inconvenient for the
-spending party, who must watch the whole chain to spot it.". Were it not for CIP
-31, then I would find this argument incredibly weak. Without CIP 31 but with CIP
-32, this is simply a tooling issue. To create a transaction, a user already
+spending party, who must watch the whole chain to spot it". 
+I find this argument incredibly weak. To create a transaction, a user already
 needs access to the chain via functions `getUtxosAtTip` and `submitTx`. Having
-another `getDatumByHash` is not a big deal. With CIP 31 but without CIP 32, the
-referencing transaction would also need to include the datum as part of the
-redeemer which would then be hashed, and then matched with that of the
-referenced inputs datum hash. With both CIP 31 and 32, a referencing transaction
-does not pay in fees nor bytes for the inclusion of the datum, and the
-additional logic is avoided.
+another `getDatumByHash` is not a big deal - it is just a tooling issue. 
+A more compelling case is that it reduces the size of transactions. 
+Prior to the change and in normal application an output datum hash 
+would need to be validated, 
+and so the datum would be present in the witness set, adding to the 
+transaction size. 
+The consuming transaction would then need to include the same data.
+There are some contexts where this can be improved upon, 
+but CIP 32 essentially halves this problem by paying for the data just once.
+The impact of CIP 32 is compounded when used with CIP 31.
+With both CIP 31 and 32, any referencing transaction
+does not pay in fees nor bytes for the inclusion of the datum.
 
 CIP 33 allowed scripts to be referenced, rather than having to be included in
 the transaction. As mentioned, scripts can easily exhaust most if not all the
 transaction size limit. Referencing scripts dramatically reduces the size of
-script heavy transactions.
+script heavy transactions. Generally speaking, of the three CIPs, this was the 
+most significant.
 
 The ledger changes in Vasil were a small perturbation of what had come before.
 CIPs 32 and 33 did not introduce new functionality in and of themselves. They