fix(fmt): lint

eth_estimateGasBundle/api-spec.yml

@@ -1,16 +1,14 @@
 openapi: 3.0.0
 info:
   title: Ethereum Bundle API
-  version: "1.0"
+  version: '1.0'
 paths:
   /eth_callBundle:
     post:
       summary: Simulate a bundle of transactions
       description: >
-        Simulate a bundle of transactions at the top of a given block with the state of another
-        (or the same) block. This can be used to simulate future blocks with the current state,
-        or it can be used to simulate a past block. The sender is responsible for signing the
-        transactions and using the correct nonce and ensuring validity.
+        Simulate a bundle of transactions at the top of a given block with the state of another (or the same) block. This can be used to simulate future blocks with the current state, or it can be used to simulate a past block. The sender is responsible for signing the transactions and using the correct nonce and ensuring validity.
+
       requestBody:
         required: true
         content:
@@ -39,8 +37,8 @@ paths:
     post:
       summary: Estimate gas for a bundle of transactions
       description: >
-        Estimate the gas required for executing a bundle of transactions without actually
-        sending them to the network. This is useful for predicting gas usage and costs.
+        Estimate the gas required for executing a bundle of transactions without actually sending them to the network. This is useful for predicting gas usage and costs.
+
       requestBody:
         required: true
         content:

eth_getLogs+timestamp/README.md

@@ -52,8 +52,8 @@ params: [
 -   `transactionIndex`: `QUANTITY` - integer of the transactions index position log was created from. `null` when its pending log.
 -   `transactionHash`: `DATA`, 32 Bytes - hash of the transactions this log was created from. `null` when its pending log.
 -   `blockHash`: `DATA`, 32 Bytes - hash of the block where this log was in. `null` when its pending. `null` when its pending log.
--   `blockNumber`: `QUANTITY` - the block number where this log was in. `null` when its pending. `null` when its pending log.  
--   `blockTimestamp`: `QUANTITY` - the unix timestamp for when the block where this log was in, was collated. `null` when its pending. `null` when its pending log.**
+-   `blockNumber`: `QUANTITY` - the block number where this log was in. `null` when its pending. `null` when its pending log.
+-   `blockTimestamp`: `QUANTITY` - the unix timestamp for when the block where this log was in, was collated. `null` when its pending. `null` when its pending log.\*\*
 -   `address`: `DATA`, 20 Bytes - address from which this log originated.
 -   `data`: `DATA` - contains one or more 32 Bytes non-indexed arguments of the log.
 -   `topics`: `Array of DATA` - Array of 0 to 4 32 Bytes `DATA` of indexed log arguments. (In _solidity_: The first topic is the _hash_ of the signature of the event (e.g. `Deposit(address,bytes32,uint256)`), except you declared the event with the `anonymous` specifier.)

eth_getinclusionstats/SPEC.md

@@ -1,4 +1,3 @@
-
 ---
 EIP: XXXX
 Title: Add `eth_getinclusionstats` RPC Method
@@ -23,40 +22,44 @@ Understanding transaction inclusion dynamics is crucial for both users and devel
 ### **Method Name**: `eth_getinclusionstats`
 
 ### **Parameters**:
-  1. `TRANSACTION_HASH`: The hash of the transaction for which inclusion statistics are being requested.
-  2. `BLOCK_PARAMETER`: An optional parameter specifying the block (by number, hash, or the string "latest") up to which the search should be conducted. If omitted, the search includes the latest block.
+
+1. `TRANSACTION_HASH`: The hash of the transaction for which inclusion statistics are being requested.
+2. `BLOCK_PARAMETER`: An optional parameter specifying the block (by number, hash, or the string "latest") up to which the search should be conducted. If omitted, the search includes the latest block.
 
 ### **Returns**: An object containing:
-  - `included`: A boolean indicating whether the transaction was included in a block (`true`) or not (`false`).
-  - `blockHash`: The hash of the block in which the transaction was included. `null` if the transaction has not been included in any block.
-  - `blockNumber`: The number of the block in which the transaction was included. `null` if the transaction has not been included in any block.
-  - `transactionIndex`: The index position of the transaction in the block. `null` if the transaction has not been included in any block.
-  - Additional fields may be included to provide further analytics, such as average inclusion time, network congestion metrics, etc.
+
+-   `included`: A boolean indicating whether the transaction was included in a block (`true`) or not (`false`).
+-   `blockHash`: The hash of the block in which the transaction was included. `null` if the transaction has not been included in any block.
+-   `blockNumber`: The number of the block in which the transaction was included. `null` if the transaction has not been included in any block.
+-   `transactionIndex`: The index position of the transaction in the block. `null` if the transaction has not been included in any block.
+-   Additional fields may be included to provide further analytics, such as average inclusion time, network congestion metrics, etc.
 
 ### **Example**:
+
 ```jsonc
-  // Request
-  {
-    "jsonrpc": "2.0",
-    "method": "eth_getinclusionstats",
-    "params": ["0x...transaction hash...", "latest"],
-    "id": 1
-  }
+// Request
+{
+	"jsonrpc": "2.0",
+	"method": "eth_getinclusionstats",
+	"params": ["0x...transaction hash...", "latest"],
+	"id": 1
+}
 ```
 
-  // Response
+// Response
+
 ```jsonc
-  {
-    "jsonrpc": "2.0",
-    "id": 1,
-    "result": {
-      "included": true,
-      "blockHash": "0x...block hash...",
-      "blockNumber": "0x...block number...",
-      "transactionIndex": "0x15"
-      // Additional fields as necessary
-    }
-  }
+{
+	"jsonrpc": "2.0",
+	"id": 1,
+	"result": {
+		"included": true,
+		"blockHash": "0x...block hash...",
+		"blockNumber": "0x...block number...",
+		"transactionIndex": "0x15"
+		// Additional fields as necessary
+	}
+}
 ```
 
 **Rationale**
@@ -74,15 +77,16 @@ This EIP is fully backwards compatible as it introduces a new method without alt
 **Test Cases**
 
 Test cases for an implementation are essential for ensuring the method behaves as expected across different scenarios. These should cover, at a minimum:
-- A transaction included in a block.
-- A transaction not yet included in any block.
-- Querying with and without the `BLOCK_PARAMETER`.
+
+-   A transaction included in a block.
+-   A transaction not yet included in any block.
+-   Querying with and without the `BLOCK_PARAMETER`.
 
 **Implementation**
 
 [Note: The implementation details would typically be provided here, potentially with links to a GitHub repository containing the code.]
 
 **References**
 
-- Existing Ethereum JSON RPC documentation.
-- Related EIPs and Ethereum GitHub discussions.
+-   Existing Ethereum JSON RPC documentation.
+-   Related EIPs and Ethereum GitHub discussions.

eth_testMethod/README.md

@@ -1,6 +1,7 @@
 ### EIP-XXXX: Custom JSON-RPC Methods for Ethereum Client Testing
 
 #### Preamble
+
 ```
 EIP: <EIP number>
 Title: Custom JSON-RPC Methods for Ethereum Client Testing
@@ -13,62 +14,71 @@ Requires (*optional): <EIP number(s)>
 ```
 
 #### Abstract
+
 This EIP introduces a set of custom JSON-RPC methods designed to facilitate comprehensive testing of Ethereum clients. These methods enable the simulation of various network conditions, smart contract interactions, and blockchain states, providing developers with powerful tools for evaluating client performance, security, and compatibility.
 
 #### Motivation
+
 The motivation behind introducing these custom JSON-RPC methods is to address the lack of standardized testing mechanisms that can simulate a wide range of Ethereum network scenarios. These methods allow for more rigorous and exhaustive testing of Ethereum clients, ensuring they can operate reliably under different conditions and adhere to the Ethereum protocol specifications.
 
 #### Specification
 
 ##### Method: `eth_testMethod`
-- **Description**: This method simulates a specified blockchain condition or operation for testing purposes.
-- **Parameters**:
-  1. `testType` - A string specifying the type of test to simulate (e.g., "networkDelay", "smartContractInteraction").
-  2. `parameters` - An object containing parameters relevant to the specified test.
-- **Returns**: An object containing the results of the simulated test, including any relevant data or metrics.
+
+-   **Description**: This method simulates a specified blockchain condition or operation for testing purposes.
+-   **Parameters**:
+    1. `testType` - A string specifying the type of test to simulate (e.g., "networkDelay", "smartContractInteraction").
+    2. `parameters` - An object containing parameters relevant to the specified test.
+-   **Returns**: An object containing the results of the simulated test, including any relevant data or metrics.
 
 ##### Example
+
 ```jsonc
 // Request
 {
-  "jsonrpc": "2.0",
-  "method": "eth_testMethod",
-  "params": [
-    "smartContractInteraction",
-    {
-      "contractAddress": "0x...",
-      "functionSignature": "transfer(address,uint256)",
-      "parameters": ["0xrecipientAddress...", 100]
-    }
-  ],
-  "id": 1
+	"jsonrpc": "2.0",
+	"method": "eth_testMethod",
+	"params": [
+		"smartContractInteraction",
+		{
+			"contractAddress": "0x...",
+			"functionSignature": "transfer(address,uint256)",
+			"parameters": ["0xrecipientAddress...", 100]
+		}
+	],
+	"id": 1
 }
 ```
 
- Response
+Response
+
 ```jsonc
 {
-  "id": 1,
-  "jsonrpc": "2.0",
-  "result": {
-    "success": true,
-    "transactionHash": "0x..."
-  }
+	"id": 1,
+	"jsonrpc": "2.0",
+	"result": {
+		"success": true,
+		"transactionHash": "0x..."
+	}
 }
 ```
 
 #### Rationale
+
 The custom methods introduced in this EIP are designed to be flexible and comprehensive, allowing developers to simulate a wide range of Ethereum network conditions and behaviors. This flexibility is crucial for thorough testing and validation of Ethereum clients across different scenarios.
 
 #### Backwards Compatibility
+
 These custom JSON-RPC methods are designed to be fully compatible with existing Ethereum JSON-RPC specifications. They do not modify or replace existing methods, but rather supplement them with additional functionality for testing purposes.
 
 #### Test Cases
+
 Test cases should cover a variety of scenarios, including but not limited to network delays, smart contract deployments, transaction processing under heavy load, and consensus algorithm behaviors.
 
 #### Implementation
+
 A reference implementation of these custom methods should be provided, demonstrating their integration with existing Ethereum client software. This implementation should include detailed documentation on method usage, parameters, and expected outcomes.
 
 #### Security Considerations
-The introduction of custom JSON-RPC methods for testing purposes should not compromise the security of Ethereum clients or networks. These methods should be designed with security in mind, ensuring that they cannot be exploited to introduce vulnerabilities into client implementations or network operations.
 
+The introduction of custom JSON-RPC methods for testing purposes should not compromise the security of Ethereum clients or networks. These methods should be designed with security in mind, ensuring that they cannot be exploited to introduce vulnerabilities into client implementations or network operations.

mev_sendbetabundle/.default-spectral.yml

@@ -1 +1 @@
-extends: ["spectral:oas", "spectral:asyncapi"]
+extends: ['spectral:oas', 'spectral:asyncapi']

mev_sendbetabundle/.spectral.yaml

@@ -1 +1 @@
-extends: ["@stoplight/spectral-documentation"]
+extends: ['@stoplight/spectral-documentation']

mev_sendbetabundle/README.md

@@ -5,79 +5,93 @@ Creating an Ethereum Improvement Proposal (EIP) for a custom JSON-RPC method inv
 # EIP-XXXX: MEV Send Beta Bundle Method
 
 ## Simple Summary
+
 Introduces a custom JSON-RPC method `mev_sendBetaBundle` for submitting a set of transactions as a bundle to be included in a specific block on the Ethereum blockchain, targeting scenarios where transactions are not priority-sensitive.
 
 ## Abstract
+
 This EIP proposes a new JSON-RPC method that allows the submission of a bundle of transactions to be included in a specific block. This method is designed for transactions that do not require priority ordering within the block. The method ensures that transactions originating from the sender have a corresponding call option for the specified slot. Transactions exceeding the block's remaining gas limit are dropped in the order listed within the bundle, allowing partial fulfillment of the bundle.
 
 ## Motivation
+
 Miner Extractable Value (MEV) strategies often require the submission of transaction bundles that are executed together within the same block to exploit arbitrage opportunities, perform liquidations, or protect against front-running. The existing JSON-RPC methods do not support the submission of transaction bundles with specific block targeting and handling for non-priority sensitive transactions. This EIP aims to fill this gap, providing developers and MEV searchers with a tool to more effectively manage their transactions.
 
 ## Specification
 
 ### Method Name
+
 `mev_sendBetaBundle`
 
 ### Parameters
+
 1. `txs` - Array of raw transactions (as hex strings) to be included in the bundle.
 2. `slot` - The block number (as a string) at which the bundle should be included.
 
 ### Returns
-- `jsonrpc`: The JSON-RPC version (e.g., "2.0").
-- `method`: The method name (`mev_sendBetaBundle`).
-- `params`: An array containing a single object with two fields: `txs` (an array of raw transaction data) and `slot` (the target block number as a string).
-- `id`: A unique identifier for the request.
+
+-   `jsonrpc`: The JSON-RPC version (e.g., "2.0").
+-   `method`: The method name (`mev_sendBetaBundle`).
+-   `params`: An array containing a single object with two fields: `txs` (an array of raw transaction data) and `slot` (the target block number as a string).
+-   `id`: A unique identifier for the request.
 
 ### Errors
-- If the transaction originator does not have a corresponding call option for the specified slot, the method will fail.
-- Transactions that would cause the block's gas limit to be exceeded are dropped in the order they appear in the bundle.
+
+-   If the transaction originator does not have a corresponding call option for the specified slot, the method will fail.
+-   Transactions that would cause the block's gas limit to be exceeded are dropped in the order they appear in the bundle.
 
 ### Example
+
 Request:
+
 ```json
 {
-  "jsonrpc": "2.0",
-  "method": "mev_sendBetaBundle",
-  "params": [
-    {
-      "txs": ["0x..."],
-      "slot": "1001"
-    }
-  ],
-  "id": 8
+	"jsonrpc": "2.0",
+	"method": "mev_sendBetaBundle",
+	"params": [
+		{
+			"txs": ["0x..."],
+			"slot": "1001"
+		}
+	],
+	"id": 8
 }
 ```
 
 Response:
+
 ```json
 {
-  "jsonrpc": "2.0",
-  "method": "mev_sendBetaBundle",
-  "params": [
-    {
-      "txs": ["0x... - rawData"],
-      "slot": "1001"
-    }
-  ],
-  "id": 8
+	"jsonrpc": "2.0",
+	"method": "mev_sendBetaBundle",
+	"params": [
+		{
+			"txs": ["0x... - rawData"],
+			"slot": "1001"
+		}
+	],
+	"id": 8
 }
 ```
 
 ## Rationale
+
 The `mev_sendBetaBundle` method is designed to accommodate the specific needs of MEV strategies that do not require transactions to be executed in a priority order within a block. By allowing transactions to be bundled and specifying the block in which they should be included, this method provides a more flexible and efficient way to manage MEV-related transactions. The decision to drop transactions exceeding the block's gas limit in the order they are listed allows for partial fulfillment of the bundle, ensuring that the most critical transactions can be prioritized by the sender.
 
 ## Security Considerations
-- This method requires careful management of the block's gas limit to prevent denial of service attacks by submitting large bundles that could monopolize block space.
-- Implementers should ensure that only authorized users have the ability to submit transaction bundles to prevent spam and potential manipulation of block contents.
+
+-   This method requires careful management of the block's gas limit to prevent denial of service attacks by submitting large bundles that could monopolize block space.
+-   Implementers should ensure that only authorized users have the ability to submit transaction bundles to prevent spam and potential manipulation of block contents.
 
 ## Test Cases
-- Submission of a valid transaction bundle for a future block.
-- Handling of a bundle when the block's gas limit is exceeded.
-- Rejection of a bundle when the sender does not have a corresponding call option for the specified slot.
+
+-   Submission of a valid transaction bundle for a future block.
+-   Handling of a bundle when the block's gas limit is exceeded.
+-   Rejection of a bundle when the sender does not have a corresponding call option for the specified slot.
 
 ## Implementation
+
 This EIP requires changes to Ethereum client software to support the new JSON-RPC method. Implementations should follow the specifications outlined above to ensure compatibility across different clients.
 
 ---
 
-This draft EIP provides a comprehensive overview of the proposed `mev_sendBetaBundle` method, including its purpose, specifications, and considerations. It's structured to fit within the Ethereum Improvement Proposal framework, aiming for clarity, completeness, and technical accuracy.
+This draft EIP provides a comprehensive overview of the proposed `mev_sendBetaBundle` method, including its purpose, specifications, and considerations. It's structured to fit within the Ethereum Improvement Proposal framework, aiming for clarity, completeness, and technical accuracy.