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, 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.