diff --git a/_posts/en/newsletters/2026-07-31-newsletter.md b/_posts/en/newsletters/2026-07-31-newsletter.md
new file mode 100644
index 000000000..7285b6b80
--- /dev/null
+++ b/_posts/en/newsletters/2026-07-31-newsletter.md
@@ -0,0 +1,334 @@
+---
+title: 'Bitcoin Optech Newsletter #416'
+permalink: /en/newsletters/2026/07/31/
+name: 2026-07-31-newsletter
+slug: 2026-07-31-newsletter
+type: newsletter
+layout: newsletter
+lang: en
+---
+This week's newsletter warns about a severe vulnerability affecting wallets
+generated by COLDCARD signing devices, summarizes the disclosure of two
+denial-of-service vulnerabilities in Core Lightning, and describes a proof of
+concept for a zero-knowledge proof of reserves. Also included are our regular
+sections with selected questions and answers from the Bitcoin Stack Exchange,
+announcements of new releases and release candidates, and descriptions of
+notable changes to popular Bitcoin infrastructure software.
+
+## Action items
+
+- **Move funds secured by COLDCARD-generated keys:** if you used a
+  COLDCARD Mk3 to generate a wallet, any funds received by that wallet
+  are at risk of theft and should be carefully moved to an unaffected
+  wallet as soon as possible.  Wallets generated by other COLDCARD
+  models may also be affected.  See the News section below for details.
+
+## News
+
+- **Wallets generated by COLDCARD at risk of theft**:
+  On 30 July 2026, some Bitcoin users discovered that funds from their COLDCARD
+  wallets had been stolen in a series of unexpected transactions on 29 July.
+  Over the course of the day, a bug was identified in the firmware of the
+  COLDCARD Mk3 that causes wallets to be generated with insufficient
+  entropy. As of this writing, estimated losses exceed 1,000 BTC, a figure
+  that may continue to rise as the situation develops.
+
+  A [security advisory][coinkite advisory] by Coinkite identified wallets
+  generated by COLDCARD Mk3 using firmware version 4.0.1 (March 2021) or later,
+  including the latest released version, as vulnerable to theft, unless the
+  seed was created with sufficient externally generated entropy (such as 50 or
+  more private dice rolls) or the wallet was additionally encumbered with a
+  strong passphrase. The advisory also identifies seeds generated by Mk4 and
+  Mk5 firmware before version 5.6.0 and Q firmware before version 1.5.0Q as
+  affected.
+
+  In a follow-up [technical backgrounder][coinkite backgrounder], Coinkite
+  attributes the bug to a 2021 code change that unintentionally routed seed
+  generation to a software PRNG, initialized from predictable device-unique
+  values, instead of the device's hardware RNG. Seeds generated by an
+  affected Mk3 without supplemental dice rolls have roughly 40 bits of
+  effective entropy instead of the intended 128. Seeds from affected Mk4,
+  Mk5, and Q devices are harder to attack because output from a secure
+  element is also mixed in, although an [analysis][block analysis] by Block,
+  performed with anonymous researchers and disclosed in coordination with
+  Coinkite, found that only 32 bits of that entropy reach the PRNG state,
+  leaving those seeds still well below the intended security level.
+
+  Several developers were able to immediately reproduce the attack with the
+  assistance of frontier AI models, so the vulnerability should be assumed to
+  be under active exploitation. Block's analysis additionally identifies the
+  older COLDCARD Mk2 running 4.x firmware as affected to the same degree as
+  the Mk3, and notes that other randomly generated secrets, such as
+  paper-wallet private keys and ephemeral seeds, are also affected.
+
+  This is an evolving situation, and additional information is likely to
+  emerge after this newsletter's publication. Readers should monitor
+  [Coinkite's blog][coinkite blog] and other sources for updates. Bitcoin Optech
+  recommends that COLDCARD users whose wallets may be affected
+  move their funds carefully to an unaffected wallet as soon as possible.
+  Seeds generated on an affected device without supplemental dice rolls
+  should be treated as compromised. Users of Mk4, Mk5, and Q devices should
+  upgrade to fixed firmware before generating any new wallets. Upgrading
+  alone does not make an existing seed safe.
+
+- **Disclosure of two DoS vulnerabilities in Core Lightning**: Chandra Pratap
+  [posted][cln vuln del] to Delving Bitcoin about two denial-of-service (DoS)
+  vulnerabilities he found
+  in Core Lightning during his internship for the [Summer of Bitcoin][sob]
+  program. Specifically, these vulnerabilities would have allowed an attacker to crash
+  a node by exhausting its memory. The bugs are related to the `gossipd` daemon
+  state machine, in particular to its interface with the `connectd` daemon.
+  Pratap was able to find the vulnerabilities thanks to his work on a new fuzz
+  target, `fuzz-gossipd-connectd`, which aims to test the robustness of the
+  communication between the two modules.
+
+  The first vulnerability was related to the inter-daemon message queue,
+  shared between the two daemons, whose goal is to store all the `channel_update`
+  messages arriving from the network. An attacker would have been able to flood
+  the node with messages, causing the internal queue to grow indefinitely and leading
+  to the consumption of all the available RAM. The bug was simply fixed in
+  [Core Lightning #8376][] by allowing the queue to drop messages,
+  adding a cutoff point at 500,000 messages.
+
+  The second vulnerability was found while trying to fix the first one.
+  In particular, this was related to the internal map used to track unknown short
+  channel IDs (SCIDs) to query peers for possible missing channels.
+  An attacker would have been able to flood the node with fake SCIDs, causing an
+  ever-increasing memory consumption. Although the bug had not been previously
+  reported, Rusty Russell was already working on a patch in
+  [Core Lightning #8903][], which introduced an improved garbage collection
+  mechanism for the internal map.
+
+- **Proof of concept for a zero-knowledge proof of reserves**: fabohax [posted][zkpoh del]
+  about zkPoH ("zero-knowledge proof-of-hodl"), a proof of concept for a
+  non-custodial [proof of reserves][topic proof of reserves] system for Bitcoin.
+  The prototype allows a user to prove that they control a set of UTXOs, whose combined
+  value is at least 100,000,000 sats (1 BTC), without revealing any further information.
+
+  The proof of concept takes as input a UTXO snapshot generated off-chain, which is then
+  committed into a merkle tree, whose root becomes the public commitment. The prover
+  selects up to four UTXOs from the snapshot and generates the witness input for the
+  [Noir][noir lang] circuit, which verifies that the chosen UTXOs actually belong to
+  the snapshot, the merkle paths are valid, and the sum of the selected UTXOs is at
+  least the required amount. The verifier only learns that the prover satisfies the
+  100,000,000 sats requirement.
+
+  As of this writing, an explicit ownership binding step is not available in the proof of
+  concept. This means that there is no way to prove that the chosen UTXOs actually
+  belong to the prover. The author is currently working on adding this feature, either
+  through an off-circuit ownership check or directly inside it. The prototype is
+  currently available in a dedicated [repository][zkpoh gh].
+
+## Selected Q&A from Bitcoin Stack Exchange
+
+*[Bitcoin Stack Exchange][bitcoin.se] is one of the first places Optech
+contributors look for answers to their questions---or when we have a
+few spare moments to help curious or confused users.  In
+this monthly feature, we highlight some of the top-voted questions and
+answers posted since our last update.*
+
+{% comment %}<!-- https://bitcoin.stackexchange.com/search?tab=votes&q=created%3a1m..%20is%3aanswer -->{% endcomment %}
+{% assign bse = "https://bitcoin.stackexchange.com/a/" %}
+
+- [What is Bitcoin's objective definition of transaction neutrality?]({{bse}}130849)
+  Ava Chow frames neutrality as whether a change prevents anyone from
+  continuing to use Bitcoin as they already do, such as making previously
+  spendable scripts unspendable or breaking a deployed protocol.
+
+- [Why does BIP110's decentralization benefit not outweigh its impact on transaction neutrality?]({{bse}}130848)
+  Pieter Wuille argues that invalidating data-carrying transaction patterns
+  would not reduce node costs because the block weight limit already bounds
+  resource usage, data storage bytes are among the cheapest to process, and
+  outlawed patterns would simply be replaced by other transactions.
+
+- [Why does BIP110 require a 55% signaling threshold if its nodes reject non-signaling blocks?]({{bse}}130885)
+  Vojtěch Strnad explains that the threshold applies to voluntary miner
+  signaling before the mandatory signaling period begins (see [Newsletter
+  #392][news392 bip110]). An early lock-in indicates wider buy-in and can
+  activate the soft fork sooner, but once mandatory signaling begins, enforcing
+  nodes discard non-signaling blocks.
+
+- [Why use ElligatorSwift encoding in BIP324?]({{bse}}130887)
+  Pieter Wuille explains that encoding the handshake's public keys as
+  uniformly random bytes makes the entire [v2 transport][topic v2 p2p
+  transport] bytestream pseudorandom, preventing identification by pattern
+  matching and forcing a censoring firewall to either mount a full
+  man-in-the-middle attack or operate an allowlist. It can also make it easier
+  to mimic other protocols.
+
+- [Was the OP_SUCCESSx reservation in BIP342 designed with specific opcode families in mind?]({{bse}}130670)
+  Murch describes the `OP_SUCCESS` opcodes as generic upgrade hooks. Since
+  any `OP_SUCCESS` makes a [tapscript][topic tapscript] unconditionally
+  valid, a future soft fork can redefine one with more restrictive
+  behavior, including stack manipulation that redefined `OP_NOP` opcodes
+  could never perform.
+
+- [What is the difference between the long-term feerate and the discard feerate?]({{bse}}130861)
+  Murch clarifies that the two are not interchangeable. The discard feerate
+  sets the dust limits below which a potential change output's value is given
+  to fees, while the long-term feerate sets the wallet's boundary between
+  consolidatory and thrifty [coin selection][topic coin selection].
+
+- [What is the quickest method for migrating a legacy wallet to a descriptor wallet on a pruned node?]({{bse}}130713)
+  Pol Espinasa explains that migration attempts to load the migrated wallet,
+  which fails on a node pruned below the wallet's birthday. [Bitcoin Core
+  #35266][] (see [Newsletter #412][news412 migratewallet]), expected in
+  version 32.0, allows migrating without loading the wallet, although loading
+  the migrated [descriptor][topic descriptors] wallet will still require a
+  node with the relevant blocks.
+
+- [Is there historical data on orphan/stale block rates during high-fee periods?]({{bse}}130889)
+  0xB10C points to the [stale-blocks dataset][stale blocks site] maintained by
+  the bitcoin-data project, which charts the stale block rate over time and
+  provides the [raw data][stale blocks repo] for deriving custom metrics.
+
+## Releases and release candidates
+
+_New releases and release candidates for popular Bitcoin infrastructure
+projects.  Please consider upgrading to new releases or helping to test
+release candidates._
+
+- [BTCPay Server 2.4.1][] is a maintenance release for this self-hosted payment
+  processor. It adds [BIP329][] wallet label imports (see [Newsletter
+  #415][news415 labels]), editable invoice comments, and several other
+  improvements and bug fixes.
+
+- [Eclair 0.14.1][] is a maintenance release for this LN node implementation.
+  It now requires Bitcoin Core 31.x, disables an experimental [BOLT12][topic
+  offers] blinded-path fee discount that did not correctly work with
+  [multipath payments][topic multipath payments], and includes several bug fixes
+  and performance improvements. Operators using custom offer-handler plugins
+  should review the [release notes][eclair 0.14.1 notes].
+
+## Notable code and documentation changes
+
+_Notable recent changes in [Bitcoin Core][bitcoin core repo], [Core
+Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo],
+[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet
+Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay
+Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement
+Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo],
+[Lightning BLIPs][blips repo], [Bitcoin Inquisition][bitcoin inquisition
+repo], and [BINANAs][binana repo]._
+
+- [Bitcoin Core #34628][] replaces independent per-peer transaction relay
+  backlogs with global inbound and outbound backlogs controlled by count and
+  serialized size token buckets. This reduces duplicate storage and sorting
+  across peers, which contributed to a CPU exhaustion problem (see [Newsletter
+  #324][news324 inv]). Relay credit starts at 420 transaction tokens and 12 MB,
+  replenishing at a rate of 14 transactions and 20 kB/s for the inbound peer
+  backlog. The count balance is capped at 420 tokens, while the size balance can
+  accumulate up to 50 MB. The outbound refill rate retains the 2.5-times
+  multiplier described in [Newsletter #373][news373 rate]. When relay demand
+  exceeds available credit, transactions are prioritized by mining score while
+  respecting dependencies. Selected transactions then enter small, randomized,
+  per-peer queues. New `getnetworkinfo` fields expose each backlog and its token
+  balances, and the debug-only `-txsendrate` option allows testing different
+  count rates.
+
+- [Bitcoin Core #28463][] increases the default maximum number of connections
+  from 125 to 200 and adds the `-inboundrelaypercent` option (default 50), which
+  sets the maximum percentage of inbound slots that transaction-relaying peers
+  can occupy. With eleven outbound slots by default, 189 slots remain available
+  for inbound connections, of which at most 94 may be occupied by
+  transaction-relaying peers under the default setting. This limit is enforced
+  after a peer announces its relay preference and is rechecked if the peer later
+  enables transaction relay using [BIP37][] messages. This reserves capacity for
+  low-bandwidth block relay and prepares for the addition of more outbound
+  block-relay-only connections, to improve resistance to [eclipse attacks][topic
+  eclipse attacks].
+
+- [Bitcoin Core #32800][] adds explicit [BIP141][] and policy-adjusted
+  transaction size fields to several RPCs. `vsize_bip141` reports the virtual
+  size calculated from the transaction's weight, while `vsize_adjusted` reports
+  the greater of that value or the size implied by the transaction's sigops cost
+  under the configured `-bytespersigop` policy. The adjusted value is used for
+  mempool policy and block template feerate calculations. `getmempoolentry`,
+  verbose `getrawmempool`, `testmempoolaccept`, and `submitpackage` now report
+  both fields. The existing `vsize` field, which was documented as the BIP141
+  virtual size but actually contained the policy-adjusted value, is retained but
+  marked as deprecated. Additionally, `getrawtransaction` reports
+  `vsize_adjusted` when the transaction is in the mempool, while its existing
+  `vsize` remains the BIP141 value. The verbose output of `getorphantxs` also
+  adds the explicit `vsize_bip141` field.
+
+- [Bitcoin Core #34683][] adds an automatically generated [OpenRPC 1.4.1][]
+  description of the RPC interface. The new `rpc.discover` RPC returns the
+  public interface, while `getopenrpcinfo` can optionally include hidden
+  commands and arguments. The document is generated at runtime from the
+  `RPCHelpMan` metadata for all registered RPCs, and describes method
+  parameters, required and default values, result shapes, and other interface
+  details.
+
+- [Bitcoin Core #33014][] fixes how `descriptorprocesspsbt` (see [Newsletter
+  #253][news253 descriptorpsbt]) handles a [PSBT][topic psbt] whose finalized
+  script fields are populated but contain invalid signatures. Previously, the
+  RPC only checked for the presence of final scripts, marked the PSBT as
+  complete, and returned an internal error when transaction extraction failed.
+  Now, it verifies every input before reporting completion, so a PSBT with an
+  invalid signature returns `complete: false` without a serialized transaction
+  in the `hex` field.
+
+- [Eclair #3325][] accepts [BOLT12][topic offers] invoice [onion messages][topic
+  onion messages] that include a `reply_path`. A payee can attach a
+  [blinded][topic rv routing] reply path to an invoice so that the payer can
+  return an `invoice_error` if it considers the invoice invalid. Eclair
+  previously rejected this combination, causing interoperability problems with
+  LDK, which added reply paths to invoices (see [Newsletter #321][news321
+  replypath]).
+
+- [BOLTs #1346][] specifies [BOLT12][topic offers] payer proofs, a receipt format
+  that allows [a payer to prove][topic proof of payment] they paid an invoice
+  using the payment preimage, the invoicing node's signature, and a payer
+  signature from `invreq_payer_id`, while allowing selected invoice fields to be
+  omitted for privacy. The specification assigns the `lnp` human-readable
+  prefix and adds generation and verification test vectors. Core Lightning
+  experimentally implemented an earlier draft (see [Newsletter #405][news405
+  proof]).
+
+- [BOLTs #1344][] extends the [attributable failures][topic attributable
+  failures] protocol to successful payments by adding an optional
+  `fulfillment_payload` to `update_fulfill_htlc`, the message that returns the
+  payment preimage and settles an [HTLC][topic htlc]. Only a padding field is
+  defined, so the PR establishes transport for future success-related data, such
+  as signed [keysend][topic spontaneous payments] receipts, without yet
+  standardizing any application.
+
+- [BOLTs #1343][] adds the `option_onion_messages_only_channels` feature bit for
+  nodes that only accept [onion messages][topic onion messages] from channel
+  peers. Nodes that do not advertise this feature should accept onion messages
+  from peers without channels, though they may still rate-limit or drop them.
+  This feature allows senders to avoid relay paths that are known to fail while
+  enabling operators to reduce their exposure to denial-of-service attacks. See
+  [Newsletter #409][news409 onion] for an LDK workaround that addresses LND's
+  behavior of receiving but not forwarding onion messages from non-channel
+  peers.
+
+{% include snippets/recap-ad.md when="2026-08-04 16:30" %}
+{% include references.md %}
+{% include linkers/issues.md v=2 issues="8376,8903,35266,34628,28463,32800,34683,33014,3325,1346,1344,1343" %}
+
+[news392 bip110]: /en/newsletters/2026/02/13/#bips-2017
+[news412 migratewallet]: /en/newsletters/2026/07/03/#bitcoin-core-35266
+[stale blocks site]: https://bitcoin-data.github.io/stale-blocks/
+[stale blocks repo]: https://github.com/bitcoin-data/stale-blocks
+[cln vuln del]:https://delvingbitcoin.org/t/vulnerability-disclosure-twin-memory-exhaustion-dos-vulnerabilities-in-core-lightning/2731
+[sob]:https://www.summerofbitcoin.org/
+[zkpoh del]: https://delvingbitcoin.org/t/zkpoh-zero-knowledge-proof-of-hodl/2699
+[noir lang]: https://noir-lang.org/
+[zkpoh gh]: https://github.com/fabohax/zkPoH
+[BTCPay Server 2.4.1]: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.1
+[Eclair 0.14.1]: https://github.com/ACINQ/eclair/releases/tag/v0.14.1
+[eclair 0.14.1 notes]: https://github.com/ACINQ/eclair/blob/v0.14.1/docs/release-notes/eclair-v0.14.1.md
+[OpenRPC 1.4.1]: https://spec.open-rpc.org/
+[news415 labels]: /en/newsletters/2026/07/24/#btcpay-server-7457
+[news324 inv]: /en/newsletters/2024/10/11/#dos-from-large-inventory-sets
+[news373 rate]: /en/newsletters/2025/09/26/#bitcoin-core-28592
+[news253 descriptorpsbt]: /en/newsletters/2023/05/31/#bitcoin-core-25796
+[news321 replypath]: /en/newsletters/2024/09/20/#ldk-3163
+[news405 proof]: /en/newsletters/2026/05/15/#core-lightning-9116
+[news409 onion]: /en/newsletters/2026/06/12/#ldk-4647
+[coinkite advisory]: https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
+[coinkite blog]: https://blog.coinkite.com/
+[coinkite backgrounder]: https://blog.coinkite.com/entropy-technical-backgrounder/
+[block analysis]: https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
diff --git a/_topics/en/attributable-failures.md b/_topics/en/attributable-failures.md
index 799dd55cb..871cde6af 100644
--- a/_topics/en/attributable-failures.md
+++ b/_topics/en/attributable-failures.md
@@ -50,6 +50,9 @@ optech_mentions:
   - title: "LDK #3801 extends attributable failures to the payment success path"
     url: /en/newsletters/2025/07/25/#ldk-3801
 
+  - title: "BOLTs #1344 extends attributable failures to successful payments"
+    url: /en/newsletters/2026/07/31/#bolts-1344
+
 ## Optional.  Same format as "primary_sources" above
 # see_also:
 #   - title:
diff --git a/_topics/en/coin-selection.md b/_topics/en/coin-selection.md
index 8893901d9..a0c21ba95 100644
--- a/_topics/en/coin-selection.md
+++ b/_topics/en/coin-selection.md
@@ -93,6 +93,9 @@ optech_mentions:
   - title: "Bitcoin Core #32150 rewrites the branch-and-bound algorithm to search more distinct candidates"
     url: /en/newsletters/2026/06/12/#bitcoin-core-32150
 
+  - title: "Difference between the long-term feerate and the discard feerate"
+    url: /en/newsletters/2026/07/31/#what-is-the-difference-between-the-long-term-feerate-and-the-discard-feerate
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: An Evaluation of Coin Selection Strategies
diff --git a/_topics/en/eclipse-attacks.md b/_topics/en/eclipse-attacks.md
index 782f300ff..8d03a163a 100644
--- a/_topics/en/eclipse-attacks.md
+++ b/_topics/en/eclipse-attacks.md
@@ -86,6 +86,9 @@ optech_mentions:
   - title: "Bitcoin Core #29850 limits the max number of IP addresses accepted from an individual DNS seed"
     url: /en/newsletters/2024/04/24/#bitcoin-core-29850
 
+  - title: "Bitcoin Core #28463 raises default connection limit, reserves inbound slots for block-relay peers"
+    url: /en/newsletters/2026/07/31/#bitcoin-core-28463
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Anonymity networks
diff --git a/_topics/en/offers.md b/_topics/en/offers.md
index 6186e4ce4..e8f355f90 100644
--- a/_topics/en/offers.md
+++ b/_topics/en/offers.md
@@ -144,6 +144,9 @@ optech_mentions:
   - title: "BLIPs #42 adds BLIP42, a specification for BOLT12 contacts"
     url: /en/newsletters/2026/05/22/#blips-42
 
+  - title: "Eclair #3325 accepts BOLT12 invoices with attached reply paths"
+    url: /en/newsletters/2026/07/31/#eclair-3325
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Blinded paths
diff --git a/_topics/en/onion-messages.md b/_topics/en/onion-messages.md
index 832105bdc..0d57a45b4 100644
--- a/_topics/en/onion-messages.md
+++ b/_topics/en/onion-messages.md
@@ -107,6 +107,9 @@ optech_mentions:
   - title: "LND #10612 adds graph-based pathfinding for onion messages"
     url: /en/newsletters/2026/05/15/#lnd-10612
 
+  - title: "BOLTs #1343 adds a feature bit for accepting onion messages only from channel peers"
+    url: /en/newsletters/2026/07/31/#bolts-1343
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Blinded paths
diff --git a/_topics/en/output-script-descriptors.md b/_topics/en/output-script-descriptors.md
index 78f197478..4deaccb50 100644
--- a/_topics/en/output-script-descriptors.md
+++ b/_topics/en/output-script-descriptors.md
@@ -221,6 +221,9 @@ optech_mentions:
   - title: "BIPs #1548 adds BIP391, a closed specification for Binary Output Descriptors superseded by BIP393"
     url: /en/newsletters/2026/05/01/#bips-1548
 
+  - title: "Migrating a legacy wallet to a descriptor wallet on a pruned node"
+    url: /en/newsletters/2026/07/31/#what-is-the-quickest-method-for-migrating-a-legacy-wallet-to-a-descriptor-wallet-on-a-pruned-node
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Miniscript
diff --git a/_topics/en/proof-of-payment.md b/_topics/en/proof-of-payment.md
index 0b0dbccd9..f937e9db0 100644
--- a/_topics/en/proof-of-payment.md
+++ b/_topics/en/proof-of-payment.md
@@ -52,6 +52,9 @@ optech_mentions:
   - title: "LDK #4685 moves BOLT12 verification nonce into payer metadata for compatibility with  payment proofs"
     url: /en/newsletters/2026/06/19/#ldk-4685
 
+  - title: "BOLTs #1346 specifies BOLT12 payer proofs"
+    url: /en/newsletters/2026/07/31/#bolts-1346
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Pay to contract
diff --git a/_topics/en/proof-of-reserves.md b/_topics/en/proof-of-reserves.md
index 43afef662..3f7cac993 100644
--- a/_topics/en/proof-of-reserves.md
+++ b/_topics/en/proof-of-reserves.md
@@ -39,6 +39,9 @@ optech_mentions:
   - title: "Kraken announces proof of reserves scheme"
     url: /en/newsletters/2022/02/16/#kraken-announces-proof-of-reserves-scheme
 
+  - title: "Proof of concept for a zero-knowledge proof of reserves"
+    url: /en/newsletters/2026/07/31/#proof-of-concept-for-a-zero-knowledge-proof-of-reserves
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: BIP322 signature proofs
diff --git a/_topics/en/psbt.md b/_topics/en/psbt.md
index 6754df116..792019b6d 100644
--- a/_topics/en/psbt.md
+++ b/_topics/en/psbt.md
@@ -252,6 +252,9 @@ optech_mentions:
   - title: "BIPs #2075 clarifies BIP174's description of how PSBTs are combined"
     url: /en/newsletters/2026/07/24/#bips-2075
 
+  - title: "Bitcoin Core #33014 verifies signatures before reporting a PSBT complete"
+    url: /en/newsletters/2026/07/31/#bitcoin-core-33014
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Output Script Descriptors
diff --git a/_topics/en/responsible-disclosures.md b/_topics/en/responsible-disclosures.md
index e08e9436c..2c1795029 100644
--- a/_topics/en/responsible-disclosures.md
+++ b/_topics/en/responsible-disclosures.md
@@ -196,6 +196,9 @@ optech_mentions:
   - title: "Nishant Bansal responsibly disclosed a gossip DoS vulnerability affecting LND"
     url: /en/newsletters/2026/06/26/#lnd-zero-timestamp-gossip-dos-disclosure
 
+  - title: "Chandra Pratap disclosed two memory-exhaustion DoS vulnerabilities in Core Lightning"
+    url: /en/newsletters/2026/07/31/#disclosure-of-two-dos-vulnerabilities-in-core-lightning
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: "Common Vulnerabilities and Exposures (CVEs)"
diff --git a/_topics/en/tapscript.md b/_topics/en/tapscript.md
index 09453a2c7..e281ce5b0 100644
--- a/_topics/en/tapscript.md
+++ b/_topics/en/tapscript.md
@@ -109,6 +109,9 @@ optech_mentions:
   - title: "Proposal to embed post-quantum keys in tapscript without consensus changes"
     url: /en/newsletters/2026/05/01/#proposal-to-embed-post-quantum-keys-in-tapscript-without-consensus-changes
 
+  - title: "OP_SUCCESSx opcodes as generic tapscript upgrade hooks"
+    url: /en/newsletters/2026/07/31/#was-the-op-successx-reservation-in-bip342-designed-with-specific-opcode-families-in-mind
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Taproot
diff --git a/_topics/en/v2-p2p-transport.md b/_topics/en/v2-p2p-transport.md
index 15354f944..19abd9182 100644
--- a/_topics/en/v2-p2p-transport.md
+++ b/_topics/en/v2-p2p-transport.md
@@ -92,6 +92,9 @@ optech_mentions:
   - title: "Bitcoin Core #35766 defaults to v2 transport when connecting to addresses from seeds"
     url: /en/newsletters/2026/07/24/#bitcoin-core-35766
 
+  - title: "Why use ElligatorSwift encoding in BIP324?"
+    url: /en/newsletters/2026/07/31/#why-use-elligatorswift-encoding-in-bip324
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: BIP151
diff --git a/_topics/en/wallet-labels.md b/_topics/en/wallet-labels.md
index ef5168a46..1b74917b4 100644
--- a/_topics/en/wallet-labels.md
+++ b/_topics/en/wallet-labels.md
@@ -57,6 +57,9 @@ optech_mentions:
   - title: "BTCPay Server #7457 adds importing of wallet labels in BIP329 format"
     url: /en/newsletters/2026/07/24/#btcpay-server-7457
 
+  - title: "BTCPay Server 2.4.1 ships BIP329 wallet label imports"
+    url: /en/newsletters/2026/07/31/#btcpay-server-2-4-1
+
 ## Optional.  Same format as "primary_sources" above
 see_also:
   - title: Output script descriptors