Action required: IBC assets on Sei will become inaccessible If you hold USDC.n (USDC via Noble), USDT.kava (Kava USDT), Wormhole-bridged tokens, or any other IBC asset on Sei, you must swap, migrate, or bridge out before the governance proposal to disable inbound/outbound IBC transfers passes and is activated to avoid permanent loss of access. After this, Sei will no longer support IBC bridging of assets from Cosmos-based chains to and from Sei Network. Consult the SIP-03 Migration Guide for the full list of affected assets, required actions, and supported routes. For USDC.n specifically, see: Holders of USDC.n Need to Swap or Migrate.
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.
Changes that affect most implementations of Sei, such as consensus, networking, RPC, EVM and CosmWasm behavior, and contract standards. Must also declare a category.
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.
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.