Introducing the Celestia Improvement Proposal Process

The Celestia Foundation is pleased to announce the Celestia Improvement Proposal (CIP) Process. The CIP process aims to coordinate technical proposals in the Celestia community to help improve the network across the modular stack, including core protocol upgrades.

A vital aspect of the trust-minimisation that Celestia strives for is that no majority of dishonest parties can arbitrarily change or violate protocol rules. This means that unlike most Cosmos chains, core protocol upgrades in Celestia are ultimately not governed by token voting or validators, but by the off-chain social layer, similar to Ethereum. On-chain governance on Celestia is limited to certain protocol parameters, and can be overridden or updated with upgrades by the off-chain social layer.

As stated in the CIP-1 draft that describes the CIP process, the rationale and explanation of the CIP process is as follows:

A CIP is a design document providing information to the Celestia community, or describing a new feature for Celestia or its processes or environment. The CIP should provide a concise technical specification of the feature and a rationale for the feature.

We intend CIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Celestia.

For Celestia software clients and core devs, CIPs are a convenient way to track the progress of their implementation.

Following in the footsteps of other standardization processes, starting with the standards body found in the Internet Engineering Task Force (IETF) all the way to the Ethereum Improvement Proposal (EIP) process, the CIP process rests on the shoulders of giants, taking inspiration to create a process for decentralized specification and core development around the Celestia protocol.

CIPs will apply across Celestia's stack, including the consensus and data availability layers, the peer-to-peer layer, and the interface layer that dictates how rollups communicate with Celestia. There will also be a process for Celestia Request for Comments proposals (CRCs), which will take the same place as the ERC section in Ethereum’s EIP process (think ERC-20 and ERC-721 specifications). Because Celestia doesn’t have a smart contract environment, the CRC section will focus around interesting design specifications on proposals that don’t impact the Celestia core protocol directly, just like ERCs in Ethereum. For example, a CRC proposal could be made to standardize Celestia’s namespaces.

With that said, the Celestia Foundation is excited to announce the following core developer teams as some of the earliest participants in the CIP process, focusing on different layers of the modular stack. However, all stakeholders are invited to participate in the CIP process, as that will result in the best technical decision-making for Celestia’s users and ecosystem:

For next steps, the first Core Dev Call will be hosted after Mainnet launch to align on the CIP-1 draft proposal, and if consensus emerges around the proposal, then the process will kickstart from there. The meeting will be recorded and notes will be shared with the community after the call.

The CIP process will help push forward the design space of the modular stack and lead to powerful, permissionless collaboration between distributed core development teams. The Celestia community is excited to begin this journey with the modular ecosystem.