George Knee

The direction I would like us to take on this is to: * move as much of the complexity as possible into pure functions which live in regular `.go` files...

We would probably want to streamline the process of **removing** a chain, in fact an entire superchain, from the registry. This could be done with new `add-chain` (now called `ops`)...

The problem is rather that we aren't validating all chains in all the cases that we should be. We are being _too_ eager to skip validation on all chains. On...

I think we already threw this pretty open so that any chain can opt in. Unless there are additional changes to docs / readme, then we can probably close this...

Maintaining our CI config "diff bots" has also proven to be more work than anticipated, and this change would likely remove the need for those diff bots.

There are some docs here https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/hardfork-activation-inheritance.md

This aligns with the approach of simplifying things like we plan to with #715. We should also see the `SuperchainConfig` appear in the codegen'ed `addreses.json` file.

Related problem that we should clear up: https://github.com/ethereum-optimism/superchain-registry/blob/ad6f08a52802ec7a55bb4a91d57937551504885c/superchain/configs/mainnet/superchain.toml#L3 is actually the adderess of the **proxy** so the name should reflect that.

@teddyknox check out https://github.com/ethereum-optimism/specs/pull/778 for a few more pointers.

> Since only one objective can own a ledger at a time things blow up. Do you mean, only one objective can own a _virtual_ channel at a time? As...