From ae7e7ccb1751475e6a412463f7096b45faa2485b Mon Sep 17 00:00:00 2001
From: Conny Brunnkvist <cbrunnkvist@gmail.com>
Date: Thu, 28 May 2026 12:29:20 +0700
Subject: [PATCH] docs: Standardize markdown block spacing

---
 docs/commands/command-line-interface.md       |   4 +
 docs/commands/rpc-protocol.md                 | 653 +++++++++++++++++-
 docs/core-development/overview.md             |   1 -
 .../understanding-the-code.md                 |  31 +-
 docs/glossary.md                              |  49 ++
 docs/index.md                                 |  65 +-
 docs/integration-guides/advanced.md           |   6 +-
 docs/integration-guides/build-options.md      |  19 +-
 docs/integration-guides/index.md              |   3 -
 docs/integration-guides/ipc-integration.md    |   4 +
 docs/integration-guides/key-management.md     |  49 +-
 docs/integration-guides/the-basics.md         |  11 +-
 docs/integration-guides/websockets.md         |   8 +-
 docs/integration-guides/work-generation.md    |   5 +-
 docs/node-implementation/blocks.md            |   1 +
 docs/node-implementation/work.md              |   1 -
 docs/protocol-design/attack-vectors.md        |   1 +
 docs/protocol-design/blocks.md                |   4 +-
 .../protocol-design/distribution-and-units.md |   5 +-
 docs/protocol-design/introduction.md          |   1 +
 docs/protocol-design/ledger.md                |   1 +
 docs/protocol-design/networking.md            |   4 +
 docs/protocol-design/orv-consensus.md         |   1 +
 .../signing-hashing-and-key-derivation.md     |   2 +
 docs/releases/network-upgrades.md             |   5 +
 docs/releases/node-releases.md                |   4 +
 docs/releases/release-v19-0.md                |   8 +
 docs/releases/release-v20-0.md                |  10 +-
 docs/releases/release-v21-0.md                |   8 +
 docs/releases/release-v21-3.md                |   1 -
 docs/releases/release-v22-0.md                |   1 -
 docs/releases/release-v22-1.md                |   2 +-
 docs/releases/release-v23-1.md                |   1 +
 docs/releases/release-v23-3.md                |   1 +
 docs/releases/release-v24-0.md                |   1 +
 docs/releases/release-v25-0.md                |   8 +
 docs/releases/release-v27-0.md                |   8 +
 docs/releases/release-v28-0.md                |   4 +
 docs/releases/release-v28-1.md                |   1 -
 docs/releases/release-v28-2.md                |   1 +
 docs/running-a-node/beta-network.md           |  10 +-
 docs/running-a-node/configuration.md          |   7 +
 docs/running-a-node/docker-management.md      |   3 +
 docs/running-a-node/ledger-management.md      |   7 +
 docs/running-a-node/logging-tracing.md        |  21 +-
 docs/running-a-node/node-setup.md             |  18 +-
 docs/running-a-node/overview.md               |   5 +
 docs/running-a-node/test-network.md           |   7 +-
 docs/running-a-node/troubleshooting.md        |  18 +-
 .../voting-as-a-representative.md             |   4 +-
 docs/running-a-node/wallet-setup.md           |  27 +-
 ...fig-node-option-node-enable-voting-true.md |   1 +
 .../config-node-option-rpc-enable-true.md     |   1 +
 docs/snippets/hardware-recommendations.md     |   2 +
 .../known-issue-macos-too-many-open-files.md  |   3 -
 docs/snippets/release-details-v22-1.md        |   3 +-
 docs/snippets/release-details-v23-1.md        |   3 +-
 docs/snippets/release-details-v23-3.md        |   3 +-
 docs/snippets/release-details-v26-1.md        |   2 +-
 docs/snippets/unconfirmed-information.md      |   2 +-
 .../warning-only-official-builds-supported.md |   1 +
 .../warning-unsupported-configuration.md      |   1 +
 docs/what-is-nano/overview.md                 |   4 +
 docs/whitepaper/english.md                    |   1 +
 scripts/format_markdown.py                    | 135 ++++
 65 files changed, 1189 insertions(+), 93 deletions(-)
 create mode 100755 scripts/format_markdown.py

diff --git a/docs/commands/command-line-interface.md b/docs/commands/command-line-interface.md
index 698b3fbb4..d0b781025 100644
--- a/docs/commands/command-line-interface.md
+++ b/docs/commands/command-line-interface.md
@@ -3,6 +3,7 @@ description: Reference for the CLI commands available for the nano node
 
 # Command Line Interface
 ## nano_node commands
+
 | Command | Description |
 |---------|-------------|      
 | `--account_create --wallet=<wallet>` | Insert next deterministic key into `<wallet>` |
@@ -41,11 +42,13 @@ description: Reference for the CLI commands available for the nano node
 | `--wallet_representative_set`<br>`--wallet=<wallet>`<br>&nbsp;&nbsp;`--account=<account>` | Set `<account>` as default representative for `<wallet>`. |
 
 ## Launch Options
+
 The node is typically run like this:
 
 ```bash
 ./nano_node --daemon [--launch_options]
 ```
+
 !!! note "Intended for developer use"
 	These options are only for developer use so please understand the impacts before use.
 
@@ -88,6 +91,7 @@ The node is typically run like this:
 | `--disable_wallet_bootstrap` | Turn off use of wallet-based bootstrap. |
 
 ## Debug commands
+
 | Command | Description |
 |---------|-------------|
 | `--debug_account_count` | Display the number of accounts. |
diff --git a/docs/commands/rpc-protocol.md b/docs/commands/rpc-protocol.md
index 937ebb20e..d7c4cd3f8 100644
--- a/docs/commands/rpc-protocol.md
+++ b/docs/commands/rpc-protocol.md
@@ -20,11 +20,13 @@ The RPC protocol accepts JSON HTTP POST requests. The following are RPC commands
 ---
 
 ### account_balance 
+
 Returns how many RAW is owned and how many have not yet been received by **account**  
 
 --8<-- "deprecation-info-pending.md"
 
 **Request:**
+
 ```json 
 {
   "action": "account_balance",
@@ -33,6 +35,7 @@ Returns how many RAW is owned and how many have not yet been received by **accou
 ```
 
 **Response:**
+
 ```json
 {
   "balance": "10000",
@@ -48,9 +51,11 @@ Boolean, true by default. Results in `balance` only including blocks on this acc
 ---
 
 ### account_block_count
+
 Get number of blocks for a specific **account**  
 
 **Request:**
+
 ```json
 {
   "action": "account_block_count",
@@ -59,6 +64,7 @@ Get number of blocks for a specific **account**
 ```
 
 **Response:**
+
 ```json
 {
   "block_count" : "19"
@@ -68,9 +74,11 @@ Get number of blocks for a specific **account**
 ---
 
 ### account_get
+
 Get account number for the **public key**  
 
 **Request:**
+
 ```json
 {
   "action": "account_get",
@@ -79,6 +87,7 @@ Get account number for the **public key**
 ```
 
 **Response:**
+
 ```json
 {
   "account" : "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx"
@@ -94,6 +103,7 @@ Reports send/receive information for an account. Returns only **send & receive**
 --8<-- "warning-includes-unconfirmed.md"
 
 **Request:**
+
 ```json
 {
   "action": "account_history",
@@ -103,6 +113,7 @@ Reports send/receive information for an account. Returns only **send & receive**
 ```
 
 **Response:**
+
 ```json
 {
   "account": "nano_1ipx847tk8o46pwxt5qjdbncjqcbwcc1rrmqnkztrfjy5k7z4imsrata9est",
@@ -135,6 +146,7 @@ If the `count` limit results in stopping before the end of the account chain, th
 ---
 
 ### account_info
+
 Returns frontier, open block, change representative block, balance, last modified timestamp from local database & block count for **account**. Only works for accounts that have received their first transaction and have an entry on the ledger, will return "Account not found" otherwise. To open an account, use [receive](#receive).  
 
 --8<-- "unconfirmed-information.md"
@@ -143,6 +155,7 @@ Returns frontier, open block, change representative block, balance, last modifie
     If you need only details for confirmed blocks, use the `include_confirmed` option below and referenced the `confirmed_*` fields added in to the response.
 
 **Request:**
+
 ```json
 {
   "action": "account_info",
@@ -151,6 +164,7 @@ Returns frontier, open block, change representative block, balance, last modifie
 ```
 
 **Response:**
+
 ```json
 {
   "frontier": "FF84533A571D953A596EA401FD41743AC85D04F406E76FDE4408EAED50B473C5",
@@ -181,6 +195,7 @@ Boolean, false by default. Adds new return fields with prefix of `confirmed_` fo
 --8<-- "deprecation-info-pending.md"
 
 **Request:**
+
 ```json
 {
   "action": "account_info",  
@@ -193,6 +208,7 @@ Boolean, false by default. Adds new return fields with prefix of `confirmed_` fo
 ```
 
 **Response:**
+
 ```json
 {
     "frontier": "80A6745762493FA21A22718ABFA4F635656A707B48B3324198AC7F3938DE6D4F",
@@ -220,6 +236,7 @@ _version 9.0+_
 Booleans, false by default. Additionally returns representative, voting weight, pending/receivable balance for account   
 
 **Request:**
+
 ```json
 {
   "action": "account_info",
@@ -231,6 +248,7 @@ Booleans, false by default. Additionally returns representative, voting weight,
 ```
 
 **Response:**
+
 ```json
 {
   "frontier": "FF84533A571D953A596EA401FD41743AC85D04F406E76FDE4408EAED50B473C5",
@@ -252,16 +270,20 @@ Booleans, false by default. Additionally returns representative, voting weight,
 ---
 
 ### account_key
+
 Get the public key for **account**  
 
 **Request:**
+
 ```json
 {
   "action": "account_key",
   "account" : "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "key": "3068BB1CA04525BB0E416C485FE6A67FD52540227D267CC8B6E8DA958A7FA039"
@@ -271,16 +293,20 @@ Get the public key for **account**
 ---
 
 ### account_representative 
+
 Returns the representative for **account**  
 
 **Request:**
+
 ```json
 {
   "action": "account_representative",
   "account": "nano_39a73oy5ungrhxy5z5oao1xso4zo7dmgpjd4u74xcrx3r1w6rtazuouw6qfi"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "representative" : "nano_16u1uufyoig8777y6r8iqjtrw8sg8maqrm36zzcm95jmbd9i9aj5i8abr8u5"
@@ -290,16 +316,20 @@ Returns the representative for **account**
 ---
 
 ### account_weight  
+
 Returns the voting weight for **account**  
 
 **Request:**
+
 ```json
 {
   "action": "account_weight",
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "weight": "10000"
@@ -309,6 +339,7 @@ Returns the voting weight for **account**
 ---
 
 ### accounts_balances  
+
 Returns how many RAW is owned and how many have not yet been received by **accounts list**  
 
 --8<-- "unconfirmed-information.md"
@@ -317,13 +348,16 @@ Returns how many RAW is owned and how many have not yet been received by **accou
 --8<-- "deprecation-info-pending.md"
 
 **Request:**
+
 ```json
 {
   "action": "accounts_balances",
   "accounts": ["nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3", "nano_3i1aq1cchnmbn9x5rsbap8b15akfh7wj7pwskuzi7ahz8oq6cobd99d4r3b7"]
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "balances" : {
@@ -350,6 +384,7 @@ Boolean, true by default. Results in `balance` only including blocks on the prov
     With _version 25.0+_, `accounts_balances` response errors come in a different entry, named as `errors`. This
     fixes the breaking change added in V24.0. Please notice that when an account is not found in the ledger, no error
     is returned anymore. It now returns a zero balance and zero as receivable.
+
     ```json
     {
       "balances": {
@@ -369,16 +404,20 @@ Boolean, true by default. Results in `balance` only including blocks on the prov
       }
     }
     ```
+
     If all requested entries result in errors, no entry will be added in the response for `balances`. Similarly,
     if there are no errors, no entry will be added for `errors`.  
     Request:
+
     ```json
     {  
       "action": "accounts_balances",  
       "accounts": ["nano_36uccgpjzhjsdbj44wm1y5hyz8gefx3wjpp1jircxt84nopxkxti5bzq1rnz"]  
     }
     ```
+
     Response:
+
     ```json
     {
       "errors": {
@@ -386,9 +425,11 @@ Boolean, true by default. Results in `balance` only including blocks on the prov
       }
     }
     ```
+
     In _version 24.0+_, `accounts_balances` response errors are returned per account entry in `balances` object.
     If an account does not exist, zero balance and zero receivables should be returned, but V24.0 has a bug: unopened
     accounts with receivables return an error instead of the receivables.
+
     ```json
     {
       "balances": {
@@ -404,22 +445,25 @@ Boolean, true by default. Results in `balance` only including blocks on the prov
     }
     ```
 
-
 ---
 
 ### accounts_frontiers  
+
 Returns a list of pairs of account and block hash representing the head block for **accounts list**  
 
 --8<-- "warning-includes-unconfirmed.md"
 
 **Request:**
+
 ```json
 {
   "action": "accounts_frontiers",
   "accounts": ["nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3", "nano_3i1aq1cchnmbn9x5rsbap8b15akfh7wj7pwskuzi7ahz8oq6cobd99d4r3b7"]
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "frontiers" : {
@@ -431,6 +475,7 @@ Returns a list of pairs of account and block hash representing the head block fo
 
 !!! info "Error handling"
     With _version 25.0+_, `accounts_frontiers` response errors come in a different entry, named `errors`.
+
     ```json
     {
       "frontiers": {
@@ -442,16 +487,20 @@ Returns a list of pairs of account and block hash representing the head block fo
       }
     }
     ```
+
     If all requested entries result in errors, no entry will be added in the response for `frontiers`. Similarly,
     if there are no errors, no entry will be added for `errors`.  
     Request:
+
     ```json
     {  
       "action": "accounts_frontiers",  
       "accounts": ["nano_1hrts7hcoozxccnffoq9hqhngnn9jz783usapejm57ejtqcyz9dpso1bibuy"]  
     }
     ```
+
     Response:  
+
     ```json
     {
       "errors": {
@@ -459,8 +508,10 @@ Returns a list of pairs of account and block hash representing the head block fo
       }
     }
     ```
+
     In _version 24.0+_, `accounts_frontiers` response errors were returned per account entry in the
     `frontiers` object.
+
     ```json
     {
       "frontiers": {
@@ -480,6 +531,7 @@ _since V24.0, use [accounts_pending](#accounts_pending) for V23.3 and below_
 Returns a list of confirmed block hashes which have not yet been received by these **accounts**  
 
 **Request:**
+
 ```json
 {
   "action": "accounts_receivable",
@@ -487,7 +539,9 @@ Returns a list of confirmed block hashes which have not yet been received by the
   "count": "1"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks" : {
@@ -496,11 +550,13 @@ Returns a list of confirmed block hashes which have not yet been received by the
   }
 }
 ```  
+
 **Optional "threshold"**  
 _version 8.0+_   
 Number (128 bit, decimal). Returns a list of receivable block hashes with amount more or equal to **threshold**   
 
 **Request:**
+
 ```json
 {
   "action": "accounts_receivable",
@@ -509,7 +565,9 @@ Number (128 bit, decimal). Returns a list of receivable block hashes with amount
   "threshold": "1000000000000000000000000"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks" : {
@@ -522,11 +580,13 @@ Number (128 bit, decimal). Returns a list of receivable block hashes with amount
   }
 }
 ```  
+
 **Optional "source"**  
 _version 9.0+_   
 Boolean, false by default. Returns a list of receivable block hashes with amount and source accounts   
 
 **Request:**
+
 ```json
 {
   "action": "accounts_receivable",
@@ -535,7 +595,9 @@ Boolean, false by default. Returns a list of receivable block hashes with amount
   "source": "true"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks" : {
@@ -554,12 +616,14 @@ Boolean, false by default. Returns a list of receivable block hashes with amount
   }
 }
 ```  
+
 **Optional "include_active"**
 
 _version 15.0+_   
 Boolean, false by default. Include active (not confirmed) blocks    
 
 **Request:**
+
 ```json
 {
   "action": "accounts_receivable",
@@ -582,16 +646,20 @@ Boolean, true by default (_version 22.0+_), previously false by default. Only re
 ---
 
 ### accounts_representatives 
+
 Returns the representatives for given **accounts**  
 
 **Request:**
+
 ```json
 {
   "action": "accounts_representatives",
   "accounts": ["nano_16u1uufyoig8777y6r8iqjtrw8sg8maqrm36zzcm95jmbd9i9aj5i8abr8u5","nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3"]
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "representatives" : {
@@ -603,6 +671,7 @@ Returns the representatives for given **accounts**
 
 !!! info "Error handling"
     With _version 25.0+_, `accounts_representatives` response errors come in a different entry, named `errors`.
+
     ```json
     {
       "representatives": {
@@ -614,16 +683,20 @@ Returns the representatives for given **accounts**
       }
     }
     ```
+
     If all requested entries result in errors, no entry will be added in the response for `representatives`. Similarly,
     if there are no errors, no entry will be added for `errors`.  
     Request:
+
     ```json
     {  
       "action": "accounts_representatives",  
       "accounts": ["nano_1hrts7hcoozxccnffoq9hqhngnn9jz783usapejm57ejtqcyz9dpso1bibuy"]  
     }
     ```
+
     Response:  
+
     ```json
     {
       "errors": {
@@ -631,8 +704,10 @@ Returns the representatives for given **accounts**
       }
     }
     ```
+
     In _version 24.0+_, `accounts_representatives` response errors were returned per account entry in the
     `representatives` object.
+
     ```json
     {
       "representatives": {
@@ -646,15 +721,19 @@ Returns the representatives for given **accounts**
 ---
 
 ### available_supply  
+
 Returns how many raw are in the public supply  
 
 **Request:**
+
 ```json
 {
   "action": "available_supply"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "available": "133248061996216572282917317807824970865"
@@ -664,16 +743,20 @@ Returns how many raw are in the public supply
 ---
 
 ### block_account  
+
 Returns the account containing block  
 
 **Request:**
+
 ```json
 {
   "action": "block_account",
   "hash": "023B94B7D27B311666C8636954FE17F1FD2EAA97A8BAC27DE5084FBBD5C6B02C"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "account": "nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3"
@@ -683,17 +766,21 @@ Returns the account containing block
 ---
 
 ### block_confirm   
+
 _version 12.2+_   
 Request confirmation for **block** from known online representative nodes. Check results with [confirmation history](#confirmation_history).
 
 **Request:**
+
 ```json
 {
   "action": "block_confirm",
   "hash": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "started": "1"
@@ -705,15 +792,19 @@ Request confirmation for **block** from known online representative nodes. Check
 ---
 
 ### block_count  
+
 Reports the number of blocks in the ledger and unchecked synchronizing blocks   
 
 **Request:**
+
 ```json
 {
   "action": "block_count"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "count": "1000",
@@ -721,6 +812,7 @@ Reports the number of blocks in the ledger and unchecked synchronizing blocks
   "cemented": "25"
 }
 ```
+
 **Note:** If the node is running the RocksDB backend the unchecked count may only be estimate.  
 
 **Optional "include_cemented"**
@@ -733,13 +825,14 @@ Default "true". If "true", "cemented" in the response will contain the number of
 ---
 
 ### block_create
+
 _enable_control required, version 9.0+_  
 Creates a json representations of new block based on input data & signed with **private key** or **account** in **wallet**. Use for offline signing. Using the optional `json_block` is recommended since v19.0.  
 
 --8<-- "warning-enable-control.md"
 
-
 **Request sample for state block:**  
+
 ```json
 {
   "action": "block_create",
@@ -752,6 +845,7 @@ Creates a json representations of new block based on input data & signed with **
   "previous": "F47B23107E5F34B2CE06F562B5C435DF72A533251CB414C51B2B62A8F63A00E4"
 }
 ```  
+
 Parameters for state block:
 
 * `balance`: **final** balance for account after block creation, formatted in 'raw' units using a decimal integer. If balance is less than previous, block is considered as send subtype!
@@ -790,6 +884,7 @@ If difficulty and work values are both not given, RPC processor tries to calcula
 **Examples**
 
 **Response sample for above request**:  
+
 ```json
 {
   "hash": "FF0144381CFF0B2C079A115E7ADA7E96F43FD219446E7524C48D1CC9900C4F17",
@@ -811,10 +906,12 @@ If difficulty and work values are both not given, RPC processor tries to calcula
 ---
 
 ### block_hash  
+
 _version 13.0+_   
 Returning block hash for given **block** content. Using the optional `json_block` is recommended since v19.0.  
 
 **Request:**
+
 ```json
 {  
   "action": "block_hash",
@@ -832,7 +929,9 @@ Returning block hash for given **block** content. Using the optional `json_block
   }
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "hash": "FF0144381CFF0B2C079A115E7ADA7E96F43FD219446E7524C48D1CC9900C4F17"
@@ -847,6 +946,7 @@ Default "false". If "true", "block" must contain a JSON subtree instead of a JSO
 ---
 
 ### block_info  
+
 Retrieves a json representation of the block in `contents` along with:
 
 * _since version 18.0_: `block_account`, transaction `amount`, block `balance`, block `height` in account chain, block local modification `timestamp`
@@ -856,6 +956,7 @@ Retrieves a json representation of the block in `contents` along with:
 Using the optional `json_block` is recommended since v19.0.  
 
 **Request:**
+
 ```json
 {  
   "action": "block_info",
@@ -863,7 +964,9 @@ Using the optional `json_block` is recommended since v19.0.
   "hash": "87434F8041869A01C8F6F263B87972D7BA443A72E0A97D7A3FD0CCC2358FD6F9"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "block_account": "nano_1ipx847tk8o46pwxt5qjdbncjqcbwcc1rrmqnkztrfjy5k7z4imsrata9est",
@@ -895,19 +998,19 @@ Note: The `Balance` in contents is a uint128. However, it will be a hex-encoded
 _version 19.0+_  
 Default "false". If "true", "contents" will contain a JSON subtree instead of a JSON string.
 
-
 **Optional `include_linked_account`**
 
 _version 28.0+_
 (bool):  When set to `true`, the response will include a new field `linked_account`, which returns the linked account associated with the block (or "0" if no linked account exists/was found e.g. due to pruning).
 
-
 ---
 
 ### blocks  
+
 Retrieves a json representations of **blocks**. Using the optional `json_block` is recommended since v19.0.  
 
 **Request:**
+
 ```json
 {
   "action": "blocks",
@@ -915,7 +1018,9 @@ Retrieves a json representations of **blocks**. Using the optional `json_block`
   "hashes": ["87434F8041869A01C8F6F263B87972D7BA443A72E0A97D7A3FD0CCC2358FD6F9"]
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks": {
@@ -942,6 +1047,7 @@ Default "false". If "true", "contents" will contain a JSON subtree instead of a
 ---
 
 ### blocks_info   
+
 Retrieves a json representations of `blocks` in `contents` along with:
 
 * _since version 18.0_: `block_account`, transaction `amount`, block `balance`, block `height` in account chain, block local modification `timestamp`
@@ -951,6 +1057,7 @@ Retrieves a json representations of `blocks` in `contents` along with:
 Using the optional `json_block` is recommended since v19.0.  
 
 **Request:**
+
 ```json
 {
   "action": "blocks_info",
@@ -958,7 +1065,9 @@ Using the optional `json_block` is recommended since v19.0.
   "hashes": ["87434F8041869A01C8F6F263B87972D7BA443A72E0A97D7A3FD0CCC2358FD6F9"]
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks": {
@@ -986,6 +1095,7 @@ Using the optional `json_block` is recommended since v19.0.
   }
 }
 ```
+
 **Optional `include_linked_account`**
 
 _version 28.0+_
@@ -999,6 +1109,7 @@ Booleans, false by default. Additionally checks if block is pending, returns sou
 --8<-- "deprecation-info-pending.md"
 
 **Request:**
+
 ```json
 {
   "action": "blocks_info",
@@ -1007,7 +1118,9 @@ Booleans, false by default. Additionally checks if block is pending, returns sou
   "source": "true"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks" : {
@@ -1024,12 +1137,14 @@ Booleans, false by default. Additionally checks if block is pending, returns sou
   }
 }
 ```
+
 **Optional "receive_hash"**
 
 _version 24.0+_  
 Boolean, default false. If "true", displays the hash of the send block's corresponding receive (if any). Returns 0 for non-send blocks, and for receivable blocks that do not yet have a corresponding receive.
 
 **Request:**
+
 ```json
 {
   "action": "blocks_info",
@@ -1039,6 +1154,7 @@ Boolean, default false. If "true", displays the hash of the send block's corresp
 ```
 
 **Response**
+
 ```json
 {
     "blocks": {
@@ -1069,6 +1185,7 @@ _version 19.0+_
 Default "false". If "true", an additional "blocks_not_found" is provided in the response, containing a list of the block hashes that were not found in the local database. Previously to this version an error would be produced if any block was not found.
 
 **Request:**
+
 ```json
 {
   "action": "blocks_info",
@@ -1078,6 +1195,7 @@ Default "false". If "true", an additional "blocks_not_found" is provided in the
 ```
 
 **Response:**
+
 ```json
 {
   "blocks" : {
@@ -1102,9 +1220,11 @@ Default "false". If "true", an additional "blocks_not_found" is provided in the
 ---
 
 ### bootstrap  
+
 Initialize bootstrap to specific **IP address** and **port**. Not compatible with launch flag [--disable_legacy_bootstrap](/commands/command-line-interface/#-disable_legacy_bootstrap)   
 
 **Request:**
+
 ```json
 {
   "action": "bootstrap",
@@ -1112,7 +1232,9 @@ Initialize bootstrap to specific **IP address** and **port**. Not compatible wit
   "port": "7075"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "success": ""
@@ -1130,20 +1252,25 @@ String, empty by default. Set specific ID for new bootstrap attempt for better t
 ---
 
 ### bootstrap_any  
+
 Initialize multi-connection bootstrap to random peers. Not compatible with launch flag [--disable_legacy_bootstrap](/commands/command-line-interface/#-disable_legacy_bootstrap)   
 
 **Request:**
+
 ```json
 {
   "action": "bootstrap_any"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "success": ""
 }
 ```
+
 **Optional "force"**  
 _version 20.0+_  
 Boolean, false by default. Manually force closing of all current bootstraps  
@@ -1159,25 +1286,30 @@ String, empty by default. Public address for targeting a specific account on boo
 ---
 
 ### bootstrap_lazy  
+
 _enable_control required, version 17.0+_   
 Initialize lazy bootstrap with given block **hash**. Not compatible with launch flag [--disable_lazy_bootstrap](/commands/command-line-interface/#-disable_lazy_bootstrap). As of _version 22.0_, response includes whether new election was `started` and whether a new lazy `key_inserted` was successful.
 
 --8<-- "warning-enable-control.md"
 
 **Request:**
+
 ```json
 {
   "action": "bootstrap_lazy",
   "hash": "FF0144381CFF0B2C079A115E7ADA7E96F43FD219446E7524C48D1CC9900C4F17"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "started": "1",
   "key_inserted": "0"
 }
 ```
+
 **Optional "force"**
 
 Boolean, false by default. Manually force closing of all current bootstraps  
@@ -1189,12 +1321,14 @@ String, empty by default. Set specific ID for new bootstrap attempt for better t
 ---
 
 ### bootstrap_priorities  
+
 _enable_control required, version 28.0+_   
 Dumps info about priority and blocking sets to aid in debugging any potential problems
 
 --8<-- "warning-enable-control.md"
 
 **Request:**
+
 ```json
 {
   "action": "bootstrap_priorities"
@@ -1204,12 +1338,14 @@ Dumps info about priority and blocking sets to aid in debugging any potential pr
 ---
 
 ### bootstrap_reset  
+
 _enable_control required, version 28.0+_   
 Resets ascending bootstrap state - both priority and blocking sets are cleared.
 
 --8<-- "warning-enable-control.md"
 
 **Request:**
+
 ```json
 {
   "action": "bootstrap_reset"
@@ -1219,6 +1355,7 @@ Resets ascending bootstrap state - both priority and blocking sets are cleared.
 ---
 
 ### bootstrap_status  
+
 _version 17.0+_
 
 --8<-- "warning-debug-only-command.md"
@@ -1226,13 +1363,16 @@ _version 17.0+_
 Returning status of current bootstrap attempt
 
 **Request:**
+
 ```json
 {
   "action": "bootstrap_status"
 }
 ```  
+
 **Response:**
 _versions 21.0+_
+
 ```json
 {
   "bootstrap_threads": "2",
@@ -1283,6 +1423,7 @@ _versions 21.0+_
 ```
 
 ??? abstract "Response V17.0-V20.0"
+
     ```json
     {
       "clients": "0",
@@ -1312,9 +1453,11 @@ _versions 21.0+_
 ---
 
 ### chain  
+
 Returns a consecutive list of block hashes in the account chain starting at **block** back to **count** (direction from frontier back to open block, from newer blocks to older). Will list all blocks back to the open block of this chain when count is set to "-1". The requested block hash is included in the answer.  
 
 **Request:**
+
 ```json
 {
   "action": "chain",
@@ -1322,7 +1465,9 @@ Returns a consecutive list of block hashes in the account chain starting at **bl
   "count": "1"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "blocks": [
@@ -1330,6 +1475,7 @@ Returns a consecutive list of block hashes in the account chain starting at **bl
   ]
 }
 ```
+
 **Optional "offset"**
 
 _version 18.0+_   
@@ -1343,6 +1489,7 @@ Boolean, false by default. Returns a list of block hashes in the account chain s
 ---
 
 ### confirmation_active  
+
 _version 16.0+_   
 Returns list of active elections qualified roots (excluding stopped & aborted elections); since V21, also includes the number of unconfirmed and confirmed active elections. Find info about specific qualified root with [confirmation_info](#confirmation_info)  
 
@@ -1352,14 +1499,16 @@ Returns list of active elections qualified roots (excluding stopped & aborted el
     * First account block (open): account public key + `0000000000000000000000000000000000000000000000000000000000000000`
     * Other blocks: previous hash + previous hash
 
-
 **Request:**
+
 ```json
 {
   "action": "confirmation_active"
 }
 ```  
+
 **Response:**
+
 ```json
 {
  "confirmations": [
@@ -1377,6 +1526,7 @@ Number, 0 by default. Returns only active elections with equal or higher announc
 ---
 
 ### confirmation_history  
+
 _version 12.0+_
 
 --8<-- "warning-debug-only-command.md"
@@ -1387,12 +1537,15 @@ Returns hash, tally weight, election duration (in milliseconds), election confir
 With version 19.0+ `confirmation_history_size` can be managed in the configuration file to adjust the number of elections to be kept in history and returned by this call. Due to timings inside the node, the default 2048 limit will return all confirmations up to traffic levels of approximately 56 confirmations/sec. To properly track levels above this, increase this value or use the confirmation subscription through the [websocket](/integration-guides/websockets) instead.
 
 **Request:**
+
 ```json
 {
   "action": "confirmation_history"
 }
 ```  
+
 **Response:**
+
 ```json
 {
   "confirmation_stats": {
@@ -1423,9 +1576,11 @@ With version 19.0+ `confirmation_history_size` can be managed in the configurati
   ]
 }
 ```   
+
 **Optional "hash"**
 
 Valid block hash, filters return for only the provided hash. If there is no confirmation available for that hash anymore, the following return can be expected:  
+
 ```json
 {
   "confirmation_stats": {
@@ -1436,6 +1591,7 @@ Valid block hash, filters return for only the provided hash. If there is no conf
 ```  
 
 If the block is unknown on the node, the following error will be returned:  
+
 ```"error": "Invalid block hash"```  
  
 ---
@@ -1453,14 +1609,17 @@ Returns info about an unconfirmed active election by **root**. Including announc
 
 **Request:**
 ```json
+
 {
   "action": "confirmation_info",
   "json_block": "true",
   "root": "EE125B1B1D85D3C24636B3590E1642D9F21B166C0C6CD99C9C6087A1224A0C44EE125B1B1D85D3C24636B3590E1642D9F21B166C0C6CD99C9C6087A1224A0C44"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "announcements": "2",
   "voters": "29",
@@ -1484,6 +1643,7 @@ Returns info about an unconfirmed active election by **root**. Including announc
     }
   }
 }   
+
 ```   
 
 **Optional "contents"**
@@ -1501,15 +1661,18 @@ Boolean, false by default. Returns list of votes representatives & its weights f
 
 **Request:**
 ```json
+
 {
   "action": "confirmation_info",
   "json_block": "true",
   "root": "EE125B1B1D85D3C24636B3590E1642D9F21B166C0C6CD99C9C6087A1224A0C44EE125B1B1D85D3C24636B3590E1642D9F21B166C0C6CD99C9C6087A1224A0C44",
   "representatives": "true"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "announcements": "5",
   "last_winner": "B94C505029F04BC057A0486ADA8BD07981B4A8736AE6581F2E98C6D18498146F",
@@ -1537,6 +1700,7 @@ Boolean, false by default. Returns list of votes representatives & its weights f
     }
   }
 }
+
 ```   
 
 ---
@@ -1555,12 +1719,15 @@ Returns information about node elections settings & observed network state:
 
 **Request:**
 ```json
+
 {  
   "action": "confirmation_quorum"      
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "quorum_delta": "41469707173777717318245825935516662250",
   "online_weight_quorum_percent": "50",
@@ -1569,6 +1736,7 @@ Returns information about node elections settings & observed network state:
   "peers_stake_total": "69026910610720098597176027400951402360",
   "trended_stake_total": "81939414347555434636491651871033324568"
 }   
+
 ```   
 
 **Optional "peer_details"**
@@ -1596,14 +1764,17 @@ Returns a list of open database transactions which are equal or greater than the
 
 **Request:**
 ```json
+
 {
   "action": "database_txn_tracker",
   "min_read_time" : "1000",
   "min_write_time" : "0"
 }
+
 ```
 **Response on Windows/Debug:**  
 ```json
+
 {
   "txn_tracking": [
     {
@@ -1635,6 +1806,7 @@ Returns a list of open database transactions which are equal or greater than the
     ... // other threads
   ]
 }
+
 ```
 
 ---
@@ -1645,19 +1817,23 @@ Returns a list of pairs of delegator accounts and balances given a representativ
 
 **Request:**
 ```json
+
 {
   "action": "delegators",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "delegators": {
     "nano_13bqhi1cdqq8yb9szneoc38qk899d58i5rcrgdk5mkdm86hekpoez3zxw5sd": "500000000000000000000000000000000000",
     "nano_17k6ug685154an8gri9whhe5kb5z1mf5w6y39gokc1657sh95fegm8ht1zpn": "961647970820730000000000000000000000"
   }
 }
+
 ```   
 
 **Optional parameters:**  
@@ -1675,16 +1851,20 @@ Get number of delegators for a specific representative **account**
 
 **Request:**
 ```json
+
 {
   "action": "delegators_count",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "count": "2"
 }
+
 ```   
 
 ---
@@ -1694,19 +1874,23 @@ Derive deterministic keypair from **seed** based on **index**
 
 **Request:**
 ```json
+
 {
   "action": "deterministic_key",
   "seed": "0000000000000000000000000000000000000000000000000000000000000000",
   "index": "0"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "private": "9F0E444C69F77A49BD0BE89DB92C38FE713E0963165CCA12FAF5712D7657120F",
   "public": "C008B814A7D269A1FA3C6528B19201A24D797912DB9996FF02A1FF356E45552B",
   "account": "nano_3i1aq1cchnmbn9x5rsbap8b15akfh7wj7pwskuzi7ahz8oq6cobd99d4r3b7"
 }
+
 ```  
 
 ---
@@ -1720,12 +1904,15 @@ Values in `max_election_age` and `average_election_age` are in milliseconds.
 
 **Request:**
 ```json
+
 {
   "action": "election_statistics"
 }
+
 ```  
 **Response sample:**
 ```json
+
 {
     "normal": "152",
     "priority": "1",
@@ -1736,6 +1923,7 @@ Values in `max_election_age` and `average_election_age` are in milliseconds.
     "max_election_age": "5493",
     "average_election_age": "421"
 }
+
 ```
 
 ---
@@ -1751,17 +1939,21 @@ Upgrade network to new **epoch** with epoch signer private **key**. This spawns
 
 **Request:**
 ```json
+
 {
   "action": "epoch_upgrade",
   "epoch": "1",
   "key": "0000000000000000000000000000000000000000000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "started": "1"
 }
+
 ```  
 **Optional "count"**  
 Number. Determines limit of number of accounts to upgrade.
@@ -1777,15 +1969,19 @@ Reports the number of accounts in the ledger
 
 **Request:**
 ```json
+
 {
   "action": "frontier_count"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "count": "920471"
 }
+
 ```
 
 ---
@@ -1795,19 +1991,23 @@ Returns a list of pairs of account and block hash representing the head block st
 
 **Request:**
 ```json
+
 {
   "action": "frontiers",
   "account": "nano_1111111111111111111111111111111111111111111111111111hifc8npp",
   "count": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "frontiers" : {
     "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
   }
 }
+
 ```
 
 ---
@@ -1820,17 +2020,21 @@ Tells the node to send a keepalive packet to **address**:**port**
 
 **Request:**
 ```json
+
 {
   "action": "keepalive",
   "address": "::ffff:192.169.0.1",
   "port": "1024"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "started": "1"
 }
+
 ```
 
 ---
@@ -1840,17 +2044,21 @@ Generates an **adhoc random keypair**
 
 **Request:**
 ```json
+
 {
   "action": "key_create"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "private": "781186FB9EF17DB6E3D1056550D9FAE5D5BBADA6A6BC370E4CBB938B1DC71DA3",
   "public": "3068BB1CA04525BB0E416C485FE6A67FD52540227D267CC8B6E8DA958A7FA039",
   "account": "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx"
 }
+
 ```  
 
 ---
@@ -1860,18 +2068,22 @@ Derive public key and account number from **private key**
 
 **Request:**
 ```json
+
 {
   "action": "key_expand",
   "key": "781186FB9EF17DB6E3D1056550D9FAE5D5BBADA6A6BC370E4CBB938B1DC71DA3"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "private": "781186FB9EF17DB6E3D1056550D9FAE5D5BBADA6A6BC370E4CBB938B1DC71DA3",
   "public": "3068BB1CA04525BB0E416C485FE6A67FD52540227D267CC8B6E8DA958A7FA039",
   "account": "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3sxwjym5rx"
 }
+
 ```  
 
 ---
@@ -1886,14 +2098,17 @@ Returns frontier, open block, change representative block, balance, last modifie
 
 **Request:**
 ```json
+
 {
   "action": "ledger",
   "account": "nano_1111111111111111111111111111111111111111111111111111hifc8npp",
   "count": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "accounts": {
     "nano_11119gbh8hb4hj1duf7fdtfyf5s75okzxdgupgpgm1bj78ex3kgy7frt3s9n": {
@@ -1906,12 +2121,14 @@ Returns frontier, open block, change representative block, balance, last modifie
     }
   }
 }
+
 ```  
 **Optional "representative", "weight", "receivable"**  
 Booleans, false by default. Additionally returns representative, voting weight, receivable balance for each account   
 
 **Request:**
 ```json
+
 {
   "action": "ledger",
   "account": "nano_1111111111111111111111111111111111111111111111111111hifc8npp",
@@ -1920,9 +2137,11 @@ Booleans, false by default. Additionally returns representative, voting weight,
   "weight": "true",
   "receivable": "true"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "accounts": {
     "nano_11119gbh8hb4hj1duf7fdtfyf5s75okzxdgupgpgm1bj78ex3kgy7frt3s9n": {
@@ -1939,6 +2158,7 @@ Booleans, false by default. Additionally returns representative, voting weight,
     }   
   }   
 }
+
 ```  
 **Optional "modified_since"**  
 _version 11.0+_   
@@ -1966,18 +2186,22 @@ _version 20.0 will generate the node_id with `node_` prefix, earlier versions wi
 
 **Request:**
 ```json
+
 {
   "action": "node_id"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "private": "2AD75C9DC20EA497E41722290C4DC966ECC4D6C75CAA4E447961F918FD73D8C7",
   "public": "78B11E1777B8E7DF9090004376C3EDE008E84680A497C0805F68CA5928626E1C",
   "as_account": "nano_1y7j5rdqhg99uyab1145gu3yur1ax35a3b6qr417yt8cd6n86uiw3d4whty3",
   "node_id": "node_1y7j5rdqhg99uyab1145gu3yur1ax35a3b6qr417yt8cd6n86uiw3d4whty3"
 }
+
 ```  
 
 ---
@@ -1987,27 +2211,33 @@ Returns a list of pairs of online peer IPv6:port and its node protocol network v
 
 **Request:**
 ```json
+
 {
   "action": "peers"
 }
+
 ```  
  
 **Response version 8.0+:**
 ```json
+
 {
   "peers": {
     "[::ffff:172.17.0.1]:32841": "16"
   }
 }
+
 ```   
 
 **Response before version 8.0:**
 ```json
+
 {
   "peers": [
       "[::ffff:172.17.0.1]:32841"
   ]
 }
+
 ```   
 **Optional "peer_details"**
 
@@ -2023,10 +2253,12 @@ _version 20.0 will generate the node_id with `node_` prefix, earlier versions wi
   "action": "peers",
   "peer_details": "true"
 }
+
 ```
 
 **Response:**
 ```json
+
 {
   "peers": {
     "[::ffff:172.17.0.1]:7075": {
@@ -2036,6 +2268,7 @@ _version 20.0 will generate the node_id with `node_` prefix, earlier versions wi
     }
   }
 }
+
 ```
 
 ---
@@ -2048,15 +2281,19 @@ Scans all accounts, checks for unconfirmed blocks in account chains, and then qu
 
 **Request**
 ```json
+
 { 
   "action": "populate_backlog"   
 }
+
 ```
 **Response**
 ```json
+
 {
   "success": "" 
 }
+
 ```
 
 ---
@@ -2070,6 +2307,7 @@ Note: after v25.0, it is possible that the block processing queue can internally
 
 **Request:**
 ```json
+
 {
   "action": "process",
   "json_block": "true",
@@ -2086,12 +2324,15 @@ Note: after v25.0, it is possible that the block processing queue can internally
     "work": "000bc55b014e807d"
   }
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "hash": "E2FB233EF4554077A7BF1AA85851D5BF0B36965D2B0FB504B2BC778AB89917D3"
 }
+
 ```
 **Optional "force"**  
 _version 13.1+_  
@@ -2129,17 +2370,21 @@ Returns a list of block hashes which have not yet been received by this account.
 
 **Request:**
 ```json
+
 {
   "action": "receivable",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda",
   "count": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": [ "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F" ]
 }
+
 ```   
 **Optional "count"**  
 Number. Determines limit of number of blocks to return.
@@ -2150,20 +2395,24 @@ Number (128 bit, decimal). Returns a list of receivable block hashes with amount
 
 **Request:**
 ```json
+
 {
   "action": "receivable",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda",
   "count": "1",
   "threshold": "1000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks" : {
     "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F": "6000000000000000000000000000000"
   }
 }
+
 ```  
 **Optional "source"**  
 _version 9.0+_   
@@ -2171,15 +2420,18 @@ Boolean, false by default. Returns a list of receivable block hashes with amount
 
 **Request:**
 ```json
+
 {
   "action": "receivable",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda",
   "count": "1",
   "source": "true"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks" : {
     "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F": {
@@ -2188,6 +2440,7 @@ Boolean, false by default. Returns a list of receivable block hashes with amount
     }
   }
 }
+
 ```  
 **Optional "include_active"**
 
@@ -2196,12 +2449,14 @@ Boolean, false by default. Include active blocks without finished confirmations
 
 **Request:**
 ```json
+
 {
   "action": "receivable",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda",
   "count": "1",
   "include_active": "true"
 }
+
 ```  
 
 **Optional "min_version"**
@@ -2233,16 +2488,20 @@ Check whether block is receivable by **hash**
 
 **Request:**
 ```json
+
 {
   "action": "receivable_exists",
   "hash": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "exists" : "1"
 }
+
 ```
 
 **Optional "include_active"**
@@ -2252,11 +2511,13 @@ Boolean, false by default. Include active blocks without finished confirmations
 
 **Request:**
 ```json
+
 {
   "action": "receivable_exists",
   "hash": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "include_active": "true"
 }
+
 ```  
 
 **Optional "include_only_confirmed"**
@@ -2271,12 +2532,15 @@ Returns a list of pairs of representative and its voting weight
 
 **Request:**
 ```json
+
 {
   "action": "representatives"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "representatives": {
     "nano_1111111111111111111111111111111111111111111111111117353trpda": "3822372327060170000000000000000000000",
@@ -2284,6 +2548,7 @@ Returns a list of pairs of representative and its voting weight
     "nano_114nk4rwjctu6n6tr6g6ps61g1w3hdpjxfas4xj1tq6i8jyomc5d858xr1xi": "0"
   }
 }
+
 ```
 **Optional "count"**
 
@@ -2304,12 +2569,15 @@ Returns a list of online representative accounts that have voted recently
 
 **Request:**
 ```json
+
 {
   "action": "representatives_online"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "representatives": [
     "nano_1111111111111111111111111111111111111111111111111117353trpda",
@@ -2317,11 +2585,13 @@ Returns a list of online representative accounts that have voted recently
     "nano_114nk4rwjctu6n6tr6g6ps61g1w3hdpjxfas4xj1tq6i8jyomc5d858xr1xi"
   ]
 }
+
 ```
 _versions 11.2–17.1_   
 Returns a list of pairs of online representative accounts that have voted recently and empty strings  
 **Response:**
 ```json
+
 {
   "representatives" : {
     "nano_1111111111111111111111111111111111111111111111111117353trpda": "",
@@ -2329,6 +2599,7 @@ Returns a list of pairs of online representative accounts that have voted recent
     "nano_114nk4rwjctu6n6tr6g6ps61g1w3hdpjxfas4xj1tq6i8jyomc5d858xr1xi": ""
   }
 }
+
 ```
 **Optional "weight"**
 
@@ -2336,6 +2607,7 @@ _version 17.0+_
 Boolean, false by default. Returns voting weight for each representative.  
 **Response:**
 ```json
+
 {
   "representatives": {
     "nano_114nk4rwjctu6n6tr6g6ps61g1w3hdpjxfas4xj1tq6i8jyomc5d858xr1xi": {
@@ -2343,6 +2615,7 @@ Boolean, false by default. Returns voting weight for each representative.
     }
   }
 }
+
 ```
 
 **Optional "accounts"**  
@@ -2350,18 +2623,22 @@ Array of accounts. Returned list is filtered for only these accounts.
 
 **Request:**
 ```json
+
 {
   "action": "representatives_online",
   "accounts": ["nano_1q3hqecaw15cjt7thbtxu3pbzr1eihtzzpzxguoc37bj1wc5ffoh7w74gi6p", "nano_1111111111111111111111111111111111111111111111111117353trpda"]
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "representatives": [
     "nano_1q3hqecaw15cjt7thbtxu3pbzr1eihtzzpzxguoc37bj1wc5ffoh7w74gi6p"
   ]
 }
+
 ```
 
 ---
@@ -2371,13 +2648,16 @@ Rebroadcast blocks starting at **hash** to the network
 
 **Request:**
 ```json
+
 {
   "action": "republish",
   "hash": "991CF190094C00F0B68E2E5F75F6BEE95A2E0BD93CEAA4A6734DB9F19B728948"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": "",
   "blocks": [
@@ -2385,6 +2665,7 @@ Rebroadcast blocks starting at **hash** to the network
     "A170D51B94E00371ACE76E35AC81DC9405D5D04D4CEBC399AEACE07AE05DD293"
   ]
 }
+
 ```   
 
 **Optional "sources"**
@@ -2394,15 +2675,18 @@ Boolean, false by default. Additionally rebroadcast source chain blocks for rece
 
 **Request:**
 ```json
+
 {
   "action": "republish",
   "hash": "90D0C16AC92DD35814E84BFBCC739A039615D0A42A76EF44ADAEF1D99E9F8A35",
   "count": "1",
   "sources": "2"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": [
     "991CF190094C00F0B68E2E5F75F6BEE95A2E0BD93CEAA4A6734DB9F19B728948",
@@ -2410,6 +2694,7 @@ Boolean, false by default. Additionally rebroadcast source chain blocks for rece
     "90D0C16AC92DD35814E84BFBCC739A039615D0A42A76EF44ADAEF1D99E9F8A35"
   ]
 }
+
 ```   
 
 **Optional "destinations"**
@@ -2419,15 +2704,18 @@ Boolean, false by default. Additionally rebroadcast destination chain blocks fro
 
 **Request:**
 ```json
+
 {
   "action": "republish",
   "hash": "A170D51B94E00371ACE76E35AC81DC9405D5D04D4CEBC399AEACE07AE05DD293",
   "count": "1",
   "destinations": "2"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": [
     "A170D51B94E00371ACE76E35AC81DC9405D5D04D4CEBC399AEACE07AE05DD293",
@@ -2435,6 +2723,7 @@ Boolean, false by default. Additionally rebroadcast destination chain blocks fro
     "18563C814A54535B7C12BF76A0E23291BA3769536634AB90AD0305776A533E8E"
   ]
 }
+
 ```   
 
 ---
@@ -2445,6 +2734,7 @@ Signing provided **block** with private **key** or key of **account** from **wal
 
 **Request with private key:**
 ```json
+
 {
   "action": "sign",
   "json_block": "true",
@@ -2461,10 +2751,12 @@ Signing provided **block** with private **key** or key of **account** from **wal
     "work": "000bc55b014e807d"
   }
 }
+
 ```
 
 **Request with account from wallet:**
 ```json
+
 {
   "action": "sign",
   "json_block": "true",
@@ -2482,9 +2774,11 @@ Signing provided **block** with private **key** or key of **account** from **wal
     "work": "000bc55b014e807d"
   }
 }
+
 ```
 **Response:**
 ```json
+
 {
   "signature": "2A71F3877033F5966735F260E906BFCB7FA82CDD543BCD1224F180F85A96FC26CB3F0E4180E662332A0DFE4EE6A0F798A71C401011E635604E532383EC08C70D",
   "block": {
@@ -2499,6 +2793,7 @@ Signing provided **block** with private **key** or key of **account** from **wal
     "work": "000bc55b014e807d"
   }
 }
+
 ```
 
 **Optional "json_block"**
@@ -2512,16 +2807,20 @@ _Requires configuration changes. Set "rpc.enable_sign_hash" to "true"_
 
 **Request:**
 ```json
+
 {
   "action": "sign",
   "hash": "E2FB233EF4554077A7BF1AA85851D5BF0B36965D2B0FB504B2BC778AB89917D3"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "signature": "2A71F3877033F5966735F260E906BFCB7FA82CDD543BCD1224F180F85A96FC26CB3F0E4180E662332A0DFE4EE6A0F798A71C401011E635604E532383EC08C70D"
 }
+
 ```  
 
 ---
@@ -2532,14 +2831,17 @@ For configuration and other details, please see [Statistics from RPC](/running-a
 
 **Request counters:**
 ```json
+
 {
   "action": "stats",
   "type": "counters"
 }
+
 ```
 
 **Counters response:**
 ```json
+
 {
   "type": "counters",
   "created": "2018.03.29 01:46:36",
@@ -2561,20 +2863,24 @@ For configuration and other details, please see [Statistics from RPC](/running-a
     ...
   ]
 }
+
 ```
 
 _version 18.0+ also returns "stat_duration_seconds": the number of seconds since startup or since the last "stats_clear" call_
 
 **Request samples:**
 ```json
+
 {
   "action": "stats",
   "type": "samples"
 }
+
 ```
 
 **Samples response:**
 ```json
+
 {
   "type": "samples",
   "created": "2018.03.29 01:47:08",
@@ -2596,20 +2902,24 @@ _version 18.0+ also returns "stat_duration_seconds": the number of seconds since
     ...
    ]
 }
+
 ```
 _version 18.0+_  
 NOTE: This call is for debug purposes only and is unstable as returned objects may be frequently changed.
 
 **Request objects:**
 ```json
+
 {
   "action": "stats",
   "type": "objects"
 }
+
 ```
 
 **Objects response:**
 ```json
+
 {
   "node": {
     "ledger": {
@@ -2631,6 +2941,7 @@ NOTE: This call is for debug purposes only and is unstable as returned objects m
     ...
   }
 }
+
 ```
 
 _version 22.0+_  
@@ -2638,15 +2949,18 @@ NOTE: This call is for debug purposes only and is unstable as returned objects m
 
 **Request database:**
 ```json
+
 {
   "action": "stats",
   "type": "database"
 }
+
 ```
 
 **Database response:**  
 **LMDB:**
 ```json
+
 {
     "branch_pages": "0",
     "depth": "1",
@@ -2655,9 +2969,11 @@ NOTE: This call is for debug purposes only and is unstable as returned objects m
     "overflow_pages": "0",
     "page_size": "4096"
 }
+
 ```
 **RocksDB:**  
 ```json
+
 {
     "cur-size-all-mem-tables": "74063072",
     "size-all-mem-tables": "487744504",
@@ -2670,6 +2986,7 @@ NOTE: This call is for debug purposes only and is unstable as returned objects m
     "block-cache-capacity": "318767104",
     "block-cache-usage": "150310696"
 }
+
 ```
 ---
 
@@ -2681,15 +2998,19 @@ Clears all collected statistics. The "stat_duration_seconds" value in the "stats
 
 **Request:**
 ```json
+
 {
   "action": "stats_clear"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""
 }
+
 ```
 
 ---
@@ -2702,15 +3023,19 @@ Method to safely shutdown node
 
 **Request:**
 ```json
+
 {
   "action": "stop"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""
 }
+
 ```  
 
 ---
@@ -2720,19 +3045,23 @@ Returns a list of block hashes in the account chain starting at **block** up to
 
 **Request:**
 ```json
+
 {
   "action": "successors",
   "block": "991CF190094C00F0B68E2E5F75F6BEE95A2E0BD93CEAA4A6734DB9F19B728948",
   "count": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks" : [
     "991CF190094C00F0B68E2E5F75F6BEE95A2E0BD93CEAA4A6734DB9F19B728948"
   ]
 }
+
 ```
 **Optional "offset"**
 
@@ -2752,12 +3081,15 @@ Return metrics from other nodes on the network. By default, returns a summarized
 [Networking - node telemetry](/protocol-design/networking#node-telemetry) contains more detailed information on the protocol implementation of telemetry.  
 **Request:**
 ```json
+
 {
   "action": "telemetry"
 }
+
 ```
 **Response:**
 ```json
+
 {
     "block_count": "214104509",
     "cemented_count": "214104509",
@@ -2783,6 +3115,7 @@ Return metrics from other nodes on the network. By default, returns a summarized
     "node_id": "node_3odec59q6i9qarh5txyrxmu3aqhfzm54mxoxgtumwpzyq6obxqktdzcxkfag",
     "signature": "067523993D0B4C07525DF4C5AA814FBCC40875F868C2A04A85AC288F75E152763196B7DCB11240921F6D8BA92E3E9F094D8F2F9D8B0970114CDAD48838372100"
 }
+
 ```
 
 This contains a summarized view of the network with 10% of lower/upper bound results removed to reduce the effect of outliers. Returned values are calculated as follows:
@@ -2816,14 +3149,17 @@ When setting raw to true metrics from all nodes are displayed. It additionally c
 
 **Request:**
 ```json
+
 {
   "action": "telemetry",
   "raw" : "true"
 }
+
 ```
 
 **Response:**
 ```json
+
 {
   "metrics": [
     {
@@ -2845,16 +3181,19 @@ When setting raw to true metrics from all nodes are displayed. It additionally c
     ...
   ]
 }
+
 ```
 
 **Optional "address" & "port"**  
 Get metrics from a specific peer. It accepts both ipv4 and ipv6 addresses
 ```json
+
 {
   "action": "telemetry",
   "address": "246.125.123.456",
   "port": "7075"
 }
+
 ```
 
 !!!tip "Requesting telemetry data from the local node"
@@ -2867,16 +3206,20 @@ Check whether **account** is a valid account number using checksum
 
 **Request:**
 ```json
+
 {
   "action": "validate_account_number",
   "account": "nano_1111111111111111111111111111111111111111111111111117353trpda"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "valid" : "1"
 }
+
 ```
 
 ---
@@ -2888,12 +3231,15 @@ _RPC Version always returns "1" as of 01/11/2018_
 
 **Request:**
 ```json
+
 {
   "action": "version"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "rpc_version": "1",
   "store_version": "14",
@@ -2904,6 +3250,7 @@ _RPC Version always returns "1" as of 01/11/2018_
   "network_identifier": "991CF190094C00F0B68E2E5F75F6BEE95A2E0BD93CEAA4A6734DB9F19B728948", // since v20.0
   "build_info": "Build Info <git hash> \"<compiler> version \" \"<compiler version string>\" \"BOOST <boost version>\" BUILT \"<build date>\"" // since v20.0
 }
+
 ```
 
 ---
@@ -2914,14 +3261,17 @@ Returns a list of pairs of unchecked block hashes and their json representation
 
 **Request:**
 ```json
+
 {
   "action": "unchecked",
   "json_block": "true",
   "count": "1",
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": {
     "87434F8041869A01C8F6F263B87972D7BA443A72E0A97D7A3FD0CCC2358FD6F9": {
@@ -2937,6 +3287,7 @@ Returns a list of pairs of unchecked block hashes and their json representation
     }
   }
 }
+
 ```
 
 ---
@@ -2949,15 +3300,19 @@ Clear unchecked synchronizing blocks
 
 **Request:**
 ```json
+
 {
     "action": "unchecked_clear"
 }
+
 ```  
 **Response:**
 ```json
+
 {
     "success": ""
 }
+
 ```  
 
 ---
@@ -2968,14 +3323,17 @@ Retrieves a json representation of unchecked synchronizing block by **hash**. Us
 
 **Request:**
 ```json
+
 {
   "action": "unchecked_get",
   "json_block": "true",
   "hash": "19BF0C268C2D9AED1A8C02E40961B67EA56B1681DE274CD0C50F3DD972F0655C"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "modified_timestamp": "1565856525",
   "contents": {
@@ -2990,6 +3348,7 @@ Retrieves a json representation of unchecked synchronizing block by **hash**. Us
     "work": "0dfb32653e189699"
   }
 }
+
 ```
 **Optional "json_block"**
 
@@ -3006,15 +3365,18 @@ Retrieves unchecked database keys, blocks hashes & a json representations of unc
 
 **Request:**
 ```json
+
 {
   "action": "unchecked_keys",
   "json_block": "true",
   "key": "19BF0C268C2D9AED1A8C02E40961B67EA56B1681DE274CD0C50F3DD972F0655C",
   "count": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "unchecked": [
     {
@@ -3035,6 +3397,7 @@ Retrieves unchecked database keys, blocks hashes & a json representations of unc
     }
   ]
 }
+
 ```   
 
 **Optional "json_block"**
@@ -3054,20 +3417,24 @@ Returns the total receivable balance for unopened accounts in the local database
 
 **Request:**
 ```json
+
 {
   "action": "unopened",
   "account": "nano_1111111111111111111111111111111111111111111111111111hifc8npp",
   "count": "1"
 }
+
 ```   
 
 **Response:**
 ```json 
+
 {
   "accounts": {
     "nano_1111111111111111111111111111111111111111111111111111hifc8npp": "207034077034226183413773082289554618448"
   }
 }
+
 ```   
 
 **Optional "threshold"**  
@@ -3081,15 +3448,19 @@ Return node uptime in seconds
 
 **Request:**
 ```json
+
 {
   "action": "uptime"
 }
+
 ```  
 **Response:**
 ```json
+
 {
     "seconds": "6000"
 }
+
 ```  
 
 ---
@@ -3102,16 +3473,20 @@ Stop generating **work** for block
 
 **Request:**
 ```json
+
 {
   "action": "work_cancel",
   "hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""
 }
+
 ```  
 
 ---
@@ -3124,19 +3499,23 @@ Generates **work** for block. **hash** is the frontier of the account or in the
 
 **Request:**
 ```json
+
 {
   "action": "work_generate",
   "hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "work": "2b3d689bbcb21dca",
   "difficulty": "fffffff93c41ec94", // of the resulting work
   "multiplier": "1.182623871097636", // since v19.0, calculated from default base difficulty
   "hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2" // since v20.0
 }
+
 ```  
 
 **Optional "use_peers"**
@@ -3193,17 +3572,21 @@ Add specific **IP address** and **port** as work peer for node until restart
 
 **Request:**
 ```json
+
 {
   "action": "work_peer_add",
   "address": "::ffff:172.17.0.1",
   "port": "7076"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""
 }
+
 ```  
 
 ---
@@ -3215,17 +3598,21 @@ _enable_control required, version 8.0+_
 
 **Request:**
 ```json
+
 {
   "action": "work_peers"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "work_peers": [
     "::ffff:172.17.0.1:7076"
   ]
 }
+
 ```  
 
 ---
@@ -3238,15 +3625,19 @@ Clear work peers node list until restart
 
 **Request:**
 ```json
+
 {
   "action": "work_peers_clear"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""
 }
+
 ```  
 
 ---
@@ -3266,29 +3657,35 @@ Check whether **work** is valid for block. Provides two values: **valid_all** is
 
 **Request:**
 ```json
+
 {
   "action": "work_validate",
   "work": "2bf29ef00786a6bc",
   "hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2"
 }
+
 ```  
 **Response since v21.0:**
 ```json
+
 {
   "valid_all": "1",
   "valid_receive": "1",
   "difficulty": "fffffff93c41ec94",
   "multiplier": "1.182623871097636" // calculated from the default base difficulty
 }
+
 ```
 
 ??? abstract "Response up to v20.0"
     ```json
+
     {
       "valid": "1",
       "difficulty": "fffffff93c41ec94", // since v19.0
       "multiplier": "9.4609" // since v19.0
     }
+
     ```
 
 **Optional "difficulty"**
@@ -3298,15 +3695,18 @@ Difficulty value (16 hexadecimal digits string, 64 bit). Uses **difficulty** val
 
 **Request with given "difficulty"**  
 ```json
+
 {
   "action": "work_validate",
   "difficulty": "ffffffffffffffff",
   "work": "2bf29ef00786a6bc",
   "hash": "718CC2121C3E641059BC1C2CFC45666C99E8AE922F7A807B7D07B62C995D79E2"
 }
+
 ```
 **Response with given "difficulty:**
 ```json
+
 {
   "valid": "0",
   "valid_all": "1", // since v21.0
@@ -3314,6 +3714,7 @@ Difficulty value (16 hexadecimal digits string, 64 bit). Uses **difficulty** val
   "difficulty": "fffffff93c41ec94",
   "multiplier": "1.182623871097636"
 }
+
 ```
 
 **Optional "multiplier"**
@@ -3344,17 +3745,21 @@ Creates a new account, insert next deterministic key in **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "account_create",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```
   
 **Response:**
 ```json
+
 {
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
+
 ```
 **Optional "index"**
 
@@ -3363,11 +3768,13 @@ unset by default. Indicates which index to create account for starting with 0
 
 **Request:**
 ```json
+
 {
   "action": "account_create",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "index": "1"
 }
+
 ```
 
 **Optional "work"**
@@ -3377,11 +3784,13 @@ Boolean, true by default. Setting false disables work generation after creating
 
 **Request:**
 ```json
+
 {
   "action": "account_create",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "work": "false"
 }
+
 ```
 
 ---
@@ -3391,18 +3800,22 @@ Lists all the accounts inside **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "account_list",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "accounts": [
     "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
   ]
 }
+
 ```
 
 ---
@@ -3415,6 +3828,7 @@ Moves **accounts** from **source** to **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "account_move",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
@@ -3423,12 +3837,15 @@ Moves **accounts** from **source** to **wallet**
     "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
   ]
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "moved" : "1"
 }
+
 ```
 
 ---
@@ -3441,17 +3858,21 @@ Remove **account** from **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "account_remove",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "account": "nano_39a73oy5ungrhxy5z5oao1xso4zo7dmgpjd4u74xcrx3r1w6rtazuouw6qfi"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "removed": "1"
 }
+
 ```
 
 ---
@@ -3464,18 +3885,22 @@ Sets the representative for **account** in **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "account_representative_set",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "account": "nano_39a73oy5ungrhxy5z5oao1xso4zo7dmgpjd4u74xcrx3r1w6rtazuouw6qfi",
   "representative": "nano_16u1uufyoig8777y6r8iqjtrw8sg8maqrm36zzcm95jmbd9i9aj5i8abr8u5"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "block": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```
 **Optional "work"**
 
@@ -3492,20 +3917,24 @@ Creates new accounts, insert next deterministic keys in **wallet** up to **count
 
 **Request:**
 ```json
+
 {
   "action": "accounts_create",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "2"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "accounts": [
     "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000",
     "nano_1e5aqegc1jb7qe964u4adzmcezyo6o146zb8hm6dft8tkp79za3s00000000"
   ]
 }
+
 ```
 **Optional enabling work generation**  
 _version 11.2+_  
@@ -3513,12 +3942,14 @@ Boolean, false by default. Enables work generation after creating accounts
 
 **Request:**
 ```json
+
 {
   "action": "accounts_create",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "2",
   "work": "true"
 }
+
 ```  
 ***Note:*** Before version 11.2 work generation was enabled by default, if you want to disable work generation for previous versions, use "work": "false"
 
@@ -3537,17 +3968,21 @@ Changes the password for **wallet** to **password**
 
 **Request:**
 ```json
+
 {
   "action": "password_change",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "password": "test"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "changed" : "1"
 }
+
 ```
 
 ---
@@ -3557,17 +3992,21 @@ Enters the **password** in to **wallet** to unlock it
 
 **Request:**
 ```json
+
 {
   "action": "password_enter",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "password": "test"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "valid": "1"
 }
+
 ```
 
 ---
@@ -3577,16 +4016,20 @@ Checks whether the password entered for **wallet** is valid
 
 **Request:**
 ```json
+
 {
   "action": "password_valid",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "valid" : "1"
 }
+
 ```
 
 ---
@@ -3599,18 +4042,22 @@ Receive receivable **block** for **account** in **wallet**. If receiving the blo
 
 **Request:**
 ```json
+
 {
   "action": "receive",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000",
   "block": "53EAA25CE28FA0E6D55EA9704B32604A736966255948594D55CBB05267CECD48"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "block": "EE5286AB32F580AB65FD84A69E107C69FBEB571DEC4D99297E19E3FA5529547B"
 }
+
 ```
 **Optional "work"**
 
@@ -3627,15 +4074,19 @@ Returns receive minimum for node wallet
 
 **Request:**
 ```json
+
 {
   "action": "receive_minimum"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1000000000000000000000000"
 }
+
 ```
 
 ---
@@ -3648,16 +4099,20 @@ Set **amount** as new receive minimum for node wallet until restart
 
 **Request:**
 ```json
+
 {
   "action": "receive_minimum_set",
   "amount": "1000000000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""
 }
+
 ```
 
 ---
@@ -3679,16 +4134,20 @@ Tells the node to look for receivable blocks for any account in **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "search_receivable",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "started": "1"
 }
+
 ```
 ---
 
@@ -3709,15 +4168,19 @@ Tells the node to look for receivable blocks for any account in all available wa
 
 **Request:**
 ```json
+
 {
   "action": "search_receivable_all"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success": ""  
 }
+
 ```
 
 ---
@@ -3733,6 +4196,7 @@ Send **amount** from **source** in **wallet** to **destination**
 
 **Request:**
 ```json
+
 {
   "action": "send",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
@@ -3741,12 +4205,15 @@ Send **amount** from **source** in **wallet** to **destination**
   "amount": "1000000",
   "id": "your-unique-id"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "block": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```
 Proof of Work is precomputed for **one** transaction in the background when you are using the node wallet to track accounts.  If it has been a while since your last transaction it will send instantly, the next one will need to wait for Proof of Work to be generated.
 
@@ -3765,6 +4232,7 @@ Using the same id for requests with different parameters (wallet, source, destin
 
 **Request:**
 ```json
+
 {
   "action": "send",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
@@ -3773,12 +4241,15 @@ Using the same id for requests with different parameters (wallet, source, destin
   "amount": "1000000",
   "id": "7081e2b8fec9146e"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "block": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```
 
 Sending the request again will yield the same block, and will not affect the ledger.
@@ -3790,6 +4261,7 @@ Work value (16 hexadecimal digits string, 64 bit). Uses **work** value for block
 
 **Request:**
 ```json
+
 {
   "action": "send",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
@@ -3798,6 +4270,7 @@ Work value (16 hexadecimal digits string, 64 bit). Uses **work** value for block
   "amount": "1000000",
   "work": "2bf29ef00786a6bc"
 }
+
 ```  
 
 ---
@@ -3815,17 +4288,21 @@ Add an adhoc private key **key** to **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_add",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "key": "34F0A37AAD20F4A260F0A5B3CB3D7FB50673212263E58A380BC10474BB039CE4"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
+
 ```
 **Optional disabling work generation**
 
@@ -3834,12 +4311,14 @@ Boolean, false by default. Disables work generation after adding account
 
 **Request:**
 ```json
+
 {
   "action": "wallet_add",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "key": "34F0A37AAD20F4A260F0A5B3CB3D7FB50673212263E58A380BC10474BB039CE4",
   "work": "false"
 }
+
 ```  
 
 ---
@@ -3852,6 +4331,7 @@ Add watch-only **accounts** to **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_add_watch",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
@@ -3860,12 +4340,15 @@ Add watch-only **accounts** to **wallet**
     "nano_111111111111111111111111111111111111111111111111111000000000"
   ]
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success" : ""
 }
+
 ```
 
 ---
@@ -3879,13 +4362,16 @@ Returns how many raw is owned and how many have not yet been received by all acc
 
 **Request:**
 ```json
+
 {
   "action": "wallet_balances",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "balances" : {
     "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000": {
@@ -3895,6 +4381,7 @@ Returns how many raw is owned and how many have not yet been received by all acc
     }
   }
 }
+
 ```
 **Optional "threshold"**
 
@@ -3912,19 +4399,23 @@ Changes seed for **wallet** to **seed**.  ***Notes:*** Clear all deterministic a
 
 **Request:**
 ```json
+
 {
   "action": "wallet_change_seed",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "seed": "74F2B37AAD20F4A260F0A5B3CB3D7FB51673212263E58A380BC10474BB039CEE"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "success" : "",
   "last_restored_account": "nano_1mhdfre3zczr86mp44jd3xft1g1jg66jwkjtjqixmh6eajfexxti7nxcot9c",
   "restored_count": "1"
 }
+
 ```
 
 **Optional "count"**
@@ -3939,17 +4430,21 @@ Check whether **wallet** contains **account**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_contains",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "exists": "1"
 }
+
 ```
 
 ---
@@ -3962,15 +4457,19 @@ Creates a new random wallet id
 
 **Request:**
 ```json
+
 {
   "action": "wallet_create"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```
 **Optional "seed"**
 
@@ -3987,16 +4486,20 @@ Destroys **wallet** and all contained accounts
 
 **Request:**
 ```json
+
 {
   "action": "wallet_destroy",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "destroyed": "1"
 }
+
 ```
 
 ---
@@ -4006,16 +4509,20 @@ Return a json representation of **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_export",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "json" : "{\"0000000000000000000000000000000000000000000000000000000000000000\": \"0000000000000000000000000000000000000000000000000000000000000001\"}"
 }
+
 ```
 
 ---
@@ -4025,18 +4532,22 @@ Returns a list of pairs of account and block hash representing the head block st
 
 **Request:**
 ```json
+
 {
   "action": "wallet_frontiers",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "frontiers": {
     "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
   }
 }
+
 ```
 
 ---
@@ -4049,13 +4560,16 @@ Reports send/receive information for accounts in wallet. Change blocks are skipp
 
 **Request:**
 ```json
+
 {
   "action": "wallet_history",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "history":
   [
@@ -4077,6 +4591,7 @@ Reports send/receive information for accounts in wallet. Change blocks are skipp
     }
   ]
 }
+
 ```
 **Optional "modified_since"**
 
@@ -4102,13 +4617,16 @@ Given a **wallet** id, from all of the accounts in the wallet, returns:
 
 **Request:**
 ```json
+
 {
   "action": "wallet_info",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "balance": "10000",
   "pending": "10000",
@@ -4120,6 +4638,7 @@ Given a **wallet** id, from all of the accounts in the wallet, returns:
   "accounts_block_count": "14",
   "accounts_cemented_block_count": "13"
 }
+
 ```
 
 ---
@@ -4136,13 +4655,16 @@ Returns frontier, open block, change representative block, balance, last modifie
 
 **Request:**
 ```json
+
 {
   "action": "wallet_ledger",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "accounts": {
     "nano_11119gbh8hb4hj1duf7fdtfyf5s75okzxdgupgpgm1bj78ex3kgy7frt3s9n": {
@@ -4155,6 +4677,7 @@ Returns frontier, open block, change representative block, balance, last modifie
     }
   }
 }
+
 ```  
 **Optional "representative", "weight", "receivable"**
 
@@ -4162,6 +4685,7 @@ Booleans, false by default. Additionally returns representative, voting weight,
 
 **Request:**
 ```json
+
 {
   "action": "wallet_ledger",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
@@ -4169,9 +4693,11 @@ Booleans, false by default. Additionally returns representative, voting weight,
   "weight": "true",
   "receivable": "true"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "accounts": {
     "nano_11119gbh8hb4hj1duf7fdtfyf5s75okzxdgupgpgm1bj78ex3kgy7frt3s9n": {
@@ -4188,6 +4714,7 @@ Booleans, false by default. Additionally returns representative, voting weight,
     }
   }
 }
+
 ```  
 **Optional "modified_since"**
 
@@ -4203,16 +4730,20 @@ Locks **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_lock",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "locked": "1"
 }
+
 ```
 
 ---
@@ -4222,16 +4753,20 @@ Checks whether **wallet** is locked
 
 **Request:**
 ```json
+
 {
   "action": "wallet_locked",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "locked": "0"
 }
+
 ```
 ---
 
@@ -4252,20 +4787,24 @@ Returns a list of block hashes which have not yet been received by accounts in t
 
 **Request:**
 ```json
+
 {
   "action": "wallet_receivable",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": {
     "nano_1111111111111111111111111111111111111111111111111117353trpda": ["142A538F36833D1CC78B94E11C766F75818F8B940771335C6C1B8AB880C5BB1D"],
     "nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3": ["4C1FEEF0BEA7F50BE35489A1233FE002B212DEA554B55B1B470D78BD8F210C74"]
   }
 }
+
 ```  
 **Optional "threshold"**
 
@@ -4273,15 +4812,18 @@ Number (128 bit, decimal). Returns a list of receivable block hashes with amount
 
 **Request:**
 ```json
+
 {
   "action": "wallet_receivable",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "1",
   "threshold": "1000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": {
     "nano_1111111111111111111111111111111111111111111111111117353trpda": {
@@ -4292,6 +4834,7 @@ Number (128 bit, decimal). Returns a list of receivable block hashes with amount
     }
   }
 }
+
 ```  
 **Optional "source"**
 
@@ -4300,15 +4843,18 @@ Boolean, false by default. Returns a list of receivable block hashes with amount
 
 **Request:**
 ```json
+
 {
   "action": "wallet_receivable",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "1",
   "source": "true"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": {
     "nano_1111111111111111111111111111111111111111111111111117353trpda": {
@@ -4325,6 +4871,7 @@ Boolean, false by default. Returns a list of receivable block hashes with amount
     }
   }
 }
+
 ```  
 **Optional "include_active"**
 
@@ -4333,12 +4880,14 @@ Boolean, false by default. Include active blocks without finished confirmations
 
 **Request:**
 ```json
+
 {
   "action": "wallet_receivable",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "1",
   "include_active": "true"
 }
+
 ```  
 
 **Optional "min_version"**
@@ -4358,16 +4907,20 @@ Returns the default representative for **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_representative",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "representative": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
+
 ```
 
 ---
@@ -4380,17 +4933,21 @@ Sets the default **representative** for **wallet** _(used only for new accounts,
 
 **Request:**
 ```json
+
 {
   "action": "wallet_representative_set",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "representative": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "set": "1"
 }
+
 ```
 
 **Optional "update_existing_accounts"**
@@ -4408,14 +4965,17 @@ Rebroadcast blocks for accounts from **wallet** starting at frontier down to **c
 
 **Request:**
 ```json
+
 {
   "action": "wallet_republish",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "count": "2"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "blocks": [
     "991CF190094C00F0B68E2E5F75F6BEE95A2E0BD93CEAA4A6734DB9F19B728948",
@@ -4423,6 +4983,7 @@ Rebroadcast blocks for accounts from **wallet** starting at frontier down to **c
     "90D0C16AC92DD35814E84BFBCC739A039615D0A42A76EF44ADAEF1D99E9F8A35"
   ]       
 }
+
 ```   
 
 ---
@@ -4435,18 +4996,22 @@ Returns a list of pairs of account and work from **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "wallet_work_get",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "works": {
     "nano_1111111111111111111111111111111111111111111111111111hifc8npp": "432e5cf728c90f4f"
   }
 }
+
 ```  
 
 ---
@@ -4459,17 +5024,21 @@ Retrieves work for **account** in **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "work_get",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "account": "nano_1111111111111111111111111111111111111111111111111111hifc8npp"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "work": "432e5cf728c90f4f"
 }
+
 ```  
 
 ---
@@ -4482,18 +5051,22 @@ Set **work** for **account** in **wallet**
 
 **Request:**
 ```json
+
 {
   "action": "work_set",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F",
   "account": "nano_1111111111111111111111111111111111111111111111111111hifc8npp",
   "work": "0000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
     "success": ""
 }
+
 ```  
 
 ---
@@ -4507,16 +5080,20 @@ Convert `nano` amount (10^30 raw) into `raw` (10^0)
 
 **Request:**
 ```json
+
 {
   "action": "nano_to_raw",
   "amount": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1000000000000000000000000000000"
 }
+
 ```
 
 ### raw_to_nano    
@@ -4524,16 +5101,20 @@ Convert `raw` amount (10^0) into `nano` (10^30 raw)
 
 **Request:**
 ```json
+
 {
   "action": "raw_to_nano",
   "amount": "1000000000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1"
 }
+
 ```
 
 ---
@@ -4562,13 +5143,16 @@ Returns the difficulty values (16 hexadecimal digits string, 64 bit) and related
 
 **Request:**
 ```json
+
 {
   "action": "active_difficulty"
 }
+
 ```  
 
 **Response:**
 ```json
+
 {
     "deprecated": "1",
     "network_minimum": "fffffff800000000",
@@ -4577,6 +5161,7 @@ Returns the difficulty values (16 hexadecimal digits string, 64 bit) and related
     "network_receive_current": "fffffe0000000000", // since V21.2
     "multiplier": "1"
 }
+
 ```
 
 **Optional "include_trend"**
@@ -4586,14 +5171,17 @@ Note: Before v20, the sampling period was between 16 and 36 seconds.
 
 **Request:**
 ```json
+
 {
   "action": "active_difficulty",
   "include_trend": "true"
 }
+
 ```
 
 **Response:**
 ```json
+
 {
   ...,
   "difficulty_trend": [
@@ -4605,6 +5193,7 @@ Note: Before v20, the sampling period was between 16 and 36 seconds.
     "1.000000000000000"
   ]
 }
+
 ```
 
 ---
@@ -4629,16 +5218,20 @@ Divide a raw amount down by the krai ratio.
 
 **Request:**
 ```json
+
 {
   "action": "krai_from_raw",
   "amount": "1000000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1"
 }
+
 ```
 
 ---
@@ -4651,16 +5244,20 @@ Multiply an krai amount by the krai ratio.
 
 **Request:**
 ```json
+
 {
   "action": "krai_to_raw",
   "amount": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1000000000000000000000000000"
 }
+
 ```
 
 ---
@@ -4673,16 +5270,20 @@ Divide a raw amount down by the Mrai ratio.
 
 **Request:**
 ```json
+
 {
   "action": "mrai_from_raw",
   "amount": "1000000000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1"
 }
+
 ```
 
 ---
@@ -4695,16 +5296,20 @@ Multiply an Mrai amount by the Mrai ratio.
 
 **Request:**
 ```json
+
 {
   "action": "mrai_to_raw",
   "amount": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1000000000000000000000000000000"
 }
+
 ```
 
 ---
@@ -4721,15 +5326,19 @@ Removing node ID (restart required to take effect)
 
 **Request:**
 ```json
+
 {
   "action": "node_id_delete"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "deprecated": "1"
 }
+
 ```  
 
 ---
@@ -4742,16 +5351,20 @@ Divide a raw amount down by the rai ratio.
 
 **Request:**
 ```json
+
 {
   "action": "rai_from_raw",
   "amount": "1000000000000000000000000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1"
 }
+
 ```
 
 ---
@@ -4764,16 +5377,20 @@ Multiply an rai amount by the rai ratio.
 
 **Request:**
 ```json
+
 {
   "action": "rai_to_raw",
   "amount": "1"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "amount": "1000000000000000000000000"
 }
+
 ```
 
 ---
@@ -4804,15 +5421,19 @@ Returns the hash of the block which is having the confirmation height set for, e
 
 **Request:**
 ```json
+
 {
   "action": "confirmation_height_currently_processing"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "hash": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```
 
 ---
@@ -4822,12 +5443,15 @@ Reports the number of blocks in the ledger by type (send, receive, open, change,
 
 **Request:**
 ```json
+
 {
   "action": "block_count_type"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "send": "5016664",
   "receive": "4081228",
@@ -4837,6 +5461,7 @@ Reports the number of blocks in the ledger by type (send, receive, open, change,
   "state_v1": "10653709",
   "state": "14870246"
 }
+
 ```  
 
 ---
@@ -4846,16 +5471,20 @@ Begin a new payment session. Searches wallet for an account that's marked as ava
 
 **Request:**
 ```json
+
 {
   "action": "payment_begin",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "account" : "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000"
 }
+
 ```  
 
 ---
@@ -4865,16 +5494,20 @@ End a payment session.  Marks the account as available for use in a payment sess
 
 **Request:**
 ```json
+
 {
   "action": "payment_end",
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000",
   "wallet": "FFFD1BAEC8EC20814BBB9059B393051AAA8380F9B5A2E6B2489A277D81789EEE"
 }
+
 ```  
 **Response:**
 ```json
+
 {
 }
+
 ```   
 
 ---
@@ -4884,16 +5517,20 @@ Marks all accounts in wallet as available for being used as a payment session.
 
 **Request:**
 ```json
+
 {
   "action": "payment_init",
   "wallet": "000D1BAEC8EC208142C99059B393051BAC8380F9B5A2E6B2489A277D81789F3F"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "status": "Ready"
 }
+
 ```  
 
 ---
@@ -4903,17 +5540,21 @@ Wait for payment of 'amount' to arrive in 'account' or until 'timeout' milliseco
 
 **Request:**
 ```json
+
 {
   "action": "payment_wait",
   "account": "nano_3e3j5tkog48pnny9dmfzj1r16pg8t1e76dz5tmac6iq689wyjfpi00000000",
   "amount": "1",
   "timeout": "1000"
 }
+
 ```  
 **Response:**
 ```json
+
 {
   "deprecated": "1",
   "status" : "success"
 }
-```  
+
+```
diff --git a/docs/core-development/overview.md b/docs/core-development/overview.md
index 6513d3d7f..7cc22111c 100644
--- a/docs/core-development/overview.md
+++ b/docs/core-development/overview.md
@@ -16,7 +16,6 @@ It is recommended to have an understanding of how the nano protocol is designed
 - Participate in the community through [Discord](https://chat.nano.org)
 - Start perusing the code in the repositories below and don't be afraid to ask questions
 
-
 ## Code repositories
 
 The Nano Foundation manages the [`nanocurrency`](https://github.com/nanocurrency) GitHub Organization account which includes various repositories for nano tools and implementations. Below is a partial list of the most common repositories referenced.
diff --git a/docs/core-development/understanding-the-code.md b/docs/core-development/understanding-the-code.md
index 8967dfa04..d8b7230a7 100644
--- a/docs/core-development/understanding-the-code.md
+++ b/docs/core-development/understanding-the-code.md
@@ -34,6 +34,7 @@ All executables have `nano_` prefix and projects have a `main` function inside `
 The googletest (gtest) framework is used to validate a variety of functionality in the node, we do not currently use gmock in the codebase.  
 
 ### Running tests
+
 The dev network is forced for locally run tests, this lowers work and other settings to make it simpler to test.
 Build with `cmake -DNANO_TEST=ON ..`
 See docs.nano.org for more information. There may be intermittent failures, if so add them here https://github.com/nanocurrency/nano-node/issues/1121 and fix if possible.
@@ -47,12 +48,14 @@ See docs.nano.org for more information. There may be intermittent failures, if s
 **load_test** – This creates a dynamic number of nodes, sends blocks from 1 of the nodes (primary) and waits until all other nodes have the same number of blocks. This does not normally need to be modified but is run as part CI at the end.  
 
 **rpc_test** – All RPC tests go here. There is some boilerplate to follow which creates an `ipc_server` for the node which mimics out of process rpc commands communicating with it. Care must be taken when creating write transactions as they are not allowed on io-threads (https://github.com/nanocurrency/nano-node/pull/1264). To make sure this is adhered to when calling the RPC commands, there is an RAII object `scoped_io_thread_name_change` which changes the current thread (normally the main one) to be `io`, and restores it when the object goes out of scope. For instance
+
 ```
 ...
 scoped_thread_name_io.reset ();
 node.process (state_block);
 scoped_thread_name_io.renew ();
 ```
+
 **slow_test** – Any core tests which are not suitable for CI because they take a long time (> a few seconds) should go here. There is a desire to make this file run once per night, but until then should be periodically run by developers.
 
 ### Work/Sig verification modifying for tests
@@ -71,7 +74,9 @@ The fuzzer uses libfuzzer which inputs arbitrary data continuously trying to fin
 There aren’t currently tests for specific CLIs so it’s recommended to abstract the functionality so that it can be tested in `core_test`.
 
 ### Testing implementation details
+
 Sometimes it is necessary to be able to change something about a class only for a test. Rather than make this the class interface public just for tests, the specific tests can be added as friends to the class, this is done like so for a test named like so TEST (node, example);
+
 ```
 class my_class
 {
@@ -80,9 +85,11 @@ private:
    friend class node_example_Test;
 };
 ```
+
 The test itself needs to be wrapped with the nano { } namespace for this to work correctly, if the class itself is in the nano namespace which is normally the case.
 
 ### Additional pre-release testing
+
 - Run tests with TSAN/ASAN/Valgrind. All errors should be fixed before launch unless these are determined to be test related or false positives. We currently have some errors with using coroutines. There are blacklist files for the sanitizers which remove some errors caused by lmdb & rocksdb.
 
 ---
@@ -147,6 +154,7 @@ The wallets database uses the wallets_store which only has an LMDB backend.
 `nano::lmdb::store::do_upgrades ()` is where LMDB database upgrades are done. For instance `void nano::lmdb::store::upgrade_v21_to_v22 ()` combines all block databases into a single one. Raw mdb functions are normally required as `block_store::get ()` and other functions normally can’t be used because they are updated to the latest db spec. The RocksDB upgrades were introduced by V25.0. It follows a similar approach implemented for LMDB. There were in the past multiple upgrades during a release when a beta build went out and a subsequent upgrade was desired. Previously a ledger reset was done and the version was re-used but this was deemed too inconvenient.
 
 ### write_database_queue
+
 This was introduced to reduce LMDB write lock contention between the block processor and the confirmation height processor. As during bootstrapping or high TPS the block processor can hold onto the lock up to 5s (by default), before the lock is held by the blockprocessor it signals that it is about to get the LMDB lock, the confirmation height processor can make use of this information and continue processing where it would otherwise be stalled. Ongoing pruning also makes use of this.
 
 ---
@@ -178,6 +186,7 @@ The biggest bottleneck for node start-up is caused by setting up the ledger cach
 Some classes use `node_initialized_latch.wait ();` The latch was added in https://github.com/nanocurrency/nano-node/pull/2042 this is to prevent some of the issues in the node constructor initializer list where the `node` object is passed and a child constructor is wants to use a node member which is not yet initialized. This makes it resume operation once the latch is incremented at the beginning of the `node` constructor.
 
 ### Initial output
+
 When the node is run it prints out some information about the database used, compiler etc. An example of appending to the output is here: https://github.com/nanocurrency/nano-node/pull/2807
 
 ---
@@ -227,6 +236,7 @@ In `nano/lib/memory.hpp` a `nano::make_shared` function is defined which checks
 ## Libraries and submodules
 
 ### Boost
+
 We use the Boost library where possible, such as coroutine, filesystem, endian converter, lexical_cast, multi_index_container etc. If there is a static/dynamic Boost library which is not used, there are generally no issues in adding it. Just make sure the build scripts and documentation are updated.
 
 **nano/boost**
@@ -241,9 +251,11 @@ This is a small library which has no dependency to anything in the nano core, wh
 Any functionality which is shared between test projects and may also use gtest library. There is also `nano/node/testing.cpp` which has no gtest dependency because it is also used in CLI commands too.
 
 ### `nano/lib` vs. `nano/secure`
+
 The`nano/lib` library was originally intended to be used by other programs wanting some of the nano functionality, but those specific external C functions were removed and it has now become the place to put all commonly used code. As such anything which doesn’t depend on the node should go here, and the `secure` library is now mostly for ledger specific things.
 
 ### git submodules
+
 We have a variety of submodules https://docs.nano.org/node-implementation/contributing/?h=+submodule#about-the-code-base third party dependencies are to be kept as minimal as possible in order to keep build times lean, but if there is a suitable one it can be added a submodule.
 
 ---
@@ -263,23 +275,29 @@ We have a variety of submodules https://docs.nano.org/node-implementation/contri
 To confirm a block a sufficient number of votes which are taken from `confirm_ack` messages are tallied up. If the tally is above the delta inside `nano::election::have_quorum ()` it returns true and the block is considered confirmed. `confirm_ack` messages can either contain the whole block or a hash (vote by hash). `confirm_req` message header as well as `confirm_ack` indicate what the type of the contents is in the header, either `not_a_block` which means dealing with block hashes or the block type. `nano/node/common.cpp` contains these messages (among others) and (de)serializing functions.
 
 ### voting
+
 The vote generator `nano::vote_generator::vote_generator` is responsible for collecting hashes that need a vote generated, combining them into a single `vote by hash` message, signing the package with the representative key and publishing the votes to the network.  A maximum of `nano::network::confirm_ack_hashes_max` hashes can be combined into a single vote `confirm_ack` message, this provides a decent tradeoff between optimizing vote signatures and reducing bandwidth.  While the process is running it waits for `config.vote_generator_delay` time in order to pack more hashes into a single vote message.  If there are more than `config.vote_generator_threshold` after waiting then it will wait for one additional `config.vote_generator_delay` before broadcasting the message.  This allows for fast vote publishing at lower rates while enabling more hashes to be combined together at higher rates.
 
 ### vote_processor
+
 Votes are signed by the representative and the vote processor schedules checking these votes through the `signature_checker` inside `nano::vote_processor::verify_votes ()`.  Once a vote signature has been verified, the hashes within the vote packet are passed to active_elections where they are either added to an active election or added to the inactive votes cache if an election does not exist.
 
 ### active_transactions
+
 The active transactions class handles election management and prioritization.  When a block is processed and `nano::active_transactions::insert` called, a new election is started for the block hash if one does not already exist.  In addition to starting elections there is a 500ms `request_loop` that handles election management.  This process assists with moving elections through the different transition states as well as moving elections to a prioritized status if there is a backlog of elections.  During the requst loop the current network difficulty is updated through `update_active_multiplier` which takes the top `prioritized_cutoff` number of active elections that have not been confirmed and samples their difficulty multiplier.
 
 Finally, the active transactions class also handles frontiers that have not been confirmed.  Most commonly this is from bootstrapping, where the frontier of an account is added to the active elections and vote requests are sent to other nodes to confirm the frontier and thereby the rest of the account and ancestors through confirmation height processing.
 
 ### confirmation_solicitor
+
 During the `request_loop` of the active transactions process, any election that is in the `active` state for more than 5 seconds will request votes from Principle Representative nodes that it has not seen a vote from yet.  These requests are added to the `confirmation_solicitor` which aggregates the hashes up to `nano::network::confirm_req_hashes_max` into a single `confirm_req` message and publishes it to select PR nodes that have not voted.  This helps fill any gaps in network communication failures where a vote may have been dropped which helps reach quorum on the highest priority elections.
 
 ### request_aggregator
+
 The request aggregator is responsible for collecting vote requests `confirm_req` messages from other nodes and finding the optimal responses.  A local vote cache is used for recently generated votes, if the block hash in the request exists in the cache then a cached vote is returned, if the hash does not exist then the hash is added to the vote generator and a new vote is generated and published to the requesting node.  The request aggregator also handles publishing forks if the request is for a competing fork.  If the local node has a different winning hash it will publish a vote for the winning hash instead of the requested hash in addition to sending the requesting node the winning block as well.
 
 ### election
+
 An election is created when a new block is processed.  The primary purpose of the election class is to tally the vote weight and ensure consensus between any competing forks. In order to efficiently move an election through the process it can have several states.  Initially `passive` where it is waiting for votes from other nodes, then after 5 seconds if it has not been confirmed it will transition to `active` where vote requests to other nodes are made.  After `active_request_count_min` rounds of requesting votes are complete if the election is still not confirmed it moves to `broadcasting` where it will publish the block to PR nodes that have not voted in an attempt to ensure the block has been propagated throughout the network.  Under low load the `active` and `broadcasting` states are rarely used as all elections are complete within the `passive` window.
 
 Every vote that is added to the election triggers a check for whether quorum has been reached on the election.  Quorum requires that the winning hash has `node.online_reps.delta` more weight than any competing forks.  If quorum is reached the election is marked confirmed, transitions to the `confirmed` state and is added to the confirmation height procesor which updates the ledger.
@@ -303,6 +321,7 @@ Instead of confirming every block in every account-chain one-by-one, the optimis
 See [here](https://github.com/nanocurrency/nano-node/pull/4111) for more details.
 
 ### Confirmation height processor
+
 When a block is confirmed `void nano::node::process_confirmed ()` the block is added to the confirmation height processor. This begins the process of cementing it and all of its dependents, once this occurs these blocks can never be rolled back. There are 2 confirmation height algorithms bounded and unbounded. Originally only the unbounded one existed, this would store the block hash for the original block confirmed, all its previous blocks, and recurse the bottom most receive block to the source and repeat the process. If this hit something like the binance chain or (any long chain) it could use a lot of memory (unbounded amount). So this brought about the bounded confirmation height processor algorithm which starts at the very bottom of the account chains but does the same recursion when a receive block is hit. This limits the amount of block hashes needing to be stored in memory to be able to cement the bottom most blocks. Checkpoints are used if there are a lot of accounts which need to be traversed to reach which exceeds the maximum amount of memory . It does mean in certain cases the same iteration will need to be done more than once but this should be a rare case only during initial cementing.  
 
 Once the uncemented count (block count – cemented count) is less than 16K the unbounded processor is used. As mentioned above this instead starts from the top (original confirmed block) and works downwards and saves all the blocks hit (not just hash) which means they don’t need to be re-read during writing  later. This does use a lot more memory though which is why this is limited to a certain number of blocks, once the unbounded cutoff is exceeded the bounded processor resumes.  
@@ -310,11 +329,13 @@ Once the uncemented count (block count – cemented count) is less than 16K the
 Both algorithms operate with a read transaction first which reduces write lock held time as it can do a lot of iterating. This does mean that there can be some inconsistency by the time the writing is done, but this shouldn’t be an issue because once a block is confirmed by the network it will stay confirmed by `debug_assert` checks are added to catch any programming mistakes. While it is more effort to maintain 2 algorithms the unbounded one largely existed before so it made sense to re-use it, given the performance improvements in almost cemented ledgers.
 
 ### Frontiers confirmation
+
 `nano/node/frontiers_confirmation.cpp` contains code which starts at the beginning of the accounts database (`nano::blockstore_partial::accounts_begin`) and iterates in ascending order and prioritises accounts based on the number of uncemented blocks (stores up to 100k) and requests confirmation for a limited number of these accounts. When the cemented count is above the hardcoded bootstrap weights this is limited to the number of optimistic elections which is 50 in this case so it is expected to be quite slow in this case. Accounts in wallets are also checked.
 
 ---
 
 ## Telemetry
+
 nano/node/telemetry.cpp contains the logic for telemetry processing. This sets up an ongoing telemetry request round (every 60 seconds on the live network) where a telemetry_req message is sent to every peer. There is an `alarm` timeout of about 10 seconds in which we require the response (telemetry_ack) to be received otherwise it is rejected. Any calls to get_metrics_* return a cached result. To add a new definition to the telemetry_ack message this can be used as a guide which added the `active_multiplier`: https://github.com/nanocurrency/nano-node/pull/2728
 `telemetry_ack` messages are signed and are backwards compatible with older nodes (from v22 onwards). Those nodes will verify the whole message including any extra unknown data which is appended at the end is just ignored. To prevent ddosing by `telemetry_req` messages, nodes ignore messages received within that 60second (on live) boundary. This is done in `void nano::bootstrap_server::receive_header_action ()`
 
@@ -323,9 +344,11 @@ nano/node/telemetry.cpp contains the logic for telemetry processing. This sets u
 ## Stats
 
 ### Counters
+
 The `stats` object is used to keep a count of events that have happened, this is a useful idiom for checking values in tests and is aggregated in the stats->counts RPC. There are main stat types and then details for that type. A simple example of adding new details and incrementing the stats can be seen here: https://github.com/nanocurrency/nano-node/pull/2515 Adding a type for a stat is a similar procedure just using the `nano::stat::type` enumerator.
 
 ### Objects
+
 Most classes which have a member variable of container of multiple items (map, vector, list etc..) should have a function with a prototype of:
 `std::unique_ptr<container_info_component> collect_container_info (my_class & my_class, std::string const & name);`
 And then call this in an owning object which should itself be called recursively until it reaches the `node` object `collect_container_info`. They are typically not made as part of the class itself because it’s a very specialised function which is only called as part of the stats->object RPC, like so:
@@ -334,17 +357,21 @@ And then call this in an owning object which should itself be called recursively
 ---
 
 ## Pruning
+
 Pruning occurs periodically inside `nano::node::ongoing_ledger_pruning ()`. Pruning currently requires a full ledger to be bootstrapped and when an account frontier is confirmed it can then be pruned. The hashes of the pruned blocks are put into the pruned database so that we know to ignore any of these old blocks should the node bootstrap them again. Pending blocks cannot be pruned currently.
 
 ---
 
 ## Config files
+
 TOML config files are used, previously we used json files but TOML config files have the benefit of providing comments inside. There are no versions or upgrades done here, instead any defaults not explicitly overridden in the toml file get updated implicitly. There are few config files:
 
 ### config-node.toml
+
 This is actually called `daemonconfig.cpp` in the code base, but it wraps a `node_config` object.
 
 ### Other config files  
+
 `config-rpc.toml` & `config-wallet.toml` contain settings which can be modified by the user to override the defaults. The most common ones are enabling rpc/websocket & rocksdb.
 
 The `nano/node/node_rpc_config.cpp` are the rpc settings for the node.
@@ -386,11 +413,11 @@ This is used by both blocks/votes and creates (total threads / 2) to perform sig
 Peers are written to disk periodically. This was added in https://github.com/nanocurrency/nano-node/pull/1608 
 If the node has not been run in a long time (1 week), the peers list is cleared and the preconfigured peers list is used, this was added in https://github.com/nanocurrency/nano-node/pull/2506
 
-
 - Do not use the `node` object or include `node.hpp` in new core source files unless necessary, instead include the dependencies that it requires. We are still in the process of removing this idiom from other files because it adds circular dependencies, potentially ordering bugs and increases the build time.
 - Take care not to have nested `tx_begin_write ()`, it is quite easy to forget about this in tests, it will just cause a deadlock. To solve it, limit the scope:
 	- Pass `std::shared_ptr` parameters by reference where possible, https://github.com/nanocurrency/nano-node/pull/3029
 	- Be cautious with random DB reads, they are much slower than sequential reads. This PR sped up the delegators by a factor of 100 RPC by removing the block_get call needed in the loop. https://github.com/nanocurrency/nano-node/pull/2283
+
 	```
 	{ // Limit scope
 	auto transaction = store->tx_begin_write ();
@@ -399,9 +426,11 @@ If the node has not been run in a long time (1 week), the peers list is cleared
 	…
 	auto transaction = store->tx_begin_write ();
 	```
+
 	or if it’s a single write can create a temporary just for that use:
 	`block_put (store.tx_begin_write (), block);`
 	Be cautious with callback lifetimes with asynchronous callbacks, such as the worker, alarm and asio. The following issue was because of them:
+
 	```
 	int x = 4;
 	worker.push_back ([&x]() { 
diff --git a/docs/glossary.md b/docs/glossary.md
index 53eff142d..34f981cbe 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -4,146 +4,193 @@ description: A glossary of common terms used within the nano documentation and n
 # Glossary
 
 #### account
+
 Refers to an address (starts with `xrb_` or `nano_` which are interchangeable) that you control the private keys of. An address is a reinterpretation of the 256-bit public key using BASE32 encoding and a checksum. Previously supported `xrb-` or `nano-` prefixes are deprecated.
 
 #### active transaction
+
 A newly downloaded block to the node which enters into the voting process.
 
 #### ad hoc accounts
+
 Accounts not derived from a private seed which can be held in the node wallet through the wallet ID. These accounts are only recommended for use with advanced systems.
 
 #### announcement rounds
+
 A repeating half-second cycle on the node during which votes are collected for active transactions in attempt to reach quorum.
 
 #### Block
+
 A single Nano transaction. All new transactions (e.g. sends, receives, representative changes, etc) on the Nano Protocol are communicated via state blocks (since node V11). The account's entire state, including the balance after each transaction, is recorded in each block. Transaction amounts are interpreted as the difference in balance between consecutive blocks. Before V11, each transaction type (open, send, receive, change) had its own legacy block type.
 
 #### block hash
+
 A 64 character, uppercase hexadecimal string (0-9A-F) value representing a unique block on an account.
 
 #### Block height
+
 A local integer value that represents the order of a block in an account chain. For example, the 15th block in an account would have a block height of 15. Related to (but different from) [confirmation height](#confirmation-height).
 
 #### Block Lattice
+
 The Block Lattice is a data-structure in which individual accounts control their own blockchain. This allows transactions to be added quickly without conflict and sent to the network for confirmation.
 
 #### Blocks Per Second (BPS)
+
 The transmission rate of [unconfirmed](#confirmation) blocks (transactions) on the network. 
 
 #### bootstrap network
+
 A sub-network established between peers via Transmission Control Protocol (TCP) for managing bulk transmission of blocks. This is used on initial bootstrapping of peers and when out-of-sync peers attempt to fill large gaps in their ledgers. This is available within all Nano networks (main, beta and test networks).
 
 #### bootstrapping
+
 During initial sync, the nano\_node requests old transactions to independently verify and populate its local ledger database. Bootstrapping will also occur when the nano\_node becomes out of sync with the network.
 
 #### burn
+
 When a 'burn' takes place, funds are sent to a specifc address that no one can access. Because no one can ever access funds sent to a burn address, it reduces the [circulating supply](#circulating-supply).
 
 #### circulating supply
+
 133,248,297.920938463463374607431768211455 Nano. This is the supply that resulted after [burns](#burn) were made from the [genesis](#genesis) account, landing account and faucet account, following original distribution. Actual circulating supply is lower due to lost keys and sends to burn accounts. The original supply minus any amounts sent to the burn account can be found using the [available_supply](/commands/rpc-protocol/#available_supply) RPC.
 
 #### Cementing
+
 When a specific node marks a [confirmed](#confirmation) transaction as locally irreversible by setting the [account's](#account) [confirmation height](#confirmation-height) (in the node database) to the now higher [block height](#block-height) of the confirmed transaction. Cementing is a node-level operation.
 
 #### Confirmation
+
 When a block (transaction) gathers enough votes from the network to pass [quorum](#quorum). Note that confirmed sends are irreversible (i.e. fully-settled), but the receiver must publish a corresponding receive block before they will be able to spend the [receivable](#receivable) funds. Confirmation is a network-level decision.
 
 #### Confirmation Height
+
 A number stored in the local node database that represents the highest (most recent) [confirmed](#confirmation) block in an account chain. Related to (but different from) [block height](#block-height).
 
 #### Confirmations Per Second (CPS)
+
 The rate of [confirmed](#confirmation) [blocks](#blocks).
 
 #### election
 
 #### frontier
+
 The most recent block added to the account chain. Also called the head block. Can be either confirmed or unconfirmed.
 
 #### genesis
+
 The first [account](#account) to be created, containing the maximum amount of Nano to ever exist. From here the funds were sent to other wallets; for distribution or to be [burned](#burn).
 
 #### head block
+
 See [frontier](#frontier).
 
 #### inbound send
+
 A block with funds being transferred to an [account](#account) owned by a [wallet](#wallet) on your node.
 
 #### legacy blocks
+
 Blocks on an account chain before the first v1 block (which is often the v1 epoch block but can be other types). The first v1 block and all subsequent blocks are stateful blocks.
 
 #### live network
+
 A sub-network established between peers via Transmission Control Protocol (TCP) for communicating newly published blocks, votes and other non-bootstrap related traffic. This is available within all Nano networks (main, beta and test networks). In versions prior to V19, this was done via User Datagram Protocol (UDP). UDP was retained as a fallback for peer connection for versions 19 and 20. In V21 it was deprecated, and in V25 it was fully removed.
 
 #### node version
+
 The version used to identify a unique release build of the node. Each node version is tied to a single [protocol version](#protocol-version), but they are updated independently.
 
 #### online voting weight
+
 Also called online stake, it is a trended value. The node samples online representative weights every 5 minutes across a rolling 2 week period. The online voting weight value is the median of those samples.
 
 #### peers
+
 Nodes connected over the public internet to share Nano network data.
 
 #### pending
+
 See [receivable](#receivable)
 
 #### Private Key
+
 See [wallet](#wallet).
 
 #### Public Key
+
 A public key is derived from a [private key](#private-key) using the ED25519 elliptic curve algorithm. An address is a representation of the public key, see [account](#account) for more info.
 
 #### Open Representative Voting (ORV)
+
 A consensus mechanism unique to Nano which involves accounts delegating their balance as [voting weight](#voting-weight) to [Representatives](#representative). The Representatives [vote](#voting) themselves on the validity of transactions published to the network using the voting weight delegated to them. These votes are shared with their directly connected peers and they also rebroadcast votes seen from [Principal Representatives](#principal-representative). Votes are tallied and once [quorum](#quorum) is reached on a published block, it is considered confirmed by the network.
 
 #### Proof-of-Work (PoW)
+
 A Proof-of-Work is a piece of data which satisfies certain requirements and is difficult (costly, time-consuming) to produce, but easy for others to verify. In some systems this data is a central part of the security model used to protect against double-spends and other types of attacks, but with Nano it is only used to increase economic costs of spamming the network.
 
 #### Principal Representative
+
 A Nano account with >= 0.1% of the [online voting weight](#online-voting-weight) delegated to it. When configured on a node which is voting, the votes it produces will be rebroadcasted by other nodes to who receive them, helping the network reach consensus more quickly.
 
 #### protocol version
+
 The version used to identify the set of protocol rules nodes are required to follow in order to properly communicate with peers. Nodes running older protocol versions are periodically de-peered on the network to keep communication efficient - see [Active Releases](/releases/node-releases/#active-releases) and [Inactive Releases](/releases/node-releases/#inactive-releases) for the latest versions allowed to peer with one another.
 
 #### qualified root
+
 The concatenation of the root and previous attributes of a block. For the first block on an account, this would be is the account public key following by 32 zero bytes. For the second or higher block on an account, this would be the previous field repeated twice (root + previous, where root == previous).
 
 #### quorum
+
 When the delta between the two successive blocks of a root is > 67% of the online voting weight.
 
 #### receivable
+
 A transaction state where a block sending funds was published and confirmed by the network, but a matching block receiving those funds has not yet been confirmed.
 
 #### Representative
+
 A Nano account with > 0 voting weight, but < 0.1% of the [online voting weight](#online-voting-weight), delegated to it. Unlike [Principal Representatives](#principal-representative), when configured on a node which is voting, the votes it produces and sends to directly connected peers won't be rebroadcasted by those peers.
 
 #### root
+
 If the block is the first block on the account, the root is the account public key. Otherwise it is the previous hash included in the block. The root of a block can never be zero.
 
 #### seed
+
 A 256-bit random value usually represented to the user as a 64 character hexidecimal (0-9 and A-F) value. Private keys are derived from a seed.
 
 #### Transactions Per Second (TPS)
+
 Historically, TPS was a per-node measurement that represented a node's perception of the rate of transactions on the network ([BPS](#blocks-per-second-bps)). This measurement was found to be inaccurate due to peering and propagation differences between nodes, so [CPS](#confirmations-per-second-cps) is now the preferred term for describing overall Nano network scalability. It's also important to note that while Nano sends do not require a corresponding receive to be [confirmed](#confirmation), a receive block must be confirmed before received funds can be sent again (see [receivable](#receivable)).
 
 #### unchecked (blocks)
+
 Blocks (transactions) that have been downloaded but not yet processed by the Nano node. The node software downloads all blocks from other nodes as unchecked, processes them and adds to block count, confirms the [frontier](#frontier) blocks for each account, and then marks them as [cemented](#cementing).
 
 #### unopened account
+
 An account address that does not have a first block on it (which must be a block to receive Nano sent from another account, cannot be a block only changing the Representative).
 
 #### unpocketed
+
 See [receivable](#receivable).
 
 #### vote-by-hash
+
 Allows representatives to only include the hash of a block in each vote to save bandwidth. Before vote-by-hash was activated the entire block contents were required.
 
 #### voting
+
 Each node configured with a [Representative](#representative) votes on every block by appending their Representative signature and a sequence number to the hash. These will be sent out to directly connected peers and if the vote originates from a [Principal Representative](#principal-representative), it will subsequently be rebroadcasted by nodes to their peers.
 
 #### voting weight
+
 The amount of weight delegated to a [Representative](#representative).
 
 #### wallet
+
 A wallet is an organizational object in a nano\_node that holds a single seed from which multiple accounts are deterministically derived via a 32-bit unsigned integer index starting at 0. Private keys are derived from the seed and index as follows: (`||` means concatenation; `blake2b` is a [highly optimized cryptographic hash function](/protocol-design/signing-hashing-and-key-derivation/#hashing-algorithm-blake2))
 
 $$
@@ -151,7 +198,9 @@ k_{private} = blake2b(\text{seed} || \text{index})
 $$
 
 #### WALLET_ID
+
 A 256-bit random value name/identifier for a specific wallet in the local nano\_node database. The WALLET\_ID **is not** stored anywhere in the network and is only used in the local nano\_node. Even though a WALLET\_ID looks identical to a seed, do not confuse the WALLET\_ID with a seed; funds cannot be restored with a WALLET\_ID. Do not backup the WALLET\_ID as a means to backup funds.
 
 #### work peers
+
 Node peers which are configured to generate work for transactions at the originating nodes request.
diff --git a/docs/index.md b/docs/index.md
index 5dbdb39fe..ede2d9de1 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,31 +1,34 @@
----
-title: Home
-description: Explore the design, features, releases and other related resources for the nano protocol and node implementation.
-hide:
-  - navigation
-  - toc
----
-
-# Nano Node and Protocol Documentation
-Welcome! This documentation is focused on helping developers understand Nano, including setup, maintenance, and building on top of the Nano node. Details of how this documentation has been arranged are below:
-
-| Section | Details | Audience |
-| | | |
-|<span class="no-break">**[What is Nano?](what-is-nano/overview.md)**</span>|Take a high-level tour - this is a great place to learn about how Nano is uniquely suited to being a global digital currency.|Everyone|
-|<span class="no-break">**[Running a Node](running-a-node/overview.md)**</span>| Set up a Nano node to manage the ledger, create and publish blocks and participate in consensus. | Node operators, developers  |
-|<span class="no-break">**[Integration Guides](integration-guides/the-basics.md)**</span>| Learn practical concepts, structures and features for building wallets, payment systems and other services on the Nano network. | Developers  |
-|<span class="no-break">**[Living Whitepaper](living-whitepaper/index.md)**</span>| Dive into the details of why Nano was created & how it's designed. Split into two sub-sections: [Protocol Design](protocol-design/introduction.md) & [Node Implementation](node-implementation/introduction.md).  | Developers |
-|<span class="no-break">**[Protocol Design](protocol-design/introduction.md)**</span>| Dig deeper into the design and behaviors driving the protocol, including the election process, peering mechanics and more. | Developers |
-|<span class="no-break">**[Node Implementation](node-implementation/introduction.md)**</span>| Details of the Nano Foundation managed node implementation of the protocol. | Developers |
-|<span class="no-break">**[Core Development](core-development/overview.md)**</span>| Interested in contributing to the core Nano code or protocol? Here's how to get started. | Developers |
-|<span class="no-break">**[Commands](commands/rpc-protocol.md)**</span>|  Explore an exhaustive list of interaction methods for the node via RPC and CLI. | Node operators, developers |
-|<span class="no-break">**[Releases](releases/node-releases.md)**</span>| Review past node releases and get details about the features coming soon in new releases.  | Everyone  |
-|<span class="no-break">**[Glossary](glossary.md)**</span>| Commonly used terms throughout the documentation and Nano ecosystem.  | Everyone  |
-
-**Join the Community**
-
-If you are looking for other details about Nano, links to wallets, discussions about the network and more, check out our community:
-
---8<-- "community-links.md"
-
-[Change cookie settings](#__consent)
+---
+title: Home
+description: Explore the design, features, releases and other related resources for the nano protocol and node implementation.
+hide:
+
+  - navigation
+  - toc
+
+---
+
+# Nano Node and Protocol Documentation
+
+Welcome! This documentation is focused on helping developers understand Nano, including setup, maintenance, and building on top of the Nano node. Details of how this documentation has been arranged are below:
+
+| Section | Details | Audience |
+| | | |
+|<span class="no-break">**[What is Nano?](what-is-nano/overview.md)**</span>|Take a high-level tour - this is a great place to learn about how Nano is uniquely suited to being a global digital currency.|Everyone|
+|<span class="no-break">**[Running a Node](running-a-node/overview.md)**</span>| Set up a Nano node to manage the ledger, create and publish blocks and participate in consensus. | Node operators, developers  |
+|<span class="no-break">**[Integration Guides](integration-guides/the-basics.md)**</span>| Learn practical concepts, structures and features for building wallets, payment systems and other services on the Nano network. | Developers  |
+|<span class="no-break">**[Living Whitepaper](living-whitepaper/index.md)**</span>| Dive into the details of why Nano was created & how it's designed. Split into two sub-sections: [Protocol Design](protocol-design/introduction.md) & [Node Implementation](node-implementation/introduction.md).  | Developers |
+|<span class="no-break">**[Protocol Design](protocol-design/introduction.md)**</span>| Dig deeper into the design and behaviors driving the protocol, including the election process, peering mechanics and more. | Developers |
+|<span class="no-break">**[Node Implementation](node-implementation/introduction.md)**</span>| Details of the Nano Foundation managed node implementation of the protocol. | Developers |
+|<span class="no-break">**[Core Development](core-development/overview.md)**</span>| Interested in contributing to the core Nano code or protocol? Here's how to get started. | Developers |
+|<span class="no-break">**[Commands](commands/rpc-protocol.md)**</span>|  Explore an exhaustive list of interaction methods for the node via RPC and CLI. | Node operators, developers |
+|<span class="no-break">**[Releases](releases/node-releases.md)**</span>| Review past node releases and get details about the features coming soon in new releases.  | Everyone  |
+|<span class="no-break">**[Glossary](glossary.md)**</span>| Commonly used terms throughout the documentation and Nano ecosystem.  | Everyone  |
+
+**Join the Community**
+
+If you are looking for other details about Nano, links to wallets, discussions about the network and more, check out our community:
+
+--8<-- "community-links.md"
+
+[Change cookie settings](#__consent)
diff --git a/docs/integration-guides/advanced.md b/docs/integration-guides/advanced.md
index a99f2dc93..839e7a5ef 100644
--- a/docs/integration-guides/advanced.md
+++ b/docs/integration-guides/advanced.md
@@ -32,7 +32,6 @@ This guide extends the concepts covered in [External Private Key Management](/in
 	1. Transfer the signed transaction back to the `(HOT)` insecure online-computer.
 	1. `(HOT)` Publish the signed transaction to the Nano Network.
 
-
 <div class="mermaid-wrapper">
 
 ```mermaid
@@ -234,6 +233,7 @@ For details on configuring the HTTP callback within a node, see the [HTTP callba
 ```
 
 Send state blocks have special fields "is_send" & "subtype"   
+
 ```json
 {  
     "account": "nano_1ipx847tk8o46pwxt5qjdbncjqcbwcc1rrmqnkztrfjy5k7z4imsrata9est",  
@@ -255,7 +255,6 @@ Send state blocks have special fields "is_send" & "subtype"
 }
 ```  
 
-
 !!! warning
     It is recommended to fetch the block using the hash provided in the callback rather than trust this data is valid, and check that data instead, since a malicious 3rd party can also make a fake callback request to your endpoint.
 
@@ -340,7 +339,6 @@ curl -d '{
 
     sudo systemctl enable nano_node
     
-    
 !!! tip
     To manage node, use [RPC commands](/commands/rpc-protocol) or [CLI](/commands/command-line-interface)
 
@@ -356,12 +354,14 @@ and should be increased to at least 16384.
 ```
 
 To resolve this on Linux increase max open files limit by editing `/etc/security/limits.conf` and adding or updating:    
+
 ```
     *               soft    nofile          65535    
     *               hard    nofile          65535    
     root            soft    nofile          65535    
     root            hard    nofile          65535    
 ```
+
 Then restart session & `nano_node` service. Check changes with `ulimit -n`.
 
 For macOS the version impacts the steps necessary, but some people had success with the recipe in [https://superuser.com/a/1171028](https://superuser.com/a/1171028).
diff --git a/docs/integration-guides/build-options.md b/docs/integration-guides/build-options.md
index f78b12ed0..60bf84ad7 100644
--- a/docs/integration-guides/build-options.md
+++ b/docs/integration-guides/build-options.md
@@ -66,18 +66,21 @@ If you are building a version before V25.0, the node build commands further down
 * From inside [boost.src] run:
 
 === "*nix"
+
     ```bash
     ./bootstrap.sh --with-libraries=context,coroutine,filesystem,log,program_options,system,thread
     ./b2 --prefix=[boost] --build-dir=[boost.build] link=static install
     ```
 
 === "macOS"
+
     ```bash
     ./bootstrap.sh --with-libraries=context,coroutine,filesystem,log,program_options,system,thread
     ./b2 --prefix=[boost] --build-dir=[boost.build] link=static install
     ```
 
 === "Windows"
+
     ```bash
     ./bootstrap.sh --with-libraries=context,coroutine,filesystem,log,program_options,system,thread
     ./b2 --prefix=[boost] --build-dir=[boost.build] address-model=64 link=static install
@@ -90,6 +93,7 @@ If using this option, remove `bash util/build_prep/bootstrap_boost.sh -m` from t
 If building the Qt-based `nano_wallet`, first download [Qt 5.15.2+ open source edition](https://www.qt.io/download) and extract to [qt.src]. In [qt.build] execute:
 
 === "*nix"
+
     ```bash
     [qt.src]/configure -shared -opensource -nomake examples -nomake tests -confirm-license  -prefix [qt]
     make
@@ -97,6 +101,7 @@ If building the Qt-based `nano_wallet`, first download [Qt 5.15.2+ open source e
     ```
 
 === "macOS"
+
     ```bash
     [qt.src]/configure -shared -opensource -nomake examples -nomake tests -confirm-license  -prefix [qt]
     make
@@ -104,6 +109,7 @@ If building the Qt-based `nano_wallet`, first download [Qt 5.15.2+ open source e
     ```
 
 === "Windows"
+
     ```bash
     [qt.src]/configure -shared -opensource -nomake examples -nomake tests -confirm-license  -prefix [qt]
     nmake
@@ -177,6 +183,7 @@ If building the Qt-based `nano_wallet`, first download [Qt 5.15.2+ open source e
         ```
 
         **Configure repository with modern GCC**
+
         ```bash
         sudo yum install gcc-toolset-12
         scl enable gcc-toolset-12 bash
@@ -215,6 +222,7 @@ If building the Qt-based `nano_wallet`, first download [Qt 5.15.2+ open source e
 The process below will create a release build of the node for the main network. See [network options](#network-options) below for details on building for the test or beta networks.
 
 === "*nix"
+
     ```bash
     git clone --branch V25.0 --recursive https://github.com/nanocurrency/nano-node.git nano_build
     cd nano_build
@@ -227,6 +235,7 @@ The process below will create a release build of the node for the main network.
     ```
 
 === "macOS"
+
     ```bash
     git clone --branch V25.0 --recursive https://github.com/nanocurrency/nano-node.git nano_build
     cd nano_build
@@ -245,6 +254,7 @@ The process below will create a release build of the node for the main network.
     *Download Source*
 
     Using git_bash:
+
     ```bash
     git clone --branch V25.0 --recursive https://github.com/nanocurrency/nano-node
     cd nano-node
@@ -253,15 +263,18 @@ The process below will create a release build of the node for the main network.
     *Create a `build` directory inside nano-node (makes for easier cleaning of build)*
 
     Using git_bash:
+
     ```bash
     mkdir build
     cd build
     ``` 
+
     * **Note:** all subsequent commands should be run within this "build" directory.
 
     *Get redistributables*
 
     Using Powershell:
+
     ```bash
     Invoke-WebRequest -Uri https://aka.ms/vs/16/release/vc_redist.x64.exe -OutFile .\vc_redist.x64.exe
     ```
@@ -364,7 +377,6 @@ Run CMake GUI
 
 ![CMake Generator](../images/windows-10-build-instructions/cmake-generator.jpg)
 
-
 **Visual studio**
 
 - Open project solution file in `C:\Users\YourUser\Documents\NanoSolution\nano-node-beta.sln`
@@ -455,17 +467,20 @@ A number of tests binaries can be built when the CMake variable `-DNANO_TEST=ON`
 ### Running Tests
 
 To run all tests in a binary just launch it:
+
 ```bash
 ./core_test
 ```
 
 To check a specific subset of tests, gtest filtering can be used (with optional wildcards):
+
 ```bash
 ./core_test --gtest_filter=confirmation_height.single
 ./rpc_test --gtest_filter=rpc.*
 ```
 
 To run tests multiple times:
+
 ```bash
 ./core_test --gtest_repeat=10
 ```
@@ -484,6 +499,7 @@ If running on a debugger, add the argument `--gtest_break_on_failure` break at t
 3 different CMake sanitizer options are supported: `NANO_ASAN_INT`, `NANO_TSAN` and `NANO_ASAN`. They cannot be used in conjunction with each other.
 
 #### Thread Sanitizer
+
 Use `-DNANO_TSAN=ON` as an extra CMake option. The following environment variable should also be set:
 
 `export TSAN_OPTIONS="suppressions=../tsan_suppressions"`
@@ -491,6 +507,7 @@ Use `-DNANO_TSAN=ON` as an extra CMake option. The following environment variabl
 `tsan_suppressions` should be a path to the file in the root nano directory. This suppresses many errors relating to the mdb and rocksdb libraries.
 
 #### Address Sanitizer
+
 Use the CMake variable `-DNANO_ASAN=ON` or `-DNANO_ASAN_INT=ON` before running an executable.
 
 ### Valgrind
diff --git a/docs/integration-guides/index.md b/docs/integration-guides/index.md
index 68ff2fe9a..964687de5 100644
--- a/docs/integration-guides/index.md
+++ b/docs/integration-guides/index.md
@@ -88,12 +88,10 @@ This community built wallet is a production-ready, high performance developer wa
 
 [![Pippin](https://opengraph.githubassets.com/38565027a4d84e26310588fd4712b3cf836745cbe2b4a20ac44590225da01765/appditto/pippin_nano_wallet){width=50%}](https://github.com/appditto/pippin_nano_wallet)
 
-
 ### Nault
 
 This community built wallet is more end-user focused with a robust GUI full of various options. It can be useful in development and testing as it supports setting the custom backend to your own node and can function as a basic account/block explorer. If you use this wallet, it also has an open source license so contributions are encouraged.
 
-
 [![Nault](https://repository-images.githubusercontent.com/274627453/14c0c180-bc4a-11ea-82e9-cc23b8b5a718){width=50%}](https://github.com/Nault/Nault)
 
 ---
@@ -115,4 +113,3 @@ If you've made it this far you may have a node running with a wallet setup and h
 - Tracking block confirmations: see [Block Confirmation Tracking guide](block-confirmation-tracking.md)
 - Performing efficient work generation: see [Work Generation guide](work-generation.md)
 - Optional WebSocket integration: see [WebSockets guide](websockets.md)
-
diff --git a/docs/integration-guides/ipc-integration.md b/docs/integration-guides/ipc-integration.md
index bf80b89cc..c753a8994 100644
--- a/docs/integration-guides/ipc-integration.md
+++ b/docs/integration-guides/ipc-integration.md
@@ -82,11 +82,13 @@ The RPC gateway automatically translates between Flatbuffers and JSON messages o
 	The examples below assumes the node is compiled with TLS support. If not, replace https with http. If using TLS with a self-signed certificate, add --insecure to curl commands.
 
 ### Making calls without a message envelope
+
 A message envelope is a way to tell the server which message type is sent, as well as other information such as credentials.
 
 For HTTP clients, it's convenient to send messages _without_ an envelope. They do so by appending the message name (using uppercase CamelCase) to the path:
 
 `POST` to https://www.example.com:7076/api/v2/AccountWeight
+
 ```
 {
     "account": "nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3"
@@ -139,6 +141,7 @@ The correlation header is Nano-Correlation-Id, which can be an arbitrary string.
 If the message name is missing from the path, an envelope will be expected which tells the node about the message type.
 
 `POST` to https://www.example.com:7076/api/v2
+
 ```json
 { 
     "message_type" : "AccountWeight", 
@@ -231,6 +234,7 @@ curl --header "Nano-Api-Key:mywalletuser" --insecure -d \
    '{ "account": "nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3"}' \
    https://www.example.com:7076/api/v2/AccountWeight
 ```
+
 This uses HTTPS (which the node supports through a build option), and the `--insecure` is there because the node's certificate in this example is self-signed.
 
 Using an envelope instead of the `AccountWeight` endpoint:
diff --git a/docs/integration-guides/key-management.md b/docs/integration-guides/key-management.md
index 498796fd1..14eb53ee4 100644
--- a/docs/integration-guides/key-management.md
+++ b/docs/integration-guides/key-management.md
@@ -6,9 +6,11 @@ description: Learn best practices for private key management for the nano protoc
 ## Seeds
 
 ### Hex Seed
+
 Nano's private key(s) have been traditionally derived from a 64 character, uppercase hexadecimal string (0-9A-F). This is currently the more popular form of seed supported by a variety of services and wallets. Additional details available in [The Basics guide](/integration-guides/the-basics/#seed).
 
 ### Mnemonic Seed
+
 Wallets that provide mnemonic seeds should use the [BIP39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) standard word list and methods for generating the seed. When BIP32 master keys are generated from the seed, the HMAC hash key variation "ed25519 seed" should be used due to nano using [ed25519 for the signing algorithm](../protocol-design/signing-hashing-and-key-derivation.md#signing-algorithm-ed25519) (see [SLIP-0010](https://github.com/satoshilabs/slips/blob/master/slip-0010.md)).
 
 A non-standard derivation path is used for nano in the [Ledger Nano implementation](https://github.com/LedgerHQ/app-nano), as well as other popular wallets. With a coin-type of `165'` (`0x800000a5`), this is a partial BIP44 path of `m/44'/165'/[address index]`. Only hardened paths are defined.
@@ -36,11 +38,15 @@ https://github.com/numsu/nanocurrency-web-js
 ```
 edge defense waste choose enrich upon flee junk siren film clown finish luggage leader kid quick brick print evidence swap drill paddle truly occur
 ```
+
 Given Passphrase:
+
 ```
 some password
 ```
+
 Derived BIP39 Seed:
+
 ```
 0dc285fde768f7ff29b66ce7252d56ed92fe003b605907f7a4f683c3dc8586d34a914d3c71fc099bb38ee4a59e5b081a3497b7a323e90cc68f67b5837690310c
 ```
@@ -48,14 +54,19 @@ Derived BIP39 Seed:
 ??? success "Index 0 (`44'/165'/0'`)"
 
     Derived Private Key:
+
     ```
     3be4fc2ef3f3b7374e6fc4fb6e7bb153f8a2998b3b3dab50853eabe128024143
     ```
+
     Derived Public key:
+
     ```
     5b65b0e8173ee0802c2c3e6c9080d1a16b06de1176c938a924f58670904e82c4
     ```
+
     Derived Address:
+
     ```
     nano_1pu7p5n3ghq1i1p4rhmek41f5add1uh34xpb94nkbxe8g4a6x1p69emk8y1d
     ```
@@ -63,14 +74,19 @@ Derived BIP39 Seed:
 ??? success "Index 1 (`44'/165'/1'`)"
 
     Derived Private Key:
+
     ```
     ce7e429e683d652446261c17a96da9ed1897aea96c8046f2b8036f6b05cb1a83
     ```
+
     Derived Public key:
+
     ```
     d9f7762e9cd4e7ed632481308cdb8f54abf0241332c0a8641f61e92e2fb03c12
     ```
+
     Derived Address:
+
     ```
     nano_3phqgrqbso99xojkb1bijmfryo7dy1k38ep1o3k3yrhb7rqu1h1k47yu78gz
     ```
@@ -78,14 +94,19 @@ Derived BIP39 Seed:
 ??? success "Index 2 (`44'/165'/2'`)"
 
     Derived Private Key:
+
     ```
     1257df74609b9c6461a3f4e7fd6e3278f2ddcf2562694f2c3aa0515af4f09e38
     ```
+
     Derived Public key:
+
     ```
     a46da51986e25a14d82e32d765dcee69b9eeccd4405411430d91ddb61b717566
     ```
+
     Derived Address:
+
     ```
     nano_3b5fnnerfrkt4me4wepqeqggwtfsxu8fai4n473iu6gxprfq4xd8pk9gh1dg
     ```
@@ -99,6 +120,7 @@ company public remove bread fashion tortoise ahead shrimp onion prefer waste bla
 No Passphrase
 
 Derived BIP39 Seed:
+
 ```
 924a962cae64448812be28a514093ebfeeed537d61a44318eb35f902961d21b2fccd30008d33c8d1d5327a34b9b73281c4b27a0a3d004c1c2e85e8dbb234cba8
 ```
@@ -106,14 +128,19 @@ Derived BIP39 Seed:
 ??? success "Index 0 (`44'/165'/0'`)"
 
     Derived Private Key:
+
     ```
     6f73d61ca0b56fcdb79d69d437f102348ad75ca971433eb92b2b003f8c99b48d
     ```
+
     Derived Public key:
+
     ```
     134d938215f68bcaa3a0e574fde325fc4b1abad9bd3d698bfef95633b54ffb57
     ```
+
     Derived Address:
+
     ```
     nano_16tfkg33dxndscjt3sdnzqjkdz4d5cxfmhbxf87zxycp8gtnzytqmcosi3zr
     ```
@@ -121,14 +148,19 @@ Derived BIP39 Seed:
 ??? success "Index 1 (`44'/165'/1'`)"
 
     Derived Private Key:
+
     ```
     7e104389811a0967ef574af1f3f423f23cbf7b614be17844f67fb6fd315f9a7e
     ```
+
     Derived Public key:
+
     ```
     71e6caac915affe836c3e822be6a5b3464f40c74bd2e5459d4e74205c6a7c0df
     ```
+
     Derived Address:
+
     ```
     nano_1wh8scpb4pqzx1ue9t34qso7pf56yi89bhbgcjexbst41q5chi8zqtwb74ih
     ```
@@ -136,19 +168,23 @@ Derived BIP39 Seed:
 ??? success "Index 2 (`44'/165'/2'`)"
 
     Derived Private Key:
+
     ```
     8b7250869207a277ac37068dbe32782c2ab9fc6a5342f0deabbfdfae1285196a
     ```
+
     Derived Public key:
+
     ```
     fcebc6554853ed01c242817abf1b5050b887002f8de8f55d00c7c6b5fe01075d
     ```
+
     Derived Address:
+
     ```
     nano_3z9drscninzf193671dtqwfo1n7riw14z5hayogi3jy8pqz143txaghe4gbk
     ```
 
-
 ## External Management
 
 For larger, more robust systems, external private key management is recommended. In this setup, the node operator generates and stores private keys in an external database and only queries the nano\_node to:
@@ -161,6 +197,7 @@ For larger, more robust systems, external private key management is recommended.
     [WALLET\_IDs](/integration-guides/the-basics/#wallet-id) are not used for External Private Key Management since private keys are not stored in the nano\_node. Much of this section builds off of the [Blocks Specifications](/integration-guides/the-basics/#blocks-specifications) documentation.
 
 ---
+
 ### External accounting systems
 
 In order to properly implement accounting systems external to the Nano node the following best practices should be put into place, which ensure only fully confirmed blocks are used for external tracking of credits, debits, etc.
@@ -175,7 +212,6 @@ In order to properly implement accounting systems external to the Nano node the
 
 Before crediting funds to an account internally based on a deposit on the network, the block sending the funds must be confirmed. This is done by verifying the network has reached quorum on the block. Details of the recommended verification process can be found in the [block confirmation tracking guide](/integration-guides/block-confirmation-tracking).
 
-
 #### Tracking confirmed balances
 
 External accounting systems that track balances arriving to the node must track hashes of blocks that have been received in order to guarantee idempotency. Once confirmation of a block has been validated, the block hash should be recorded for the account along with any credits, debits or other related information. Any attempts to credit or debit accounts external to the node should check that no previous conflicting or duplicate activity was already recorded for that same block hash.
@@ -193,6 +229,7 @@ However, you must always wait for the confirmation of **receivable blocks** befo
 A Nano private key is a 256-bit piece of data produced from a cryptographically secure random number generator.
 
 !!! danger "Secure Private Keys" 
+
     * Generating private keys from an insecure source may result in loss of funds.
     * Be sure to backup any generated private key; if lost the funds in the account will become inaccessible.
 
@@ -320,6 +357,7 @@ curl -d '{
 ```
 
 !!! info "Additional details"
+
     * The option `json_block`, available since V19.0, makes the RPC call return a non-stringified version of the block, which is easier to parse and always recommended.
     * [`block_create`](/commands/rpc-protocol#block_create) RPC commands generally take longer than other RPC commands because the nano\_node has to generate the [Proof-of-Work](/integration-guides/the-basics/#proof-of-work) for the transaction. The response block data is already properly formatted to include in the [`process`](/commands/rpc-protocol#process) RPC command.
     * The nano\_node creating and signing this transaction has no concept of what the transaction amount is, nor network state; all the nano\_node knows is that it is creating a block whose previous block on the account chain has hash `92BA74A7D6DC7557F3EDA95ADC6341D51AC777A0A6FF0688A5C492AB2B2CB40D` results in the account having a balance of `3618869000000000000000000000000`.
@@ -536,6 +574,7 @@ curl -d '{
 --8<-- "warning-process-sub-type-recommended.md"
 
 ##### Request Example
+
 ```bash
 curl -d '{
   "action": "process",
@@ -556,6 +595,7 @@ curl -d '{
 ```
 
 ##### Success Response
+
 ```json
 { 
   "hash": "42A723D2B60462BF7C9A003FE9A70057D3A6355CA5F1D0A57581000000000000"
@@ -571,8 +611,8 @@ curl -d '{
     * The target proof-of-work difficulty threshold is obtained internally as the minimum between [`active_difficulty`](/commands/rpc-protocol/#active_difficulty) and `max_work_generate_multiplier` (converted to difficulty).
     * With a new, [higher difficulty](/integration-guides/the-basics/#difficulty-multiplier) proof-of-work, the block will get higher confirmation priority across the network.
 
-
 !!! info "When a transaction does not confirm"
+
     * If a transaction is taking too long to confirm, you may call the [`process`](/commands/rpc-protocol#process) RPC command with the same block data with no risk.
     * If for some reason a transaction fails to properly broadcast, subsequent transactions on the account-chain after that transaction will not be accepted by the network since the `"previous"` field in the transaction data refers to a non-existant block.
     * If this situation occurs, rebroadcasting the missing transaction(s) will make the subsequent blocks valid in the network's ledger.
@@ -725,6 +765,7 @@ curl -d '{
 ##### Error Response
 
 Response if the wallet_id isn't found in nano\_node:
+
 ```json
 {
   "error": "Wallet not found"
@@ -732,6 +773,7 @@ Response if the wallet_id isn't found in nano\_node:
 ```
 
 Response if the seed field contains non-hexidecimal values or is too long:
+
 ```json
 { 
   "error": "Bad seed"
@@ -941,4 +983,5 @@ curl -d '{
   ]
 }
 ```
+
 On success, the nano\_node returns the hashes of all republished blocks.
diff --git a/docs/integration-guides/the-basics.md b/docs/integration-guides/the-basics.md
index 9a7ab133d..f318fdc82 100644
--- a/docs/integration-guides/the-basics.md
+++ b/docs/integration-guides/the-basics.md
@@ -12,7 +12,6 @@ Action  | Description
 Send    | Send funds from users account to another account
 Receive | Receive funds from a given "Send" transaction
 
-
 The system is akin to writing (send) and cashing (receive) a Cashier's Check.  There are a few things to consider about transactions:
 
 * The receiving account does not have to be online during the Send transaction.
@@ -45,6 +44,7 @@ When dealing with the various IDs in the node it is important to understand the
     There are several things that can have a similar form but may have very different functions, and mixing them up can result in loss of funds. Use caution when handling them.
 
 ### Wallet ID
+
 This is a series of 32 random bytes of data and is **not the seed**. It is used in several RPC actions and command line options for the node. It is a **purely local** UUID that is a reference to a block of data about a specific wallet (set of seed/private keys/info about them) in your node's local database file.
 
 The reason this is necessary is because we want to store information about each account in a wallet: whether it's been used, what its account is so we don't have to generate it every time, its balance, etc. Also, so we can hold ad hoc accounts, which are accounts that are not derived from the seed. This identifier is only useful in conjunction with your node's database file and **it will not recover funds if that database is lost or corrupted**. 
@@ -52,6 +52,7 @@ The reason this is necessary is because we want to store information about each
 This is the value that you get back when using the `wallet_create` etc RPC commands, and what the node expects for RPC commands with a `"wallet"` field as input.
 
 ### Seed
+
 This is a series of 32 random bytes of data, usually represented as a 64 character, uppercase hexadecimal string (0-9A-F). This value is used to derive **account private keys** for accounts by combining it with an index and then putting that into the following hash function where `||` means concatenation and `i` is a 32-bit big-endian unsigned integer: `PrivK[i] = blake2b(outLen = 32, input = seed || i)`
 
 Private keys are derived **deterministically** from the seed, which means that as long as you put the same seed and index into the derivation function, you will get the same resulting private key every time. Therefore, knowing just the seed allows you to be able to access all the derived private keys from index 0 to $2^{32} - 1$ (because the index value is a unsigned 32-bit integer).
@@ -81,6 +82,7 @@ It should be noted that Nano reference wallet is using described Blake2b private
 === "Bitcoinjs"
 
 	Mnemonic words for Blake2b Nano seed using [Bitcoinjs](https://github.com/bitcoinjs/bip39):
+
 	```js
 	const bip39 = require('bip39')
 	
@@ -91,14 +93,16 @@ It should be noted that Nano reference wallet is using described Blake2b private
 	// => '0000000000000000000000000000000000000000000000000000000000000001'
 	```
 
-
 ### Account private key
+
 This is also a 32 byte value, usually represented as a 64 character, uppercase hexadecimal string(0-9A-F). It can either be random (an *ad-hoc key*) or derived from a seed, as described above. This is what represents control of a specific account on the ledger. If you know or can know the private key of someone's account, you can transact as if you own that account.
 
 ### Account public key
+
 This is also a 32 byte value, usually represented as a 64 character, uppercase hexadecimal string (0-9A-F). It is derived from an *account private key* by using the ED25519 curve using Blake2b-512 as the hash function (instead of SHA-512). Usually account public keys will not be passed around in this form, rather the below address is used.
 
 ### Account public address
+
 This is what you think of as someone's Nano address: it's a string that starts with `nano_` (previously `xrb_`), then has 52 characters which are the *account public key* but encoded with a specific base32 encoding algorithm to prevent human transcription errors by limiting ambiguity between different characters (no `O` and `0` for example). Then the final 8 characters are Blake2b-40 checksum of the account public key to aid in discovering typos, also encoded with the same base32 scheme (5 bytes).
 
 So for address `nano_1anrzcuwe64rwxzcco8dkhpyxpi8kd7zsjc1oeimpc3ppca4mrjtwnqposrs`:
@@ -142,6 +146,7 @@ If an account balance decreases, the transaction that caused the decrease is con
     Because final balances are recorded rather than transaction amounts, API calls must be done carefully to avoid sending erroneous amounts.
 
 ### Block Format
+
 Because each block contains the current state of the account, the `"type"` of the block is always `"state"`. The following table presents the anatomy of a block, along with the format used within RPC calls for building blocks, and the serialized, binary representation:
 
 | Key            | RPC Format              | Serialized | Description |
@@ -166,6 +171,7 @@ Depending on the action each transaction intends to perform, the `"link"` field
  If using the [block_create](/commands/rpc-protocol#block_create) RPC command the optional fields `"source"` (with the block hash to be received) and `"destination"` (with the target `nano_` address) fields can be used instead of directly defining the `"link"` field.
 
 !!! note
+
     * Any transaction may also simultaneously change the representative. The above description of the "Change" action is for creating a block with an explicit representative change where no funds are transferred (balance is not changed).
     * In the completed, signed transaction json, the `"link"` field is **always** hexadecimal.
     * The first block on an account must be receiving funds (cannot be an explicit representative change). The first block is often referred to as "opening the account".
@@ -243,6 +249,7 @@ Change to representative with label and message
     nanoseed:<encoded seed>[?][label=<label>][&][message=<message>][&][lastindex=<index>]
 
 ### Process a JSON blob block
+
 (to be sent as the `block` argument to the RPC call `process`)
 
     nanoblock:<blob>
diff --git a/docs/integration-guides/websockets.md b/docs/integration-guides/websockets.md
index cff8ac1c8..496c62bba 100644
--- a/docs/integration-guides/websockets.md
+++ b/docs/integration-guides/websockets.md
@@ -123,6 +123,7 @@ To receive notifications through the websocket you must subscribe to the specifi
 Unsubscribing also has the format:
 
 To unsubscribe:
+
 ```json
 {
   "action": "unsubscribe",
@@ -209,6 +210,7 @@ Filters for **confirmation** can be used to subscribe only to selected accounts.
 !!! tip "Updating the list of accounts"
     _version 21.0+_  
     The list of `accounts` for which blocks are broadcasted can be updated (see [Update](#update)):
+
     ```json
     {
       "action": "update",
@@ -223,6 +225,7 @@ Filters for **confirmation** can be used to subscribe only to selected accounts.
       }
     }
     ```
+
     Note that this can result in an empty filter.
 
 ##### Response Options
@@ -290,6 +293,7 @@ The sideband fields when its option is set to true are:
 ##### Sample Results
 
 !!! note "Differences from the HTTP callback"
+
     * The "block" contains JSON instead of an escaped string. This makes parsing easier.
     * The JSON received by the client contains a topic, event time (milliseconds since epoch) and the message itself.
     * Subtype is part of block (if it's a state block)
@@ -602,8 +606,8 @@ No filters are currently available for the `telemetry` topic.
   }
 }
 ```
-See the [telemetry](../commands/rpc-protocol.md#telemetry) RPC command which gives more information about the message response.  
 
+See the [telemetry](../commands/rpc-protocol.md#telemetry) RPC command which gives more information about the message response.  
 
 ### New unconfirmed blocks
 
@@ -658,6 +662,7 @@ This subscription is available since _v21.0_
 ##### Subscribing
 
 To subscribe to bootstrap attempts start/exit notifications:
+
 ```json
 {
   "action": "subscribe",
@@ -706,6 +711,7 @@ Notes:
 ## Removed Topics
 
 ### Active difficulty
+
 _removed in version 22.0_
 
 ##### Subscribing
diff --git a/docs/integration-guides/work-generation.md b/docs/integration-guides/work-generation.md
index 29a8775ce..9f780568b 100644
--- a/docs/integration-guides/work-generation.md
+++ b/docs/integration-guides/work-generation.md
@@ -126,6 +126,7 @@ Determines the number of local CPU threads to used for work generation. **While
 Set to `0` to turn off local CPU work generation.
 
 ### node.work_peers
+
 Used when offloading work generation to another node or service. Format must be ipv6, preceded by `::ffff:` if ipv4. Hostnames are supported since v21. Calls are made to the address:port designated using the standard RPC format [work_generate](../commands/rpc-protocol.md#work_generate). Example:
 
 ```toml
@@ -146,7 +147,6 @@ Sets a limit on the generation difficulty. Multiplier is based off the [base dif
 
 ### Benchmark commands
 
-
 **Nano PoW Benchmarking tool**
 
 The [Nano PoW Benchmark](https://github.com/koczadly/nano-pow-benchmark) tool is the preferred approach for benchmarking OpenCL-enabled hardware such as GPUs.
@@ -274,6 +274,7 @@ $$
 
 ??? example "Code Snippets"
     === "Python"
+
         ```python
         def to_multiplier(difficulty: int, base_difficulty) -> float:
           return float((1 << 64) - base_difficulty) / float((1 << 64) - difficulty)
@@ -283,6 +284,7 @@ $$
         ```
 
     === "Rust"
+
         ```rust
         fn to_multiplier(difficulty: u64, base_difficulty: u64) -> f64 {
           (base_difficulty.wrapping_neg() as f64) / (difficulty.wrapping_neg() as f64)
@@ -294,6 +296,7 @@ $$
         ```
 
     === "C++"
+
         ```cpp
         double to_multiplier(uint64_t const difficulty, uint64_t const base_difficulty) {
           return static_cast<double>(-base_difficulty) / (-difficulty);
diff --git a/docs/node-implementation/blocks.md b/docs/node-implementation/blocks.md
index 19b2348d7..f8bb2e607 100644
--- a/docs/node-implementation/blocks.md
+++ b/docs/node-implementation/blocks.md
@@ -6,6 +6,7 @@ description: Review of block handling in the current nano node implementation
 --8<-- "wip-living-whitepaper.md"
 
 ## Block publishing and propagation
+
 Nodes use a modified gossip protocol for message distribution that enables quick distribution of blocks and votes across the network while distributing the load required to propagate messages across multiple nodes rather than each node having to respond to requests from every other node.  Prioritization of messages are focused on the Principal Representative nodes that make up the core consensus mechanism where they receive blocks and votes directly from other nodes and then messages are spread to the rest of the network via gossiping.
 
 Blocks are initially broadcast and propagated across the network to different types of nodes based on the blocks status. Some basic rules are listed below:
diff --git a/docs/node-implementation/work.md b/docs/node-implementation/work.md
index 74a727503..ddaf38fef 100644
--- a/docs/node-implementation/work.md
+++ b/docs/node-implementation/work.md
@@ -17,7 +17,6 @@ description: Explore how work generation and management has been implemented in
 
 ---
 
-
 Existing whitepaper sections related to this page:
 
 * [Implementation](../whitepaper/english.md#implementation)
diff --git a/docs/protocol-design/attack-vectors.md b/docs/protocol-design/attack-vectors.md
index 0237f62d2..e8c5eb1d0 100644
--- a/docs/protocol-design/attack-vectors.md
+++ b/docs/protocol-design/attack-vectors.md
@@ -6,6 +6,7 @@ description: Understand the different attack vectors on the nano network and the
 --8<-- "wip-living-whitepaper.md"
 
 ## Block gap synchronization
+
 | | |
 |----------------|-------------
 | **Risk**        | Low risk
diff --git a/docs/protocol-design/blocks.md b/docs/protocol-design/blocks.md
index f540de3ab..25aa9b4bd 100644
--- a/docs/protocol-design/blocks.md
+++ b/docs/protocol-design/blocks.md
@@ -31,8 +31,8 @@ Depending on the action each transaction intends to perform, the `"link"` field
 | Send    | string             | Destination "nano_" address                |
 | Receive | 64 hex-char string | Pairing block's hash (block sending funds) |
 
-
 An example of a Nano block:
+
 ```
 "block": {
   "type": "state",
@@ -46,6 +46,7 @@ An example of a Nano block:
   "work": "cab7404f0b5449d0"
 }
 ```
+
 Note that there is an open [proposal](https://github.com/nanocurrency/nano-node/issues/2864) to update the state block with version, block height, and subtype fields.
 
 ### Account balance
@@ -64,7 +65,6 @@ In traditional blockchain-based cryptocurrencies like Bitcoin, a block is a grou
 
 To create an account, an open transaction must be issued first. This is always the first transaction (block height 1) of every account-chain and can be created upon the first receipt of funds. To open an account, you must have sent some funds to it with a send transaction from another account. The funds will be pending on the receiving account. The account field stores the public-key (address) derived from the private-key that is used for signing. The link field contains the hash of the transaction that sent the funds. On account creation, a representative must be chosen to vote on your behalf; this can be changed later. The account can declare itself as its own representative. 
 
-
 ### Send
 
 A send transaction is one that decreases the sender's account balance by the amount they intend to send. To send from an address, the address must already have been opened with an open (receive) block and therefore will have a balance. The previous field contains the hash of the previous block in the account-chain. The link field contains the account for funds to be sent to. A send block is immutable once confirmed by the network. This means the funds are deducted from the balance of the sender's account and wait as pending until the receiving party signs a block to accept these funds. Pending funds should not be considered awaiting confirmation, as they are as good as spent from the senders account and the sender cannot revoke the transaction.
diff --git a/docs/protocol-design/distribution-and-units.md b/docs/protocol-design/distribution-and-units.md
index df4dd4872..76721fd8d 100644
--- a/docs/protocol-design/distribution-and-units.md
+++ b/docs/protocol-design/distribution-and-units.md
@@ -9,6 +9,7 @@ description: Review the breakdown of divisibility, distribution and units within
 --8<-- "wip-living-whitepaper.md"
 
 ## Divisibility
+
 There are three important aspects of divisibility of the supply which are satisfied by the final distributed amount:
 
 - The supply needs to be able to be divided up amongst a large number of users with users possibly wanting several accounts.
@@ -16,9 +17,11 @@ There are three important aspects of divisibility of the supply which are satisf
 - The supply should be able to deal with deflation over time as accounts are abandoned.
 
 ## Distribution
+
 The distribution of Nano (formerly RaiBlocks) was performed through solving manual captchas starting in late 2015 and ending in October 2017. Distribution stopped after \~39% of the [Genesis](/glossary#genesis) amount was distributed and the rest of the supply was burnt.[^1]
 
 !!! info "Distribution Accounts"
+
 	* **Genesis**: `nano_3t6k35gi95xu6tergt6p69ck76ogmitsa8mnijtpxm9fkcm736xtoncuohr3` 
 	* **Landing**: `nano_13ezf4od79h1tgj9aiu4djzcmmguendtjfuhwfukhuucboua8cpoihmh8byo`
 	* **Faucet**: `nano_35jjmmmh81kydepzeuf9oec8hzkay7msr6yxagzxpcht7thwa5bus5tomgz9`
@@ -30,6 +33,7 @@ During distribution the Genesis seed was kept in cold storage and funds were mov
 	With $2^{128} - 1$ raw (i.e. `FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF` HEX raw) in the original Genesis account, upon closing of the faucet and burning of the remaining funds, the total supply which is 100% in circulation ended at **~133,248,297 nano** (or more precisely 133248297920938463463374607431768211455 raw). Since then, additional funds have been sent to the known burn address slightly lowering the amount in circulation as a result. This amount can be found using the [available_supply](/commands/rpc-protocol/#available_supply) RPC.
 
 ## Unit Dividers
+
 A 128 bit integer is used to represent account balances. The reference wallet uses nano as a divider.
 
 | Name              | Integer                            | Power    | Previous              |
@@ -37,7 +41,6 @@ A 128 bit integer is used to represent account balances. The reference wallet us
 | nano (NANO/Nano)  | 1000000000000000000000000000000    | $10^{30}$| Mnano                 |
 | raw               | 1                                  | $10^{0}$ | raw                   |
 
-
 **NOTE:** 1 raw is the smallest possible division and is used in QR codes as `amount`, while nano is the current standard division used for human readable elements in most wallets, on exchanges, etc.
 
 A set of SI prefixes[^2] from the base nano has been previously used to make the numbers more accessible and avoid confusion in certain scenarios, but this approach is not common (e.g., micronano or μnano for $10^{24}$).
diff --git a/docs/protocol-design/introduction.md b/docs/protocol-design/introduction.md
index fcac55270..8d4cc0a72 100644
--- a/docs/protocol-design/introduction.md
+++ b/docs/protocol-design/introduction.md
@@ -29,6 +29,7 @@ To date, the Nano network has processed more than 118 million transactions with
 In 2008, an anonymous individual under the pseudonym Satoshi Nakamoto published a whitepaper outlining the world’s first decentralized cryptocurrency, Bitcoin [^1]. A key innovation brought about by Bitcoin was the blockchain, a public, immutable and decentralized data-structure which is used as a ledger for the currency’s transactions. Unfortunately, as Bitcoin matured, several issues in the protocol made Bitcoin prohibitive for many applications: 
 
 1. Poor scalability: Each block in the blockchain can store a limited amount of data, which means the system can only process so many transactions per second, making
+
 spots in a block a commodity. Median transaction fees fluctuate between a few cents and as high as \$34 (currently ~\$2.98 as of August 26, 2020) [^4].
 
 2. High latency: Average confirmation times fluctuate between 10 and 300 minutes [^5]. In addition, most Bitcoin services require more than one confirmation before considering a transaction fully-settled [^6], which adds additional latency for end users.
diff --git a/docs/protocol-design/ledger.md b/docs/protocol-design/ledger.md
index a500014f8..45b1f6fc0 100644
--- a/docs/protocol-design/ledger.md
+++ b/docs/protocol-design/ledger.md
@@ -52,6 +52,7 @@ This difference in transaction structures means the terminology used can have di
   "work": "cab7404f0b5449d0"
 }
 ```
+
 _Figure 2 - An example Nano block with all required fields_
 
 Note that there is an open [proposal](https://github.com/nanocurrency/nano-node/issues/2864) to update the state block with version, block height, and subtype fields.
diff --git a/docs/protocol-design/networking.md b/docs/protocol-design/networking.md
index b18b98176..4e7c1ae6e 100644
--- a/docs/protocol-design/networking.md
+++ b/docs/protocol-design/networking.md
@@ -6,14 +6,17 @@ description: Details of networking setup design for nano protocol
 --8<-- "wip-living-whitepaper.md"
 
 ## TCP messages
+
 TCP is used for traffic on the [live network](/glossary#live-network) and for bulk data transfer on the [bootstrap network](/glossary#bootstrap-network).
 
 --8<-- "network-details.md"
 
 ## IPV4/IPV6 addressing
+
 The system is built to only operate on IPv6 and uses IPv4-mapped IPv6 addresses to connect to IPv4 hosts.
 
 ## Node telemetry
+
 In _v21_ node telemetry was added to node. This allows peers to communicate telemetry metrics to each other. For specific details on the message format see `telemetry_ack` in the [protocol specification](https://github.com/nanocurrency/protocol/tree/master/reference).
 
 The nodes are designed to reply to `telemetry_req` messages. They avoid replying if messages are received from the same peer in quick succession; the minimum time until another reply is 60 seconds on the main network, 15 seconds on beta. This is done to reduce bandwidth.
@@ -21,6 +24,7 @@ The nodes are designed to reply to `telemetry_req` messages. They avoid replying
 Telemetry messages bypass the node's bandwidth limiter so that services monitoring the network can still do so during when the network is heavily used. Sending `telemetry_req` frequently within this exclusion zone could see your ip blacklisted by other peers. The node safely handles this for you by doing ongoing requests periodically and only sent when valid to do so.
 
 ### Signing
+
 `Telemetry_ack` messages are signed using [ED25519](/protocol-design/signing-hashing-and-key-derivation/#signing-algorithm-ed25519) as follows:
 
 ```
diff --git a/docs/protocol-design/orv-consensus.md b/docs/protocol-design/orv-consensus.md
index c11745896..cb5a4a8cd 100644
--- a/docs/protocol-design/orv-consensus.md
+++ b/docs/protocol-design/orv-consensus.md
@@ -70,6 +70,7 @@ This implementation decision was made in part because of the exponential bandwid
 ---
 
 ## Incentives for participating in consensus
+
 [Incentives to run a node](https://medium.com/nanocurrency/the-incentives-to-run-a-node-ccc3510c2562)
 
 ---
diff --git a/docs/protocol-design/signing-hashing-and-key-derivation.md b/docs/protocol-design/signing-hashing-and-key-derivation.md
index 454a30b78..baf19d75d 100644
--- a/docs/protocol-design/signing-hashing-and-key-derivation.md
+++ b/docs/protocol-design/signing-hashing-and-key-derivation.md
@@ -10,12 +10,14 @@ description: All about the methods for signing messages, hashing data and derivi
 ED25519 is an elliptic curve algorithm developed in an academic setting with a focus on security from side channel attack, performance, and fixing a lot of the little annoyances in most elliptic curve systems[^1]. However, it should be noted that instead of using SHA-512 in the key derivation function, Nano uses Blake2b-512.
 
 !!! failure "Incorrect, SHA-512 has been used"
+
   ```
   0000000000000000000000000000000000000000000000000000000000000000 ->
   3B6A27BCCEB6A42D62A3A8D02A6F0D73653215771DE243A63AC048A18B59DA29
   ```
 
 !!! success "Correct, Blake2b-512 digested the seed"
+
   ```
   0000000000000000000000000000000000000000000000000000000000000000 ->
   19D3D919475DEED4696B5D13018151D1AF88B2BD3BCFF048B45031C1F36D1858
diff --git a/docs/releases/network-upgrades.md b/docs/releases/network-upgrades.md
index ae4eadeaf..2d09c7db5 100644
--- a/docs/releases/network-upgrades.md
+++ b/docs/releases/network-upgrades.md
@@ -168,9 +168,11 @@ Of course many features, including protocol changes, can be activated immediatel
 ---
 
 ## Upgrade methods
+
 There are various methods used to upgrade and a brief overview of each, along with benefits and drawbacks, are included below. Upgrades for behaviors contained and activated with a single node release are not included as they are the foundation on top of which these other methods are made capable.
 
 ### Phased node upgrades
+
 A feature is introduced in a node release but not activated for use across the network until a subsequent node release. See [State block upgrade](#state-blocks) details for an example.
 
 | Trigger | Uses blocks | Benefits | Drawbacks |
@@ -178,6 +180,7 @@ A feature is introduced in a node release but not activated for use across the n
 | Multiple node upgrades | No | <ul><li>No manual intervention or automated process needed</li><li>Uses already established upgrade process node operators are used to</li></ul> | <ul><li>Longer time period to get feature activated</li><li>Cannot be used to perform upgrades needed simultaneously across the network</li></ul> |
 
 ### Hardcoded date
+
 A date is hardcoded into the node release to activate a feature or behavior at a specific time in the future. See [Vote-by-Hash upgrade](#vote-by-hash) details for an example.
 
 | Trigger | Uses blocks | Benefits | Drawbacks |
@@ -185,6 +188,7 @@ A date is hardcoded into the node release to activate a feature or behavior at a
 | Node upgrade + specific date | No | <ul><li><span class="no-break">Simple to implement</span></li><li>No manual activity required</li></ul> | <ul><li>Inability to adjust timing without rushing new release out</li></ul> |
 
 ### Canary block(s)
+
 The hash of a block is hardcoded in the node such that once that hash is seen by the node, it will activate a feature or behavior. Multiple block hashes can be used to perform different phases of a transition. See [State blocks upgrade](#state-blocks) details for an example. 
 
 | Trigger | Uses blocks | Benefits | Drawbacks |
@@ -192,6 +196,7 @@ The hash of a block is hardcoded in the node such that once that hash is seen by
 | Node upgrade + distribution of one block per transition phase | Yes | <ul><li>Can be used for multi-phase upgrades, including in combination with other options</li><li>Timing flexible</li></ul> | <ul><li>Requires manual intervention</li><li>Adds additional code complexity</li><li>Can cause unchecked table to fill during transition</li></ul> |
 
 ### Epoch blocks
+
 A special block type that can only be generated using a pre-determined private key. These will be accepted by nodes and be attached as the frontier blocks on each account-chain on the network. This feature was built to allow very limited controls using these blocks: they cannot change account balances or representatives, only upgrade the account versions to allow new block structures. See [State block upgrade](#state-blocks) details for an example.
 
 | Trigger | Uses blocks | Benefits | Drawbacks |
diff --git a/docs/releases/node-releases.md b/docs/releases/node-releases.md
index 0c9c6336a..22e8064b7 100644
--- a/docs/releases/node-releases.md
+++ b/docs/releases/node-releases.md
@@ -9,6 +9,7 @@ Updates to the Nano protocol are done through major node releases, occurring app
 	Head over to the [Nano Roadmap GitHub Project](https://github.com/orgs/nanocurrency/projects/27) for a more dynamic and updated view of the upcoming features under research and implementation for the Nano node and protocol.
 
 ## Current Release
+
 The following release is the latest and only release actively supported by the Nano Foundation. This release and the [Active Releases](#active-releases) below represent the only node versions that will participate on the main network. More details can be found on the [Current Release Notes page](/releases/current-release-notes).
 
 --8<-- "release-details-v28-2.md"
@@ -20,6 +21,7 @@ The following release is the latest and only release actively supported by the N
 ---
 
 ## Next Planned Release
+
 The following release is currently under development. Details about potential features to be included can be found in the [Nano Roadmap GitHub Project](https://github.com/orgs/nanocurrency/projects/27).
 
 --8<-- "release-details-v29-0.md"
@@ -29,6 +31,7 @@ The following release is currently under development. Details about potential fe
 ---
 
 ## Active Releases
+
 The following releases can still actively participate on the network by peering with other nodes of the same versions. Any nodes running versions earlier than these will no longer peer with the latest and fall out of sync with the network.
 
 --8<-- "release-details-v28-2.md"
@@ -60,6 +63,7 @@ The following releases can still actively participate on the network by peering
 ---
 
 ## Inactive Releases
+
 The following versions are no longer peered with by nodes running the active versions above and will not work properly communicate if run on the network. The details below are for historical purposes only.
 
 ??? info "Inactive Releases"
diff --git a/docs/releases/release-v19-0.md b/docs/releases/release-v19-0.md
index b20ea9730..c587d5174 100644
--- a/docs/releases/release-v19-0.md
+++ b/docs/releases/release-v19-0.md
@@ -8,12 +8,14 @@ description: Details of the V19.0 nano node release including upgrade notices, m
 ## Upgrade Notices
 
 ### Version Limits
+
 Upgrades from versions V17.1 and to V19 will involve a sequential database upgrade and impact participation of the node on the network. RPC calls will be unavailable for a long period of time amongst other impacts.
 
 !!! warning "Upgrading from V17.1 and earlier to V19.0 not recommended"
 	It is highly recommended that nodes are upgraded to V18.0 first or a V18.0 ledger is acquired and used when upgrading to V19.0.
 
 ### Confirmation tracking considerations
+
 The addition of confirmation height to the database requires the node to validate that blocks are confirmed before the cementing can occur. This process can take up to 24 hours or longer to complete and will cause an increase in some resource usage, particularly CPU and network bandwidth increases, but won’t impact participation on the network. For integrations watching confirmations, the existing [HTTP callback](/integration-guides/advanced/#http-callback), [block_confirm](/commands/rpc-protocol/#block_confirm) RPC and [confirmation_history](/commands/rpc-protocol/#confirmation_history) RPC methods will continue to function as before.
 
 !!! warning "Tracking confirmed block hashes required"
@@ -26,9 +28,11 @@ For those looking to utilize the new WebSocket confirmation subscription or new
 * To validate that confirmation height upgrade is complete, note the `count` value from the [`block_count`](/commands/rpc-protocol/#block_count) RPC when the upgrade is started and once the `cemented` amount returned by this call (include the `include_cemented` option) is higher than that previous count, cementing is in sync.
 
 ### Emitting nano_ prefixed addresses
+
 In this and future versions, all addresses emitted from the node will use the `nano_` prefix. It will continue to support input for `xrb_` prefixed addresses, but all services must verify they are properly set up to handle the node outputting `nano_` prefixed addresses.
 
 ### Live network over TCP
+
 Live network traffic over TCP is now available and operates on the same port (7075 for main network, 54000 for beta network) as the bootstrapping network that was already available over TCP. Because of this, existing network setups that are open inbound and outbound on port 7075 for TCP should function as expected with V19.0. For those running production services, it is still recommended to verify [network ports setup](/running-a-node/node-setup/#network-ports) and consider setting up a new node on internal networks to ensure it can connect and participate on the main network before production nodes are upgraded.
 
 * To check for proper connection via TCP, call the [`peers`](/commands/rpc-protocol/#peers) RPC with `peer_details` option and look for peers with `type` = `tcp`. This command can be used to search for these instances:
@@ -42,15 +46,19 @@ curl -sd '{"action": "peers", "peer_details":"true"}' [::1]:7076 | grep "\"type\
 ## Major Updates
 
 ### Confirmation Height
+
 This provides cementing of blocks by marking on an account the highest block height that has been confirmed for the account. A more detailed look at this feature can be found in the relatd Medium article: https://medium.com/nanocurrency/looking-up-to-confirmation-height-69f0cd2a85bc
 
 ### TCP Network
+
 Blocks being published and voted on live are now supported via TCP, with UDP remaining as a fallback. See the TCP callouts in [Upgrade Notices](#upgrade-notices) above for information about verifying your network setup is ready for the upgrade.
 
 ### Dynamic Proof-of-Work and Prioritization
+
 With the ability to track work difficulty seen on the network and have the node wallet produce more difficult work for local blocks, this feature allows users to get their transactions prioritized for processing. More details about this feature can be found in the Medium article: https://medium.com/nanocurrency/dynamic-proof-of-work-prioritization-4618b78c5be9
 
 ### RPC Process Options
+
 By default the RPC server will run in the node process, but can be configured to run as a child process or completely out of process (currently limited to running on the same computer), depending on your needs. See [Running Nano as a service](/integration-guides/advanced/#running-nano-as-a-service) for more details.
 
 ---
diff --git a/docs/releases/release-v20-0.md b/docs/releases/release-v20-0.md
index e957efec3..d67ab90ed 100644
--- a/docs/releases/release-v20-0.md
+++ b/docs/releases/release-v20-0.md
@@ -25,6 +25,7 @@ This version brings some new optimizations to the ledger which require database
 * Doing proper ledger backups is recommended before starting this process. **Ensure you have enough disk space to allow for any ledger backups plus the additional disk space required for the database upgrade mentioned above.** A new config option in V20, `node.backup_before_upgrade`, will allow for automated ledger backups between future versions.
 
 ### New .toml config files
+
 A new setup in V20.0 uses internal default config values, so config files are only needed for non-default settings. During upgrade new .toml format files will be created for the config.json and rpc_config.json files if they contain non-default values. Before migration `config_backup_toml_migration.json` and `rpc_config_backup_toml_migration.json` files will be created for backup.
 
 The following commands can be used to generated commented out, complete config files for review:
@@ -37,9 +38,11 @@ The following commands can be used to generated commented out, complete config f
 More details on the new configuration setup can be found in the node [Configuration documentation](https://docs.nano.org/running-a-node/configuration/).
 
 ### Networking changes
+
 Improvements to default network setup in this version requires less setup from node operators, specifically around port forwarding. Although new setups will immediately benefit, any existing systems that have already setup port forwarding may be impacted by these changes. For those systems, we recommend validating your network setup allows proper peering with a test V20.0 node prior to upgrading. If you run into issues, review the [Troubleshooting UPnP documentation](/running-a-node/troubleshooting/#troubleshooting-upnp) for assistance. Additional help can be sought in the [Node and Representative Management forum category](https://forum.nano.org/c/node-and-rep). 
 
 ### Proof-of-Work management
+
 A couple changes to PoW management that services should be aware of:
 
 * With OpenCL enabled, nodes will still use the local CPU for work generation by default. Setting `node.work_threads` to `0` will turn this off if required.
@@ -48,29 +51,32 @@ A couple changes to PoW management that services should be aware of:
 **Other updates to review**  
 Improvements to the [External Management](https://docs.nano.org/integration-guides/key-management/#external-management) and [Block Confirmation and Tracking](https://docs.nano.org/integration-guides/block-confirmation-tracking/) documentation should help clarify the recommended approaches to building integrations.
 
-
 ---
 
 ## Major Updates
  
 ### Migration to .toml config files
+
 Better legibility, support for comments, and no more having the node write to your config files are some of the benefits of this upgrade. Any non-default values captured in your existing .json files will be migrated and you can export a full list of configuration options for use with simple commands. See additional callouts in [Upgrade Notices](#upgrade-notices) above and in the node [Configuration documentation](https://docs.nano.org/running-a-node/configuration/).
 
 ### Proof-of-Work regeneration outside development wallet
+
 Any requests to the [process RPC](https://docs.nano.org/commands/rpc-protocol/#process) will have the new `watch_work` option turned on by default, allowing the node to regenerate Proof-of-Work for blocks even if they are outside of the node’s development wallet. This makes Dynamic PoW and prioritization function more consistently across the network. If you have an external integration utilizing this RPC call, you will automatically start taking advantage of rework during confirmation delays on the network.
 
 ### RocksDB experimental support
+
 With better disk IO usage, RocksDB is being introduced in this version with experimental support. It is not recommended for use in production, but those interested in testing out a more performant database for the ledger should checkout [how to install RocksDB](https://docs.nano.org/running-a-node/rocksdb-ledger-backend/) and try it out on development and test systems. We also have a [related discussion in our forum](https://forum.nano.org/t/rocksdb-ledger-backend-testing/111/4) for those interested.
 
 ### Active elections and other optimizations
+
 Thanks to our excellent community testers putting effort into collecting and analyzing block, voting and confirmation data from the beta network, we’ve found various optimizations with the active elections process, confirmation request attempts and bootstrapping behaviors. Various changes have been implemented to help reduce resource usage on nodes in various areas and increase the available throughput on the network. This feature also enhances the effectiveness of prioritization and rework of PoW. No action is needed to take advantage of these great updates. 
 
 ### Infrastructure for PoW transition
+
 Back in September we [announced a new PoW algorithm design](https://medium.com/nanocurrency/v20-a-look-at-lydia-62bf6e1b24b) we had been working on which aimed to be memory hard. After open sourcing an implementation of the algorithm, an efficient low-memory solution was found and we subsequently [removed the algorithm implementation from V20](https://medium.com/nanocurrency/nano-pow-v20-update-e2197ff52941).
 
 As part of the original implementation work we were able to setup infrastructure for moving PoW out of the node process in the future, and also added support for version 2 of epoch blocks, which will allow the [network upgrade](https://docs.nano.org/releases/network-upgrades/) later when a new PoW algorithm is ready. These updates will be included in Lydia but not be utilized until a future version. To follow along with node releases going forward, check out the [Upcoming Features](https://docs.nano.org/releases/upcoming-features/) page.
 
-
 ---
 
 ## RPC Updates
diff --git a/docs/releases/release-v21-0.md b/docs/releases/release-v21-0.md
index 60cbc08db..18797d231 100644
--- a/docs/releases/release-v21-0.md
+++ b/docs/releases/release-v21-0.md
@@ -13,14 +13,17 @@ description: Details of the V21.0 nano node release including upgrade notices, m
 The following key upgrade details should be reviewed by all node operators to determine how they will impact plans for upgrading:
 
 ### Database upgrades
+
 An in-place database upgrade will occur with this release to accomodate epoch-related flags. Machines will need at least 30GB free disk space to accommodate the upgrade. During the upgrade process, which may take multiple hours to complete depending on the machine specs, the node will not participate on the network or respond to RPC calls.
 
 As a result, **the recommended approach is to upgrade the ledger in a separate environment before replacing on production**. For detailed steps on this approach and other options, see the [Updating the node section](/running-a-node/ledger-management/#updating-the-node) of the Ledger Management page.
 
 ### Minor RPC breaking changes
+
 Although breaking changes were kept to a minimum in this release, there are two RPC calls with such changes: `work_validate` and `bootstrap_status`. For integrations using them, carefully review the additional details on these changes included in the [RPC Updates](#rpc-updates) section below.
 
 ### Upcoming v2 epoch upgrade
+
 As outlined in the [February Development Update: V21 PoW Difficulty Increases](https://medium.com/nanocurrency/development-update-v21-pow-difficulty-increases-362b5d052c8e), an epoch block distribution must be done to complete the upgrade to the new work difficulty thresholds. **All integrations generating work are encouraged to review the details on the [Network Upgrades page under the Upcoming upgrades section](/releases/network-upgrades#increased-work-difficulty) ahead of the epoch V2 distribution.**
 
 !!! danger "Only nodes V21.0+ will be active after epoch distribution"
@@ -31,6 +34,7 @@ As outlined in the [February Development Update: V21 PoW Difficulty Increases](h
 	**All network participants are encouraged to upgrade to V21.1 as soon as possible to avoid disruption.**
 
 ### UDP disabled by default
+
 With all active peers capable of communicating via TCP, the UDP connections will be disabled by default in this version. To avoid disruptions, all nodes should allow traffic on 7075 TCP (see [Network Ports](/running-a-node/node-setup/#network-ports) details) and once upgraded, the [`peers`](/commands/rpc-protocol/#peers) RPC call should return at least dozens of peers and the [`confirmation_quorum`](/commands/rpc-protocol/#confirmation_quorum) RPC call should have a `peers_stake_total` value in the high tens of millions of Nano.
 
 Although not recommended, if necessary the temporary use of UDP can be done with the new [`--enable_udp`](/commands/command-line-interface/#-enable_udp) flag.
@@ -40,11 +44,13 @@ Although not recommended, if necessary the temporary use of UDP can be done with
 ## Major Updates
  
 ### Work difficulty increase
+
 As mentioned in the [Upgrade Notices](#upgrade-notices) section above, work difficulty changes were implemented in V21, but will not be activated until epoch v2 blocks are distributed at a future date. Please review the [Upcoming upgrades section](/releases/network-upgrades#increased-work-difficulty) of the Network Upgrades page for details.
 
 Updates on the progress toward the epoch upgrade will be posted in our many social channels as well as sent through our technical updates mailing list which can be joined here: <a href="http://eepurl.com/gZucL1" class="button" target="_blank" rel="noopener">Join Mailing List</a>.
 
 ### Node Telemetry
+
 To allow better communication between nodes about various performance and other details, telemetry was added between peers. Various version details, account and block counts, active difficulty and more can be discovered from individual peers or summarized across them.
 
 Details of what is shared and options for receiving them can be found in the [node telemetry WebSocket section](../integration-guides/websockets.md#node-telemetry) and [`node_telemetry`](/commands/rpc-protocol/#telemetry) RPC.  For protocol level details, see [Node Telemetry section](/protocol-design/networking/#node-telemetry) under Protocol Design > Networking.
@@ -54,9 +60,11 @@ Details of what is shared and options for receiving them can be found in the [no
 Continued conversation around telemetry is happening through the [related forum discussion](https://forum.nano.org/t/node-telemetry-metrics/112/8).
 
 ### IPC 2.0
+
 As a key update towards the upcoming RPC 2.0 redesign, this background upgrade will provide more performant communication to the node, allow easier integration across various languages by supporting Flatbuffers and provide the foundation for [more granular authorization of specific calls](https://github.com/cryptocode/notes/wiki/IPC-Authorization).
 
 ### Better election alignment and performance
+
 Behind the scenes many improvements were made to better streamline alignment of elections across the network and allow for better performance. Resource usage by nodes, particularly network bandwidth, will be reduced even further than previous levels. No action is needed to take advantage of this increase other than upgrading your node to V21 as soon as you can!
 
 ---
diff --git a/docs/releases/release-v21-3.md b/docs/releases/release-v21-3.md
index 55250468f..1c2629b75 100644
--- a/docs/releases/release-v21-3.md
+++ b/docs/releases/release-v21-3.md
@@ -3,7 +3,6 @@ description: Details of the V21.3 nano node release including upgrade notices, m
 
 # V21.3
 
-
 --8<-- "release-details-v21-3.md"
 
 !!! success "No special upgrade considerations"
diff --git a/docs/releases/release-v22-0.md b/docs/releases/release-v22-0.md
index 96079ae0d..db7379477 100644
--- a/docs/releases/release-v22-0.md
+++ b/docs/releases/release-v22-0.md
@@ -71,7 +71,6 @@ A [new election prioritization and scheduling mechanism](https://forum.nano.org/
 * **REMOVAL** The `online_weight_quorum` value, which was used in combination with online voting weight values to determine the voting weight necessary for confirming a block, has been [removed as a configuration option and hardcoded to 67% for all nodes](https://github.com/nanocurrency/nano-node/pull/3052). Any existing overrides for `online_weight_quorum` in the `config-node.toml` file can be removed.
 * The default value for `active_elections_size` in `config-node.toml` has been reduced from 50,000 to 5,000. This change was to help limit extra network traffic generated by large amounts of elections as behavior of the active elections container was modified for election scheduler and prioritization needs.
 
-
 ---
 
 ## RPC updates
diff --git a/docs/releases/release-v22-1.md b/docs/releases/release-v22-1.md
index 59d2f8175..e8a9a1951 100644
--- a/docs/releases/release-v22-1.md
+++ b/docs/releases/release-v22-1.md
@@ -6,8 +6,8 @@ description: Details of the V22.1 nano node release including upgrade notices an
 --8<-- "release-details-v22-1.md"
 
 ## Upgrade notices
-There are no special considerations when upgrading from V22.0 to V22.1. There are no database upgrades or API changes.
 
+There are no special considerations when upgrading from V22.0 to V22.1. There are no database upgrades or API changes.
 
 ## Major updates
 
diff --git a/docs/releases/release-v23-1.md b/docs/releases/release-v23-1.md
index 6f102a2b4..89e70dd45 100644
--- a/docs/releases/release-v23-1.md
+++ b/docs/releases/release-v23-1.md
@@ -6,6 +6,7 @@ description: Details of the V23.1 nano node release including upgrade notices an
 --8<-- "release-details-v23-1.md"
 
 ## Upgrade notices
+
 There are no special considerations when upgrading from V22.X or V23.0 to V23.1. There are no database upgrades or API changes.
 
 ## Fixes
diff --git a/docs/releases/release-v23-3.md b/docs/releases/release-v23-3.md
index 8ef4c5632..c731de7b4 100644
--- a/docs/releases/release-v23-3.md
+++ b/docs/releases/release-v23-3.md
@@ -6,6 +6,7 @@ description: Details of the V23.3 nano node release including upgrade notices an
 --8<-- "release-details-v23-3.md"
 
 ## Upgrade notices
+
 There are no special considerations when upgrading from V22.X or V23.X to V23.3. There are no database upgrades or API changes.
 
 ## Fixes
diff --git a/docs/releases/release-v24-0.md b/docs/releases/release-v24-0.md
index 0d1b35604..04a647518 100644
--- a/docs/releases/release-v24-0.md
+++ b/docs/releases/release-v24-0.md
@@ -14,6 +14,7 @@ Exchanges who have not faced issues with their nano nodes are recommended to awa
 In general, exchanges, services and integrations are encouraged to join [the test network](../running-a-node/test-network.md) for performing integration testing. This network mimics the live network in work requirements but has a smaller number of nodes and a lower block count for easier setup.
 
 ### Minor RPC breaking changes
+
 There are three RPC calls with such changes: `accounts_balances`, `accounts_frontiers`, and `accounts_representatives`. For integrations using them, carefully review the additional details on these changes included in the [RPC Updates](#rpc-updates) section below.
 
 ---
diff --git a/docs/releases/release-v25-0.md b/docs/releases/release-v25-0.md
index a329f1de9..5b14a02ba 100644
--- a/docs/releases/release-v25-0.md
+++ b/docs/releases/release-v25-0.md
@@ -16,6 +16,7 @@ In general, exchanges, services and integrations are encouraged to join [the tes
 This version no longer stores unchecked data in the database. The data is now held in memory, resulting in reduced storage access and mitigated database growth. As a result of this change, an upgrade will be performed on the database to eliminate the unchecked table. This upgrade is applicable to both database types, LMDB and RocksDB.
 
 ### Minor RPC breaking changes
+
 The following RPC calls have undergone minor breaking changes: `accounts_balances`, `accounts_frontiers`, and `accounts_representatives`. These changes address the issue where an error is returned for the entire response when at least one of the requested accounts results in an error.
 
 The fix was initially introduced in [V24.0](release-v24-0.md#rpc-updates), but it inadvertently disrupted the `accounts_balances` RPC by breaking the default zero balance and zero receivable response when the account is not found in the ledger. Additionally, the absence of the error message within a specific entry disrupts the established JSON format.
@@ -31,23 +32,29 @@ The Proof-of-Work (PoW) server is no longer bundled within the docker artifact.
 ## Major updates
 
 ### Adding the ascending bootstrap client
+
 In [V24](release-v24-0.md#ascending-bootstrap) the server components and network messages were added. In V25, the bootstrap client is added, enabling it to finally work on the nano node software. This leads to several improvements which reduce socket usage, lighten the burden on the unchecked table by pulling blocks in an ascending manner instead of descending, allows the unchecked table to exist entirely in memory, reduces bandwidth and isolates the bootstrapping logic from the rest of the node.
 
 The client also uses a priority-weighted tracing algorithm to pull successive iterations of blocks from peers, which further improves the efficiency of the syncing process. Overall, these improvements significantly reduce the time it takes for a new node to sync with the rest of the network.
 
 ### Optimistic elections
+
 This is a major change that improves the efficiency and speed of the election process. When a node is starting up, it needs to confirm a large number of blocks, and this process can take a long time. Currently, the node confirms blocks one by one. The new feature randomly selects an account with unconfirmed blocks and confirms the latest unconfirmed block in the account chain, which speeds up the process. This feature is limited to 500 elections and does not replace the current method. It's a simple algorithm but makes a big difference in the efficiency of the process. This should significantly increase the speed of node syncing.
 
 ### Complete removal of UDP channel implementation
+
 The nano protocol was originally written using UDP and later transitioned to TCP. In the V24 release, most of the UDP protocol code was already removed. In V25, the remaining of it has been removed from the network channels, leaving the only implemented transport layer to be the TCP protocol. It enabled some other removals like the message buffer class and other code that was already unuseful since the UDP deprecation.
 
 ### Bug fixes
+
 Several bugs were fixed, including issues with counting successes/failures, updating token buckets, and race conditions.
 
 ### Enhancements
+
 Several enhancements were made to the Nano node software, including improved stat counters, refactoring of the election vote process, and cleaning up of stat counters for active transactions.
 
 ### Build, Text, Automate, Cleanup & Chores
+
 The V25 version of the Nano node software includes several updates related to build, test, automation, cleanup, and chores. These updates include improvements to the unit test chains setup, fixing sign comparison mismatches, removing unnecessary "usings," disambiguating implemented locks, and more. Additionally, the minimum required OSX version has been increased to 10.15, and the IPv6 socket is now specified for IPv4 communication.
 
 ---
@@ -67,6 +74,7 @@ The V25 version of the Nano node software includes several updates related to bu
 ---
 
 ## Ledger & Database
+
 * The unchecked table was removed from LMDB and RocksDB
 * RocksDB now supports database upgrades
 * RocksDB was updated to version 7.8.3
diff --git a/docs/releases/release-v27-0.md b/docs/releases/release-v27-0.md
index 68f048023..6b2f38b3f 100644
--- a/docs/releases/release-v27-0.md
+++ b/docs/releases/release-v27-0.md
@@ -32,29 +32,37 @@ V27 RPC changes are  minor and non-breaking.
 ## Major updates
 
 ### Fair Queueing Enhancements
+
 Designed by Piotr Wójcik, the fair queue has been integrated into the nano node, ensuring equal processing time for each network peer. The fair queue orders requests in a fair, round-robin fashion, which is needed by several components in the node, including block, network message, bootstrap request, and vote request processing. These fair queues help ensure that higher priority transactions are seen and prioritized more consistently, even during network congestion.
 
 ### Network Handling Rewrite
+
 Significant portions of the networking stack have been rewritten and simplified. Legacy code that handled half-duplex TCP channels has been removed and all TCP connections now operate full-duplex. Asynchronous callback-style code has been replaced with coroutines in several places simplifying code flow.
 
 ### Network Flow Control Improvements
+
 This suite of features optimises transaction processing, guards against spam and denial-of-service attacks, and ensures equitable resource distribution.
 
 ### Up to 255 votes per message
+
 V27 allows voting messages to contain up to 255 votes per message, an increase from the previous limit of 12. This enhancement reduces voting traffic and network congestion, improving consensus efficiency and robustness. Note that this change de-peers nodes older than V26.0.
 
 ### Additional prioritization bucket
+
 An additional prioritization bucket for amounts between Ӿ0.000001 and Ӿ0.0003 has been added, for a total of 63. More precisely, amounts above Ӿ0.0000006 (2^79 raw) and below Ӿ0.000309 (2^88 raw) will fall in this new bucket. All existing buckets remain unchanged to minimize the impact of bucket reallocation. Many Nano faucets send amounts in this range to new users trying out nano for the first time, and many wallets use Ӿ0.000001 as the minimum amount for automatic receives. More details on buckets and bucket ranges [here](../protocol-design/spam-work-and-prioritization.md/#prioritization-details).  
 
 ### Configurable Logging
+
 A new, highly configurable logging system allows node operators to tailor logging levels and outputs, enhancing debugging and health monitoring without excessive disk space use.
 
 ### Bug fixes
+
 Several bugs were fixed, including race conditions, missing notifications, & dependency issues.
 
 ---
 
 ## Official V27 Blog Post
+
 See [here](https://nano.org/en/blog/v27-denarius-preview--eb8bceac) for the official V27 blog post.
 
 ---
diff --git a/docs/releases/release-v28-0.md b/docs/releases/release-v28-0.md
index 0a7972bc0..c72d414b0 100644
--- a/docs/releases/release-v28-0.md
+++ b/docs/releases/release-v28-0.md
@@ -77,6 +77,7 @@ Xrb_ratio has been removed and replaced with nano_ratio:
 | xrb_ratio | 10^24 | 0.000001 | __removed__ |
  
 The following deprecated RPC endpoints for conversion have been removed:
+
 * `krai_from_raw`
 * `krai_to_raw`
 * `mrai_from_raw`
@@ -103,16 +104,19 @@ Consider reviewing and updating your configuration files with the `--update_conf
 Bootstrapping from scratch with pruning enabled causes the node to crash. As a potential workaround, node operators may be able to bootstrap with pruning disabled, and then enable pruning after bootstrapping is complete. A higher max_pruning_depth may also reduce the frequency of crashes. Pruning is considered experimental, so use it at your own risk - pruning is not currently recommended for important production services.
 
 #### Sideband Crashes
+
 Some nodes may experience occasional crashes due to missing sideband in election blocks. Please upgrade to v28.1 to resolve this issue.
 
 ---
 
 ## Official V28 Blog Post
+
 See [here](https://nano.org/en/blog/v28-electrum-the-start-of-commercial-grade--1b8adb83) for the official V28 blog post.
 
 ---
 
 ## V28 GitHub Milestone
+
 See [here](https://github.com/nanocurrency/nano-node/milestone/34?closed=1) for the V28 GitHub milestone.
 
 ---
diff --git a/docs/releases/release-v28-1.md b/docs/releases/release-v28-1.md
index ff2a5d059..a718f7edc 100644
--- a/docs/releases/release-v28-1.md
+++ b/docs/releases/release-v28-1.md
@@ -17,7 +17,6 @@ See the [V28.0 release notes](../releases/release-v28-0.md#major-updates) for th
 
 Some v28.0 users experienced occasional node crashes due to missing sideband in election blocks. This has been resolved in v28.1.
 
-
 ---
 
 ## Upgrade notices
diff --git a/docs/releases/release-v28-2.md b/docs/releases/release-v28-2.md
index 6ea0629bd..0c3800d49 100644
--- a/docs/releases/release-v28-2.md
+++ b/docs/releases/release-v28-2.md
@@ -6,6 +6,7 @@ description: Details of the V28.2 nano node release.
 --8<-- "release-details-v28-2.md"
 
 ---
+
 ## Upgrade notice
 
 This release introduces a ledger consistency check at startup.
diff --git a/docs/running-a-node/beta-network.md b/docs/running-a-node/beta-network.md
index fd051fc05..e402b367e 100644
--- a/docs/running-a-node/beta-network.md
+++ b/docs/running-a-node/beta-network.md
@@ -7,8 +7,8 @@ The beta network exists for the purpose of conducting certain network-wide activ
 
 With those things in consideration, if you are interested in helping with testing on the beta network we are excited to help you out - so keep reading!
 
-
 ## Node release testing
+
 The Nano Foundation maintains a few beta nodes on the network and various community members also setup nodes to help provide an environment more similar to the main network. During each development cycle Development Builds (DB) are prepared and shared in the Discord Beta Testing section of channels where early testing is coordinated. Once features are stabilized and included, release builds are published as Release Candidates (RC). Starting with RC1 and incrementing with each published build if needed (RC2, RC3, etc.). Final release of a version typically follows quickly once the RC is observed to be stable.
 
 !!! warning
@@ -31,14 +31,17 @@ ___
 ---
 
 ### Pulling the Docker image
+
 [![Docker Pulls](https://img.shields.io/docker/pulls/nanocurrency/nano.svg)](https://hub.docker.com/r/nanocurrency/nano-beta)
 
 Pulls the latest release of the Nano Node:
+
 ```bash
 docker pull nanocurrency/nano-beta
 ```
 
 Pulls a specific version of the Nano node:
+
 ```bash
 docker pull nanocurrency/nano-beta:<tag>
 ```
@@ -50,6 +53,7 @@ A list of beta tags can be found at the official [Nano Currency Docker Hub](http
 --8<-- "docker-run-command-beta.md"
 
 !!! tip
+
 	* For an explanation of the options included in the Docker `run` command, see [Starting the Container](/running-a-node/docker-management/#starting) details for the main network.
 	* See [Docker management](/running-a-node/docker-management/) for other related commands
 
@@ -74,6 +78,7 @@ A list of beta tags can be found at the official [Nano Currency Docker Hub](http
 <span id="release-candidate-builds"></span>
 <span id="development-builds"></span>
 <span id="latest-beta-builds"></span>
+
 ## Testing Builds
 
 Most of the resources needed to participate on the beta network can be found within the `#beta-xxxxxxx` channels on our [Discord server](https://chat.nano.org). As much of the discussion, planning and engagement happens here, all participants are highly encouraged to join there.
@@ -95,6 +100,9 @@ The following command will download and unzip a recent ledger snapshot. Any exis
 ```
 curl -O https://s3.us-east-2.amazonaws.com/beta-snapshot.nano.org/data.tar.gz; tar -xzvf data.tar.gz; rm -fr data.tar.gz
 ```
+
 <span id="ongoing-test-cases"></span>
+
 ### Build contents and test cases
+
 With each DB a GitHub Project board will be created in the [Nano GitHub Organization](https://github.com/orgs/nanocurrency/projects) containing all the Pull Requests newly added in the DB, changes from previous DBs that still need network testing, and issues with the various test cases that are targeted to be run with that build. For those looking to assist with these tests, we encourage connecting with the other beta network participants in the `#beta-net` channel on our [Discord server](https://chat.nano.org).
diff --git a/docs/running-a-node/configuration.md b/docs/running-a-node/configuration.md
index 939f6cba8..177f170b8 100644
--- a/docs/running-a-node/configuration.md
+++ b/docs/running-a-node/configuration.md
@@ -205,9 +205,11 @@ For backwards compatibility this is also supported in _v22_+
 As of _V20.0_ the sample TOML packaged with the binaries and available for [generation via the command line](#configuration-file-locations) are commented out with descriptions of each option. Where applicable the following integration areas have those options included along with additional context where necessary.
 
 ### Work generation
+
 See the [Work Generation guide](../integration-guides/work-generation.md#node-configuration).
 
 ### WebSockets
+
 See the [WebSockets Integration guide](../integration-guides/websockets.md#configuration).
 
 ### RPC
@@ -215,6 +217,7 @@ See the [WebSockets Integration guide](../integration-guides/websockets.md#confi
 --8<-- "config-node-option-rpc-enable-true.md"
 
 #### enable_control
+
 This configuration option is set in the [`config-rpc.toml`](../running-a-node/configuration.md#configuration-file-locations) file.
 
 Due to their sensitive or dangerous nature, certain RPC calls/options require this setting to be enabled before they can be used. Examples of RPC calls that require this include:
@@ -237,15 +240,19 @@ enable_control = false
 More advanced options for controlling the process the RPC server runs under can be found in the [Running Nano as a service guide](../integration-guides/advanced.md#running-nano-as-a-service).
 
 ### IPC
+
 See the [IPC Integration guide](../integration-guides/ipc-integration.md#configuration).
 
 ### Voting
+
 See the [Voting as a Representative guide](voting-as-a-representative.md).
 
 ### Ledger backends
+
 See the [Ledger Management guide](ledger-management.md).
 
 ### HTTPS support
+
 Support for TLS is deprecated from V27.
 Secure RPC/Websockets can be achieved by using a reverse proxy.
 
diff --git a/docs/running-a-node/docker-management.md b/docs/running-a-node/docker-management.md
index 990948768..546d9691c 100644
--- a/docs/running-a-node/docker-management.md
+++ b/docs/running-a-node/docker-management.md
@@ -113,6 +113,7 @@ docker stop ${NANO_NAME}
 Then we can download the [specific version](https://hub.docker.com/r/nanocurrency/nano/tags/) we need.
 
 Pull a version of the nano node
+
 ```bash
 docker pull nanocurrency/nano:V22.0
 ```
@@ -164,6 +165,7 @@ services:
 ### Docker entrypoint support
 
 As of v20.0, the docker entry script has migrated to a command with default arguments:
+
 ```
 Usage:
    /entry.sh nano_node [[--]daemon] [cli_options] [-l] [-v size]
@@ -184,6 +186,7 @@ Usage:
  default:
    /entry.sh nano_node daemon -l
 ```
+
 ---
 
 ### Docker USER Support
diff --git a/docs/running-a-node/ledger-management.md b/docs/running-a-node/ledger-management.md
index 3bd5b2a62..ec5d971cb 100644
--- a/docs/running-a-node/ledger-management.md
+++ b/docs/running-a-node/ledger-management.md
@@ -66,9 +66,11 @@ To avoid bootstrapping times, a [ledger file](#ledger-file) (`data.ldb`) can be
 Before using this method there are a few considerations to ensure it is done safely:
 
 ### Data source
+
 Make sure you trust the source providing the data to you. If you are unfamiliar with the individual or organization providing the ledger, consider other options for the data or fallback to the default of [bootstrapping](#bootstrapping) from the network.
 
 ### Validating blocks and voting weights
+
 Blocks are confirmed using the voting weight of representatives and these weights are determined by the account balances assigned to those representatives. In addition, the node releases contain a hard-coded set of representative weights captured at the time of the node release to help this process during bootstrapping.
 
 If looking to use a downloaded ledger there is a risk of it providing inaccurate representative voting weights. Although the potential impacts of this are minimal, below are some recommended steps to take which can help provide additional confidence the ledger can be used.
@@ -79,6 +81,7 @@ If looking to use a downloaded ledger there is a risk of it providing inaccurate
 If you need support with this process or need help in evaluating some of the CLI command results, join the [Node and Representative Management category](https://forum.nano.org/c/node-and-rep/8) on the [Nano Forums](https://forum.nano.org).
 
 ### Confirmation data
+
 Within each account on the ledger a confirmation height is set. This indicates the height of the last block on that chain where quorum was observed on the network. This is set locally by the node and a new ledger file may include this information with it. If the ledger is from a trusted source this confirmation data can be kept, which will save bandwidth and resources on the network by not querying for votes to verify these confirmations.
 
 If confirmation data for the ledger is not trusted the [--confirmation_height_clear](/commands/command-line-interface/#-confirmation_height_clear) CLI can be used to clear these out.
@@ -125,6 +128,7 @@ The node ledger currently uses LMDB (Lightning memory-mapped database) by defaul
 This document will not go into much detail about theses key-value data stores as there is a lot of information available online.
 
 ### Enable RocksDB
+
 This can be enabled by adding the following to the `config-node.toml` file:
 
 ```
@@ -133,13 +137,16 @@ enable = true
 ```
 
 The other options are:
+
 ```
 io_threads = 4
 memory_multiplier = 2
 ```
+
 It shouldn't be necessary to update these variables manually. See TOML comments in the generated file for more information on what these do.
 
 ### Migrating existing ledger from LMDB to RocksDB
+
 An existing LMDB ledger can be upgraded by running the [--migrate_database_lmdb_to_rocksdb](/commands/command-line-interface/#-migrate_database_lmdb_to_rocksdb) CLI command. This process can take some time, estimates range from 20 minutes to 1 hour depending on node hardware specs. There are some internal checks which are made to determine if the migration was successful, however it is recommended to run the node first (after [enabling RocksDB](#enable-rocksdb)) for a period of time to make sure things are working as expected. After which the `data.ldb` file can be deleted if no longer required to save on disk space. Please also note the [limitations](#rocksdb-limitations) most notably is that the `unchecked_count` from the `block_count` RPC will only be an estimate.
 
 Ledger backend comparison:
diff --git a/docs/running-a-node/logging-tracing.md b/docs/running-a-node/logging-tracing.md
index e95e7c8c5..519a4a73e 100644
--- a/docs/running-a-node/logging-tracing.md
+++ b/docs/running-a-node/logging-tracing.md
@@ -30,13 +30,13 @@ There are two ways to configure the logger:
 
 * The second is to use `NANO_LOG` and `NANO_LOG_LEVELS` **environment variables**. The environment variables take precedence over the configuration file.
 
-
 #### Config File (config-log.toml)
 
 During normal node operation, the configuration file is loaded from the data directory.
 When running test suites, the configuration is loaded from the current working directory.
 
 ##### Example config-log.toml
+
 ```
 [log]
 default_level = "info"
@@ -63,28 +63,29 @@ enable = true
 
 The full list of `log_types` can be found [here](https://github.com/nanocurrency/nano-node/blob/develop/nano/lib/logging_enums.hpp#L24-L95)
 
-
 #### Environment Variables
 
 Environment variables override the configuration file. This is useful when running test suites.
 
 ##### Set default log level
+
 ```
 NANO_LOG = [trace|debug|info|warn|error|critical|off]
 ```
 
 ##### Set log level for individual loggers
+
 ```
 NANO_LOG_LEVELS = log_type_1=level_1[,log_type_2=level_2,...]
 ```
 
 Example:
+
 ```
 export NANO_LOG=warn
 export NANO_LOG_LEVELS=active_transactions=debug,bootstrap=debug
 ```
 
-
 ### Unit Tests
 
 By default, the logger is disabled when running unit tests to keep the output clean.  To enable it, set the `NANO_LOG` environment variable to a desired log level.
@@ -92,48 +93,52 @@ Alternatively a configuration file inside the current working directory will be
 
 In test suite mode, each log line additionally contains the identifier of the node that produced the log line (first 10 characters of its node ID). This makes it easier to follow the flow of events and will become much more useful once full tracing is implemented.
 
-
 ### Tracing
 
 The goal of tracing is to introduce a framework for tracing events in the node. This is meant to be used for debugging and profiling purposes, e.g., by visualizing the flow of votes through the network or analyzing the delay between receiving a block and confirming it.
 
 #### Tracing Usage
+
 To use tracing, it must be enabled **at compile time** by passing the `-DNANO_TRACING=ON` flag to CMake. By default, it is disabled for release builds and enabled for debug builds.
 
 After that, tracing can be enabled by setting the logging verbosity level to `trace`:
+
 ```
 NANO_LOG=trace
 ```
 
 Since the amount of logs when setting the logging level to `trace` is very large, it is recommended to use the trace level only for specific components. This can be done by setting the `NANO_LOG_LEVELS` environment variable to a comma-separated list of components to trace. For example, to trace only `active_transactions` and `vote_processor`, set:
+
 ```
 NANO_LOG_LEVELS="active_transactions=trace,vote_processor=trace"
 ```
 
 Alternatively, this can also be done by modifying the `config-log.toml` file.
 
-
 ### Tracing Formats
 
 It is possible to specify the format of tracing output at runtime. This is done by setting the `NANO_TRACE_FORMAT` environment variable to one of the following: `standard` or `json`.
 
 #### Standard Tracing
+
 Standard tracing is enabled by default. It is a simple key: { value } format with indentation that should be easy to read.
 
 #### JSON Tracing
+
 JSON tracing is meant to be parsed by external tools. There is no indentation or newlines, so each log output line can be treated as a separate event, which simplifies parsing.
 
 ##### Sample JSON Tracing output:
+
 ```
 [2024-01-30 17:56:53.312] [vote_processor::vote_processed] [trace] "event":"vote_processor::vote_processed","time":1706633813312751,"vote":{"account":"FD16B0FE0102F68C2D9482348AE7211E3CBF86681364E53D8793A5E551167A6C","final":true,"timestamp":18446744073709551615,"hashes":["7DEF4D1F5EB222BC5DE2123293EE5A8CE58E283176AB65DF3373DA009FD99E86"]},"result":"indeterminate"
 ```
 
-
 ### Stats Logging
 
 This allows logging individual stat counter increments. This is useful for debugging tests. This functionality can be enabled by setting the `NANO_LOG_STATS=[1,true,on]` environment variable.
 
 #### Example output:
+
 ```
 [2024-05-02 18:43:27.939] [node_16gzg] [stats] [debug] Stat: bootstrap_server::request::in += 1
 [2024-05-02 18:43:27.939] [node_16gzg] [stats] [debug] Stat: bootstrap_server_request::blocks::in += 1
@@ -142,8 +147,6 @@ This allows logging individual stat counter increments. This is useful for debug
 [2024-05-02 18:43:27.939] [node_3e5x4] [stats] [debug] Sample: bootstrap_tag_duration -> 1
 ```
 
-
-
 ## Overview - V26 and prior
 
 V26 and prior version use a different method to enable logs.
@@ -169,8 +172,8 @@ To generate a config file with all logging options, run `nano_node --generate_co
 
 By default this option is set to `false` which results in all log files having a timestamp appended to them, even the currently active file. If set to `true` the currently active log file will have a static name at `log/node.log` for easier management.
 
-
 #### logging.log_rpc
+
 This configuration option is set in the [`config-rpc.toml`](../running-a-node/configuration.md#configuration-file-locations) file.
 
 By default, all RPC calls and the time spent handling each one are [logged](../running-a-node/troubleshooting.md#log-files). This can be optionally turned off by switching option `logging.log_rpc` to `false`
diff --git a/docs/running-a-node/node-setup.md b/docs/running-a-node/node-setup.md
index 09d03f290..28deee9e2 100644
--- a/docs/running-a-node/node-setup.md
+++ b/docs/running-a-node/node-setup.md
@@ -117,7 +117,6 @@ The following command will start the node container. Either set the specified en
 
 `${NANO_HOST_DIR}` - Location on the host computer where the ledger, configuration files, and logs will be stored. The Docker container will directly store files such as `config-node.toml`, `config-rpc.toml` and `data.ldb` into this directory.
 
-
 === "Test network"
 
 	--8<-- "docker-run-command-test.md"
@@ -143,43 +142,51 @@ When the node starts up it will generate log files in the `${NANO_HOST_DIR}` def
 ```
 Node starting, version: V25.1
 ```
+
 :exclamation: Verify you are running the correct version  
 Appears at each startup to indicate version number
 
 ```
 Build information: d91016b "Clang version " "12.0.0 (clang-1200.0.32.29)" "BOOST 107000" BUILT "Jun 21 2021"
 ```
+
 Various build information starting with the abbreviated git hash of latest commit, Clang and BOOST version information and build date.
 
 ```
 Database backend: LMDB 0.9.25
 ```
+
 Database used for the backend - default LMDB but [RocksDB](ledger-management.md#rocksdb-ledger-backend) can also be configured.
 
 ```
 Active network: test
 ```
+
 :exclamation: Verify you are running on the correct network  
 Indicates which of the three network (test, main, beta) the node is running on.
 
 ```
 Work pool running 12 threads 
 ```
+
 Number of threads available for generating Proof of Work.
 
 ```
 0 work peers configured
 ```
+
 Work peers setup in the `config-node.toml` file, option `node.work_peers`. This is not required if doing local work generation, but is encouraged if planning to do large transaction volumes. See the [work generation integration guide](../integration-guides/work-generation.md) for further details.
 
 ```
 Outbound Voting Bandwidth limited to 10485760 bytes per second, burst ratio 3
 ```
+
 Bandwidth limit set in the `config-node.toml` file, options `node.bandwidth_limit` and `node.bandwidth_limit_burst_ratio`.
 
 ```
 Node ID: node_1gh7ghwwquxp9kw7r3p5634p3n8goyf49a3xyzcnbykxge44gjjonmhexd6h
 ```
+
 Ephemeral and unique node ID created on each startup and only used for network communications with other nodes. This is not a valid nano address (notice prefix of `node_`).
 
 ```
@@ -187,6 +194,7 @@ Starting legacy bootstrap attempt with ID auto_bootstrap_0
 ...
 Exiting legacy bootstrap attempt with ID auto_bootstrap_0
 ```
+
 Indicates attempts at starting [bootstrap](ledger-management.md#bootstrapping) activities from other nodes on the network.
 
 ```
@@ -195,16 +203,19 @@ UPNP_GetSpecificPortMappingEntry failed 714: NoSuchEntryInArray
 UPnP leasing time getting old, remaining time: 0, lease time: 1787, below the threshold: 893
 UPnP TCP 24.17.20.184:17075 mapped to 17075
 ```
+
 Details of UPnP attempts at mapping ports. See [UPnP troubleshooting](troubleshooting.md#troubleshooting-upnp) for further details.
 
 ```
 Found a representative at [::ffff:168.119.169.220]:17075
 ```
+
 Indicates the IP address of a new representative discovered on the network.
 
 ```
 Wallet unlocked
 ```
+
 Certain activities performed by the node, including signing votes, requires unlocking the wallet during operation.
 
 The above examples are subset of potential entries in logging.
@@ -226,6 +237,7 @@ Once the node is up and running you can query via RPC. Below is a basic command
 	```
 
 	**Response**
+
 	```json
 	{
 	    "count": "16599",
@@ -297,6 +309,7 @@ The fastest way compare is using the ['telemetry' RPC](../commands/rpc-protocol.
 	```
 
 	**Response**
+
 	```json
 	{
 	    "block_count": "16599",
@@ -329,6 +342,7 @@ The fastest way compare is using the ['telemetry' RPC](../commands/rpc-protocol.
 	```
 
 	**Response**
+
 	```json
 	{
 	    "block_count": "122270697",
@@ -361,6 +375,7 @@ The fastest way compare is using the ['telemetry' RPC](../commands/rpc-protocol.
 	```
 
 	**Response**
+
 	```json
 	{
 	    "block_count": "48983527",
@@ -403,4 +418,3 @@ Below are resources to help you take the next step to use your node to interact
 - Update your [node configuration options](configuration.md) to enable various features
 - Start [voting as a representative](voting-as-a-representative.md)
 - Find out how to best [manage your ledger file](ledger-management.md)
-
diff --git a/docs/running-a-node/overview.md b/docs/running-a-node/overview.md
index e7e8dc45b..1f8af4332 100644
--- a/docs/running-a-node/overview.md
+++ b/docs/running-a-node/overview.md
@@ -6,6 +6,7 @@ description: Understand the purpose for running a nano node, the different types
 Running a node is a key way to help decentralize the network and provide a network access point for systems built on top of nano. Before setting up a node we recommend reviewing the following details in order to understand more about the motivations for running, required upkeep, types and recommended specifications for nodes.
 
 ## Why run a node?
+
 By design, the incentives for running a nano node are not built into the network itself, but instead are external. This is an important difference compared to nearly all other cryptocurrency networks and allows nano to operate securely without transaction fees.[^1][^2] These indirect, external incentives include the following and more:
 
 * Advertising exposure from their representative showing up on curated representative lists
@@ -23,21 +24,25 @@ Regardless of the motivation for running a node, it will only benefit the networ
 	Regardless of the type of node you are planning to run, make sure to review the [Node security guide](security.md) to ensure best practice with configuration, firewalls and more.
 
 ### Non-voting nodes
+
 When first setting up a node it will not be configured to participate in consensus by voting on traffic. This type of node is common and is recommended for all integrations. If your goal in setting up a node is to learn how to integrate and use nano for payments, this is the best starting point. If you want to dedicate resources to help secure consensus on the network, then a Representative node should be explored.
 
 !!! info "Representatives and voting"
 	For a very brief overview of how representatives and voting works in the nano network, see the [What is nano? page](../what-is-nano/overview.md#representatives-and-voting). If you're looking to dig deeper, the [ORV consensus section of the living whitepaper](../protocol-design/orv-consensus.md) helps explain further how consensus works.
 
 ### Representative nodes
+
 If a node is setup with a Representative account, is configured to vote and has **less than 0.1% of [online voting weight](/glossary#online-voting-weight)** delegated to them, they are a considered Representative node. These nodes will validate and vote on transactions seen on the network. Their votes will be directly sent to a subset of their peers, but other nodes on the network will not rebroadcast their votes.
 
 ### Principal Representative nodes
+
 Representative nodes with **at least 0.1% of the [online voting weight](/glossary#online-voting-weight)** delegated to them participate more broadly in network consensus because votes they send to their peers are then rebroadcasted by those nodes as well. These "PR" nodes have the most impact to the security and availability of the network so [keeping them secure](security.md) and following [maintenance recommendations](#maintenance) should be taken seriously.
 
 !!! success "Becoming a Principal Representative"
 	With the ability for any user on the network to redelegate their voting weight, even an account with no weight today can become a Principal Representative over time.
 
 ## Hardware recommendations
+
 <span id="resources-and-ongoing-maintenance"></span>
 Nodes consume CPU, RAM, disk IO and bandwidth IO resources, all of which come at a cost. In order to keep the node participating and in-sync, the recommended specifications for machines based on node type below should be followed.
 
diff --git a/docs/running-a-node/test-network.md b/docs/running-a-node/test-network.md
index 8849c37b1..3669b895b 100644
--- a/docs/running-a-node/test-network.md
+++ b/docs/running-a-node/test-network.md
@@ -23,26 +23,26 @@ ___
 
 ---
 
-
 ### Binaries
 
 In addition to the Docker details above, the latest binary builds of the node for the test network can be found below. These will only change when Release Candidates (RC) builds are ready, or when final releases are done. However, the first build available today is actually a development build since the changes to enable this network were recently introduced.
 
 --8<-- "current-build-links-test.md"
 
-
 If manual builds are needed, see the [build options](../integration-guides/build-options.md) page for details.
 
-
 ### Pulling the Docker image
+
 [![Docker Pulls](https://img.shields.io/docker/pulls/nanocurrency/nano.svg)](https://hub.docker.com/r/nanocurrency/nano-test)
 
 Pulls the latest test release of the nano Node:
+
 ```bash
 docker pull nanocurrency/nano-test
 ```
 
 Pulls a specific test version of the nano node:
+
 ```bash
 docker pull nanocurrency/nano-test:<tag>
 ```
@@ -54,6 +54,7 @@ A list of test tags can be found at the official [Nano Currency Docker Hub](http
 --8<-- "docker-run-command-test.md"
 
 !!! tip
+
 	* For an explanation of the options included in the Docker `run` command, see [Starting the Container](/running-a-node/docker-management/#starting) details for the main network.
 	* See [Docker management](/running-a-node/docker-management/) for other related commands
 
diff --git a/docs/running-a-node/troubleshooting.md b/docs/running-a-node/troubleshooting.md
index fb8635eaa..95172760e 100644
--- a/docs/running-a-node/troubleshooting.md
+++ b/docs/running-a-node/troubleshooting.md
@@ -27,7 +27,6 @@ If the node crashes, the most commonly seen message is "Segmentation fault (core
 
 When you are done gathering all information, please [create a new Github issue](https://github.com/nanocurrency/nano-node/issues/new), or [reach us on Discord](https://chat.nano.org) in the *#support* channel, detailing your issue as much as possible.
 
-
 !!! note "Getting the latest node log"
     The following command will order the log files such that the first one in the output is the most recent. If you restarted the node since the crash, then the relevant log file is not the latest one. Please be careful to give us the relevant log file.
 
@@ -39,6 +38,7 @@ When you are done gathering all information, please [create a new Github issue](
     Please provide the complete log file.
 
 Please follow the steps below for the corresponding node version you are using. Should there be an error obtaining the information in a newer version, the older version steps should then be attempted.
+
 #### _v21_+ nodes
 
 !!! example "Step 1: Make sure addr2line is installed"
@@ -69,6 +69,7 @@ Please follow the steps below for the corresponding node version you are using.
     ```
 
     Example output:
+
     ```
     [    6.336071] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
     [    6.375123] wlp2s0: Limiting TX power to 23 (23 - 0) dBm as advertised by **:**:**:**:**:**
@@ -87,6 +88,7 @@ Please follow the steps below for the corresponding node version you are using.
     ```
 
     Example output:
+
     ```
     Aug 15 11:56:07 ubuntu-server kernel: [6141.711993] show_signal_msg: 23 callbacks suppressed
     Aug 15 11:56:07 ubuntu-server kernel: [6141.711995] I/O[25975]: segfault at 1 ip 000055b2960e2d24 sp 00007fcff50f6fc0 error 6 in nano_node[55b295f9b000+6d8000]
@@ -99,11 +101,13 @@ Please follow the steps below for the corresponding node version you are using.
     This command will produce some basic information about the error.
 
     **Not using docker**:
+
     ```bash
     ./nano_node --debug_output_last_backtrace_dump > nano_node_backtrace_output.txt
     ```
 
     **Using docker**:
+
     ```bash
     mkdir -p /tmp/nano_node_crash && cd $_
     docker exec ${NANO_NAME} nano_node --debug_output_last_backtrace_dump > nano_node_backtrace_output.txt
@@ -113,6 +117,7 @@ Please follow the steps below for the corresponding node version you are using.
 
 !!! example "Step 4: Producing the archive file"
     See the output of this command for the name of the file you should include in your report.
+
     ```bash
     FILE="nano_node_crash_$(date +"%Y-%m-%d_%H-%M-%S.tar.gz")" && tar czf $FILE --exclude=*.tar.gz nano_node_* && echo "Created archive $FILE"
     ```
@@ -682,6 +687,7 @@ dir (direction) :
     "type": "samples"
 }
 ```
+
 #### Samples response
 
 ```json
@@ -825,7 +831,9 @@ samples,2018.03.29 01:45:41
 ## Troubleshooting UPnP
 
 ### Ensure UPnP is enabled
+
 UPnP will be enabled unless the external port is set in either the config
+
 ```toml
 [node]
 ...
@@ -833,12 +841,15 @@ UPnP will be enabled unless the external port is set in either the config
 # type:string,ip
 external_address = "::ffff:<some_public_ipv4>"
 ```
+
 or via cli flag
+
 ```bash
 --config node.external_address="::ffff:<some_public_ipv4>"
 ```
 
 ### Enable UPnP logging
+
 Appending this to your launch command will enable upnp debug logging.
 
 ```bash
@@ -850,11 +861,14 @@ Appending this to your launch command will enable upnp debug logging.
 # V26 or before
 --config node.logging.upnp_details=true
 ```
+
 ### Error UPnP Messages
+
 Check the beginning of the logs for UPNP_* messages
 
 !!! error "Port Mapping Conflict"
     Check for static routes
+
     ```bash
     [2019-Oct-29 11:06:56.641389]: UPnP failed 718: ConflictInMappingEntry
     [2019-Oct-29 11:06:56.644387]: UPnP failed 718: ConflictInMappingEntry
@@ -863,10 +877,12 @@ Check the beginning of the logs for UPNP_* messages
 ### Normal UPnP Messages
 
 !!! note ""
+
     ```bash
     [2019-Oct-29 11:06:56.641389]: UPNP_GetSpecificPortMappingEntry failed 714: NoSuchEntryInArray
     [2019-Oct-29 11:06:56.644387]: UPNP_GetSpecificPortMappingEntry failed 714: NoSuchEntryInArray
     ```
+
     This message is expected when starting the node and will go away after the UPnP has mappeded the port
 
 ---
diff --git a/docs/running-a-node/voting-as-a-representative.md b/docs/running-a-node/voting-as-a-representative.md
index 148d71884..cb47a2bd8 100644
--- a/docs/running-a-node/voting-as-a-representative.md
+++ b/docs/running-a-node/voting-as-a-representative.md
@@ -10,6 +10,7 @@ The default [node setup](node-setup.md) guide provides instructions for getting
 Before getting into the setup instructions, there are a few important considerations:
 
 ## Commitment, security and maintenance
+
 Running a Nano Representative is a commitment to helping secure the network. This can only be done if the operation of the node is taken seriously.
 
 * Prepare for the necessary [maintenance](overview.md#maintenance) on the node and host machine
@@ -21,11 +22,13 @@ Running a Nano Representative is a commitment to helping secure the network. Thi
 --8<-- "hardware-recommendations.md"
 
 ## Synced ledger
+
 In order to open a new account to become a representative, the local node ledger must be in sync with the rest of the network. If you are starting a fresh node and bootstrapping, this process can take days to complete, depending on the network conditions, hardware specifications, etc. To speed this up, a [downloaded ledger](ledger-management.md#downloaded-ledger-files) can be used if necessary.
 
 ---
 
 ## Step 1: Enable voting
+
 For the node to start voting, the following [configuration](configuration.md) options need to be updated:
 
 --8<-- "config-node-option-node-enable-voting-true.md"
@@ -48,7 +51,6 @@ Add a representative account to a wallet:
     - [account_create](../commands/rpc-protocol.md#account_create) RPC if you had a seed or are creating a new representative account
 1. Verify the account is in the wallet with [account_list](../commands/rpc-protocol.md#account_list)
 
-
 Open the account - until you do [account_info](../commands/rpc-protocol.md#account_info) and others will fail:
 
 1. Send some funds to the account, at least 0.01 Nano
diff --git a/docs/running-a-node/wallet-setup.md b/docs/running-a-node/wallet-setup.md
index c588f5616..0948e0b0f 100644
--- a/docs/running-a-node/wallet-setup.md
+++ b/docs/running-a-node/wallet-setup.md
@@ -47,6 +47,7 @@ After this configuration change you can create a wallet using the ['wallet_creat
 
 === "Test network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "wallet_create"
@@ -55,6 +56,7 @@ After this configuration change you can create a wallet using the ['wallet_creat
 
 === "Main network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "wallet_create"
@@ -63,12 +65,15 @@ After this configuration change you can create a wallet using the ['wallet_creat
 
 === "Beta network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "wallet_create"
 	}' http://127.0.0.1:55000
 	```
+
 **Response**
+
 ```json
 { 
   "wallet": "E3E67B1B3FFA46F606240F1D0B964873D42E9C6D0B7A0BF376A2E128541CC446"
@@ -85,15 +90,20 @@ Note that the seed generated in the wallet isn't returned in the RPC response. T
 
 === "Docker"
 	**Request**
+
 	```bash
 	docker exec ${NANO_CONTAINER_NAME} nano_node --wallet_decrypt_unsafe --wallet E3E67B1B3FFA46F606240F1D0B964873D42E9C6D0B7A0BF376A2E128541CC446
 	```
+
 === "Other builds"
 	**Request**
+
 	```bash
 	/path/to/nano_node --wallet_decrypt_unsafe --wallet E3E67B1B3FFA46F606240F1D0B964873D42E9C6D0B7A0BF376A2E128541CC446
 	```
+
 **Response**
+
 ```bash
 Seed: A7EA09F17C914AE8BA1B7FD1747DB8942DF551C271A7085187B8A20C21898CC6
 ```
@@ -105,6 +115,7 @@ If you would like to replace the wallet's automatically generated seed with your
 
     === "Test network"
       **Request**
+
       ```bash
       curl -d '{
           "action": "wallet_change_seed",
@@ -112,8 +123,10 @@ If you would like to replace the wallet's automatically generated seed with your
           "seed": "A7EA09F17C914AE8BA1B7FD1747DB8942DF551C271A7085187B8A20C21898CC6" 
       }' http://127.0.0.1:17076
       ```
+
 	=== "Main network"
       **Request**
+
       ```bash
       curl -d '{
           "action": "wallet_change_seed",
@@ -121,8 +134,10 @@ If you would like to replace the wallet's automatically generated seed with your
           "seed": "A7EA09F17C914AE8BA1B7FD1747DB8942DF551C271A7085187B8A20C21898CC6" 
       }' http://127.0.0.1:7076
       ```
+
     === "Beta network"
       **Request**
+
       ```bash
       curl -d '{
           "action": "wallet_change_seed",
@@ -139,9 +154,9 @@ It is a best practice to set the wallet password for additional security. Use th
 
 By default a newly created wallet with a seed will not have any accounts in it, but they are easy to add by simply calling the ['account_create' RPC](../commands/rpc-protocol.md#account-create). By default this will derive the private key for index `0` first from the seed and return the related public address. See the [seed](../integration-guides/the-basics.md#seed) section for more information about private key derivation.
 
-
 === "Test network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "account_create",
@@ -151,6 +166,7 @@ By default a newly created wallet with a seed will not have any accounts in it,
 
 === "Main network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "account_create",
@@ -160,24 +176,27 @@ By default a newly created wallet with a seed will not have any accounts in it,
 
 === "Beta network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "account_create",
 	  "wallet": "E3E67B1B3FFA46F606240F1D0B964873D42E9C6D0B7A0BF376A2E128541CC446"
 	}' http://127.0.0.1:55000
 	```
+
 **Response**
+
 ```json
 {
     "account": "nano_3z3ntcdh5st3mtsogwip7kys1mgp6febnk3pwtex7acggykdkc9kexj4j87b"
 }
 ```
 
-
 If the optional `index` parameter is included the private key for that specific index will be added. Any subsequent calls to ['account_create' RPC](../commands/rpc-protocol.md#account-create) without the `index` parameter will return to incrementing one from the lowest derived index above 0. Test out the command by generating a few accounts and then using the [`account_list` RPC](../commands/rpc-protocol.md#account_list) to see them all.
 
 === "Test network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "account_list",
@@ -187,6 +206,7 @@ If the optional `index` parameter is included the private key for that specific
 
 === "Main network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "account_list",
@@ -196,13 +216,16 @@ If the optional `index` parameter is included the private key for that specific
 
 === "Beta network"
 	**Request**
+
 	```bash
 	curl -d '{
 	  "action": "account_list",
 	  "wallet": "E3E67B1B3FFA46F606240F1D0B964873D42E9C6D0B7A0BF376A2E128541CC446"
 	}' http://127.0.0.1:55000
 	```
+
 **Response**
+
 ```json
 {
     "accounts": [
diff --git a/docs/snippets/config-node-option-node-enable-voting-true.md b/docs/snippets/config-node-option-node-enable-voting-true.md
index a199c99dc..6be146d7d 100644
--- a/docs/snippets/config-node-option-node-enable-voting-true.md
+++ b/docs/snippets/config-node-option-node-enable-voting-true.md
@@ -1,4 +1,5 @@
 #### node.enable_voting
+
 Newly setup nodes have voting disabled by default. In order to participate in network consensus, this value must be updated in the [`config-node.toml`](../running-a-node/configuration.md#configuration-file-locations) file.
 
 ```toml
diff --git a/docs/snippets/config-node-option-rpc-enable-true.md b/docs/snippets/config-node-option-rpc-enable-true.md
index 08a76994f..c757c231f 100644
--- a/docs/snippets/config-node-option-rpc-enable-true.md
+++ b/docs/snippets/config-node-option-rpc-enable-true.md
@@ -1,4 +1,5 @@
 #### rpc.enable
+
 To enable communication via RPC, set this configuration option in the [`config-node.toml`](../running-a-node/configuration.md#configuration-file-locations) file.
 
 ```toml
diff --git a/docs/snippets/hardware-recommendations.md b/docs/snippets/hardware-recommendations.md
index 80635954c..aee8183a4 100644
--- a/docs/snippets/hardware-recommendations.md
+++ b/docs/snippets/hardware-recommendations.md
@@ -1,4 +1,5 @@
 ### Principal Representative Nodes
+
 The following are minimum recommended specifications for nodes with more than 0.1% of the online voting weight ([Principal Representatives](../glossary.md#principal-representative)):
 
 * 16GB RAM
@@ -7,6 +8,7 @@ The following are minimum recommended specifications for nodes with more than 0.
 * SSD-based hard drive with 400GB+ of free space
 
 ### Non-voting and Representative Nodes
+
 The following are minimum recommended specifications for non-voting nodes and Representative nodes with less than 0.1% of the online voting weight (regular [Representatives](../glossary.md#representative)):
 
 * 8GB RAM
diff --git a/docs/snippets/known-issue-macos-too-many-open-files.md b/docs/snippets/known-issue-macos-too-many-open-files.md
index 62903c276..e6ca0e064 100644
--- a/docs/snippets/known-issue-macos-too-many-open-files.md
+++ b/docs/snippets/known-issue-macos-too-many-open-files.md
@@ -3,6 +3,3 @@
     * **Issue:** The following error, or a similar one, can be seen when attempting to run a full node on some versions of macOS, Linux and possibly other operating systems. This is most common when using the built-in Qt wallet or other GUI-based wallets: "Exception while running wallet: open: Too many open files" or other errors containing "Too many open files". This is due to some systems having a very low default file descriptor limit and V19.0+ uses more of them after the move to TCP.
     
     * **Solution:** Increasing the file limits is needed to resolve this. See [this known issue](../integration-guides/advanced.md#known-issues) for more details on resolution.
-
-
-
diff --git a/docs/snippets/release-details-v22-1.md b/docs/snippets/release-details-v22-1.md
index f214f0256..c3f2f9b1b 100644
--- a/docs/snippets/release-details-v22-1.md
+++ b/docs/snippets/release-details-v22-1.md
@@ -1,4 +1,3 @@
 | Node | Protocol | Database | Release Date | Release Notes | GitHub Links | 
 |      |          |          |              | 				|			   |
-| 22.1 | 18       | 21       | 2021-06-11          | [V22.1](../releases/release-v22-1.md) | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V22.1) - [Milestone](https://github.com/nanocurrency/nano-node/milestone/24) - [Changelog](https://github.com/nanocurrency/nano-node/compare/853398af...ade6f224) | 
-
+| 22.1 | 18       | 21       | 2021-06-11          | [V22.1](../releases/release-v22-1.md) | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V22.1) - [Milestone](https://github.com/nanocurrency/nano-node/milestone/24) - [Changelog](https://github.com/nanocurrency/nano-node/compare/853398af...ade6f224) |
diff --git a/docs/snippets/release-details-v23-1.md b/docs/snippets/release-details-v23-1.md
index b4ba665ff..335890dcb 100644
--- a/docs/snippets/release-details-v23-1.md
+++ b/docs/snippets/release-details-v23-1.md
@@ -1,4 +1,3 @@
 | Node | Protocol | Database | Release Date | Release Notes | GitHub Links | 
 |      |          |          |              | 				|			   |
-| 23.1 | 18       | 21       | 2022-05-19   | [V23.1](../releases/release-v23-1.md) | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V23.1) - [Milestone](https://github.com/nanocurrency/nano-node/milestone/26) - [Changelog](https://github.com/nanocurrency/nano-node/compare/a7a44f9e8a23672f66e15804e79560f004995859...fef94e3601410542a971f945b0f8c238829c3c96) | 
-
+| 23.1 | 18       | 21       | 2022-05-19   | [V23.1](../releases/release-v23-1.md) | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V23.1) - [Milestone](https://github.com/nanocurrency/nano-node/milestone/26) - [Changelog](https://github.com/nanocurrency/nano-node/compare/a7a44f9e8a23672f66e15804e79560f004995859...fef94e3601410542a971f945b0f8c238829c3c96) |
diff --git a/docs/snippets/release-details-v23-3.md b/docs/snippets/release-details-v23-3.md
index 0cefeba9b..e9d39fcaa 100644
--- a/docs/snippets/release-details-v23-3.md
+++ b/docs/snippets/release-details-v23-3.md
@@ -1,4 +1,3 @@
 | Node | Protocol | Database | Release Date | Release Notes | GitHub Links | 
 |      |          |          |              | 				|			   |
-| 23.3 | 18       | 21       | 2022-06-13   | [V23.3](../releases/release-v23-3.md) | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V23.3) - [Changelog](https://github.com/nanocurrency/nano-node/compare/fef94e3601410542a971f945b0f8c238829c3c96...33422f46e3fb46c3086278e2bdc411220133f3e2) | 
-
+| 23.3 | 18       | 21       | 2022-06-13   | [V23.3](../releases/release-v23-3.md) | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V23.3) - [Changelog](https://github.com/nanocurrency/nano-node/compare/fef94e3601410542a971f945b0f8c238829c3c96...33422f46e3fb46c3086278e2bdc411220133f3e2) |
diff --git a/docs/snippets/release-details-v26-1.md b/docs/snippets/release-details-v26-1.md
index fad4c8170..974f787d8 100644
--- a/docs/snippets/release-details-v26-1.md
+++ b/docs/snippets/release-details-v26-1.md
@@ -1,3 +1,3 @@
 | Node | Protocol | Database | Release Date | Release Notes | GitHub Links | 
 |      |          |          |              |               |              |
-| 26.1 | 20       | 22       | 2024-02-26   | [V26.1](../releases/release-v26-1.md)         | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V26.1) - Milestone - [Changelog](https://github.com/nanocurrency/nano-node/compare/bbbfe92cffe6ba861085c7eb3d21193bc141aaba...66d74ffd86b4beea3c8df3b918e4f1e8e31f2800) | 
+| 26.1 | 20       | 22       | 2024-02-26   | [V26.1](../releases/release-v26-1.md)         | [Release](https://github.com/nanocurrency/nano-node/releases/tag/V26.1) - Milestone - [Changelog](https://github.com/nanocurrency/nano-node/compare/bbbfe92cffe6ba861085c7eb3d21193bc141aaba...66d74ffd86b4beea3c8df3b918e4f1e8e31f2800) |
diff --git a/docs/snippets/unconfirmed-information.md b/docs/snippets/unconfirmed-information.md
index 8e5145231..4b0930753 100644
--- a/docs/snippets/unconfirmed-information.md
+++ b/docs/snippets/unconfirmed-information.md
@@ -1,2 +1,2 @@
 !!! info "Unconfirmed information"
-	This call returns information that may be based on unconfirmed blocks. These details should not be relied on for any process or integration that requires confirmed blocks.  
\ No newline at end of file
+	This call returns information that may be based on unconfirmed blocks. These details should not be relied on for any process or integration that requires confirmed blocks.
\ No newline at end of file
diff --git a/docs/snippets/warning-only-official-builds-supported.md b/docs/snippets/warning-only-official-builds-supported.md
index ec28f622b..13f8911d4 100644
--- a/docs/snippets/warning-only-official-builds-supported.md
+++ b/docs/snippets/warning-only-official-builds-supported.md
@@ -1,4 +1,5 @@
 !!! warning "Only Official Builds Supported"
+
 	* The fastest and most recommended method of installation is through [Docker management](/running-a-node/node-setup)
 	* Only [official release builds](/integration-guides/build-options#official-release-builds) are recommended and supported for use on the main network
 	* Builds created from git should be done using the available release tags (`V21.2` etc.)
diff --git a/docs/snippets/warning-unsupported-configuration.md b/docs/snippets/warning-unsupported-configuration.md
index 5b0ecdcc7..cce1224c4 100644
--- a/docs/snippets/warning-unsupported-configuration.md
+++ b/docs/snippets/warning-unsupported-configuration.md
@@ -1,4 +1,5 @@
 !!! warning "Unsupported configuration"
+
 	* This documentation is intended only for developers of the Nano Node software, and will not result in a supported configuration.  End-users are advised to use releases.
 	* The fastest and most recommended method of installation is through [Docker](/running-a-node/node-setup).
 	* [Running node as a service](/integration-guides/advanced/#running-nano-as-a-service).
diff --git a/docs/what-is-nano/overview.md b/docs/what-is-nano/overview.md
index 961fb387a..620e061ed 100644
--- a/docs/what-is-nano/overview.md
+++ b/docs/what-is-nano/overview.md
@@ -2,8 +2,10 @@
 title: What is nano?
 description: A broad introduction to nano - the instant, fee-less and eco-friendly digital money available across the world
 hide:
+
   - navigation
   - toc
+
 ---
 
 # What is nano?
@@ -30,6 +32,7 @@ Every block must also contain a small, user-generated [Proof-of-Work](/glossary#
 For more details, see the [Blocks](/integration-guides/the-basics/#blocks-specifications) and [Proof-of-Work specifications](/integration-guides/the-basics/#proof-of-work) in our [Integration Guides](/integration-guides/the-basics/).
 
 ### Representatives and Voting
+
 Nano has a unique consensus mechanism called [Open Representative Voting (ORV)](/glossary/#open-representative-voting-orv). Every account can freely choose a [Representative](/glossary#representative) at any time to vote on their behalf, even when the delegating account itself is offline. These Representative accounts are configured on nodes that remain online and vote on the validity of transactions they see on the network. Their voting weight is the sum of balances for accounts delegating to them, and if they have enough voting weight they become a [Principal Representative](/glossary/#principal-representative). The votes these Principal Representatives send out will subsequently be rebroadcasted by other nodes.
 
 As these votes are shared and rebroadcasted between nodes, they are tallied up and compared against the online voting weight available. Once a node sees a block get enough votes to reach [quorum](/glossary/#quorum), that block is confirmed. Due to the lightweight nature of blocks and votes, the network is able to reach confirmation for transaction ultrafast, often in under a couple seconds. Also note that delegation of voting weight does not mean staking of any funds - the account delegating can still spend all their available funds at any time without restrictions.
@@ -37,6 +40,7 @@ As these votes are shared and rebroadcasted between nodes, they are tallied up a
 Because Nano accounts can freely delegate their voting weight to representatives at any time, the users have more control over who has power with consensus and how decentralized the network is. This is a key advantage to the design of [Open Representative Voting (ORV)](/glossary/#open-representative-voting-orv). With no direct monetary incentive for nodes, this removes emergent centralization forces for longer-term trending toward decentralization of the network.[^1]
 
 ### Design Advantages
+
 Nano was designed with new data structures, consensus mechanisms and other features to gain some key advantages over competing digital currencies:
 
 * Minimal block size allows for lightweight communication resulting in ultrafast transaction confirmation times
diff --git a/docs/whitepaper/english.md b/docs/whitepaper/english.md
index fc9afc91b..d2a1c53b5 100644
--- a/docs/whitepaper/english.md
+++ b/docs/whitepaper/english.md
@@ -386,6 +386,7 @@ change {
    signature: 83B0...006433265C7B204
 }
 ```
+
 ### Forks and Voting
 
 A fork occurs when $j$ signed blocks $b_1, b_2, \dots, b_j$ claim the
diff --git a/scripts/format_markdown.py b/scripts/format_markdown.py
new file mode 100755
index 000000000..068aab78e
--- /dev/null
+++ b/scripts/format_markdown.py
@@ -0,0 +1,135 @@
+#!/usr/bin/env python3
+"""
+Markdown Spacing Formatter
+
+This script formats Markdown files to insert standard empty lines between distinct 
+block-level elements (headings, code blocks, lists, and tables).
+
+Ensuring clean spacing around these blocks prevents layout and rendering issues on 
+standard Markdown parsers (like GitHub's file preview and other repository viewers) 
+while maintaining 100% compatibility with MkDocs.
+
+Usage:
+    python scripts/format_markdown.py
+"""
+
+import os
+import re
+
+# Resolve the absolute path to the docs directory relative to the repository root
+repo_root = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
+docs_dir = os.path.join(repo_root, "docs")
+
+heading_re = re.compile(r"^#{1,6}\s+")
+code_block_re = re.compile(r"^```")
+list_re = re.compile(r"^(\s*[-*+]\s|\s*\d+\.\s)")
+
+def format_markdown_file(filepath):
+    with open(filepath, "r", encoding="utf-8") as f:
+        content = f.read()
+
+    had_final_newline = content.endswith("\n")
+    lines = content.splitlines()
+    output = []
+    
+    def add_line(l):
+        # Prevent consecutive empty lines
+        if not l.strip():
+            if not output or not output[-1].strip():
+                return
+        output.append(l)
+
+    in_code_block = False
+    idx = 0
+    num_lines = len(lines)
+    
+    while idx < num_lines:
+        line = lines[idx]
+        stripped = line.strip()
+        
+        # Code block boundaries
+        if code_block_re.match(stripped):
+            in_code_block = not in_code_block
+            
+            if in_code_block: # Starting code block
+                if idx > 0:
+                    prev_line = lines[idx - 1].strip()
+                    if prev_line and not code_block_re.match(prev_line) and not prev_line.startswith(">"):
+                        add_line("")
+                add_line(line)
+            else: # Ending code block
+                add_line(line)
+                if idx < num_lines - 1:
+                    next_line = lines[idx + 1].strip()
+                    if next_line and not code_block_re.match(next_line) and not next_line.startswith(">"):
+                        add_line("")
+            idx += 1
+            continue
+            
+        if in_code_block:
+            output.append(line)
+            idx += 1
+            continue
+            
+        # Heading boundaries
+        if heading_re.match(line):
+            if idx > 0:
+                prev_line = lines[idx - 1].strip()
+                if prev_line and not heading_re.match(prev_line):
+                    add_line("")
+            
+            add_line(line)
+            
+            if idx < num_lines - 1:
+                next_line = lines[idx + 1].strip()
+                if next_line and not heading_re.match(next_line):
+                    add_line("")
+            idx += 1
+            continue
+            
+        # List boundaries
+        if list_re.match(line):
+            if idx > 0:
+                prev_line = lines[idx - 1].strip()
+                if prev_line and not list_re.match(lines[idx - 1]) and not heading_re.match(prev_line) and not prev_line.startswith(">"):
+                    add_line("")
+            
+            add_line(line)
+            
+            if idx < num_lines - 1:
+                next_line = lines[idx + 1].strip()
+                if next_line and not list_re.match(lines[idx + 1]) and not next_line.startswith(">") and not code_block_re.match(next_line):
+                    orig_next_line = lines[idx + 1]
+                    if orig_next_line and not orig_next_line.startswith(" ") and not orig_next_line.startswith("\t"):
+                        add_line("")
+            idx += 1
+            continue
+            
+        add_line(line)
+        idx += 1
+        
+    new_content = "\n".join(output).strip()
+    if had_final_newline:
+        new_content += "\n"
+
+    if new_content != content:
+        with open(filepath, "w", encoding="utf-8") as f:
+            f.write(new_content)
+        return True
+    return False
+
+if __name__ == "__main__":
+    if not os.path.exists(docs_dir):
+        print(f"Error: Could not find documentation directory at: {docs_dir}")
+        exit(1)
+        
+    modified_count = 0
+    for root, dirs, files in os.walk(docs_dir):
+        for file in files:
+            if file.endswith(".md"):
+                filepath = os.path.join(root, file)
+                if format_markdown_file(filepath):
+                    print(f"Formatted: {os.path.relpath(filepath, docs_dir)}")
+                    modified_count += 1
+
+    print(f"\nDone. Formatted {modified_count} files.")