Rollup Operator Control Planes
This note narrows control-surfaces, routing-and-defaults, and permissions-and-policy to rollup stacks, managed chain operators, proving paths, and chain-brand defaults. The point is to keep the read on who actually keeps the thing live, not on every downstream app or stack cousin.
Questions worth asking:
- Who actually keeps the chain live: sequencer, prover, gateway, bridge operator, or managed vendor?
- Which defaults are inherited from the stack steward or hosted operator?
- Where do proof mode, bridge packaging, or fallback execution become the real control surface?
Canonical comparison set
- Stack steward and canonical-default case: optimism-labs
- Governance and emergency-admin counterpart inside the same stack: optimism-foundation
- Distribution-heavy inherited operator stack: base
- Managed rollup operator wrapper: caldera
- Gateway or proof-path chokepoints: based-op and op-succinct
- Underlying issuer / bridge rail when the chain brand is not the real settlement authority: cctp
Useful traversal questions
- Did the chain choose its own control plane, or inherit one from a vendor, foundation-admin lane, or stack steward?
- Is the key default bridge, proof path, gateway, or operator package being treated as if it were just
the chain? - When the visible chain brand fails, who still decides the fallback and who is still allowed to publish the answer?