docs/dev/launch-a-live-network.md

 # How to launch a live network
 
-## 1. Choose the currency type
+Launching a new live network is more difficult than spawning a local blockchain. Follow this process if you know what you are doing and you already experimented a bit with local blockchains. Part of this process is automated with Rust scripts, including interaction with GitLab's GraphQL API. Do not hesitate to improve and complete it (see TODOs inside `xtask/**/*.rs` files).
 
-Ensure that the currency type you want has the requirements.
+## Requirements
+
+In order to build in a standardized environment, you need Docker. 
+
+- see docker docs to [install docker](https://docs.docker.com/engine/install/)
+- make sure you can run docker as non-root user with `docker info` or so
+
+## Preparation
+
+When launching a new network, you're likely to use a new runtime. See how to [release a new runtime](./release-new-runtime.md).
+
+### Inject runtime in chainspec
+
+ĞDev runtime is automatically embeded in the raw chainspec with the `include_bytes!` macro. An other way to inject the runtime is to use "inject-runtime-code" xtask:
+
+```bash
+cargo xtask inject-runtime-code --runtime runtime/gdev/target/srtool/release/wbuild/gdev-runtime/gdev_runtime.compact.compressed.wasm --raw-spec resources/gdev-raw.json 
+```
+
+## Bootstraping
+
+### Choose the currency type
 
 For now, only `gdev` is supported.
 
 In the commands that will be indicated afterwards, you will have to replace `CURRENCY` by the
 currency type you have chosen.
 
-## 2. Choose the docker image
+### Choose the docker image
 
-Choose or build the docker image that contains the version of the code thut you want to use.
+Choose the docker image that contains the version of the code that you want to use.
 
 In the commands that will be indicated afterwards, you will have to replace `TAG` by the tag of the
-docker image that you have chosen.
+docker image that you have chosen (example : runtime-400).
 
-## 3. Generate the session keys of genesis authority
+### Generate the session keys of genesis authority
 
 Generate a random secret phrase:
 
 ```bash
-$ docker run --rm -it --entrypoint duniter duniter/duniter-v2s:TAG key generate
+$ docker run --rm duniter/duniter-v2s:TAG -- key generate
 Secret phrase:       noble stay fury mean poverty delay stadium organ evil east vague can
   Secret seed:       0xb39c31fb10c5080721738880c2ea45412cb3df33df022bf8d9a51483b3a9b7a6
   Public key (hex):  0x90a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d62
@@ -35,42 +56,64 @@ Keep this secret phrase **carefully**, it will be used **several** times later.
 Then, generate the session keys:
 
 ```bash
-$ docker run --rm -it --entrypoint duniter duniter/duniter-v2s:TAG key generate-session-keys --chain CURRENCY_local --suri "<your secret phrase>"
+$ docker run --rm duniter/duniter-v2s:TAG -- key generate-session-keys --chain CURRENCY_local --suri "<your secret phrase>"
 Session Keys: 0x87189d723e1b2826c243bc433c718ac26ba60526932216a09102a254d54462b890a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d6290a0c2866034db9d05f8193a95fe5af8d5e12ab295a501c17c95cdbeaf226d62
 ```
 
-## 4. Paste sessions keys in the genesis configuration file
+### Paste sessions keys in the genesis configuration file
 
-An example of genesis configuration file: `resources/gdev.json`
+An example of genesis configuration file: `resources/gdev.json`. Paste your session keys in your `smith` identity with key `session_keys`.
 
-## 5. Generate raw spec
+### Generate raw spec
 
 ```docker
-docker run -v $HOME/dev/duniter-v2s/resources:/var/lib/duniter/resources -e DUNITER_GENESIS_CONFIG=/var/lib/duniter/resources/gdev.json --rm -it --entrypoint duniter duniter/duniter-v2s:TAG build-spec -lerror --chain=gdev-gl --raw > name-raw.json
+docker run -v $HOME/dev/duniter-v2s/resources:/var/lib/duniter/resources -e DUNITER_GENESIS_CONFIG=/var/lib/duniter/resources/gdev.json --rm duniter/duniter-v2s:TAG -- build-spec -lerror --chain=gdev_live --raw > name-raw.json
 ```
 
 ```bash
 ./scripts/gen-live-network-raw-spec.sh CURRENCY "<path/to/your/genesis/config/file>"
 ```
 
-## 6. Generate the docker compose and prepare nodes keys
+This builds the specs using debug version of Duniter.
+
+### Generate the docker compose and prepare nodes keys
 
 ```bash
 ./scripts/create-live-network.sh "<your secret phrase>" CURRENCY "<path/to/dist/folder>"
 ```
 
-The distribution folder can then be copied to a server, then the compose must be launched from the
-root of the distribution folder:
+The new distribution folder can be copied to a server
 
 ```bash
-scp -r -P SSH_PORT "<path/to/dist/folder>" user@ip:/remote/dist/path
-cd "<path/to/dist/folder>"
-docker compose up -d
+scp -r "<path/to/dist/folder>" <server>:/remote/dist/path
 ```
 
-Then, on the server:
+then on the server, launch the compose file from the the distribution folder's root:
 
 ```bash
+ssh <server>
 cd "<path/to/dist/folder>"
 docker compose up -d
 ```
+
+This is the first node of the new live network.
+
+## Finalization
+
+The following steps should be completed once you are satisfied with the new live network.
+
+### Rotate session keys
+
+You should rotate session keys for more secured keys produced on the server (the one you used before are still in your develop machine bash history and clipboard).
+
+### Publish image
+
+With these new session keys in the chainspec and the runtime build with srtool, you can release the new runtime again with: 
+
+```bash
+cargo xtask release-runtime 400
+```
+
+### Tell the other smith
+
+Once you completed all these steps, the other smith can pull the docker image with a genesis containing your bootnode with the correct session keys. They can base their `docker-compose.yml` on the `duniter-validator` template.

docs/dev/pallet_conventions.md

+# Duniter Pallet Conventions
+
+## Call
+
+Custom Duniter pallet calls should adhere to the standard Substrate naming convention:
+
+- `action_` for regular calls (e.g., `create_identity`).
+- `force_action_` for calls with a privileged origin (e.g., `force_set_distance_status`).
+
+## Error
+
+In the event of a call failure, it should trigger a pallet error with a self-explanatory name, for instance, `IdtyNotFound`.
+
+## Event
+
+Successful calls should deposit a system event to notify external entities of the change. The event name should be self-explanatory and structured in the form of a Rust struct with named fields, ensuring clarity in autogenerated documentation. An example is:
+
+```rust
+IdtyRemoved {
+    idty_index: T::IdtyIndex,
+    reason: IdtyRemovalReason<T::IdtyRemovalOtherReason>,
+}
+```
+
+## Hook
+
+Hooks are inherently infallible, and no errors should be emitted within them. To monitor progression from inside the hook, events can be employed to inform external entities about changes or no-changes.
+
+## Internal Function
+
+Internal functions should adhere to the following naming convention:
+
+- `do_action_` for regular functions executing the base logic of a call (e.g., `do_remove_identity_`). These functions should directly emit events and trigger errors as needed.
+- `force_action_` for privileged functions that bypass any checks. This can be useful for specific benchmarking functions.
+- `check_` for functions performing checks and triggering errors in case of failure.

docs/dev/release-new-runtime.md

+# Release a new Runtime
+
+![](img/release-pipeline.png)
+
+> The following instructions have been described in french at: [Créer une release](https://forum.duniter.org/t/industrialiser-le-demarrage-dune-nouvelle-gx/11535/41).
+
+## Process
+
+Example for `runtime-800`.
+
+### New release with new Runtime
+
+* create a `release/runtime-800` branch locally
+* update the values:
+  * update spec version (in `runtime/<currency>/src/lib.rs`)
+  * eventually update `gdev.yml` (smiths, tech. committee, ...)
+* push the `release/runtime-800` branch
+  * in the CI/CD, wait for `Create release` button to be available and click on it (see above screenshot)
+
+The Runtime is now available on the release page [runtime-800](https://git.duniter.org/nodes/rust/duniter-v2s/-/releases/runtime-800).
+
+### New Client
+
+The Client is published as a Docker image.
+
+You may want to publish a new Client version along with a Runtime update.
+
+#### New raw specs (optional)
+
+For a reboot, you will likely want to update the raw specs:
+
+* in the CI/CD, wait for `release_gdev_specs` button to be available and click on it
+* in the CI/CD, wait for `release_gtest_specs` button to be available and click on it
+* wait for both jobs to finish
+* update the Client raw specs with `cargo xtask update-raw-specs runtime-800`
+
+#### New version (mandatory)
+
+Update Client values:
+
+* update Client version (in `Cargo.toml`)
+* update `Cargo.lock` with `cargo build`
+  
+#### Publish Docker image
+
+Commit everything and push the branch:
+
+* in the CI/CD, a new pipeline has been launched
+* you can stop jobs `create_g1_data`, `gdev_srtool`, `gtest_srtool` (won't be used)
+* click on `gdev_docker_deploy` and `gtest_docker_deploy`
+
+The Docker images should now be available at: https://hub.docker.com/r/duniter/duniter-v2s-gdev/tags.
+
+## Runtime tag and spec version
+
+Our runtime tags use `xxyy` version numbers where `x` corresponds to major change and `y` hotfix.
+
+Make sure to move any issue or merge request assigned to the choosen milestone `runtime-xxyy` to the next one. This prevents from forgetting unfinished work.

docs/test/replay-block.md → docs/dev/replay-block.md

 # How to replay a block
 
+WARN: try-runtime is not properly implemented
+
 You can use `try-runtime` subcommand to replay a block against a real state from a live network.
 
 1. Checkout the git tag of the runtime version at the block you want to replay
@@ -9,13 +11,13 @@ You can use `try-runtime` subcommand to replay a block against a real state from
 5. Replay the block a first time to get the state:
 
 ```
-duniter try-runtime --exectuion=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 live -s tmp/snapshot1 -u ws://localhost:9944
+duniter try-runtime --execution=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 live -s tmp/snapshot1 -u ws://localhost:9944
 ```
 
 6. Then, replay the block as many times as you need against your local snapshot:
 
 ```
-duniter try-runtime --exectuion=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 --block-ws-uri ws://localhost:9944 snap -s tmp/snapshot1
+duniter try-runtime --execution=Native execute-block --block-at 0x2633026e3e428b010cfe08d215b6253843a9fe54db28748ca56de37e6a83c644 --block-ws-uri ws://localhost:9944 snap -s tmp/snapshot1
 ```
 
 try-runtime does not allow (for now) to store the block locally, only the storage can be stored.

docs/dev/setup.md

@@ -35,7 +35,7 @@ Use a terminal shell to execute the following commands:
 ```bash
 sudo apt update
 # May prompt for location information
-sudo apt install -y cmake pkg-config libssl-dev git build-essential clang libclang-dev curl
+sudo apt install -y cmake pkg-config libssl-dev git build-essential clang libclang-dev curl protobuf-compiler
 ```
 
 ### Arch Linux
@@ -79,3 +79,16 @@ rustup update nightly
 rustup update stable
 rustup target add wasm32-unknown-unknown --toolchain nightly
 ```
+
+
+### Installing mold linker to decrease build time
+
+Mold (modern linker) (https://github.com/rui314/mold) decreases the build time. Install it through your system package for example then add the following to your `~/.cargo/config`:
+
+```toml
+[target.x86_64-unknown-linux-gnu]
+linker = "clang"
+rustflags = ["-C", "link-arg=-fuse-ld=/usr/bin/mold"]
+```
+
+(see https://forum.duniter.org/t/decrease-duniter-build-time/10170 on the forum)
\ No newline at end of file

docs/dev/upgrade-substrate.md

-# Upgrade Substrate
+# Polkadot Upgrade Guide
 
-We need to keep up to date with Substrate. Here is an empirical guide.
+ParityTech frequently releases upgrades of the polkadot-sdk. For each upgrade, Duniter should be upgraded following the instructions below. These instructions are based on upgrading from version 1.8.0 to 1.9.0.
 
-Let's say for the example that we want to upgrade from `v0.9.26` to `v0.9.32`.
+## 1. Upgrade the duniter-polkadot-sdk
 
-## Upgrade Substrate fork
+* Clone the repository: `git clone git@github.com:duniter/duniter-polkadot-sdk.git`
+* Set the upstream repository: `git remote add upstream git@github.com:paritytech/polkadot-sdk.git`
+* Fetch the latest released version: `git fetch --tag polkadot-v1.9.0`
+* Create a new branch: `git checkout -b duniter-polkadot-v1.9.0`
+* Rebase the branch, keeping only specific commits: "fix treasury benchmarks when no SpendOrigin", "allow manual seal to produce non-empty blocks with BABE", "add custom pallet-balance GenesisConfig", and "remove pallet-balances upgrade_account extrinsic", "remove all paritytech sdk dependencies".
+* Push the new branch: `git push`
 
-TBD (only Élois has done this for now)
+## 2. Upgrade repository
 
-## Upgrade Subxt fork
+* In the `Cargo.toml` file of Duniter, change the version number from 1.8.0 to 1.9.0 for all polkadot-sdk dependencies. Also, change the version for Subxt. `find . -type f -name "Cargo.toml" -exec sed -i'' -e 's/polkadot-v1.8.0\/polkadot-v1.9.0/g' {} +`.
+* Upgrade the version number of all crateio dependencies to ensure compatibility with those used in the polkadot-sdk, see the node template at: [Node Template](https://github.com/paritytech/polkadot-sdk/blob/master/templates/solochain/node/Cargo.toml) (choose the correct branch/tag).
 
-1. Checkout the currently used branch in [our Subxt fork](https://github.com/duniter/subxt), e.g. `duniter-substrate-v0.9.26`
-2. Create a new branch `duniter-substrate-v0.9.32`
-3. Fetch the [upstream repository](https://github.com/paritytech/subxt)
-4. Rebase on an upstream stable branch matching the wanted version
+At this point, two cases may arise:
 
-## Upgrade Duniter
+1. If the upgrade only adds some types and minor changes, add the types in the pallet configuration, replace the offending `WeightInfo`, and delete the corresponding weights files until they can be regenerated.
 
-1. Replace `duniter-substrate-v0.9.26` with `duniter-substrate-v0.9.32` in `Cargo.toml`
-2. Update the `rust-toolchain` file according to [Polkadot release notes](https://github.com/paritytech/polkadot/releases)
-	* Tip: To save storage space on your machine, do `rm target -r` after changing the rust toolchain version and before re-building the project with the new version.
-3. While needed, iterate `cargo check`, `cargo update` and upgrading dependencies to match substrate's dependencies
-4. Fix errors in Duniter code
-	* You may need to check how Polkadot is doing by searching in [their repo](https://github.com/paritytech/polkadot). Luckily, the project structure and Substrate patterns are close enough to ours.
-	* Some errors may happen due to two semver-incompatible versions of a same crate being used. To check this, use `cargo tree -i <crate>`. Update the dependency accordingly, then do `cargo update`.
-5. As always, don't forget to `clippy` once you're done with the errors.
-6. Test benchmarking:  
-	`cargo run --features runtime-benchmarks -- benchmark overhead --chain=dev --execution=wasm --wasm-execution=interpreted-i-know-what-i-do --weight-path=. --warmup=10 --repeat=100`
\ No newline at end of file
+2. If there are many breaking changes, it is recommended to break down the process:
+
+    * Start by correcting errors on individual pallets using `cargo check -p my_pallet` to identify and rectify any errors. Then, test using `cargo test -p my_pallet` and benchmark using `cargo test -p my_pallet --feature runtime-benchmark`.
+    * After correcting all pallets, fix the runtimes using the same approach: check for trait declarations added or removed in each pallet configuration, and use `cargo check -p runtime`, `cargo test -p runtime`, and `cargo test -p runtime --feature runtime-benchmark`.
+    * Repeat this process with the node part, the distance-oracle, all the tests, xtask, and the client.
+    * Conclude the process by executing all benchmarks using the command `scripts/run_all_benchmarks.sh`.
+
+## 4. Troubleshooting
+
+As Duniter may sometimes be the only chain implementing advanced features, such as manual sealing, not many references can be found. However, the following projects may be useful:
+
+* Node template for general up-to-date implementation: [Node Template](https://github.com/paritytech/polkadot-sdk/tree/master/templates)
+* Acala: [Acala](https://github.com/AcalaNetwork/Acala), which also uses manual sealing add a similar node implementation.