Skip to main content

​
Versioning

PressChain has several version domains, and they should not be treated as one global number. The active protocol major is V3. Individual contracts can still carry names such as CapsuleRevisionsRegistryV1. The HTTP API currently uses /v1/. Capsule metadata has schema presschain.capsule.metadata.v1. PressKey has its own extension release version. Those numbers describe different compatibility boundaries.

​
Protocol major

Current platform authority declares v3 as the active major and prevents a new major from being introduced before the mainnet launch and stability review gate. Application configuration should make protocol major explicit:
Do not infer protocol major from an individual contract filename.

​
Contract version

A contract domain can evolve at a different pace from the overall protocol. Current source, for example, includes V3 evidence and contributor registries while other Capsule registries retain V1 names. A deployment manifest should record the exact contract implementation associated with each address.

​
API version

/v1/ describes an HTTP compatibility contract, not blockchain V1. The API can expose current V3 data while preserving a stable V1 response shape. Breaking response changes should create a new API version or explicit migration rather than silently changing existing client meaning.

​
Metadata schema version

presschain.capsule.metadata.v1 identifies the canonical serialization rules used to produce a metadata commitment. Changing canonicalization can change the hash, so schema version is part of verification, not decorative metadata. A consumer must verify with the rules for the declared schema.

​
Model version

Broader data envelopes such as Trust Object also have their own version. Parsers should adapt or reject incompatible versions explicitly.

​
PressKey version

PressKey extension releases evolve independently. The currently inspected implementation is version 4.11.0. Applications should feature-detect provider behavior where practical instead of assuming every installed extension updates immediately.

​
Compatibility matrix

​
Upgrade rule

Never perform an upgrade by changing one address constant in one frontend and hoping the rest of the system follows. A controlled upgrade updates authority, deployment manifest, ABI set, indexer configuration, API projection, Explorer semantics, application clients and documentation as one compatibility event. That discipline prevents partial upgrades from producing technically valid but semantically inconsistent records.