diff --git a/SUMMARY.md b/SUMMARY.md
index 7f13263..4222f1f 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -6,7 +6,7 @@
 * [How does it work?](general/how-does-it-work.md)
 * [TORN](general/token/index.md)
 * [Governance](general/community/governance.md)
-* [Locking](general/token/locking.md)
+* [Staking](general/token/staking.md)
 * [Contributing](general/community/contributing.md)
 
 ## Guides
diff --git a/general/token/locking.md b/general/token/staking.md
similarity index 99%
rename from general/token/locking.md
rename to general/token/staking.md
index eb4dd60..5a76fb0 100644
--- a/general/token/locking.md
+++ b/general/token/staking.md
@@ -1,5 +1,7 @@
 # Locking in Governance
 
+### Why? (See below on how to lock)
+
 All Governance systems converge towards the same pattern of consensus systems based on some form of pluralism-based voting. This is for the reason, that large-scale coordination problems can only be resolved by giving "users" or "nodes" or "validators" (however you want to call it) an incentive to cooperate, and then bind that incentive within a ruleset which ultimately the "users/nodes/validators" will prefer because it encourages the stability of the system which actually supplies them the incentives, meaning that it economically guarantees them future income.
 
 For this reason, since the prime directive of the Governance "community" surrounding Tornado Cash is ensuring protocol and service stability, mechanisms must exist by which Governance can incentivize "users/validators/nodes" to configure a system around the core protocol contracts, which must act as a bridge between them and users wanting to interface with the protocol. Specifically, this is necessary due to the fee dilemma which has been mentioned in the guide for relayers, which states that a third party must be providing ether on the withdrawal side of a run through Tornado.