diff --git a/zip-0213.rst b/zip-0213.rst
index 4a4d2c64..5465c31b 100644
--- a/zip-0213.rst
+++ b/zip-0213.rst
@@ -124,17 +124,30 @@ spending a note is to select an anchor 10 blocks back from the current chain tip
 acts as a de-facto 10-block maturity on all notes, coinbase included. This might be
 proposed as a consensus rule in future.
 
-There is another reason for shielded coinbase maturity being unnecessary: when a reorg or
-rollback occurs that would cause a shielded coinbase output to disappear, it will also
-invalidate every shielded transaction that uses an anchor descending from the tree that
-the shielded coinbase output had been appended to. That is, all economic activity would be
-rolled back in addition to the shielded coinbase output disappearing, so there is no
-reason to make shielded coinbase a special case when the same behaviour occurs in regular
-shielded notes already. In the transparent coinbase case, only direct child transactions
-of the transparent coinbase would become invalid, and thus it would be possible to end up
-in a situation where a logical child transaction (for example, a mining pool paying out
-miners) persists in the block chain after its logical parent (the mining pool receiving a
-block) disappears.
+There is another reason for shielded coinbase maturity being unnecessary: shielded
+coinbase outputs have the same effect on economic activity as regular shielded outputs.
+When a transparent address receives a coin in some "parent" transaction and later spends
+it, a tree of "direct child" transactions is created that all require the original parent
+transaction to be valid. However, most wallets treat unspent transparent outputs as a
+single "bucket of money", and select coins to spend without direct user input. This can
+create a disconnect between the economic activity of users (who might be intending to
+spend funds that they just received, creating "logical child" transactions), and their
+on-chain transaction graph.
+
+> For example, a mining pool that successfully mines a block will receive a coinbase
+> output, but their subsequent payout to miners might instead spend ZEC that they already
+> had before the block was mined. If the mining pool pays out for block X, and then a
+> reorg or rollback occurs that causes the transparent coinbase in block X to become
+> invalid, the payout transaction might still be mined on the new chain, even though the
+> funds that the miner was logically spending do not exist there.
+
+By contrast, when a reorg or rollback occurs that would cause a shielded coinbase output
+to disappear, it will also invalidate every shielded transaction that uses an anchor
+descending from the tree that the shielded coinbase output had been appended to. That is,
+all shielded economic activity would be rolled back in addition to the shielded coinbase
+output disappearing, ensuring that all logical child transactions are invalidated, not
+just direct child transactions. Therefore, there is no reason to make shielded coinbase a
+special case when the same behaviour already occurs in regular shielded notes.
 
 Requiring that note commitments are valid when recovering using a fixed outgoing viewing
 key implies that target addresses and values for all Sapling outputs within the coinbase