diff --git a/docs/rfc/003-imports-stabilization.md b/docs/rfc/003-imports-stabilization.md
index 0b85d53105..d089cdbb22 100644
--- a/docs/rfc/003-imports-stabilization.md
+++ b/docs/rfc/003-imports-stabilization.md
@@ -8,7 +8,7 @@ The Aleo Team.
 
 IMPLEMENTED
 
-# Summary
+## Summary
 
 This proposal aims to improve the import management system in Leo programs to
 make program environment more reproducible, predictable and compatible. To achieve
@@ -20,7 +20,7 @@ that we suggest few changes to Leo CLI and Manifest:
 - add "include" and "exclude" parameters for "proving system" and "curve";
 - add a lock file which would store imported dependencies and their relations;
 
-# Motivation
+## Motivation
 
 The current design of imports does not provide any guarantees on what's stored
 in program imports and published with the program to Aleo Package Manager.
@@ -37,9 +37,9 @@ for different proving systems or curves. To make a foundation for these features
 imports need to be managed with include/exclude lists for allowed (compatible)
 proving systems and curves.
 
-# Design
+## Design
 
-## Leo Manifest - target section
+### Leo Manifest - target section
 
 To lay the foundation for the future of the Leo ecosystem and start integrating
 information about programs compatibility we suggest adding two new fields to
@@ -64,7 +64,7 @@ These fields are meant to be used to determine whether imported program is
 compatible to the original when support for different curves and proving systems
 is added.
 
-## Leo Manifest - dependencies
+### Leo Manifest - dependencies
 
 Dependencies section:
 
@@ -79,7 +79,7 @@ package = "package"
 version = "1.0"
 ```
 
-### Parameters description
+#### Parameters description
 
 `name` field sets the name of the dependency in Leo code. That way we allow
 developer to resolve collisions in import names manually. So, for example,
@@ -94,7 +94,7 @@ import sudoku;
 version respectively. They are already used as arguments in `leo add`
 command, so these fields are already understood by the Leo developers.
 
-## Leo CLI
+### Leo CLI
 
 To support updated Manifest new command should be added to Leo CLI.
 
@@ -103,7 +103,7 @@ To support updated Manifest new command should be added to Leo CLI.
 leo fetch
 ```
 
-## Imports Restructurization
+### Imports Restructurization
 
 One of the goals of proposed changes is to allow importing packages with the
 same name but different authors. This has to be solved not only on the
@@ -141,7 +141,7 @@ first-program  => author1-program@0.1.0
 second-program => author2-program2@1.0.4
 ```
 
-## Leo.lock
+### Leo.lock
 
 For imports map to be generated and read by the Leo binary and then by the Leo compiler,
 a lock file needs to be created. Lock file should be generated by the `leo fetch` command,
@@ -179,7 +179,7 @@ passed to the compiler.
 It is important to note that Leo.lock file is created only when a package has dependencies.
 For programs with no dependencies, a lock file is not required and not created.
 
-## Recursive Dependencies
+### Recursive Dependencies
 
 This improvement introduces recursive dependencies. To solve this case preemptively
 Leo CLI needs to check the dependency tree and throw an error when a recursive dependency
@@ -190,7 +190,7 @@ Later this solution can be improved by building a lock file containing all the
 information on program dependencies, and the file itself will have enough data
 to track and prevent recursion.
 
-# Drawbacks
+## Drawbacks
 
 This change might require the update of already published programs on Aleo PM due to
 Leo Manifest change. However it is possible to implement it in a backward-compatible
@@ -198,14 +198,14 @@ way.
 
 It also introduces the danger of having recursive dependencies, this problem is addressed in the Design section above.
 
-# Effect on Ecosystem
+## Effect on Ecosystem
 
 Proposed improvement provides safety inside Leo programs and should not affect
 ecosystem except for the tools which use Leo directly (such as Aleo Studio).
 
 It is possible that some of the proposed features will open new features on Aleo PM.
 
-# Alternatives
+## Alternatives
 
 Another approach to the stated cases is to keep everything as we have now but change
 the way programs are imported and stored and make names unique. Also, current