GIGAHDX

[enthusiastmartin]

1. Overview

GIGAHDX is a Liquid Staking Token (LST) for HDX designed to:

1. Provide automatic value accrual — holders benefit from appreciating exchange rate simply by holding GIGAHDX, with no manual claiming required
2. Enable HDX to be used as collateral in the Money Market while continuing to accrue value
3. Maintain voting capabilities for governance participation
4. Offer additional rewards for active governance participants through referenda voting incentives

---

2. Problem Statement

• Current HDX staking has low APR with diminishing incentive for long-term stakers
• Users at 100% claimable rewards have little reason to continue high-conviction participation
• Strong user demand to use HDX as collateral without missing DeFi opportunities
• Need to better align rewards with commitment level

---

3. Configurable Parameters

Key feature: After giga-unstake, there is a cooldown period (~222 days) before HDX can be claimed. This is a major differentiator from classic HDX staking which has no cooldown.

Parameter	Description	Example/Suggested Value
pallet-gigahdx
Cooldown period	Lock duration after giga-unstake before HDX can be claimed	~222 days
Min stake amount	Minimum HDX to stake / minimum to hold after partial unstake	1,000
stHDX asset ID	Asset ID for stHDX token	670
HDX asset ID	Asset ID for HDX token	0
GIGAHDX asset ID	Asset ID for GIGAHDX token (MM aToken)	67
pallet-fee-processor
HDX Staking Pot %	Percentage of fees to classic HDX stakers	~20%
stHDX Pot %	Percentage of fees to GIGAHDX value accrual	~50%
GigaReward Pot %	Percentage of fees to voting rewards	~30%
Referenda seeding % per track	How much of GigaReward pot seeds each referenda (per track)	TBD
Money Market
LTV (Loan-to-Value)	Maximum borrow ratio	~40%
LT (Liquidation Threshold)	Threshold for liquidation	~70%
Debt ceiling	Maximum total debt for GIGAHDX collateral	1,000,000
Oracle EMA period	EMA period for price oracle	1 day

---

4. Architecture

Two new pallets will be introduced:

Pallet	Responsibility
pallet-gigahdx	GIGAHDX token mechanics, staking, unstaking, migration, reward claiming for governance participation
pallet-fee-processor	Fee accumulation, HDX buyback via omnipool, dynamic pot distribution

Classic HDX staking remains available alongside GIGAHDX.

---

5. Token Representation

5.1 Tokens Overview

Token	Description	Visibility	Requirements
HDX	Native token	Visible	—
stHDX	Intermediate staking token (received when staking HDX)	Mostly hidden from users	Transferable, non-tradable (no market/exchange listing)
GIGAHDX	Money Market token (received when supplying stHDX)	Visible	Transferable (unless locked), non-tradable, usable as collateral in AAVE v3 MM, usable for governance voting (with locking mechanism)

Users interact with HDX and GIGAHDX on the frontend. stHDX is an intermediate token that exists for technical reasons but is abstracted away from the user experience.

Note: stHDX and GIGAHDX are interchangeable 1:1. The issuance of stHDX and GIGAHDX is always the same — supplying 100 stHDX to MM yields exactly 100 GIGAHDX, and withdrawing 100 GIGAHDX returns exactly 100 stHDX.

Note on Value Accrual: In isolation mode, users supply stHDX as collateral to borrow HOLLAR — nobody borrows stHDX itself. This means GIGAHDX rebasing from borrow interest is effectively zero. All value accrual comes from the stHDX pot (fee buybacks), not from Money Market interest.

5.2 GIGAHDX Token Implementation

GIGAHDX (the Money Market token) requires a custom ERC20 implementation that combines:

1. AToken functionality — standard AAVE aToken behavior for Money Market integration
2. Locking mechanism — ability to lock tokens for a specified period (for governance voting)

5.2.1 Locking Mechanism Requirements

• Users can lock GIGAHDX for voting in governance
• Locked GIGAHDX cannot be transferred directly
• GIGAHDX can be withdrawn from MM via standard MM withdrawal, however locked GIGAHDX cannot be withdrawn
• The only way to withdraw locked GIGAHDX is via giga-unstake, which first removes any existing locks, then allows standard MM withdrawal to proceed
• Must track lock duration per account
• Lock should be compatible with conviction voting periods
• Must support forced lock removal for liquidation — when a position is liquidated, any existing locks must be removable so the liquidated amount can be transferred
• Must support forced lock removal on partial amounts — when user partially unstakes, the lock is removed only from the unstaked portion while preserving the lock on the remaining balance

5.3 Token Flow

From the user's perspective, the flow is simplified:

Flow:

1. Gigastake:    HDX → GIGAHDX
2. Borrow:       HOLLAR against GIGAHDX
3. Giga-unstake: GIGAHDX → HDX (after cooldown period)

Internally, gigastake handles: HDX → stHDX → supply to MM → GIGAHDX
Internally, giga-unstake handles: remove locks → withdraw from MM → stHDX → HDX

Pros:

• Standard AAVE v3 patterns preserved (no MM modification)
• Clean separation: stHDX mechanics vs AAVE mechanics
• User sees simplified view: HDX and GIGAHDX only

Cons:

• Edge case: user could theoretically end up holding only stHDX (which is hidden on frontend), however by design this should not be possible since gigastake always wraps to GIGAHDX and giga-unstake handles the full unwrap

---

6. GIGAHDX Value Mechanism

Note: This is technically the stHDX value mechanism, as stHDX is the underlying vault token that appreciates. Since stHDX and GIGAHDX are 1:1 interchangeable, the value accrual applies equally to GIGAHDX holders.

GIGAHDX operates as a vault token with appreciating exchange rate.

6.1 Exchange Rate

At launch, the ratio is 1:1. As rewards accrue to the pot, the HDX-per-GIGAHDX ratio increases. Later entrants receive fewer GIGAHDX per HDX deposited.

Formulas:

Exchange rate (HDX per GIGAHDX) = Total HDX in gigapot / Total stHDX supply

GIGAHDX received when staking = HDX deposited / Exchange rate

HDX received when unstaking = GIGAHDX burned × Exchange rate

Note: The exchange rate calculation uses stHDX supply internally (since stHDX and GIGAHDX are 1:1 interchangeable).

6.2 Example

1. User 1 deposits 1000 HDX → receives 1000 GIGAHDX
2. User 2 deposits 500 HDX → receives 500 GIGAHDX
3. 100 HDX accrues from fees into pot
4. Total pot: 1600 HDX, Total supply: 1500 GIGAHDX
5. Exchange rate: 1.067 HDX per GIGAHDX
6. User 3 deposits 500 HDX → receives 469 GIGAHDX
7. If User 3 withdraws immediately: receives 500 HDX (no profit from others' rewards)

---

7. pallet-gigahdx

7.1 Core Functions

7.1.1 Gigastake

Converts HDX to GIGAHDX:

1. Transfers HDX from user to special account (gigapot)
2. Mints stHDX based on current stHDX:HDX exchange rate
3. Immediately supplies stHDX to Money Market as collateral
4. User receives GIGAHDX

User earns staking rewards as long as they hold GIGAHDX. The intermediate stHDX token is not visible to the user.

7.1.2 Giga-unstake

Converts GIGAHDX to HDX:

1. Removes any existing governance locks on user's GIGAHDX (if present)
2. Withdraws from Money Market — user's GIGAHDX is returned as stHDX
3. Burns stHDX from user
4. Calculates HDX amount based on current exchange rate
5. Creates pending unlock position with cooldown period

Cooldown calculation:

Actual cooldown = max(Fixed cooldown period, Current GIGAHDX governance lock remaining)

This ensures users cannot bypass governance lock commitments by unstaking.

Note: Giga-unstake is the only way to withdraw locked GIGAHDX. Standard MM withdrawal will fail if GIGAHDX is locked. By removing locks first, giga-unstake enables the MM withdrawal to proceed.

Notes:

• Allows partial unstake, but must respect minimum staked amount
• User can have multiple concurrent unlock positions
• If user partially unstakes a locked amount, the lock must be preserved on the remaining GIGAHDX balance

7.1.3 Claim Unlock

Claims HDX after cooldown period expires.

7.1.4 Migrate

One-time migration from existing staked HDX to GIGAHDX directly:

1. Converts all staked HDX plus all unclaimed rewards (regardless of claim status)
2. Mints stHDX at current exchange rate
3. Immediately supplies stHDX to Money Market
4. User receives GIGAHDX

7.1.5 Claim Rewards

Claims rewards from governance participation (referenda voting).

Flow:

1. Retrieves all pending reward entries for the user (recorded when votes were removed)
2. For each reward entry:
   • Transfers HDX from the referenda's reward pot
   • Performs internal "gigastake" — converts HDX to GIGAHDX
3. User receives GIGAHDX as reward
4. Claimed reward entries are cleared from storage

Note: Rewards become claimable only after the user removes their vote from a finished referenda (Approved or Rejected). See Section 10 for details on how rewards are calculated and recorded.

7.2 Configuration

Parameter	Description
Cooldown period	Lock duration in blocks after giga-unstake
Min stake amount	Minimum HDX to stake / minimum GIGAHDX to hold after partial unstake
stHDX asset ID	Asset ID for stHDX token
HDX asset ID	Asset ID for HDX token
GIGAHDX asset ID	Asset ID for GIGAHDX token (Money Market aToken)

---

8. pallet-fee-processor

8.1 Purpose

Consolidates fee handling currently spread across referral pallet:

1. Accumulate trading fees (various assets)
2. Buyback HDX via omnipool
3. Distribute to registered pots based on configured percentages

8.2 Note on Refactoring

This functionality is currently handled by pallet-referrals:

• Fee accumulation
• HDX buybacks (in on_idle hook)
• Distribution to staking pot (fixed, single pot)

This logic needs to be extracted from pallet-referrals into the new pallet-fee-processor. The referrals pallet should be refactored to delegate fee processing to this new pallet, retaining only referral-specific logic.

8.3 Pot System

Pots can be registered and updated dynamically via governance. Initial pots:

Pot	Description
HDX Staking Pot	Classic HDX stakers (existing)
stHDX Pot	Auto-compounds into stHDX value
stHDX Reward Pot	Active participation rewards (e.g., voting incentives)
Referral Pot	Referrals rewards

8.4 Buyback Mechanism

• Runs in on_idle hook
• Converts accumulated fee assets → HDX via omnipool
• Distributes HDX to pots based on configured percentages
• Available for any component that needs asset exchange (not just GIGAHDX)

8.5 Referral changes

Referrals pallet has a system of tier, where each tier has configured percentages for trader,referrer and external.
External account is currently used for legacy staking.
With the refactored approach, referrals pallet is no longer responsible for fee processing, nor is for buyback. It simply receives a given portion of the trade fee which it can divided between trader, referrer and external account.
As legacy staking will have a dedicated fee receiver registered in the fee processing module, the external account will be changed to the Treasury account.

Example of TIER 1.
Currently
Level::Tier1 => FeeDistribution {
referrer: Permill::from_percent(6),
trader: Permill::from_percent(4),
external: Permill::from_percent(40),
},

This will become ( note that the percentage are only for demonstrating purposes )
Level::Tier1 => FeeDistribution {
referrer: Permill::from_percent(30),
trader: Permill::from_percent(20),
external: Permill::from_percent(50),
},

This means, that given portion of the trade fee amount will be divided: 30% to referrer , 20% to trader and 50% goes to treasury.

---

9. Voting Integration

9.1 Overview

Voting using pallet-conviction-voting is preserved. No custom changes to the conviction voting pallet are required.

Key points:

• GIGAHDX votes support user-selected conviction — users can choose their conviction level (1x to 6x) just like with HDX voting
• Higher conviction = longer lock period = higher governance rewards (see Section 10)
• Governance locks and staking cooldown are combined — giga-unstake cooldown is max(fixed cooldown period, current governance lock)

9.2 Current Implementation

The conviction voting pallet has a Currency config option:

type Currency: ReservableCurrency<Self::AccountId>
    + LockableCurrency<Self::AccountId, Moment = BlockNumberFor<Self, I>>
    + fungible::Inspect<Self::AccountId>;

Currently, this is configured to use an implementation from the balances pallet, which supports voting with the native HDX token only.

9.3 Proposed Approach: Custom Adapter

Note: This is a suggested approach. Further detailed analysis during implementation may reveal additional complexities or alternative solutions. The feasibility depends on whether all required trait methods can be properly delegated and coordinated between the two underlying implementations.

To extend voting support to HDX and GIGAHDX, we will create a special adapter that:

1. Implements required traits — ReservableCurrency, LockableCurrency, fungible::Inspect
2. Returns combined balance — When queried for user balance, returns sum of GIGAHDX + HDX
3. Handles locking with priority — When a lock is required:
   • First, consume GIGAHDX balance
   • Then, use HDX for the remainder (if any)

9.4 Lock Operations

set_lock

When set_lock is called with amount X:

1. Determine how much GIGAHDX user has
2. Lock GIGAHDX first (call set_lock on GIGAHDX custom aToken implementation)
3. If X > GIGAHDX balance, lock remainder from HDX (call set_lock on balances pallet)

extend_lock / remove_lock

Same approach applies:

• Adapter coordinates between GIGAHDX token (custom aToken with locking support) and HDX (balances pallet)
• Operations are split proportionally based on what was originally locked

9.5 Example

User has 1000 GIGAHDX + 2000 HDX, votes with 2500:

• Adapter returns total balance: 3000
• Lock requested: 2500
• GIGAHDX locked: 1000 (full balance)
• HDX locked: 1500 (remainder)

9.6 Open Issue: Liquidation vs Voting Lock Conflict

There is a potential conflict when GIGAHDX is both:

• Used as collateral in the Money Market
• Locked for voting

Scenario:

1. User has GIGAHDX as collateral and borrows HOLLAR
2. User votes with GIGAHDX, locking it for a conviction voting period
3. User's position becomes undercollateralized (e.g., HDX price drops)
4. Liquidation is triggered — protocol attempts to seize GIGAHDX
5. Problem: The GIGAHDX is locked for voting and cannot be transferred

Proposed solution:
When liquidating a GIGAHDX position, any existing voting locks are removed before the liquidation proceeds. This will require custom liquidation logic specifically for the GIGAHDX asset that:

1. Checks for existing voting locks on the position - force removes any votes ( even a vote in ongoing referenda
2. Removes/clears the locks
3. Proceeds with standard liquidation flow

9.7 Voting Lock vs Giga-unstake

Scenario:

1. User has GIGAHDX
2. User votes with conviction, GIGAHDX gets locked for conviction voting period
3. User wants to giga-unstake (withdraw)

Solution:
The giga-unstake cooldown period is calculated as:

Actual cooldown = max(Fixed cooldown period, Current GIGAHDX governance lock remaining)

This means:

• If governance lock > fixed cooldown → cooldown extends to match governance lock
• If governance lock < fixed cooldown → standard fixed cooldown applies
• If no governance lock → standard fixed cooldown applies

Example:

• Fixed cooldown period: 222 days
• User voted with 6x conviction (lock: 192 days remaining)
• Actual cooldown: max(222, 192) = 222 days

Example 2:

• Fixed cooldown period: 222 days
• User voted with 6x conviction (lock: 250 days remaining)
• Actual cooldown: max(222, 250) = 250 days

question:
What happens if a referenda has not finished yet and the user has voted but wants to withdraw?

This wont be allowed - user cannot have a vote in ongoing referenda if user wants to unstake.

---

10. Referenda Participation Rewards

This section describes how active Referenda participants will be rewarded.

Important:

• Rewards are distributed in GIGAHDX, not HDX
• Only votes made with GIGAHDX are eligible for rewards — votes made with HDX are not rewarded

10.1 Overview

Rewards for referenda participation are set up after a referenda finishes (Approved or Rejected) using a lazy approach. No temporary pots are created during the referenda.

Note: Cancelled referenda do not receive rewards — only Approved or Rejected referenda are eligible.

10.2 Vote Tracking

To determine reward eligibility, pallet-gigahdx must track GIGAHDX votes for each running referenda:

• When a user votes with GIGAHDX, record the vote (user, referenda ID, GIGAHDX amount, conviction)
• This tracking is separate from the conviction voting pallet's own tracking
• Only GIGAHDX votes are tracked — HDX votes are not recorded

10.3 Lazy Reward Allocation

Rewards are allocated lazily — triggered by the first vote removal after a referenda finishes (Approved or Rejected only).

When the first vote is removed from a finished referenda:

1. Take a configured portion from the GigaReward Pot
2. Transfer this amount to a temporary holding account for the specific referenda
3. Store the total reward amount and total GIGAHDX amount voted for this referenda in pallet-gigahdx

On subsequent vote removals:

• The reward pool for the referenda is already allocated
• No additional allocation from GigaReward Pot

Cancelled referenda:

• No rewards are allocated
• Users simply remove their votes without receiving any rewards

10.4 Reward Calculation on Vote Removal

When a user removes their vote from a finished referenda (Approved or Rejected):

1. Calculate user's share of rewards based on GIGAHDX amount voted and conviction:

User weighted vote = User GIGAHDX amount × User conviction multiplier
Total weighted votes = Sum of (GIGAHDX amount × conviction) for all voters

User reward = (User weighted vote / Total weighted votes) × Referenda reward pool

2. Record the calculated reward for the user (not transferred yet)
   • Store: user account, reward amount, referenda reward pot reference

Example:

• Referenda reward pool: 1000 HDX
• User A voted with 100 GIGAHDX at 1x conviction → weighted: 100
• User B voted with 100 GIGAHDX at 3x conviction → weighted: 300
• User C voted with 100 GIGAHDX at 6x conviction → weighted: 600
• Total weighted votes: 1000

Calculated rewards (recorded, not transferred):

• User A: (100 / 1000) × 1000 = 100 HDX
• User B: (300 / 1000) × 1000 = 300 HDX
• User C: (600 / 1000) × 1000 = 600 HDX

Note: Higher conviction = longer lock = higher reward share. Users must eventually remove their votes to have rewards calculated. This is enforced by the voting system itself — locked tokens cannot be used until votes are removed.

10.5 Claiming Rewards

To receive rewards, users must call claim_rewards from pallet-gigahdx (see Section 7.1.5).

Claim flow:

1. User calls claim_rewards
2. System retrieves all recorded rewards for the user (from various referenda)
3. For each reward entry:
   • Transfer HDX from the referenda's reward pot to user
   • Perform internal "gigastake" — convert HDX to GIGAHDX
4. User receives GIGAHDX as reward
5. Claimed reward entries are cleared from storage

10.6 Referenda Rewards Storage

The following information is stored in pallet-gigahdx:

Per running referenda:

• List of GIGAHDX voters (user, GIGAHDX amount voted, conviction)
• Total weighted votes (sum of amount × conviction)

Per finished referenda (after first vote removal):

• Total reward pool allocated
• Total weighted votes (snapshot at allocation time)
• Remaining reward balance
• Referenda reward pot account reference

Per user (claimable rewards):

• List of pending rewards: (referenda ID, reward amount, referenda reward pot reference)

10.7 Configuration

Parameter	Description
Referenda reward percentage	Percentage of GigaReward Pot to allocate per finished referenda

Note: The reward percentage may be configurable per track (e.g., root referenda get larger rewards than small treasury proposals).

---

11. Money Market Integration

11.1 Price Oracle

GIGAHDX price in the Money Market is determined as:

GIGAHDX/USD = EMA oracle of HDX/USD × GIGAHDX/HDX ratio

11.2 Isolation Mode

GIGAHDX will be configured as isolated collateral in AAVE v3:

Parameter	Value
Collateral	stHDX
Borrowable assets	HOLLAR only
LTV (Loan-to-Value)	~40% (conservative)
LT (Liquidation Threshold)	~50%
Debt ceiling	Start low, increase over time

11.3 Liquidation

GIGAHDX liquidation uses a Treasury-only mechanism. External liquidators are blocked to prevent manipulation attacks (e.g., manipulating HDX price to liquidate stakers and extract HOLLAR).

Why Treasury-only:

• External liquidators would need to wait ~222 days to convert liquidated GIGAHDX to HDX
• Prevents price manipulation attacks targeting GIGAHDX holders
• Treasury can safely absorb the debt and collateral

On-chain Liquidation Flow:

1. Protocol flashmints HOLLAR to repay the user's debt
2. Gov locks are removed on the liquidated account
3. Liquidates position, receives GIGAHDX (doesn't unwrap)
4. Received GIGAHDX is transferred to dedicated treasury account
5. All needed HOLLAR is borrowed from regular treasury account against other collateral
6. Flashmint is repaid

Note: The simpler approach is to not use the liquidated GIGAHDX as treasury collateral at all — just borrow all HOLLAR against other treasury collateral. This is easier to calculate and execute, though it lowers debt ceiling somewhat.

Debt Ceiling: Should be set based on what treasury can safely cover in case of liquidations.

Locked GIGAHDX:
If the GIGAHDX being liquidated has existing governance voting locks, the liquidation process removes these locks before transferring the collateral (step 2 above).

See also Section 9.6 for discussion of the liquidation vs voting lock conflict scenario.

11.4 Future Features (Out of Scope for Initial Launch)

Feature	Description
Immortal loans	Pay charge after liquidation to recover position
Reduced HOLLAR borrow APY	Preferential rate for GIGAHDX holders
Self-repaying loans	HOLLAR revenue distributed as loan repayment

---

12. Migration

Existing staked HDX holders can migrate to GIGAHDX directly:

1. All staked HDX plus all unclaimed rewards converted at current exchange rate
2. stHDX is minted and immediately supplied to MM
3. User receives GIGAHDX
4. One-time opt-in per account

---

13. Parallel Workstreams

The following workstreams can be developed:

#	Workstream	Can Parallel?
1	GIGAHDX token implementation (custom ERC20 + aToken + locking mechanism)	Yes
2	pallet-gigahdx	Yes
3	Referrals refactor + pallet-fee-processor	Yes
4	Voting integration + active votes rewards	Partially
5	Treasury-only liquidation mechanism	Yes

Workstreams 1, 2, 3, and 5 can be developed fully in parallel. Workstream 4 can be started in parallel but will need integration with the other components.