tornadocontrib/docs
1
0
Fork 0
forked from tornadocash/docs
Code Pull Requests Activity

change back naming

Browse Source 
Signed-off-by: AlienTornadosaurusHex <>
This commit is contained in:
AlienTornadosaurusHex 2023-06-08 19:53:18 +00:00
parent ae22f7450a
commit f80f0cf0cd
2 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
SUMMARY.md
View File

@ -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

2
general/token/locking.md → general/token/staking.md
View File

@ -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.