- [`try-runtime::follow-chain`](https://paritytech.github.io/substrate/master/try_runtime_cli/enum.Command.html#variant.FollowChain) allows you to follow a chain's finalized blocks and apply the same extrinsics on top of a new WASM runtime. Indeed, because the `:CODE:` is different, and won't expect the state root check to pass in these blocks. 

This is mainly to ensure that the the transactions of alive chain execute successfully on top of a new runtime. 

Moreover, as of , you can add new auxiliary checks to each pallet (in [`try_state` hook](https://paritytech.github.io/substrate/master/frame_support/traits/trait.Hooks.html#method.try_state)) that are executed only when you execute `try-runtime::follow-chain`. These could be checks that ensure your state is consistent, and all of its assumptions are hold. 

So, in other words, you don't do the state root check, because you are using a new runtime, but you could optionally execute more additional checks.

---

`fork-of-substrate` only downloads the state of a chain, and creates a new dev network that uses that state as its genesis. Its purpose is to ensure that block production continues on top of that state. **These blocks are all empty.** They won't be equivalent to the real chain of choice anymore. 

Mixing these two concepts in the docs are in my opinion not a good idea and they are not that related. 


> Opinionated: I actually think `fork-of-substrate` does **not** provide that much meaningful information. Block production is mainly a function of the client side code, and putting a live chain's state on top of a `--dev` client is not a variable that can actually affect block production that much.