I agree that caller is too generic, and that it will need specialized logic in order to receive an authorized batch of calls. Being less abstract will make the spec much clearer. Call it Branch? Remote? Open to ideas.
It feels like the conversation is starting to gain focus- so I want to take a step back and reframe what we’re talking about.
Recap
The proposal lifecycle can be boiled down into three steps:
- Proposal is created
- Proposal is voted on
- If passed, proposal is executed
This thread has touched on all three of these steps, but we have the most common ground in the third: proposal execution. Most protocols will need to coordinate and execute state changes across multiple chains. That’s a given.
In fact, this is exactly what the Toby has written up in the Uniswap Universal Governance Module. They want to remote control contracts.
The Uniswap RFC says that they are evaluating different vendors. In all likelihood these vendors have different interfaces: the resulting module will be proprietary.
It seems like we all agree that cross-chain execution is the biggest and most common pain point: so how about we start there? I would love to be able to swap different bridges: for example start with a native bridge then swap out for Nomad or another solution (or straight to Nomad 
)
You used a word in the Governance Router that I thought captured it well: remote. We’re talking about “Remote Execution”.
Standard for Remote Execution
It seems that we all want a standard for Remote Execution. This is really ground zero for multi-chain system: executing cross-chain calls. The standard should be comprehensive enough to be useful, but small enough to be easy to implement.
What should the goals of the standard be? Perhaps:
- Make it easy to trace protocol execution across multiple chains, regardless of transport layer.
- Make it easy to swap out transport layer
Tracing would be easy to do, as we really just need to standardize events, like we’ve been talking about.
Being able to swap out the remote execution puts more constraints on the implementation, but would be incredibly useful.
Using your language, imagine we had two contracts:
- Router: send execution batches to remotes
- Remote: receives batches and executes
The spec could define that:
- remotes are keyed on (chainid, address)
- events are emitted to help with tracing
- a Router function sends batches
- a Remote function checks batch status
Thoughts? I feel like we’re starting to gain some clarity here!