diff --git a/docs/dev/weights-benchmarking.md b/docs/dev/weights-benchmarking.md
index 1428a4015c3c3d7d581096354a42f001ad108ba6..2b7640c2a836d8603f26402e5df968fb8f9045f0 100644
--- a/docs/dev/weights-benchmarking.md
+++ b/docs/dev/weights-benchmarking.md
@@ -70,3 +70,22 @@ duniter benchmark storage -d=/mnt/ssd1/duniter-v2s/t1 --chain=gdev --mul=2 --wei
 
 4. Copy the generated file `paritydb_weights.rs` in the codebase in folder `runtime/common/src/weights/`.
 5. Commit changes and open an MR.
+
+
+## How to Write Benchmarks
+
+### Calls
+
+Ensure that any extrinsic call is benchmarked using the most computationally intensive path, i.e., the worst-case scenario.
+
+### Hooks
+
+Benchmark each hook to determine the weight consumed by it; hence, it is essential to benchmark all possible paths.
+
+### Handlers and Internal Functions
+
+When designing handlers and internal functions, it is advisable to avoid having them return weight for the following reasons:
+
+1. **Simplified Benchmarking**: Writing benchmarks for hooks or calls where handlers and internal functions are utilized becomes more straightforward.
+2. **Reduced Benchmarking Complexity**: By directly measuring execution and overhead in a single pass, the number of benchmarks is minimized.
+3. **Enhanced Readability**: Understanding that weight accounting occurs at the outermost level improves the overall readability of the code.