Governance, Notices, and Upgrades

Last reviewed: 2026-08-01

Governance

Lithosphere exposes Cosmos governance and EVM-compatible application surfaces. The internal operator process (GOVERNANCE_SOP.md) is not yet published to this site.

Public governance documentation should explain proposal discovery, deposit and voting periods, vote choices, transaction fees, explorer verification, and the distinction between protocol governance and off-chain operational ownership. Do not publish testnet proposal IDs or contract-owner addresses as Lithosphere governance references.

Network upgrades

Node operators must follow coordinated release notices before changing a binary. The internal operational process is documented in the upgrade runbook, change-management process, and rollback decision matrix, none of which are yet published to this site.

A public upgrade notice should include:

• affected network and chain IDs;
• release version, source tag, and binary checksums;
• upgrade height or UTC window;
• required operator actions and configuration changes;
• compatibility and API changes;
• rollback or halt conditions;
• status updates and final completion notice; and
• a security contact for reporting release problems.

Notices page

The client must designate the canonical public notice channel. Until then, the documentation site should not imply that a social-media or chat account is an authoritative release feed.

Recommended status labels are scheduled, in progress, completed, postponed, cancelled, and security advisory.

Report an issue

The public site needs two separate routes:

1. Documentation errors and ordinary developer-support questions.
2. Private security or vulnerability reports.

The client must approve the public support URL/email and the private security contact before publication. Users must be warned never to submit private keys, seed phrases, custody credentials, API secrets, or personally identifying account data.