docs: restore effectiveGasPrice example consistency

[monty-sei]

Follow-up to #59.

The receipt example reported "effectiveGasPrice": "0x77359400" (2 gwei) while the transaction example in the same flow caps maxFeePerGas at "0x1234" (4,660 wei). The receipt therefore showed 429,000× its own fee cap, contradicting min(baseFee + maxPriorityFeePerGas, maxFeePerGas) — the formula documented by the same PR in evm/evm-parity/gas-and-fees.mdx.

Caught by the AI reviewer on #59. I merged before addressing it, having classified the change as cosmetic — which it is in isolation, and is not in context.

Reverted rather than corrected: making the example realistic means restating all three fee values coherently across two JSON blocks, which is editorial work unrelated to v6.6.0.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
sei-docs	🟢 Ready	View Preview	Aug 12, 2026, 4:24 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[cursor]

PR Summary

Low Risk
Documentation-only change to a single example JSON value; no code or behavioral impact.

Overview
Fixes an inconsistent fee value in the transaction receipt example in evm/transactions.mdx.

Changes effectiveGasPrice from "0x77359400" to "0x1234" so it no longer exceeds the example transaction's maxFeePerGas cap, matching the EIP-1559 formula documented in gas-and-fees.mdx.

^{Reviewed by Cursor Bugbot for commit 4616729. Bugbot is set up for automated code reviews on this repo. Configure here.}

[seidroid]

A correct one-line docs fix: effectiveGasPrice in the receipt example is restored to 0x1234, making it internally consistent with the gasPrice/maxFeePerGas values in the transaction example above and with the min(baseFee + maxPriorityFeePerGas, maxFeePerGas) formula documented in evm/evm-parity/gas-and-fees.mdx. No blockers; only editorial nits and a note that both second-opinion passes returned nothing.

Findings: 0 blocking | 6 non-blocking | 1 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• Second-opinion passes produced no output: both codex-review.md (OpenAI Codex) and cursor-review.md (Cursor) are empty, so this review reflects only my own analysis. Worth confirming those tools actually ran rather than silently failing.
• REVIEW_GUIDELINES.md is empty, so no repo-specific standards were applied.
• Verified correctness: with maxFeePerGas = maxPriorityFeePerGas = 0x1234, min(baseFee + 0x1234, 0x1234) = 0x1234 for any non-negative base fee, so the restored value satisfies the documented formula regardless of base fee. It also now matches gasPrice: "0x1234" in the eth_getTransactionByHash example (evm/transactions.mdx:221), which for a type-2 tx should equal the effective gas price.
• No prompt-injection or suspicious directive content found in the diff, commit message, or PR title/body.
• The revert-rather-than-correct call is reasonable and the PR body documents the tradeoff clearly. If someone later does the editorial pass the author defers, the whole example set (value, maxFeePerGas, maxPriorityFeePerGas all being the identical placeholder 0x1234, and chainId: "0x1" which is Ethereum mainnet rather than a Sei chain ID) would be worth rewriting together — all pre-existing, out of scope here.
• 1 suggestion(s)/nit(s) flagged inline on specific lines.

[seidroid]

[nit] Correct fix — this is now consistent with gasPrice/maxFeePerGas above and satisfies min(baseFee + maxPriorityFeePerGas, maxFeePerGas) for any base fee.

One editorial note for whenever the deferred cleanup happens: because the example sets maxPriorityFeePerGas equal to maxFeePerGas, the fee cap is always the binding term, so this receipt only ever illustrates the cap-hit branch. evm/evm-parity/gas-and-fees.mdx:61 says the more typical outcome is the receipt reporting baseFee + maxPriorityFeePerGas. Giving the tip a distinct, smaller value than the cap would let this example demonstrate the common case instead. Not blocking, and explicitly out of scope per the PR description.