tcoratger
diff --git a/‎docs/client/chain.md‎
Lines changed: 14 additions & 13 deletions b/‎docs/client/chain.md‎
Lines changed: 14 additions & 13 deletions
diff --git a/‎docs/client/containers.md‎
Lines changed: 5 additions & 0 deletions b/‎docs/client/containers.md‎
Lines changed: 5 additions & 0 deletions
@@ -1,4 +1,5 @@
 # Lean Consensus Experimental Chain
+
 <!-- mdformat-toc start --slug=github --no-anchors --maxlevel=6 --minlevel=2 -->
 
 - [Introduction](#introduction)
@@ -32,15 +33,14 @@ This document specs the behavior and functionality of the lean chain. This is a
 | 0      | minimal consensus | Sep 2025 |
 | 1      | pq signature      | Oct 2025 |
 
-
 ### Devnet 0 Functionality
 
 1. Chain-ing: This is beacon style chaining via `latest_block_header` in state verified against parent hash of the new block. LMD-Ghost (without application of beacon chain style filter block tree)
-2. 3SF mini justification & finalization: Departing from the beacon chain epoch centric processing, the lean chain employs a slightly translated version of the 3SF mini where all validators vote every slot.
-3. Empty signatures: Since we will be moving to post quantum signatures `Devnet1` onwards, `Devnet0` data is generated with zero bytes signatures with no signature verification involved. This means voting is a trusted process where the client creates a vote as per their assigned validators.
-4. No Aggregation: The votes casted in the network are simply consumed and packed without aggregation. Beacon style aggregation will be introduced in the Devnet 2.
-5. Round robin proposals: The proposal assignment process has also been kept simple to just assign the proposals based on a round robin process based on the validator index. This makes proposal also a trusted process where the client proposes a block as per their assigned validators.
-5. Simplified Validators: There is no validator deposit, activation, withdrawal or slashing making the validator lifecycle super simple. Each validator has the weight of `1` and since validators don't even generate signatures, there is no validator tracking in the state. Validators are assigned to the clients based on a config file.
+1. 3SF mini justification & finalization: Departing from the beacon chain epoch centric processing, the lean chain employs a slightly translated version of the 3SF mini where all validators vote every slot.
+1. Empty signatures: Since we will be moving to post quantum signatures `Devnet1` onwards, `Devnet0` data is generated with zero bytes signatures with no signature verification involved. This means voting is a trusted process where the client creates a vote as per their assigned validators.
+1. No Aggregation: The votes casted in the network are simply consumed and packed without aggregation. Beacon style aggregation will be introduced in the Devnet 2.
+1. Round robin proposals: The proposal assignment process has also been kept simple to just assign the proposals based on a round robin process based on the validator index. This makes proposal also a trusted process where the client proposes a block as per their assigned validators.
+1. Simplified Validators: There is no validator deposit, activation, withdrawal or slashing making the validator lifecycle super simple. Each validator has the weight of `1` and since validators don't even generate signatures, there is no validator tracking in the state. Validators are assigned to the clients based on a config file.
 
 ## Configuration
 
@@ -71,10 +71,10 @@ _Note:_ The definitions below are for specification purposes and are not necessa
 Returns a map of `root -> justifications` constructed from the flattened data in
 the state:
 
- - `state.justifications_roots` which is a list of block roots that are under
-   voting consideration
- - `state.justifications_validators` which are flattened list of validator ids
-   which have voted for the respective roots
+- `state.justifications_roots` which is a list of block roots that are under
+  voting consideration
+- `state.justifications_validators` which are flattened list of validator ids
+  which have voted for the respective roots
 
 A client implementation may cache this map on the first construction for performance.
 
@@ -143,10 +143,11 @@ def is_justifiable_slot(finalized_slot: int, candidate: int):
 The genesis for lean devnets especially `Devnet0` is rather simple. This can even be generated by clients locally:
 Let `genesis_state = generate_genesis_state(genesis_time, num_validators)`
 where:
- - `genesis_time` is the configured time for the genesis slot
- - `num_validators` is the configured number of validators to run the chain with
 
- Even though `Devnet0` has no individual validators tracking, there would also be no need for `genesis_validators_root` going further as well because the state and hence state root would already encode the genesis validator's array.
+- `genesis_time` is the configured time for the genesis slot
+- `num_validators` is the configured number of validators to run the chain with
+
+Even though `Devnet0` has no individual validators tracking, there would also be no need for `genesis_validators_root` going further as well because the state and hence state root would already encode the genesis validator's array.
 
 ### Genesis state
 
 
@@ -1,5 +1,6 @@
 <!-- mdformat-toc start --slug=github --no-anchors --maxlevel=6 --minlevel=2 -->
 
+- [Encoding](#encoding)
 - [`Config`](#config)
 - [`Checkpoint`](#checkpoint)
 - [`State`](#state)
@@ -16,6 +17,10 @@
 
 # Containers
 
+## Encoding
+
+The containers for various blockchain consensus objects are primarily SSZ objects. To be more prover friendly, the Poseidon2 hasher will be used for hash tree rooting of these objects. However `devnet0` & `devnet1` continue to use the sha256 hasher.
+
 ## `Config`
 
 ```python