Skip to content

Instantly share code, notes, and snippets.

@Falci
Created June 1, 2022 07:07
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Falci/04ee458066f6e1f3d7af36501b188e1d to your computer and use it in GitHub Desktop.
Save Falci/04ee458066f6e1f3d7af36501b188e1d to your computer and use it in GitHub Desktop.

HIP-00XX : HIP Template

Number:  HIP-00xx
Title:   Soft fork: extend name claim period
Type:    Standards Track
Status:  Draft
Authors: Fernando Falci <https://iamfernando/>
Created: 202Y-MM-DD

Abstract

Extend name claim period, from 4 years to 8 years.

Motivation

Handshake mainnet is live for almost 2 years. The community growing and every day there more "HNS domains" live as well as new software created specifically for Handshake. However, we can notice the adoption is slow. We are halfway to the end of the name claim period and there's a feeling that two more year won't be enough.

Extending the claim period would allow more companies to claim their name. However, we believe that keeping the name claim allowed forever could be harmful to the project, since companies could delay their onboarding undefinetelly. Also, as the time pass, the Alexa 100k becomes more and more outdated. There's no point in lock those names forever.

That said, we believe 4 extra years (8 years from genesis) would be a fair extension.

Activation

Changing the claim period from 4 to 8 years won't have any impact now. Any possible problem would only occur after the original claim period is over, which gives us around 2 years to coordinate this update.

To make sure everyone is aligned with this update and aiming to avoid a hard fork we should deploy this change following BIP9 as below:

Name HIP10
Bit 1
Start Time 2022-10-01
End Time 2023-10-01

Force Split

Even though the deploy end time is in Octuber 2023, the real activation will only happen after 2023-02-03 (4 years after genesis). However, we can't know for sure if it was a success until a CLAIM happen. Since there is no way to guarantee a CLAIM will appear, we can't really know if the soft work was a success or not.

A possible solution for this is to intentionally change (break) another consensus rule in an one time event.

The first block after the original claim period should include an extra mining reward of 1 HNS, which should have a nulldata address output (burn).

This extra step will intentionally break the consensus rules for node

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment