diff --git a/zip-0315.rst b/zip-0315.rst
index 1bf68fee..473db8ab 100644
--- a/zip-0315.rst
+++ b/zip-0315.rst
@@ -155,7 +155,18 @@ transactions to other transactions.
 The remainder of this specification assumes a wallet that follows all of these
 recommendations, except where explicitly noted.
 
-A wallet MAY allow users to disable auto-shielding.
+A wallet MAY allow users to disable auto-shielding, auto-migration,
+and/or opportunistic migration. If it does so, this need not be via
+three independent settings.
+
+Automatic shielding and automatic/opportunistic migration SHOULD NOT be
+applied to inputs where the cost of shielding or migrating them will
+exceed their economic value. If these transactions are paying the
+ZIP 317 conventional fee [#zip-0317]_, that will be the case if the
+amount of the UTXO to be shielded/migrated exceeds the marginal
+fee, and cannot be accommodated by an input that would be present
+in any case due to padding of the number of inputs from a given
+shielded pool.
 
 
 Trusted and untrusted TXOs
@@ -177,7 +188,7 @@ Rationale for the given numbers of confirmations
 ''''''''''''''''''''''''''''''''''''''''''''''''
 
 The rationale for choosing three confirmations for trusted TXOs is that
-empirically, reorgs are usually less than three blocks.
+anecdotally, reorgs are usually less than three blocks.
 
 The consequences of attempting to spend a trusted TXO may be less severe in the
 case of a rollback than the consequences of attempting to spend an untrusted TXO.
@@ -243,8 +254,8 @@ Note: the definition of "confirmed-spendable" above ensures that:
 * if auto-shielding is enabled, transparent funds will be reported in
   the pending or total balance, but not in the confirmed-spendable
   balance;
-* if the wallet is not synchronized, the confirmed-spendable balance
-  will be zero.
+* if the wallet has not synchronized at least the nullifier set to the
+  chain tip, the confirmed-spendable balance will be zero.
 
 If auto-shielding is disabled, the wallet MAY report shielded and
 transparent balances separately. If it does so, it MUST make clear
@@ -255,12 +266,14 @@ Rationale for reporting of balances
 '''''''''''''''''''''''''''''''''''
 
 If auto-shielding is disabled, then separate shielded and transparent
-balances (and potentially, for expert users, separate shielded balances
-per pool) can constitute useful information. If auto-shielding is enabled
+balances can constitute useful information. If auto-shielding is enabled
 then the wallet can and will automatically spend transparent TXOs in
 order to shield them, and so transparent TXOs need to be presented as
 pending, not as part of the balance spendable by the user.
 
+Potentially, for expert users, separate shielded balances per pool
+could also be useful.
+
 TODO: The specification of balance reporting is intended to give the user
 visibility into the operation of auto-shielding, opportunistic shielding,
 and pool migration/usage. (Does the spec satisfy this?)
@@ -327,7 +340,7 @@ Kinds of information leakage
 
 * Transaction version (v4 or v5, as of NU5)
 
-SHOULD use v5 (unless you're spending Sprout funds).
+It is RECOMMENDED to use v5 transactions unless Sprout funds are being spent.
 
 * Lock time (rarely used; may be a distinguisher if it is)
 
@@ -657,3 +670,4 @@ References
 
 .. [#BCP14] `Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words" <https://www.rfc-editor.org/info/bcp14>`_
 .. [#zip-0203] `ZIP 203: Transaction Expiry <zip-0203.rst>`_
+.. [#zip-0317] `ZIP 317: Proportional Transfer Fee Mechanism <zip-0317.rst>`_