> ## Documentation Index
> Fetch the complete documentation index at: https://docs.presschain.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning

> Keep protocol major, contract versions, API versions, model schemas and application releases distinct.

# 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:

```ts theme={null}
const environment = {
  network: "presschain-testnet",
  protocolMajor: "v3",
  chainId: 77117002,
};
```

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.

```json theme={null}
{
  "capsuleEvidenceRegistry": {
    "version": "v3",
    "address": "0x...",
    "deployedAtBlock": "..."
  }
}
```

## 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

| Layer            | Current documented value         | What it controls                |
| ---------------- | -------------------------------- | ------------------------------- |
| Protocol         | `v3`                             | canonical protocol semantics    |
| Network          | `presschain-testnet`             | active test environment         |
| Chain ID         | `77117002`                       | EVM network identity            |
| Capsule metadata | `presschain.capsule.metadata.v1` | canonical metadata bytes        |
| HTTP API         | `/v1/`                           | read API response compatibility |
| PressKey         | `4.11.0` inspected               | browser extension release       |

## 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.