From 737ea93f2334ed601925b01db4403edd4b7bca20 Mon Sep 17 00:00:00 2001 From: Bernhard Schuster Date: Thu, 13 Feb 2025 17:34:34 +0100 Subject: [PATCH 1/5] docs: fmt all commonmark --- contracts/contracts/README.md | 6 +- contracts/ops/README.md | 4 +- contracts/specs/PROPERTIES.md | 20 +++--- .../subnets/parent-child-interactions.md | 3 - .../developer-guides/deploy-blockscout.md | 7 +- .../pluggable-syscall-tutorial.md | 17 +++-- .../developer-guides/upgrades/README.md | 4 +- .../developer-guides/upgrades/patch-state.md | 3 +- .../upgrades/upgrade-wasm-actor.md | 3 +- docs-gitbook/quickstarts/deploy-a-subnet.md | 36 ++++++---- docs-gitbook/reference/faq.md | 4 +- docs-gitbook/reference/ipc-cli-usage.md | 12 +++- docs-gitbook/reference/troubleshooting.md | 2 - .../performing-transactions-in-a-subnet.md | 2 - docs/fendermint/README.md | 1 + docs/fendermint/activity_rollups.md | 2 +- docs/fendermint/architecture.md | 3 +- docs/fendermint/checkpointing.md | 1 + docs/fendermint/gas_markets.md | 2 +- docs/fendermint/ipc.md | 61 ++++++++++------ docs/fendermint/localnet.md | 1 + docs/fendermint/observability.md | 2 +- docs/fendermint/running.md | 22 ++++-- docs/fendermint/tendermint.md | 2 +- docs/ipc/contracts.md | 10 ++- docs/ipc/developers.md | 5 +- docs/ipc/quickstart-calibration.md | 2 +- docs/ipc/usage.md | 72 ++++++++++++++++++- docs/ipc/validator-gater.md | 4 +- specs/drafts/contract-redesign.md | 36 +++++----- specs/drafts/genesis-v2.md | 10 +-- specs/drafts/observability.md | 8 +-- 32 files changed, 240 insertions(+), 127 deletions(-) diff --git a/contracts/contracts/README.md b/contracts/contracts/README.md index 4f39799929..5a73931034 100644 --- a/contracts/contracts/README.md +++ b/contracts/contracts/README.md @@ -30,6 +30,6 @@ To do that, we use the `get_selectors` function from a script in Python. ## References -- [Introduction to EIP-2535 Diamonds](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard) -- [ERC-2535: Diamonds, Multi-Facet Proxy](https://eips.ethereum.org/EIPS/eip-2535#facets-state-variables-and-diamond-storage) -- [Understanding Diamonds on Ethereum](https://dev.to/mudgen/understanding-diamonds-on-ethereum-1fb) +- [Introduction to EIP-2535 Diamonds](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard) +- [ERC-2535: Diamonds, Multi-Facet Proxy](https://eips.ethereum.org/EIPS/eip-2535#facets-state-variables-and-diamond-storage) +- [Understanding Diamonds on Ethereum](https://dev.to/mudgen/understanding-diamonds-on-ethereum-1fb) diff --git a/contracts/ops/README.md b/contracts/ops/README.md index 6367deedf0..28bb9518e1 100644 --- a/contracts/ops/README.md +++ b/contracts/ops/README.md @@ -2,5 +2,5 @@ This directory includes a set of scripts to ease the deployment of the IPC Solidity contracts to any network using hardhat. -- `deploy.sh`: Deploys the IPC solidity contracts into a specific network. -- `compile-abi.sh`: Compiles all contracts and outputs the ABI for the high-level contracts in the desired folder (by default `./out`). +- `deploy.sh`: Deploys the IPC solidity contracts into a specific network. +- `compile-abi.sh`: Compiles all contracts and outputs the ABI for the high-level contracts in the desired folder (by default `./out`). diff --git a/contracts/specs/PROPERTIES.md b/contracts/specs/PROPERTIES.md index 6033184b81..6bdf1fe2d1 100644 --- a/contracts/specs/PROPERTIES.md +++ b/contracts/specs/PROPERTIES.md @@ -2,16 +2,16 @@ List of identified and checked invariants of the IPC protocol following the categorization by [Certora](https://github.com/Certora/Tutorials/blob/master/06.Lesson_ThinkingProperties/Categorizing_Properties.pdf): -- Valid States -- State Transitions -- Variable Transitions -- High-Level Properties -- Unit Tests -- Valid States -- State Transitions -- Variable Transitions -- High-Level Properties -- Unit Tests +- Valid States +- State Transitions +- Variable Transitions +- High-Level Properties +- Unit Tests +- Valid States +- State Transitions +- Variable Transitions +- High-Level Properties +- Unit Tests ## Subnet Registry diff --git a/docs-gitbook/concepts/subnets/parent-child-interactions.md b/docs-gitbook/concepts/subnets/parent-child-interactions.md index ec23576961..8d4ef686b7 100644 --- a/docs-gitbook/concepts/subnets/parent-child-interactions.md +++ b/docs-gitbook/concepts/subnets/parent-child-interactions.md @@ -16,8 +16,6 @@ There are following parent-child interactions available in IPC 6\. Removing child subnets from the IPC hierarchy. - - ## Checkpointing Checkpointing is a method for a parent subnet to keep a record of the evolution of its child subnet’s state by including snapshots of the child’s state (called checkpoints) in the parent’s state. If, for some reason, the child subnet misbehaves as a whole, agreement can be reached in the parent subnet about how to proceed. @@ -26,7 +24,6 @@ Checkpointed history of a child subnet cannot be reverted as long as a parent su In case of subnet failure, checkpointing enables participants (e.g., former users of the failed subnet) to agree on picking up an older version of the child subnet’s state from before the occurrence of the failure and, say, use that version as the initial state of a new, more robust subnet.\ - ### Checkpointing fees There are a number of fees that are paid during checkpointing: diff --git a/docs-gitbook/developer-guides/deploy-blockscout.md b/docs-gitbook/developer-guides/deploy-blockscout.md index 7bed80bf73..b35a4d5a62 100644 --- a/docs-gitbook/developer-guides/deploy-blockscout.md +++ b/docs-gitbook/developer-guides/deploy-blockscout.md @@ -1,16 +1,18 @@ -# Deploying Blockscout on a local subnet +# Deploying Blockscout on a local subnet Before delving into this tutorial, you should have [deployed a local subnet](deploy-a-subnet). If you're connecting to an existing remote subnet and not following the guide, make sure that you have a local docker installation. These are instructions for deploying a basic, non-customised, local subnet explorer. The resulting instance will not provide all Blockscout features not be appropriate for production use. 1. Get Blockscout + ``` git clone https://github.com/blockscout/blockscout cd ./blockscout/docker-compose ``` -2. Edit `./envs/common-blockscout.env` and set +2. Edit `./envs/common-blockscout.env` and set + ``` INDEXER_DISABLE_PENDING_TRANSACTIONS_FETCHER=true INDEXER_DISABLE_INTERNAL_TRANSACTIONS_FETCHER=true @@ -21,6 +23,7 @@ The default setup assumes a local subnet with the Ethereum RPC on `localhost:854 Some frontend calls use hardcoded absolute URLs. Unless you're only accessing the Blockscout interface on `localhost`, make sure to review the environmental variables in the different files under `./envs/` and adjust addresses (e.g. `BLOCKSCOUT_HOST` in `envs/common-blockscout.env` and `NEXT_PUBLIC_STATS_API_HOST` in `envs/common-frontend.env`. You'll also need to make sure the required ports are accessible (at least 80, 8080, and 8081). 3. Start Blockscout + ``` docker compose -f docker-compose-no-build-geth.yml up -d ``` diff --git a/docs-gitbook/developer-guides/pluggable-syscall-tutorial.md b/docs-gitbook/developer-guides/pluggable-syscall-tutorial.md index 2ea14ac2df..70719cc3ff 100644 --- a/docs-gitbook/developer-guides/pluggable-syscall-tutorial.md +++ b/docs-gitbook/developer-guides/pluggable-syscall-tutorial.md @@ -15,7 +15,7 @@ IPC uses the [Filecoin Virtual Machine (FVM)](https://docs.filecoin.io/smart-con * Extending chain-specific syscalls once IPC supports more root chains. Because other chains may have their own special syscalls different as Filecoin (proof validation, etc.). * Extending features to support better development tools. E.g. adding special debugging syscalls, adding randomness syscalls, and supporting more ECC curve, etc. -## Pre-requisite knowledge for tutorial: +## Pre-requisite knowledge for tutorial * [ref-fvm](https://github.com/filecoin-project/ref-fvm) * [fvm syscall APIs](https://docs.rs/fvm\_sdk/latest/fvm\_sdk/sys/index.html) @@ -34,7 +34,7 @@ TIP: For clarity, the instructions may have skipped certain files (like long `Ca ### **1. Define the custom syscall** * In this example, we will be creating a simple syscall which accesses the filesystem. Inside syscalls, you can run external processes, link to rust libraries, access network, call other syscalls, etc. -* We’ll call this new syscall `my_custom_syscall`and its defined as follows: +* We’ll call this new syscall `my_custom_syscall`and its defined as follows: ```rust pub trait CustomKernel: Kernel { @@ -43,7 +43,7 @@ TIP: For clarity, the instructions may have skipped certain files (like long `Ca ``` [fendermint/vm/interpreter/src/fvm/examples/mycustomkernel.rs#L23](https://github.com/consensus-shipyard/ipc/blob/98497363a10e08236325e6d5c52755b9fcd52958/fendermint/vm/interpreter/src/fvm/examples/mycustomkernel.rs#L23) -* Define a struct `CustomKernelImpl` which extends `DefaultKernel` . We use the `ambassador` crate to automatically delegate calls which reduces the boilerplate code we need to write. Here we simply delegate all calls to existing syscall to the `DefaultKernel`. +* Define a struct `CustomKernelImpl` which extends `DefaultKernel` . We use the `ambassador` crate to automatically delegate calls which reduces the boilerplate code we need to write. Here we simply delegate all calls to existing syscall to the `DefaultKernel`. ```rust #[derive(Delegate)] @@ -65,7 +65,7 @@ TIP: For clarity, the instructions may have skipped certain files (like long `Ca ### **2. Implementing all necessary functions for the syscall** -* Implement `my_custom_syscall` +* Implement `my_custom_syscall` Here is where we implement our custom syscall: @@ -166,11 +166,11 @@ where + MessageOps + NetworkOps + RandomnessOps - + SelfOps, + + SelfOps, { - fn link_syscalls(linker: &mut Linker<K>) -> anyhow::Result<()> { + fn link_syscalls(linker: &mut Linker<K>) -> anyhow::Result<()> { DefaultKernel::<K::CallManager>::link_syscalls(linker)?; - + linker.link_syscall("my_custom_kernel", "my_custom_syscall", my_custom_syscall)?; Ok(()) @@ -211,8 +211,7 @@ executor: DefaultExecutor) -> anyhow::Result<()> { let state_tree = state.state_tree_mut(); @@ -90,4 +89,4 @@ let interpreter = FvmMessageInterpreter::::new( ... scheduler, ); -``` \ No newline at end of file +``` diff --git a/docs-gitbook/developer-guides/upgrades/upgrade-wasm-actor.md b/docs-gitbook/developer-guides/upgrades/upgrade-wasm-actor.md index e94735cd41..fe6ca24766 100644 --- a/docs-gitbook/developer-guides/upgrades/upgrade-wasm-actor.md +++ b/docs-gitbook/developer-guides/upgrades/upgrade-wasm-actor.md @@ -10,7 +10,6 @@ To replace the existing `chainmetadata` actor that we deployed at genesis with t Our migration function is defined as follows: - ```rust // The WASM binary of the new version of the chainmetadata actor. static WASM_BIN: &[u8] = include_bytes!("../output/fendermint_actor_chainmetadata_v2.wasm"); @@ -73,4 +72,4 @@ let interpreter = FvmMessageInterpreter::::new( ... scheduler, ); -``` \ No newline at end of file +``` diff --git a/docs-gitbook/quickstarts/deploy-a-subnet.md b/docs-gitbook/quickstarts/deploy-a-subnet.md index 0fe9223e30..956e72a92b 100644 --- a/docs-gitbook/quickstarts/deploy-a-subnet.md +++ b/docs-gitbook/quickstarts/deploy-a-subnet.md @@ -10,10 +10,11 @@ Several steps in this guide involve running long-lived processes. In each of the ### Step 1: Prepare your system -#### Install the basic requirements for IPC: +#### Install the basic requirements for IPC {% tabs %} {% tab title="Linux" %} + * Install system packages: `sudo apt install build-essential clang cmake pkg-config libssl-dev protobuf-compiler git curl`. * Install Rust. See [instructions](https://www.rust-lang.org/tools/install). * Install cargo-make: `cargo install --force cargo-make`. @@ -25,9 +26,11 @@ Also install the following dependencies ([details](https://lotus.filecoin.io/lot ``` sudo apt update && sudo apt install build-essential libssl-dev mesa-opencl-icd ocl-icd-opencl-dev gcc git bzr jq pkg-config curl clang hwloc libhwloc-dev wget ca-certificates gnupg -y ``` + {% endtab %} {% tab title="MacOS" %} + * Install Xcode from App Store or terminal: `xcode-select --install` * Install Homebrew. See [instructions](https://brew.sh/). * Install dependencies: `brew install jq` @@ -38,7 +41,7 @@ sudo apt update && sudo apt install build-essential libssl-dev mesa-opencl-icd o {% endtab %} {% endtabs %} -#### Building: +#### Building {% hint style="info" %} NOTE: this step may take a while to compile, depending on OS version and hardware build @@ -46,6 +49,7 @@ NOTE: this step may take a while to compile, depending on OS version and hardwar {% tabs %} {% tab title="Linux" %} + ``` # make sure that rust has the wasm32 target & use stable version of rustc rustup target add wasm32-unknown-unknown @@ -63,9 +67,11 @@ make ./target/release/ipc-cli --version ./target/release/fendermint --version ``` + {% endtab %} {% tab title="MacOS" %} + ``` # make sure that rust has the wasm32 target & use stable version of rustc rustup target add wasm32-unknown-unknown @@ -82,6 +88,7 @@ cargo build --release ./target/release/ipc-cli --version ./target/release/fendermint --version ``` + {% endtab %} {% endtabs %} @@ -91,10 +98,12 @@ cargo build --release {% tabs %} {% tab title="Linux/MacOS" %} + ``` alias ipc-cli="cargo run -q -p ipc-cli --release --" ipc-cli config init ``` + {% endtab %} {% endtabs %} @@ -117,7 +126,7 @@ gateway_addr = "" registry_addr = "" ``` -* **Replace** the `gateway_addr` and `registry_addr` with the following values. Click on the badges below to take you to the source to copy and paste them or go to [this link](https://github.com/consensus-shipyard/ipc/blob/cd/contracts/deployments/r314159.json). +* **Replace** the `gateway_addr` and `registry_addr` with the following values. Click on the badges below to take you to the source to copy and paste them or go to [this link](https://github.com/consensus-shipyard/ipc/blob/cd/contracts/deployments/r314159.json). [![Gateway Address](https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fraw.githubusercontent.com%2Fconsensus-shipyard%2Fipc%2Fcd%2Fcontracts%2Fdeployments%2Fr314159.json\&query=%24.gateway\_addr\&label=Gateway%20Address)](https://github.com/consensus-shipyard/ipc/blob/cd/contracts/deployments/r314159.json) @@ -224,39 +233,40 @@ TIP: Highly recommend documenting that information which will be useful to boots ################################# Subnet ID: - /r314159/t410f6b2qto756ox3qfoonq4ii6pdrylxwyretgpixuy + /r314159/t410f6b2qto756ox3qfoonq4ii6pdrylxwyretgpixuy Eth API: - http://0.0.0.0:8545 + http://0.0.0.0:8545 Chain ID: - 3684170297508395 + 3684170297508395 Fendermint API: - http://localhost:26658 + http://localhost:26658 CometBFT API: - http://0.0.0.0:26657 + http://0.0.0.0:26657 CometBFT node ID: - ca644ac3194d39a2834f5d98e141d682772c149b + ca644ac3194d39a2834f5d98e141d682772c149b CometBFT P2P: - http://0.0.0.0:26656 + http://0.0.0.0:26656 IPLD Resolver Multiaddress: - /ip4/0.0.0.0/tcp/26655/p2p/16Uiu2HAkwhrWn9hYFQMR2QmW5Ky7HJKSGVkT8xKnQr1oUGCkqWms + /ip4/0.0.0.0/tcp/26655/p2p/16Uiu2HAkwhrWn9hYFQMR2QmW5Ky7HJKSGVkT8xKnQr1oUGCkqWms ``` You'll need the final component of the `IPLD Resolver Multiaddress` (the `peer ID`) and the `CometBFT node ID` for the next nodes to start. -* _**BOOTSTRAPS**_: \@validator-1-cometbft:26656 +* _**BOOTSTRAPS**_: \@validator-1-cometbft:26656 ``` // An example ca644ac3194d39a2834f5d98e141d682772c149b@validator-1-cometbft:26656 ``` -* _**RESOLVER\_BOOTSTRAPS**_: /dns/validator-1-fendermint/tcp/26655/p2p/\ + +* _**RESOLVER\_BOOTSTRAPS**_: /dns/validator-1-fendermint/tcp/26655/p2p/\ 
// An example
     /dns/validator-1-fendermint/tcp/26655/p2p/16Uiu2HAkwhrWn9hYFQMR2QmW5Ky7HJKSGVkT8xKnQr1oUGCkqWms
diff --git a/docs-gitbook/reference/faq.md b/docs-gitbook/reference/faq.md
index df20353653..93d1e1fb51 100644
--- a/docs-gitbook/reference/faq.md
+++ b/docs-gitbook/reference/faq.md
@@ -10,7 +10,7 @@ The IPC team is working on delivering IPC features incrementally based on the ro
 * :white\_check\_mark: _**Milestone2.5:** IPC preview._
   * This milestone migrates away from the Eudico/Lotus stack to the Fendermint stack.
   * Developers can spin up new IPC subnets anchored on Filecoin's Calibration network for general purposes with the fast block time and finality, not customization at this stage.
-*   _**\[WIP] Milestone 3:** Production-grade manually-created, customizable L2+ networks_
+* _**\[WIP] Milestone 3:** Production-grade manually-created, customizable L2+ networks_
 
     Audited and tested a version of the Fendermint stack that is safe to deploy production apps and move customers’ funds into (well-designed) subnets. 
 * _**Milestone 4**: Support for user-deployed Wasm actors + multi-subnet apps + QoL improvements._
@@ -146,7 +146,7 @@ The smart contract interaction between subnets is achieved by using GMP (General
 
 ***
 
-### Cost & Performance:
+### Cost & Performance
 
 **Q: Are the gas usage costs the same as the Filecoin mainnet (independent from gas price)?** 
 
diff --git a/docs-gitbook/reference/ipc-cli-usage.md b/docs-gitbook/reference/ipc-cli-usage.md
index 807cff03a8..28b6985e77 100644
--- a/docs-gitbook/reference/ipc-cli-usage.md
+++ b/docs-gitbook/reference/ipc-cli-usage.md
@@ -58,6 +58,7 @@ This command only shows subnets that have been registered to the gateway, i.e. t
 #### Create a child subnet
 
 {% code overflow="wrap" %}
+
 ```
 ipc-cli subnet create
     --parent 
@@ -65,6 +66,7 @@ ipc-cli subnet create
     --min-validator-stake 
     --bottomup-check-period 
 ```
+
 {% endcode %}
 
 This command will create a subnet and create a corresponding contract based on the parameters specified with it. Make a note of the subnet-id for the subnet just created.
@@ -78,6 +80,7 @@ $ ipc-cli subnet create --parent /r314159 --min-validators 3 --min-validator-sta
 #### Join a subnet as a validator
 
 {% code overflow="wrap" %}
+
 ```sh
 ipc-cli subnet join
     --subnet 
@@ -85,6 +88,7 @@ ipc-cli subnet join
     --public-key 
     --initial-balance 
 ```
+
 {% endcode %}
 
 This command specifies the subnet to join, the amount of collateral to provide, and the public key of the `--from` address that is joining as a validator.
@@ -156,11 +160,13 @@ To inspect the changes to the power table that have been performed between two e
 ```
 ipc-cli checkpoint list-validator-changes --from-epoch= --to-epoch=
 ```
+
 {% endhint %}
 
 #### Transfer tokens within a subnet
 
 {% code overflow="wrap" %}
+
 ```sh
 ipc-cli subnet send-value
     --subnet 
@@ -168,6 +174,7 @@ ipc-cli subnet send-value
     --to 
     
 ```
+
 {% endcode %}
 
 You can use this command to send tokens between addresses of the same subnet. If `--from` is not specified, `ipc-cli` will send tokens from the default wallet address.
@@ -245,12 +252,13 @@ $ ipc-cli wallet export --wallet-type evm --address 0x406a7a1d002b71ece175cc7e06
 exported new wallet with address 0x406a7a1d002b71ece175cc7e067620ae5b58e9ec in file "/tmp/priv.key"
 ```
 
-*   Export key encoded in based64 for Fendermint
+* Export key encoded in based64 for Fendermint
 
     ```sh
     ipc-cli wallet export --wallet-type evm --address  --fendermint > 
     ```
-*   Export key in HEX
+
+* Export key in HEX
 
     ```sh
     ipc-cli wallet export --wallet-type evm --address  --hex > 
diff --git a/docs-gitbook/reference/troubleshooting.md b/docs-gitbook/reference/troubleshooting.md
index 5a9e047782..982b1cd7f3 100644
--- a/docs-gitbook/reference/troubleshooting.md
+++ b/docs-gitbook/reference/troubleshooting.md
@@ -43,8 +43,6 @@ By running `cargo tree` we saw that these dependencies were pulled in from the `
 
 Example: Failing integration tests due to local changes in ~/.cargo/registry
 
-
-
 
 
 If you are seeing weird unexplained behaviour that you kind of can't wrap your head around, then you may want to delete your `~/.cargo/registry` and run `cargo build`. Here is why, you _might_ have accidentally changed some of the crates's source files that cargo is using in your project. There is no way to know if you had made any local changes to any of these crates as \`Cargo\`\` does not maintain hash of these dependencies and there is no git repo available to compare against.
diff --git a/docs-gitbook/user-guides/performing-transactions-in-a-subnet.md b/docs-gitbook/user-guides/performing-transactions-in-a-subnet.md
index d0d4b4953a..6e28e774a5 100644
--- a/docs-gitbook/user-guides/performing-transactions-in-a-subnet.md
+++ b/docs-gitbook/user-guides/performing-transactions-in-a-subnet.md
@@ -10,8 +10,6 @@ description: >-
 
 Assuming the process of launching a custom IPC Subnet with at least one validator node is complete, the custom IPC Subnet is now available for a user (defined here as a wallet on the subnet that is does not necessarily represent a validator) to perform transactions. 
 
-
-
 * A user would begin by launching Metamask, and manually adding the custom IPC Network to their Metamask networks list using “Add a network manually.”  
 
 \
diff --git a/docs/fendermint/README.md b/docs/fendermint/README.md
index ac67227960..afb5769684 100644
--- a/docs/fendermint/README.md
+++ b/docs/fendermint/README.md
@@ -9,4 +9,5 @@ The following documentation should help getting oriented:
 * [Running IPC infrastructure](./ipc.md)
 
 You can also check out the previous demos:
+
 * [Milestone-1 Demo](./demos/milestone-1/README.md)
diff --git a/docs/fendermint/activity_rollups.md b/docs/fendermint/activity_rollups.md
index 32cb53825a..4eb23f7992 100644
--- a/docs/fendermint/activity_rollups.md
+++ b/docs/fendermint/activity_rollups.md
@@ -245,7 +245,7 @@ In order to set the address of the ValidatorRewarder at subnet creation time, yo
 flag when deploying the subnet actor:
 
 ```bash
-$ ipc-cli subnet create --validator-rewarder 
+ipc-cli subnet create --validator-rewarder 
 ```
 
 #### Example ValidatorRewarder implementations
diff --git a/docs/fendermint/architecture.md b/docs/fendermint/architecture.md
index 3e40771057..1f20ec3492 100644
--- a/docs/fendermint/architecture.md
+++ b/docs/fendermint/architecture.md
@@ -6,6 +6,7 @@ some of which can be implemented using Fendermint:
 ![Architecture](images/IPC%20with%20Tendermint%20Core.jpg)
 
 The components in a nutshell:
+
 * __Lotus rootnet__: Lotus has to support IPC to act as the rootnet for its child subnets. There are competing proposals with regards to this being in the form of mostly user-deployed smart contracts, or built-in (privileged) capabilities.
 * __Tendermint Core__: acts as the generic SMR in one of the subnets, talking to all other Tendermint instances in that subnet. It runs separate from the Application, which is completely in our control, and talks to it via ABCI++.
 * __Application__: This is where we implement the IPC ledger logic, the transaction handling, using the FVM/FEVM. We implement the ABCI++ interface to be compatible with Tendermint. Other than that we delegate to reusable smart contracts, for example to produce checkpoints. We rely on ABCI to pass us the headers to be signed, and we can use the ledger to gather signatures for checkpoints.
@@ -19,7 +20,7 @@ The components in a nutshell:
 
 We want make use of the ABCI++ interface to get more control over the voting process by implementing the new `PrepareProposal` and `ProcessProposal` methods. These are close to be [released](https://github.com/tendermint/tendermint/issues/9053) in the upcoming `v0.37` of Tendermint Core.
 
-The best place to look up the details of the ABCI++ spec is currently at https://github.com/tendermint/tendermint/tree/v0.37.0-rc2/spec/abci
+The best place to look up the details of the ABCI++ spec is currently at 
 
 Note that the spec has previously been under the `main` branch but not any more, and that it changed recently to only contain the above two extra methods, but not _vote extensions_ for the new `FinalizeBlock` method, which was supposed to replace `BeginBlock`, `DeliverTx`, `EndBlock` and I think `Commit`.
 
diff --git a/docs/fendermint/checkpointing.md b/docs/fendermint/checkpointing.md
index 9c2a63fd51..9ae4f2ffa9 100644
--- a/docs/fendermint/checkpointing.md
+++ b/docs/fendermint/checkpointing.md
@@ -1,6 +1,7 @@
 # Checkpointing
 
 Bottom-up checkpoints are periodically submitted to the parent subnet, carrying:
+
 * bottom-up messages
 * the next highest configuration number adopted form the validator changesets observed on the parent
 * a multi-sig from the current validator set
diff --git a/docs/fendermint/gas_markets.md b/docs/fendermint/gas_markets.md
index 293946a345..3e24015153 100644
--- a/docs/fendermint/gas_markets.md
+++ b/docs/fendermint/gas_markets.md
@@ -111,4 +111,4 @@ UpgradeScheduler.
 
 1. Updating the block gas limit in a block containing other transactions leads to undefined behaviour. Always perform
    this update in isolation, and at the end of the block. The new block gas limit is applied from the next block
-   onwards.  
\ No newline at end of file
+   onwards.  
diff --git a/docs/fendermint/ipc.md b/docs/fendermint/ipc.md
index 0823740122..fa865675ed 100644
--- a/docs/fendermint/ipc.md
+++ b/docs/fendermint/ipc.md
@@ -9,7 +9,9 @@ This docs are only focused on the infrastructure deployment, for an end-to-end w
 * Install the basic requirements for IPC (see [README](../../README.md#Prerequisites))
 
 ## Deploy subnet bootstrap
+
 In order not to expose directly the network address information from validators, subnets leverage the use of bootstrap nodes (or `seeds` in CometBFT parlance), for new nodes to discover peers in the network and connect to the subnet's validators. To run a bootstrap node you can run the following command from the root of the repo:
+
 ```bash
 cargo make --makefile infra/Makefile.toml \
     -e SUBNET_ID= \
@@ -21,7 +23,9 @@ cargo make --makefile infra/Makefile.toml \
     -e CMT_P2P_EXTERNAL_ADDR= \
     bootstrap
 ```
+
 You'll see that by the end of the output, this command should output the network address of your bootstrap. You can use this endpoint to include this bootstrap node as a seed in the `seeds` configuration of CometBFT.
+
 ```console
 [cargo-make] INFO - Running Task: cometbft-wait
 [cargo-make] INFO - Running Task: cometbft-node-id
@@ -30,36 +34,42 @@ You'll see that by the end of the output, this command should output the network
 ```
 
 If at any time you need to query the endpoint of your bootstrap, you can run:
+
 ```bash
 cargo make --makefile infra/Makefile.toml \
     bootstrap-id
 ```
 
 `cargo-make bootstrap` supports the following environment variables to customize the deployment:
-- `CMT_P2P_HOST_PORT` (optional): Specifies the listening port for the bootstraps P2p interface in the localhost for CometBFT. This is the address that needs to be shared with other peers if they want to use the bootstrap as a `seed` to discover connections.
-- `CMT_RPC_HOST_PORT` (optional): Specifies the listening port in the localhost for CometBFT's RPC.
-- `SUBNET_ID`: SubnetID the bootstrap is operating in.
-- `NODE_NAME` (optional): Node name information to attach to the containers of the deployment. This will be needed to deploy more than one bootstrap in the same local environment.
-- `BOOTSTRAPS`: Comma separated list of bootstraps (or seeds in CometBFT parlance) that we want this bootstrap to also be connected to.
-- `CMT_P2P_EXTERNAL_ADDR`: Address to advertise to peers for them to dial. If empty, will use the same as the default listening address from CometBFT (generally `0.0.0.0:`).
-- `PARENT_ENDPOINT`: Public endpoint that the validator should use to connect to the parent.
-- `PARENT_REGISTRY`: Ethereum address of the IPC registry contract in the parent
-- `PARENT_GATEWAY`: Ethereum address of the IPC gateway contract in the parent.
+
+* `CMT_P2P_HOST_PORT` (optional): Specifies the listening port for the bootstraps P2p interface in the localhost for CometBFT. This is the address that needs to be shared with other peers if they want to use the bootstrap as a `seed` to discover connections.
+* `CMT_RPC_HOST_PORT` (optional): Specifies the listening port in the localhost for CometBFT's RPC.
+* `SUBNET_ID`: SubnetID the bootstrap is operating in.
+* `NODE_NAME` (optional): Node name information to attach to the containers of the deployment. This will be needed to deploy more than one bootstrap in the same local environment.
+* `BOOTSTRAPS`: Comma separated list of bootstraps (or seeds in CometBFT parlance) that we want this bootstrap to also be connected to.
+* `CMT_P2P_EXTERNAL_ADDR`: Address to advertise to peers for them to dial. If empty, will use the same as the default listening address from CometBFT (generally `0.0.0.0:`).
+* `PARENT_ENDPOINT`: Public endpoint that the validator should use to connect to the parent.
+* `PARENT_REGISTRY`: Ethereum address of the IPC registry contract in the parent
+* `PARENT_GATEWAY`: Ethereum address of the IPC gateway contract in the parent.
 
 Finally, to remove the bootstrap you can run:
+
 ```bash
 cargo make --makefile infra/Makefile.toml bootstrap-down
 ```
+
 And to restart it:
+
 ```
 cargo make --makefile infra/Makefile.toml bootstrap-restart
 ```
 
-
 ## Deploy child subnet validator
+
 Once a child subnet has been bootstrapped in its parent, its subnet actor has been deployed, and has fulfilled its minimum requirements in terms of validators and minimum collateral, validators in the subnet can deploy their infrastructure to spawn the child subnet.
 
 In order to spawn a validator node in a child subnet, you need to run:
+
 ```bash
 cargo make --makefile infra/Makefile.toml \
     -e PRIVATE_KEY_PATH= \
@@ -73,32 +83,39 @@ cargo make --makefile infra/Makefile.toml \
     -e CMT_P2P_EXTERNAL_ADDR= \
     child-validator
 ```
+
 This command will run the infrastructure for a Fendermint validator in the child subnet. It will generate the genesis of the subnet from the information in its parent, and will run the validator's infrastructure with the specific configuration passed in the command.
 
 `cargo-make child-validator` supports the following environment variables to customize the deployment:
-- `CMT_P2P_HOST_PORT` (optional): Specifies the listening port in the localhost for the P2P interface of the CometBFT node.
-- `CMT_RPC_HOST_PORT` (optional): Specifies the listening port in the localhost for CometBFT's RPC.
-- `ETHAPI_HOST_PORT` (optional): Specifies the listening port in the localhost for the ETH RPC of the node.
-- `NODE_NAME` (optional): Name for the node deployment. Along with `CMT_P2P_HOST_PORT`, `CMT_RPC_HOST_PORT` and `ETHAPI_HOST_PORT`, these variables come really handy for the deployment of several validator nodes over the same system.
-- `PRIVATE_KEY_PATH`: Path of the hex encoded private key for your validator (it should be the corresponding one used to join the subnet in the parent). This can be exported from the `ipc-cli` or any other wallet like Metamask.
-- `SUBNET_ID`: SubnetID for the child subnet.
-- `BOOTSTRAPS`: Comma separated list of bootstraps (or seeds in CometBFT parlance).
-- `CMT_P2P_EXTERNAL_ADDR`: Address to advertise to peers for them to dial. If empty, will use the same as the default listening address from CometBFT (generally `0.0.0.0:`).
-- `PARENT_ENDPOINT`: Public endpoint that the validator should use to connect to the parent.
-- `PARENT_REGISTRY`: Ethereum address of the IPC registry contract in the parent
-- `PARENT_GATEWAY`: Ethereum address of the IPC gateway contract in the parent.
+
+* `CMT_P2P_HOST_PORT` (optional): Specifies the listening port in the localhost for the P2P interface of the CometBFT node.
+* `CMT_RPC_HOST_PORT` (optional): Specifies the listening port in the localhost for CometBFT's RPC.
+* `ETHAPI_HOST_PORT` (optional): Specifies the listening port in the localhost for the ETH RPC of the node.
+* `NODE_NAME` (optional): Name for the node deployment. Along with `CMT_P2P_HOST_PORT`, `CMT_RPC_HOST_PORT` and `ETHAPI_HOST_PORT`, these variables come really handy for the deployment of several validator nodes over the same system.
+* `PRIVATE_KEY_PATH`: Path of the hex encoded private key for your validator (it should be the corresponding one used to join the subnet in the parent). This can be exported from the `ipc-cli` or any other wallet like Metamask.
+* `SUBNET_ID`: SubnetID for the child subnet.
+* `BOOTSTRAPS`: Comma separated list of bootstraps (or seeds in CometBFT parlance).
+* `CMT_P2P_EXTERNAL_ADDR`: Address to advertise to peers for them to dial. If empty, will use the same as the default listening address from CometBFT (generally `0.0.0.0:`).
+* `PARENT_ENDPOINT`: Public endpoint that the validator should use to connect to the parent.
+* `PARENT_REGISTRY`: Ethereum address of the IPC registry contract in the parent
+* `PARENT_GATEWAY`: Ethereum address of the IPC gateway contract in the parent.
 
 Finally, to remove the bootstrap you can run:
+
 ```
 cargo make --makefile infra/Makefile.toml child-validator-down
 ```
+
 And to restart it:
+
 ```
 cargo make --makefile infra/Makefile.toml child-validator-restart
 ```
 
 ## Deploy subnet full-node
+
 To deploy a full node (i.e. a node that validates and keeps all the state of a subnet but doesn't participate in the proposal of new blocks), the following command can be used:
+
 ```bash
 cargo make --makefile infra/Makefile.toml \
     -e SUBNET_ID= \
@@ -111,7 +128,9 @@ cargo make --makefile infra/Makefile.toml \
     -e CMT_P2P_EXTERNAL_ADDR= \
     child-fullnode
 ```
+
 The full node also has its corresponding commands to kill and restart the node:
+
 ```
 cargo make --makefile infra/Makefile.toml child-fullnode-down
 cargo make --makefile infra/Makefile.toml child-fullnode-restart
diff --git a/docs/fendermint/localnet.md b/docs/fendermint/localnet.md
index ab1d7644bf..fe423af61c 100644
--- a/docs/fendermint/localnet.md
+++ b/docs/fendermint/localnet.md
@@ -33,6 +33,7 @@ cargo make --makefile ./infra/fendermint/Makefile.toml testnode
 It will create three docker containers (cometbft, fendermint, and eth-api).
 
 To stop run the following:
+
 ```bash
 cargo make --makefile ./infra/Makefile.toml testnode-down
 ```
diff --git a/docs/fendermint/observability.md b/docs/fendermint/observability.md
index 03001e8e17..679f09dd93 100644
--- a/docs/fendermint/observability.md
+++ b/docs/fendermint/observability.md
@@ -423,7 +423,7 @@ enabled = true
 
 > 🚧 Note: the event journal and general logs are currently output to the same file.
 > We plan to segregate in the near future so that the event journal has its dedicated file.
-> See this issue: https://github.com/consensus-shipyard/ipc/issues/1084.
+> See this issue: .
 
 Tracing can also be configured via the configuration file for Fendermint. You can set the tracing level and specify whether to log to console or file.
 
diff --git a/docs/fendermint/running.md b/docs/fendermint/running.md
index eabcb2e0a9..c3e1a8de47 100644
--- a/docs/fendermint/running.md
+++ b/docs/fendermint/running.md
@@ -2,6 +2,7 @@
 
 The commands are all executed by the `fendermint` binary, which is produced from the `fendermint_app` crate,
 so we have many ways to run the program:
+
 * `fendermint `, after running `cargo install --path fendermint/app`
 * `./target/release/fendermint `, after running `cargo build --release`
 * `cargo run -p fendermint_app --release -- `
@@ -27,6 +28,7 @@ mkdir test-network
 ```
 
 If you are running in test network, define the network using env variable.
+
 ```shell
 export FM_NETWORK=test
 ```
@@ -197,7 +199,9 @@ cargo run -p fendermint_app --release -- \
       --bottom-up-check-period 10 \
       --msg-fee 1 --majority-percentage 65
 ```
+
 Check the result:
+
 ```console
 $ cat test-network/genesis.json | jq .ipc
 {
@@ -212,6 +216,7 @@ $ cat test-network/genesis.json | jq .ipc
 ```
 
 ### Seal Genesis State
+
 After the genesis file has been created, seal the genesis state and dump to a car file.
 
 ```shell
@@ -331,7 +336,6 @@ $ cat ~/.cometbft/config/genesis.json
 We can see that our original `genesis.json` has been made part of CometBFT's version under `app_state`,
 and that the top level `validators` are empty, to be filled out by the application during the `init_chain` ABCI call.
 
-
 #### Convert the private key
 
 By default CometBFT uses Ed25519 validator keys, but in theory it can use anything that looks like a key.
@@ -366,6 +370,7 @@ $ cat ~/.cometbft/config/priv_validator_key.json
 $ cat test-network/keys/bob.pk
 AiImfwVC/LeFJN9bB612aCtjbCYWuilf2SorSUXez/QE
 ```
+
 
 
 ## Run processes
@@ -455,8 +460,8 @@ $ rm -rf ~/.fendermint/data/rocksdb && cargo run -p fendermint_app --release --
 ...
 2023-05-19T09:13:54.110007Z DEBUG fendermint_app::app: commit state state_root="bafy2bzacebh4fbl6rv7tlxxf2zsxqifjr424tkykwmgffqaho6mvr6hy7dq42" timestamp=1684487633
 ```
-
 
+
 
 

   CometBFT log
@@ -477,15 +482,18 @@ I[2023-05-19|10:13:54.110] committed state                              module=s
 I[2023-05-19|10:13:54.116] indexed block exents                         module=txindex height=3
 ...
 ```
+
 

 
 Note that the first block execution is very slow because we have to load the Wasm engine, as indicated by the first proposal having a timeout,
 but after that the blocks come in fast, one per second.
 
 ### Run ETH API
+
 If we want to use `evm` related API, such as running `fendermint/eth/api/examples/ethers.rs`, we need to start ETH API process.
 
 The ETH RPC api runs on top of cometbft. Make sure you have cometbft running properly. The architecture is as follows:
+
 ```
 +---------------------------+
 | Node                      |
@@ -519,10 +527,13 @@ The ETH RPC api runs on top of cometbft. Make sure you have cometbft running pro
 | :8545                     |
 -----------------------------
 ```
+
 To start the ethereum RPC api with:
+
 ```
 cargo run -p fendermint_app --release -- eth run
 ```
+
 We will see:
 

   ETH API log
@@ -535,13 +546,14 @@ We will see:
 

 
 We can try query the chain id by:
+
 ```shell
 curl -X POST -i   -H 'Content-Type: application/json'   -d '{"jsonrpc":"2.0","id":0,"method":"eth_chainId","params":[]}'   http://localhost:8545
 ```
 
 ### Access Metrics
 
-By default `fendermint` has Prometheus metrics enabled (with more to be added) and available at http://localhost:9184/metrics.
+By default `fendermint` has Prometheus metrics enabled (with more to be added) and available at .
 
 ## Query the state
 
@@ -664,7 +676,6 @@ $ cargo run -p fendermint_app --release -- rpc query actor-state --address $ALIC
 
 Great, Alice's nonce was correctly increased as well.
 
-
 ## Create FEVM Contract
 
 When we want to deploy a smart contract to the FVM, the currently supported way is by deploying EVM contracts to FEVM.
@@ -736,7 +747,9 @@ Note that the script figures out the Alice's nonce on its own, so we don't have
 ## Deploy IPC child subnet
 
 ### Crate genesis from parent
+
 Fendermint includes a command to automatically create the genesis file for an IPC child subnet according to the information for the subnet available in its parent. Here's an example of the generation of a genesis file for a subnet that has already been bootstrapped in the parent.
+
 ```shell
 cargo run -p fendermint_app -- \
     --network=test \
@@ -747,6 +760,7 @@ cargo run -p fendermint_app -- \
 ```
 
 Here's a sample execution of the command for an already bootstrapped subnet in `/r314159`:
+
 ```shell
 cargo run -p fendermint_app -- \
     --network=test \
diff --git a/docs/fendermint/tendermint.md b/docs/fendermint/tendermint.md
index 16f3964af2..7978572efa 100644
--- a/docs/fendermint/tendermint.md
+++ b/docs/fendermint/tendermint.md
@@ -8,7 +8,6 @@ To implement the [architecture](./architecture.md) we intend to make use of the
 
 That should be enough to get us started with Tendermint.
 
-
 ## Install CometBFT
 
 We will need ~~Tendermint Core~~ CometBFT running and building the blockchain, and since we don't want to fork it, we can install the pre-packaged `cometbft` binary from the [releases](https://github.com/cometbft/cometbft/releases). At the time of this writing, our target is the [v0.37.1](https://github.com/cometbft/cometbft/releases/tag/v0.37.1) release, and things should work with the `v0.37.0-rc2` version of Tendermint Core as well.
@@ -16,6 +15,7 @@ We will need ~~Tendermint Core~~ CometBFT running and building the blockchain, a
 Alternatively, we can [install](https://github.com/cometbft/cometbft/blob/main/docs/guides/install.md) the project from source. I expect to have to dig around in the source code to understand the finer nuances, so this is what I'll do. It needs `go` 1.18 or higher [installed](https://go.dev/doc/install) (check with `go version`).
 
 The following code downloads the source, checks out the branch with the necessary ABCI++ features, and installs it.
+
 ```shell
 git clone https://github.com/cometbft/cometbft.git
 cd cometbft
diff --git a/docs/ipc/contracts.md b/docs/ipc/contracts.md
index 58ca907e18..8b178acbd7 100644
--- a/docs/ipc/contracts.md
+++ b/docs/ipc/contracts.md
@@ -2,10 +2,9 @@
 
 IPC subnets have the same exact support for the deployment of EVM contracts as the Filecoin network. We highly recommend refering to [the following docs](https://docs.filecoin.io/smart-contracts/fundamentals/overview/) for a detailed description of FEVM and the steps and tooling to use EVM in Filecoin. In this section, we will present the additional steps required to follow the docs in a subnet.
 
-
 ## Configuring EVM tooling with your subnet
 
-In order to connect the Ethereum tooling to your subnet, you'll need to get the RPC endpoint of your subnet peer and the subnet's `chainID`. For this, you can use the following command from your IPC agent to retrieve the RPC endpoint for a specific subnet: 
+In order to connect the Ethereum tooling to your subnet, you'll need to get the RPC endpoint of your subnet peer and the subnet's `chainID`. For this, you can use the following command from your IPC agent to retrieve the RPC endpoint for a specific subnet:
 
 ```bash
 ipc-cli subnet rpc --network 
@@ -16,10 +15,9 @@ rpc: "http://0.0.0.0:8545/"
 chainID: "1874254988642837"
 ```
 
-
 ### Example: Connect Metamask to your subnet
 
-To connect Metamask to your subnet, you need to add it as a new network. To do this you need to: 
+To connect Metamask to your subnet, you need to add it as a new network. To do this you need to:
 
 - Click `Add network` in networks section of Metamask.
 
@@ -39,9 +37,9 @@ With this your Metamask should be successfully connected to your subnet, and you
 
 ## Deploying a contract in your subnet
 
-To deploy a smart contract in your subnet the only pre-requirement is to have some funds in the subnet to pay for the gas. To inject funds in your subnet you can follow the steps described [here](./usage.md). 
+To deploy a smart contract in your subnet the only pre-requirement is to have some funds in the subnet to pay for the gas. To inject funds in your subnet you can follow the steps described [here](./usage.md).
 
-It is important to note that the IPC agent doesn't understand Ethereum addresses directly, which means that to send funds to an Ethereum address, you will need to send funds to their underlying f4 address. You can use the following command from the IPC agent to get the f4 address for an Ethereum address: 
+It is important to note that the IPC agent doesn't understand Ethereum addresses directly, which means that to send funds to an Ethereum address, you will need to send funds to their underlying f4 address. You can use the following command from the IPC agent to get the f4 address for an Ethereum address:
 
 ```bash
 ipc-cli util eth-to-f4-addr --addr 
diff --git a/docs/ipc/developers.md b/docs/ipc/developers.md
index 8dcb93dd96..5a1a052803 100644
--- a/docs/ipc/developers.md
+++ b/docs/ipc/developers.md
@@ -4,7 +4,7 @@
 
 This project has a large set of dependencies and they are all bundled together in a root Cargo.lock file. This means that sometimes, when upgrading some of our dependencies, Cargo will do something unexpected which causes build errors which can be very time consuming to figure out.
 
-### Failed to select a version for `xyz`.
+### Failed to select a version for `xyz`
 
 

 Example
@@ -27,13 +27,13 @@ all possible versions conflict with previously selected packages.
     ... which satisfies path dependency `fil_actor_miner` (locked to 12.0.0) of package `fil_actors_integration_tests v1.0.0 (/home/fridrik/workspace4/builtin-actors/integration_tests)`
     ... which satisfies path dependency `fil_actors_integration_tests` (locked to 1.0.0) of package `test_vm v12.0.0 (/home/fridrik/workspace4/builtin-actors/test_vm)`
 ```
+
 

 
 If you get this error, then it means that Rust could not find a version of the `xyz` crate which fulfills the requirements of the package and other packages that depend on it. To debug this, look what dependencies of `xyz` package are, and check if they need to be updated.
 
 This error can happen for example when upgrading to a new major/minor FVM versions without upgrading also other dependencies like `frc_dispatch` which requires fvm as well. In that case we must upgrade the `frc_dispatch` package to use the same FVM version as we are using.
 
-
 ### Unexplained transitive dependencies in wasm32 target after upgrading FVM version
 
 When upgrading FVM dependency (from 4.0 to 4.1) it resulted in our `fendermint/actors/build.rs` script to fail due Cargo including multiple new dependencies in the `wasm32` target which did not occur before and caused build errors since these new dependencies did not support Wasm target.
@@ -58,6 +58,7 @@ So I had tried cargo clean, removing all docker images/containers but nothing wo
 If something like this happen again, I will make sure to try to remove .cargo/registry altogether to make sure there are no local changes.
 If someone knows if its possible to check if there are any local changes in the .cargo/registry I would be interested to know, but as far as I know there is no way to do that
 ```
+
 
 
 If you are seeing weird unexplained behaviour that you kind of can't wrap your head around, then you may want to delete your `~/.cargo/registry` and run `cargo build`. Here is why, you _might_ have accidentally changed some of the crates's source files that cargo is using in your project. There is no way to know if you had made any local changes to any of these crates as `Cargo`` does not maintain hash of these dependencies and there is no git repo available to compare against.
diff --git a/docs/ipc/quickstart-calibration.md b/docs/ipc/quickstart-calibration.md
index 82e3b79bce..ff18ef9a72 100644
--- a/docs/ipc/quickstart-calibration.md
+++ b/docs/ipc/quickstart-calibration.md
@@ -1 +1 @@
-# Moved to [IPC Docs](https://docs.ipc.space/quickstarts/deploy-a-subnet)
\ No newline at end of file
+# Moved to [IPC Docs](https://docs.ipc.space/quickstarts/deploy-a-subnet)
diff --git a/docs/ipc/usage.md b/docs/ipc/usage.md
index e49c94b66d..556f2b9319 100644
--- a/docs/ipc/usage.md
+++ b/docs/ipc/usage.md
@@ -3,11 +3,15 @@
 >💡 For background and setup information, make sure to start with the [README](/README.md).
 
 ## Key management
+
 The `ipc-cli` has internally an EVM wallet that it uses to sign transactions and interact with IPC on behalf of specific addresses. Some of the features available for EVM addresses through the EVM are:
+
 * Creating new Ethereum addresses
+
 ```bash
 ./bin/ipc-cli wallet new --wallet-type evm
 ```
+
 ```console
 # Sample execution
 ./bin/ipc-cli wallet new --wallet-type evm
@@ -15,9 +19,11 @@ The `ipc-cli` has internally an EVM wallet that it uses to sign transactions and
 ```
 
 * Exporting a key stored in the IPC cli keystore.
+
 ```bash
 ./bin/ipc-cli wallet export --wallet-type evm --address  > 
 ```
+
 ```console
 # Sample execution
 ./bin/ipc-cli wallet export --wallet-type evm --address 0x406a7a1d002b71ece175cc7e067620ae5b58e9ec -o /tmp/priv.key
@@ -25,19 +31,23 @@ exported new wallet with address 0x406a7a1d002b71ece175cc7e067620ae5b58e9ec in f
 ```
 
 * You can also export your private key encoded in base64 in a format that can be consumed by Fendermint by adding the `--fendermint` flag.
+
 ```bash
 ./bin/ipc-cli wallet export --wallet-type evm --address   --fendermint > 
 ```
 
 * Or hex encoded as expected by Ethereum tooling (like Metamask or hardhat).
+
 ```bash
 ./bin/ipc-cli wallet export --wallet-type evm --address  -o  --hex
 ```
 
 * Importing a key from a file
+
 ```bash
 ./bin/ipc-cli wallet import --wallet-type evm --path=
 ```
+
 ```console
 # Sample execution
 $ ./bin/ipc-cli wallet import --wallet-type evm --path=~/tmp/wallet.key
@@ -45,15 +55,19 @@ imported wallet with address "0x406a7a1d002b71ece175cc7e067620ae5b58e9ec"
 ```
 
 > 💡 The format expected to import new EVM keys is the following:
+>
 > ```
 > {"address":,"private_key":}
 > ```
+>
 > You can always create this file manually to import some address into the agent that you have exported from some other tool with an alternative format.
 
 * Importing an identity directly from its private key
+
 ```bash
 ./bin/ipc-cli wallet import --wallet-type evm --private-key 
 ```
+
 ```console
 # Sample execution
 $ ./bin/ipc-cli wallet import --wallet-type evm --private-key=0x405f50458008edd6e2eb2efc3bf34846db1d6689b89fe1a9f9ccfe7f6e301d8d
@@ -61,16 +75,19 @@ imported wallet with address "0x406a7a1d002b71ece175cc7e067620ae5b58e9ec"
 ```
 
 * You can set a default key for your wallet so it is always the one used when the `--from` flag is not explicitly set
+
 ```bash
 ./bin/ipc-cli wallet set-default --address  --wallet-type evm
 ```
 
 * And check what is your current default key:
+
 ```bash
 ./bin/ipc-cli wallet get-default --wallet-type evm
 ```
 
 * Check the hex encoded public key of your address with:
+
 ```bash
 ./bin/ipc-cli wallet pub-key --wallet-type evm --address=
 ```
@@ -82,6 +99,7 @@ As a sanity-check that we have joined the subnet successfully and that the subne
 ```bash
 ./bin/ipc-cli subnet list --subnet=
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet list --subnet=/r31415926
@@ -93,13 +111,16 @@ This command only shows subnets that have been registered to the gateway, i.e. t
 ## Joining a subnet and adding collateral
 
 * To join a subnet with the `ipc-cli`
+
 ```bash
 ./bin/ipc-cli subnet join --subnet  --collateral 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet join --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc2lf5bpjo6i --collateral=1
 ```
+
 This command specifies the subnet to join, the amount of collateral to provide and the public key of the `--from` address that is joining as a validator.
 
 * And to stake more collateral as a validator:
@@ -107,21 +128,26 @@ This command specifies the subnet to join, the amount of collateral to provide a
 ```bash
 ./bin/ipc-cli subnet stake --subnet  --collateral 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet stake --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc2lf5bpjo6i --collateral=1
 ```
 
 > 💡 Note that changes in collateral and the power table are not reflected immediately in the parent. They need to be confirmed in the execution of the next bottom-up checkpoint, so until this happen, even if there has been a change in collateral, you may not be the change immediately when running `ipc-cli subnet list`. This impacts any change to the collateral of validators, i.e. `stake`, `unstake` and `leave` commands. In order to inspect the changes to the power table that have been performed between two epochs you can use the following command:
+>
 > ```bash
 > ./bin/ipc-cli checkpoint list-validator-changes --from-epoch= --to-epoch=
 > ```
 
 ## Listing your balance in a subnet
+
 In order to send messages in a subnet, you'll need to have funds in your subnet account. You can use the following command to list the balance of your wallets in a subnet:
+
 ```bash
 ./bin/ipc-cli wallet balances --wallet-type evm --subnet 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli wallet balances --subnet=/r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq
@@ -130,9 +156,11 @@ $ ./bin/ipc-cli wallet balances --subnet=/r31415926/t4xwzbdu7z5sam6hc57xxwkctciu
 ## Sending funds in a subnet
 
 The agent provides a command to conveniently exchange funds between addresses of the same subnet. This can be achieved through the following command:
+
 ```bash
 ./bin/ipc-cli subnet send-value --subnet  [--from ] --to  
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet send-value --subnet /r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq --to t1xbevqterae2tanmh2kaqksnoacflrv6w2dflq4i 10
@@ -141,22 +169,27 @@ $ ./bin/ipc-cli subnet send-value --subnet /r31415926/t4xwzbdu7z5sam6hc57xxwkctc
 ## Sending funds between subnets
 
 At the moment, the IPC agent only expose commands to perform the basic IPC interoperability primitives for cross-net communication, which is the exchange of FIL (the native token for IPC) between the same address of a subnet. Mainly:
-- `fund`, which sends native token from one public key address, to the same public key address in the child.
-- `release` that movesnative token from one account in a child subnet to its counter-part in the parent.
+
+* `fund`, which sends native token from one public key address, to the same public key address in the child.
+* `release` that movesnative token from one account in a child subnet to its counter-part in the parent.
 
 Complex behavior can be implemented using these primitives: sending value to a user in another subnet can be implemented a set of `release/fund` and `sendValue` operations. Calling  smart contract from one subnet to another works by providing funds to one account in the destination subnet, and then calling the contract. The `ipc-cli` doesn't currently include abstractions for this complex operations, but it will in the future. That being said, users can still leverage the `ipc-cli` or even the `IpcProvider` library to easily compose the basic primitives into complex functionality (in case you want to hack something cool and contribute to the project :) ).
 
 >💡 All cross-net operations need to pay an additional cross-msg fee (apart from the gas cost of the message). This is reason why even if you sent `X FIL` you may see `X - fee FIL` arriving to you account at destination. This fee is used to reward subnet validators for their work committing the checkpoint that carries the message.
 
 ### Fund
+
 Funding a subnet can be performed by using the following command:
+
 ```bash
 ./bin/ipc-cli cross-msg fund --subnet  [--from ] [--to ] 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli cross-msg fund --subnet /r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq 100
 ```
+
 This command includes the cross-net message into the next top-down proof-of-finality. Once the top-down finality is committed in the child, the message will be executed and you should see the funds in your account of the child subnet. If the `--to` is not set explicitly, the funds are send to the address of the `--from` in the subnet.
 
 Alternatively, we can pass an additional parameter to send the funds to a specific address in the child subnet
@@ -168,6 +201,7 @@ fund performed in epoch 1030279
 ```
 
 The epoch were the message is performed can give you a sense of the time the message will take to be propagated. You can check the current finality in a subnet and wait for the finality height that includes your message to be committed.
+
 ```bash
 ./bin/ipc-cli cross-msg parent-finality --subnet 
 ```
@@ -181,30 +215,38 @@ $ ./bin/ipc-cli cross-msg parent-finality --subnet /r31415926/t4xwzbdu7z5sam6hc5
 >💡 Top-down proofs-of-finality is the underlying process used for IPC to propagate information from the parent to the child. Validators in the child subnet include information in every block in the child subnet about the height of the parent they agree to consider final. When this information is committed on-chain, changes into the validator set of the subnet, and the execution of top-down messages are correspondingly triggered.
 
 * In order to list the top-down messages sent for a subnet from a parent network for a specific epoch, run the following command:
+
 ```bash
 ./bin/ipc-cli cross-msg list-topdown-msgs --subnet= --epoch=
 
 ```
 
 #### Funding subnet address in genesis
+
 In order to fund your address in a child subnet genesis before it is bootstrapped, and include some funds on your address in the subnet in genesis, you can use the `pre-fund` command. This command can only be used before the subnet is bootsrapped and started. The inverse of this operation is `pre-release`, which allows you to recover some of these initial funds before the subnet starts:
+
 ```bash
 ./bin/ipc-cli cross-msg pre-fund --subnet  [--from ] 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli cross-msg pre-fund --subnet=/r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq 0.1
 ```
 
 ### Release
+
 In order to release funds from a subnet, your account must hold enough funds inside it. Releasing funds to the parent subnet can be performed with the following command:
+
 ```bash
 ./bin/ipc-cli cross-msg release --subnet  [--from ] [--to ] 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli cross-msg release --subnet=/r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq 100
 ```
+
 This command includes the cross-net message into a bottom-up checkpoint after the current epoch. Once the bottom-up checkpoint is committed in the parent, you should see the funds in your account in the parent. If the `--to` is not set explicitly, the funds are send to the address of the `--from` in the parent.
 
 Alternatively, we can pass an additional parameter to release the funds to a specific address in the parent subnet
@@ -214,10 +256,13 @@ Alternatively, we can pass an additional parameter to release the funds to a spe
 $ ./bin/ipc-cli cross-msg release --subnet /r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq --to=0x406a7a1d002b71ece175cc7e067620ae5b58e9ec 100
 release performed in epoch 1030
 ```
+
 As with top-down messages, you can get a sense of the time that your message will take to get to the parent by looking at the epoch in which your bottom-up message was triggered (the output of the command), and listing the latest bottom-up checkpoints to see how far it is from being propagated.
 
 The propagation of a bottom-up checkpoint from a child subnet to its parent follows these stages:
+
 * Validators in the child subnet populate the checkpoint, sign it, and agree on their validity. When validators have agreed on the validity of a checkpoint for a specific epoch, a new `QuorumReached` event is emitted in the child subnet. You can check if a checkpoint for certain epoch has already been signed by a majority of child validators through the following command: `./bin/ipc-cli checkpoint quorum-reached-events --from-epoch 600 --to-epoch 680 --subnet`.
+
 ```shell
 # Sample execution
 ./bin/ipc-cli checkpoint quorum-reached-events --from-epoch 600 --to-epoch 680 --subnet /r314159/t410ffumhfeppdjixhkxtgagowxkdu77j7xz5aaa52vy
@@ -230,28 +275,36 @@ The propagation of a bottom-up checkpoint from a child subnet to its parent foll
 Finally, the bundle of checkpoints and signatures populated and already signed by a child subnet for their submission to the parent on a window of heights can be checked through the command `./bin/ipc-cli checkpoint list-bottomup-bundle --subnet  --from-epoch  --to-epoch `
 
 #### Releasing initial subnet balance
+
 To recover some (or all) of the funds that were sent to a subnet through `pre-fund` to be included as genesis balance for your address, you can use the `pre-release` command as follows:
+
 ```bash
 ./bin/ipc-cli cross-msg pre-release --subnet  [--from ] 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli cross-msg pre-release --subnet=/r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq 0.1
 ```
 
 ## Running a relayer
+
 IPC relies on the role of a specific type of peer on the network called the relayers that are responsible for submitting bottom-up checkpoints that have been finalized in a child subnet to its parent. This process is key for the commitment of child subnet checkpoints in the parent, and the execution of bottom-up cross-net messages. Without relayers, cross-net messages will only flow from top levels of the hierarchy to the bottom, but not the other way around.
 
 * *session* Run the relayer process for your subnet using your default address by calling:
+
 ```bash
 ./bin/ipc-cli checkpoint relayer --subnet 
 ```
+
 * In order to run the relayer from a different address you can use the `--submitted` flag:
+
 ```bash
 ./bin/ipc-cli checkpoint relayer --subnet  --submitter 
 ```
 
 Relayers are rewarded through cross-net messages fees for the timely submission of bottom-up checkpoints to the parent. In order to claim the checkpointing rewards collected for a subnet, the following command need to be run from the relayer address:
+
 ```bash
 ./bin/ipc-cli subnet claim --subnet= --reward
 ```
@@ -259,9 +312,11 @@ Relayers are rewarded through cross-net messages fees for the timely submission
 ## Listing checkpoints from a subnet
 
 Subnets are periodically committing checkpoints to their parent every `bottomup-check-period` (parameter defined when creating the subnet). If you want to inspect the information of a range of bottom-up checkpoints committed in the parent for a subnet, you can use the `checkpoint list-bottomup` command provided by the agent as follows:
+
 ```bash
 ./bin/ipc-cli checkpoint list-bottomup --from-epoch  --to-epoch  --subnet 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli checkpoint list-bottomup --from-epoch 0 --to-epoch 100 --subnet /r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq
@@ -269,24 +324,30 @@ epoch 0 - prev_check={"/":"bafy2bzacedkoa623kvi5gfis2yks7xxjl73vg7xwbojz4tpq63dd
 epoch 10 - prev_check={"/":"bafy2bzacecsatvda6lodrorh7y7foxjt3a2dexxx5jiyvtl7gimrrvywb7l5m"}, cross_msgs=null, child_checks=null
 epoch 30 - prev_check={"/":"bafy2bzaceauzdx22hna4e4cqf55jqmd64a4fx72sxprzj72qhrwuxhdl7zexu"}, cross_msgs=null, child_checks=null
 ```
+
 You can find the checkpoint where your cross-message was included by listing the checkpoints around the epoch where your message was sent.
 
 ## Leaving a subnet and releasing collateral
 
 * To join a subnet with the `ipc-cli`
+
 ```bash
 ./bin/ipc-cli subnet join --subnet  --collateral 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet join --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc2lf5bpjo6i --collateral=1
 ```
+
 This command specifies the subnet to join, the amount of collateral to provide and the public key of the `--from` address that is joining as a validator.
 
 * To join a subnet and also include some initial balance for the validator in the subnet, you can add the `--initial-balance` flag with the balance to be included in genesis:
+
 ```bash
 ./bin/ipc-cli subnet join --subnet  --collateral  --initial-balance 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet join --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc2lf5bpjo6i --collateral=1 \
@@ -294,32 +355,37 @@ $ ./bin/ipc-cli subnet join --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc
 ```
 
 * To leave a subnet, the following agent command can be used:
+
 ```bash
 ./bin/ipc-cli subnet leave --subnet 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet leave --subnet /r31415926/t4xwzbdu7z5sam6hc57xxwkctciuaz7oe5omipwbq
 ```
-Leaving a subnet will release the collateral for the validator and remove all the validation rights from its account. This means that if you have a validator running in that subnet, its validation process will immediately terminate.
 
+Leaving a subnet will release the collateral for the validator and remove all the validation rights from its account. This means that if you have a validator running in that subnet, its validation process will immediately terminate.
 
 * Validators can also reduce their collateral in the subnet through `unstake`
 
 ```bash
 ./bin/ipc-cli subnet stake --subnet  --collateral 
 ```
+
 ```console
 # Example execution
 $ ./bin/ipc-cli subnet stake --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc2lf5bpjo6i --collateral=1
 ```
 
 > 💡 Remember, as described in the joining and leaving collateral section, that changes to the validator set and their collateral are not reflected immediately. Validator changes between two epochs can be inspected through:
+>
 > ```bash
 > ./bin/ipc-cli checkpoint list-validator-changes --from-epoch= --to-epoch=
 > ```
 
 * Once the reduction of collateral has been confirmed by the subnet, validators can claim their collateral back through:
+
 ```bash
 ./bin/ipc-cli subnet claim --subnet=/r314159/t410fh4ywg4wvxcjzz4vsja3uh4f53johc2lf5bpjo6i
 ```
diff --git a/docs/ipc/validator-gater.md b/docs/ipc/validator-gater.md
index 6a5fec930c..2de5b3ecb1 100644
--- a/docs/ipc/validator-gater.md
+++ b/docs/ipc/validator-gater.md
@@ -64,7 +64,7 @@ The Validator Gater feature supports two primary modes of operation:
 
 In a federated network, the gater contract can directly manage validator power using the `setFederatedPower` method. This method is typically used when validator power is explicitly set by a central authority or policy.
 
-#### Example Command:
+#### Example Command
 
 ```bash
 ipc-cli subnet set-federated-power
@@ -76,7 +76,7 @@ This allows for centralized control over which validators participate and with w
 
 For networks operating in collateral-based mode, the Validator Gater contract will intercept validator actions such as joining the network, staking, unstaking, and leaving.
 
-#### Example Commands:
+#### Example Commands
 
 ```bash
 ipc-cli subnet join
diff --git a/specs/drafts/contract-redesign.md b/specs/drafts/contract-redesign.md
index f293e10c22..cc6a20ef8a 100644
--- a/specs/drafts/contract-redesign.md
+++ b/specs/drafts/contract-redesign.md
@@ -19,8 +19,8 @@ There are a few problems associated with the above approach or the current imple
 # Phases / scope
 
 - [ ]  Milestone 1: Security-focused refactor of contracts
-    - Segregation of each `SubnetActor`
-    - Gateway performs routing of messages
+  - Segregation of each `SubnetActor`
+  - Gateway performs routing of messages
 - [ ]  Milestone 2: Generalisation of permission modes
 - [ ]  Milestone 3: Generalisation of subnet genesis
 - [ ]  Milestone 4: Subnet and gateway upgrades
@@ -54,7 +54,7 @@ interface SubnetActor {
   function genesis() external view returns(bytes memory);
 
   function powerAllocationMode() external view 
-	  returns(PowerAllocationMode memory);
+   returns(PowerAllocationMode memory);
 
   function consensus() external view returns(Consensus memory);
 
@@ -118,7 +118,7 @@ The lifecycle of a subnet happens both in the parent, i.e. through `SubnetActor`
 
 - Creation: Subnet creation is just contract deployment, which currently is handled by the subnet registry or by the subnet owner. The creation of the subnet is not a concern here.
 - Bootstrap: When the subnet has reached `PowerAllocationMode` thresholds, such as min collateral and min validator count reached, for collateral based mode. The su
-    - Then each power allocation mode should have its own implementation.
+  - Then each power allocation mode should have its own implementation.
 
 `IPC` will provide several template implementations of different permission modes.
 
@@ -138,17 +138,17 @@ interface CollateralSubnet is SubnetActor {
 
   // for join, stake, unstake, leave, kill handling of pre
   function validatorJoin(
-	  uint256 collateral,
-	  bytes publicKey
-	) external emits PowerChange[];
+   uint256 collateral,
+   bytes publicKey
+ ) external emits PowerChange[];
 
   function validatorStake(
-	  uint256 collateral
-	) external emits PowerChange[];
+   uint256 collateral
+ ) external emits PowerChange[];
 
   function validatorUnstake(
-	  uint256 collateral
-	) external emits PowerChange[];
+   uint256 collateral
+ ) external emits PowerChange[];
 
   function validatorLeave() external emits PowerChange[];
 
@@ -195,12 +195,12 @@ For topdown messages, the funds should be locked in the child subnet. For exampl
 contract SubnetActor {
 
   function fund(..., uint256 amount) {
-	  SupplySource memory s = ...;
-	  s.lock(amount);
-	  
-	  IPCEnvolope msg = ...
-	  
-	  // same as current implementation
+   SupplySource memory s = ...;
+   s.lock(amount);
+   
+   IPCEnvolope msg = ...
+   
+   // same as current implementation
     commitTopdownMsg(msg);
   }
 }
@@ -285,4 +285,4 @@ contract SubnetBootstrapFacet {
 
 The `SubnetActorFacet, FederatedPowerFacet` above can have their own bootstrap conditions. Caller of `SubnetBootstrapFacet.genesis` just need to parse the bytes to accordingly.
 
-The `SubnetBootstrapFacet.genesis()` should be passed to the child `Gateway` , so that the gateway can streamline the genesis syncing process, without manually customization.
\ No newline at end of file
+The `SubnetBootstrapFacet.genesis()` should be passed to the child `Gateway` , so that the gateway can streamline the genesis syncing process, without manually customization.
diff --git a/specs/drafts/genesis-v2.md b/specs/drafts/genesis-v2.md
index 1b112b6ea3..dcd8035787 100644
--- a/specs/drafts/genesis-v2.md
+++ b/specs/drafts/genesis-v2.md
@@ -1,12 +1,12 @@
 # Subnet genesis v2
 
-### Scope 
+### Scope
 
 This document introduces a revised set of processes to conduct subnet genesis, codenamed "Subnet Genesis v2".  
 
 ### Context
 
-_Genesis_ is a term widely used in the DLT space, and it can take various nuances depending on the technology/chain. 
+_Genesis_ is a term widely used in the DLT space, and it can take various nuances depending on the technology/chain.
 In Bitcoin, genesis refers to the first block in the Bitcoin chain. In Tendermint, genesis refers to the specification
 document used to bootstrap a chain.
 
@@ -26,9 +26,9 @@ general steps for genesis are as follows:
 4. Seal the specification (generates the initial state tree).
 5. Materialize the consensus-specific genesis assets.
 
-### Data model 
+### Data model
 
-Below is the schema for the IPC genesis specification, in a relaxed YAML notation. 
+Below is the schema for the IPC genesis specification, in a relaxed YAML notation.
 
 ```yaml
 ## Schema version. Initial value: 1.
@@ -171,4 +171,4 @@ setting the root CID in the `initial_state_tree` field. It also transitions the
 ### Materializing consensus-specific genesis assets
 
 `ipc genesis materialize --spec-file=` reads the specification file, ensures that it's sealed, and generates
-the genesis assets required for the selected consensus engine type.
\ No newline at end of file
+the genesis assets required for the selected consensus engine type.
diff --git a/specs/drafts/observability.md b/specs/drafts/observability.md
index 7b0ab1f019..da321a9e77 100644
--- a/specs/drafts/observability.md
+++ b/specs/drafts/observability.md
@@ -81,10 +81,10 @@ The tracing journal is configured via a `[tracing]` block within the Fendermint
 
 Implementation note: we're not reinventing the wheel here. It’s simply an abstraction over the `tracing` library and its appenders, all of which we already use. Refs:
 
-- Tracing Appender: https://docs.rs/tracing-appender/latest/tracing_appender/rolling/
-- EnvFilter Structure: https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html
+- Tracing Appender: 
+- EnvFilter Structure: 
 
-For a pretty decent reference, look at the Lotus journal: https://github.com/filecoin-project/lotus/tree/master/journal. We even managed to slap an alerting system on top of it without breaking everything.
+For a pretty decent reference, look at the Lotus journal: . We even managed to slap an alerting system on top of it without breaking everything.
 
 ## Tracing Configuration
 
@@ -120,7 +120,7 @@ By configuring these options, you can control the behavior of metrics and tracin
 
 ## Implementation
 
-The existing metrics code paths are rather contorted and messy due to unnecessary indirection and excessive meta-programming. Read more commentary in the original pull request: https://github.com/consensus-shipyard/ipc/pull/835.
+The existing metrics code paths are rather contorted and messy due to unnecessary indirection and excessive meta-programming. Read more commentary in the original pull request: .
 
 Take for example the `NewParentView` trace.
 

From 05d439819e96a635d7f74f6c86932b465b9cde60 Mon Sep 17 00:00:00 2001
From: Bernhard Schuster 
Date: Thu, 13 Feb 2025 17:55:34 +0100
Subject: [PATCH 2/5] fix

---
 .markdownlint.yaml            | 252 ++++++++++++++++++++++++++++++++++
 docs/ipc/validator-gater.md   |   4 -
 specs/drafts/observability.md |   1 -
 3 files changed, 252 insertions(+), 5 deletions(-)
 create mode 100644 .markdownlint.yaml

diff --git a/.markdownlint.yaml b/.markdownlint.yaml
new file mode 100644
index 0000000000..056ef0aaa9
--- /dev/null
+++ b/.markdownlint.yaml
@@ -0,0 +1,252 @@
+# Example markdownlint configuration with all properties set to their default value
+
+# Default state for all rules
+default: true
+
+# Path to configuration file to extend
+extends: null
+
+# MD001/heading-increment : Heading levels should only increment by one level at a time : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md001.md
+MD001: false
+
+# MD003/heading-style : Heading style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md003.md
+MD003: false
+  # Heading style
+#  style: "consistent"
+
+# MD004/ul-style : Unordered list style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md004.md
+MD004:
+  # List style
+  style: "consistent"
+
+# MD005/list-indent : Inconsistent indentation for list items at the same level : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md005.md
+MD005: true
+
+# MD007/ul-indent : Unordered list indentation : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md007.md
+MD007:
+  # Spaces for indent
+  indent: 2
+  # Whether to indent the first level of the list
+  start_indented: false
+  # Spaces for first level indent (when start_indented is set)
+  start_indent: 2
+
+# MD009/no-trailing-spaces : Trailing spaces : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md009.md
+MD009:
+  # Spaces for line break
+  br_spaces: 2
+  # Allow spaces for empty lines in list items
+  list_item_empty_lines: false
+  # Include unnecessary breaks
+  strict: false
+
+# MD010/no-hard-tabs : Hard tabs : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md010.md
+MD010:
+  # Include code blocks
+  code_blocks: true
+  # Fenced code languages to ignore
+  ignore_code_languages: []
+  # Number of spaces for each hard tab
+  spaces_per_tab: 1
+
+# MD011/no-reversed-links : Reversed link syntax : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md011.md
+MD011: true
+
+# MD012/no-multiple-blanks : Multiple consecutive blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md012.md
+MD012:
+  # Consecutive blank lines
+  maximum: 1
+
+# MD013/line-length : Line length : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md013.md
+MD013: false
+  # Number of characters
+#  line_length: 200
+  # Number of characters for headings
+#  heading_line_length: 200
+  # Number of characters for code blocks
+#  code_block_line_length: 200
+  # Include code blocks
+#  code_blocks: true
+  # Include tables
+#  tables: true
+  # Include headings
+#  headings: true
+  # Strict length checking
+#  strict: false
+  # Stern length checking
+#  stern: false
+
+# MD014/commands-show-output : Dollar signs used before commands without showing output : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md014.md
+MD014: true
+
+# MD018/no-missing-space-atx : No space after hash on atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md018.md
+MD018: true
+
+# MD019/no-multiple-space-atx : Multiple spaces after hash on atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md019.md
+MD019: true
+
+# MD020/no-missing-space-closed-atx : No space inside hashes on closed atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md020.md
+MD020: true
+
+# MD021/no-multiple-space-closed-atx : Multiple spaces inside hashes on closed atx style heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md021.md
+MD021: true
+
+# MD022/blanks-around-headings : Headings should be surrounded by blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md022.md
+MD022:
+  # Blank lines above heading
+  lines_above: 1
+  # Blank lines below heading
+  lines_below: 1
+
+# MD023/heading-start-left : Headings must start at the beginning of the line : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md023.md
+MD023: true
+
+# MD024/no-duplicate-heading : Multiple headings with the same content : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md024.md
+MD024: false
+
+# MD025/single-title/single-h1 : Multiple top-level headings in the same document : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md025.md
+MD025: false
+  # Heading level
+#  level: 1
+  # RegExp for matching title in front matter
+#  front_matter_title: "^\\s*title\\s*[:=]"
+
+# MD026/no-trailing-punctuation : Trailing punctuation in heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md026.md
+MD026:
+  # Punctuation characters
+  punctuation: ".,;:!。，；：！"
+
+# MD027/no-multiple-space-blockquote : Multiple spaces after blockquote symbol : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md027.md
+MD027: true
+
+# MD028/no-blanks-blockquote : Blank line inside blockquote : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md028.md
+MD028: true
+
+# MD029/ol-prefix : Ordered list item prefix : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md029.md
+MD029: false
+  # List style
+#  style: "one_or_ordered"
+
+# MD030/list-marker-space : Spaces after list markers : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md030.md
+MD030:
+  # Spaces for single-line unordered list items
+  ul_single: 1
+  # Spaces for single-line ordered list items
+  ol_single: 1
+  # Spaces for multi-line unordered list items
+  ul_multi: 1
+  # Spaces for multi-line ordered list items
+  ol_multi: 1
+
+# MD031/blanks-around-fences : Fenced code blocks should be surrounded by blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md031.md
+MD031:
+  # Include list items
+  list_items: true
+
+# MD032/blanks-around-lists : Lists should be surrounded by blank lines : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md032.md
+MD032: true
+
+# MD033/no-inline-html : Inline HTML : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md033.md
+MD033:
+  # Allowed elements
+  allowed_elements: [details, summary, strong, code, pre, img]
+
+# MD034/no-bare-urls : Bare URL used : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md034.md
+MD034: true
+
+# MD035/hr-style : Horizontal rule style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md035.md
+MD035:
+  # Horizontal rule style
+  style: "consistent"
+
+# MD036/no-emphasis-as-heading : Emphasis used instead of a heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md036.md
+MD036: false
+  # Punctuation characters
+# punctuation: ".,;:!?。，；：！？"
+
+# MD037/no-space-in-emphasis : Spaces inside emphasis markers : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md037.md
+MD037: true
+
+# MD038/no-space-in-code : Spaces inside code span elements : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md038.md
+MD038: true
+
+# MD039/no-space-in-links : Spaces inside link text : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md039.md
+MD039: true
+
+# MD040/fenced-code-language : Fenced code blocks should have a language specified : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md040.md
+MD040: false
+  # List of languages
+#  allowed_languages: []
+  # Require language only
+#  language_only: false
+
+# MD041/first-line-heading/first-line-h1 : First line in a file should be a top-level heading : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md041.md
+MD041: false
+  # Heading level
+#  level: 1
+  # RegExp for matching title in front matter
+#  front_matter_title: "^\\s*title\\s*[:=]"
+
+# MD042/no-empty-links : No empty links : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md042.md
+MD042: true
+
+# MD043/required-headings : Required heading structure : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md043.md
+MD043: false
+
+# MD044/proper-names : Proper names should have the correct capitalization : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md044.md
+MD044: false
+
+# MD045/no-alt-text : Images should have alternate text (alt text) : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md045.md
+MD045: false
+
+# MD046/code-block-style : Code block style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md046.md
+MD046:
+  # Block style
+  style: "consistent"
+
+# MD047/single-trailing-newline : Files should end with a single newline character : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md047.md
+MD047: true
+
+# MD048/code-fence-style : Code fence style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md048.md
+MD048:
+  # Code fence style
+  style: "consistent"
+
+# MD049/emphasis-style : Emphasis style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md049.md
+MD049:
+  # Emphasis style
+  style: "consistent"
+
+# MD050/strong-style : Strong style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md050.md
+MD050:
+  # Strong style
+  style: "consistent"
+
+# MD051/link-fragments : Link fragments should be valid : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md051.md
+MD051: true
+
+# MD052/reference-links-images : Reference links and images should use a label that is defined : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md052.md
+MD052:
+  # Include shortcut syntax
+  shortcut_syntax: false
+
+# MD053/link-image-reference-definitions : Link and image reference definitions should be needed : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md053.md
+MD053:
+  # Ignored definitions
+  ignored_definitions:
+    - "//"
+
+# MD054/link-image-style : Link and image style : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md054.md
+MD054:
+  # Allow autolinks
+  autolink: true
+  # Allow inline links and images
+  inline: true
+  # Allow full reference links and images
+  full: true
+  # Allow collapsed reference links and images
+  collapsed: true
+  # Allow shortcut reference links and images
+  shortcut: true
+  # Allow URLs as inline links
+  url_inline: true
diff --git a/docs/ipc/validator-gater.md b/docs/ipc/validator-gater.md
index 2de5b3ecb1..2f8c59c5ed 100644
--- a/docs/ipc/validator-gater.md
+++ b/docs/ipc/validator-gater.md
@@ -102,7 +102,3 @@ After implementing the gater contract, deploy it to the network. Then, during su
 ### 3. Enforcing Validator Actions
 
 Once the gater contract is set, it will automatically intercept validator-related actions and enforce the rules defined within the contract. This gives the subnet creator full control over who can participate and how the network is governed.
-
-### 4. Example Implementation
-
-Please see an example implementation [here]().
diff --git a/specs/drafts/observability.md b/specs/drafts/observability.md
index da321a9e77..10c8a53416 100644
--- a/specs/drafts/observability.md
+++ b/specs/drafts/observability.md
@@ -52,7 +52,6 @@ Once we capture the trace object (hopefully with negligible overhead), and we en
 | x    |           |                |                                    |                                                                                                                | ipc_exec_fvm_apply_execution_time_secs (histogram)                           |
 | x    |           |                |                                    |                                                                                                                | ipc_exec_fvm_call_execution_time_secs (histogram)                            |
 | x    | Tracing   | Errors         | Error while processing tracing     | TracingError{affected_event, reason}                                                                           | ipc_tracing_errors{event} (counter)                                          |
-|      |
 
 ## Fine-grained VM metrics
 

From cf732ba78f6569ba014befa24761661b0c9f671d Mon Sep 17 00:00:00 2001
From: Bernhard Schuster 
Date: Thu, 13 Feb 2025 17:59:27 +0100
Subject: [PATCH 3/5] prettier lints are wrong

---
 contracts/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/contracts/Makefile b/contracts/Makefile
index 0518f9241d..04c33bb5ff 100644
--- a/contracts/Makefile
+++ b/contracts/Makefile
@@ -101,7 +101,7 @@ lint: fmt
 
 fmt:
 	pnpm install --silent --no-save
-	pnpm exec prettier --check -w 'contracts/**/**/*.sol' 'sdk/**/**/*.sol' 'test/**/**/*.sol' 'test/**/**/*.t.sol' '**/*.{js,jsx,ts,tsx,json,css,md}'
+	pnpm exec prettier --check -w 'contracts/**/**/*.sol' 'sdk/**/**/*.sol' 'test/**/**/*.sol' 'test/**/**/*.t.sol' '**/*.{js,jsx,ts,tsx,json,css}'
 
 deps: node_modules
 

From 20e13a1ddb1fd4ebbeb7304248b9d0ad87f93798 Mon Sep 17 00:00:00 2001
From: Bernhard Schuster 
Date: Thu, 13 Feb 2025 18:02:18 +0100
Subject: [PATCH 4/5] version delta lcoal vs CI

---
 .markdownlint.yaml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.markdownlint.yaml b/.markdownlint.yaml
index 056ef0aaa9..4626687884 100644
--- a/.markdownlint.yaml
+++ b/.markdownlint.yaml
@@ -149,7 +149,7 @@ MD032: true
 # MD033/no-inline-html : Inline HTML : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md033.md
 MD033:
   # Allowed elements
-  allowed_elements: [details, summary, strong, code, pre, img]
+  allowed_elements: [details, summary, strong, code, pre, img, aside]
 
 # MD034/no-bare-urls : Bare URL used : https://github.com/DavidAnson/markdownlint/blob/v0.32.1/doc/md034.md
 MD034: true

From afe72970fbc55724d438cfc1dae058efda772ded Mon Sep 17 00:00:00 2001
From: Bernhard Schuster 
Date: Thu, 13 Feb 2025 18:04:10 +0100
Subject: [PATCH 5/5] simplify, there might be otehr reasons for a git delta

I.e. fix is not coherent with jsut checking
---
 .github/workflows/commonmark-lint.yaml | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/.github/workflows/commonmark-lint.yaml b/.github/workflows/commonmark-lint.yaml
index ae6e316f9b..81779765e7 100644
--- a/.github/workflows/commonmark-lint.yaml
+++ b/.github/workflows/commonmark-lint.yaml
@@ -7,19 +7,13 @@ on:
 jobs:
   lint-commonmark:
     runs-on: ubuntu-latest
-    continue-on-error: true
     steps:
     - name: Check out the project
       uses: actions/checkout@v4
 
     - name: Lint all commonmark/markdown files
       uses: DavidAnson/markdownlint-cli2-action@v19
-      continue-on-error: true
       with:
         fix: true
         globs: '(scripts|crates)/**/README.md;contracts/specs/**/*.md;specs/**/*.md;docs/**/*.md'
-        separator: ';'
-
-    - name: Check compliance
-      run: |
-        git diff --exit-code
+        separator: ';'
\ No newline at end of file