diff --git a/part1.md b/part1.md
index ad6b562..72af67f 100644
--- a/part1.md
+++ b/part1.md
@@ -419,26 +419,26 @@ their objects later if they are not satisfied with their service.
 
 #### 5.2.2 Virtual Group and Virtual Family
 
-A Virtual Group consists of a primary storage provider and several secondary storage providers. 
-Each object is associated with a virtual group, limiting the range of secondary storage providers for storing object 
-replica data. The number of storage providers in each virtual group is determined by the redundancy policy. 
-E.g If our redundancy policy specifies a full replica and a 4+2 erasure coding (EC) replica tree, so every 
+A Virtual Group consists of a primary storage provider and several secondary storage providers.
+Each object is associated with a virtual group, limiting the range of secondary storage providers for storing object
+replica data. The number of storage providers in each virtual group is determined by the redundancy policy.
+E.g If our redundancy policy specifies a full replica and a 4+2 erasure coding (EC) replica, so every
 virtual group should have one primary sp and six secondary sp.
 
-A Virtual Family consists of several Virtual Groups that share the same primary storage provider. 
-A Virtual Family has limited storage capacity. When the number of Virtual Groups in a Virtual Family reaches its limit, 
+A Virtual Family consists of several Virtual Groups that share the same primary storage provider.
+A Virtual Family has limited storage capacity. When the number of Virtual Groups in a Virtual Family reaches its limit,
 a new Virtual Family needs to be created.
 
 #### 5.2.3 Staking For Storage
 
-Primary SP must stake BNB for the Virtual Group it creates before it can provide storage services. 
-The minimum required staking tokens can be calculated bt the following formula: 
+Primary SP must stake BNB for the Virtual Group it creates before it can provide storage services.
+The minimum required staking tokens can be calculated bt the following formula:
  `storage_staking_price * stored_size.`
 
-Storage providers can choose to pre-stake tokens for future storage if necessary. 
-The excessive staked BNB can be retrieved anytime. 
+Storage providers can choose to pre-stake tokens for future storage if necessary.
+The excessive staked BNB can be retrieved anytime.
 
-If a storage provider force exit, the staking will be slashed as a reward to storage providers who 
+If a storage provider force exit, the staking will be slashed as a reward to storage providers who
 take over the Virtual Group.
 
 #### 5.2.4 Data Redundancy
diff --git a/part3.md b/part3.md
index 40fee43..d5ceb31 100644
--- a/part3.md
+++ b/part3.md
@@ -330,13 +330,14 @@ Data availability challenge will be covered in the later section.
 
 Storage providers can freely decide to exit, but SPs must complete a graceful exit to ensure no users are affected,
 otherwise, part of staked BNB from the SP will be slashed. Below are the key workflows about how SP exit:
+
 - The Storage Provider (SP1), initiates the exit process by submitting a `StorageProviderExit` transaction to the blockchain.
 - The SP1 or its successor SP must then repeatedly call `SwapOut` to remove itself from all Virtual Groups.
-- For the primary SP, the swap-out process occurs at the family level to ensure there are no conflicts with other SPs 
+- For the primary SP, the swap-out process occurs at the family level to ensure there are no conflicts with other SPs
   within the Virtual Group.
 - For secondary SPs, the swap-out happens at the Virtual Group level and must also avoid conflicts with the primary SP.
-- Once the SP1 has successfully completed the swap-out process from all Virtual Groups, it can submit a 
-  `CompleteStorageProviderExit` transaction to retrieve the staked BNB. 
+- Once the SP1 has successfully completed the swap-out process from all Virtual Groups, it can submit a
+  `CompleteStorageProviderExit` transaction to retrieve the staked BNB.
 
 ## 17 Storage MetaData Models