---
# System prepended metadata

title: 'Governance, Staking and Treasury'

---



# Governance, Staking and Treasury

## Governance
**FTHM Governance through veFTHM**

We have chose On-Chain voting since Off-Chain voting is in its infancy.  Many of the new Off-Chain voting tools are not chain agnostic (Cannot be used on XDC).

veFTHM follows the veNomics model.  Ve stands for vote escrow.  Here users lock FTHM and receive intransferable veFTHM tokens in exchange.  Voting rights and staking rewards are granted according to the amount of veFTHM tokens that each user holds.   This is essentially a clone of Curve, Frax and Alpacas governance models.  The locking period can be between a week and four years. The longer the lock, the higher the rewards and voting power.  

**Why use ve tokens?**

* Ve tokens causes positive price pressure on the FTHM token because time locking a token increases the long-term commitment from the holders and reduces circulating supply, removing potential downward price pressure.
* Token locking reduces risk of flash loan attacks on our protocol.  Users cannot allocate funds to themselves if they purchase enough of our vote token using a flashloan.
* A single staking contract can be used for both staking and vote power calculations.
* Protocols wishing to influence our protocol would have to lock many tokens, further reducing circulating supply.


**Governance Flow:**
![](https://i.imgur.com/jvvaCVq.png)


**LifeCycle of a Proposal:**

An entity creating a Proposal must have at least _N_ veFTHM tokens.  This is called the Proposal Threshold and prevents spam creation of proposals.

Once a proposal has been submitted a delay starts.

Delay is set to two days.  The delay allows voters to acquire and lock more FTHM if they wish to have more voting power.  Once the delay period is over, voting weights are finalized for the current proposal.

The voting period is set to two weeks, starting immediately after the end of the delay period.

If veFTHM holders vote in favor of the proposal, the execution of the proposal will go into a timelock of two days.  This gives users the time to exit if they disagree with the proposal and gives us time to veto the proposal if we deem it malicious.

Contracts can have FTHMGovernor as their owner, allowing governance to change permitted parameters.

Treasury controls the release of funds to protocols seeking funding, and Staking controls the calculation of staking rewards and voting power of FTHM users.



```

```

## Staking


![](https://i.imgur.com/zAZpOVg.png)



**Why Lock Tokens for a certain period?**

* Calculation of the number of veFTHM tokens to be released is based upon lock period.
* Tokens locked for a certain period incentivizes people to participate in the project more.

**Why multiple Lock Positions?**

* Helps for flexible staking and flexible lock periods, allowing people to close undesirable positions earlier while retaining others.
* Assists in easier calculation of the number of veFTHM tokens to release

**How Lock Positions work?**
* A staker can create a new lock position with lock period and lock id. Depending upon unlock period and size of the locked position, number of veFTHM tokens will be released. The lock position will start to accumulate rewards for the user.
* If a staker wants to unlock with a lock id, the user will be able to claim the accumulated rewards of the locked position. Note that the stakers cannot unlock before the lock period is over, unless in the case of early withdrawals, where a penalty will be applied.


**Why Aurora's Rewards Distribution?**

* Aurora's rewards distribution perfectly fits our requirement of having multiple protocols distributing rewards. The Aurora staking contract is thoughtfully structured.  It has many features including a weighting function, stream shares, to name a few, that are a perfect fit for our purposes.

**Why Stream Rewards?**

* Incentivizes different protocols to use our FTHM token, by allocating some funding in, FTHM tokens and Stablecoins, to the protocols.  In return they distribute their own tokens back to our community of stakers.



![](https://i.imgur.com/MHuK9HR.png)






**Rewards Technicals**

Stream Shares: Share of rewards, for each protocol that is distributing their reward through our staking contract.

Weighing Function: The amount of stream shares that stakers receive is based on a weighing function, which linearly decreases the amount of shares stakers receive as time passes by.

The user is able to unstake their locked position partially. However, the weighing function will be applied to the remaining position in the same locked position, in turn, decreasing reward shares of the remaining locked position.



**Why decreasing weighing function?**

* The weighing function and its mechanics help incentivize early staking and long term holding.

```

```


## Treasury


Features:

- Multisig wallet holds the funds.
- Held to be distributed to other protocols seeking funding, or updates within our protocol that require funding.
- Penalties from early withdrawl and liquidations are deposited here.


**Why Multisig?**

Although the ultimate goal is decentralisation, control over the funds to be distributed by our protocol is essential.  This is especially true while the protocol is new.

```

```


## Front-End Requirements

Front ends for for the following secitons are required: 
![](https://i.imgur.com/PcyUGvT.png)
