diff --git a/akka_msquic_transport.md b/akka_msquic_transport.md
index 00c8ea8..ef095e7 100644
--- a/akka_msquic_transport.md
+++ b/akka_msquic_transport.md
@@ -41,6 +41,21 @@ recommendation at the end.
 
 So "wait for 1.6" is not a near-term plan. QUIC benefits this year would mean building it in-house.
 
+> **STATUS UPDATE (2026-07-22, same day, deeper look):** the two paragraphs above are correct about
+> *QUIC* but stale about *Artery* — searching PRs for "quic" missed work named "artery".
+> **Artery implementation began 2026-07-03 and is landing rapidly on `dev`, as Artery-TCP** (the
+> JVM-parallel move): design spec via openspec (#8313, "artery-tcp-remoting"), transport-substrate
+> validation gate G0 (#8315), TCP framing + envelope codec G1 (#8319), handshake/association G2
+> (#8320), parallel inbound/outbound lanes (#8356/#8357, Jul 11), dedicated large-message stream
+> streamId 3 (#8352, Jul 10), quarantine port in flight (#8416), MNTR/CI integration for both
+> transports (#8373/#8413). 192/192 Artery specs passing as of #8352. In parallel,
+> **Serialization.V2** (source-generated + MessagePack internals) is in heavy development — ~30
+> merged PRs with wire-format snapshot tests and an open cross-component integration proof suite
+> (#8407). TCP-first also confirms §7's forward-looking note: the Artery benefits (lanes,
+> large-message stream, control stream) are arriving **transport-agnostic over TCP** — no libmsquic
+> required — with QUIC as a later substrate swap. No preview release or public benchmark numbers
+> yet; see the 1.6-status section of the conversation record for the remaining-work list.
+
 ## 2. What the projects run today
 
 Both ScadaBridge and OtOpcUa pin **Akka 1.5.62** and use the classic **`dot-netty.tcp`** transport,
@@ -246,10 +261,12 @@ extra framing. Only interesting for exotic proxy/firewall traversal. Skip.
 QUIC implementation in .NET, and nothing else in the box provides independent streams. So "QUIC
 without libmsquic" is not on the table, on any .NET version.
 
-Forward-looking note: if Akka.NET's 1.6 Artery ships QUIC-only, libmsquic becomes unavoidable *at
-that point* — worth watching whether upstream adds a TCP mode (to11mtm explicitly advocated
-transport pluggability for firewall-restricted environments in the #7466 design discussion, citing
-the JVM's TCP Artery).
+Forward-looking note — **resolved 2026-07-22**: upstream did exactly this. The Artery port that
+began landing on `dev` in July 2026 is **Artery-TCP** (openspec #8313), so the pipeline benefits
+arrive without libmsquic, and QUIC becomes a later optional substrate — the outcome to11mtm
+advocated in the #7466 design discussion. This also removes the platform/ops constraints of §6
+from the 1.6 adoption path (TCP, no native deps, no UDP firewall changes) unless/until a QUIC
+substrate is chosen deliberately.
 
 ## 8. Would it actually alleviate the gRPC?