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 field; no runtime or API behavior.

Overview
Restores internal consistency in the EIP-1559 transaction flow on evm/transactions.mdx by changing the receipt example’s effectiveGasPrice from 0x77359400 back to 0x1234.

That matches the same page’s maxFeePerGas / maxPriorityFeePerGas placeholders in the type-2 transaction and eth_getTransactionByHash examples, so the receipt no longer implies an effective price far above the documented fee cap.

^{Reviewed by Cursor Bugbot for commit 6c827b6. 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.

[seidroid]

One-line documentation fix reverting effectiveGasPrice to 0x1234, which restores internal consistency with the maxFeePerGas/maxPriorityFeePerGas/gasPrice values in the same example flow and satisfies the min(baseFee + maxPriorityFeePerGas, maxFeePerGas) formula documented elsewhere in the repo. Correct and safe to merge; the only notes are that the supplied review-guideline and second-opinion files were empty.

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

Blockers

• None at the file/PR level.

Non-blocking

• REVIEW_GUIDELINES.md is empty, so no repo-specific review standards could be applied to this pass.
• Both second-opinion files (codex-review.md, cursor-review.md) are empty — the Codex and Cursor passes produced no output, so this review reflects only my own analysis.
• Correctness check: with maxPriorityFeePerGas equal to maxFeePerGas (0x1234), min(baseFee + tip, maxFeePerGas) resolves to 0x1234 for any base fee, so the new value is consistent with evm/evm-parity/gas-and-fees.mdx:59 regardless of assumed network conditions. The prior 0x77359400 exceeded the transaction's own fee cap by ~429,000×.
• 1 suggestion(s)/nit(s) flagged inline on specific lines.

[seidroid]

[nit] Correct — this now matches maxFeePerGas/gasPrice (0x1234) in the sibling eth_getTransactionByHash block, and since maxPriorityFeePerGas also equals 0x1234, min(baseFee + tip, maxFeePerGas) resolves to exactly 0x1234 for any base fee.

Nit, and explicitly deferred in the PR description so not blocking: because the tip already saturates the cap, this example only ever illustrates the maxFeePerGas-clamped branch, never the baseFee + maxPriorityFeePerGas branch that evm/evm-parity/gas-and-fees.mdx:61 calls out as the common case. If someone later refreshes these fixtures editorially, giving maxPriorityFeePerGas a value below maxFeePerGas would make the flow demonstrate both branches (and use more realistic magnitudes than 4,660 wei).