docs: Polygon runs on Bor — trace_*/erigon_* unavailable, migrate to debug_*#515
Conversation
…t (Aug 1, 2026) Polygon Labs is sunsetting the Erigon client on Polygon PoS mainnet by August 1, 2026 (forum.polygon.technology/t/sunsetting-erigon-support/21872). Erigon serves the Parity trace_* and erigon_* namespaces; Bor (the remaining client) serves the Geth debug_trace* methods. After the cutover those namespaces stop working on Polygon. - polygon-methods: add a deprecation Warning + trace_* -> debug_trace* migration table; annotate the 8 trace_* and 8 erigon_* rows. - polygon-trace_transaction / polygon-trace_block reference pages: add a deprecation Warning pointing to debug_traceTransaction / debug_traceBlockByNumber. Verified live on Chainstack Polygon mainnet (2026-07-07): trace_transaction returns data via Erigon today; debug_traceTransaction and debug_traceBlockByNumber with callTracer return equivalent call traces on Bor.
|
|
Warning Review limit reached
Next review available in: 53 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR updates Polygon documentation to identify Erigon-only ChangesPolygon Bor Trace Documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…f caveat Per Chainstack Infra (INFRA-9692 / #dev-infra-product): Chainstack retires Erigon from Polygon Mainnet on Jul 29, 2026, moving archive to Bor + PBSS — ahead of Polygon's upstream Erigon sunset (Aug 1). Lead the docs with the Jul 29 Chainstack-effective date; keep Aug 1 as upstream context. Also document that eth_getProof on Bor serves only ~the latest 128 blocks (Erigon served full history) — a regression the original PR missed.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/polygon-methods.mdx (2)
21-23: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winCall out the lossy trace migration
trace_filter/trace_replay*are not drop-in replacements fordebug_traceBlockByNumberoreth_getLogs; the former expose trace data, while the latter only returns logs. Spell out the client-side filtering/normalization needed so downstream parsers don’t lose internal calls.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/polygon-methods.mdx` around lines 21 - 23, Update the trace migration guidance in docs/polygon-methods.mdx to distinguish trace data from event logs: do not present debug_traceBlockByNumber or eth_getLogs as equivalent drop-in replacements for trace_filter or trace_replay*. Explicitly document the client-side filtering and normalization required when using these alternatives, preserving internal-call trace data for downstream parsers.
16-21: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winFill in the missing migration guidance for
trace_callManyandtrace_rawTransaction. In lines 16–21, both methods are marked removed, but this table doesn’t say what Bor users should use instead or that no direct replacement exists.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/polygon-methods.mdx` around lines 16 - 21, Update the Erigon trace-method replacement table to add migration guidance for trace_callMany and trace_rawTransaction, explicitly stating that Bor has no direct replacement for each removed method. Keep the existing mappings unchanged and place the new entries alongside the other trace_* methods.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/polygon-methods.mdx`:
- Line 23: Update the method guidance in the debug_trace*/erigon_* documentation
so erigon_forks explicitly states that it has no direct eth_* equivalent, while
erigon_getBlockByTimestamp directs users to a timestamp lookup flow such as
binary-searching via eth_getBlockByNumber; avoid applying the blanket fallback
to these methods.
- Line 25: Update the eth_getProof history-limit statement in the Polygon
documentation to match the established Erigon limit of the most recent 100,000
blocks, replacing the claim that Erigon served the full history while preserving
the Bor limit and retrieval-date guidance.
---
Outside diff comments:
In `@docs/polygon-methods.mdx`:
- Around line 21-23: Update the trace migration guidance in
docs/polygon-methods.mdx to distinguish trace data from event logs: do not
present debug_traceBlockByNumber or eth_getLogs as equivalent drop-in
replacements for trace_filter or trace_replay*. Explicitly document the
client-side filtering and normalization required when using these alternatives,
preserving internal-call trace data for downstream parsers.
- Around line 16-21: Update the Erigon trace-method replacement table to add
migration guidance for trace_callMany and trace_rawTransaction, explicitly
stating that Bor has no direct replacement for each removed method. Keep the
existing mappings unchanged and place the new entries alongside the other
trace_* methods.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 766490a2-500f-4cfe-8209-beffd21f0e89
📒 Files selected for processing (3)
docs/polygon-methods.mdxreference/polygon-trace_block.mdxreference/polygon-trace_transaction.mdx
🚧 Files skipped from review as they are similar to previous changes (2)
- reference/polygon-trace_block.mdx
- reference/polygon-trace_transaction.mdx
| | `trace_call` | [`debug_traceCall`](/reference/polygon-tracecall) with `callTracer` | | ||
| | `trace_filter`, `trace_replayBlockTransactions`, `trace_replayTransaction` | [`debug_traceBlockByNumber`](/reference/polygon-traceblockbynumber) per block, or [`eth_getLogs`](/docs/understanding-eth-getlogs-limitations) for event ranges | | ||
|
|
||
| The `debug_trace*` methods return equivalent execution traces on Bor (verified live on Chainstack Polygon nodes). The `erigon_*` convenience methods have no Bor equivalent — use the standard `eth_*` methods instead. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n## docs/polygon-methods.mdx (targeted lines)\n'
nl -ba docs/polygon-methods.mdx | sed -n '1,140p'
printf '\n## search for erigon method mentions\n'
rg -n "erigon_forks|erigon_getBlockByTimestamp|debug_trace|eth_" docs -SRepository: chainstack/dev-portal
Length of output: 245
🏁 Script executed:
#!/bin/bash
set -euo pipefail
if [ -f docs/polygon-methods.mdx ]; then
echo "Exists"
nl -ba docs/polygon-methods.mdx | sed -n '1,120p'
else
echo "Missing docs/polygon-methods.mdx"
fiRepository: chainstack/dev-portal
Length of output: 206
🌐 Web query:
Erigon JSON-RPC erigon_forks erigon_getBlockByTimestamp eth equivalent
💡 Result:
The Erigon-specific JSON-RPC methods erigon_forks and erigon_getBlockByTimestamp are extensions designed to provide specialized data access that is either unavailable or less efficient in the standard Ethereum (eth_) JSON-RPC API namespace [1][2]. 1. erigon_forks: This method returns the genesis block hash and a comprehensive list of all height-based and time-based forks the node is aware of [1][3]. There is no direct standard Ethereum JSON-RPC equivalent that provides this aggregate fork configuration data in a single call [1][2]. 2. erigon_getBlockByTimestamp: This method retrieves a block based on a Unix timestamp by utilizing an internal binary search to efficiently locate the block closest to the specified time [1]. There is no native eth_ method that accepts a timestamp to fetch a block [4]. To achieve this using standard eth_ methods, applications typically must implement their own binary search algorithm by making multiple calls to eth_getBlockByNumber [1][5]. Because these methods are Erigon-specific, they are available in the erigon_ RPC namespace, which can be enabled in your Erigon node configuration (e.g., using the --http.api flag) [1][2]. They are often preferred for their performance optimizations, such as using binary search for timestamp lookups or skipping unnecessary transaction/uncle data [1].
Citations:
- 1: https://docs.erigon.tech/interacting-with-erigon/erigon
- 2: https://docs.erigon.tech/interacting-with-erigon/interacting-with-erigon
- 3: https://www.alchemy.com/docs/chains/ethereum/ethereum-api-endpoints/erigon-forks
- 4: https://docs.erigon.tech/interacting-with-erigon/eth
- 5: fixing bugs in the function GetBlockByTimeStamp erigontech/erigon#6664
Make the Erigon fallback guidance method-specific. erigon_forks has no direct eth_* equivalent, and erigon_getBlockByTimestamp should point to a timestamp lookup flow (for example, a binary search over eth_getBlockByNumber) instead of a blanket “use standard eth_* methods.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/polygon-methods.mdx` at line 23, Update the method guidance in the
debug_trace*/erigon_* documentation so erigon_forks explicitly states that it
has no direct eth_* equivalent, while erigon_getBlockByTimestamp directs users
to a timestamp lookup flow such as binary-searching via eth_getBlockByNumber;
avoid applying the blanket fallback to these methods.
|
|
||
| The `debug_trace*` methods return equivalent execution traces on Bor (verified live on Chainstack Polygon nodes). The `erigon_*` convenience methods have no Bor equivalent — use the standard `eth_*` methods instead. | ||
|
|
||
| `eth_getProof` also changes with the move to Bor: it returns proofs only for roughly the latest 128 blocks, whereas Erigon served the full history. If you rely on historical state proofs on Polygon, retrieve them before July 29, 2026. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== File list ==\n'
git ls-files 'docs/*.mdx' 'docs/**/*.mdx' | sed -n '1,200p'
printf '\n== Relevant snippets ==\n'
for f in docs/polygon-methods.mdx docs/deep-dive-into-merkle-proofs-and-eth-getproof-ethereum-rpc-method.mdx; do
echo "--- $f ---"
if [ -f "$f" ]; then
nl -ba "$f" | sed -n '1,220p' | rg -n "eth_getProof|Erigon|Bor|128|100,000|100000|historical|latest"
else
echo "missing"
fi
doneRepository: chainstack/dev-portal
Length of output: 9179
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
paths = [
Path("docs/polygon-methods.mdx"),
Path("docs/deep-dive-into-merkle-proofs-and-eth-getproof-ethereum-rpc-method.mdx"),
]
for p in paths:
print(f"\n--- {p} ---")
text = p.read_text()
for i, line in enumerate(text.splitlines(), 1):
if any(k in line for k in ["eth_getProof", "Erigon", "Bor", "128", "100,000", "100000", "historical", "latest"]):
print(f"{i}: {line}")
PYRepository: chainstack/dev-portal
Length of output: 8395
🏁 Script executed:
#!/bin/bash
set -euo pipefail
for f in docs/polygon-methods.mdx docs/deep-dive-into-merkle-proofs-and-eth-getproof-ethereum-rpc-method.mdx; do
echo "===== $f ====="
nl -ba "$f" | sed -n '1,220p' | rg -n "eth_getProof|Erigon|Bor|128|100,000|100000|historical|latest|July 29, 2026"
doneRepository: chainstack/dev-portal
Length of output: 232
Align the eth_getProof history limit wording. docs/polygon-methods.mdx says Erigon served the full history, but docs/deep-dive-into-merkle-proofs-and-eth-getproof-ethereum-rpc-method.mdx says Erigon only supports the most recent 100,000 blocks. Use one limit consistently across both docs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/polygon-methods.mdx` at line 25, Update the eth_getProof history-limit
statement in the Polygon documentation to match the established Erigon limit of
the most recent 100,000 blocks, replacing the claim that Erigon served the full
history while preserving the Bor limit and retrieval-date guidance.
Reframe the Polygon Erigon docs to represent the post-cutover state as current fact, per Ake: Polygon runs on Bor (archive Bor+PBSS); Parity trace_* and erigon_* are not available (marked unavailable, map to debug_trace*/eth_*); eth_getProof serves ~latest 128 blocks. Dropped all dates and transition framing (deprecating/retiring/moving/before).
…archive) The ~128-block eth_getProof limit is a PBSS default but is version/config- dependent (Geth v1.17+ history.trienode restores historical proofs). Not confirmed for Chainstack's production Bor archive, so remove the caveat until Infra confirms the actual Bor config. trace_*/erigon_* changes stand.
Represents the Polygon-on-Bor end-state as current fact (no transition dates):
trace_*anderigon_*namespaces are not available (marked unavailable in the method table; map todebug_trace*/eth_*, with a migration table).Files:
docs/polygon-methods.mdx(Info note + migration table + method-table rows flipped to unavailable);reference/polygon-trace_transaction.mdxandreference/polygon-trace_block.mdx(present-state "not available on Polygon — use debug_*" notes).mint validate+mint broken-linkspass.Context (not in the doc): Chainstack retires Erigon Jul 29 (Infra decision / INFRA-9692), ahead of Polygon's upstream Erigon sunset Aug 1.
Dropped: an earlier
eth_getProof"~128 blocks on Bor" caveat — that's a PBSS default but is version/config-dependent (Geth v1.17+history.trienoderestores historical proofs), and unconfirmed for our production Bor archive. Pending Infra confirmation of the Bor config; re-add only if confirmed.