From feaa8a36eb7c77cb46b718b12b1092318c981d73 Mon Sep 17 00:00:00 2001
From: jlwllmr <95916148+jlwllmr@users.noreply.github.com>
Date: Thu, 19 Sep 2024 11:06:45 +0100
Subject: [PATCH] Expand with detail about relevant API methods

---
 .../trace-expansion-proving/prover-limits.mdx  | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/docs/architecture/stack/trace-expansion-proving/prover-limits.mdx b/docs/architecture/stack/trace-expansion-proving/prover-limits.mdx
index 12ff993eb..82e8a84a1 100644
--- a/docs/architecture/stack/trace-expansion-proving/prover-limits.mdx
+++ b/docs/architecture/stack/trace-expansion-proving/prover-limits.mdx
@@ -6,18 +6,30 @@ sidebar_position: 3
 
 Linea has a built-in mechanism for ensuring that the prover can continue to generate proofs
 without increasing proof complexity to such a level that current infrastructure cannot process them. 
-This buffer is represented by module limits. 
+This mechanism involves module limits. 
 
 Modules are the sections into which Linea's arithmetization specification is divided. Each module 
-represents a collection of operations (opcodes) at the EVM level, and corresponds to a specific 
+represents a collection of operations (opcodes) at the EVM level, or corresponds to a specific 
 function of Linea's zkEVM. Some of the modules process transaction data; some manage zkEVM memory; 
 others coordinate interactions between modules.
 
 Regardless of its purpose, each module has a specific limit to the amount of lines of data that 
 its operations can generate. You can view each module's limits in the [Linea source code](https://github.com/Consensys/linea-monorepo/blob/main/config/common/traces-limits-besu-v2.toml).
-Every time one of the operations in a module is 
+Every time one of the operations in a module is used, it generates additional lines.
 
 Transactions with a high complexity—using a large volume of operations repeatedly—may generate too 
 many lines of data, and exceed that module's limit. Transactions that reach this point are 
 rejected by the [sequencer](../sequencer/index.mdx) to ensure that the trace data passed to the 
 prover is of a manageable scope, and that a proof can be generated.
+
+Transaction rejections caused by module limits are prevented at one of three stages:
+1. [`linea_estimateGas`](../../../developers/reference/api/linea-estimategas.mdx), which simulates
+a transaction using given parameters. Transactions that exceed module limits cause an error.
+2. [`eth_sendRawTransaction`](../../../developers/reference/api/eth-sendrawtransaction.mdx). 
+Similarly, `eth_sendRawTransaction` simulates the transaction before it is submitted, and 
+returns an error if module limits would be exceeded.
+3. As a final protection, the [`linea_getTransactionExclusionStatusV1`](../../../developers/reference/api/linea-gettransactionexclusionstatusv1.mdx)
+API method can be used to query the reason for transaction rejection in edge cases where 
+`linea_estimateGas` or `eth_sendRawTransaction` did not return an error. `linea_getTransactionExclusionStatusV1`
+is only available for Infura nodes via request. View its [reference page](../../../developers/reference/api/linea-gettransactionexclusionstatusv1.mdx) 
+for more information on requesting it.