Handshake Hard Fork - Arbitrary DNS Records, Supply Reallocation, and Tree Interval

[realrasengan]

This PR proposes a hard fork with three consensus changes proposed by myself and @2drewlee :

1. Arbitrary DNS resource records on-chain. Expand from 7 custom record types to full DNS zone support including A, AAAA, MX, CNAME, SRV, TLSA, and any other DNS type via a generic RAW record, with subdomain label compression and an increased resource size limit (512 to 8192 bytes).

2. Unclaimed supply reallocation. Reallocate ~874.7M unclaimed HNS (airdrop + name claims) to a Handshake Foundation multisig wallet via a one-time coinbase output at the fork activation height.

3. Tree interval reduction. Commit the Urkel Tree every block instead of every 36 blocks, reducing proof availability from ~6 hours to ~10 minutes.

Motivation

DNS Records

Handshake currently restricts on-chain resource records to 7 custom types (DS, NS, GLUE4, GLUE6, SYNTH4, SYNTH6, TXT) with a 512-byte size limit. TLD owners cannot serve arbitrary DNS records directly from the chain. They can only delegate via NS or use synthetic records. This forces reliance on external nameservers for common records like A, AAAA, MX, and TLSA, undermining the trustless nature of Handshake.

By allowing full zone data on-chain, TLD owners can operate entirely from the blockchain without running external infrastructure. The LABEL mechanism enables subdomain records (e.g., _443._tcp for TLSA, www for A records) within a single compact resource. The RAW record type future-proofs the system for any DNS type that may emerge.

Supply Reallocation

The airstop soft fork (HSD v8.0.0, activated October 2025) permanently disabled airdrop claims. The original developer airdrop achieved only ~2.9% uptake, leaving ~686.8M HNS unclaimed. Similarly, ICANN TLD and Alexa domain name claims expired after the 4-year claim period with ~188.0M HNS unclaimed.

Combined, ~874.7M HNS is permanently unclaimable dead supply. This PR reallocates these tokens to a Handshake Foundation multisig controlled by long-standing community members, to fund ecosystem development, tooling, and adoption.

Tree Interval

The Urkel Tree currently commits every 36 blocks (~6 hours). While full nodes serve DNS from the in-memory transaction (no delay), light clients and proof-based verification must wait up to 6 hours for cryptographic proofs of name ownership. Reducing the tree interval to 1 block makes proofs available within ~10 minutes. The Urkel Tree is append-only, so the additional disk I/O is negligible on modern hardware, and reorg recovery is actually simplified.

Specification

1. Arbitrary DNS Resource Records

1.1 New Record Types

Add 17 new Handshake record types to hsTypes:

hsType	Value	DNS Equivalent	Binary Format
A	7	A	4 bytes (IPv4)
AAAA	8	AAAA	16 bytes (IPv6)
CNAME	9	CNAME	compressed name
DNAME	10	DNAME	compressed name
MX	11	MX	u16 preference + compressed name
SRV	12	SRV	u16 priority + u16 weight + u16 port + compressed name
TLSA	13	TLSA	u8 usage + u8 selector + u8 matchingType + u8 len + data
SSHFP	14	SSHFP	u8 algorithm + u8 fpType + u8 len + fingerprint
CAA	15	CAA	u8 flags + string tag + string value
SOA	16	SOA	2× compressed name + 5× u32
PTR	17	PTR	compressed name
NAPTR	18	NAPTR	u16 order + u16 pref + string flags + string service + string regexp + compressed name
SMIMEA	19	SMIMEA	u8 usage + u8 selector + u8 matchingType + u8 len + data
OPENPGPKEY	20	OPENPGPKEY	u16 len + public key data
URI	21	URI	u16 priority + u16 weight + string target
LOC	22	LOC	u8 version + u8 size + u8 horizPre + u8 vertPre + u32 lat + u32 lon + u32 alt
RP	23	RP	2× compressed name

1.2 LABEL Pseudo-Record (hsType 24)

The LABEL record is a control marker that sets the subdomain context for all subsequent records. It does not produce a DNS record itself.

LABEL "www"       → subsequent records apply to www.<tld>.
LABEL "_443._tcp" → subsequent records apply to _443._tcp.<tld>.

Records before any LABEL apply to the TLD itself. This enables compact subdomain encoding without repeating names per record.

Backwards compatibility: TLD-level records are always serialized first. Old nodes encountering an unknown hsType (LABEL = 24) will stop decoding and still have all TLD records intact.

1.3 RAW Record (hsType 25)

A generic container for any DNS record type not covered by the named types above:

u16 dnsType    - the DNS wire type number
u16 length     - rdata length
bytes rdata    - raw record data

This future-proofs the system for new DNS types without requiring consensus changes.

1.4 Resource Size Limit

MAX_RESOURCE_SIZE increases from 512 to 8192 bytes, allowing rich zone files with multiple subdomains and record types.

1.5 Dynamic NSEC Bitmap

NSEC denial-of-existence proofs are now generated dynamically from the record types present in a resource, replacing hardcoded type bitmaps. This correctly advertises which types exist at each name and subdomain.

1.6 DNS Resolution

• Records without a LABEL are authoritative answers for the TLD (when no NS delegation exists).
• Records with a LABEL are authoritative for the corresponding subdomain.
• CNAME records are returned for any query type per RFC 1034.
• Multi-label queries (e.g., www.example.) extract the prefix, check for a matching LABEL, and resolve from on-chain subdomain records.

2. Supply Reallocation

At a designated activation height, the coinbase transaction MUST include an additional output:

• Amount: 874,728,834,850,000 dollarydoos (874,728,834.85 HNS)
• Address: Handshake Foundation multisig (TBD)

This is a one-time event. The amount represents:

• 686,773,848.08 HNS unclaimed from the developer airdrop (MAX_AIRDROP − claimed)
• 187,954,986.77 HNS unclaimed from ICANN/Alexa name claims (MAX_TLD + MAX_DOMAIN + MAX_CA_NAMING − claimed)

Validation rules:

• At the activation height, the allowed block reward is increased by the reallocation amount.
• The coinbase must contain an output with the exact amount to the exact Foundation address.
• At all other heights, no change to validation.

2.1 Foundation Multisig

The reallocation address is a multisig wallet controlled by the following Handshake Foundation keyholders:

• Andrew Lee (@2drewlee) - Co-Founder of Handshake, Former CEO of Purse.io
• Christopher Jeffrey (@chjj) - Co-Founder of Handshake, Lead Protocol Developer
• Rithvik Vibhu (@rithvikvibhu) - Handshake Core Developer
• Mike Michelini (@skyinclude) - Handshake Community Advocate, Founder of SkyInclude
• Jordan Koch (@eskimo) - Handshake Ecosystem Developer
• Namebase Ownership - Namebase

The multisig threshold is TBD (e.g., 4-of-6).

3. Tree Interval

The Urkel Tree commit interval (treeInterval) changes from 36 blocks to 1 block across all networks. Every block now commits the tree, making cryptographic name proofs available within ~10 minutes.

Consensus Changes Summary

Parameter	Before	After
MAX_RESOURCE_SIZE	512 bytes	8,192 bytes
hsTypes count	7 (DS-TXT)	26 (DS-RAW)
treeInterval (mainnet)	36 blocks (~6 hrs)	1 block (~10 min)
Reallocation	-	874,728,834.85 HNS one-time coinbase

Activation

This is a hard fork. Activation occurs at a designated block height (TBD). All nodes must upgrade before the activation height.

Security Considerations

• The increased resource size (8,192 bytes) increases potential UTXO bloat. At 10M names × 8KB worst case, this is ~80GB. In practice, most resources will be much smaller.
• The Foundation multisig key management requires operational security practices (hardware wallets, geographic distribution, etc.).
• The tree interval reduction has no negative security impact; reorg recovery is simplified since there are no pending tree transactions to replay.

References

• HIP 68 - Handshake V2 Proposal
• HIP 69 - Burn Baby Burn
• PR #927 - Airstop Soft Fork
• ShakeShift Supply Stats
• RFC 1034 - Domain Concepts and Facilities

[eskimo]

Overall I agree with this though I would disagree with the signers. I would make the following changes if it were up to me.

Remove:
Andrew Lee
Christopher Jeffrey
Namebase

Add:
@Nathanwoodburn
Jesse (Handshake Institute)
Cymon (shakeshift.com)

[walletdomain]

I'm for all of this, but I think the multi-sig wallet would be better served as a registered DAO. A DAO gives more of an independent feel than a multi-sig wallet. The DAO can use a multi-sig wallet to manage the treasury, but it allows voting to be done more cleanly in the event that one of the signers wants out.

So instead of identifying a multi-sig wallet and the signers, just identify the DAO and allocate the tokens to whoever you want and however many you want. It will make future voting efforts easier.

[ForestCoin]

@2drewlee How many years has the Handshake community been developing? What have you done in the community?

[ForestCoin]

disagree hard fork

[ForestCoin]

Overall I agree with this though I would disagree with the signers. I would make the following changes if it were up to me.

Remove: Andrew Lee Christopher Jeffrey Namebase

Add: @Nathanwoodburn Jesse (Handshake Institute) Cymon (shakeshift.com)

Remove: Andrew Lee

[2drewlee]

Not sure who you are @ForestCoin, I don't think we've ever interacted.

I'm mostly a behind the scenes guy. Originally was the node that brought Joseph JJ Andrew together to start Handshake. Kept the team together, unblocked obstacles that came up, and pushed to get the project launched.

The idea behind Handshake was for us to pass off the project to the community like Satoshi - and we've all done that to varying degrees. Time to time, community members have asked me to help with things, and I've continued to try my best to guide the project without being a figure that overshadows community member efforts.

Mike and Anne asked me to be a part of Handycon every year, and I've continued to be a part of it to show support as part of the founding team. I also helped organize and fund the first live hackathon for Handshake in Vietnam - many community members from the East met for the first time as a result including Michelini, Rithvik, Nathan, Jacky Chan, and so forth.

Most recently, Mark Tyneway has been pitching an idea to bridge HNS to Solana, and I think it's a terrific idea. To get it moving, I brought together a group with multi-chain engineers including Rithvik to explore how to do this. Zcash, for example, got a lot of traction this cycle in part because of this type of strategy.

Long story short, the highest leverage thing I can do is tapping into a network of people I know who can move the needle together for various initiatives. Some are my ideas, but most are ideas people have but don't have the connections, resources or know-how to get things moving. Even this upgrade that @realrasengan is proposing is the result of multi-year conversations we've had within the community (including Skyinclude's HIP-18 proposal). We wouldn't be discussing this unless I was in the background pushing for it.

I'm sure most of the other proposed multi-sig members including @realrasengan Nathan Rithvik Jesse Skyinclude would vouch for everything above.

Also, I'll make a quick case for JJ - he poured blood sweat and tears into the project and wrote 99% of the code. He knows the codebase better than everyone. He's technical, apolitical, and there will come a time when the project needs him, and I'm sure he'll deliver when he's needed.

DAO is a good idea too. Mb DAO should control the multi-sig.

[faltrum]

I'm agree with points 1 and 3.
It could be good to know the implications for blockchain about increase from 512 to 8192 bytes.
Could be great split the proposal in 2 proposals, first one with points 1 and 3 and second one with point 2.
Waiting technical opinions from @rithvikvibhu, @Falci, @pinheadmz adn others.

[pinheadmz]

Waiting technical opinions from @rithvikvibhu, @Falci, @pinheadmz adn others.

I have almost no interest (or stake) in HNS anymore but I will leave some comments so community members have some threads to pull. I am going to mute this thread after posting, so don't reply me: reply to the community.

First of all

A hard fork PR adding 2,000 lines of code in one commit with zero tests is absolutely, unforgivably, UTTERLY NOT SERIOUS. I don't know what kind of discussion has already taken place around these proposed changes, but if it's not worth the author's time to take seriously, it's not worth the reviewers time to take seriously.

DNS records

As far as I can remember, there are NO CONSENSUS RULES whatsoever about data in the resource. You can put whatever you want in there. It's not a hard fork, it's not a soft fork, it's application-layer data. I think I had a proposal back in the day that used resource version 1 instead of 0 so the data could be interpreted by a new protocol.

Consensus limits

Author proposes expanding the maximum resource size 16x. Some analysis should be done on the impact of this on block space, TX relay, effect on light clients, the amount of hashing required by Urkel operations.

Author proposes writing the Urkel tree to disk and computing new tree root every block instead of every 36 blocks.

For both of these changes, there is probably a lengthy explanation in the whitepaper for the original values. A proposal to change them should address that directly. However, its also reasonable to admit that the project overall has failed the original goals of the founders who wrote the whitepaper, the blockchain has a totally different use case now, and is so under-utilized that these limits can be safely multiplied.

Reallocation

I thought the whole point of the last soft fork was to effectively reduce the money supply to make the coin more valuable?

How much real-world value is there in 800M HNS? Are there developers out there willing to trade their time for that? What happens to the price when these coins are minted? Or sold for USD?

Author proposes three Handshake founders as recipients. As founders, those parties should already have a huge amount of HNS premine. Not to mention the three people mentioned are early bitcoin adopters with history of selling companies and otherwise, I would assume, being completely capable of funding developers right from their own pocket.

Nathan

If I still have your attention, please review #953 and leave feedback there if you think @Nathanwoodburn would be a good LEAD DEVELOPER AND PROJECT MAINTAINER for the entire HNS ecosystem. hsd and hnsd. He may very well be the single person who decides if a hard fork like this gets deployed.

[Falci]

Thanks for submitting a pull request.

My recommendation is: make 3 individual PR to address each individual change.
Easy to review and discuss.

Also, about hard fork, they need to be activated via BIP 9, as every other change we had in the past.

[realrasengan]

Appreciate everyone weighing in. Let me address things directly.

1. Arbitrary DNS records make Handshake actually uncensorable DNS. Governments across Europe are ordering blocking of domains right now. However, DNS-on-chain (DOC) doesn't work if you're waiting hours for tree commits, so tree interval needs to be 1 block.

2. Unless I'm misunderstanding, BIP9 is a soft fork activation mechanism. This is a hard fork, so it's following existing HSD convention/historic forks. HSD's previous hard forks (deflationHeight at block 61043, goosigStop) both used height-based activation, not BIP9. The three BIP9 deployments (hardening, icannlockup, airstop) were all soft forks. So this is following convention exactly.

3. There are 33 new test cases covering serialization round-trips for every new record type, LABEL handling, RAW records, DNS resolution, NSEC bitmaps, and size validation. You can read them in test/resource-test.js. Chain-level tests for the reallocation and tree interval do need to be created once social consensus is achieved.

4. pinheadz is right that record types are application-layer, but this requires consensus change. MAX_RESOURCE_SIZE is enforced in the block validation path. Older nodes will reject blocks with > 512.

Also, a fun tidbit I want to mention is that resource record limits are per name, not per subdomain. Thus, you can DNAME a subdomain to another TLD you own fully on-chain and uncensorable

5. The reallocation isn't going into the named people's pockets. The goal is a Foundation with a diverse, multi-party board and community representation across founders, developers, advocates, and ecosystem builders. A funded working body is the difference between this project having a future and not having one. I'm completely open to discussion on governance structure, be it multisig, DAO, DUNA, or whatever works.

10 min trees make Handshake as a powerful decentralized identity possible. On chain resource records make Handshake as uncensorable DNS possible. And a funded Foundation will steward development and community outreach for the next generation of Handshake.

[Gh0sTtD3v]

Split this into 3 separate PRs.

Items 1 (Arbitrary DNS Records) and 3 (Tree Interval) are solid technical improvements that stand on their own merit. Bundling them with a ~875M HNS supply reallocation forces the community into an all-or-nothing decision where opposing the treasury grab means blocking legitimate protocol upgrades. These should be evaluated independently.

On the supply reallocation specifically:

These tokens were permanently unclaimable — the market priced them as dead supply. Minting them into a multisig wallet doesn't bring new capital, new users, or new demand into the ecosystem. It just increases the liquid supply, diluting every current holder.

Worse, this dilution directly undermines the miners who are actually securing the network. Their block rewards become worth less in real terms while a one-time coinbase output hands a small group more tokens than miners earn over extended periods. If you weaken the economic incentive to mine, you weaken network security — which hurts adoption, not helps it.

There is zero accountability framework.

Before any supply reallocation should even be considered, the community needs to see at minimum:

• A proposal for a legally recognized entity (DAO, DUNA, or equivalent) with transparent governance
• A clear mandate defining what "ecosystem development" means in practice, with spending categories and limits
• A proposal and voting system where the broader community can approve or reject how these funds are allocated
• A mechanism to elect and rotate foundation chairs — not a self-appointed list of insiders with permanent seats
• Vesting schedules and milestone-based unlocks so tokens can't be dumped freely
• Public reporting of all transactions from the treasury

As it stands, this proposal asks the community to trust a self-selected multisig with no legal obligations, no spending rules, no oversight, and no way to remove bad actors. That's not a foundation — it's a blank check.

Get items 1 and 3 merged on their own. Then come back with item 2 as a standalone proposal that includes a real governance framework the community can evaluate.

[realrasengan]

Split this into 3 separate PRs.

Items 1 (Arbitrary DNS Records) and 3 (Tree Interval) are solid technical improvements that stand on their own merit. Bundling them with a ~875M HNS supply reallocation forces the community into an all-or-nothing decision where opposing the treasury grab means blocking legitimate protocol upgrades. These should be evaluated independently.

On the supply reallocation specifically:

These tokens were permanently unclaimable — the market priced them as dead supply. Minting them into a multisig wallet doesn't bring new capital, new users, or new demand into the ecosystem. It just increases the liquid supply, diluting every current holder.

Worse, this dilution directly undermines the miners who are actually securing the network. Their block rewards become worth less in real terms while a one-time coinbase output hands a small group more tokens than miners earn over extended periods. If you weaken the economic incentive to mine, you weaken network security — which hurts adoption, not helps it.

There is zero accountability framework.

Before any supply reallocation should even be considered, the community needs to see at minimum:

• A proposal for a legally recognized entity (DAO, DUNA, or equivalent) with transparent governance
• A clear mandate defining what "ecosystem development" means in practice, with spending categories and limits
• A proposal and voting system where the broader community can approve or reject how these funds are allocated
• A mechanism to elect and rotate foundation chairs — not a self-appointed list of insiders with permanent seats
• Vesting schedules and milestone-based unlocks so tokens can't be dumped freely
• Public reporting of all transactions from the treasury

As it stands, this proposal asks the community to trust a self-selected multisig with no legal obligations, no spending rules, no oversight, and no way to remove bad actors. That's not a foundation — it's a blank check.

Get items 1 and 3 merged on their own. Then come back with item 2 as a standalone proposal that includes a real governance framework the community can evaluate.

AI is a great auto-completion tool, but as you can see lacks world context. We're talking about a 4M market cap blockchain here that's quickly nearing zero.

[Gh0sTtD3v]

AI is a great auto-completion tool, but as you can see lacks world context. We're talking about a 4M market cap blockchain here that's quickly nearing zero.

So we should force it to zero faster?

Furthermore you don't want to see the response my AI gave me on this PR lol

[realrasengan]

AI is a great auto-completion tool, but as you can see lacks world context. We're talking about a 4M market cap blockchain here that's quickly nearing zero.

So we should force it to zero faster?

Furthermore you don't want to see the response my AI gave me on this PR lol

Forcing it to zero faster is a poor suggestion. It's imperative that Handshake both pivots its use case and has the resources available to disseminate said use case. This can be 3 PRs but remains a single issue.

[Gh0sTtD3v]

AI is a great auto-completion tool, but as you can see lacks world context. We're talking about a 4M market cap blockchain here that's quickly nearing zero.

So we should force it to zero faster?
Furthermore you don't want to see the response my AI gave me on this PR lol

Forcing it to zero faster is a poor suggestion. It's imperative that Handshake both pivots its use case and has the resources available to disseminate said use case. This can be 3 PRs but remains a single issue.

I'm not the one suggesting we force it to zero. This PR is. Minting 875M tokens into a self-appointed multisig with no plan, no accountability, and no new capital is the definition of forcing it to zero faster. It's not like demand appears out of thin air to back them up.
You want to pivot the use case? Great. Write the plan first. Show the community what you're building, how the funds will be spent, and what accountability looks like. Then ask for resources. This is the wrong way around.

[Nathanwoodburn]

G'day,
Just seeing your response #952 (comment) and I've got a few questions

1. Is there any reason for why a 10 minute DNS change is needed? DNS changes are rare in production sites.
   Also note that resolvers can use the temporary DNS that isn't committed to the urkle tree when returning DNS queries.
   Does reducing the tree update time have a big impact on disk size? What about syncing time of hnsd/light clients?

2. Yes hard forks don't have the bip9 signalling because it isn't compatible with the "old software". We still need to communicate with the miners. We could use the same "style" of signalling or use out of band communication (telegram, email, etc).

3. Wouldn't it make sense to write the tests to follow the rules already in this pr. Then change the tests as the pr changes? For example tests to simulate the fork or tests to simulate spending funds from a foundation address.

4. Is there any reason we need to have this increase in storage. Could you provide a realistic example of where this increase is needed for a real world use?
   4b. Is there a need for increased storage if we can just dname to a new "subdomain TLD"?

5. Will a foundation actually help? If I remember correctly dweb foundation had a ton of funds which they didn't have any opportunities to spend to help Handshake. What difference will this foundation have? Also since these coins are created here, is there an actual reason for the amount? Or is it just because this amount used to be possible onchain before might as well create it again?

[realrasengan]

G'day, Just seeing your response #952 (comment) and I've got a few questions

1. Is there any reason for why a 10 minute DNS change is needed?

It's a pain to wait. Even 10 minutes is long! :)

DNS changes are rare in production sites.

It depends on what site/service. While many static production sites may not change their DNS settings often, there are actually many other sites that include dynamically changing DNS as a part of their architecture.

Also note that resolvers can use the temporary DNS that isn't committed to the urkle tree when returning DNS queries.

Only full nodes CAN do this.

Does reducing the tree update time have a big impact on disk size? What about syncing time of hnsd/light clients?

As of now, there is likely minimal to no impact since the community is small. This answer is variably dependent on community size, though, and should be revisited as the community grows again!

2. Yes hard forks don't have the bip9 signalling because it isn't compatible with the "old software". We still need to communicate with the miners. We could use the same "style" of signalling or use out of band communication (telegram, email, etc).

If the community is on board, it's imperative the foundation contacts now and stays in touch thereafter with the mining community; albeit, in a loosely coupled fashion.

3. Wouldn't it make sense to write the tests to follow the rules already in this pr. Then change the tests as the pr changes? For example tests to simulate the fork or tests to simulate spending funds from a foundation address.

There are still TBD (to be determined) decisions to be made!

4. Is there any reason we need to have this increase in storage. Could you provide a realistic example of where this increase is needed for a real world use?

512 bytes is too small for a zone file.

4b. Is there a need for increased storage if we can just dname to a new "subdomain TLD"?

512 bytes is still too small for a zone file. Every subdomain will automatically take a significant number of bytes. Other records could take up more. A simple handshake bech32 address is already 32 bytes!

5. Will a foundation actually help? If I remember correctly dweb foundation had a ton of funds which they didn't have any opportunities to spend to help Handshake. What difference will this foundation have? Also since these coins are created here, is there an actual reason for the amount? Or is it just because this amount used to be possible onchain before might as well create it again?

This is a good question, and while my previous answers had more confidence, this one is significantly more of an opinion than a fact: Other foundations in the past had good motives, but the world of cryptocurrency has evolved at such a quick speed, that the launching and sustaining of a token and, in this case a chain, is much different than it was when Handshake first launched. There are certain things missing from the ecosystem that need to exist.

In hindsight, the step away of the founders should have been more transitioned with a foundation taking its place. Rather than complain about spilt milk, let's clean it up and eat some cookies while we are at it!

Edit: s\it\at it

[Nathanwoodburn]

There are a few issues that I can see with every block being an urkel update.

1. Re-orgs? At the moment how does hsd handle re-orgs that cross the urkel tree update block? How would a re-org of >1 block work for hsd. Will it be able to rewind though multiple urkel trees
2. Safe height confirmations. At the moment we have to wait a few blocks (12? I think) after a tree update before it is considered safe. So currently there is a min of 12 blocks and a max of 48 blocks for an update to take affect. This PR would fix that to 12 blocks, which is still an improvement but isn't instant every block updates.
3. Compaction. From memory, hsd stores all the no longer used tree data until there is a tree compaction. By increasing the number of urkel updates, do we need to compact more often?