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 gets 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 rather than a copy that can fall behind.
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.
Once 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 supporting 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. Talk the idea over with the community before you write it, so you can gauge 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 and 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 and follow the section structure described in SIP format. Keep the title under 64 characters and don’t end it 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, keeping the proposal moving is your job. An editor will help you find the right people to talk to, but won’t chase the process for you.