-```
-
-More information on the various `cargo install` options can be found
-[here](https://doc.rust-lang.org/cargo/commands/cargo-install.html#install-options).
-
-## Updating
-
-:::warning
-We currently have no backwards compatibility guarantees. This means updating your node is destructive - your
-existing chain will not work with the new version. This will change as our protocol and database schema mature and
-settle.
-:::
-
-Updating the node to a new version is as simple as re-running the install process and repeating the [bootstrapping](./usage#bootstrapping) instructions.
diff --git a/docs/external/src/operator/monitoring.md b/docs/external/src/operator/monitoring.md
deleted file mode 100644
index 64327e443f..0000000000
--- a/docs/external/src/operator/monitoring.md
+++ /dev/null
@@ -1,281 +0,0 @@
----
-title: "Monitoring"
-sidebar_position: 5
----
-
-# Monitoring & telemetry
-
-We provide logging to `stdout` and an optional [OpenTelemetry](https://opentelemetry.io/) exporter for our traces.
-
-OpenTelemetry exporting can be enabled by specifying `--enable-otel` via the command-line or the
-`MIDEN_NODE_ENABLE_OTEL` environment variable when operating the node.
-
-We do _not_ export OpenTelemetry logs or metrics. Our end goal is to derive these based off of our tracing information.
-This approach is known as [wide-events](https://isburmistrov.substack.com/p/all-you-need-is-wide-events-not-metrics),
-[structured logs](https://newrelic.com/blog/how-to-relic/structured-logging), and
-[Observability 2.0](https://www.honeycomb.io/blog/time-to-version-observability-signs-point-to-yes).
-
-What we're exporting are `traces` which consist of `spans` (covering a period of time), and `events` (something happened
-at a specific instance in time). These are extremely useful to debug distributed systems - even though `miden` is still
-centralized, the `node` components are distributed.
-
-OpenTelemetry provides a
-[Span Metrics Converter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/spanmetricsconnector)
-which can be used to convert our traces into more conventional metrics.
-
-## What gets traced
-
-We assign a unique trace (aka root span) to each RPC request, batch build, and block build process.
-
-
-
-Span and attribute naming is unstable and should not be relied upon. This also means changes here will not be considered
-breaking, however we will do our best to document them.
-
-
-
-### RPC request/response
-
-Not yet implemented.
-
-### Block building
-
-This trace covers the building, proving and submission of a block.
-
-
- Span tree
-
-```sh
-block_builder.build_block
-┝━ block_builder.select_block
-│ ┝━ mempool.lock
-│ ┕━ mempool.select_block
-┝━ block_builder.get_block_inputs
-│ ┝━ block_builder.summarize_batches
-│ ┕━ store.state.get_block_inputs
-│ ┝━ select_note_inclusion_proofs
-│ ┕━ select_block_headers
-┝━ block_builder.prove_block
-│ ┝━ execute_program
-│ ┕━ block_builder.simulate_proving
-┝━ block_builder.inject_failure
-┕━ block_builder.commit_block
- ┝━ store.state.apply_block_with_proving_inputs
- │ ┕━ apply_block
- │ ┝━ select_block_header_by_block_num
- │ ┕━ update_in_memory_structs
- ┝━ mempool.lock
- ┕━ mempool.commit_block
- ┕━ mempool.revert_expired_transactions
- ┕━ mempool.revert_transactions
-```
-
-
-
-### Batch building
-
-This trace covers the building and proving of a batch.
-
-
- Span tree
-
-```sh
-batch_builder.build_batch
-┝━ batch_builder.wait_for_available_worker
-┝━ batch_builder.select_batch
-│ ┝━ mempool.lock
-│ ┕━ mempool.select_batch
-┝━ batch_builder.get_batch_inputs
-│ ┕━ store.state.get_batch_inputs
-┝━ batch_builder.propose_batch
-┝━ batch_builder.prove_batch
-┝━ batch_builder.inject_failure
-┕━ batch_builder.commit_batch
- ┝━ mempool.lock
- ┕━ mempool.commit_batch
-```
-
-
-
-## Verbosity
-
-We log important spans and events at `info` level or higher, which is also the default log level.
-
-Changing this level should rarely be required - let us know if you're missing information that should be at `info`.
-
-The available log levels are `trace`, `debug`, `info` (default), `warn`, `error` which can be configured using the
-`RUST_LOG` environment variable e.g.
-
-```sh
-export RUST_LOG=debug
-```
-
-The verbosity can also be specified by component:
-
-```sh
-export RUST_LOG=warn,block-producer=debug,rpc=error
-```
-
-The above would set the general level to `warn`, and the `block-producer` and `rpc` components would be overridden to
-`debug` and `error` respectively. Though as mentioned, it should be unusual to do this.
-
-## Configuration
-
-The OpenTelemetry trace exporter is enabled by adding the `--enable-otel` flag to each component's start command:
-
-```sh
-miden-node store start --enable-otel
-miden-node block-producer start --enable-otel
-miden-node rpc start --enable-otel
-```
-
-The exporter can be configured using environment variables as specified in the official
-[documents](https://opentelemetry.io/docs/specs/otel/protocol/exporter/).
-
-
-Not all options are fully supported. We are limited to what the Rust OpenTelemetry implementation supports. If you have any problems please open an issue and we'll do our best to resolve it.
-
-Note: we only support gRPC as the export protocol.
-
-
-
-#### Example: Honeycomb configuration
-
-This is based off Honeycomb's OpenTelemetry
-[setup guide](https://docs.honeycomb.io/send-data/opentelemetry/#using-the-honeycomb-opentelemetry-endpoint).
-
-```sh
-OTEL_EXPORTER_OTLP_ENDPOINT=https://api.honeycomb.io:443 \
-OTEL_EXPORTER_OTLP_HEADERS="x-honeycomb-team=your-api-key" \
-miden-node store start --enable-otel
-```
-
-### Honeycomb queries, triggers and board examples
-
-#### Example Queries
-
-Here are some useful Honeycomb queries to help monitor your Miden node:
-
-**Block building performance**:
-
-```honeycomb
-VISUALIZE
-HEATMAP(duration_ms) AVG(duration_ms)
-WHERE
-name = "block_builder.build_block"
-GROUP BY block.number
-ORDER BY block.number DESC
-LIMIT 100
-```
-
-**Batch processing latency**:
-
-```honeycomb
-VISUALIZE
-HEATMAP(duration_ms) AVG(duration_ms) P95(duration_ms)
-WHERE
-name = "batch_builder.build_batch"
-GROUP BY batch.id
-LIMIT 100
-```
-
-**Block proving failures**:
-
-```honeycomb
-VISUALIZE
-COUNT
-WHERE
-name = "block_builder.build_block"
-AND status = "error"
-CALCULATE RATE
-```
-
-**Transaction volume by block**:
-
-```honeycomb
-VISUALIZE
-MAX(transactions.count)
-WHERE
-name = "block_builder.build_block"
-GROUP BY block.number
-ORDER BY block.number DESC
-LIMIT 100
-```
-
-**RPC request rate by endpoint**:
-
-```honeycomb
-VISUALIZE
-COUNT
-WHERE
-name contains "rpc"
-GROUP BY name
-```
-
-**RPC latency by endpoint**:
-
-```honeycomb
-VISUALIZE
-AVG(duration_ms) P95(duration_ms)
-WHERE
-name contains "rpc"
-GROUP BY name
-```
-
-**RPC errors by status code**:
-
-```honeycomb
-VISUALIZE
-COUNT
-WHERE
-name contains "rpc"
-GROUP BY status_code
-```
-
-#### Example Triggers
-
-Create triggers in Honeycomb to alert you when important thresholds are crossed:
-
-**Slow block building**:
-
-- Query:
-
-```honeycomb
-VISUALIZE
-AVG(duration_ms)
-WHERE
-name = "block_builder.build_block"
-```
-
-- Trigger condition: `AVG(duration_ms) > 30000` (adjust based on your expected block time)
-- Description: Alert when blocks take too long to build (more than 30 seconds on average)
-
-**High failure rate**:
-
-- Query:
-
-```honeycomb
-VISUALIZE
-COUNT
-WHERE
-name = "block_builder.build_block" AND error = true
-```
-
-- Trigger condition: `COUNT > 100 WHERE error = true`
-- Description: Alert when more than 100 block builds are failing
-
-#### Advanced investigation with BubbleUp
-
-To identify the root cause of performance issues or errors, use Honeycomb's BubbleUp feature:
-
-1. Create a query for a specific issue (e.g., high latency for block building)
-2. Click on a specific high-latency point in the visualization
-3. Use BubbleUp to see which attributes differ significantly between normal and slow operations
-4. Inspect the related spans in the trace to pinpoint the exact step causing problems
-
-This approach helps identify patterns like:
-
-- Which types of transactions are causing slow blocks
-- Which specific operations within block/batch processing take the most time
-- Correlations between resource usage and performance
-- Common patterns in error cases
diff --git a/docs/external/src/operator/usage.md b/docs/external/src/operator/usage.md
deleted file mode 100644
index 2167c88bab..0000000000
--- a/docs/external/src/operator/usage.md
+++ /dev/null
@@ -1,259 +0,0 @@
----
-sidebar_position: 4
----
-
-# Configuration and Usage
-
-As outlined in the [Architecture](./architecture) chapter, the node consists of several components which are run
-as separate processes. The recommended way to operate a node locally is using `docker compose`, which starts each
-component in its own container and automatically bootstraps on first run. Operating the components without Docker
-is also straightforward using the individual CLI subcommands.
-
-This guide focuses on basic usage. To discover more advanced options we recommend exploring the various help menus
-which can be accessed by appending `--help` to any of the commands.
-
-## Bootstrapping
-
-The first step in starting a new Miden network is to initialize the genesis block data. This is a
-two-step process: first the validator signs and creates the genesis block, then the store initializes
-its database from that block. By default the genesis block will contain a single faucet account.
-
-```sh
-# Step 1: Validator bootstrap — create the signed genesis block and account files.
-miden-validator bootstrap \
- --genesis-block-directory genesis-data \
- --accounts-directory accounts
-
-# Step 2: Node bootstrap — initialize the node database from the genesis block.
-miden-node bootstrap \
- --data-directory store-data \
- --file genesis-data/genesis.dat
-```
-
-You can also configure the account and asset data in the genesis block by passing in a toml configuration file.
-This is particularly useful for setting up test scenarios without requiring multiple rounds of
-transactions to achieve the desired state. Any account secrets will be written to disk inside the
-provided `--accounts-directory` path in the process.
-
-```sh
-miden-validator bootstrap \
- --genesis-block-directory genesis-data \
- --accounts-directory accounts \
- --genesis-config-file genesis.toml
-```
-
-The genesis configuration file should contain fee parameters, optionally a custom native faucet,
-optionally other fungible faucets, and also optionally, wallet definitions with assets, for example:
-
-```toml
-# The UNIX timestamp of the genesis block. It will influence the hash of the genesis block.
-timestamp = 1717344256
-# Defines the format of the block protocol to use for the genesis block.
-version = 1
-
-# The native faucet defaults to a MIDEN token (symbol="MIDEN", decimals=6,
-# max_supply=100_000_000_000_000_000). To override it with a pre-built account
-# file, specify the path:
-#
-# native_faucet = "path/to/faucet.mac"
-#
-# The path is relative to this configuration file.
-
-# The fee parameters to use for the genesis block.
-[fee_parameters]
-verification_base_fee = 0
-
-# Another fungible faucet (optional) to initialize at genesis.
-[[fungible_faucet]]
-# The token symbol to use for the token
-symbol = "FUZZY"
-# Number of decimals your token will have, it effectively defines the fixed point accuracy.
-decimals = 6
-# Total supply, in _base units_
-#
-# e.g. a max supply of `1e15` _base units_ and decimals set to `6`, will yield you a total supply
-# of `1e15/1e6 = 1e9` `FUZZY`s.
-max_supply = 1_000_000_000_000_000
-# Account type of the faucet account.
-account_type = "public"
-
-
-[[wallet]]
-# List of all assets the account should hold. Each token type _must_ have a corresponding faucet.
-# The number is in _base units_, e.g. specifying `999 FUZZY` at 6 decimals would become
-# `999_000_000`.
-assets = [{ amount = 999_000_000, symbol = "FUZZY" }]
-# Account type of the wallet account.
-account_type = "private"
-```
-
-To include pre-built accounts (e.g. bridge or wrapped-asset faucets) in the genesis block, use
-`[[account]]` entries with paths to `.mac` files:
-
-```toml
-[[account]]
-path = "bridge.mac"
-
-[[account]]
-path = "eth_faucet.mac"
-```
-
-## Operation
-
-### Using docker compose
-
-Build the Docker image and start the node. Bootstrap happens automatically on first run.
-The default `compose-up` target starts all node components along with a telemetry stack
-([Tempo](https://grafana.com/oss/tempo/) + [Grafana](https://grafana.com/oss/grafana/)) and
-a network monitor:
-
-```sh
-make docker-build
-make docker-build-monitor
-make compose-genesis
-make compose-up
-```
-
-This starts:
-
-- All node components (store, validator, block-producer, rpc, ntx-builder) with OpenTelemetry tracing enabled
-- **Tempo** — receives OTLP traces from the node on port `4317`, HTTP API on port `3200`
-- **Grafana** — pre-configured with a Tempo datasource and a Miden Node dashboard, available at `http://localhost:3000`
-- **Network monitor** — monitors the local node, available at `http://localhost:3001`
-
-Follow logs:
-
-```sh
-make compose-logs
-```
-
-Stop the node:
-
-```sh
-make compose-down
-```
-
-Teardown and regenesis:
-
-```sh
-make compose-genesis
-```
-
-### Running components individually
-
-A convenience script is provided that bootstraps and starts all components as separate processes:
-
-```sh
-./scripts/run-node.sh
-```
-
-To avoid genesis and simply restart from a previous run:
-
-```sh
-SKIP_BOOTSTRAP=true scripts/run-node.sh
-```
-
-Each component can also be started as a standalone process. For example:
-
-```sh
-# Start the store
-miden-node store start \
- --rpc.listen 0.0.0.0:50001 \
- --block-producer.listen 0.0.0.0:50003 \
- --data-directory /tmp/store
-
-# Start the validator
-miden-validator start --listen 0.0.0.0:50101 \
- --data-directory /tmp/validator
-
-# Start the block producer
-miden-node block-producer start --listen 0.0.0.0:50201 \
- --store.url http://127.0.0.1:50003 \
- --validator.url http://127.0.0.1:50101
-
-# Start the RPC server
-miden-node rpc start \
- --listen 0.0.0.0:57291 \
- --store.url http://127.0.0.1:50001 \
- --block-producer.url http://127.0.0.1:50201 \
- --validator.url http://127.0.0.1:50101
-
-# Start the network transaction builder
-miden-node ntx-builder start \
- --listen 0.0.0.0:50301 \
- --store.url http://127.0.0.1:50001 \
- --block-producer.url http://127.0.0.1:50201 \
- --validator.url http://127.0.0.1:50101 \
- --data-directory /tmp/ntx-builder
-```
-
-### SQLite pools
-
-The store, validator, and network transaction builder use SQLite connection pools for database
-queries. By default, each pool size is twice the number of available CPU cores. Override it with
-`--sqlite.connection_pool_size` or the component-specific environment variable:
-
-- `MIDEN_NODE_STORE_SQLITE_CONNECTION_POOL_SIZE`
-- `MIDEN_NODE_VALIDATOR_SQLITE_CONNECTION_POOL_SIZE`
-- `MIDEN_NODE_NTX_BUILDER_SQLITE_CONNECTION_POOL_SIZE`
-
-### gRPC server limits and timeouts
-
-The RPC component enforces per-request timeouts, per-IP rate limits, and global concurrency caps. Configure these
-settings with the following options:
-
-- `--grpc.timeout` (default `10s`): Maximum request duration before the server drops the request.
-- `--grpc.max_connection_age` (default `30m`): Maximum lifetime of a connection before the server closes it.
-- `--grpc.burst_size` (default `128`): Per-IP burst capacity before rate limiting kicks in.
-- `--grpc.replenish_per_sec` (default `16`): Per-IP request credits replenished per second.
-- `--grpc.max_global_connections` (default `1000`): Maximum concurrent gRPC connections across all clients.
-
-## Systemd
-
-Our [Debian packages](./installation.md#debian-package) install a systemd service which operates the node in `bundled`
-mode. You'll still need to run the [bootstrapping](#bootstrapping) process before the node can be started.
-
-You can inspect the service file with `systemctl cat miden-node` or alternatively you can see it in
-our repository in the `packaging` folder. For the bootstrapping process be sure to specify the data-directory as
-expected by the systemd file.
-
-## RocksDB tuning
-
-The store uses RocksDB for the account and nullifier trees, one instance each. The two most impactful knobs per tree
-are exposed as CLI flags (also available as environment variables):
-
-| Flag | Default | Notes |
-|---|---|---|
-| `--account_tree.rocksdb.max_cache_size` | 2 GiB | Shared LRU block cache. Increase on memory-rich hosts. |
-| `--account_tree.rocksdb.max_open_fds` | 64 | Raise to 512+ when `ulimit -n` allows. |
-| `--nullifier_tree.rocksdb.max_cache_size` | 2 GiB | Same as above for the nullifier tree. |
-| `--nullifier_tree.rocksdb.max_open_fds` | 64 | Same as above for the nullifier tree. |
-
-Compaction parallelism is set automatically to the number of available CPU cores.
-
-```sh
-miden-node store start \
- --data-directory data \
- --rpc.listen 0.0.0.0:57291 \
- --account_tree.rocksdb.max_cache_size 4294967296 \
- --account_tree.rocksdb.max_open_fds 512 \
- --nullifier_tree.rocksdb.max_cache_size 4294967296 \
- --nullifier_tree.rocksdb.max_open_fds 512
-```
-
-## Environment variables
-
-Most configuration options can also be configured using environment variables as an alternative to providing the values
-via the command-line. This is useful for certain deployment options like `docker`, where they can be easier
-to define or inject instead of changing the underlying command line options.
-
-These are especially convenient where multiple different configuration profiles are used. Write the environment
-variables to some specific `profile.env` file and load it as part of the node command:
-
-```sh
-source profile.env && miden-node <...>
-```
-
-This works well on Linux and MacOS, but Windows requires some additional scripting unfortunately.
-
-See the `.env` files in each of the binary crates' [directories](https://github.com/0xMiden/node/tree/next/bin) for a list of all available environment variables.
diff --git a/docs/external/src/operator/versioning.md b/docs/external/src/operator/versioning.md
deleted file mode 100644
index d3d6bad943..0000000000
--- a/docs/external/src/operator/versioning.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-sidebar_position: 6
----
-
-# Versioning
-
-We follow the [semver](https://semver.org/) standard for versioning.
-
-The following is considered the node's public API, and will therefore be considered as breaking changes.
-
-- RPC gRPC specification (note that this _excludes_ internal inter-component gRPC schemas).
-- Node configuration options.
-- Large protocol and behavioral changes.
-
-We intend to include our OpenTelemetry trace specification in this once it stabilizes.
-
-We _will_ also call out non-breaking behavioral changes in our changelog and release notes.
diff --git a/docs/external/src/rpc.md b/docs/external/src/rpc.md
deleted file mode 100644
index c530bd96f2..0000000000
--- a/docs/external/src/rpc.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: "Node gRPC Reference"
-sidebar_position: 1
----
-
-# gRPC Reference
-
-This is a reference of the Node's public RPC interface. It consists of a gRPC API which may be used to submit transactions and query the state of the blockchain.
-
-The gRPC service definition can be found in the Miden node's `proto` [directory](https://github.com/0xMiden/node/tree/main/proto) in the `rpc.proto` file.
-
-
-
-- [GetAccount](#getaccount)
-- [GetBlockByNumber](#getblockbynumber)
-- [GetBlockHeaderByNumber](#getblockheaderbynumber)
-- [GetLimits](#getlimits)
-- [GetNetworkNoteStatus](#getnetworknotestatus)
-- [GetNotesById](#getnotesbyid)
-- [GetNoteScriptByRoot](#getnotescriptbyroot)
-- [BlockSubscription](#blocksubscription)
-- [ProofSubscription](#proofsubscription)
-- [Status](#status)
-- [SubmitProvenTx](#submitproventx)
-- [SyncAccountStorageMaps](#syncaccountstoragemaps)
-- [SyncAccountVault](#syncaccountvault)
-- [SyncChainMmr](#syncchainmmr)
-- [SyncNotes](#syncnotes)
-- [SyncNullifiers](#syncnullifiers)
-- [SyncTransactions](#synctransactions)
-
-
-
-## API Endpoints
-
-### GetAccount
-
-Request an account witness (Merkle proof of inclusion in the account tree) and optionally account details.
-
-The witness proves the account's state commitment in the account tree. If details are requested, the response also includes the account's header, code, vault assets, and storage data. Account details are only available for public accounts.
-
-If `block_num` is provided, returns the state at that historical block; otherwise, returns the latest state.
-
-#### Error Codes
-
-When the request fails, detailed error information is provided through gRPC status details. The following error codes may be returned:
-
-| Error Code | Value | gRPC Status | Description |
-|---------------------------|-------|--------------------|------------------------------------------------------|
-| `INTERNAL_ERROR` | 0 | `INTERNAL` | Internal server error occurred |
-| `DESERIALIZATION_FAILED` | 1 | `INVALID_ARGUMENT` | Request could not be deserialized |
-| `ACCOUNT_NOT_FOUND` | 2 | `INVALID_ARGUMENT` | Account not found at the requested block |
-| `ACCOUNT_NOT_PUBLIC` | 3 | `INVALID_ARGUMENT` | Account details requested for a non-public account |
-| `UNKNOWN_BLOCK` | 4 | `INVALID_ARGUMENT` | Requested block number is unknown |
-| `BLOCK_PRUNED` | 5 | `INVALID_ARGUMENT` | Requested block has been pruned |
-
-### GetBlockByNumber
-
-Request the raw data for a specific block.
-
-### GetBlockHeaderByNumber
-
-Request a specific block header and its inclusion proof.
-
-### GetLimits
-
-Returns the query parameter limits configured for RPC endpoints.
-
-This endpoint allows clients to discover the maximum number of items that can be requested in a single call for various endpoints. The response contains a map of endpoint names to their parameter limits.
-
-**Example response structure:**
-
-```json
-{
- "endpoints": {
- "SyncNullifiers": { "parameters": { "nullifier": 1000 } },
- "SyncTransactions": { "parameters": { "account_id": 1000 } },
- "SyncAccountVault": { "parameters": { "account_id": 1000 } },
- "SyncAccountStorageMaps": { "parameters": { "account_id": 1000 } },
- "SyncNotes": { "parameters": { "note_tag": 1000 } },
- "GetNotesById": { "parameters": { "note_id": 100 } }
- }
-}
-```
-
-### GetNotesById
-
-Request a set of notes.
-
-**Limits:** `note_id` (100)
-
-### GetNetworkNoteStatus
-
-Returns the current lifecycle status of a network note. The status indicates where the note is in its lifecycle: pending execution, processed (consumed by a transaction in the mempool), or discarded after too many failed attempts. The response also includes the latest execution error, if any.
-
-This endpoint is only available when the network transaction builder is enabled and connected. If it is not configured, the endpoint returns `UNAVAILABLE`.
-
-#### Request
-
-```protobuf
-message NoteId {
- Digest id = 1; // The note ID
-}
-```
-
-#### Response
-
-```protobuf
-enum NetworkNoteStatus {
- NETWORK_NOTE_STATUS_UNSPECIFIED = 0;
- NETWORK_NOTE_STATUS_PENDING = 1; // Awaiting execution or being retried
- NETWORK_NOTE_STATUS_NULLIFIER_INFLIGHT = 2; // Consumed by a transaction sent to block producer
- NETWORK_NOTE_STATUS_DISCARDED = 3; // Exceeded max retries, will not be retried
- NETWORK_NOTE_STATUS_NULLIFIER_COMMITTED = 4; // Consuming transaction committed on-chain
-}
-
-message GetNetworkNoteStatusResponse {
- NetworkNoteStatus status = 1; // Current lifecycle status
- optional string last_error = 2; // The latest error message, if any
- uint32 attempt_count = 3; // Number of failed execution attempts
- optional fixed32 last_attempt_block_num = 4; // Block number of the last failed attempt, if any
-}
-```
-
-If the note is not found in the network transaction builder's database, the endpoint returns `NOT_FOUND`.
-
-### GetNoteScriptByRoot
-
-Request the script for a note by its root.
-
-### BlockSubscription
-
-Streams committed blocks starting from `block_from` inclusive.
-
-Each stream item contains the serialized signed block and the committed chain tip observed when
-the item was emitted.
-
-### ProofSubscription
-
-Streams block proofs starting from `block_from` inclusive.
-
-Each stream item contains the block number, serialized block proof, and the proven chain tip
-observed when the item was emitted.
-
-### Status
-
-Request the status of the node components. The response contains the current version of the RPC component and the connection status of the other components, including their versions and the number of the most recent block in the chain (chain tip).
-
-### SubmitProvenTx
-
-Submit a transaction to the network.
-
-This endpoint accepts a proven transaction and attempts to add it to the mempool for inclusion in future blocks. The transaction must be properly formatted and include a valid execution proof.
-
-#### Error Codes
-
-When transaction submission fails, detailed error information is provided through gRPC status details. The following error codes may be returned:
-
-| Error Code | Value | gRPC Status | Description |
-|-----------------------------------------------|-------|--------------------|---------------------------------------------------------------|
-| `INTERNAL_ERROR` | 0 | `INTERNAL` | Internal server error occurred |
-| `DESERIALIZATION_FAILED` | 1 | `INVALID_ARGUMENT` | Transaction could not be deserialized |
-| `INVALID_TRANSACTION_PROOF` | 2 | `INVALID_ARGUMENT` | Transaction execution proof is invalid |
-| `INCORRECT_ACCOUNT_INITIAL_COMMITMENT` | 3 | `INVALID_ARGUMENT` | Account's initial state doesn't match current state |
-| `INPUT_NOTES_ALREADY_CONSUMED` | 4 | `INVALID_ARGUMENT` | Input notes have already been consumed by another transaction |
-| `UNAUTHENTICATED_NOTES_NOT_FOUND` | 5 | `INVALID_ARGUMENT` | Required unauthenticated notes were not found |
-| `OUTPUT_NOTES_ALREADY_EXIST` | 6 | `INVALID_ARGUMENT` | Output note IDs are already in use |
-| `TRANSACTION_EXPIRED` | 7 | `INVALID_ARGUMENT` | Transaction has exceeded its expiration block height |
-
-### SyncAccountStorageMaps
-
-Returns storage map synchronization data for a specified public account within a given block range. This method allows clients to efficiently sync the storage map state of an account by retrieving only the changes that occurred between two blocks.
-
-Caller specifies the `account_id` of the public account and the block range (`block_from`, `block_to`) for which to retrieve storage updates. The response includes all storage map key-value updates that occurred within that range, along with the last block included in the sync and the current chain tip.
-
-This endpoint enables clients to maintain an updated view of account storage.
-
-### SyncAccountVault
-
-Returns information that allows clients to sync asset values for specific public accounts within a block range.
-
-For any `[block_from..block_to]` range, the latest known set of assets is returned for the requested account ID. The data can be split and a cutoff block may be selected if there are too many assets to sync. The response contains the chain tip so that the caller knows when it has been reached.
-
-### SyncChainMmr
-
-Returns MMR delta information needed to synchronize the chain MMR within a block range.
-
-Caller specifies the `block_range`, starting from the last block already represented in its local MMR. The response contains the MMR delta for the requested range, but at most to (including) the chain tip.
-
-### SyncNotes
-
-Iteratively sync data for a given set of note tags.
-
-Client specifies the `note_tags` they are interested in, and the block range from which to search for matching notes. The request will then return the next block containing any note matching the provided tags within the specified range.
-
-The response includes each note's metadata and inclusion proof.
-
-A basic note sync can be implemented by repeatedly requesting the previous response's block until reaching the tip of the chain.
-
-**Limits:** `note_tag` (1000)
-
-### SyncNullifiers
-
-Returns nullifier synchronization data for a set of prefixes within a given block range. This method allows clients to efficiently track nullifier creation by retrieving only the nullifiers produced between two blocks.
-
-Caller specifies the `prefix_len` (currently only 16), the list of prefix values (`nullifiers`), and the block range (`block_from`, optional `block_to`). The response includes all matching nullifiers created within that range, the last block included in the response (`block_num`), and the current chain tip (`chain_tip`).
-
-If the response is chunked (i.e., `block_num < block_to`), continue by issuing another request with `block_from = block_num + 1` to retrieve subsequent updates.
-
-**Limits:** `nullifier` (1000)
-
-### SyncTransactions
-
-Returns transaction records for specific accounts within a block range.
-
-## Error Handling
-
-The Miden node uses standard gRPC error reporting mechanisms. When an RPC call fails, a `Status` object is returned containing:
-
-- **Status Code**: Standard gRPC status codes (`INVALID_ARGUMENT`, `INTERNAL`, etc.).
-- **Message**: Human-readable error description.
-- **Details**: Additional structured error information (when available).
-
-For critical operations like transaction submission, detailed error codes are provided in the `Status.details` field to help clients understand the specific failure reason and take appropriate action.
-
-### Error Details Format
-
-The `Status.details` field contains the specific error code serialized as raw bytes:
-
-- **Format**: Single byte containing the numeric error code value
-- **Decoding**: Read the first byte to get the error code
-- **Mapping**: Map the numeric value to the corresponding error enum
-
-**Example decoding** (pseudocode):
-
-```
-if status.details.length > 0:
- error_code = status.details[0] // Extract first byte
- switch error_code:
- case 1: return "INTERNAL_ERROR"
- case 2: return "DESERIALIZATION_FAILED"
- case 5: return "INPUT_NOTES_ALREADY_CONSUMED"
- // ... etc
-```
diff --git a/docs/external/src/rpc/_category_.yml b/docs/external/src/rpc/_category_.yml
new file mode 100644
index 0000000000..c260a9788b
--- /dev/null
+++ b/docs/external/src/rpc/_category_.yml
@@ -0,0 +1,3 @@
+label: "gRPC API"
+position: 3
+collapsed: false
diff --git a/docs/external/src/rpc/errors-and-limits.md b/docs/external/src/rpc/errors-and-limits.md
new file mode 100644
index 0000000000..12705d832e
--- /dev/null
+++ b/docs/external/src/rpc/errors-and-limits.md
@@ -0,0 +1,90 @@
+---
+title: "Errors and Limits"
+sidebar_position: 3
+---
+
+# Errors and Limits
+
+The Miden RPC API uses standard gRPC status codes. Individual methods may also return structured details defined by the
+protobuf schema or encoded by the server implementation.
+
+## Structured Error Details
+
+Some methods encode a method-specific error enum in addition to the conventional gRPC error code. This error enum is
+encoded in the gRPC status `details` field, allowing clients to branch on more detailed error conditions.
+
+When present, the detail payload contains the method-specific error code as a single raw byte. This byte can be
+interpreted as per the per-method tables below.
+
+```text
+if status.details is not empty:
+ error_code = status.details[0]
+ # Interpret error_code using the failed method's table.
+else:
+ # Fall back to the gRPC status code and message.
+```
+
+Only method-specific failures with documented additional codes set the details byte. Other validation errors, including
+malformed requests, unsupported content negotiation, missing genesis data, and failed proof checks, return ordinary gRPC
+statuses without a Miden error detail code. The error message remains applicable in all cases, but should be considered
+unstable and it is not recommended to match on it.
+
+If you are missing specific error information that could be useful, please open an issue in the
+[Node Repository](https://github.com/0xMiden/node).
+
+## Transaction Submission Errors
+
+`SubmitProvenTx` and `SubmitProvenTxBatch` may return the following detail codes when a transaction or batch reaches the
+sequencer's mempool and is rejected.
+
+| Error | Value | gRPC status | Meaning |
+| ------------------ | ----- | ------------------ | --------------------------- |
+| `Internal` | `0` | `INTERNAL` | Internal submission failure |
+| `Expired` | `1` | `INVALID_ARGUMENT` | Transaction expired |
+| `StateConflict` | `2` | `INVALID_ARGUMENT` | State conflict |
+| `CapacityExceeded` | `3` | `INVALID_ARGUMENT` | Mempool capacity exceeded |
+
+`Expired` means the transaction or batch has expired, or will expire too soon for the sequencer to consider accepting
+it.
+
+`StateConflict` is intentionally coarse. It can represent spent nullifiers, duplicate output notes, missing
+unauthenticated input notes, or an account initial commitment mismatch. Use the status message for the specific
+conflict, and use the detail byte when a client needs stable branching between broad submission failure classes.
+
+`CapacityExceeded` means the mempool capacity has been exhausted and is under load.
+
+## Request Limits
+
+Use `GetLimits` to discover method-specific request limits before sending large sync requests. Methods such as
+`SyncNotes`, `SyncNullifiers`, and `GetNotesById` may reject requests that exceed the configured limit. Split larger
+requests into smaller batches.
+
+The limits are returned in `json` format as follows:
+
+```json
+{
+ "endpoints": {
+ "CheckNullifiers": { "parameters": { "nullifier": 1000 } },
+ "SyncNullifiers": { "parameters": { "nullifier": 1000 } },
+ "SyncTransactions": { "parameters": { "account_id": 1000 } },
+ "SyncAccountVault": { "parameters": { "account_id": 1000 } },
+ "SyncAccountStorageMaps": { "parameters": { "account_id": 1000 } },
+ "SyncNotes": { "parameters": { "note_tag": 1000 } },
+ "GetNotesById": { "parameters": { "note_id": 100 } }
+ }
+}
+```
+
+## Content Negotiation
+
+The RPC server checks the `Accept` header for Miden-specific media parameters:
+
+```text
+application/vnd.miden; version=; genesis=
+```
+
+Both parameters are optional for read requests. Write requests, including `SubmitProvenTx` and `SubmitProvenTxBatch`,
+require the `genesis` parameter so the client explicitly targets the intended network.
+
+The server accepts compatible major/minor RPC versions. Stable versions allow patch flexibility. Pre-release versions
+must match the pre-release label and patch version expected by the server.
diff --git a/docs/external/src/rpc/index.md b/docs/external/src/rpc/index.md
new file mode 100644
index 0000000000..1500d3fd92
--- /dev/null
+++ b/docs/external/src/rpc/index.md
@@ -0,0 +1,59 @@
+---
+title: "gRPC API"
+sidebar_position: 0
+---
+
+# gRPC API
+
+Miden nodes expose a public gRPC API for querying chain state, synchronizing local state, submitting proven
+transactions, and subscribing to committed blocks and block proofs.
+
+The API uses standard gRPC status codes. Some methods also include additional Miden-specific error codes in status
+details for stable client-side handling.
+
+The official networks are served at `https://rpc.testnet.miden.io` and `https://rpc.devnet.miden.io`.
+
+## Schema
+
+The safest way to inspect the schema for a deployed network is through gRPC reflection:
+
+```bash
+grpcurl rpc.testnet.miden.io:443 describe rpc.Api
+```
+
+For a local development network without TLS, use `-plaintext`:
+
+```bash
+grpcurl -plaintext localhost:57291 describe rpc.Api
+```
+
+For Rust developers, we also ship a Rust crate
+[miden_node_proto_build](https://docs.rs/miden-node-proto-build/latest/miden_node_proto_build/) which exposes the gRPC
+schemas as file descriptor sets, which can be used to generate the gRPC bindings using [tonic](https://docs.rs/tonic).
+
+The source schema files are also available in the [Miden node repository](https://github.com/0xMiden/node), in the
+`proto/` directory. If you use the repository source instead of reflection, check out the release tag that matches the
+network or client version you are targeting. Branches such as `next` describe repository state, not necessarily the
+schema deployed on an official network.
+
+## Protocol Support
+
+The RPC server supports:
+
+- gRPC over HTTP/2.
+- gRPC-Web.
+- gRPC reflection for discovery tools such as `grpcurl`.
+
+## Endpoint Groups
+
+| Group | Methods |
+| ---------------------- | --------------------------------------------------------------------------------------------------------------- |
+| Status and limits | `Status`, `GetLimits` |
+| State queries | `GetAccount`, `GetBlockByNumber`, `GetBlockHeaderByNumber`, `GetNotesById`, `GetNoteScriptByRoot` |
+| Transaction submission | `SubmitProvenTx`, `SubmitProvenTxBatch` |
+| State synchronization | `SyncTransactions`, `SyncNotes`, `SyncNullifiers`, `SyncAccountVault`, `SyncAccountStorageMaps`, `SyncChainMmr` |
+| Block streaming | `BlockSubscription`, `ProofSubscription` |
+| Network note debugging | `GetNetworkNoteStatus` |
+
+See [Public RPC](/rpc/public-api) for endpoint summaries, [Subscriptions](/rpc/subscriptions) for stream semantics, and
+[Errors and Limits](/rpc/errors-and-limits) for request limits, content negotiation, and method-specific error codes.
diff --git a/docs/external/src/rpc/public-api.md b/docs/external/src/rpc/public-api.md
new file mode 100644
index 0000000000..efd9ab7b21
--- /dev/null
+++ b/docs/external/src/rpc/public-api.md
@@ -0,0 +1,82 @@
+---
+title: "Public RPC"
+sidebar_position: 1
+---
+
+# Public RPC
+
+This page summarizes the public gRPC `rpc.Api` service.
+
+As a reminder, you can inspect the exact schema on any deployed network using gRPC reflection:
+
+```bash
+grpcurl rpc.testnet.miden.io:443 describe rpc.Api
+```
+
+## Status and Limits
+
+| Method | Purpose |
+| ----------- | --------------------------------------------------------------------------------------------------------- |
+| `Status` | Returns the node RPC version, genesis commitment, store status, and block producer status when available. |
+| `GetLimits` | Returns configured query parameter limits for methods that accept large repeated parameters. |
+
+## State Queries
+
+| Method | Purpose |
+| ------------------------ | -------------------------------------------------------------------------------- |
+| `GetAccount` | Returns account witness data and optional details for public accounts. |
+| `GetBlockByNumber` | Returns raw block data for a block number, optionally including the block proof. |
+| `GetBlockHeaderByNumber` | Returns a block header and, optionally, MMR authentication data. |
+| `GetNotesById` | Returns committed notes matching the requested note IDs. |
+| `GetNoteScriptByRoot` | Returns a note script by script root when available. |
+
+## Transaction Submission
+
+| Method | Purpose |
+| --------------------- | ------------------------------------------------------------------------------------------- |
+| `SubmitProvenTx` | Submits one proven transaction and returns the node's current block height. |
+| `SubmitProvenTxBatch` | Submits an atomic batch of proven transactions and returns the node's current block height. |
+
+Write requests must identify the target network with the `genesis` parameter in the `Accept` header:
+
+```text
+application/vnd.miden; genesis=
+```
+
+Clients may also include a compatible RPC version:
+
+```text
+application/vnd.miden; version=; genesis=
+```
+
+See [Errors and Limits](./errors-and-limits.md#transaction-submission-errors) for the transaction submission detail
+codes returned in gRPC status details.
+
+## State Synchronization
+
+| Method | Purpose |
+| ------------------------ | --------------------------------------------------------------------------------------- |
+| `SyncTransactions` | Returns transaction records for specified accounts within a block range. |
+| `SyncNotes` | Returns note metadata and inclusion proofs for matching note tags within a block range. |
+| `SyncNullifiers` | Returns nullifiers matching specified 16-bit prefixes within a block range. |
+| `SyncAccountVault` | Returns public account vault updates within a block range. |
+| `SyncAccountStorageMaps` | Returns public account storage map updates within a block range. |
+| `SyncChainMmr` | Returns MMR delta information needed to synchronize the chain MMR. |
+
+Use `GetLimits` to discover the maximum request sizes accepted by the node before batching large sync requests.
+
+## Streaming
+
+| Method | Purpose |
+| ------------------- | ------------------------------------------------------------------------------------- |
+| `BlockSubscription` | Streams committed blocks from `block_from`, replaying history before live blocks. |
+| `ProofSubscription` | Streams block proofs from `block_from`, replaying existing proofs before live proofs. |
+
+These streams are the primary mechanism full nodes use to replicate chain data from an upstream source. They are also
+useful for indexers, explorers, and other services that need an append-only view of network progress.
+
+## Network Note Debugging
+
+| Method | Purpose |
+| ---------------------- | ------------------------------------------------------------------------------------------ |
+| `GetNetworkNoteStatus` | Returns the lifecycle status of a network note tracked by the network transaction builder. |
diff --git a/docs/external/src/rpc/subscriptions.md b/docs/external/src/rpc/subscriptions.md
new file mode 100644
index 0000000000..6e2fe37eeb
--- /dev/null
+++ b/docs/external/src/rpc/subscriptions.md
@@ -0,0 +1,38 @@
+---
+title: "Subscriptions"
+sidebar_position: 2
+---
+
+# Subscriptions
+
+The RPC API exposes two server-streaming methods for consumers that need to follow network progress.
+
+## BlockSubscription
+
+`BlockSubscription` streams committed blocks starting from `block_from`, inclusive. The server first replays historical
+blocks, then continues streaming live blocks as they are committed.
+
+Each response includes:
+
+- `block`: the serialized block.
+- `committed_chain_tip`: the current committed chain tip observed when the item was emitted.
+
+## ProofSubscription
+
+`ProofSubscription` streams block proofs starting from `block_from`, inclusive. The server first replays existing
+proofs, then continues streaming live proofs as they are generated.
+
+Each response includes:
+
+- `block_num`: the block number the proof corresponds to.
+- `proof`: the serialized block proof.
+- `proven_chain_tip`: the proven chain tip observed when the item was emitted.
+
+## Consumers
+
+Full nodes use both streams to replicate state from an upstream source. Indexers, explorers, and monitoring services can
+also use the streams to ingest block data without repeatedly polling by block number.
+
+Consumers should persist their local tip before acknowledging work internally. If a stream closes, reconnect from the
+last persisted local tip. If the server reports lag with `DATA_LOSS`, reconnect from local state rather than assuming
+any missed items were delivered.