diff --git a/versioned_docs/version-0.12/private-state-manager/_category_.yml b/versioned_docs/version-0.12/private-state-manager/_category_.yml
new file mode 100644
index 0000000..ff51d11
--- /dev/null
+++ b/versioned_docs/version-0.12/private-state-manager/_category_.yml
@@ -0,0 +1,4 @@
+label: "Private State Manager"
+# Determines where this documentation section appears relative to other sections on the main documentation page (which is the parent of this folder in the miden-docs repository)
+position: 9
+collapsed: true
\ No newline at end of file
diff --git a/versioned_docs/version-0.12/private-state-manager/api-reference.md b/versioned_docs/version-0.12/private-state-manager/api-reference.md
new file mode 100644
index 0000000..f1c2a4f
--- /dev/null
+++ b/versioned_docs/version-0.12/private-state-manager/api-reference.md
@@ -0,0 +1,34 @@
+---
+title: API Reference
+sidebar_position: 3
+---
+
+This page summarizes the HTTP/gRPC APIs provided by the **Private State Manager**. The semantics match across transports. 
+
+## Authentication
+PSM authorizes requests through the headers (HTTP) or metadata (gRPC):
+- `x-pubkey`: Commitment to the public key of the signer.
+- `x-signature`: Signature over the request payload. 
+
+## HTTP endpoints
+- `POST /configure`: create account with auth policy and initial state, returns PSM acknowledgement public key.
+- `POST /delta`: push a delta, server verifies, signs `new_commitment`, sets status (candidate or canonical).
+- `GET /delta?account_id&nonce`: fetch delta by nonce.
+- `GET /delta/since?account_id&from_nonce`: merged canonical snapshot since a nonce.
+- `GET /state?account_id`: latest state.
+- `POST /delta/proposal`: create pending proposal (tx summary + optional sigs), returns proposal commitment.
+- `GET /delta/proposal?account_id`: list pending proposals.
+- `PUT /delta/proposal`: append cosigner signature to a pending proposal.
+- `GET /pubkey`: returns PSM acknowledgement public key for verifying `ack_sig`.
+
+## gRPC
+Mirrors HTTP (same auth headers in metadata).
+
+> Please refer to the [API specification](https://github.com/OpenZeppelin/private-state-manager/blob/main/spec/api.md) for more details.
+
+## Rust client
+
+The Rust client provides a wrapper around the HTTP API. Please refer to the [Rust client documentation](https://github.com/OpenZeppelin/private-state-manager/blob/main/crates/client/README.md) for more details.
+
+## Web client
+The Web client provides a Typescrip wrapper around the HTTP API. Please refer to the [Web client documentation](https://github.com/OpenZeppelin/private-state-manager/blob/main/packages/psm-client/README.md) for more details.
diff --git a/versioned_docs/version-0.12/private-state-manager/index.md b/versioned_docs/version-0.12/private-state-manager/index.md
new file mode 100644
index 0000000..0b513e5
--- /dev/null
+++ b/versioned_docs/version-0.12/private-state-manager/index.md
@@ -0,0 +1,8 @@
+# Private State Manager
+
+Miden’s execution model requires clients to manage their own private state (accounts, notes, etc.) when working with privacy. While this design provides scalability and privacy benefits, it also introduces challenges for usability and security. Losing any part of the account state means losing access to the account itself, which creates the following risks:
+
+- Solo-account users risk losing access if the state is not backed up.
+- Shared-accounts users risk losing access by having a stale state due to a faulty or malicious participant withholding the state.
+
+To address these challenges, Miden introduces the Private State Manager (PSM). The PSM is a system that allows clients to backup and sync their state securely without trust assumptions about other participants or the server operator.
diff --git a/versioned_docs/version-0.12/private-state-manager/multisig.md b/versioned_docs/version-0.12/private-state-manager/multisig.md
new file mode 100644
index 0000000..600823a
--- /dev/null
+++ b/versioned_docs/version-0.12/private-state-manager/multisig.md
@@ -0,0 +1,17 @@
+---
+title: Multisig
+sidebar_position: 2
+---
+
+Miden multisig accounts store their commitment on-chain, but their state (storage, code, vault, etc.) is kept private. Then the PSM acts as a coordination server, for keeping the state and transactions in sync between the participants.
+
+## Flow
+1) **Propose**: push delta/proposal including a `TransactionSummary` and optional proposer signature.
+2) **Sign**: cosigners fetch pending proposals, verify details locally, and append their signatures.
+3) **Ready**: once threshold is met, fetch proposal and build the final transaction advice map using all cosigner signatures + the PSM acknowledgement.
+4) **Execute**: push the final transaction advice map and submit on-chain, verifying the PSM acknowledgement.
+5) **Sync**: the clients can fetch the latest account state at any time from the server.
+
+## Links
+- [Rust multisig client](https://github.com/OpenZeppelin/private-state-manager/tree/main/crates/miden-multisig-client)
+- [TypeScript multisig client](https://github.com/OpenZeppelin/private-state-manager/tree/main/packages/miden-multisig-client)
diff --git a/versioned_docs/version-0.12/private-state-manager/operator-guide.md b/versioned_docs/version-0.12/private-state-manager/operator-guide.md
new file mode 100644
index 0000000..f16cabb
--- /dev/null
+++ b/versioned_docs/version-0.12/private-state-manager/operator-guide.md
@@ -0,0 +1,45 @@
+---
+title: Operator Guide
+sidebar_position: 4
+---
+
+This guide summarizes how to run and observe a PSM node.
+
+## Prerequisites
+- Rust toolchain (version 1.90.0 or greater).
+- Docker client.
+
+## Clone the repository
+- Clone the repository: `git clone https://github.com/OpenZeppelin/private-state-manager.git`
+- Build the server: `cargo build --release --bin server`
+
+## Run using docker compose
+- Docker compose: copy `.env.example` to `.env`.
+- set paths
+- run: `docker-compose up --build -d`
+- view logs: `docker-compose logs -f`
+- stop services: `docker-compose down`
+
+## Configuration
+- `PSM_STORAGE_PATH`: storage backend path (states/deltas)
+- `PSM_METADATA_PATH`: metadata store path
+- `PSM_KEYSTORE_PATH`: server key store (ack key)
+- `PSM_ENV`: `dev` by default
+- `RUST_LOG`: e.g. `info`, `debug`, or module-specific (`server::jobs::canonicalization=debug`)
+
+## Ports
+- HTTP: `:3000`
+- gRPC: `:50051`
+
+## Canonicalization
+- **Candidate mode (default)**: background worker promotes/discards after delay and network verification.
+- **Optimistic mode**: deltas become canonical immediately.
+- **Defaults**: delay 15m, check interval 60s (configurable).
+
+## Troubleshooting
+- Verify ack key via `GET /pubkey` matches what clients expect.
+- Ensure storage and metadata paths are writable and consistent.
+
+## Links
+- Repository: https://github.com/OpenZeppelin/private-state-manager
+- Server README: [crates/server/README.md](https://github.com/OpenZeppelin/private-state-manager/blob/main/crates/server/README.md)
\ No newline at end of file
diff --git a/versioned_docs/version-0.12/private-state-manager/overview.md b/versioned_docs/version-0.12/private-state-manager/overview.md
new file mode 100644
index 0000000..04045db
--- /dev/null
+++ b/versioned_docs/version-0.12/private-state-manager/overview.md
@@ -0,0 +1,43 @@
+---
+title: Overview
+sidebar_position: 1
+---
+
+Private State Manager (PSM) lets Miden accounts (single or multisig) keep their private state backed up, synchronized, and verifiable without trusting a server operator.
+
+## Core concepts
+- Account State: canonical snapshot of an account (ID, commitment, nonce, vault, storage, etc).
+- Account Delta: append-only change that transitions the account; includes a `TransactionSummary` plus metadata.
+
+## Account management
+Accounts are configured with per-account authentication based on public keys (commitments), during setup, the PSM records which keys are authorized to manage the account. 
+
+For each request, the client signs a payload with one of those keys and the server verifies the signature against the account’s authorized keys.
+
+PSM stores states, deltas, and proposals so clients can sync and verify over time.
+
+## End-to-end flow
+1) Configure account: set auth keys and initial account state (account ID, storage, vault, etc.).
+2) When sending a transaction on-chain:
+- a) client builds a `TransactionSummary` and sends it to the server.
+- b) the server validates the transaction against the current state and returns an acknowledgement (signature over the transaction summary commitment).
+- c) client executes the transaction, optionally passing the acknowledgement as advice.
+- d) the on-chain component verifies the user signature and optionally the PSM acknowledgement, then executes the transaction.
+3) State sync: the clients can fetch the account state at any time from the server.
+
+## Common use cases
+- **Single-user accounts**: a single user can use the PSM to backup and sync their state securely. In case their device is lost, they can recover their state from the PSM.
+- **Multi-user accounts**: a multi-user account can use the PSM to backup and sync their state securely. The PSM helps to coordinate the state and transactions between the participants.
+
+## Canonicalization
+Canonicalization is the process of validating that certain state transition (delta) is valid against the on-chain commitment. It is optional and mainly used in multi-user setups.
+
+It consists of a state machine that tracks the status of the delta:
+- **Candidate**: a transaction is accepted and stored but not yet confirmed against the on-chain commitment.
+- **Canonical**: after some pre-defined window of time, the transaction is confirmed against the on-chain commitment and becomes the source of truth.
+
+## Transaction Proposals
+
+In cases where a transaction requires more than one signature, the PSM can be used to distribute a transaction proposal (delta), and coordinate the signatures between the participants.
+
+Once the threshold is met, any participant can execute the transaction. From there, the transaction will follow the same validation path to become canonical.