diff --git a/neps/nep-0509.md b/neps/nep-0509.md
index 20ed14b26..fb6e1e0bb 100644
--- a/neps/nep-0509.md
+++ b/neps/nep-0509.md
@@ -532,23 +532,23 @@ The only real alternative that was considered is the original nightshade proposa
 
 ### Positive
 
-- The validator nodes will need to track at most one shard. 
-- The state will be held in memory making the chunk application much faster.
-- The disk space hardware requirement will decrease. The top 100 nodes will need to store at most 2 shards at a time and the remaining nodes will not need to store any shards. 
-- Thanks to the above, in the future, it will be possible to reduce the gas costs and by doing so increase the throughput of the system. 
+* The validator nodes will need to track at most one shard. 
+* The state will be held in memory making the chunk application much faster.
+* The disk space hardware requirement will decrease. The top 100 nodes will need to store at most 2 shards at a time and the remaining nodes will not need to store any shards. 
+* Thanks to the above, in the future, it will be possible to reduce the gas costs and by doing so increase the throughput of the system. 
 
 ### Neutral
 
-- The current approach to resharding will need to be revised to support generating state witness. 
-- The security assumptions will change. The responsibility will be moved from block producers to chunk validators and the security will become probabilistic. 
+* The current approach to resharding will need to be revised to support generating state witness. 
+* The security assumptions will change. The responsibility will be moved from block producers to chunk validators and the security will become probabilistic. 
 
 ### Negative
 
-- The network bandwidth and memory hardware requirements will increase.
-  - The top 100 validators will need to store up to 2 shards in memory and participate in state witness distribution. 
-  - The remaining validators will need to participate in state witness distribution. 
-- Additional limits will be put on the size of transactions, receipts and, more generally, cross shard communication.
-- The dependency on cloud state sync will increase the centralization of the blockchain. This will be resolved separately by the decentralized state sync. 
+* The network bandwidth and memory hardware requirements will increase.
+  * The top 100 validators will need to store up to 2 shards in memory and participate in state witness distribution. 
+  * The remaining validators will need to participate in state witness distribution. 
+* Additional limits will be put on the size of transactions, receipts and, more generally, cross shard communication.
+* The dependency on cloud state sync will increase the centralization of the blockchain. This will be resolved separately by the decentralized state sync. 
 
 ### Backwards Compatibility
 
@@ -558,9 +558,9 @@ The only real alternative that was considered is the original nightshade proposa
 
 [Explain any issues that warrant further discussion. Considerations
 
-- What parts of the design do you expect to resolve through the NEP process before this gets merged?
-- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
-- What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?]
+* What parts of the design do you expect to resolve through the NEP process before this gets merged?
+* What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
+* What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?]
 
 ## Changelog