This document goes beyond the training rollkit rollup documentation provided by Celestia, and guides you through how to fork a production chain, rollkit it, and actually run it, fully configuring it from core to backend and frontend.

This methodology can be applied to other chains as well, in this example we forked Crescent-Network.

#Understanding Rollkit version selection

The first thing you need to do is check the COSMOS-SDK version dependency of the chain you're deploying.

https://github.com/crescent-network/crescent/blob/release/v4.0.x/go.mod#L264

github.com/cosmos/cosmos-sdk => github.com/crescent-network/cosmos-sdk v1.1.4-sdk-0.45.10

In the case of Crescent, we are using a customized cosmos-sdk, but the base version is 0.45.10, so we will adopt version 0.45.10 of the Rollkit SDK to proceed, but first we need to check which modules are actually affected by the customized sdk.

[<https://github.com/crescent-network/cosmos-sdk/commit/cd29fbbc80a769b757b4f4a88457084d24fccc3b>](<https://github.com/crescent-network/cosmos-sdk/commit/cd29fbbc80a769b757b4f4a88457084d24fccc3b>)

Untitled

If you look at the above commit, you can see that we are customizing the default modules of Cosmos, which can cause problems when building with the actual Rollkit.

In the case of Rollkit-cosmos-sdk, it was created by forking the base version, so if you have customized the default configuration of the base module, it is not actually compatible with Rollkit. There are two ways to solve this problem.

  1. Rebase your rollkit on the forked Crescent, look for errors, and remove the customized logic.