Discussion: Event Signature Support for Generic Signal Types

[g4titanx]

currently, the escrow contract only validates only Transfer(address,address,uint256) events. This limits the protocol to proving token transfers and prevents extending Mirage to other use cases. Of course this is by design. but this support seems like a "nice to have"

we allow executors to specify the event signature they want to prove when posting their bond, making the escrow contract a generic event-proving system

this was suggested by @ozwaldorf while we were having a conversation in this direction

[EmperorOrokuSaki]

@ozwaldorf & @g4titanx this is definitely were we want to go in the next version. there are security concerns though, you need to be mindful of that. non-erc20 contracts can act unexpectedly and there could be many scenarios in which the node executes the tx but fails to collect the collateral because that event was actually not emitted (mev people have been dealing with this for a long time, check https://github.com/Defi-Cartel/salmonella)

[ozwaldorf]

@EmperorOrokuSaki: contracts can act unexpectedly and there could be many scenarios in which the node executes the tx but fails to collect the collateral because that event was actually not emitted

The interesting part though, is that node runners are only going to load or opt into the contracts they want to by loading collateral ahead of time. We could make a system of verified contracts we recommend nodes to get and fund tokens or other assets as a baseline.

Also consider maybe in the signal, like the contract address, we could have another cleartext field for the escrow type that nodes can filter signals they're interested in by. So for example an incoming signal for USDC would be like:

Signal { 
  type: "Token",
  contract: "0x...",
  puzzle, 
  encrypted, 
}

And nodes can opt into supporting the signal type and contract by loading usdc onto the eoas

[EmperorOrokuSaki]

@claude wdyt