Skip to content

Protocol version ​

OSx tracks two different versions:

  • Protocol version — which version of the OSx protocol a contract was built against (e.g. [1, 4, 0]). Reported by protocolVersion(), defined here.
  • Plugin release/build — which version of a specific plugin an install is, tracked by PluginRepo as release.build. Unrelated to the protocol version.

protocolVersion() ​

Contracts across the protocol (every plugin, every plugin setup, the DAO, registries) mix in ProtocolVersion and expose:

solidity
function protocolVersion() external view returns (uint8[3] memory); // e.g. [1, 4, 0]

This makes the protocol version discoverable onchain for tooling and compatibility checks. ProtocolVersion is intentionally stateless (pure, zero storage): the source warns not to add storage variables to it, so it can be safely mixed into any inheritance chain, upgradeable or not, without disturbing storage layout or needing its own __gap.

VersionComparisonLib provides lexicographic comparisons (eq, lt, gte, …) over the uint8[3] triple for code that gates on protocol version.

Why versioning discipline matters ​

The DAO's initializeFrom uses the protocol version to decide which storage migrations to run on upgrade, and refuses to cross a major version. More broadly, every upgradeable contract in OSx follows the same storage-safety discipline (reserved __gap slots, renamed-not-removed fields) so that a new implementation never corrupts an existing proxy's storage. See proxies and choosing a plugin base.

See also ​