2nd Generation of $NHCT is coming!
On Apr. 10, we launched the initial generation of $NHCT, and we will launch the 2nd generation of $NHCT — discount exchange stage — at 22:00 UTC on May 10.
For a clearer understanding of the difference between the two stages, let’s look back at the initial generation stage first.
The generation of NHCT is divided into two stages: the initial generation stage and the discount exchange stage.
Users can have quotas for both stages simultaneously, and the two quotas do not affect each other.
The Initial Generation Stage
This stage is for the initial distribution of NHCT.
Only users who have locked sHCT in the locking contract (contract address: 0x0b6D1C3E60722123718FaF13bFc48270BD14E9A9) before block 11071850 (February 18 2022, 09:00 AM UTC) can participate in the initial generation. These users can mint an equal amount of NHCT tokens by burning a specific amount of HCT.
The initial generation of NHCT is subject to the following conditions:
- The quota (the amount of HCT that can be burned) is equal to 30% of the total amount of sHCT locked by the user before the block height of 11071850.
- All the quotas will be available on Apr 10.
- After users burn HCT and mint NHCT, all their NHCT will be released immediately.
- Exchange ratio: burn 1 HCT to mint 1 NHCT
- The quota used in the initial generation stage cannot be used again in the 2nd generation stage.
E.g.
If the user locked 1 million sHCT at block 11070000, then he can get a 300,000 HCT quota for exchanging NHCT. Then if the user decides to burn 300,000 HCT, he will get 300,000 NHCT immediately.
The Discount Exchange Stage
This stage is the primary generation stage of NHCT.
Users who lock sHCT in the locking contract after block 11071850 can participate in the discount exchange for NHCT. These users can mint NHCT tokens at 30% off the market price by burning a specific amount of HCT.
The discount exchange for NHCT is subject to the following conditions:
- The quota is equal to 30% of the total amount of sHCT locked after block 11071850.
- The quota will be released in three phases; on the 0th, 90th, and 180th days after the lock-up, 33.3% of the quota will be released in each phase.
- After users burn HCT and mint NHCT, all their NHCT will be released immediately.
- The exchange ratio depends on the prices of HCT and NHCT. The amount of NHCT= the USD value of HCT burned / (NHCT price*0.7). NHCT price here is a time-weighted average price (TWAP).
*The mechanism of NHCT time-weighted average price (TWAP) will be described in detail below.
E.g.
Assuming the price of HCT is 0.02 USD, the time-weighted average price of NHCT is 2 USD, and the available exchange quota of the user is 70,000 HCT. Then when the user burns 70,000 HCT, he can get 70000*0.02/(2*0.7)=1000 NHCT immediately.
Note: Although the generation of NHCT is affected by both the HCT price and the NHCT price, the max supply of NHCT is capped at 120,000,000 NHCT. Once the cap is reached, NHCT generation will cease.
***
NHCT time-weighted average price (TWAP)
Hurricane includes several improvements for supporting manipulation-resistant public price feeds. First, every pair measures (but does not store) the market price at the beginning of each block, before any trades take place. This price is expensive to manipulate because it is set by the last transaction, whether it is a mint, swap, or burn, in a previous block.
To set the measured price to one that is out of sync with the global market price, an attacker has to make a bad trade at the end of a previous block, typically with no guarantee that they will arbitrage it back in the next block. Attackers will lose money to arbitrageurs unless they can “selfishly” mine two blocks in a row. This type of attack presents several challenges and has not been observed to date.
Unfortunately, this alone is not enough. If significant value settles based on the price resulting from this mechanism, an attack’s profit will likely outweigh the loss.
Instead, Hurricane adds this end-of-block price to a single cumulative-price variable in the core contract weighted by the amount of time this price existed. This variable represents the sum of the Hurricane price for every second in the entire history of the contract.
This variable can be used by external contracts to track accurate time-weighted average prices (TWAPs) across any time interval.
The TWAP is constructed by reading the cumulative price from an ERC20 token pair at the beginning and at the end of the desired interval. The difference in this cumulative price can then be divided by the length of the interval to create a TWAP for that period.
TWAPs can be used directly or as the basis for moving averages (EMAs and SMAs) as needed.
A few notes:
For a 10-minute TWAP, sample once every 10 minutes. For a 1-week TWAP, sample once every week.
For a simple TWAP, the cost of manipulation increases (approx. linear) with liquidity on Hurricane, as well as (approx. linear) with the length of time over which you average.
The Cost of an attack is relatively simple to estimate. Moving the price 5% on a 1-hour TWAP is approximately equal to the amount lost to arbitrage and fees for moving the price 5% every block for 1 hour.
How does locking sHCT again affect the locking period & the quota release schedule?
If you have sHCT locked (even the locking period ends, but you haven’t unlocked it), then when you lock sHCT again, the locking period for all sHCT will restart timing.
The NHCT quota release schedule will also be affected: the redeemed quota will remain unchanged, while the rest quota will be re-timed with the new quota.
Suppose the user has obtained the 3a HCT quota earlier and a HCT quota will be released on Day0, Day90, and Day180 respectively, and the user redeemed b HCT quota before obtaining more quotas by locking sHCT again. If 3c HCT quota is obtained by locking sHCT again, according to the rules, c HCT quota will be released on Day0’, Day90’, and Day180’ respectively.
The overall quota release schedule will be changed to:
Day0’: c+ if(a-b≤0,0,a-b)
Day90’: c+ if(2a-b≤0,0,2a-b)
Day180’: c+if(3a-b≤0,0,3a-b)
*IF(test condition, value_if_true, [value_if_false])
