Add type to evm transaction filters (#658)

Author: stwiname

docs/indexer/build/manifest/arbitrum.md

@@ -301,7 +301,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                   | Supported filter                                                                                    |
 | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/arbitrum.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/arbitrum.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/arbitrum.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/arbitrum.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/avalanche.md

@@ -310,7 +310,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                    | Supported filter                                                                                    |
 | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/avalanche.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/avalanche.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/avalanche.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/avalanche.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/bsc.md

@@ -299,7 +299,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                              | Supported filter                                                                                    |
 | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/bsc.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/bsc.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/bsc.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/bsc.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/ethereum.md

@@ -297,7 +297,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                   | Supported filter                                                                                    |
 | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/ethereum.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/ethereum.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/ethereum.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/ethereum.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/flare.md

@@ -296,7 +296,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                | Supported filter                                                                                    |
 | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/flare.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/flare.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/flare.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/flare.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/gnosis.md

@@ -310,7 +310,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                 | Supported filter                                                                                    |
 | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/gnosis.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/gnosis.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/gnosis.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/gnosis.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/optimism.md

@@ -309,7 +309,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                   | Supported filter                                                                                    |
 | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/optimism.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/optimism.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/optimism.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/optimism.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.

docs/indexer/build/manifest/polygon.md

@@ -300,7 +300,7 @@ The following table explains filters supported by different handlers.
 | Handler                                                                  | Supported filter                                                                                    |
 | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------- |
 | [ethereum/BlockHandler](../mapping/polygon.md#block-handler)             | `modulo`, `timestamp`                                                                               |
-| [ethereum/TransactionHandler](../mapping/polygon.md#transaction-handler) | `function` filters (either be the function fragment or signature), `from` (address), `to` (address) |
+| [ethereum/TransactionHandler](../mapping/polygon.md#transaction-handler)| `function` filters (either be the function fragment or signature), `from` (address), `to` (address), `type` ("0x0" for legacy, "0x1" for access type lists, "0x2" for dynamic fees and "0x3" for blob transactions)  |
 | [ethereum/LogHandler](../mapping/polygon.md#log-handler)                 | `topics` filters, and `address`                                                                     |
 
 Default runtime mapping filters are an extremely useful feature to decide what block, event, or extrinsic will trigger a mapping handler.