Governance
Ordered authority changes, versioned parameters, staged rollouts, and controlled settlement upgrades across Paxeer X.
Paxeer X governance operates across two boundaries: the Layer X activity log governs protocol execution, while Paxeer settlement contracts enforce their own authorized roles and delayed calls. A governance decision is evidence with an actor, scope, ordering position, and activation condition.
Governance in the activity log
Module 7 processes governance activities through the same envelope, authority, ordering, fee, and receipt rules as other activities. Identity creation, key rotation, recovery changes, session grants, revocation, and delegated capability issuance therefore remain part of replayable history.
| Activity | Purpose |
|---|---|
0x00070001 | Create or onboard an identity. |
0x00070002 | Announce, apply, or lapse primary-key rotation. |
0x00070003 | Update the recovery root and applicable recovery delays. |
0x00070005 | Grant session authority. |
0x00070006 | Revoke an existing grant with its sequence and reason. |
0x00070008 | Issue a delegated capability or budget allowance. |
0x00070009 | Authorize sequencer handover with its dedicated evidence format. |
Governance activity types are specific operations. Parameter proposals and emergency-state operations use the governance interfaces; applications must not manufacture an activity ordinal for a library operation. See Identity and authority for account delegation.
Parameter proposals and activation
A parameter entry binds a bounded value to a key and target module. A proposal records its identifier, proposed value, activation epoch, ordered sequence, rollout scope, cohort, and parameter version. Authorization and an ordered governance activity are required; a proposal respects the configured minimum activation delay.
Stage a rollout
| Scope | Application |
|---|---|
| All | Apply the change across the protocol. |
| Module | Target a module cohort. |
| Market | Target the selected markets. |
| Account set | Target a defined group of accounts. |
- Inspect the current value, allowed bounds, parameter version, and target scope.
- Prepare a proposal with an activation epoch beyond the minimum delay and a canonical cohort.
- Authorize and order the proposal; retain its activity receipt and proposal identifier.
- Apply activation at the first batch of the designated epoch.
- Verify the enacted value, version, and parameter-state root for the executing cohort.
For example, a market-specific parameter change records the market cohort and future epoch before execution begins using the new version. Replay selects the value for the execution epoch and cohort rather than reading an operator's current configuration.
Emergency controls
Governance records emergency halt and resume events with an ordered sequence. A pause identifies a module, market, or network scope, a trigger commitment, exit conditions, and entry epoch. Module enablement is also an ordered governance action. These interfaces require governance authorization and do not create an operator shortcut outside the log.
When responding to an incident, retain the triggering evidence, select the narrowest applicable scope, order the halt, and inspect the resulting emergency state. Resume against the recorded exit conditions through a subsequent ordered action. Applications continue to distinguish execution availability from the availability of existing receipts and proofs.
Settlement roles and timelocks
| Role | Authority |
|---|---|
| Proposer | Schedules an allowed target and function selector with a sufficient delay. |
| Executor | Executes the exact scheduled operation after readiness and before grace-period expiry. |
| Guardian | Cancels a pending, incomplete operation. |
| Timelock itself | Changes roles, minimum delay, and call permissions through authorized self-calls. |
The operation identifier commits to the chain, timelock address, target, value, calldata hash, salt, and nonce. Scheduling and execution both enforce call permissions and value limits. Completion prevents operation replay; target failure reverts execution. Read the deployed contract's minDelay, delayFloor, and gracePeriod rather than assuming one universal waiting period.
Upgrades respect component boundaries
Layer X settlement components expose their role, static configuration hash, release version, and storage-layout version. The component base disables UUPS upgrades. The Sidiora proxy governance timelock provides a separate constrained upgrade path for its proxy targets. A proxy upgrade therefore follows that target's governance contract, while protocol parameter changes follow their own versioned activity rules.
Before execution, compare the scheduled target, implementation, calldata, configuration commitments, and activation dependencies. After execution, retain the operation event and verify the target's resulting version and state.
Continue
Read Guarantors for membership and bonds, Security and trust boundaries for verification responsibilities, and Finality for checkpoint settlement.