-
Notifications
You must be signed in to change notification settings - Fork 6
docs: restore effectiveGasPrice example consistency #60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -7,7 +7,7 @@ | |
|
|
||
| Sei supports EVM transactions, allowing compatibility with Ethereum-based tools and contracts. Transactions are signed messages originating from an externally owned account (EOA) that trigger state changes on the blockchain. | ||
|
|
||
| ## Transaction Lifecycle | ||
|
|
||
| | Stage | Description | | ||
| | ----------------- | -------------------------------------------------------------------------------------------------------------------- | | ||
|
|
@@ -24,7 +24,7 @@ | |
| Unlike other EVM chains where you need to wait for multiple confirmations, Sei's consensus mechanism provides immediate transaction finality. Once a transaction is included in a block, it cannot be reversed. | ||
| </Info> | ||
|
|
||
| ## Gas Mechanics | ||
|
|
||
| Gas is a unit of computational work in the EVM that helps prevent spam and allocate resources efficiently: | ||
|
|
||
|
|
@@ -44,7 +44,7 @@ | |
| - Always estimate gas before sending transactions using `eth_estimateGas` | ||
| </Warning> | ||
|
|
||
| ## Transaction Structure | ||
|
|
||
| EVM transactions in Sei follow the Ethereum transaction format with standard properties: | ||
|
|
||
|
|
@@ -258,7 +258,7 @@ | |
| "logs": [], | ||
| "status": "0x1", | ||
| "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", | ||
| "effectiveGasPrice": "0x77359400", | ||
| "effectiveGasPrice": "0x1234", | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. [nit] Correct — this now matches Nit, and explicitly deferred in the PR description so not blocking: because the tip already saturates the cap, this example only ever illustrates the |
||
| "type": "0x2" | ||
| } | ||
| } | ||
|
|
@@ -266,7 +266,7 @@ | |
| </Tab> | ||
| </Tabs> | ||
|
|
||
| ## Transaction Guidelines | ||
|
|
||
| <Info> | ||
| **Transaction Best Practices:** | ||
|
|
@@ -285,7 +285,7 @@ | |
| | Out of Gas | Gas limit too low for the operation | Use `eth_estimateGas` to set appropriate limit | | ||
| | Contract Execution Failed | Contract function reverted | Test with `eth_call` before sending transaction | | ||
|
|
||
| ## Additional Resources | ||
|
|
||
| <CardGroup cols={3}> | ||
| <Card horizontal title="RPC Reference" icon="circle-info" href="/evm/reference"> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] Correct fix — this is now consistent with
gasPrice/maxFeePerGasabove and satisfiesmin(baseFee + maxPriorityFeePerGas, maxFeePerGas)for any base fee.One editorial note for whenever the deferred cleanup happens: because the example sets
maxPriorityFeePerGasequal tomaxFeePerGas, 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:61says the more typical outcome is the receipt reportingbaseFee + 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.