Sei Improvement Proposals

Browse every Sei Improvement Proposal (SIP) with status, type, authorship, and section outlines pulled live from the sei-protocol/sips repository.

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.

Type	Scope	Needs consensus
Standard	Changes that affect most implementations of Sei, such as consensus, networking, RPC, EVM and CosmWasm behavior, and contract standards. Must also declare a category.	Yes
Process	Changes around Sei rather than inside it, such as developer tooling, node and validator procedures, and the SIP process itself.	Yes
Informational	Guidelines or information for the community, with no change to the protocol or development environment.	No

Categories

A Standard SIP must also declare one of five categories.

Category	Covers
Core	Consensus, execution, storage, and account signatures
Networking	Mempool and network protocols
Interface	RPC specifications and lower-level naming conventions
Framework	EVM and CosmWasm contracts and primitives included in the Sei codebase
Application	New EVM or CosmWasm standards and primitives that sit outside the Sei codebase

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.

Status	What it means
Idea	Written, but not yet admitted to the process and not yet numbered.
Draft	An editor has accepted the formatting and assigned a number. The author now gathers community feedback.
Review	The author has worked through early feedback. Assigned reviewers now give a formal review, and it takes at least three of them.
Fast Track	For proposals that already reached consensus outside the SIP process. Runs the same way as Review.
Last Call	A final window for objections, usually at least one week.
Final	Accepted, and the specification is now frozen.
Implemented	Development is complete, but the feature is not yet live on mainnet.
Activated	Live on Sei mainnet.
Stagnant	Inactive for four weeks while in Draft, Review, or Last Call.
Withdrawn	The author has withdrawn the proposal.
Living	A continuously updated proposal that never reaches Final, such as SIP-1 itself.

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

Move assets off Cosmos-native addresses and IBC tokens before Sei becomes EVM-only.

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.