diff --git a/.github/workflows/lint-pr.yaml b/.github/workflows/lint-pr.yaml index eaadf42c8..41376f3e3 100644 --- a/.github/workflows/lint-pr.yaml +++ b/.github/workflows/lint-pr.yaml @@ -1,4 +1,4 @@ -name: "Lint PR" +name: "Lint PR title" on: pull_request: diff --git a/CHANGELOG.md b/CHANGELOG.md index cbf239d63..5e35088f3 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -90,7 +90,7 @@ All notable changes to this project will be documented in this file. ## [axon-r05] - 2024-09-24 -_Full changelog below._ +*Full changelog below.* ### ⭐ HIGHLIGHT | Token-bound validator collateral 🪙🔐 @@ -102,11 +102,11 @@ By decoupling consensus security from the parent token, subnet operators gain gr ### 🚀 Features -- _(contracts)_ Token-bound validator collateral (#1130) +- *(contracts)* Token-bound validator collateral (#1130) ### 🐛 Bug Fixes -- _(topdown)_ Pull effects up until committed finality. (#887) +- *(topdown)* Pull effects up until committed finality. (#887) ### ⚙️ Miscellaneous Tasks @@ -114,7 +114,7 @@ By decoupling consensus security from the parent token, subnet operators gain gr ## [axon-r04] - 2024-09-18 -_Full changelog below._ +*Full changelog below.* ### ⭐ HIGHLIGHT | Validator Gating 🌁🌉 @@ -124,11 +124,11 @@ This feature is designed to support both federated and collateral-based networks ### 🚀 Features -- _(contracts)_ Validator gating (#1127) +- *(contracts)* Validator gating (#1127) ### 📚 Documentation -- _(docs)_ Validator gating docs (#1127) +- *(docs)* Validator gating docs (#1127) ### ⚙️ Miscellaneous Tasks @@ -137,7 +137,7 @@ This feature is designed to support both federated and collateral-based networks ## [axon-r03] - 2024-09-06 -_Full changelog below._ +*Full changelog below.* ### ⭐ HIGHLIGHT | Consistent Genesis 🧬🚀 @@ -145,19 +145,19 @@ The Consistent Genesis feature introduces an additional step of sealing the gene ### 🚀 Features -- _(node)_ Consistent Genesis (#1016) -- _(contracts)_ Improvements to contract deployment scripts (#1108) +- *(node)* Consistent Genesis (#1016) +- *(contracts)* Improvements to contract deployment scripts (#1108) ### 🐛 Bug Fixes -- _(core)_ Set the default Fendermint log level to INFO (#1123) -- _(ci)_ CI speed-up improvements (#1124) +- *(core)* Set the default Fendermint log level to INFO (#1123) +- *(ci)* CI speed-up improvements (#1124) ### 📚 Documentation -- _(docs)_ Moved documentation to monorepo (#1014) -- _(specs)_ Subnet Genesis v2 spec (#1113) -- _(node)_ Updated running docs with Consistent Genesis (#1128) +- *(docs)* Moved documentation to monorepo (#1014) +- *(specs)* Subnet Genesis v2 spec (#1113) +- *(node)* Updated running docs with Consistent Genesis (#1128) ### ⚙️ Miscellaneous Tasks @@ -167,7 +167,7 @@ The Consistent Genesis feature introduces an additional step of sealing the gene ## [axon-r02] - 2024-07-23 -_Full changelog below._ +*Full changelog below.* ### ⭐ HIGHLIGHTED | Observability Framework 👁️📊 @@ -202,23 +202,23 @@ Refer to full observability documentation [here](./docs/fendermint/observability ### 🚀 Features -- _(node)_ New observability architecture + events (#1053) -- _(node)_ New observability bottom up tracing/metrics (#1061) -- _(ethapi)_ Add eth cors settings (#1021) -- _(node)_ File-based observability configuration (#1078) -- _(node)_ Observability docs and changelog section (#1083) +- *(node)* New observability architecture + events (#1053) +- *(node)* New observability bottom up tracing/metrics (#1061) +- *(ethapi)* Add eth cors settings (#1021) +- *(node)* File-based observability configuration (#1078) +- *(node)* Observability docs and changelog section (#1083) ### 🐛 Bug Fixes -- _(ethapi)_ Make `eth_getTransactionReceipt` null for unexecuted/unknown transactions (#1006) +- *(ethapi)* Make `eth_getTransactionReceipt` null for unexecuted/unknown transactions (#1006) ### 🚜 Refactor -- _(node)_ Observability refinements. (#1085) +- *(node)* Observability refinements. (#1085) ### 📚 Documentation -- _(specs)_ Ethereum JSON-RPC API (#913) +- *(specs)* Ethereum JSON-RPC API (#913) ### ⚙️ Miscellaneous Tasks @@ -232,11 +232,11 @@ Hello World! It's early days for IPC. We are starting to enact a proper versioni We introduce the notion of "product generations" to represent the lifetime of IPC under each of these major architectural iterations. Product generations are named alphabetically A-Z (we certainly don't expect more than 26 generations...) We've kept the naming universe deliberately broad: entities/concepts found in biological, mathematical, or computing networks. -The first product generation is called **_Axon_**! +The first product generation is called ***Axon***! ![image](https://github.com/user-attachments/assets/7f9ac874-acdd-49d2-a409-995c55f6bfd4) -Find more background on these choices / implications here: https://github.com/consensus-shipyard/ipc/issues/1012. +Find more background on these choices / implications here: . ### Axon r01 @@ -259,6 +259,6 @@ Axon r01 supports these major features (not a comprehensive list): - Compatibility with the BlockScount explorer and Ethereum wallets out of the box. - ... and a lot more. -### Join the conversation! +### Join the conversation Come ask your questions or give us feedback in the `#ipc` channel on [Filecoin Slack](https://filecoin.io/slack). diff --git a/SECURITY.md b/SECURITY.md index ff7ba2ad9..641c39d52 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -2,4 +2,4 @@ ## Reporting a vulnerability -Please report any security-sensitive issues via ipc@protocol.ai +Please report any security-sensitive issues via diff --git a/contracts/README.md b/contracts/README.md index 42f284c5e..6c8a61ef2 100644 --- a/contracts/README.md +++ b/contracts/README.md @@ -6,9 +6,9 @@ These actors are written in Solidity and target Filecoin’s FEVM. The project accommodates the following main contracts -- `GatewayDiamond.sol`: Implementation of the IPC GatewayActor within the Diamond pattern. -- `SubnetActorDiamond.sol`: Reference implementation of an IPC SubnetActor within the Diamond pattern. -- `SubnetRegistry.sol`: Registry contract for seamlessly deploying subnet actors. +- `GatewayDiamond.sol`: Implementation of the IPC GatewayActor within the Diamond pattern. +- `SubnetActorDiamond.sol`: Reference implementation of an IPC SubnetActor within the Diamond pattern. +- `SubnetRegistry.sol`: Registry contract for seamlessly deploying subnet actors. # Documentation @@ -62,19 +62,20 @@ When you run an upgrade command, the repository's scripts handle several tasks: To upgrade a contract, you may use the following commands. The NETWORK parameter is optional; if not specified, the scripts will default to "auto": -- **Gateway Diamond Upgrade**: +- **Gateway Diamond Upgrade**: ```bash make upgrade-gw-diamond [NETWORK=] ``` -- **Subnet Actor Diamond Upgrade**: +- **Subnet Actor Diamond Upgrade**: ```bash make upgrade-sa-diamond [NETWORK=] ``` -- **Subnet Registry Diamond Upgrade**: +- **Subnet Registry Diamond Upgrade**: + ```bash make upgrade-sr-diamond [NETWORK=] ``` @@ -84,10 +85,10 @@ Check the transaction on the appropriate block explorer to confirm the upgrade's ## Important Notes -- The upgrade commands are intended for use by authorized personnel with a deep understanding of the contracts' functionality. -- Ensure that your local repository is up to date with the latest contract code and JSON files before initiating an upgrade. -- Backup all contract data and thoroughly test any new code in a controlled environment prior to an upgrade. -- Monitor the output of the upgrade process carefully for transaction details and to verify its successful completion. +- The upgrade commands are intended for use by authorized personnel with a deep understanding of the contracts' functionality. +- Ensure that your local repository is up to date with the latest contract code and JSON files before initiating an upgrade. +- Backup all contract data and thoroughly test any new code in a controlled environment prior to an upgrade. +- Monitor the output of the upgrade process carefully for transaction details and to verify its successful completion. # Actors overview diff --git a/contracts/contracts/README.md b/contracts/contracts/README.md index 4f3979992..5a7393103 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 6367deedf..28bb9518e 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 6033184b8..6bdf1fe2d 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/crates/client/README.md b/crates/client/README.md index 64e05d696..cb45f13a6 100644 --- a/crates/client/README.md +++ b/crates/client/README.md @@ -8,7 +8,7 @@ Fendermint is an effort to implement [IPC with Tendermint Core](https://docs.goo ## Quick Start -- [Local testnets](../docs/client/localnet.md) +* [Local testnets](../docs/client/localnet.md) ## Docs @@ -62,7 +62,6 @@ make docker-build See the [docker docs](./docker/README.md) for more details about the build. - ### Pre-built Docker Image The CI build publishes a [Docker image](https://github.com/consensus-shipyard/client/pkgs/container/fendermint) to Github Container Registry upon a successful build on the `main` branch. This is the same image as the one used in the End-to-End tests; it contains the built-in actor bundle and IPC Solidity actors, ready to be deployed during genesis. @@ -84,6 +83,7 @@ The [settings](./app/settings/) contains the configuration options for the `fend The default configuration is in [default.toml](./app/config/default.toml). This file is copied into the `fendermint` docker image and should not be edited, so that any further releases can provide any new keys with default values necessary for the application to start; instead the operator can provide further partial configuration files to override the defaults. The [Settings::config](./app/settings/src/lib.rs) method expects the following files in a configuration directory: + * `default.toml` with the settings for the keys that have meaningful default values * `.toml` is an optional file correponding to the `--mode` CLI option (by default `dev`); these are files that could be checked into Github e.g. to have values for production or test environments * `local.toml` is also optional with potential overrides specific to the developer's machine @@ -95,6 +95,7 @@ An example of this override is the [test.toml](./app/config/test.toml) file whic The location of the configuration directory is determined by [Options::config_dir](./app/options/src/lib.rs) in the following way: The optional `--config-dir` CLI parameter can be used to set it directly. If it's missing, the default is the `config` directory under the `--home-dir` CLI parameter, which by default is `~/.fendermint`. The `FM_CONFIG_DIR` and `FM_HOME_DIR` env vars are also recognised. The `--config-dir` can be used in combination with `--home-dir` and the pre-build docker image to: + 1. set `--home-dir` to a custom mounted volume where the data files can persist 2. set `--config-dir` to `/client/config`, which is where the `runner.Dockerfile` places the `default.toml` file 3. mount any custom config files next to `default.toml` in the container diff --git a/crates/client/docker/README.md b/crates/client/docker/README.md index e65e1af26..9de917b8b 100644 --- a/crates/client/docker/README.md +++ b/crates/client/docker/README.md @@ -6,11 +6,12 @@ The docker image for `fendermint` can be built with the following top-level comm make docker-build ``` -The image contains both the `fendermint` and `ipc-cli` executables (dispatched by [docker-entry.sh](./docker-entry.sh)), as well as all the actor bytecode that needs to be deployed at genesis inside a subnet. In other words, it's a one-stop image for everything IPC. +The image contains both the `fendermint` and `ipc-cli` executables (dispatched by [docker-entry.sh](./docker-entry.sh)), as well as all the actor bytecode that needs to be deployed at genesis inside a subnet. In other words, it's a one-stop image for everything IPC. ## Dependencies As a pre-requisite this will ensure that the following artifacts are prepared: + * The builtin-actors bundle is downloaded from GitHub; if you upgrade the version of these, make sure you clear out any existing artifacts or you might get interface version conflicts at runtime when the bundles are loaded. * The custom actor bundle is built; this prepares some JSON artifacts as well, which are needed for deployment. * The IPC actor contract-bindings are generated; this is refreshed every time a Solidity artifact changes. @@ -21,15 +22,15 @@ The actor bundles are CAR files which are copied into the `fendermint` image, so The full Docker build comprises two stages: the builder stage and the runner stage. -- The builder stage builds Fendermint and ipc-cli. It relies on a heavier base image + dependencies required by the build. -- The runner stage picks the executables and places them on lighter base images satisfying dynamically linked library dependencies. +* The builder stage builds Fendermint and ipc-cli. It relies on a heavier base image + dependencies required by the build. +* The runner stage picks the executables and places them on lighter base images satisfying dynamically linked library dependencies. ## Builder Stage For the builder stage, there are two variants of the `Dockerfile`s one of which is chosen to perform the build depending on the `PROFILE` environment variable. -- `builder.ci.Dockerfile`: used only in CI when `PROFILE=ci`. -- `builder.local.Dockerfile`: used otherwise (e.g. for local builds). +* `builder.ci.Dockerfile`: used only in CI when `PROFILE=ci`. +* `builder.local.Dockerfile`: used otherwise (e.g. for local builds). In both cases the final `Dockerfile` consists of a builder stage variant, joined with the `runner.Dockerfile`. diff --git a/crates/client/eth/api/README.md b/crates/client/eth/api/README.md index bd73db541..c7a91705e 100644 --- a/crates/client/eth/api/README.md +++ b/crates/client/eth/api/README.md @@ -4,4 +4,4 @@ The `fendermint_eth_api` crate implements some of the [Ethereum JSON-RPC](https: The API is tested for basic type lineup during the `make e2e` tests via the [ethers example](./examples/ethers.rs). -The relevant specification is [FIP-55](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0055.md). \ No newline at end of file +The relevant specification is [FIP-55](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0055.md). diff --git a/crates/client/testing/README.md b/crates/client/testing/README.md index 6694a2c72..28620e661 100644 --- a/crates/client/testing/README.md +++ b/crates/client/testing/README.md @@ -6,7 +6,6 @@ The `fendermint_testing` crate (ie. the current directory) provides some reusabl * `arb`: provides `quickcheck::Arbitrary` instances for some things which are problematic in the FVM library, such as `Address` and `TokenAmount`. * `smt`: small framework for State Machine Testing (a.k.a. Model Testing) - # End to end tests Beyond this, for no other reason than code organisation, the directory has sub-projects, which contain actual tests. diff --git a/crates/client/testing/benchmarks/state-size/README.md b/crates/client/testing/benchmarks/state-size/README.md index f24a172a4..540c23389 100644 --- a/crates/client/testing/benchmarks/state-size/README.md +++ b/crates/client/testing/benchmarks/state-size/README.md @@ -3,14 +3,12 @@ The purpose of this benchmark is to establish a baseline for state growth. The idea is to run a simple standalone node and measure the size of the RocksDB data store as the block height goes up. - ## Take measurements Let's use the [materializer](../../materializer/) to start a node. The following commands is assumed to be executed in this directory. - ### Start a node and take measurements ```bash diff --git a/crates/client/testing/graph-test/README.md b/crates/client/testing/graph-test/README.md index 78dc5f54f..b4d9134cf 100644 --- a/crates/client/testing/graph-test/README.md +++ b/crates/client/testing/graph-test/README.md @@ -1,12 +1,13 @@ # Integration test with The Graph ## Run test + ```bash cargo make setup # Start CometBFT, Fendermint and ETH API cargo make test # Run Graph integration test cargo make teardown ``` -This test is derived from: https://docs.hedera.com/hedera/tutorials/smart-contracts/deploy-a-subgraph-using-the-graph-and-json-rpc +This test is derived from: -Reference for docker setup for subgraph: https://github.com/graphprotocol/graph-node/blob/master/docker/README.md +Reference for docker setup for subgraph: diff --git a/crates/client/testing/materializer/README.md b/crates/client/testing/materializer/README.md index 310f8b52d..e4cd22f98 100644 --- a/crates/client/testing/materializer/README.md +++ b/crates/client/testing/materializer/README.md @@ -3,6 +3,7 @@ The `materializer` is a crate to help provision testnets based on a _manifest_, using a backend such as Docker. See the following for more details: + * the [manifest](./src/manifest.rs) format and corresponding [golden files](./golden/manifest) * the [testnet](./src/testnet.rs) that walks the manifests and instructs the materializer to provision resources * the [materializer](./src/materializer.rs) which is the abstract interface that backends need to implement @@ -13,7 +14,6 @@ See the following for more details: ## Usage - ### Validate The following is an example of using the CLI to validate one of the test manifests: @@ -63,6 +63,7 @@ The names contain some hashed part that makes them unique, but with their prefix #### Artifacts As the command indicates we can find the artifacts created by the docker materializer in `./tests/docker-materializer-data`, for example: + * the `materializer-state.json` file contains the mappings from node names to port ranges on the host * the `testnets` directory contains all the testnets, inheriting the names of the manifest they come from * the `testnets//ipc` directory contains the configuration for the `ipc-cli`, namely its `config.toml` and the `evm_keystore.json` @@ -72,7 +73,6 @@ As the command indicates we can find the artifacts created by the docker materia * `testnets//root/subnets//genesis.json` is the Genesis constructed from the parent * `testnets//root/subnets//nodes//static.env` contains environment variables for the node - #### Use `curl` to access the APIs To check whether the APIs are running, we can run some of the following commands on the host machine. @@ -86,11 +86,13 @@ To check what the port mapping is, we can either look at the `docker ps` command ``` Probe CometBFT: + ```bash curl http://localhost:30357/status ``` Probe the Ethereum API: + ```bash curl -X POST \ -H 'Content-Type: application/json' \ @@ -99,11 +101,13 @@ curl -X POST \ ``` Probe Fendermint Prometheus metrics: + ```bash curl http://localhost:30384/metrics ``` The ports get allocated from 30000 onward, 100 range to each node, so the last two digits resemble to internal ports: + * 8045 -> 30x45 * 26657 -> 30x57 * 9184 -> 30x84 @@ -111,10 +115,10 @@ The ports get allocated from 30000 onward, 100 range to each node, so the last t #### Logs For troubleshooting we can look at the logs, either by using `docker logs` and the container name, or for the `fendermint` container we can also access the logs: + * `less testing/materializer/tests/docker-materializer-data/testnets/layer2/root/nodes/brussels/client/logs/fendermint.2024-03-11.log` * `docker logs brussels-fendermint-955632` - #### Env vars The node containers all get same env vars, which are written to the `static.env` and `dynamic.env` files and actuated by the entry point. If something doesn't look right, the files can be inspected, or the parsed configuration printed like this: @@ -124,7 +128,6 @@ The node containers all get same env vars, which are written to the `static.env` I have no name!@london-fendermint-05d823:~$ /opt/docker/docker-entry.sh "fendermint config" /opt/docker/static.env /opt/docker/dynamic.env ``` - ### Teardown The following command removes all containers in the testnet: diff --git a/crates/ipc/types/README.md b/crates/ipc/types/README.md index a884446b9..7fc8716e2 100644 --- a/crates/ipc/types/README.md +++ b/crates/ipc/types/README.md @@ -1,4 +1,5 @@ # primitives -This crate contains the typed primitives useful for fvm implementation. The list of items -include `TAddress`, `TCid`, `TAmt` and `THamt`, corresponding to `Address`, `Cid`, -`Amt` and `Hamt`. \ No newline at end of file + +This crate contains the typed primitives useful for fvm implementation. The list of items +include `TAddress`, `TCid`, `TAmt` and `THamt`, corresponding to `Address`, `Cid`, +`Amt` and `Hamt`. diff --git a/crates/ipld/resolver/docs/README.md b/crates/ipld/resolver/docs/README.md index 4f60b78d1..1432e4026 100644 --- a/crates/ipld/resolver/docs/README.md +++ b/crates/ipld/resolver/docs/README.md @@ -34,10 +34,10 @@ After that, the parent subnet nodes reach out to their associated IPC Agent to r This is just a high level view of what happens during message resolution. In the next section we will delve deeper into the internals of the IPLD Resolver. - ## IPLD Resolver Sub-components The IPLD Resolver uses libp2p to form a Peer-to-Peer network, using the following protocols: + * [Ping](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/ping) * [Identify](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/identify) is used to learn the listening address of the remote peers * [Kademlia](https://github.com/libp2p/rust-libp2p/tree/v0.50.1/protocols/kad) is used for peer discovery @@ -51,6 +51,7 @@ The Resolver is completely agnostic over what content it can resolve, as long as The interface with the host system is through a host-provided implementation of the [BitswapStore](https://github.com/ipfs-rust/libp2p-bitswap/blob/7dd9cececda3e4a8f6e14c200a4b457159d8db33/src/behaviour.rs#L55) which the library uses to retrieve and store content. Implementors can make use of the [missing_blocks](../src/missing_blocks.rs) helper method which recursively collects all CIDs from an IPLD `Blockstore`, starting from the root CID we are looking for. Internally the protocols are wrapped into behaviours that interpret their events and manage their associated state: + * `Discovery` wraps `Kademlia` * `Membership` wraps `Gossipsub` * `Content` wraps `Bitswap` diff --git a/crates/patched_external/frc42_dispatch/README.md b/crates/patched_external/frc42_dispatch/README.md index b8ef38f84..eb7cc213b 100644 --- a/crates/patched_external/frc42_dispatch/README.md +++ b/crates/patched_external/frc42_dispatch/README.md @@ -2,4 +2,4 @@ Helper library to work with [FRC-0042](https://github.com/filecoin-project/FIPs/blob/master/FRCs/frc-0042.md) method hashing -There's an example of it in use [here](https://github.com/helix-onchain/filecoin/tree/main/dispatch_examples/greeter) \ No newline at end of file +There's an example of it in use [here](https://github.com/helix-onchain/filecoin/tree/main/dispatch_examples/greeter) diff --git a/demos/axelar-token/README.md b/demos/axelar-token/README.md index 2cdccf56a..d9d7607b4 100644 --- a/demos/axelar-token/README.md +++ b/demos/axelar-token/README.md @@ -53,15 +53,19 @@ For more information, refer to the [Axelar docs](https://docs.axelar.dev/dev/sen 1. Copy `.env.example` to `.env`. 2. Adjust the parameters, including the origin and destination chains, token addresses (from the Axelar deployment), and private keys. 3. Deploy the handler contract to the destination chain. The script records the address in `out/addresses.json`, and other scripts automatically pick it up from there. + ```bash - $ make deploy-handler + make deploy-handler ``` + 4. Deploy the sender contract to the origin chain. + ```bash - $ make deploy-sender + make deploy-sender ``` + 5. Try it out. This is an interactive command. + ```bash - $ make deposit + make deposit ``` - diff --git a/demos/linked-token/README.md b/demos/linked-token/README.md index 9da7182db..fd3f1acf8 100644 --- a/demos/linked-token/README.md +++ b/demos/linked-token/README.md @@ -13,10 +13,12 @@ All contracts are upgradable via the OpenZeppelin's Upgrade framework, with scri ## Usage To deposit N tokens into the subnet: + - Approve the controller to spend N tokens on the holder's behalf. - Call the `linkedTransfer(address receiver, uint256 amount)` method from an EOA or a contract on the parent. To withdraw N tokens from the subnet: + - Call the `linkedTransfer(address receiver, uint256 amount)` method from the holder EOA or a contract on the subnet. ## Design @@ -52,7 +54,7 @@ A high-level overview of the process is shown in the following diagrams: Transaction dropped from the mempool: 0x563e6ca21d46417020accd05cce992e30f4cb7e69e6b76cc249fea53037bdaa8 ``` - You can search for the transaction on a Filecoin explorer (e.g. Filfox) and find the correct contract address from the other tab under EthAddress: https://calibration.filfox.info/en/message/0x563e6ca21d46417020accd05cce992e30f4cb7e69e6b76cc249fea53037bdaa8?t=4 + You can search for the transaction on a Filecoin explorer (e.g. Filfox) and find the correct contract address from the other tab under EthAddress: 2. Mint 1000 USDCTest tokens to your wallet on the parent. @@ -94,7 +96,6 @@ A high-level overview of the process is shown in the following diagrams: make initialize-controller ``` - ### Depositing tokens into the subnet 1. Approve the Token Controller contract to handle our funds: @@ -129,7 +130,6 @@ A high-level overview of the process is shown in the following diagrams: 0x00000000000000000000000000000000000000000000000000000000000003e8 ``` - ### Withdraw token from the subnet In order to withdraw tokens from the subnet we must ensure we're running a checkpoint relayer with the command. See [this guide](https://docs.ipc.space/quickstarts/deploy-a-subnet) for more info. diff --git a/docs-gitbook/concepts/subnets/parent-child-interactions.md b/docs-gitbook/concepts/subnets/parent-child-interactions.md index ec2357696..8d4ef686b 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 7bed80bf7..b35a4d5a6 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 2ea14ac2d..dd4aa3010 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 e94735cd4..fe6ca2476 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 0fe9223e3..956e72a92 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 df2035365..93d1e1fb5 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 807cff03a..28b6985e7 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 933905f4f..bee996571 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 d0d4b4953..6e28e774a 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 ac6722796..afb576968 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 32cb53825..4eb23f799 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 3e4077105..1f20ec349 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 9c2a63fd5..9ae4f2ffa 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 293946a34..3e2401515 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 082374012..56f65f362 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,41 @@ 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 +82,38 @@ 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 +126,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 ab1d7644b..fe423af61 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 03001e8e1..679f09dd9 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 eabcb2e0a..c3e1a8de4 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 16f3964af..7978572ef 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 58ca907e1..8b178acbd 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 6c2f67279..1e2c3d783 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,6 +27,7 @@ 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.
@@ -57,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 82e3b79bc..ff18ef9a7 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/validator-gater.md b/docs/ipc/validator-gater.md
index 6a5fec930..2de5b3ecb 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/scripts/deploy_subnet_under_calibration_net/README.md b/scripts/deploy_subnet_under_calibration_net/README.md
index 0da252b41..2d7ed518f 100644
--- a/scripts/deploy_subnet_under_calibration_net/README.md
+++ b/scripts/deploy_subnet_under_calibration_net/README.md
@@ -1,9 +1,11 @@
 # Deployment Script
 
 ## Deploy to remote host
+
 We currently have a [Github workflow](https://github.com/consensus-shipyard/ipc/actions/workflows/deploy-to-dedicated-host.yaml) to deploy IPC infra to a dedicated host. You can go to the workflow page and click `Run workflow` button on the top right corner to initiate a deployment.
 
 ## Deploy to local machine
+
 The same `deploy.sh` script can also be used to deploy locally. This is more or less equivalent to following [quickstart-calibration.md](https://github.com/consensus-shipyard/ipc/blob/main/docs/ipc/quickstart-calibration.md), but much more automated.
 
 To run this script locally, you need to first manually prepare the environment and files.
@@ -13,10 +15,12 @@ To run this script locally, you need to first manually prepare the environment a
 3. Run `bash deploy.sh local` to deploy IPC locally.
 
 Please also notice that
+
 1. The `deploy.sh` is only for running on Linux. If you are using a Mac, you need to disable all `apt` based dependency installation. You may also need to install bash (version >= 5) to run this script since the script isn't fully compatible with zsh (default shell on Mac).
 2. The automated dependency installation isn't guarantee to work 100% time. If you encountered any dependency installation issue, please refer to the script and retry. Usually you can resolve the issues by creating a new terminal, sourcing `~/.bash.rc`, etc.
 3. Depends on the RPC endpoint's quality of service for the calibration net, your command may or may not succeed when interacting with the RPC endpoint. Sometimes you will get rate limited. In that case, you can choose a different calibration provider URL from [Chainlist](https://chainlist.org/?search=calibration&testnets=true) to replace the value of `RPC_URL` variable in the script, then retry it.
 4. You need to manually install nodejs and npm. The reason is that we need to use very recent version of nodejs and it's usually not included with the Linux distribution. It's recommended that you use nvm (Node version manager) to manage your nodejs installation.
 
 ## What's the difference between running locally and running in Github workflow?
+
 Github workflow deploys IPC in a dedicated host, whose IP and username are kept using Github secret. Also, the wallet is prepared and the content of `evm_keystore.json` is stored as Github secret. All of these Github secret will be converted into files then will be scp-ed into the dedicated host before running the script.
diff --git a/specs/bottom-up-interaction.md b/specs/bottom-up-interaction.md
index 15e42c7fe..8f0b791d3 100644
--- a/specs/bottom-up-interaction.md
+++ b/specs/bottom-up-interaction.md
@@ -1,4 +1,5 @@
 # Bottom Up Interactions
+
 This document takes a closer look in the IPC mechanics involved in information flowing from the child to the parent subnet, a.k.a. bottom-up.
 
 # Interactions
@@ -63,7 +64,7 @@ The reason we wait for the the change to be committed is so that the transaction
 The signing and sending of transactions happens in the [`broadcast`](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/vm/interpreter/src/fvm/broadcast.rs) module which fetches the current nonce of the validator, estimates the gas, performs retries, etc. Because it fetches the nonce for each submission, it cannot be used in parallel.
 
 
 
 ### **7. Load and deploy actor at genesis**
@@ -330,11 +331,11 @@ The contents of the `genesis.json` file are essentially the `Genesis` structure
 - `accounts` is a list of genesis balances, given by tokens and FVM addresses.
 - `eam_permission_mode` defines who can deploy smart contracts, which could be anyone, or a set of whitelisted addresses.
 - `ipc` is only enabled if we want Fendermint to participate in an IPC hierarchy:
-    - `gateway` defines the parameters of the IPC `Gateway` actor:
-        - `subnet_id` defines the full `SubnetID` from the root
-        - `bottom_up_check_period` is the expected checkpoint frequency for the subnet. It is important that subnet nodes create checkpoints in the ledger at the same heights; doing otherwise would be a consensus failure.
-        - `majority_percentage` is the checkpoint quorum size expressed as a number between 0 and 100; it should be at least 67 to be Byzantine fault tolerant.
-        - `active_validators_limit` is the number of validators who can participate in the subnet consensus; it is important that both the parent and the child subnet agree on this value, so they select the same top validators the same way.
+  - `gateway` defines the parameters of the IPC `Gateway` actor:
+    - `subnet_id` defines the full `SubnetID` from the root
+    - `bottom_up_check_period` is the expected checkpoint frequency for the subnet. It is important that subnet nodes create checkpoints in the ledger at the same heights; doing otherwise would be a consensus failure.
+    - `majority_percentage` is the checkpoint quorum size expressed as a number between 0 and 100; it should be at least 67 to be Byzantine fault tolerant.
+    - `active_validators_limit` is the number of validators who can participate in the subnet consensus; it is important that both the parent and the child subnet agree on this value, so they select the same top validators the same way.
 
 The `genesis.json` file is usually constructed in one of two ways:
 
diff --git a/specs/drafts/contract-redesign.md b/specs/drafts/contract-redesign.md
index f293e10c2..cc6a20ef8 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 1b112b6ea..dcd803578 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 7b0ab1f01..da321a9e7 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.
 
diff --git a/specs/ethapi.md b/specs/ethapi.md
index 5e317dd1c..16730f719 100644
--- a/specs/ethapi.md
+++ b/specs/ethapi.md
@@ -19,10 +19,10 @@ As described above, we can interact with Fendermint through the CometBFT or the
 For the former we can use the [`tendermint-rs`](https://github.com/informalsystems/tendermint-rs/tree/main/rpc) library, which contains a JSON-RPC client. This client forms the basis of our own `[fendermint_rpc](https://github.com/consensus-shipyard/ipc/tree/specs/fendermint/rpc)` crate, which contains the following abstractions:
 
 - `MessageFactory` and `SignedMessageFactory` to produce `ChainMessage` instances to be sent to using the following methods, bound to a particular account address and maintaining a `sequence`:
-    - `transaction` constructs generic `Message` instances using `RawBytes` and `MethodNum`
-    - `transfer` fills in the defaults for just sending tokens between native accounts
-    - `fevm_create` fills in some defaults for deploying EVM bytecode, such as the address of the EAM actor, and takes care of correctly serializing the request
-    - `fevm_invoke` fills in the defaults and serializes the calldata for invoking an EVM smart contract
+  - `transaction` constructs generic `Message` instances using `RawBytes` and `MethodNum`
+  - `transfer` fills in the defaults for just sending tokens between native accounts
+  - `fevm_create` fills in some defaults for deploying EVM bytecode, such as the address of the EAM actor, and takes care of correctly serializing the request
+  - `fevm_invoke` fills in the defaults and serializes the calldata for invoking an EVM smart contract
 - The `[response](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/rpc/src/response.rs)` module has some helper methods for decoding various responses from CometBFT, dealing with idiosyncrasies of Base64 encoding
 - `TxClient` is an interface with methods to actually perform the actions in the `MessageFactory`
 - `QueryClient` is an interface with methods corresponding to the `FvmQuery` variants, taking care of performing the query and decoding the results
diff --git a/specs/executions.md b/specs/executions.md
index ad3a4dbb7..67b10426f 100644
--- a/specs/executions.md
+++ b/specs/executions.md
@@ -114,17 +114,17 @@ Transactions are sent to `check_tx` as bytes, and are passed to the interpreter:
 
 - The `[BytesMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/bytes.rs#L215)` tries to parse the content as IPLD encoded `ChainMessage`
 - The `[ChainMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/chain.rs#L425)` inspects the type of message:
-    - `Signed` messages are forwarded to the inner interpreter
-    - `Ipc` messages are either:
-        - rejected because they are not expected to come from users, instead they would be added to proposed blocks by a validator
-        - validated as relayed bottom-up checkpoints, in which case they bear the signature of the relayer as well as the quorum from the subnet validators
+  - `Signed` messages are forwarded to the inner interpreter
+  - `Ipc` messages are either:
+    - rejected because they are not expected to come from users, instead they would be added to proposed blocks by a validator
+    - validated as relayed bottom-up checkpoints, in which case they bear the signature of the relayer as well as the quorum from the subnet validators
 - The `[SignedMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/signed.rs#L174)` validates the message signature, unless this is a re-check, in which case this has already been done before
 - The `[FvmMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/fvm/check.rs#L25)` checks that:
-    - the `from` exists as an actor
-    - its `balance` is sufficient to cover the `gas_fee_cap * gas_limit`
-    - its `sequence` is matches the one in the `Message`
-    - if the `[exec_in_check](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/app/config/default.toml#L100-L105)` setting is `true` then it also executes the message and checks that the `exit_code` is successful
-    - if all checks are passed then the `balance` and the `sequence` are modified in the state
+  - the `from` exists as an actor
+  - its `balance` is sufficient to cover the `gas_fee_cap * gas_limit`
+  - its `sequence` is matches the one in the `Message`
+  - if the `[exec_in_check](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/app/config/default.toml#L100-L105)` setting is `true` then it also executes the message and checks that the `exit_code` is successful
+  - if all checks are passed then the `balance` and the `sequence` are modified in the state
 
 `exec_in_check` is `true` by default so that we can support running queries against the `pending` state, but this creates a bottleneck in that checks will be blocked by queries acquiring an exclusive lock on the state.
 
@@ -142,8 +142,8 @@ These methods can be used to decide which transactions should appear in blocks.
 
 - The `[BytesMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/bytes.rs#L73)` has a setting whether to pass the messages to the inner interpreter, or only prepend/append new messages returned from it; if it has to pass them then it parses them as `ChainMessage`, otherwise it just encodes the new messages as bytes on the way out. Finally it enforces are limit on the maximum number of messages that can go in a block.
 - The `[ChainMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/chain.rs#L108-L112)` consults background components it was constructed with for IPC related messages that validators can include in a block:
-    - any bottom-up checkpoints for which the CID has been successfully resolved and are ready for execution (not used at the moment)
-    - any parent subnet finality that has received a quorum in the gossiped finality votes, and are ready for execution
+  - any bottom-up checkpoints for which the CID has been successfully resolved and are ready for execution (not used at the moment)
+  - any parent subnet finality that has received a quorum in the gossiped finality votes, and are ready for execution
 
 The extra messages can be appended or prepended to the block, depending on how the interpreters are constructed. Currently it’s set to [prepend mode](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/app/src/cmd/run.rs#L147), so IPC messages take priority, but originally the idea was that we can append them, and if we hit a message size or message number limit, then these will be re-proposed in the next round.
 
@@ -153,8 +153,8 @@ The extra messages can be appended or prepended to the block, depending on how t
 
 - The `[BytesMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/bytes.rs#L127-L128)` parses the transactions and has to make a choice whether to reject blocks that contain transactions which cannot be parsed. The messages successfully parsed are forwarded to the inner interpreter. If the block were rejected then no invalid transaction appears in the final output; on the other hand if they are accepted then the proposing validator could be penalized for including them.
 - The `[ChainMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/chain.rs#L177-L178)` is concerned about whether to vote for the IPC related messages by checking that:
-    - the CID of a checkpoint in `BottomUpExec`  has been resolved (not used at the moment)
-    - the block proposed in `TopDownExec` is final on the parent chain
+  - the CID of a checkpoint in `BottomUpExec`  has been resolved (not used at the moment)
+  - the block proposed in `TopDownExec` is final on the parent chain
 
 Note that even if a particular node votes `Reject`, others can still `Accept` the block, in which case this node has no choice but to try and procure the data from the parent or child subnet, or its peers.
 
@@ -181,9 +181,9 @@ In the sections below we omit the interpreters that simply forward method calls
 `[begin_block](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/app/src/app.rs#L693)` is the method called by CometBFT with the header of a newly finalized block; this is where we can take note of the new `timestamp`, `height` and the `block_hash` . The `App` checks if there is a `halt_height` configured (which facilitates upgrades). If not, it instantiates a new execution state and stores it in the `[exec_state](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/app/src/app.rs#L163-L164)` , which is the instance of `FvmExecState` that gets passed to the interpreters and returned in an altered state.
 
 - The `[FvmMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/fvm/exec.rs#L51)` is the only one that handles `begin`:
-    - Executes any upgrade scheduled for the current height. It is done in `begin` so that we don’t get into a situation where the transactions in the block have to be processed with old rules, and only at the `end` an upgrade is applied. Effectively the whole block is considered to be *after* the upgrade.
-    - Calls the `cron` actor with the current height (CometBFT doesn’t have null rounds, so there is no need for a backfill like in Lotus).
-    - Calls the `chainmetadata` actor with the current height and block hash, so that we can make the history available for the EVM.
+  - Executes any upgrade scheduled for the current height. It is done in `begin` so that we don’t get into a situation where the transactions in the block have to be processed with old rules, and only at the `end` an upgrade is applied. Effectively the whole block is considered to be *after* the upgrade.
+  - Calls the `cron` actor with the current height (CometBFT doesn’t have null rounds, so there is no need for a backfill like in Lotus).
+  - Calls the `chainmetadata` actor with the current height and block hash, so that we can make the history available for the EVM.
 
 ### Deliver
 
@@ -193,10 +193,10 @@ Note that the interpreters have to do the validations that `check_tx` has perfor
 
 - The `[BytesMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/bytes.rs#L177)` parses bytes into `ChainMessage`; if it fails, it could punish the validator for including them in the block.
 - The `[ChainMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/chain.rs#L242)` has more or less to do, depending on whether the message is from a user, or part of IPC:
-    - `Signed` messages are simply forwarded to the inner interpreter
-    - `BottomUpResolve` messages are synhesized into an FVM `Message` and sent to the inner interpreter which should check that the relayed bottom-up checkpoint is legit, and remember to reward the relayer later; then, it schedules the resolution of the CID of the checkpoint contents from the child subnet. This isn’t used at the moment; checkpoints are sent as full-fat transaction payloads instead.
-    - `BottomUpExec` is not yet implemented.
-    - `TopDownExec` signals that a parent subnet finality has been agreed upon by the subnet validators. The execution of it involves updating the ledger, potentially fetching any data not already in the cache, adding validator changes and executing top-down messages, finally updating the syncer and voting subsystem with the newly finalized block identity. Note that the execution of messages happens using the state, rather than forwarding to the interpreter.
+  - `Signed` messages are simply forwarded to the inner interpreter
+  - `BottomUpResolve` messages are synhesized into an FVM `Message` and sent to the inner interpreter which should check that the relayed bottom-up checkpoint is legit, and remember to reward the relayer later; then, it schedules the resolution of the CID of the checkpoint contents from the child subnet. This isn’t used at the moment; checkpoints are sent as full-fat transaction payloads instead.
+  - `BottomUpExec` is not yet implemented.
+  - `TopDownExec` signals that a parent subnet finality has been agreed upon by the subnet validators. The execution of it involves updating the ledger, potentially fetching any data not already in the cache, adding validator changes and executing top-down messages, finally updating the syncer and voting subsystem with the newly finalized block identity. Note that the execution of messages happens using the state, rather than forwarding to the interpreter.
 - The `[SignedMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/signed.rs#L132)` verifies the message signature, using the current chain ID, then forwards the `Message` without the signature.
 - The `[FvmMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/fvm/exec.rs#L147)` simply executes the `Message`.
 
@@ -206,8 +206,8 @@ Note that the interpreters have to do the validations that `check_tx` has perfor
 
 - The `[ChainMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/chain.rs#L395)` first calls the inner interpreter, then inspects the results for any power updates, and if there are some, then it updates the voting subsystem to let it know where to accept votes from. This step is here because the `ChainMessageInterpreter` receives in the `State` input a `[ChainEnv](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/chain.rs#L39-L48)` , which is a collection of components working independently in the background, using Software Transactional Memory to communicate data with the interpreter. These could technically be constructor dependencies for the interpreter, however they are instead managed by the `App` and part of the `State`, given that they are mutated during the execution - it perhaps makes it a bit easier to reason about what can change to consider them part of the state. However, these are not passed to the inner interpreter.
 - The `[FvmMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/specs/fendermint/vm/interpreter/src/fvm/exec.rs#L185)` is responsible for the checkpointing logic:
-    - If the current height is an end of an epoch, or we have enough bottom-up messages to hit a threshold, a checkpoint is created in the ledger and the previously stashed validator changes take effect, and the power updates are added to the output. This is done by all full nodes deterministically.
-    - Then, if the current node is a validator, it kicks off a background process to broadcast transactions that adds its signature to all pending checkpoints.
+  - If the current height is an end of an epoch, or we have enough bottom-up messages to hit a threshold, a checkpoint is created in the ledger and the previously stashed validator changes take effect, and the power updates are added to the output. This is done by all full nodes deterministically.
+  - Then, if the current node is a validator, it kicks off a background process to broadcast transactions that adds its signature to all pending checkpoints.
 
 ### Commit
 
@@ -239,12 +239,12 @@ The ABCI query consist of a `path` and some raw `data` bytes, which are both pas
 
 - The [`BytesMessageInterpreter`](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/bytes.rs#L252) is the only one which looks at the `path`, and if it’s `"/store"`, it interprets the `data` as a CID to be looked up in the blockstore (as per the ABCI specs). If not, it is parsed as an [`FvmQuery`](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/message/src/query.rs#L57)
 - The `[FvmMessageInterpreter](https://github.com/consensus-shipyard/ipc/blob/7af25c4c860f5ab828e8177927a0f8b6b7a7cc74/fendermint/vm/interpreter/src/fvm/query.rs#L46)` is the one executing all queries:
-    - `Ipld` queries are returning raw data from the blockstore
-    - `ActorState` looks up actor by its address and returns the state (which includes the balance and its state root CID)
-    - `Call` executes a transaction in read-only mode
-    - `EstimateGas` also executes a transaction, returning the gas used
-    - `StateParams` returns things like the circulating supply of the subnet
-    - `BuiltinActors` returns the code CID of the various actors
+  - `Ipld` queries are returning raw data from the blockstore
+  - `ActorState` looks up actor by its address and returns the state (which includes the balance and its state root CID)
+  - `Call` executes a transaction in read-only mode
+  - `EstimateGas` also executes a transaction, returning the gas used
+  - `StateParams` returns things like the circulating supply of the subnet
+  - `BuiltinActors` returns the code CID of the various actors