36 lines
3.8 KiB
Markdown
36 lines
3.8 KiB
Markdown
# Locking in Governance
|
|
|
|
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.
|
|
|
|
Since the execution of [Proposal #10](https://etherscan.io/address/0xEC2412368be52107Fa549c3fb78DE1e3e6bF18EB#code), the TORN token has gained the ability to offer such an incentive, albeit in a primitive form. Essentially, all frontends include the possibility of selecting relayers which have decided to sign up for a registry. Similarly to validators, relayers must stake TORN (irretrievably) if they would like to be registered in this registry, and this grants them the benefit of appearing on the implementing frontends independent of the person hosting the service.
|
|
|
|
The entire reason why this is done is most importantly the IPFS deployment, which is expected to be the fully censorship resistant, decentralized frontend which should survive in worst case scenarios. In the combination with the former system, the IPFS deployment should not run into relayer sybil issues.
|
|
|
|
The fee mechanism functions by relayers locking a listing amount (currently `2000 TORN`). Everytime a withdrawal is processed the registry fee (currently `0.3%` of the relayer's arbitary fee) is deducted from their locked balance. This fee is then distributed proportionally to tokenholders locked in the user vault contract (through Governance). Relayers must keep a locked balance greater than the minimum balance (`500 TORN` currently) to be marked as an active relayer and be recommended on the frontend.
|
|
|
|
The listing amount, registry fee and minimum balance are all configurable by Governance.
|
|
|
|
### How to lock?
|
|
|
|
First, [connect your wallet to Tornado Cash](../../tornado-cash-classic/how-to-connect-your-wallet.md).
|
|
|
|
As mentioned above, the process to lock TORN tokens has remained unchanged.
|
|
|
|
* To do that click the **`Voting`** button on the navigation bar at the top of the page to be directed to the governance route of the application
|
|
* The governance contract need to be approved in order to allow the transfer of your tokens to the smart contract. To do so, you need to click on the **`Approve`** button
|
|
* Once the approval is confirmed, you can chose the amount of token to lock, then click on **`Lock`**
|
|
* All you have to do after that is to confirm the transaction in your wallet & wait for the confirmation to come through
|
|
|
|
|
|
|
|
### How to claim your locking reward?
|
|
|
|
To do that click the **`Voting`** button on the navigation bar at the top of the page to be directed to the governance route of the application. As soon as you connect your wallet, you will be able to see your staking reward at the top if you have a balance.
|
|
|
|
|
|
|
|
* Click **`Manage`** -> **`Claim`** tab -> **`Claim`** _button._
|
|
|