Skip to main content
A Sei Improvement Proposal (SIP) is a design document for a change to Sei. It might cover a new protocol feature, a change to how the project runs, or a convention for the wider ecosystem. Writing one is how you put an idea in front of the community, and how the reasoning behind a decision is recorded. Every SIP lives in the sei-protocol/sips repository, and the list below reads from it directly. Titles, statuses, authors, and section outlines come from the source files, not from a copy that can become outdated.
A SIP is not the same as an on-chain governance proposal. The SIP holds the design and the reasoning. The on-chain proposal is the vote that enacts it. One SIP can take several governance proposals to carry out, as SIP-3 did. For the on-chain process, see Governance and Proposals.

​
All proposals

​
Proposal types

Every SIP declares a type, and the type decides how much community consensus it needs. SIP-1 defines all three.

​
Categories

A Standard SIP must also declare one of five categories.

​
Status lifecycle

A successful SIP usually moves through Draft, Review, Last Call, Final, Implemented, and Activated. Each card above shows the status recorded in that proposal’s own source file.
After a SIP reaches Final, nobody can withdraw or edit it. To change an accepted specification, submit a new SIP that extends or replaces the original.

​
Guides for specific proposals

SIP-3 and SIP-4 both affect how you use and build on Sei. These pages cover what they mean in practice.

SIP-3 migration guide

What SIP-3 changes for asset holders, and how to move off Cosmos-native addresses.

SIP-3 for exchanges

Integration changes for exchanges and custodians that support Sei deposits and withdrawals.

Gas and transaction fees

How Sei’s EIP-1559 implementation works, including the parameters SIP-4 revises.

Cosmos-SDK deprecation

Legacy Cosmos SDK and CosmWasm documentation, deprecated under SIP-3.

​
Submit a proposal

Anyone can author a SIP. Before you write one, discuss the idea with the community to find out whether the proposal is needed at all.
1

Read SIP-1

SIP-1 defines the process, the header fields your file needs, and what authors and editors are each responsible for.
2

Raise the idea with the community

Open a thread in GitHub Discussions to collect early feedback, especially from the people who would implement the change.
3

Fork the repository and add your file

Fork sei-protocol/sips. In your fork, create your proposal at sips/sip-temporary_title.md. Put any images in assets/sip-temporary_title/.
4

Match the required format

Start the file with the two-column header table. Follow the section structure described in SIP format. Keep the title under 64 characters. Do not end the title with a period.
5

Open a pull request

Submit the pull request from your fork. A SIP editor reviews the formatting, assigns a number, moves the status to Draft, and opens the official comments thread.
From Draft onward, you are responsible for keeping the proposal moving. An editor helps you find the right people to talk to, but does not push the process forward for you.