Skip to main content
This page is for proposers who want an on-chain record of a community decision without executing anything, and for voters reading one. It assumes the process on Submitting a proposal. A text proposal is a MsgSubmitProposal with an empty messages list. When it passes, no code runs.

​
What signaling proposals are used for

A signaling proposal records a decision that no on-chain message can execute. The Hub has used it for five kinds of decision:
  • Agreement to adopt, or not adopt, a feature before the work is funded or built (proposals 7, 31, 38, 49, 69).
  • An alert to validators that needs a formal record (proposal 8).
  • A poll of community opinion (proposal 12, on whether zero commission validators harm the Hub).
  • Ratifying a social norm (proposal 75, which set the meaning of NoWithVeto that Governance process describes).
  • Directing funds that are not in the community pool, where the executing party acts on the vote (proposal 1058).
In the Hub’s first years text was the only type. Early proposals therefore changed parameters (proposal 10) and scheduled upgrades (proposal 19) by signal, with developers applying the change afterwards. Those cases now use the executable types. A text proposal for something a message could do is a signal that the proposer did not want to be bound.

​
Why signal

A signaling proposal is a public poll with the Hub’s full voting weight behind it. It confirms interest before a team spends months on a feature. It leaves a record that newcomers find in any explorer, which forum threads and repositories do not. It is also the way to put a norm on record so that later proposals can cite it.

​
What passing does

Nothing on chain. The value is in the discussion and the recorded outcome: the community has considered the question, the proposer knows how a follow-up will be received, and later executable proposals can point to the result. The unenforceable nature is the standard criticism of the type. It is also the reason a passed text proposal is a weak basis for committing anyone else’s resources.

​
Write one that is useful

A signaling proposal only works if the question is precise. “Should the Hub support X” produces a vote that both sides read as agreement with their version of X. State what Yes commits the community to, what No means, who will act on a Yes and by when, and what the follow-up proposal (executable, usually) will contain. Put the full argument in the pinned metadata. Keep the on-chain summary to the question and the commitment. Text proposals pay the same 500 ATOM deposit and face the same veto rule as any other. Spam text proposals are the main reason NoWithVeto exists. A signal that reads as advertising, or that was not discussed on the forum first, therefore loses its deposit. The forum template for the type is About the signaling category.

​
Proposal JSON

The gaiad tx gov draft-proposal command with the text type writes this shape:
Older tooling produces a legacy form, /cosmos.gov.v1.MsgExecLegacyContent wrapping a /cosmos.gov.v1beta1.TextProposal with the gov account as authority (proposal 1010 is one). The Hub accepts both. The empty messages form is the current one and is what explorers expect. Submit with:

​
Verify

The messages field is [] for a text proposal. After the vote, status is PROPOSAL_STATUS_PASSED or PROPOSAL_STATUS_REJECTED. Nothing else on the chain has changed, which gaiad q upgrade plan (still empty) and the relevant params queries confirm.

​
Next