How to Create a Paloma Improvement Proposal or PIP

What is a PIP?

Paloma Improvement Proposals or PIPs are proposals to update some function or standard within the Paloma Ecosystem. PIPs can vary widely from proposing new community initiatives to requesting funds from the community pool to changing consensus parameters. The PIP process follows the same behavior as the Cosmos Governance process.

This is a high-level overview of a PIP lifecycle:

  1. Informal discussion & sentiment check on the Paloma Discord or Governance Forum.
  2. Formal Proposal (PIP template) on the Paloma Governance Forum
  3. Proposer changes status from “Draft” to “Proposed”
  4. PIP Proposer submits Proposal on-chain to start Deposit Period
  5. Voting Period begins
  6. Implementation by the parties involved with the improvement
  • > PIP How-to


The PIP process is not just about fulfilling Paloma’s functional duties. A streamlined and accessible PIP process can help cultivate a community that values open collaboration and ensure contributions are recognized and given a clear path to success.


1. Discord & Forum

This is the initial fielding research + discussion on Discord or the governance forum. This is an informal process to gauge community interest in a potential Paloma Governance Proposal.

Here are some questions a proposer might want to answer:

  • Am I able to informally get any traction for this proposal in Discord?
  • Has this proposal been tried before?
  • How does this proposal get the community closer to achieving its stated goals?
  • What trade-offs are implicit in this improvement’s adoption?

2. Create a PIP

Once a contributor feels they have a rough consensus that their PIP is valuable, original, and achievable, they should submit a Paloma Improvements Proposal on the Paloma governance forum.

The contributor should make sure that his proposal adheres to the basic PIP guidelines. He should also tag a Governance Forum Moderator, so a SIP number can be assigned, and a corresponding discord channel for discussions can be created.

4. Discussion and Proposal state

The forum is the formal area to debate the merits of each PIP. While the PIP is on the forum in ‘Draft’ state, the PIP author is free to make changes to the proposal.

The proposal should be up for at least 3 days on the governance forum, before moving to an onchain vote.

Once the PIP author is satisfied with the proposal, they should change the proposal status from ‘Draft’ to ‘Proposed’, and schedule a deposit.

5. Deposit and Voting period

Foundation Support for Proposal Deposits

The Paloma Foundation from time to time may find it helpful or necessary to distribute the minimum GRAINS for voting deposit to proposals that have merit and have engagement from the community. As such, any proposal DRAFT may include a request for the proposal deposit via the inclusion of the following:

“Dear Paloma Foundation. If you are interested in the community taking this proposal and conversation to an on-chain vote, please send a signal with 10 GRAINS tokens at this Cosmos address [paloma1XXXXX].”

Deposit Period

All PIPs are confirmed or rejected by the Palomas via Paloma Governance Vote. Prior to a governance proposal entering the voting period (ie. for the proposal to be voted upon), there must be at least a minimum number of GRAIN deposited (10). The deposit period lasts either 14 days or until the proposal deposit totals 10 GRAINs, whichever happens first.

Voting Period

The PIP has a voting period of 14 days where token holders may vote YES, NO, ABSTAIN or NO-WITH-VETO. Voters may change their vote at any time before the voting period ends.

6. Post Voting Process

What determines whether or not a governance proposal passes?

There are four criteria:

  1. A minimum deposit of 10 GRAIN is required for the proposal to enter the voting period
    • anyone may contribute to this deposit
    • the deposit must be reached within 14 days (this is the deposit period)
  2. A minimum of 40% of the network’s voting power (quorum) is required to participate to make the proposal valid
  3. A simple majority (greater than 50%) of the participating voting power must back the ‘yes’ vote during the 14-day voting period
  4. Less than 33.4% of participating voting power votes ‘no-with-veto’

The criteria for submitting and passing/failing all proposal types is the same.

If a proposal has passed, the PIP is moved from proposed to approved. If a proposal is rejected the PIP may be moved to be Rejected or back to Draft to be revised for future consideration.

8. Implementation

In the early stages of Paloma, approved PIPs will be executed via multisig where necessary. Otherwise, implementation of the PIP will vary on a case-by-case basis.

  • > PIP Template

This is the suggested template for new PIPs. Note that a PIP number will be assigned by a Moderator.


Status: [Draft, Proposed]

Author(s): [a list of author(s) names, usernames]

Type: [Community Pool Spend, Parameter Change, Text]

Discussions-to: [Create a new thread on and drop the link here]

Created: [date created on]

Simple Summary

“If you can’t explain it simply, you don’t understand it well enough.” Simply describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member. ‌

Abstract ‌

A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what will be done if the PIP is implemented, not why it should be done or how it will be done. If the PIP proposes changing consensus parameters, write, “we propose a change of consensus parameters X to do Y instead of Z”.

Motivation ‌

This is the problem statement. This is the reason for the PIP. It should clearly explain why the current state of the protocol is inadequate. It is critical that you explain why the change is needed. If the PIP proposes changing how something is calculated, you must address why the current calculation is inaccurate or wrong. This is not the place to describe how the PIP will address the issue!

Specification ‌Overview ‌

This is a high-level overview of how the PIP will solve the problem. The overview should clearly describe how the new feature will be implemented. ‌

Technical Specification ‌

The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces of the Paloma Protocol currently expose or the creation of new ones. ‌

Rationale ‌

This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, and what were the considerations and trade-offs? The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during the discussion.

To learn more about Paloma, please visit

To follow the project on Github, please star the project

To participate in the community, please join the Paloma Discord:

About Paloma

Paloma Protocol is a Cosmos-SDK blockchain protocol custom-built for omnichain communication that allows permissionless controls of any contract on any chain. Built by Volume, Paloma delivers the world’s first intelligently scheduled and automated smart contract transaction execution for the Cosmos ecosystem. The protocol enables developers to remotely control the transmission of value without the need to wrap, bridge tokens, or trust validators with their digital assets. Led by founding members of Sommelier, Paloma is building the primary communication layer of Web3.

1 Like