diff --git a/bip-0077.md b/bip-0077.md
index 07852f2b..25f73b26 100644
--- a/bip-0077.md
+++ b/bip-0077.md
@@ -222,7 +222,7 @@ receiver shares encoded in the URI.
 Instead of defining new Bitcoin URI parameters, the session-specific
 parameters are encoded in the [
 fragment](https://datatracker.ietf.org/doc/html/rfc3986#section-3.5)
-of the the mailbox endpoint URL.
+of the mailbox endpoint URL.
 
 The `#` fragment separator character must be [RFC 3986
 percent-encoded](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1)
diff --git a/bip-0175.mediawiki b/bip-0175.mediawiki
index 30c79858..4ffba807 100644
--- a/bip-0175.mediawiki
+++ b/bip-0175.mediawiki
@@ -244,7 +244,6 @@ Communication between payer and payee as well as hashing the contract and genera
 
 ==Reference implementations==
 
-* Reference wallet implementation, based on Copay project : https://github.com/commerceblock/copay ([[https://github.com/commerceblock/copay/pull/1|pull_request]])
 * Reference implementation to Hash to Partial Derivation Path Mapping in javascript ([[https://github.com/commerceblock/pay-to-contract-lib/blob/master/lib/contract.js|https://github.com/commerceblock/pay-to-contract-lib]])
 
 ==Reference==
diff --git a/bip-0443.mediawiki b/bip-0443.mediawiki
index 620336e9..97f42fe1 100644
--- a/bip-0443.mediawiki
+++ b/bip-0443.mediawiki
@@ -38,7 +38,7 @@ This document is licensed under the 3-clause BSD license.
 The ability to constrain the future of coins beyond what is possible with presigned transactions is at the core of
 numerous attempts to improve bitcoin. Some of the proposed applications include:
 
-* UTXO sharing schemes like Ark, CoinPools, Timeout Trees, etc. use various types of output restrictions in order to enable multiple parties to share the control of a UTXO, while ensuring that each participant controls their own `balance.
+* UTXO sharing schemes like Ark, CoinPools, Timeout Trees, etc. use various types of output restrictions in order to enable multiple parties to share the control of a UTXO, while ensuring that each participant controls their own balance.
 * <code>OP_VAULT</code><ref>[[bip-0345.mediawiki|BIP-345]]</ref> is a proposed opcode to implement a 2-step withdrawal process, enabling on-chain reactive security.
 * <code>OP_CHECKTEMPLATEVERIFY</code><ref>[[bip-119.mediawiki|BIP-114]]</ref> is a long-proposed opcode to constrain a transaction to a ''template'' with a fixed set of outputs.
 * Sidechains and rollups could be implemented via a UTXO encumbered with a recursive covenant, updating the sidechain state root every time it is spent.
@@ -135,10 +135,10 @@ The tapscript opcode <code>OP_SUCCESS187</code> (<code>0xbb</code>) is constrain
 <code>OP_CHECKCONTRACTVERIFY</code>.
 
 When evaluating <code>OP_CHECKCONTRACTVERIFY</code> (<code>OP_SUCCESS187</code>,
-<code>0xbb</code>), the expected format of the stack, shown bottom to top, is:
+<code>0xbb</code>), the expected format of the stack, shown bottom-to-top, is:
 
 <source>
-<mode> <taptree> <pk> <index> <data>
+<data> <index> <pk> <taptree> <mode>
 </source>
 
 where:
@@ -462,4 +462,4 @@ without upgrade except for mining and block validation.
 
 == Acknowledgements ==
 
-TODO
\ No newline at end of file
+TODO