From 2c9deea80f88954ad046d753ff60d65d700b84ed Mon Sep 17 00:00:00 2001
From: "github-merge-queue[bot]"
 <github-merge-queue[bot]@users.noreply.github.com>
Date: Wed, 2 Oct 2024 14:06:34 +0000
Subject: [PATCH] deploy: ef812f9f3a2e6d3a490194be1e143d069ca04659

---
 architecture/how/receipt-congestion.html | 4 ++--
 print.html                               | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/architecture/how/receipt-congestion.html b/architecture/how/receipt-congestion.html
index 8343f39807c..e7f734c5e4f 100644
--- a/architecture/how/receipt-congestion.html
+++ b/architecture/how/receipt-congestion.html
@@ -176,7 +176,7 @@ <h2 id="cross-shard-congestion-as-flow-problem"><a class="header" href="#cross-s
 <p>For a finite amount of time, we can accept more inflow than outflow, we just have to add buffers to store what we cannot execute, yet. But to stay within finite memory requirements, we need to fall back to a flow diagram where outflows are greater or equal to inflows within a finite time frame.</p>
 <p>Next, we look at ideas one at a time before combining some of them into the
 cross-shard congestion design proposed in
-<a href="https://github.com/near/NEPs/pull/539">NEP-539</a>.</p>
+<a href="https://github.com/near/NEPs/blob/master/neps/nep-0539.md">NEP-539</a>.</p>
 <h2 id="idea-1-compute-the-minimum-max-flow-and-stay-below-that-limit"><a class="header" href="#idea-1-compute-the-minimum-max-flow-and-stay-below-that-limit">Idea 1: Compute the minimum max-flow and stay below that limit</a></h2>
 <p>One approach to solve congestion would be to never allow more work into the
 system than we can execute.</p>
@@ -276,7 +276,7 @@ <h2 id="idea-4-keep-minimum-incoming-queue-length-to-avoid-deadlocks"><a class="
 transactions to those shards are rejected. All of this without affecting shards
 that are not on the critical path.</p>
 <h2 id="putting-it-all-together"><a class="header" href="#putting-it-all-together">Putting it all together</a></h2>
-<p>The proposal in <a href="https://github.com/near/NEPs/pull/539">NEP-539</a> combines all
+<p>The proposal in <a href="https://github.com/near/NEPs/blob/master/neps/nep-0539.md">NEP-539</a> combines all
 ideas 2, 3, and 4.</p>
 <p>We have a limit of how much memory we consider to be normal operations (for
 example 500 MB). Then we stop new transaction coming in to that shard but still
diff --git a/print.html b/print.html
index f7876caea49..88aaa65f501 100644
--- a/print.html
+++ b/print.html
@@ -1670,7 +1670,7 @@ <h2 id="cross-shard-congestion-as-flow-problem"><a class="header" href="#cross-s
 <p>For a finite amount of time, we can accept more inflow than outflow, we just have to add buffers to store what we cannot execute, yet. But to stay within finite memory requirements, we need to fall back to a flow diagram where outflows are greater or equal to inflows within a finite time frame.</p>
 <p>Next, we look at ideas one at a time before combining some of them into the
 cross-shard congestion design proposed in
-<a href="https://github.com/near/NEPs/pull/539">NEP-539</a>.</p>
+<a href="https://github.com/near/NEPs/blob/master/neps/nep-0539.md">NEP-539</a>.</p>
 <h2 id="idea-1-compute-the-minimum-max-flow-and-stay-below-that-limit"><a class="header" href="#idea-1-compute-the-minimum-max-flow-and-stay-below-that-limit">Idea 1: Compute the minimum max-flow and stay below that limit</a></h2>
 <p>One approach to solve congestion would be to never allow more work into the
 system than we can execute.</p>
@@ -1770,7 +1770,7 @@ <h2 id="idea-4-keep-minimum-incoming-queue-length-to-avoid-deadlocks"><a class="
 transactions to those shards are rejected. All of this without affecting shards
 that are not on the critical path.</p>
 <h2 id="putting-it-all-together"><a class="header" href="#putting-it-all-together">Putting it all together</a></h2>
-<p>The proposal in <a href="https://github.com/near/NEPs/pull/539">NEP-539</a> combines all
+<p>The proposal in <a href="https://github.com/near/NEPs/blob/master/neps/nep-0539.md">NEP-539</a> combines all
 ideas 2, 3, and 4.</p>
 <p>We have a limit of how much memory we consider to be normal operations (for
 example 500 MB). Then we stop new transaction coming in to that shard but still