Update contract listener documentation to be clearer

Signed-off-by: Enrique Lacal <[email protected]>

Author: EnriqueL8

doc-site/docs/reference/types/_includes/contractlistener_description.md

@@ -40,7 +40,7 @@ Each filter is identified by a generated `signature` that matches a single event
 
 Ethereum provides a string standard for event signatures, of the form `EventName(uint256,bytes)`. Prior to v1.3.1, the signature of each Ethereum contract listener would exactly follow this Ethereum format.
 
-As of v1.3.1, Ethereum signature strings have been changed, because this format does not fully describe the event - particularly because each top-level parameter can in the ABI definition be marked as `indexed`. For example, while the following two Solidity events have the same signature, they are serialized differently due to the different placement of `indexed` parameters, and thus a listener must define both individually to be able to process them:
+As of v1.3.1, Ethereum format signature strings have been changed in FireFly, because this format does not fully describe the event - particularly because each top-level parameter can in the ABI definition be marked as `indexed`. For example, while the following two Solidity events have the same signature, they are serialized differently due to the different placement of `indexed` parameters, and thus a listener must define both individually to be able to process them:
 
 - ERC-20 `Transfer`
 
@@ -54,7 +54,7 @@ As of v1.3.1, Ethereum signature strings have been changed, because this format
   event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
   ```
 
-The two above are now expressed in the following manner by the Ethereum blockchain connector:
+The two above are now expressed in the following manner by the FireFly Ethereum blockchain connector:
 
 ```solidity
 Transfer(address,address,uint256) [i=0,1]
@@ -65,7 +65,7 @@ The `[i=]` listing at the end of the signature indicates the position of all par
 
 Building on the blockchain-specific signature format for each event, FireFly will then compute the final signature for each filter and each contract listener as follows:
 
-- Each filter signature is a combination of the location and the specific connector event signature, such as `0xa5ea5d0a6b2eaf194716f0cc73981939dca26da1:Changed(address,uint256) [i=0]`
+- Each filter signature is a combination of the location and the specific connector event signature, such as `0xa5ea5d0a6b2eaf194716f0cc73981939dca26da1:Transfer(address,address,uint256) [i=0,1]`
 - Each contract listener signature is a concatenation of all the filter signatures, separated by `;`
 
 #### Duplicate filters
@@ -84,7 +84,7 @@ As noted above, each listener has a generated signature. This signature - contai
 
 ### Backwards compatibility
 
-As noted throughout this document, the behavior of listeners is changed in v1.3.1. However, the following behaviors are retained for backwards-compatibility, to ensure that code written prior to v1.3.1 should continue to function.
+As noted throughout this document, the behavior of listeners has changed in v1.3.1. However, the following behaviors are retained for backwards-compatibility, to ensure that code written prior to v1.3.1 should continue to function.
 
 - The response from all query APIs of `listeners` will continue to populate top-level `event` and `location` fields
   - The first entry from the `filters` array is duplicated to these fields
@@ -93,12 +93,104 @@ As noted throughout this document, the behavior of listeners is changed in v1.3.
 - The `signature` field is preserved at the listener level
   - The format has been changed as described above
 
-### Input formats
+## Input Examples
 
 The two input formats supported when creating a contract listener are shown below.
 
+### With Event Definition
+
+In these examples, the event schema in the FireFly Interface format is provided describing the event and its parameters. See [FireFly Interface Format](../firefly_interface_format.md)
+
 **Muliple Filters**
+```json
+{
+  "filters": [
+    {
+      "event": {
+          "name": "Changed",
+          "description": "",
+          "params": [
+              {
+                  "name": "x",
+                  "schema": {
+                      "type": "integer",
+                      "details": {
+                          "type": "uint256",
+                          "internalType": "uint256"
+                      }
+                  }
+              }
+          ]
+      },
+      "location": {
+        "address": "0xa5ea5d0a6b2eaf194716f0cc73981939dca26da1"
+      }
+    },
+    {
+      "event": {
+          "name": "AnotherEvent",
+          "description": "",
+          "params": [
+              {
+                  "name": "my-field",
+                  "schema": {
+                      "type": "string",
+                      "details": {
+                        "type": "address",
+                        "internalType": "address",
+                        "indexed": true
+                      }
+                  }
+              }
+          ]
+      },
+      "location": {
+        "address": "0xa4ea5d0b6b2eaf194716f0cc73981939dca27da1"
+      }
+    }
+  ],
+  "options": {
+    "firstEvent": "newest"
+  },
+  "topic": "simple-storage"
+}
+```
+
+**One filter (old format)**
+
+```json
+{
+  "event": {
+      "name": "Changed",
+      "description": "",
+      "params": [
+          {
+              "name": "x",
+              "schema": {
+                  "type": "integer",
+                  "details": {
+                      "type": "uint256",
+                      "internalType": "uint256"
+                  }
+              }
+          }
+      ]
+  },
+  "location": {
+    "address": "0xa5ea5d0a6b2eaf194716f0cc73981939dca26da1"
+  },
+  "options": {
+    "firstEvent": "newest"
+  },
+  "topic": "simple-storage"
+}
+```
+
+### With Interface Reference
 
+These examples use an `interface` reference when creating the filters, the `eventPath` field is used to reference an event defined within the interface provided. See an example of creating a [FireFly Interface](../../tutorials/custom_contracts/ethereum.md/#the-firefly-interface-format) for an EVM smart contract.
+
+**Muliple Filters**
 ```json
 {
   "filters": [

doc-site/docs/reference/types/contractlistener.md

@@ -3,7 +3,7 @@ title: ContractListener
 ---
 {% include-markdown "./_includes/contractlistener_description.md" %}
 
-### Example
+### Example Response from the API
 
 ```json
 {