docs: Polygon trace migration — flatCallTracer, eth_getProof note, decom dead trace_* pages, + reference coverage (getProof, bor_*)#542
Conversation
…etProof ~128-block note Match the customer migration comms for the Jul 29 Erigon->Bor cutover: - trace_* -> debug_* now maps to flatCallTracer (Parity flat format, drop-in for trace_* output) instead of callTracer (Geth nested format). Grounded in go-ethereum's native flatCallTracer (eth/tracers/native/call_flat.go) and Infra's Bor archive eval. - Restore the eth_getProof ~128-block note (Bor serves proofs only for roughly the latest 128 blocks; no historical proofs) — now sourced by the customer migration email. Applies to docs/polygon-methods.mdx and the two trace_* reference pages.
|
📝 WalkthroughWalkthroughAdds Polygon Bor and ChangesPolygon API additions
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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. |
…erence pages trace_* is not available on Bor, so a full reference page (with a Try it button and runnable code examples calling a dead method) is misleading. Remove them instead of band-aiding with a warning: - delete reference/polygon-trace_transaction.mdx + reference/polygon-trace_block.mdx - strip both from the reference nav in docs.json - drop their two <Card>s from polygon-debug-trace-rpc-methods.mdx - redirect /reference/polygon-trace_transaction -> polygon-tracetransaction and /reference/polygon-trace_block -> polygon-traceblockbynumber (the working debug_ equivalents) - add a flatCallTracer entry to the pre-built native tracers list
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…e flatCallTracer Close the migration-method reference-coverage gaps: - new reference/polygon-getproof.mdx (eth_getProof) with the Bor ~128-block archive caveat; Polygon was the only major chain missing a getproof page - new reference pages for the 5 bor_* methods (getAuthor, getCurrentProposer, getCurrentValidators, getRootHash, getSignersAtHash), documented in the availability table but previously without pages - all six with openapi specs (Try it) + examples verified live against a Chainstack Polygon Bor node (client bor/v2.9.0, chainId 137) - add flatCallTracer to the tracer list on the four debug_trace* pages so the tracer we now recommend for trace_* migration is documented where customers land - nav: bor_* under Chain data, eth_getProof under Accounts info
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
docs/polygon-methods.mdx (1)
21-21: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winWrap this limitation in a
<Warning>callout.As per coding guidelines, use MDX callouts to highlight important information. Since this is a significant operational limitation on Bor nodes, consider wrapping it in a
<Warning>callout to ensure it stands out to users.💡 Proposed refactor
-On Bor, `eth_getProof` returns state proofs only for roughly the latest 128 blocks; historical proof queries are not available. +<Warning> +On Bor, `eth_getProof` returns state proofs only for roughly the latest 128 blocks; historical proof queries are not available. +</Warning>🤖 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 21, Wrap the Bor `eth_getProof` historical-query limitation in the documentation’s existing MDX `<Warning>` callout syntax, preserving the current wording and ensuring the entire limitation is included inside the callout.Source: Coding guidelines
🤖 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 `@reference/polygon-borgetauthor.mdx`:
- Around line 20-30: Update the documented API sections in
reference/polygon-borgetauthor.mdx lines 20-30,
reference/polygon-borgetcurrentproposer.mdx lines 20-30,
reference/polygon-borgetcurrentvalidators.mdx lines 20-34,
reference/polygon-borgetroothash.mdx lines 20-31, and
reference/polygon-borgetsignersathash.mdx lines 20-30 to use the required MDX
components: replace parameter lists with ParamField, response lists with
ResponseField, and nested current-validator result properties with Expandable.
Replace raw request and response code blocks with RequestExample and
ResponseExample, and add authentication and error examples to each API
reference.
In `@reference/polygon-getproof.mdx`:
- Around line 28-44: Update the Parameters and Response sections in the
polygon-getproof documentation to use Mintlify ParamField and ResponseField
components, wrapping nested response properties with Expandable. Add
representative success, error, and authentication examples, while preserving the
existing parameter meanings and response field descriptions.
In `@reference/polygon-traceblockbyhash.mdx`:
- Around line 72-73: Update the inline tracer-option comments to include
flatCallTracer alongside the existing tracer names. Apply this consistently at
reference/polygon-traceblockbyhash.mdx lines 72-73, 88-89, and 111-112;
reference/polygon-traceblockbynumber.mdx lines 82-83 and 98-99; and
reference/polygon-tracetransaction.mdx lines 113-114 and 129-130, without
changing the example code.
- Around line 24-61: Replace the manual parameter and response markdown in
reference/polygon-traceblockbyhash.mdx lines 24-61 with Mintlify ParamField and
ResponseField components, using Expandable for nested properties and adding
authentication examples. Apply the same migration to
reference/polygon-traceblockbynumber.mdx lines 24-71 and
reference/polygon-tracetransaction.mdx lines 24-102; migrate the parameter
documentation and add authentication examples in reference/polygon-tracecall.mdx
lines 24-50, preserving each endpoint’s documented fields and response
structure.
In `@reference/polygon-traceblockbynumber.mdx`:
- Around line 66-70: Restore the Markdown nesting for the prestateTracer
response properties by indenting balance, code, nonce, and storage beneath smart
contract address. Preserve their existing descriptions and list formatting.
---
Nitpick comments:
In `@docs/polygon-methods.mdx`:
- Line 21: Wrap the Bor `eth_getProof` historical-query limitation in the
documentation’s existing MDX `<Warning>` callout syntax, preserving the current
wording and ensuring the entire limitation is included inside the callout.
🪄 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: e7078e5e-a2e3-45e2-82df-704b6672e0d1
📒 Files selected for processing (21)
docs.jsondocs/polygon-methods.mdxopenapi/polygon_node_api/account_info/eth_getProof.jsonopenapi/polygon_node_api/bor/bor_getAuthor.jsonopenapi/polygon_node_api/bor/bor_getCurrentProposer.jsonopenapi/polygon_node_api/bor/bor_getCurrentValidators.jsonopenapi/polygon_node_api/bor/bor_getRootHash.jsonopenapi/polygon_node_api/bor/bor_getSignersAtHash.jsonreference/polygon-borgetauthor.mdxreference/polygon-borgetcurrentproposer.mdxreference/polygon-borgetcurrentvalidators.mdxreference/polygon-borgetroothash.mdxreference/polygon-borgetsignersathash.mdxreference/polygon-debug-trace-rpc-methods.mdxreference/polygon-getproof.mdxreference/polygon-trace_block.mdxreference/polygon-trace_transaction.mdxreference/polygon-traceblockbyhash.mdxreference/polygon-traceblockbynumber.mdxreference/polygon-tracecall.mdxreference/polygon-tracetransaction.mdx
💤 Files with no reviewable changes (2)
- reference/polygon-trace_block.mdx
- reference/polygon-trace_transaction.mdx
| ## Parameters | ||
|
|
||
| * `block` — the block number in hexadecimal (for example, `0x561294b`), or a block hash. | ||
|
|
||
| ## Response | ||
|
|
||
| * `result` — the address of the validator that authored the block. | ||
|
|
||
| ```json | ||
| { "jsonrpc": "2.0", "id": 1, "result": "0x0e94b9b3fabd95338b8b23c36caae1d640e1339f" } | ||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Update API reference formatting to match required MDX components and examples.
These API reference files use plain Markdown lists instead of the required documentation components and are missing mandatory code examples. As per coding guidelines for reference/**/*.mdx, you must document all parameters with <ParamField>, show response structures with <ResponseField>, use <Expandable> for nested properties, include authentication and error examples, and use <RequestExample> / <ResponseExample> for API docs.
reference/polygon-borgetauthor.mdx#L20-L30: Replace the parameter and response Markdown lists with<ParamField>and<ResponseField>, use<RequestExample>and<ResponseExample>for the code snippets, and add missing authentication and error examples.reference/polygon-borgetcurrentproposer.mdx#L20-L30: Replace the response Markdown list with<ResponseField>, use<RequestExample>and<ResponseExample>for the code snippets, and add missing authentication and error examples.reference/polygon-borgetcurrentvalidators.mdx#L20-L34: Replace the response Markdown list with<ResponseField>utilizing<Expandable>for the nestedresultproperties, use<RequestExample>and<ResponseExample>for the code snippets, and add missing authentication and error examples.reference/polygon-borgetroothash.mdx#L20-L31: Replace the parameter and response Markdown lists with<ParamField>and<ResponseField>, use<RequestExample>and<ResponseExample>for the code snippets, and add missing authentication and error examples.reference/polygon-borgetsignersathash.mdx#L20-L30: Replace the parameter and response Markdown lists with<ParamField>and<ResponseField>, use<RequestExample>and<ResponseExample>for the code snippets, and add missing authentication and error examples.
📍 Affects 5 files
reference/polygon-borgetauthor.mdx#L20-L30(this comment)reference/polygon-borgetcurrentproposer.mdx#L20-L30reference/polygon-borgetcurrentvalidators.mdx#L20-L34reference/polygon-borgetroothash.mdx#L20-L31reference/polygon-borgetsignersathash.mdx#L20-L30
🤖 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 `@reference/polygon-borgetauthor.mdx` around lines 20 - 30, Update the
documented API sections in reference/polygon-borgetauthor.mdx lines 20-30,
reference/polygon-borgetcurrentproposer.mdx lines 20-30,
reference/polygon-borgetcurrentvalidators.mdx lines 20-34,
reference/polygon-borgetroothash.mdx lines 20-31, and
reference/polygon-borgetsignersathash.mdx lines 20-30 to use the required MDX
components: replace parameter lists with ParamField, response lists with
ResponseField, and nested current-validator result properties with Expandable.
Replace raw request and response code blocks with RequestExample and
ResponseExample, and add authentication and error examples to each API
reference.
Source: Coding guidelines
| ## Parameters | ||
|
|
||
| * `address` — the address of the account to prove. | ||
| * `storageKeys` — an array of 32-byte storage slot keys to prove. Pass an empty array to prove the account only. | ||
| * `block` — the block number in hexadecimal, or one of `earliest`, `latest`, or `pending`. Defaults to `latest`. | ||
|
|
||
| ## Response | ||
|
|
||
| * `result` — an object with the account proof and state values: | ||
| + `address` — the account address. | ||
| + `accountProof` — an array of RLP-encoded Merkle-trie nodes proving the account against the block state root. | ||
| + `balance` — the account balance, in hexadecimal wei. | ||
| + `codeHash` — the hash of the account's contract code; for a non-contract (EOA) account this is the Keccak-256 hash of empty code. | ||
| + `nonce` — the account nonce, in hexadecimal. | ||
| + `storageHash` — the root hash of the account storage trie. | ||
| + `storageProof` — an array of objects, one per requested `storageKeys` entry, each with the `key`, its `value`, and the `proof` (RLP-encoded trie nodes). | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Use Mintlify components and include examples.
As per coding guidelines for API reference documentation, all parameters must be documented with <ParamField>, the response structure must use <ResponseField> alongside <Expandable> for nested properties, and the page must include success, error, and authentication examples. Please replace the markdown lists with these components and provide the missing examples.
🛠️ Proposed fix to use components
-## Parameters
-
-* `address` — the address of the account to prove.
-* `storageKeys` — an array of 32-byte storage slot keys to prove. Pass an empty array to prove the account only.
-* `block` — the block number in hexadecimal, or one of `earliest`, `latest`, or `pending`. Defaults to `latest`.
-
-## Response
-
-* `result` — an object with the account proof and state values:
- + `address` — the account address.
- + `accountProof` — an array of RLP-encoded Merkle-trie nodes proving the account against the block state root.
- + `balance` — the account balance, in hexadecimal wei.
- + `codeHash` — the hash of the account's contract code; for a non-contract (EOA) account this is the Keccak-256 hash of empty code.
- + `nonce` — the account nonce, in hexadecimal.
- + `storageHash` — the root hash of the account storage trie.
- + `storageProof` — an array of objects, one per requested `storageKeys` entry, each with the `key`, its `value`, and the `proof` (RLP-encoded trie nodes).
+## Parameters
+
+<ParamField body="address" type="string" required>
+ The address of the account to prove.
+</ParamField>
+<ParamField body="storageKeys" type="array" required>
+ An array of 32-byte storage slot keys to prove. Pass an empty array to prove the account only.
+</ParamField>
+<ParamField body="block" type="string">
+ The block number in hexadecimal, or one of `earliest`, `latest`, or `pending`. Defaults to `latest`.
+</ParamField>
+
+## Response
+
+<ResponseField name="result" type="object">
+ An object with the account proof and state values.
+ <Expandable title="properties">
+ <ResponseField name="address" type="string">
+ The account address.
+ </ResponseField>
+ <ResponseField name="accountProof" type="array">
+ An array of RLP-encoded Merkle-trie nodes proving the account against the block state root.
+ </ResponseField>
+ <ResponseField name="balance" type="string">
+ The account balance, in hexadecimal wei.
+ </ResponseField>
+ <ResponseField name="codeHash" type="string">
+ The hash of the account's contract code; for a non-contract (EOA) account this is the Keccak-256 hash of empty code.
+ </ResponseField>
+ <ResponseField name="nonce" type="string">
+ The account nonce, in hexadecimal.
+ </ResponseField>
+ <ResponseField name="storageHash" type="string">
+ The root hash of the account storage trie.
+ </ResponseField>
+ <ResponseField name="storageProof" type="array">
+ An array of objects, one per requested `storageKeys` entry, each with the `key`, its `value`, and the `proof` (RLP-encoded trie nodes).
+ </ResponseField>
+ </Expandable>
+</ResponseField>
+
+<RequestExample>
+ <!-- Add authentication and success request examples here -->
+</RequestExample>
+
+<ResponseExample>
+ <!-- Add success and error response examples here -->
+</ResponseExample>🤖 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 `@reference/polygon-getproof.mdx` around lines 28 - 44, Update the Parameters
and Response sections in the polygon-getproof documentation to use Mintlify
ParamField and ResponseField components, wrapping nested response properties
with Expandable. Add representative success, error, and authentication examples,
while preserving the existing parameter meanings and response field
descriptions.
Source: Coding guidelines
| ## Parameters | ||
|
|
||
| * `hash` — the hash of the block to be traced. | ||
| * `tracer` — an object identifying the type of tracer and its configuration: | ||
| + `4byteTracer` — tracer that captures the function signatures and call data sizes for all functions executed during a transaction, creating a map that links each selector and size combination to the number of times it occurred. This provides valuable information about the frequency and usage of each function within the transaction. | ||
| + `callTracer` — tracer that captures information on all call frames executed during a transaction. The resulting nested list of call frames is organized into a tree structure that reflects the way the Ethereum Virtual Machine works and can be used for debugging and analysis purposes. | ||
| + `flatCallTracer` — tracer that returns the call trace as a flat list in the Parity/OpenEthereum format, matching the legacy `trace_*` output. Use it as the drop-in replacement when migrating `trace_transaction`, `trace_block`, or `trace_call` to their `debug_*` equivalents. | ||
| + `prestateTracer` — tracer with two modes: `prestate` and `diff`, where the former returns the accounts needed to execute a transaction, and the latter returns the differences between the pre and post-states of the transaction. The tracer operates by re-executing the transaction and tracking every state change made, resulting in an object with the account addresses as keys and the corresponding trie leaves as values. | ||
|
|
||
| ## Response types | ||
|
|
||
| ### `4byteTracer` response | ||
|
|
||
| * `object` — the `4byteTracer` traces object: | ||
| + `result` — a map of the function signature, the call data size, and how many times the function was called. | ||
|
|
||
| ### `callTracer` response | ||
|
|
||
| * `object` — the `callTracer` traces object: | ||
| + `from` — the address of the sender who initiated the transaction. | ||
| + `gas` — the units of gas included in the transaction by the sender. | ||
| + `gasused` — the total used gas by the call. Encoded as hexadecimal. | ||
| + `to` — the address of the recipient of the transaction if it was a transaction to an address. For contract creation transactions, this field is `null`. | ||
| + `input` — the optional input data sent with the transaction, usually used to interact with smart contracts. | ||
| + `output` — the return value of the call, encoded as a hexadecimal string. | ||
| + `error` — an error message in case the execution failed. | ||
| + `revertReason` — the reason why the transaction was reverted, returned by the smart contract if any. | ||
| + `calls` — a list of sub-calls made by the contract during the call, each represented as a nested call frame object. | ||
|
|
||
| ### `prestateTracer` response | ||
|
|
||
| * `object` — the `prestateTracer` traces object: | ||
| + `smart contract address` — the address of the smart contract associated with the result. | ||
| - `balance` — the balance of the contract, expressed in wei and encoded as a hexadecimal string. | ||
| - `code` — the bytecode of the contract, encoded as a hexadecimal string. | ||
| - `nonce` — the nonce of the account associated with the contract, represented as an unsigned integer. | ||
| - `storage` — a map of key-value pairs representing the storage slots of the contract. The keys and values are both encoded as hexadecimal strings. | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | 🏗️ Heavy lift
Migrate API parameters and responses to Mintlify components.
The current implementation uses manual markdown lists for parameters and responses. As per coding guidelines for reference/**/*.mdx, API reference documentation must document all parameters with <ParamField>, show response structure with <ResponseField>, use <Expandable> for nested properties, and always include authentication examples.
reference/polygon-traceblockbyhash.mdx#L24-L61: Migrate the manual markdown list parameters and response types to<ParamField>and<ResponseField>components, and include authentication examples.reference/polygon-traceblockbynumber.mdx#L24-L71: Migrate the parameters and response types to<ParamField>and<ResponseField>components, and include authentication examples.reference/polygon-tracetransaction.mdx#L24-L102: Migrate the parameters and response types to<ParamField>and<ResponseField>components, and include authentication examples.reference/polygon-tracecall.mdx#L24-L50: Migrate the manual markdown list parameters to<ParamField>components and include authentication examples.
📍 Affects 4 files
reference/polygon-traceblockbyhash.mdx#L24-L61(this comment)reference/polygon-traceblockbynumber.mdx#L24-L71reference/polygon-tracetransaction.mdx#L24-L102reference/polygon-tracecall.mdx#L24-L50
🤖 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 `@reference/polygon-traceblockbyhash.mdx` around lines 24 - 61, Replace the
manual parameter and response markdown in reference/polygon-traceblockbyhash.mdx
lines 24-61 with Mintlify ParamField and ResponseField components, using
Expandable for nested properties and adding authentication examples. Apply the
same migration to reference/polygon-traceblockbynumber.mdx lines 24-71 and
reference/polygon-tracetransaction.mdx lines 24-102; migrate the parameter
documentation and add authentication examples in reference/polygon-tracecall.mdx
lines 24-50, preserving each endpoint’s documented fields and response
structure.
Source: Coding guidelines
| // Specify the type of tracer: 4byteTracer, callTracer, or prestateTracer | ||
| const tracer = { tracer: '4byteTracer' }; |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Update the tracer comments to include flatCallTracer.
The code examples feature inline comments listing the available tracers, but they were not updated to reflect the addition of flatCallTracer.
reference/polygon-traceblockbyhash.mdx#L72-L73: AddflatCallTracerto the available options in the JS comment.reference/polygon-traceblockbyhash.mdx#L88-L89: AddflatCallTracerto the Python comment.reference/polygon-traceblockbyhash.mdx#L111-L112: AddflatCallTracerto the JS use case comment.reference/polygon-traceblockbynumber.mdx#L82-L83: AddflatCallTracerto the JS comment.reference/polygon-traceblockbynumber.mdx#L98-L99: AddflatCallTracerto the Python comment.reference/polygon-tracetransaction.mdx#L113-L114: AddflatCallTracerto the JS comment.reference/polygon-tracetransaction.mdx#L129-L130: AddflatCallTracerto the Python comment.
📍 Affects 3 files
reference/polygon-traceblockbyhash.mdx#L72-L73(this comment)reference/polygon-traceblockbyhash.mdx#L88-L89reference/polygon-traceblockbyhash.mdx#L111-L112reference/polygon-traceblockbynumber.mdx#L82-L83reference/polygon-traceblockbynumber.mdx#L98-L99reference/polygon-tracetransaction.mdx#L113-L114reference/polygon-tracetransaction.mdx#L129-L130
🤖 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 `@reference/polygon-traceblockbyhash.mdx` around lines 72 - 73, Update the
inline tracer-option comments to include flatCallTracer alongside the existing
tracer names. Apply this consistently at reference/polygon-traceblockbyhash.mdx
lines 72-73, 88-89, and 111-112; reference/polygon-traceblockbynumber.mdx lines
82-83 and 98-99; and reference/polygon-tracetransaction.mdx lines 113-114 and
129-130, without changing the example code.
| * `smart contract address` — the address of the smart contract associated with the result. | ||
| * `balance` — the balance of the contract, expressed in Wei and encoded as a hexadecimal string. | ||
| * `code` — the bytecode of the contract, encoded as a hexadecimal string. | ||
| * `nonce` — the nonce of the account associated with the contract, represented as an unsigned integer. | ||
| * `storage` — a map of key-value pairs representing the storage slots of the contract. The keys and values are both encoded as hexadecimal strings. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix Markdown list nesting.
During reformatting, the indentation for the prestateTracer response properties was lost. These fields should be nested under smart contract address to correctly represent the returned structure.
🐛 Proposed fix
- * `smart contract address` — the address of the smart contract associated with the result.
- * `balance` — the balance of the contract, expressed in Wei and encoded as a hexadecimal string.
- * `code` — the bytecode of the contract, encoded as a hexadecimal string.
- * `nonce` — the nonce of the account associated with the contract, represented as an unsigned integer.
- * `storage` — a map of key-value pairs representing the storage slots of the contract. The keys and values are both encoded as hexadecimal strings.
+ + `smart contract address` — the address of the smart contract associated with the result.
+ - `balance` — the balance of the contract, expressed in Wei and encoded as a hexadecimal string.
+ - `code` — the bytecode of the contract, encoded as a hexadecimal string.
+ - `nonce` — the nonce of the account associated with the contract, represented as an unsigned integer.
+ - `storage` — a map of key-value pairs representing the storage slots of the contract. The keys and values are both encoded as hexadecimal strings.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| * `smart contract address` — the address of the smart contract associated with the result. | |
| * `balance` — the balance of the contract, expressed in Wei and encoded as a hexadecimal string. | |
| * `code` — the bytecode of the contract, encoded as a hexadecimal string. | |
| * `nonce` — the nonce of the account associated with the contract, represented as an unsigned integer. | |
| * `storage` — a map of key-value pairs representing the storage slots of the contract. The keys and values are both encoded as hexadecimal strings. | |
| * `smart contract address` — the address of the smart contract associated with the result. | |
| * `balance` — the balance of the contract, expressed in Wei and encoded as a hexadecimal string. | |
| * `code` — the bytecode of the contract, encoded as a hexadecimal string. | |
| * `nonce` — the nonce of the account associated with the contract, represented as an unsigned integer. | |
| * `storage` — a map of key-value pairs representing the storage slots of the contract. The keys and values are both encoded as hexadecimal strings. |
🤖 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 `@reference/polygon-traceblockbynumber.mdx` around lines 66 - 70, Restore the
Markdown nesting for the prestateTracer response properties by indenting
balance, code, nonce, and storage beneath smart contract address. Preserve their
existing descriptions and list formatting.
|
|
Follow-up to #515, aligning our Polygon docs with the customer migration email for the Jul 29, 2026 Erigon→Bor cutover, and closing the reference-page gaps that migration surfaced.
1. Migration guidance →
flatCallTracertrace_*→debug_*now maps toflatCallTracer(Parity flat format — drop-in fortrace_*output), notcallTracer(Geth nested format, needs reparsing). Matches the customer comms. Grounded in go-ethereum's native tracer (eth/tracers/native/call_flat.go) + Infra's Bor eval. Updated the migration table onpolygon-methods.mdx.2.
eth_getProof~128-block note restoredBor serves state proofs only for ~the latest 128 blocks; no historical proofs. Dropped from #515 pending confirmation — the customer email states it explicitly, so docs + comms now agree.
3. Decommissioned the dead
trace_*reference pagestrace_transaction/trace_blockaren't available on Bor, so a full page with a Try-it and runnable examples calling a dead method is misleading. Deleted both, stripped nav, removed their<Card>s, and 301'd to thedebug_equivalents (also preserves inbound search traffic).4. Reference-coverage gaps (the migration-relevant methods now all have pages)
eth_getProofhad no Polygon reference page (Base/BNB/Optimism/Cronos/Fantom all do) — addedreference/polygon-getproof.mdxwith the Bor caveat baked in.bor_*(5 methods:getAuthor,getCurrentProposer,getCurrentValidators,getRootHash,getSignersAtHash) were in the availability table but had no pages — added all five.bor/v2.9.0, chainId 137).flatCallTracerto the tracer list on the fourdebug_trace*pages, so the tracer we now recommend for migration is documented where customers land after clicking through.Parts 1–3 assert the post-cutover end-state as current, so merge at/after the Jul 29 cutover (part 4 is additive and safe anytime, but it ships together here).
Gates:
mint broken-links✅ ·mint validate✅