Text (Signaling)

A Text proposal is the only proposal type the gov module itself understands natively. It carries no executable payload and triggers no automatic on-chain change when it passes. Its only effect is a permanent, publicly-votable record of what the community decided, which is exactly why it's useful: it turns an opinion that would otherwise live in a Telegram thread into something durable, attributable, and binding in the sense that it can be pointed back to later.

What Are Signaling Proposals Currently Used For?

On AIOZ Network, a Text proposal is the right tool whenever you want a binding read on community sentiment before committing engineering or treasury effort to something: a direction for a future upgrade, a policy the team should follow, or an off-chain commitment (e.g. a partnership or roadmap priority) that has no natural on-chain parameter to attach to. It's also the right tool when a decision genuinely has no technical payload at all, there's no subspace/key to change, no funds to move, no binary to schedule, just a direction the network wants to commit to.

A useful way to think about it: if you can express what you want as a Parameter Change, Community Pool Spend, or Software Upgrade, use that type instead, since it actually executes the outcome rather than just recording an intent. Text is what's left over for everything that can't be expressed as a concrete on-chain action.

A Note on Historical Text Proposals

Because a Text proposal has no payload, its entire value comes from how precisely it's worded. A vague signaling proposal ("should AIOZ do more marketing?") produces a result that's hard to act on even if it passes overwhelmingly: a Yes vote on a vague premise doesn't tell you which marketing, how much, or paid for by whom. Write it the way you'd write a decision you intend to hold the team accountable to later, specific enough that a Yes result gives someone a clear mandate to act on, and specific enough that a No result tells you exactly what to reconsider.

Since no Text proposal exists yet on AIOZ mainnet, there's no established local convention to point to for how detailed a good one should be. Until that changes, looking at how AIOZ's own Parameter Change proposals are worded (see Parameter Changes) is the closest available reference for the level of specificity validators expect from any proposal, payload or not.

Why Make a Signaling Proposal?

• To establish that the community supports a direction before a team commits resources to building it, so the work doesn't start on the strength of one person's judgment alone
• To record a policy decision that doesn't map to any single module parameter, something about process, priorities, or values rather than a number in the chain's state
• To settle a genuine disagreement with a vote instead of continued back-and-forth in chat, where the same argument can otherwise repeat indefinitely without a clear resolution

What Happens When a Signaling Proposal Passes?

Nothing changes automatically on-chain. Passing only means the required quorum was reached and Yes cleared the threshold under On-Chain Proposal Process. Turning that mandate into action (a follow-up Parameter Change or Software Upgrade proposal, a treasury decision, a public commitment) is on the proposer and the team, not the gov module. This is easy to underestimate: a passed Text proposal can feel like a decision has been made, but nothing enforces the follow-through except the same community pressure that got it passed in the first place.

The same is true in reverse. A Text proposal that fails or is vetoed doesn't block anyone from acting anyway, there's no on-chain mechanism preventing it. What it does is make doing so, against a recorded community vote, a much harder position to defend publicly.

Submitting a Text Proposal

aiozd tx gov submit-legacy-proposal \
  --title="<title>" \
  --description="<description>" \
  --type="Text" \
  --deposit="1000000000000000000000attoaioz" \
  --from=<key> \
  --chain-id=<chain_id>

See Submitting a Proposal for the full walkthrough, including how to track the proposal once it's live, and Off-Chain Proposal Process for how to build support before you submit at all.