-
Notifications
You must be signed in to change notification settings - Fork 13
[SPEC] Intent based architecture #607
Description
Overview
Intent based arch should relinquish any automated function of the relayer (specifically relaying and processing AUPs)
-
Relayers don’t make money submitting the AUP.
-
Why would they relay the AUP?
Maybe they make money from the private transaction relaying to justify submitting the AUP.
Goal
Goal is identify a path for the users to effectively pay for the AUP processing if needed to submit their private tx.
User Flow 1
-
User deposits on Chain A,
-
relayers should catch this and submit to SigningRules contract
-
The relayers DON'T relay the result just yet. The results are onchain (need to figure for how long, if they disappear that could be bad)
-
User wants to withdraw their funds from Chain B, but the AUP hasn’t been applied to Chain B
-
User should pay for the update + the relayed private tx by encoding a higher fee in the private tx relay.
Perhaps we update the contract so you can submit AUPs w/ relayed txes.
Example: 0.1 ETH per tx, so AUP processing costs 0.1 ETH, private tx relay costs 0.1 ETH. The relayer wants to make 5%. So they user should say something like “Here’s my proof for my private against Chain A’s merkle root M and a fee of 0.04 ETH”
Relayer says “Here’s a request to update Chain B’s roots and submit a private tx and earn enough for my liking”
Relayer needs to decide
Note: One main issue with this is if that the user commits to a proof before that AUP has been applied, enabling someone else to submit a different AUP causing their proof to be invalid, at which they’ll need to re-prove their thing.
Task Checklist
Metadata
Metadata
Assignees
Labels
Type
Projects
Status