diff --git a/README.md b/README.md
index 197937324aab87ad2814e4f6734411b179a79964..f2fe8eb1a705d80b52f0d210fc2434d1fbea2c82 100644
--- a/README.md
+++ b/README.md
@@ -20,35 +20,36 @@ Multiple documentation sources are available depending on the level of detail yo
 
 ### Internal documentation TOC
 
-- [README](./README.md)
+- [README](./README.md) (this file)
   - [Use](#use)
-  - [Test](#test)
   - [Contribute](#contribute)
-  - [Structure](#project-structure)
-- [docker](./docker/) docker-related documentation
-- [docs](./docs/)
-  - [api](./docs/api/)
-    - [manual](./docs/api/manual.md)
+  - [License](#license)
+- [docs](./docs/) internal documentation
+  - [api](./docs/api/) API
+    - [manual](./docs/api/manual.md) manage account and identities
     - [runtime-calls](./docs/api/runtime-calls.md) the calls you can submit through the RPC API
     - [runtime-errors](./docs/api/runtime-errors.md) the errors you can get submitting a call
     - [runtime-events](./docs/api/runtime-events.md) the events you can get submitting a call
-  - [dev](./docs/dev/)
+  - [dev](./docs/dev/) developer documentation
     - [beginner-walkthrough](./docs/dev/beginner-walkthrough.md)
     - [git-conventions](./docs/dev/git-conventions.md)
+    - [pallet_conventions](./docs/dev/pallet_conventions.md)
     - [launch-a-live-network](./docs/dev/launch-a-live-network.md)
     - [setup](./docs/dev/setup.md)
     - [compilation features](./docs/dev/compilation.md)
     - [verify-runtime-code](./docs/dev/verify-runtime-code.md)
     - [weights-benchmarking](./docs/dev/weights-benchmarking.md)
     - [upgrade-substrate](./docs/dev/upgrade-substrate.md)
-  - [test](./docs/test/)
     - [replay-block](./docs/test/replay-block.md)
-  - [user](./docs/user/)
+  - [user](./docs/user/) user documentation
     - [autocompletion](./docs/user/autocompletion.md)
     - [debian installation](./docs/user/installation_debian.md)
-  - [packaging](./docs/packaging/)
-    - [build-for-arm](./docs/packaging/build-for-arm.md)
+    - [distance](./docs/user/distance.md)
+    - [fees](./docs/user/fees.md)
+  - [packaging](./docs/packaging/) packaging
+    - [build-for-arm](./docs/packaging/build-for-arm.md) build for ARM architecture
     - [build-debian](./docs/packaging/build-deb.md) build a native Debian package
+- [docker](./docker/) docker-related documentation
 - [end2end-tests](./end2end-tests/) automated end to end tests written with cucumber
 - [live-tests](./live-tests/) sanity checks to test the storage of a live chain
 
@@ -58,23 +59,23 @@ Multiple documentation sources are available depending on the level of detail yo
 
 The easiest way is to use the docker image.
 
-Minimal command to deploy a **temporary** mirror peer:
+Minimal command to deploy a temporary mirror peer:
 
 ```docker
-docker run -it -p9944:9944 -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s:v0.4.0 --tmp --execution=Wasm
+docker run -it -p9944:9944 -e DUNITER_CHAIN_NAME=gdev duniter/duniter-v2s-gdev-800:latest
 ```
 
-To go further, read [How to deploy a permanent mirror node on ĞDev network](./docs/user/rpc.md).
+To go further, read [How to deploy a permanent mirror node on ĞDev network 🔗](https://duniter.org/wiki/duniter-v2/#run-a-mirror-node).
 
 ### Create your local blockchain
 
 It can be useful to deploy your local blockchain, for instance to have a controlled environment to develop/test an application that interacts with the blockchain.
 
 ```docker
-docker run -it -p9944:9944 duniter/duniter-v2s:v0.4.0 --tmp
+docker run -it -p9944:9944 duniter/duniter-v2s-gdev-800:latest
 ```
 
-Or use the `docker-compose.yml` at the root of this repository.
+Or use the [`docker-compose.yml`](./docker-compose.yml) at the root of this repository.
 
 #### Control when your local blockchain should produce blocks
 
@@ -85,34 +86,9 @@ You can decide when to produce blocks with the cli option `--sealing` which has
 - `--sealing=instant`: produce a block immediately upon receiving a transaction into the transaction pool
 - `--sealing=manual`: produce a block upon receiving an RPC request (method `engine_createBlock`).
 
-### Autocompletion
-
-See [autocompletion](./docs/user/autocompletion.md).
-
-## Test
-
-### Test a specific commit
-
-At each commit on master, an image with the tag `debug-sha-********` is published, where `********`
-corresponds to the first 8 hash characters of the commit.
-
-Usage:
-
-```docker
-docker run -it -p9944:9944 --name duniter-v2s duniter/duniter-v2s:debug-sha-b836f1a6
-```
-
-Then open `https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944` in a browser.
+### Shell autocompletion
 
-Enable detailed logging:
-
-```docker
-docker run -it -p9944:9944 --name duniter-v2s \
-  -e RUST_LOG=debug \
-  -e RUST_BACKTRACE=1 \
-  -lruntime=debug \
-  duniter/duniter-v2s:debug-sha-b836f1a6
-```
+See [autocompletion](./docs/user/autocompletion.md) to generate shell autocompletion for duniter commands.
 
 ## Contribute
 
@@ -139,20 +115,11 @@ cargo build
 Use Rust's native `cargo` command to build and launch the node:
 
 ```sh
-cargo run -- --dev --tmp
+cargo run -- --dev
 ```
 
 This will deploy a local blockchain with test accounts (Alice, Bob, etc) in the genesis.
-
-## Single-Node Development Chain
-
-This command will start the single-node development chain with persistent state:
-
-```bash
-./target/debug/duniter --dev --tmp
-```
-
-Then open `https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944` in a browser.
+Open `https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A9944` to watch and interact with your node.
 
 Start the development chain with detailed logging:
 
@@ -160,138 +127,11 @@ Start the development chain with detailed logging:
 RUST_LOG=debug RUST_BACKTRACE=1 ./target/debug/duniter -lruntime=debug --dev
 ```
 
-## Multi-Node Local Testnet
-
-If you want to see the multi-node consensus algorithm in action, refer to
-[our Start a Private Network tutorial](https://substrate.dev/docs/en/tutorials/start-a-private-network/).
-
-### Purge previous local testnet
-
-```
-./target/debug/duniter purge-chain --base-path /tmp/alice --chain local
-./target/debug/duniter purge-chain --base-path /tmp/bob --chain local
-
-```
-
-### Start Alice's node
-
-```bash
-./target/debug/duniter \
-  --base-path /tmp/alice \
-  --chain local \
-  --alice \
-  --port 30333 \
-  --rpc-port 9944 \
-  --node-key 0000000000000000000000000000000000000000000000000000000000000001 \
-  --validator
-```
+## License
 
-### Start Bob's node
+See [LICENSE](./LICENSE)
 
-```bash
-./target/debug/duniter \
-  --base-path /tmp/bob \
-  --chain local \
-  --bob \
-  --port 30334 \
-  --rpc-port 9945 \
-  --validator \
-  --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/12D3KooWEyoppNCUx8Yx66oV9fJnriXwCcXwDDUA2kj6vnc6iDEp
 ```
-
-## Project Structure
-
-A Substrate project such as this consists of a number of components that are spread across a few
-directories.
-
-### Node
-
-A blockchain node is an application that allows users to participate in a blockchain network.
-Substrate-based blockchain nodes expose a number of capabilities:
-
-- Networking: Substrate nodes use the [`libp2p`](https://libp2p.io/) networking stack to allow the
-  nodes in the network to communicate with one another.
-- Consensus: Blockchains must have a way to come to
-  [consensus](https://substrate.dev/docs/en/knowledgebase/advanced/consensus) on the state of the
-  network. Substrate makes it possible to supply custom consensus engines and also ships with
-  several consensus mechanisms that have been built on top of
-  [Web3 Foundation research](https://research.web3.foundation/en/latest/polkadot/NPoS/index.html).
-- RPC Server: A remote procedure call (RPC) server is used to interact with Substrate nodes.
-
-There are several files in the `node` directory - take special note of the following:
-
-- [`chain_spec.rs`](./node/src/chain_spec.rs): A
-  [chain specification](https://substrate.dev/docs/en/knowledgebase/integrate/chain-spec) is a
-  source code file that defines a Substrate chain's initial (genesis) state. Chain specifications
-  are useful for development and testing, and critical when architecting the launch of a
-  production chain. Take note of the `development_chain_spec` and `testnet_genesis` functions, which
-  are used to define the genesis state for the local development chain configuration. These
-  functions identify some
-  [well-known accounts](https://substrate.dev/docs/en/knowledgebase/integrate/subkey#well-known-keys)
-  and use them to configure the blockchain's initial state.
-- [`service.rs`](./node/src/service.rs): This file defines the node implementation. Take note of
-  the libraries that this file imports and the names of the functions it invokes. In particular,
-  there are references to consensus-related topics, such as the
-  [longest chain rule](https://substrate.dev/docs/en/knowledgebase/advanced/consensus#longest-chain-rule),
-  the [Babe](https://substrate.dev/docs/en/knowledgebase/advanced/consensus#babe) block authoring
-  mechanism and the
-  [GRANDPA](https://substrate.dev/docs/en/knowledgebase/advanced/consensus#grandpa) finality
-  gadget.
-
-After the node has been [built](#build), refer to the embedded documentation to learn more about the
-capabilities and configuration parameters that it exposes:
-
-```shell
-./target/debug/duniter --help
-```
-
-### Runtime
-
-In Substrate, the terms
-"[runtime](https://substrate.dev/docs/en/knowledgebase/getting-started/glossary#runtime)" and
-"[state transition function](https://substrate.dev/docs/en/knowledgebase/getting-started/glossary#stf-state-transition-function)"
-are analogous - they refer to the core logic of the blockchain that is responsible for validating
-blocks and executing the state changes they define. The Substrate project in this repository uses
-the [FRAME](https://substrate.dev/docs/en/knowledgebase/runtime/frame) framework to construct a
-blockchain runtime. FRAME allows runtime developers to declare domain-specific logic in modules
-called "pallets". At the heart of FRAME is a helpful
-[macro language](https://substrate.dev/docs/en/knowledgebase/runtime/macros) that makes it easy to
-create pallets and flexibly compose them to create blockchains that can address
-[a variety of needs](https://www.substrate.io/substrate-users/).
-
-Review the [FRAME runtime implementation](./runtime/src/lib.rs) included in this template and note
-the following:
-
-- This file configures several pallets to include in the runtime. Each pallet configuration is
-  defined by a code block that begins with `impl $PALLET_NAME::Config for Runtime`.
-- The pallets are composed into a single runtime by way of the
-  [`construct_runtime!`](https://crates.parity.io/frame_support/macro.construct_runtime.html)
-  macro, which is part of the core
-  [FRAME Support](https://substrate.dev/docs/en/knowledgebase/runtime/frame#support-library)
-  library.
-
-### Pallets
-
-The runtime in this project is constructed using many FRAME pallets that ship with the
-[core Substrate repository](https://github.com/paritytech/substrate/tree/master/frame) and a
-template pallet that is [defined in the `pallets`](./pallets/template/src/lib.rs) directory.
-
-A FRAME pallet is compromised of a number of blockchain primitives:
-
-- Storage: FRAME defines a rich set of powerful
-  [storage abstractions](https://substrate.dev/docs/en/knowledgebase/runtime/storage) that makes
-  it easy to use Substrate's efficient key-value database to manage the evolving state of a
-  blockchain.
-- Dispatchables: FRAME pallets define special types of functions that can be invoked (dispatched)
-  from outside of the runtime in order to update its state.
-- Events: Substrate uses [events](https://substrate.dev/docs/en/knowledgebase/runtime/events) to
-  notify users of important changes in the runtime.
-- Errors: When a dispatchable fails, it returns an error.
-- Config: The `Config` configuration interface is used to define the types and parameters upon
-  which a FRAME pallet depends.
-
-## License
-
 CopyLeft 2021-2023 Axiom-Team
 
 Some parts borrowed from Polkadot (Parity Technologies (UK) Ltd.)
@@ -307,3 +147,4 @@ GNU Affero General Public License for more details.
 
 You should have received a copy of the GNU Affero General Public License
 along with Duniter-v2S. If not, see <https://www.gnu.org/licenses/>.
+```
diff --git a/docker-compose.yml b/docker-compose.yml
index 85dac1986254ae50a35fd08e9e303dcd59edf593..699e3920a09102e4fb0f52e7145a60a4b5569c4a 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -5,7 +5,7 @@ services:
     container_name: duniter-v2s-mirror
     # the image tells which network you are connecting to
     # here it is gdev network
-    image: duniter/duniter-v2s-gdev:latest
+    image: duniter/duniter-v2s-gdev-800:latest
     ports:
       # prometheus telemetry to monitor resource use
       - 9615:9615
diff --git a/docker/compose/docker-compose.smith.yml b/docker/compose/docker-compose.smith.yml
index cf36c98ed0cd71ba368011871b9750592a31e0e8..fc1a48fe3e1901f8ba69e61be9d2e4b0c1a59a36 100644
--- a/docker/compose/docker-compose.smith.yml
+++ b/docker/compose/docker-compose.smith.yml
@@ -4,7 +4,7 @@ services:
   # duniter smith node
   duniter-v2s-smith:
     container_name: duniter-v2s-smith
-    image: duniter/duniter-v2s-gdev:latest
+    image: duniter/duniter-v2s-gdev-800:latest
     ports:
       # RPC API of a smith node should not be exposed publicly!
       - 127.0.0.1:9944:9944
diff --git a/docs/api/manual.md b/docs/api/manual.md
index 0b9a91eb7f77a347a0379ee6e4515435460db990..a43b76b1c5679adf47e1e53a057cef9e0bdc0101 100644
--- a/docs/api/manual.md
+++ b/docs/api/manual.md
@@ -3,7 +3,7 @@
 This functional documentation presents how wallets can interact with the blockchain.
 It is intended to complete the [runtime calls documentation](./runtime-calls.md) in a runtime-specific way to fit the real needs of wallet developers.
 
-Only ĞDev is covered for now.
+NOTE : a more detailed doc is available at <https://duniter.org/wiki/duniter-v2/doc/>
 
 ## Notations
 
@@ -11,26 +11,27 @@ Only ĞDev is covered for now.
 
 ## Account existence
 
-An account exists if and only if it contains at least the existential deposit (2 ĞD).
+An account exists if and only if it contains at least the existential deposit (`balances.existentialDeposit` = 1 ĞD).
 
 ## Become member
 
-Only use `identity` pallet. The `membership` calls are disabled.
+Only use `identity` pallet.
 
 1. The account that wants to gain membership needs to exists.
 1. Any account that already has membership and respects the identity creation period can create an identity for another account, using `identity.createIdentity`.
-1. The account has to confirm its identity with a name, using `identity.confirmIdentity`. The name must be ASCII alphanumeric, punctuation or space characters: ``/^[-!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~a-zA-Z0-9 ]{3,64}$/`` (additionally, trailing spaces and double spaces are forbidden, as a phishing countermeasure). If the name is already used, the call will fail.
+1. The account has to confirm its identity with a name, using `identity.confirmIdentity`. The name must be ASCII alphanumeric, punctuation or space characters: `` /^[-!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~a-zA-Z0-9 ]{3,64}$/ `` (additionally, trailing spaces and double spaces are forbidden, as a phishing countermeasure). If the name is already used, the call will fail.
 1. 4 different member accounts must certify the account using `cert.addCert`.
-1. The distance evaluation must be requested for the pending identity using `distance.evaluateDistance`.
-1. 3 sessions later, if the distance rule is respected, `identity.validateIdentity` can be called.
+1. The distance evaluation must be requested for the pending identity using `distance.requestDistanceEvaluation`.
+1. 3 distance sessions later, if the distance rule is respected, identity is validated automatically.
 
 ## Change key
 
 A member can request a key change via the `identity.change_onwner_key` call. It needs the following SCALE encoded (see SCALE encoding section below) payload:
-* The new owner key payload prefix (rust definition: `b"icok"`)
-* the genesis block hash. (rust type `[u8; 32]` (`H256`))
-* The identity index (rust type `u64`)
-* The old key (rust type `u64`)
+
+- The new owner key payload prefix (rust definition: `b"icok"`)
+- the genesis block hash. (rust type `[u8; 32]` (`H256`))
+- The identity index (rust type `u64`)
+- The old key (rust type `u64`)
 
 This payload must be signed with the new key.
 
@@ -43,9 +44,10 @@ This feature is useful in case the user has lost their private key since the rev
 ### Generate the revocation payload
 
 The revocation needs this SCALE encoded (see SCALE encoding section below) payload:
-* The revocation payload prefix (rust definition: `b"revo"`)
-* The identity index (rust type `u64`)
-* the genesis block hash. (rust type `[u8; 32]` (`H256`))
+
+- The revocation payload prefix (rust definition: `b"revo"`)
+- The identity index (rust type `u64`)
+- the genesis block hash. (rust type `[u8; 32]` (`H256`))
 
 This payload must be signed with the corresponding revocation key.
 
diff --git a/docs/test/replay-block.md b/docs/dev/replay-block.md
similarity index 95%
rename from docs/test/replay-block.md
rename to docs/dev/replay-block.md
index 1db20cd3cd0d22b3c74647aa7dab5e85fae5f437..429e0becb39440d8ee9721bae49552e086e57219 100644
--- a/docs/test/replay-block.md
+++ b/docs/dev/replay-block.md
@@ -1,5 +1,7 @@
 # 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