Getting event parameters from sentinel to autotask event

Support Defender
#1

Hello I was reading https://docs.openzeppelin.com/defender/sentinel#event_schema

Will the signature contain the actual variable or just the keccak of the event function?

I was expecting to be able to get the parameters from the emit event I would be monitoring
like my sentinel is send on SomeEvent(uint256,address,address,uint256,address,uint256)

So I’m looking to extract the params, the uints, and the 3 addresses.

Will I get each of these somehow in any fields of the Event Schema?

1 Like
#2

Also just to confirm, I will get 1 execution per event that matched, even if there was 20 in the block, I would get 20 invocations of my relayer, right?

1 Like
#3

Hi @Elyx0 -

The event “matchReasons” will contain the signature of the specific rule that matched. At this time, the “transaction” field has all the information that was used to evaluate (TX properties & logs) but would have to be parsed to extract the values for the specific functions.

We currently only evaluate whether the rule matched, but don’t include the parameter values there. I think this makes sense to add. Of course non-indexed parameters would not be retrievable - or would end up being the one-way hash value. Would it work if we put a ‘params’ value on the reason object?

Let us know if you have any questions. I’d be happy to jump on a call and help you set this up.

Thanks,
Steven

1 Like
#4

That would be super efficient, because I was about to switch to my own infura parser because of this issue since the txHash didn’t help me much even by getting it through web3js getTransaction().

As long as you give me something to work with that I can parse without additional call I’m good with it!

2 Likes
#5

Also my 2 cents but I think it would be good to add the params of the event in the slack & discord webhooks as well.

2 Likes
#6

Hi @Elyx0 -

I wanted to let you know that we just released this feature. You’ll see an example in our docs. We now send two additional properties to each “match reason”: args & params.

Args is an array of all parameters (in the order of the signature).
Params is a map by name of parameter.

Notes:

  • In the scenario where you have an unnamed parameter, it will only appear in the args array.
  • If it’s an indexed parameter, we will only return the hash value
  • Parameters are now passed to the notifications

Thanks for the feature suggestion! Let us know if you see anything that can be improved.

Thanks,
Steven

1 Like
#7

Awesome, and fast! It should have been in the “What’s new!” alongside the sentinel testing (really neat). Back to building

1 Like
#8

Can you point me to the documentation part that should now mention it?

1 Like
#9

Hi @Elyx0 -

We hit an issue with our Documentation CI so the updates are not yet showing :man_facepalming:. While we fix that, this is the updated schema. Sorry about that.

{
  "transaction": {                // eth_getTransactionReceipt response body
    ...                           // see https://eips.ethereum.org/EIPS/eip-1474
  },
  "blockHash": "0xab..123",       // block hash from where this transaction was seen
  "matchReasons": [               // the reasons why sentinel triggered
    {
      "type": "event",            // event, function, or transaction
      "signature": "...",         // signature of your event/function
      "condition": "value > 5",   // condition expression (if any)
      "args": ["5"],              // parameters by index (unnamed are present)
      "params": { "value": "5" }  // parameters by name (unnamed are not present)
    }
  ],
  "sentinel": {
    "id": "44a7d5...31df5",       // internal ID of your sentinel
    "name": "Sentinel Name",      // name of your sentinel
    "abi": [...],                 // abi of your address (or undefined)
    "address": "0x000..000",      // address your sentinel is watching
    "confirmBlocks": 0,           // number of blocks sentinel waits
    "network": "rinkeby"          // network of your address
  }
}```
1 Like