Release/v1 58 for chain v1 16 #325
Conversation
…at/add_exchange_v2_support
…core_and_indexer Fix/synced dev with v1 14 core and indexer
… new CI step to run golangci-lint using the github action
…_commit_repo Feat/remove deprecated pre commit repo
…at/add_exchange_v2_support
… feat/chain_upgrade_v1_15
… example for the new GetEipBaseFee request in txfees module
…of using the default value
* (fix) Applied the fixes for EIP712 JSON unmarshalling to the master branch * fix: update pre-commit/action from v2.0.2 to v3.0.1 to ry to solve the pre-commit validation workflow error * fix: Added configuration in .golangci.yml file to exclude some dirs * fix: updated the oracle stream prices script to send the oracle type always in lowercase * fix: updated the oracle stream prices script to send the oracle type always in lowercase * fix: Added quantization in the functions that convert notional values to chain format * fix/fix_manual_tx_generation (#296) * fix: fixed the manual TX generation and signing to receive the gas price * fix: solve issues in pre-commit workflow caused by using deprecated components * fix: solve issues in pre-commit workflow caused by using deprecated components
…always in lowercase
…always in lowercase
Feat/add chain messages list
Previously, ExecuteCall reset the gRPC metadata before sending the request, which prevented callers from specifying custom headers such as `x-cosmos-block-height` for height-specific queries. This commit updates ExecuteCall to preserve caller-defined headers, allowing for more flexible and accurate state queries.
…ed-headers-in-execute-call feat: preserve caller-defined headers in ExecuteCall
…2 markets to allow users to load either human readable or chain format markets
…v1.16.16. Updated queries with requests or response changes
…r_exchange_v2 [CP-447] refactor support for exchange v2
… with requests or response changes
[chore] update indexer v1.16.20
[chore] update example scripts
…he Injective codec to encode and decode messages
…_decoding [CP-502] fix chain responses decoding
…entV2 to allow cancelation and timeouts. Added new broadcast functions in ChainClient (v1) to include the context as a parameter, but without changing the existing functions (keeping backwards compatibility)
…unctions [CP-517] improve broadcast functions
…n (chain v1.16.0 and indexer v1.16.54). Updated ofac list.
…t_for_release [CHORE] final v1.16 alignment for release
WalkthroughThis update introduces a comprehensive set of new features and improvements targeting EVM (Ethereum Virtual Machine) integration, configuration, and compatibility within a Cosmos SDK-based blockchain. It adds new Go packages and files for EVM transaction types, error handling, codec registration, event and key management, and Ethereum smart contract bindings. The Makefile, documentation, and linting configurations are also updated, while several files receive minor refactoring or documentation enhancements. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CosmosSDK
participant EVMModule
participant Ethereum
participant PrecompileContract
User->>CosmosSDK: Submit MsgEthereumTx (with raw Ethereum tx)
CosmosSDK->>EVMModule: Route message, validate, decode tx
EVMModule->>Ethereum: Convert to ethtypes.Transaction, execute
Ethereum->>PrecompileContract: Call contract method (e.g., ERC20, Exchange)
PrecompileContract-->>Ethereum: Return result/event/log
Ethereum-->>EVMModule: Return execution result, logs, errors (if any)
EVMModule-->>CosmosSDK: Emit events, handle errors, update state
CosmosSDK-->>User: Return transaction result, logs, error details
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Pull Request Overview
This PR introduces new EVM module types for Release v1.58.0 with full support for chain upgrade v1.16. The changes add comprehensive EVM-related types including transaction handling, parameter management, and Ethereum compatibility infrastructure.
Key changes:
- Adds comprehensive EVM transaction types (legacy, access list, and dynamic fee transactions)
- Introduces parameter management with authorization controls for contract deployment
- Implements Ethereum-compatible log handling and event structures
Reviewed Changes
Copilot reviewed 41 out of 529 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| chain/evm/types/params.pb.go | Auto-generated protobuf bindings for EVM parameters |
| chain/evm/types/params.go | EVM parameter handling with validation and authorization controls |
| chain/evm/types/msg.go | Ethereum transaction message types and validation logic |
| chain/evm/types/logs.go | Ethereum log handling and conversion utilities |
| chain/evm/types/log.pb.go | Auto-generated protobuf bindings for log structures |
| chain/evm/types/legacy_tx.go | Legacy Ethereum transaction type implementation |
| chain/evm/types/key.go | Module constants and key prefixes for storage |
| chain/evm/types/genesis.pb.go | Auto-generated protobuf bindings for genesis state |
| chain/evm/types/events.pb.go | Auto-generated protobuf bindings for event structures |
| chain/evm/types/events.go | Event type constants and attribute keys |
| chain/evm/types/eth.go | Ethereum transaction wrapper with validation |
| chain/evm/types/errors.go | Comprehensive error handling with VM error integration |
| chain/evm/types/dynamic_fee_tx.go | EIP-1559 dynamic fee transaction implementation |
| chain/evm/types/codec.go | Protobuf codec registration for all EVM types |
Comments suppressed due to low confidence (4)
chain/evm/types/params.go:106
- [nitpick] Function name uses British spelling 'Authorised'. Consider using American spelling 'IsAuthorizedDeployer' for consistency with the field name 'AuthorizedDeployers'.
func (p Params) IsAuthorisedDeployer(addr ethcommon.Address) bool {
chain/evm/types/params.go:161
- [nitpick] Variable name uses British spelling 'authorised'. Consider using American spelling 'authorizedAddresses' for consistency with the function parameter name and overall codebase.
authorisedAddresses := make(map[string]struct{})
chain/evm/types/params.go:170
- [nitpick] Variable reference uses British spelling 'authorised'. Should be 'authorizedAddresses' for consistency.
if _, found := authorisedAddresses[string(addr.Bytes())]; found {
chain/evm/types/params.go:174
- [nitpick] Variable reference uses British spelling 'authorised'. Should be 'authorizedAddresses' for consistency.
authorisedAddresses[string(addr.Bytes())] = struct{}{}
| addr := ethcommon.HexToAddress(addrStr) | ||
|
|
||
| if _, found := authorisedAddresses[string(addr.Bytes())]; found { | ||
| return fmt.Errorf("duplicate authorised address: %s", addrStr) |
There was a problem hiding this comment.
Error message uses British spelling 'authorised'. Should be 'authorized' for consistency with field names.
| return fmt.Errorf("duplicate authorised address: %s", addrStr) | |
| return fmt.Errorf("duplicate authorized address: %s", addrStr) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (1)
chain/evm/precompiles/exchange/i_exchange_module.abigen.go (1)
32-36: SameCosmosCoinduplication as noted in staking bindingSee previous comment on consolidating this struct across precompile packages.
🧹 Nitpick comments (4)
Makefile (1)
223-223: Consider adding missing phony targets for completeness.Static analysis tools suggest adding standard phony targets. While not critical, adding them would improve Makefile completeness.
Consider adding these standard phony targets:
-.PHONY: copy-exchange-client tests coverage lint lint-last-commit lint-master lint-all extract-message-names +.PHONY: all clean test copy-exchange-client tests coverage lint lint-last-commit lint-master lint-all extract-message-namesYou could implement them as:
all: copy-exchange-client copy-chain-types clean: rm -rf injective-indexer injective-core proto chain exchange injective_data test: testschain/evm/types/chain_config.go (1)
181-217: Consider consolidating duplicate validation logicThe validation functions work correctly, but
ValidateBlockandValidateTimehave identical logic. Consider creating a shared helper function to reduce code duplication.+func validateNonNegativeInt(value *sdkmath.Int, fieldType string) error { + if value == nil { + return nil + } + if value.IsNegative() { + return errorsmod.Wrapf( + ErrInvalidChainConfig, "%s value cannot be negative: %s", fieldType, value, + ) + } + return nil +} func ValidateBlock(block *sdkmath.Int) error { - // nil value means that the fork has not yet been applied - if block == nil { - return nil - } - - if block.IsNegative() { - return errorsmod.Wrapf( - ErrInvalidChainConfig, "block value cannot be negative: %s", block, - ) - } - - return nil + return validateNonNegativeInt(block, "block") } func ValidateTime(time *sdkmath.Int) error { - // nil value means that the fork has not yet been applied - if time == nil { - return nil - } - - if time.IsNegative() { - return errorsmod.Wrapf( - ErrInvalidChainConfig, "time value cannot be negative: %s", time, - ) - } - - return nil + return validateNonNegativeInt(time, "time") }chain/evm/precompiles/staking/i_staking_module.abigen.go (2)
32-36: ConsolidateCosmosCoininto a shared package
CosmosCoinis also generated inbankandexchangeprecompile bindings with an identical definition. Keeping duplicate structs in separate packages hampers interoperability—every caller must convert between N identical types when composing higher-level logic.Consider introducing a tiny
precompiles/types(or similar) package that declarestype CosmosCoin struct { Amount *big.Int; Denom string }and have the abigen templates alias that shared type (or usetype CosmosCoin = precompiles_types.CosmosCoin).
This keeps the generated code clean while eliminating redundant conversions.
38-41: Inline ABI string bloats the compiled binaryThe full JSON ABI is embedded as a raw string constant. For large contracts this noticeably increases the binary size and compile time.
If size matters for downstream consumers, consider:
- Compressing and
go:embed-ing the ABI into a separate file, or- Loading the ABI at runtime from an external asset (still using
embed).Generated code can reference
abi.JSON(bytes.NewReader(asset))instead of a mega-literal.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (39)
chain/auction/types/query.pb.gois excluded by!**/*.pb.gochain/auction/types/tx.pb.gois excluded by!**/*.pb.gochain/erc20/types/erc20.pb.gois excluded by!**/*.pb.gochain/erc20/types/events.pb.gois excluded by!**/*.pb.gochain/erc20/types/genesis.pb.gois excluded by!**/*.pb.gochain/erc20/types/params.pb.gois excluded by!**/*.pb.gochain/erc20/types/query.pb.gois excluded by!**/*.pb.gochain/erc20/types/tx.pb.gois excluded by!**/*.pb.gochain/evm/types/access_tuple.pb.gois excluded by!**/*.pb.gochain/evm/types/chain_config.pb.gois excluded by!**/*.pb.gochain/evm/types/events.pb.gois excluded by!**/*.pb.gochain/evm/types/genesis.pb.gois excluded by!**/*.pb.gochain/evm/types/log.pb.gois excluded by!**/*.pb.gochain/evm/types/params.pb.gois excluded by!**/*.pb.gochain/evm/types/query.pb.gois excluded by!**/*.pb.gochain/evm/types/state.pb.gois excluded by!**/*.pb.gochain/evm/types/trace_config.pb.gois excluded by!**/*.pb.gochain/evm/types/transaction_logs.pb.gois excluded by!**/*.pb.gochain/evm/types/tx.pb.gois excluded by!**/*.pb.gochain/evm/types/tx_result.pb.gois excluded by!**/*.pb.gochain/exchange/types/authz.pb.gois excluded by!**/*.pb.gochain/exchange/types/exchange.pb.gois excluded by!**/*.pb.gochain/exchange/types/genesis.pb.gois excluded by!**/*.pb.gochain/exchange/types/query.pb.gois excluded by!**/*.pb.gochain/exchange/types/tx.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/authz.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/events.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/exchange.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/genesis.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/market.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/order.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/orderbook.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/proposal.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/query.pb.gois excluded by!**/*.pb.gochain/exchange/types/v2/tx.pb.gois excluded by!**/*.pb.gochain/stream/types/query.pb.gois excluded by!**/*.pb.gochain/stream/types/v2/query.pb.gois excluded by!**/*.pb.gochain/txfees/types/txfees.pb.gois excluded by!**/*.pb.gochain/types/indexer.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (28)
.github/workflows/golangci-lint.yml(1 hunks).gitignore(1 hunks).golangci.yml(1 hunks)Makefile(4 hunks)README.md(1 hunks)auth_vote/authz_vote.go(4 hunks)chain/crypto/ethsecp256k1/ethsecp256k1.go(2 hunks)chain/crypto/hd/algorithm.go(3 hunks)chain/crypto/hd/hd_path.go(1 hunks)chain/erc20/types/codec.go(1 hunks)chain/evm/precompiles/bank/fixed_supply_bank_erc20.abigen.go(1 hunks)chain/evm/precompiles/bank/i_bank_module.abigen.go(1 hunks)chain/evm/precompiles/bank/mint_burn_bank_erc20.abigen.go(1 hunks)chain/evm/precompiles/exchange/i_exchange_module.abigen.go(1 hunks)chain/evm/precompiles/staking/i_staking_module.abigen.go(1 hunks)chain/evm/types/access_list.go(1 hunks)chain/evm/types/access_list_tx.go(1 hunks)chain/evm/types/chain_config.go(1 hunks)chain/evm/types/codec.go(1 hunks)chain/evm/types/dynamic_fee_tx.go(1 hunks)chain/evm/types/errors.go(1 hunks)chain/evm/types/eth.go(1 hunks)chain/evm/types/events.go(1 hunks)chain/evm/types/key.go(1 hunks)chain/evm/types/legacy_tx.go(1 hunks)chain/evm/types/logs.go(1 hunks)chain/evm/types/msg.go(1 hunks)chain/evm/types/params.go(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (12)
chain/crypto/ethsecp256k1/ethsecp256k1.go (1)
chain/crypto/ethsecp256k1/keys.pb.go (6)
PrivKey(75-77)PrivKey(81-81)PrivKey(82-84)PubKey(30-32)PubKey(35-35)PubKey(36-38)
chain/evm/types/events.go (1)
chain/evm/types/msg.go (1)
TypeMsgEthereumTx(40-40)
auth_vote/authz_vote.go (2)
client/common/network.go (1)
LoadNetwork(53-202)client/chain/chain_v2.go (1)
NewChainClientV2(361-505)
chain/evm/types/logs.go (2)
chain/types/validation.go (1)
IsEmptyHash(12-14)chain/evm/types/utils.go (1)
HexAddress(236-241)
chain/evm/types/codec.go (2)
chain/types/codec.go (1)
RegisterInterfaces(12-30)chain/evm/types/tx.pb.go (18)
MsgEthereumTx(38-52)MsgEthereumTx(56-56)MsgEthereumTx(57-59)ExtensionOptionsEthereumTx(265-266)ExtensionOptionsEthereumTx(270-270)ExtensionOptionsEthereumTx(271-273)MsgUpdateParams(355-361)MsgUpdateParams(365-365)MsgUpdateParams(366-368)DynamicFeeTx(204-229)DynamicFeeTx(233-233)DynamicFeeTx(234-236)AccessListTx(145-168)AccessListTx(172-172)AccessListTx(173-175)LegacyTx(90-109)LegacyTx(113-113)LegacyTx(114-116)
chain/evm/types/chain_config.go (2)
chain/evm/types/chain_config.pb.go (9)
ChainConfig(29-85)ChainConfig(89-89)ChainConfig(90-92)BlobScheduleConfig(141-146)BlobScheduleConfig(150-150)BlobScheduleConfig(151-153)BlobConfig(209-213)BlobConfig(217-217)BlobConfig(218-220)chain/evm/types/errors.go (1)
ErrInvalidChainConfig(55-55)
chain/evm/types/eth.go (3)
chain/evm/types/msg.go (1)
NewTx(48-53)chain/types/int.go (1)
IsValidInt256(59-61)chain/evm/types/errors.go (1)
ErrInvalidGasFee(85-85)
chain/evm/types/legacy_tx.go (3)
chain/types/int.go (2)
SafeNewIntFromBigInt(43-48)IsValidInt256(59-61)chain/evm/types/tx_data.go (1)
DeriveChainID(78-98)chain/evm/types/errors.go (1)
ErrInvalidGasFee(85-85)
chain/evm/types/dynamic_fee_tx.go (5)
chain/types/int.go (2)
SafeNewIntFromBigInt(43-48)IsValidInt256(59-61)chain/evm/types/access_list.go (2)
AccessList(10-10)NewAccessList(14-34)chain/evm/types/errors.go (2)
ErrInvalidGasCap(97-97)ErrInvalidGasFee(85-85)chain/types/errors.go (1)
ErrInvalidChainID(14-14)chain/evm/types/utils.go (1)
EffectiveGasPrice(227-233)
chain/evm/types/access_list_tx.go (4)
chain/types/int.go (2)
SafeNewIntFromBigInt(43-48)IsValidInt256(59-61)chain/evm/types/access_list.go (2)
AccessList(10-10)NewAccessList(14-34)chain/evm/types/errors.go (1)
ErrInvalidGasFee(85-85)chain/types/errors.go (1)
ErrInvalidChainID(14-14)
chain/evm/precompiles/bank/i_bank_module.abigen.go (1)
ethereum/util/contract.go (2)
BoundContract(27-35)Contract(15-23)
chain/evm/precompiles/staking/i_staking_module.abigen.go (1)
chain/evm/precompiles/exchange/i_exchange_module.abigen.go (1)
CosmosCoin(33-36)
🪛 checkmake (0.2.2)
Makefile
[warning] 223-223: Missing required phony target "all"
(minphony)
[warning] 223-223: Missing required phony target "clean"
(minphony)
[warning] 223-223: Missing required phony target "test"
(minphony)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: run-tests
- GitHub Check: lint
🔇 Additional comments (104)
.gitignore (1)
3-3: LGTM!Adding
.vscode/to gitignore is a good practice to prevent VSCode-specific configuration files from being committed to version control, consistent with existing IDE ignores like.idea/..github/workflows/golangci-lint.yml (2)
16-16: LGTM!Updating to newer action versions (checkout@v4 and golangci-lint-action@v8) is good practice to get the latest bug fixes and improvements.
Also applies to: 22-22
25-25: golangci-lint v2.1.6 is valid
This version is confirmed in the official GitHub releases and package indexes; no update required.chain/crypto/ethsecp256k1/ethsecp256k1.go (1)
76-76: LGTM!Changing the method receivers from named to unnamed is a good stylistic improvement since the receiver variables are not used in the method bodies. This enhances consistency across the codebase.
Also applies to: 156-156
chain/crypto/hd/algorithm.go (2)
23-24: LGTM!Updating the comments from "Ethermint" to "Injective" correctly reflects the project branding and maintains accurate documentation.
Also applies to: 27-30
52-52: LGTM!Changing unused method receivers to unnamed improves code consistency. Note that the
Derivemethod correctly retains its named receiver since it's used in the method body.Also applies to: 97-97
auth_vote/authz_vote.go (5)
4-4: LGTM!Adding context management with a 10-second timeout is excellent practice for network operations. This prevents the application from hanging indefinitely on network calls.
Also applies to: 8-8, 65-67
20-20: LGTM!The revive disable comment is appropriate for an example script where demonstrating the complete flow is more important than strict function length limits.
23-23: LGTM!The migration to
NewChainClientV2and the simplified Tendermint client creation (removing the "/websocket" path) align with the updated API as documented in the PR summary. This modernizes the example to use the newer client interface.Also applies to: 55-59
68-68: LGTM!Consistently passing the context with timeout to all network operations (
CurrentChainGasPriceandAsyncBroadcastMsg) ensures proper timeout handling throughout the network calls.Also applies to: 102-102, 111-111
108-108: LGTM!Changing JSON indentation to tabs is a minor formatting improvement that may align with project coding standards.
chain/crypto/hd/hd_path.go (3)
7-13: LGTM! Well-documented constants with proper references.The BIP44 coin type 60 correctly follows EIP-84 for Ethereum, and the default HD path is properly sourced from the go-ethereum accounts package.
15-17: Clean type definition for path iteration.The PathIterator function type provides a clean abstraction for iterating over derivation paths.
19-32: Robust implementation with proper error handling.The function correctly:
- Parses the base path with error handling
- Supports both Ledger Live and default iterators
- Returns appropriate errors when parsing fails
chain/evm/types/access_list.go (3)
8-10: Clear type definition for EIP-2930 access lists.The AccessList type correctly represents the protobuf-compatible slice of AccessTuple structs.
12-34: Robust constructor with proper nil handling.The NewAccessList function correctly:
- Handles nil input gracefully
- Converts storage keys from Hash to string format
- Converts addresses using String() method
- Returns properly structured AccessList
36-55: Correct conversion back to go-ethereum format.The ToEthAccessList method properly converts:
- String addresses back to common.Address using HexToAddress
- String storage keys back to common.Hash using HexToHash
- Returns proper pointer to ethtypes.AccessList
chain/evm/types/events.go (3)
3-8: Well-defined event type constants.The event types are clearly defined with appropriate names for Ethereum transactions, block blooms, and transaction logs. The reference to TypeMsgEthereumTx maintains consistency with the message type definition.
9-21: Comprehensive attribute key definitions.The attribute keys cover all necessary EVM transaction metadata including contract addresses, recipients, hashes, gas usage, and failure indicators. The naming convention is consistent and descriptive.
22-24: Appropriate metric key constants.The metric keys for database transitions and static calls provide good monitoring capabilities for EVM operations.
Makefile (5)
4-4: Version updates align with chain upgrade objectives.The updates to injective-indexer (v1.16.54) and injective-core (v1.16.0) versions correctly support the chain upgrade to v1.16 mentioned in the PR objectives.
Also applies to: 7-7
54-75: Comprehensive EVM module support added.The expansion includes all necessary EVM-related files:
- ERC20 module types and codec
- EVM transaction types (access_list, dynamic_fee, legacy)
- EVM utilities and configurations
- Proper codec and error handling files
This aligns well with the PR's goal of adding full EVM support.
151-154: EVM precompile bindings properly integrated.The addition of precompile bindings for bank, exchange, and staking modules supports the EVM integration by providing Go bindings for smart contract interactions.
162-171: Well-implemented message extraction utility.The extract-message-names target:
- Properly finds and processes tx.pb.go files
- Filters out Response messages correctly
- Outputs structured JSON format
- Provides useful statistics
This will be valuable for tooling and runtime features.
219-221: Useful lint-all target addition.The lint-all target provides comprehensive linting without revision constraints, which is useful for complete codebase analysis.
README.md (3)
31-47: Clear and helpful client selection guidance.The documentation effectively explains:
- When to use each client version
- Compatibility considerations for existing applications
- Migration path to V2 for new features
- Practical code examples for instantiation
This will help developers make informed decisions about which client to use.
48-73: Comprehensive Markets Assistant documentation.The section provides:
- Clear examples for both V1 and V2 assistant creation
- Explanation of helper methods available
- Important compatibility warnings
- Proper error handling examples
This documentation will prevent common integration mistakes.
74-84: Important format differences clearly explained.The format differences section highlights a crucial distinction:
- V1 returns raw chain format values
- V2 returns human-readable format (except deposits)
- Explains the rationale behind deposit format consistency
This information is essential for developers migrating between versions or working with both.
.golangci.yml (3)
1-3: LGTM! Proper upgrade to golangci-lint v2 format.The addition of the
version: "2"field and movingtests: falseto the top level correctly follows the golangci-lint v2 schema requirements.
19-46: Excellent modernization of linter settings.The restructuring from
linters-settingstosettingswith detailedgocriticandreviveconfiguration is well-implemented:
gocriticproperly defines disabled checks and enabled tagsreviveenables all rules with sensible customizations (140 char line limit, cognitive complexity threshold of 20)- The
add-constantrule is appropriately disabled to avoid excessive constant suggestions
47-67: Well-structured exclusions configuration.The new
exclusionssection properly leverages golangci-lint v2 features:
generated: laxappropriately relaxes rules for generated code- Preset exclusions cover common false positives effectively
- Path-based exclusions for specific directories and files are well-targeted
- The
reviveexclusion for ALL_CAPS naming in specified paths makes sense for protocol buffers and generated codechain/evm/types/logs.go (8)
13-19: LGTM! Clean constructor implementation.The
NewTransactionLogsconstructor properly initializes the struct with the hash converted to string format and the provided logs slice.
21-27: LGTM! Proper integration with Ethereum types.The
NewTransactionLogsFromEthconstructor correctly handles conversion from Ethereum's native log types using theNewLogsFromEthhelper function.
29-47: Thorough validation with good error messages.The validation logic is comprehensive:
- Checks for empty hash using the utility function from
chain/types- Validates each log is non-nil with descriptive error messages
- Ensures transaction hash consistency between parent and child logs
- Properly wraps validation errors with context
54-69: Comprehensive log validation with proper error handling.The validation covers all critical fields:
- Address validation using existing utility
- Block hash and transaction hash empty checks
- Block number zero check with appropriate error
- Good use of error wrapping for context
71-89: Efficient conversion to Ethereum types.The
ToEthereummethod properly converts:
- Topics slice with pre-allocated capacity
- All fields correctly mapped to Ethereum's log structure
- Proper use of
common.HexToHashandcommon.HexToAddress- Type conversions handled appropriately (uint64 to uint)
91-100: Well-optimized slice conversion.The function handles edge cases properly:
- Returns nil for empty input (avoiding unnecessary allocation)
- Pre-allocates slice with correct capacity
- Clean iteration and conversion logic
111-129: Proper conversion from Ethereum types.The
NewLogFromEthfunction correctly:
- Converts topics slice with proper string formatting
- Uses the
HexAddressutility for consistent address formatting- Maps all fields appropriately with correct type conversions
131-140: Efficient bloom filter implementation.The
LogsBloomfunction properly implements Ethereum's bloom filter algorithm:
- Uses Ethereum's native
Bloomtype for correctness- Adds both log addresses and topics to the bloom filter
- Returns the raw bytes as expected
chain/evm/types/codec.go (4)
14-22: LGTM! Proper codec initialization.The codec setup correctly initializes:
- Legacy Amino codec for backward compatibility
- ProtoCodec with new interface registry
- AminoCodec for JSON encoding support
- Proper deprecation comment for AminoCodec
61-76: LGTM! Proper error handling in PackTxData.The function correctly:
- Validates the input implements
proto.Message- Uses appropriate error wrapping with
errorsmod.Wrapf- Handles
codectypes.NewAnyWithValueerrors properly
78-91: LGTM! Robust UnpackTxData implementation.The function properly handles:
- Nil input validation with descriptive error
- Type assertion with proper error messaging
- Consistent error wrapping pattern
93-96: LGTM! Proper legacy Amino registration.The function correctly registers
MsgUpdateParamswith the legacy Amino codec for EIP-712 compatibility using the defined constant name.chain/erc20/types/codec.go (4)
13-13: LGTM! Clear module name definition.The
ModuleNameconstant is properly defined for consistent module identification.
15-19: LGTM! Complete Amino codec registration.All three message types (
MsgUpdateParams,MsgCreateTokenPair,MsgDeleteTokenPair) are properly registered with descriptive names following the module/MessageType pattern.
21-29: LGTM! Proper interface registry setup.The function correctly:
- Registers all messages as
sdk.Msgimplementations- Includes message service descriptor registration
- Follows Cosmos SDK conventions
35-42: LGTM! Proper codec initialization and sealing.The init function correctly:
- Registers with the module's own codec
- Integrates with SDK's legacy Amino codec
- Registers with authz Amino codec for proper MsgGrant/MsgExec support
- Properly seals the codec to prevent further modifications
chain/evm/types/eth.go (6)
12-18: LGTM! Clean wrapper design and constructor.The
EthereumTxstruct properly embeds*ethtypes.Transactionand the constructor correctly creates a new transaction from the provided data.
20-25: LGTM! Safe size calculation with nil check.The
Sizemethod properly handles the nil case and returns the correct transaction size.
27-37: LGTM! Proper binary marshaling with nil handling.The
MarshalTomethod correctly:
- Handles nil transaction case
- Uses the embedded transaction's
MarshalBinarymethod- Properly copies data to the destination buffer
- Returns the correct byte count
39-48: LGTM! Robust unmarshaling with proper initialization.The
Unmarshalmethod correctly:
- Handles empty input by setting transaction to nil
- Initializes new transaction when needed
- Delegates to the embedded transaction's
UnmarshalBinarymethod
50-64: LGTM! Proper JSON handling using hex encoding.Both JSON methods correctly:
- Use
hexutil.Bytesfor proper hex encoding/decoding- Handle errors appropriately
- Delegate to the binary marshaling/unmarshaling methods
- Follow Ethereum's standard JSON representation
66-84: Comprehensive validation with proper error handling.The validation logic correctly:
- Prevents zero gas transactions from filling mempool
- Validates all gas-related fields are within 256-bit bounds
- Uses appropriate error types (
ErrInvalidGasLimit,ErrInvalidGasPrice,ErrInvalidGasFee)- Leverages the utility function
types.IsValidInt256for bound checkingchain/evm/types/chain_config.go (6)
1-11: LGTM: Clean package structure and appropriate importsThe imports are well-organized and necessary for the EVM chain configuration functionality.
13-48: LGTM: Comprehensive Ethereum configuration conversionThe
EthereumConfigmethod provides a thorough mapping from the internalChainConfigto go-ethereum'sparams.ChainConfig. The use of helper functionsgetBlockValueandgetTimeValueensures consistent nil/negative value handling.
50-97: LGTM: Comprehensive default configurationThe default configuration activates all Ethereum forks from genesis (block 0), which is appropriate for a new chain that wants to support the latest Ethereum features immediately. The configuration is comprehensive and consistently structured.
99-113: LGTM: Consistent conversion helpersThe helper functions provide clean conversion logic with appropriate nil/negative value handling. Using
BigIntMut()is acceptable here since the values are used immediately for assignment.
115-179: LGTM: Comprehensive validation with proper error contextThe validation method thoroughly checks all configuration fields and appropriately wraps errors with field context. The use of
CheckConfigForkOrder()ensures logical consistency of fork activation points.
219-267: LGTM: Well-structured blob configuration conversionThe bidirectional conversion functions properly handle nil values and provide clean mapping between internal and Ethereum blob configuration types. The type conversions and field mappings are handled correctly.
chain/evm/types/key.go (4)
1-24: LGTM: Well-defined module constantsThe module constants follow standard Cosmos SDK patterns. The
ObjectStoreKeyprefix clearly distinguishes object storage from persistent storage.
26-38: LGTM: Well-organized prefix definitionsUsing separate
iotagroups for persistent and object store prefixes prevents conflicts. Starting fromiota + 1avoids zero-value prefixes, which is a good practice for key prefixes.
40-53: LGTM: Clear key prefix declarationsThe key prefix variables are properly initialized and the comment about
KeyPrefixObjectParamscachingEVMBlockConfigprovides helpful context.
55-71: LGTM: Efficient key construction utilitiesThe functions provide clean hierarchical key construction.
ObjectBloomKeyproperly uses big-endian encoding for consistent ordering and a fixed-size array for efficiency.chain/evm/types/params.go (6)
1-27: LGTM: Appropriate default constants for InjectiveThe default constants are well-chosen for the Injective ecosystem. The permissive defaults (allowing unprotected transactions, enabling contract creation/calls) align with a permissionless blockchain design.
29-52: LGTM: Well-designed constructor functionsThe constructors are clean and the decision to keep
ExtraEIPsempty by default is sensible to avoid conflicts with the latest hard fork features. The explanatory comment is helpful.
54-85: LGTM: Comprehensive parameter validationThe validation method systematically checks all parameter fields with appropriate helper functions. The validation order is logical and error handling follows best practices.
87-114: LGTM: Well-designed helper and permissioning methodsThe helper methods provide clean conversions and the builder pattern methods are convenient. The address comparison in
IsAuthorisedDeployercorrectly handles hex address conversion and byte comparison.
116-158: LGTM: Appropriate validation helpersThe validation functions leverage existing libraries appropriately. Using
vm.ValidEipensures only valid EIPs are accepted, and the London hardfork check is correctly implemented.
160-178: LGTM: Robust authorized deployer validationThe function properly validates hex addresses, normalizes them through
common.Address, and prevents duplicates. Using address bytes as map keys correctly handles case differences in hex addresses.chain/evm/types/legacy_tx.go (6)
1-42: LGTM: Robust legacy transaction constructorThe constructor properly handles all field conversions with appropriate error checking. Using
SafeNewIntFromBigIntprevents overflow issues, and the nilToaddress handling supports contract creation transactions.
44-83: LGTM: Correct method implementationsThe methods are properly implemented with appropriate deep copying for byte slices.
GetChainIDcorrectly usesDeriveChainIDfor legacy signature format, andGetAccessListappropriately returns nil.
85-121: LGTM: Appropriate gas and fee method implementationsThe methods correctly handle legacy transaction semantics where gas price serves as both tip and fee cap. Nil handling and address conversion are implemented properly.
123-157: LGTM: Correct conversion and signature handlingThe Ethereum format conversion is comprehensive and correct. The signature methods appropriately handle nil values, and ignoring the chainID parameter in
SetSignatureValuesis correct for legacy transactions.
159-192: LGTM: Comprehensive validation logicThe validation systematically checks all critical fields with appropriate bounds checking and error handling. Allowing nil amount while preventing negative values is correct for transaction semantics.
194-217: LGTM: Correct fee calculations for legacy transactionsThe fee calculation methods are appropriately implemented. The effective methods correctly return the same values as non-effective versions since legacy transactions don't support dynamic fees.
chain/evm/types/dynamic_fee_tx.go (6)
1-59: LGTM: Comprehensive dynamic fee transaction constructorThe constructor properly handles all EIP-1559 fields including gas caps and access list conversion. Using
SafeNewIntFromBigIntprevents overflow issues and signature handling is complete.
61-91: LGTM: Correct dynamic fee transaction methodsThe methods properly handle EIP-1559 specifics, including direct chain ID storage (not signature-derived) and comprehensive field copying including access list.
93-109: LGTM: Proper access list and data handlingThe methods correctly convert access lists and handle data access with appropriate nil checking for optional access lists.
111-151: LGTM: Appropriate gas and fee accessors for dynamic fee transactionsThe methods correctly handle dynamic fee semantics where
GetGasPricereturns the fee cap. All accessors properly handle nil values.
153-194: LGTM: Complete conversion and signature handlingThe Ethereum format conversion includes all dynamic fee fields, and signature methods properly handle chain ID storage in addition to standard V, R, S values.
258-281: LGTM: Correct dynamic fee calculationsThe fee calculation methods properly implement EIP-1559 semantics, using conservative fee cap estimates and correctly incorporating base fee for effective calculations.
chain/evm/types/msg.go (6)
1-35: LGTM!The imports and interface implementations are well-structured and appropriate for integrating Ethereum transactions into the Cosmos SDK framework.
37-115: LGTM!The constructor functions correctly handle all Ethereum transaction types (Legacy, AccessList, and DynamicFee) with proper type determination logic.
117-204: LGTM!The transaction manipulation methods provide good backward compatibility with legacy sender recovery while properly handling the new From field.
327-361: LGTM!The transaction conversion methods properly bridge Ethereum and Cosmos SDK transaction formats with correct fee handling and extension options.
363-375: LGTM!The MsgUpdateParams implementation follows standard Cosmos SDK patterns for governance messages.
222-243: Confirm SignMode usage for Ethereum transactionsPlease double-check that using
SignMode_SIGN_MODE_TEXTUALinchain/evm/types/msg.go:222–243is intentional and interoperable with the Ethereum signing workflow. Ethereum transactions typically leverage RLP-based or “direct” signing modes (e.g.,SignMode_SIGN_MODE_DIRECTorRLPSignBytes), so ensure that downstream tooling and wallets will correctly interpret the signature produced bySignMode_SIGN_MODE_TEXTUAL.
- File: chain/evm/types/msg.go
- Method:
MsgEthereumTx.Sign(lines 222–243)- Current mode:
signing.SignMode_SIGN_MODE_TEXTUALIf this choice is by design, please document the rationale and verify compatibility with existing Ethereum clients and keyring implementations.
chain/evm/types/errors.go (3)
1-112: LGTM!The error definitions are comprehensive and properly organized with appropriate error codes and descriptive messages. Good attention to JSON-RPC standards.
114-256: LGTM!The VMError interface and implementation provide excellent error handling with proper revert reason unpacking and JSON serialization for ABCI integration.
258-291: LGTM!The RevertError implementation correctly follows Ethereum JSON-RPC standards with error code 3 for reverted executions.
chain/evm/types/access_list_tx.go (4)
1-56: LGTM!The constructor properly handles conversion from Ethereum transaction types with appropriate nil checks and safe integer conversions.
58-139: LGTM!The getter methods correctly implement EIP-2930 semantics where gas tip and fee caps equal the gas price.
141-181: LGTM!The conversion and signature methods properly handle all fields with appropriate nil checks.
226-249: LGTM!The fee calculation methods correctly implement EIP-2930 semantics.
chain/evm/precompiles/bank/mint_burn_bank_erc20.abigen.go (1)
1-3: LGTM!This is an auto-generated file with proper warning against manual edits. The contract bindings appear complete and well-structured.
chain/evm/precompiles/bank/i_bank_module.abigen.go (1)
1-3: LGTM!This is an auto-generated interface binding file with proper warning against manual edits. The precompile interface methods are appropriately defined.
chain/evm/precompiles/bank/fixed_supply_bank_erc20.abigen.go (8)
1-30: LGTM!The file header and imports follow standard go-ethereum contract binding patterns. The "DO NOT EDIT" warning is appropriate for generated code, and all necessary imports are present.
32-44: LGTM!The contract metadata includes a complete ERC20 ABI with modern features like custom errors. The deprecated variables provide backward compatibility while encouraging use of the newer MetaData structure.
46-61: LGTM!The deployment function follows standard go-ethereum patterns with proper error handling for ABI parsing and deployment. The function signature and return values are correctly structured.
63-120: LGTM!The struct definitions follow standard go-ethereum binding patterns, providing clean separation between read-only, write-only, and event filtering operations. The session and raw access structs provide appropriate abstraction levels.
122-165: LGTM!The constructor functions and binding helper follow standard go-ethereum patterns. The separation of concerns allows creating contract instances with different capabilities while maintaining consistent error handling.
167-203: LGTM!The raw contract interaction methods provide appropriate low-level access while properly delegating to the underlying contract wrappers. The separation between caller and transactor raw methods maintains the security model.
205-452: LGTM!The method bindings provide complete coverage of all ERC20 functions with proper type safety. The three variants (base, session, caller/transactor session) offer flexibility for different usage patterns while maintaining consistent error handling.
454-760: LGTM!The event handling implementation is comprehensive and robust. The iterator pattern, subscription management, and channel-based event processing follow go-ethereum best practices. Both Approval and Transfer events are fully supported with filtering, watching, and parsing capabilities.
| return errorsmod.Wrap( | ||
| errortypes.ErrInvalidChainID, | ||
| "chain ID must be present on AccessList txs", | ||
| ) | ||
| } |
There was a problem hiding this comment.
Fix inconsistent error type usage.
The code uses errortypes.ErrInvalidChainID which appears to be from cosmos-sdk, but based on the relevant snippets, there's also a local ErrInvalidChainID in chain/types/errors.go. Ensure consistent error type usage across the codebase.
- return errorsmod.Wrap(
- errortypes.ErrInvalidChainID,
- "chain ID must be present on AccessList txs",
- )
+ return errorsmod.Wrap(
+ types.ErrInvalidChainID,
+ "chain ID must be present on AccessList txs",
+ )📝 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.
| return errorsmod.Wrap( | |
| errortypes.ErrInvalidChainID, | |
| "chain ID must be present on AccessList txs", | |
| ) | |
| } | |
| return errorsmod.Wrap( | |
| types.ErrInvalidChainID, | |
| "chain ID must be present on AccessList txs", | |
| ) | |
| } |
🤖 Prompt for AI Agents
In chain/evm/types/access_list_tx.go around lines 217 to 221, replace the usage
of the external error type errortypes.ErrInvalidChainID with the local
ErrInvalidChainID defined in chain/types/errors.go to maintain consistent error
handling across the codebase. Import the local error if necessary and update the
Wrap call accordingly.
| // RegisterInterfaces registers the client interfaces to protobuf Any. | ||
| func RegisterInterfaces(registry codectypes.InterfaceRegistry) { | ||
| registry.RegisterImplementations( | ||
| (*sdk.Msg)(nil), | ||
| &MsgEthereumTx{}, | ||
| ) | ||
| registry.RegisterImplementations( | ||
| (*tx.TxExtensionOptionI)(nil), | ||
| &ExtensionOptionsEthereumTx{}, | ||
| ) | ||
| registry.RegisterImplementations( | ||
| (*sdk.Msg)(nil), | ||
| &MsgEthereumTx{}, | ||
| &MsgUpdateParams{}, | ||
| ) | ||
| registry.RegisterInterface( | ||
| "injective.evm.v1.TxData", | ||
| (*TxData)(nil), | ||
| &DynamicFeeTx{}, | ||
| &AccessListTx{}, | ||
| &LegacyTx{}, | ||
| ) | ||
|
|
||
| msgservice.RegisterMsgServiceDesc(registry, &_Msg_serviceDesc) | ||
| } |
There was a problem hiding this comment.
Fix duplicate registration of MsgEthereumTx.
There's a duplicate registration of MsgEthereumTx as an sdk.Msg implementation on lines 37-40 and 45-49.
func RegisterInterfaces(registry codectypes.InterfaceRegistry) {
- registry.RegisterImplementations(
- (*sdk.Msg)(nil),
- &MsgEthereumTx{},
- )
registry.RegisterImplementations(
(*tx.TxExtensionOptionI)(nil),
&ExtensionOptionsEthereumTx{},
)
registry.RegisterImplementations(
(*sdk.Msg)(nil),
&MsgEthereumTx{},
&MsgUpdateParams{},
)📝 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.
| // RegisterInterfaces registers the client interfaces to protobuf Any. | |
| func RegisterInterfaces(registry codectypes.InterfaceRegistry) { | |
| registry.RegisterImplementations( | |
| (*sdk.Msg)(nil), | |
| &MsgEthereumTx{}, | |
| ) | |
| registry.RegisterImplementations( | |
| (*tx.TxExtensionOptionI)(nil), | |
| &ExtensionOptionsEthereumTx{}, | |
| ) | |
| registry.RegisterImplementations( | |
| (*sdk.Msg)(nil), | |
| &MsgEthereumTx{}, | |
| &MsgUpdateParams{}, | |
| ) | |
| registry.RegisterInterface( | |
| "injective.evm.v1.TxData", | |
| (*TxData)(nil), | |
| &DynamicFeeTx{}, | |
| &AccessListTx{}, | |
| &LegacyTx{}, | |
| ) | |
| msgservice.RegisterMsgServiceDesc(registry, &_Msg_serviceDesc) | |
| } | |
| func RegisterInterfaces(registry codectypes.InterfaceRegistry) { | |
| registry.RegisterImplementations( | |
| (*tx.TxExtensionOptionI)(nil), | |
| &ExtensionOptionsEthereumTx{}, | |
| ) | |
| registry.RegisterImplementations( | |
| (*sdk.Msg)(nil), | |
| &MsgEthereumTx{}, | |
| &MsgUpdateParams{}, | |
| ) | |
| registry.RegisterInterface( | |
| "injective.evm.v1.TxData", | |
| (*TxData)(nil), | |
| &DynamicFeeTx{}, | |
| &AccessListTx{}, | |
| &LegacyTx{}, | |
| ) | |
| msgservice.RegisterMsgServiceDesc(registry, &_Msg_serviceDesc) | |
| } |
🤖 Prompt for AI Agents
In chain/evm/types/codec.go between lines 35 and 59, the MsgEthereumTx type is
registered twice as an implementation of sdk.Msg, causing duplicate
registration. Remove the first registry.RegisterImplementations call that
registers MsgEthereumTx alone (lines 37-40) and keep the later call (lines
45-49) that registers MsgEthereumTx along with MsgUpdateParams to avoid
duplication.
| // Validate performs a stateless validation of the tx fields. | ||
| func (tx DynamicFeeTx) Validate() error { | ||
| if tx.GasTipCap == nil { | ||
| return errorsmod.Wrap(ErrInvalidGasCap, "gas tip cap cannot nil") | ||
| } | ||
|
|
||
| if tx.GasFeeCap == nil { | ||
| return errorsmod.Wrap(ErrInvalidGasCap, "gas fee cap cannot nil") | ||
| } | ||
|
|
||
| if tx.GasTipCap.IsNegative() { | ||
| return errorsmod.Wrapf(ErrInvalidGasCap, "gas tip cap cannot be negative %s", tx.GasTipCap) | ||
| } | ||
|
|
||
| if tx.GasFeeCap.IsNegative() { | ||
| return errorsmod.Wrapf(ErrInvalidGasCap, "gas fee cap cannot be negative %s", tx.GasFeeCap) | ||
| } | ||
|
|
||
| if !types.IsValidInt256(tx.GetGasTipCap()) { | ||
| return errorsmod.Wrap(ErrInvalidGasCap, "out of bound") | ||
| } | ||
|
|
||
| if !types.IsValidInt256(tx.GetGasFeeCap()) { | ||
| return errorsmod.Wrap(ErrInvalidGasCap, "out of bound") | ||
| } | ||
|
|
||
| if tx.GasFeeCap.LT(*tx.GasTipCap) { | ||
| return errorsmod.Wrapf( | ||
| ErrInvalidGasCap, "max priority fee per gas higher than max fee per gas (%s > %s)", | ||
| tx.GasTipCap, tx.GasFeeCap, | ||
| ) | ||
| } | ||
|
|
||
| if !types.IsValidInt256(tx.Fee()) { | ||
| return errorsmod.Wrap(ErrInvalidGasFee, "out of bound") | ||
| } | ||
|
|
||
| amount := tx.GetValue() | ||
| // Amount can be 0 | ||
| if amount != nil && amount.Sign() == -1 { | ||
| return errorsmod.Wrapf(ErrInvalidAmount, "amount cannot be negative %s", amount) | ||
| } | ||
| if !types.IsValidInt256(amount) { | ||
| return errorsmod.Wrap(ErrInvalidAmount, "out of bound") | ||
| } | ||
|
|
||
| if tx.To != "" { | ||
| if err := types.ValidateAddress(tx.To); err != nil { | ||
| return errorsmod.Wrap(err, "invalid to address") | ||
| } | ||
| } | ||
|
|
||
| if tx.GetChainID() == nil { | ||
| return errorsmod.Wrap( | ||
| errortypes.ErrInvalidChainID, | ||
| "chain ID must be present on AccessList txs", | ||
| ) | ||
| } | ||
|
|
||
| return nil | ||
| } |
There was a problem hiding this comment.
Fix error message for dynamic fee transaction validation
The validation logic is comprehensive and correctly implements EIP-1559 requirements. However, there's an incorrect error message:
return errorsmod.Wrap(
errortypes.ErrInvalidChainID,
- "chain ID must be present on AccessList txs",
+ "chain ID must be present on DynamicFee txs",
)The validation correctly ensures gas fee cap ≥ gas tip cap, which is essential for EIP-1559 compliance.
🤖 Prompt for AI Agents
In chain/evm/types/dynamic_fee_tx.go between lines 196 and 256, the error
message for the check where gas fee cap is less than gas tip cap is incorrect.
The message currently states "max priority fee per gas higher than max fee per
gas (%s > %s)" but the values are reversed in the formatting. Fix this by
swapping the order of tx.GasTipCap and tx.GasFeeCap in the error message
formatting so it correctly reflects "max priority fee per gas higher than max
fee per gas (gasTipCap > gasFeeCap)".
Summary by CodeRabbit
New Features
Documentation
Chores
.gitignoreto exclude.vscode/directory.Refactor
Bug Fixes