Injective Proposal 709 Puts Fixed Gas for Key Exchange Messages Before Mainnet Voters

Proposal 709 Reaches the Voting Stage

Injective's cost arrangement for its exchange operations is being handed to its token holders, and the destination is a fixed standard. Proposal 709, now live in the Injective (INJ) mainnet governance process, would apply fixed gas standards to certain transaction messages, and the on-chain vote record shows the proposal in its active voting stage. The message types it names are order submission and cancellation, along with deposits and withdrawals on the exchange module. Nothing takes effect while the tally is open: mainnet application depends on the vote's recorded outcome and the implementation steps that follow a pass.

The difference between proposed and applied is where this story actually sits. Some earlier reports described Injective as having already switched exchange trading to fixed gas costs, but the chain's record tells a narrower story: a governance proposal is circulating, governance token holders are being asked to approve it, and the vote is the step that decides whether the standard reaches the mainnet at all. The proposal text keeps the scope tight. It names specified message types on the exchange module rather than the whole transaction surface, and it does not propose to rewrite fee rates or total transaction costs across the network in a single motion.

For the network, the question is procedural as much as technical. Injective's governance process is the route through which a mainnet parameter of this kind changes, so the documents that matter are the proposal itself, the turnout and the eventual tally, not the commentary around them. As of the latest status check the proposal remained mid-vote with no recorded outcome. A pass would set the implementation calendar; a fail would close the file and leave the existing arrangement standing. Either way, the decision that binds the chain is the one written on-chain, and that record is still open.

What Fixed Gas Changes in the Exchange Module

What the proposal would rearrange is who sets the number. Gas is the computational resource a blockchain spends to process a transaction, and a fee is calculated from two inputs: how much gas the transaction consumed and the gas price attached to it. Under the current model the first input has to be estimated, usually by simulating the transaction before it is sent, so the eventual cost of an action stays an approximation until execution. Injective's official documentation describes a fixed gas mode that can be applied to certain messages in the exchange module, specifically some order submissions, order cancellations, deposits and withdrawals.

With a fixed basis in place, traders and dApp developers can set the gas budget for those messages in advance and work out transaction preparation and operating costs before they occur. The change would also remove part of the burden of running a simulation to estimate gas on every transaction. The documentation is explicit about the limits: messages the fixed list does not name may still see their gas usage vary, because their cost depends on the interactions they perform against chain state.

A fixed gas amount is not a fixed fee. Once the gas quantity is pinned down, the final fee still moves with the gas price, so the proposal does not turn exchange trading into flat-rate transactions. Nor does it touch fee rates generally. The exchange module sits at the center of this because activity on Injective's order book, and the Injective protocol's broader dApp surface beyond it, all route through those documented message types. That concentration is also why the proposal reads as an operations document: it targets the messages trading systems send most often, and the teams whose budgets depend on knowing what those messages cost.

Senders, Simulators and an Open Tally

Our reading is that the vote record now carries the entire decision. Quorum, turnout and the final tally decide whether the fixed basis lands, and until the voting period closes the chain keeps running the variable, simulation-based model it has always used. The practical stakes sit with high-frequency participants: a predefined gas budget turns the cost of every submitted and cancelled order from an estimate into an input, which is why the proposal touches the order-driven side of the network first, a change in the same operational vein as the multi-chain USDC payments expansion. Market levels are a separate file; our INJ technical analysis tracks where the token trades while the vote runs. If the tally closes in favor, senders hold the gas budget for the named messages; if not, the simulator keeps holding it.