This part is especially interesting to me:
Having accounts depend on each other as part of the UserOperation validation presents a serious challenge.
One framing I’ve been exploring is whether some of this pressure can be reduced by making the account’s lifecycle more explicitly phase-separated:
- validation phase: only bounded checks over account-owned / explicitly associated state
- execution phase: arbitrary cross-contract logic
- upgrade / module-change phase: isolated behind stricter repository / version controls
In other words, instead of trying to make validation itself expressive enough to depend on more external smart-account behavior, maybe the safer direction is to make validation intentionally narrow and move richer coordination into later phases with clearer boundaries.
Do you think ERC-7562 would benefit from more explicit guidance in that direction for modular / multi-module smart accounts?
For example: “cross-account or cross-module dependencies should be represented as execution-phase checks unless the depended-on component is promoted to a first-class staked entity.”
I’ve been thinking about this from the modular AA side here as well: