tornadocash/docs
2
0
Fork 1
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Patch to show locking page #2

Merged
Theo merged 3 commits from :en into en 2023-06-09 00:01:00 +03:00
Conversation 0 Commits 3 Files Changed 2 +3 -1
2 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit f80f0cf0cd - Show all commits

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.