diff --git a/bip-0388.mediawiki b/bip-0388.mediawiki
index 19091cfb..d2d88c50 100644
--- a/bip-0388.mediawiki
+++ b/bip-0388.mediawiki
@@ -1,5 +1,5 @@
 RECENT CHANGES:
-* (06 Nov 2024) Added <tt>musig</tt> key placeholders
+* (06 Nov 2024) Added support for <tt>musig</tt> key placeholders in descriptor templates
 
 <pre>
   BIP: 388
@@ -83,7 +83,7 @@ We set two fundamental design goals:
 * Minimize the amount of information that is shown on screen - so that the user can actually validate it.
 * Minimize the number of times the user has to validate such information.
 
-Designing a secure protocol for the coordination of a descriptor wallet among distant parties is also a challenging problem that is out of scope in this document. See [[bip-0129.mediawiki|BIP-129 (Bitcoin Secure Multisig Setup)]] for an approach designed for multisig wallets. Regardless of the approach, the ability for the user to carefully verify all the details of the spending policies using the hardware signer's screen is a prerequisite for security in adversarial environments.
+Designing a secure protocol for the coordination of a descriptor wallet among distant parties is also a challenging problem that is out of the scope of this document. See [[bip-0129.mediawiki|BIP-129 (Bitcoin Secure Multisig Setup)]] for an approach designed for multisig wallets. Regardless of the approach, the ability for the user to carefully verify all the details of the spending policies using the hardware signer's screen is a prerequisite for security in adversarial environments.
 
 === Policy registration as a solution ===
 
@@ -171,9 +171,9 @@ Note that while [[bip-0389.mediawiki|BIP-389]] allows multipath <tt>/<NUM;NUM;..
 
 <tt>SCRIPT</tt>, <tt>TREE</tt> and <tt>KEY</tt> expressions map directly to the corresponding concepts defined in [[bip-0380.mediawiki|BIP-380]] for output script descriptors.
 
-Each <tt>KEY</tt> expression always correspond to a precise public key in the final bitcoin Script. Therefore, all the derivation steps in the BIP-32 hierarchy are included in a <tt>KEY</tt> expression.
+Each <tt>KEY</tt> expression always corresponds to a precise public key in the final bitcoin Script. Therefore, all the derivation steps in the BIP-32 hierarchy are included in a <tt>KEY</tt> expression.
 
-Each <tt>KP</tt> (key placeholder) expressions, on the other hand, maps to the root of all the corresponding public keys for all the possible UTXOs that belong to the account represented in the wallet policy. Therefore, no derivation steps are allowed in a <tt>KP</tt> expression.
+Each <tt>KP</tt> (key placeholder) expression, on the other hand, maps to the root of all the corresponding public keys for all the possible UTXOs that belong to the account represented in the wallet policy. Therefore, no derivation steps are allowed in a <tt>KP</tt> expression.
 
 A <tt>KI</tt> (key index) <tt>@i</tt> for some number ''i'' represents the ''i''-th key in the vector of key information items (which must be of size at least ''i + 1'', or the wallet policy is invalid).
 
@@ -243,7 +243,7 @@ Common single-signature account patterns:
 * <tt>tr(@0/**)</tt> (taproot single-signature account).
 
 Common multisig schemes:
-* <tt>wsh(multi(2,@0/**,@1/**))</tt> - SegWit 2-of-2 multisignature, keys in order.
+* <tt>wsh(multi(2,@0/**,@1/**))</tt> - SegWit 2-of-2 multisig, keys in order.
 * <tt>sh(sortedmulti(2,@0/**,@1/**,@2/**))</tt> - Legacy 2-of-3 multisig, sorted keys.
 * <tt>tr(musig(@0/**,@1/**))</tt> - MuSig2 2-of-2 in the taproot keypath