Thesettlementlayerforthemachineeconomy.

Network

Change parameters by on-chain vote

Governance proposals, parameters and pause

Proposals move Paxeer X parameters; LayerX keys carry bounds, activation epochs and pause records

You submit a software-upgrade or parameter-change proposal through the Cosmos governance module, including consensus timeouts, and two scripted flows print one vote command per bonded validator, wait for the tally and confirm the applied value. Inside the LayerX agent domain, each parameter key carries a minimum, a maximum, a target module and a version history, so a proposal outside those bounds is refused. Pause a module, a market or the network and cancellation still works.

What it does

Paxeer X uses the Cosmos governance module for on-chain proposals: software upgrades and parameter changes, including the consensus timeouts held by the params module in the baseapp subspace under the TimeoutParams key. Two scripted flows in platform/hosted/paxeer/ submit a proposal, print one vote command per bonded validator operator, wait for the tally and confirm the applied value. Inside the LayerX agent domain, governance writes to a parameter table where every key has a minimum and a maximum, a target module, an activation epoch and a version history. The same domain holds pause records at module, market and network scope, each recorded with its trigger and its exit conditions.

Key capabilities

  • Software-upgrade and parameter-change proposals with standard or expedited voting.
  • Consensus timeout changes submitted as a TimeoutParams param-change proposal.
  • Bounded LayerX parameters: per-key minimum, maximum, target module, versioned history.
  • Staged rollout of a parameter change to all, a module, a market or an account set.
  • Pause and resume at module, market or network scope, with recorded exit conditions.
  • Cancellation and exit paths stay open while a scope is paused.

Who it's for

PAX holders and validator operators who vote, and node operators who run the scripted proposal flows.

Why it matters

Parameter changes and halts go through the same vote, tally and confirm path as any other proposal, so the change is visible before it applies and auditable afterwards. In the agent domain, a proposal outside a parameter's declared bounds is refused rather than applied, and a paused scope still lets users cancel and exit.

Differentiators

Governance in the LayerX kernel cannot request a balance write, mint, burn, receipt or batch rewrite, state-root substitution or finalized-history reassignment: a non-zero effect mask is refused with LXP_ERR_AUTH_SCOPE (src/modules/governance/lxp_emergency.c:173, asserted in tests/test_governance_emergency.c:14). Pauses always permit the cancellation or exit path (lxp_pause_scope_check), and the parameter table hashes into a state root that includes the resolved value of every key for a given cohort and epoch (lxp_gov_parameter_state_root).

Outcomes

  • Every change is visible before it applies and auditable afterwards
  • A proposal outside a key's declared bounds is refused
  • A paused scope still lets users cancel and exit

Technical notes

  • Live chain governance values: max_deposit_period 172800 s, voting_period 172800 s, expedited_voting_period 86400 s, quorum 0.334, threshold 0.5, veto threshold 0.334, expedited quorum and threshold 0.667 each. Quorum is measured against bonded voting power. The expedited minimum deposit is twice the standard one.
  • A param change applies in the block that ends its voting period, so gov-consensus-params.sh refuses (exit 2) when voting would end after a target halt time, and names the expedited path when only that one still fits. Nothing is broadcast without --execute; the dry run writes the proposal JSON and prints every command. Proposal cancellation needs its own voting period, so inside 48 hours of a halt the expedited path is the only one that fits.
  • platform/hosted/paxeer/tests/gov-scripts-test.sh replays the flow against recorded fixtures and asserts the proposal file, the deposits, the expedited flag and the refusal cases; --execute is rejected under fixture replay.
  • LayerX kernel limits: 64 parameters, parameter keys up to 64 bytes, 32 history entries per key, 256 parameter versions, 64 proposals, 32 cohort members per proposal, 64 pause records, 128 emergency events, module ids 1 to 255. Rollout scopes are all, module, market and account set. Refusals are LXP_ERR_PARAMETER_BOUNDS (-734) and LXP_ERR_PAUSED_SCOPE (-735).
  • Kernel governance changes are ordinary activities with the same envelope, authority, ordering and receipt rules as any other; halt, resume and module enable each require an ordered governance activity with a strictly incrementing sequence, and there is no operator path outside the log. Sequencer handover is activity 0x00070009.
  • Not yet in place: the parameter keys are supplied by the host, so the repo holds no named key set for registry, slashing or attestation parameters; contracts/governance/LayerXBetaTimelock.sol:29 is pinned to chain 125 and its constructor rejects any non-zero minimum delay, so execution is immediate by construction; all CosmWasm governance proposal types are enabled and code upload is permissionless in node/app.go; the consensus-timeout script takes benchmarked timeout values but no benchmark result is committed to justify a specific one.

More in Network

Build on Paxeer.

Give your agent a wallet, set its policy, and settle your first call on LayerX.