diff --git a/docs/architecture/how/receipt-congestion.md b/docs/architecture/how/receipt-congestion.md
index 0b0010a055d..34f51eec3eb 100644
--- a/docs/architecture/how/receipt-congestion.md
+++ b/docs/architecture/how/receipt-congestion.md
@@ -48,7 +48,7 @@ For a finite amount of time, we can accept more inflow than outflow, we just hav
 
 Next, we look at ideas one at a time before combining some of them into the
 cross-shard congestion design proposed in
-[NEP-539](https://github.com/near/NEPs/pull/539).
+[NEP-539](https://github.com/near/NEPs/blob/master/neps/nep-0539.md).
 
 ## Idea 1: Compute the minimum max-flow and stay below that limit
 
@@ -185,7 +185,7 @@ that are not on the critical path.
 
 ## Putting it all together
 
-The proposal in [NEP-539](https://github.com/near/NEPs/pull/539) combines all
+The proposal in [NEP-539](https://github.com/near/NEPs/blob/master/neps/nep-0539.md) combines all
 ideas 2, 3, and 4.
 
 We have a limit of how much memory we consider to be normal operations (for
@@ -208,4 +208,4 @@ it back cannot lead to a slowed down global throughput.
 Another design decision was to linearly interpolate the limits, as opposed to
 binary on and off states. This way, we don't have to be too precise in finding
 the right parameters, as the system should balance itself around a specific
-limit that works for each workload.
\ No newline at end of file
+limit that works for each workload.