Fix broken link.

CONTRIBUTING.md

@@ -128,7 +128,7 @@ The Client team actively develops and maintains several dependencies used in Fue
 -   [fuel-merkle](https://github.com/FuelLabs/fuel-vm/tree/master/fuel-merkle)
 -   [fuel-tx](https://github.com/FuelLabs/fuel-vm/tree/master/fuel-tx)
 -   [fuel-asm](https://github.com/FuelLabs/fuel-vm/tree/master/fuel-asm)
--   [fuel-vm](https://github.com/FuelLabs/fuel-vm/master/fuel-vm)
+-   [fuel-vm](https://github.com/FuelLabs/fuel-vm/tree/master/fuel-vm)
 
 ### Linking issues
 

README.md

@@ -138,7 +138,7 @@ ulimit -n 10240
 
 #### Log level
 
-The service relies on the environment variable `RUST_LOG`. For more information, check the [EnvFilter examples](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/struct.EnvFilter.html#examples) crate.
+The service relies on the environment variable `RUST_LOG`. For more information, check the [EnvFilter examples](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#examples) crate.
 
 Human logging can be disabled with the environment variable `HUMAN_LOGGING=false`
 

docs/architecture.md

@@ -42,7 +42,7 @@ The following is intended to be a living document to convey how P&A can and shou
 many of these components remain in flux as our needs change, these ports and flows should be considered as a foundation 
 and structure for future design RFC refinements to build upon, rather than reflect a finalized view dictating how the 
 system should forever be. When applying this design, it's encouraged to take practical and experimental steps to evolve our 
-codebase using the Ports and Adapters (P&A) principals previously summarized to help guide our decision-making based on 
+codebase using the Ports and Adapters (P&A) principles previously summarized to help guide our decision-making based on 
 evidence discovered in the process of implementation and testing.
 
 ## Domains:

docs/fee_calculations.md

@@ -9,7 +9,7 @@ to include an additional cost to op codes that write new data to storage or to
 transactions that add new contracts to the chain.
 
 There are a number of ways we might calculate this value; we have decided to go 
-with a simple calculatoin based on the our target storage growth and working
+with a simple calculatoin based on our target storage growth and working
 backward from there.
 
 #### Pessimistic Estimate
@@ -22,14 +22,14 @@ This gives us this graph:
 | --------------- | --------------- | --------------- | --------------- | ------------- |
 | 500,000,000,000 |      10,000,000 |        31536000 |      **15,855** |    **630.72** |
 
-This is a harsh estimate that isn't taking into the additional base cost of tx
+This is a harsh estimate that isn't taking into account the additional base cost of tx
 execution and the cost of any additional op codes. It is also assuming that 
 all blocks would be maxing out the storage.
 
 #### Generous Estimate
 
-Additionally, this will only apply to our early networks, which won't be long-live.
-This allows us to take a bigger risk on the storage price and increas it over 
+Additionally, this will only apply to our early networks, which won't be long-lived.
+This allows us to take a bigger risk on the storage price and increase it over 
 time to compensate for users adding a lot of data.
 
 All this included, if we re-estimate the yearly storage limit as 5 TB we get:
@@ -56,7 +56,7 @@ blocks_per_year = 365 * 24 * 60 * ~5 = ~2628000
 
 yearly_new_contract_bytes = blocks_per_year * contracts_per_block * max_contract_size = **378,432,000,000**
 
-Which rougly lines up with our pessimistic estimate.
+Which roughly lines up with our pessimistic estimate.
 
 #### Conclusion