Staking

The GET Protocol staking system has been designed to align incentives of ecosystem participants, providing a governance-compatible token lockup mechanism while offering rewards on deposits. Depositing your GET into the staking vault acts as a commitment to the long-term vision of the protocol and is rewarded with governance rights and staking rewards.

This system has been designed to a number of principals:

• Composability. The smart contract implements the ERC-4626 Tokenized Vault Standard and issues an ERC-20 share token (xGET) representing vault deposits and accrued rewards.
• Rewards. The staking vault is able to act as the primary destination for revenue-driven rewards across multiple products and future revenue streams.
• Governance. A lockup mechanism ensures that governance votes are driven by long-term participants in the GET Protocol ecosystem.
• Flexibility. Instant withdrawals are available subject to a percentage fee set by the DAO. This fee is distributed amongst remaining depositors.

xGET

The xGET share token is issued to track individual GET balances held within the staking vault and is transferrable. Upon depositing GET into the vault you will be returned with an amount of xGET that represents your underlying assets at the time of deposit. The GET deposited will remain in the vault until withdrawal.

• Upon deposit GET is transferred to the staking vault and xGET is minted to the depositor.
• Upon withdrawal xGET is burned and GET is returned to the depositor.

Once deposited, this GET will be owned by the vault until withdrawal and cannot be transferred or traded.

Rewards

📘

All rewards provided from protocol revenue are not guaranteed and may be halted at any time.

xGET follows the xToken model and can only accrue value against the underlying asset, in this case GET. This is known as a yield-bearing asset.

Or in more plain terms; xGET will always be redeemable for the same amount or more GET than deposited, never less, because xGET would be equal to assetsDeposited + assetsRewarded. Therefore xGET is a share token that represents the underlying assets in the vault where there are only two ways for GET to enter; deposited by a staker, or transferred to the vault as rewards.

Reward Period

A linear reward issuance mechanism is applied to prevent depositors attempting to enter at favourable times when large rewards are deposited into the contract and gaining an unfair advantage. The linear release mechanism releases rewards on every block to smooth this distribution across a time period, for xGET this is set to 2 weeks.

Reward Sources

The staking system currently aggregates four sources of rewards that are regularly distributed:

• A percentage of Ticketing Fees from fuel usage is redeemable as staking rewards upon each ticket check-in or invalidation. This can create streaming rewards to stakers driven by real-world ticketing usage. 100% of UGF funded top-ups will go to stakers.
• A percentage of Trading Fees collected by protocol-owned-liquidity will be available as staking rewards. The GET collected fees will be transferred to the staking contract and the ETH/USDC collected fees will compound the position.
• Instant Withdrawal Fees are triggered when a staker withdraws their assets prior to the unlock time. This fee will remain on the contract and be distributed to remaining stakers.
• When a staker wishes to withdraw via a standard withdrawal their shares will be locked within the vault. The staker does not earn rewards during this withdrawal period but the underlying shares still acrrue this value, which is then redistributed to remaining stakers upon cancellation or withdrawal execution. These are known as Redistributed Rewards.

Lockup & Withdrawals

⚠️

All tokens deposited into the vault are subject to time-based or fee-based withdrawal conditions.

Once tokens have been deposited into the staking vault they are subject to one of the following withdrawal conditions:

• A standard withdrawal can be initiated for the current redeemable assets within the vault subject to a maturity period prior to execution (currently 6 months). No fee is applied to the underlying assets after maturity, but can be paid for early execution.
• An instant withdrawal can be executed subject to a percentage fee distributed among remaining depositors within the vault.

This has been designed to ensure that xGET will be compatible with governance participants who are able to demonstrate commitment to a longer-term position in the protocol.

Standard Withdrawals

Standard withdrawals are a two step process:

1. A withdrawal request must first be created, freezing the exchange rate for later execution and reserve xGET.
2. After 26 weeks this withdrawal request will reach maturity and will be able to be executed. This must be acted upon within 4 weeks.
3. If executed prior to the 26 week maturity period then a percentage fee must be paid as a percentage of the time elapsed. If the instant withdrawal fee is 15% and the withdrawal request has been open for 13 weeks, then a 7.5% fee must be paid for execution.

Creating a withdrawal request reserves this balance for withdrawal and the shares (xGET) required for the withdrawal are transferred to the staking contract and held there until cancellation or execution. Multiple withdrawal requests can be created, executed, and cancelled independently.

A withdrawal request can be cancelled at any time, returning the assets (GET) back to the staker's balance at the current rate. Note that when a withdrawal request is created, this will stop accruing rewards and no longer have governance rights, therefore cancelling a withdrawal request will return fewer shares (xGET) than initially created with.

Cancellations can be made any time after withdrawal request cration, the rewards earned by the shares (xGET) held on the staking contract will be redistributed to all stakers.

👍

Recap

• A standard withdrawal is a two step process beginning with creation of a withdrawal request. This locks the current rate of exchange for later execution & transfers xGET to the staking contract.
• After 26 weeks there will be the option to execute this withdrawal at the fixed rate and will be available for execution for 4 weeks, after which it can only be cancelled. Execution can happen within this time for a fee.
• Cancellations return the reserved GET as xGET at the rate at the time of cancellation.
• GET reserved within a withdrawal request does not earn rewards or have governance voting rights.

Instant Withdrawals

Instant withdrawals are available without a wait period and can be executed in a single transaction.

To execute an instant withdrawal a fee must be paid on the returned assets, which is then shared with the remaining stakers in the vault, boosting their rewards. xGET within a stakers wallet can be instantly withdrawn at any time.

If the staker wishes to withdraw the reserved balance in an existing standard withdrawal request then this request must first be cancelled prior to instant withdrawal.

The percentage fee paid is defined by the instantWithdrawalFee variable and is current set at 15%. Should a staker wish to instantly withdraw 1000 GET then 150 GET would remain on the staking contract.

👍

Recap

• Instant withdrawals are available at any time and are subject to a percentage fee.
• This percentage fee is shared across all remaining stakers in the vault and boost rewards.
• A standard withdrawal request must first be cancelled before it can be instantly withdrawn.

Governance

To ensure that governance voting power is fairly distributed across all chains, voting power is determined by the amount of assets (GET) held within the staking contract rather than the shares (xGET) held within your wallet. Rewards count towards voting power and are available as soon as they are distributed.

The staking contract implements the Compound governance standard as defined within OpenZeppelin's ERC20Votes.sol, supporting vote delegations and snapshots.

As per the OpenZeppelin standard voting power is not automatically given upon deposit and must be activated individual using a call to the delegate function, passing their own address. This makes transfers cheaper as voting is not required to be redelagated upon each transfer.

Example

As rewards are accrued, xGET will increase in price relative to GET since it will be redeemable for the amount of GET deposited plus the rewards earned.

For example:

1. A depositor wishes to enter the vault when xGET is worth 1.1 GET. It can be assumed that there have been 100 GET deposited and 10 GET rewarded with 100 xGET shares issued. This results in 100 xGET outstanding with 110 GET underlying for a rate of 1.1 GET/xGET.
2. This depositor deposits 55 GET at the rate of 1.1 GET/xGET. This issues 50 xGET to the depositor and increases the underlying GET in the vault to 165 GET.
3. An additional 3 GET rewards are transferred to the vault contract increasing the underlying GET from 165 GET to 168 GET with 150 xGET outstanding.
4. The new GET/xGET rate will have increased from 1.1 to 1.12 and a withdrawal request will be eligible to be created for a maximum of 50 xGET shares returning 56 GET for execution after 26 weeks.

The vault contract can only accept deposits or accrue rewards shared across all depositors based on their shares of the vault and therefore the GET/xGET rate can only increase.

Dashboard

👍

Always ensure that you're browsing the correct URL: https://token.get-protocol.io

The token dashboard's staking page is the easiest way to deposit and withdraw your GET into the staking contracts. This front-end application will track rewards and historical deposits and withdrawals using a variety of browser-connected wallets.

Depositing your GET

A first time deposit is a two step process and handled using the deposit tab on the 'Stake' page. Firstly a one-time approval for GET will need to be made to the staking contracts, which allows a deposit to take place.

Secondly a deposit for the amount you wish to stake must be made. Prior to depositing a confirmation step will take place listing the deposit and withdrawal conditions. Ensure you understand this before proceeding with the deposit.

Withdrawing your GET

There are two withdrawal methods available to receive your GET; standard withdrawals and instant withdrawals. Standard withdrawals are subject to a withdrawal period and operate in a two step flow where a withdrawal request is first created and then must be executed at a later date. This is the default flow and will be triggered using the 'Create withdrawal request' button after entering your withdrawal amount.

Should you wish to have instant access to your GET then the 'Immediately execute this withdrawal.' toggle must be selected before using the 'Withdraw instantly' button. In both cases you will be given a confirmation step with the conditions of the withdrawal.

Contracts

⚠️

All smart contracts will be audited by a third party and reasonable steps will be taken to reduce smart contract risk. Loss due to smart contract risk cannot be compensated by GET Protocol.

GET is available on both Polygon and Ethereum and as such the staking contracts will be launched on both networks. Due to small differences in rewards the rate of xGET may not be equivalent on each network and cannot be bridged.

• Polygon: 0x3e49E9C890Cd5B015A18ed76E7A4093f569f1A04
• Ethereum: 0x3e49E9C890Cd5B015A18ed76E7A4093f569f1A04

The vault contract is immutable and cannot be upgraded. The following operational parameters are able to be modified through governance votes:

• instantWithdrawalFee to set the percentage fee paid for instant withdrawals from the vault, default: 15.
• lockTime defines the the length of time before a standard withdrawal request becomes executable, default: 26 weeks.
• withdrawalFeeExemptions to be used to allow other contracts to execute withdrawals without being subject to the instant withdrawal fee, e.g. token migration contracts.

Two protected functions can be called only by the owner:

• setPendingOwner() can be called by the current owner to transfer ownership to a new owner address.
• updateVestingSchedule(uint256 vestingPeriod_) is an owner-protected function that can be used to set a custom-length vesting period.

Historical data has been made available through a dedicated token subgraph and more information is available in the Developer Tooling page.

Audits

On Oct 26th, 2022 the GET Protocol DAO voted to fund yAcademy to audit the GovernanceLockedRevenueDistributionToken and LockedRevenueDistributionToken contracts at v1.0.0 via a Snapshot vote. This has now been completed and the audit report is available for viewing using the links below.