handshake-org · realrasengan · Mar 5, 2026
diff --git a/HIP-0018.md b/HIP-0018.md
@@ -0,0 +1,109 @@
+# HIP-0018 : Arbitrary DNS Resource Records On-Chain
+
+```
+Number:  HIP-0018
+Title:   Arbitrary DNS Resource Records On-Chain
+Type:    Standards Track
+Status:  Draft
+Authors: Andrew Lee <https://github.com/realrasengan>
+Created: 2026-03-04
+```
+
+## Abstract
+
+Expand Handshake on-chain resource records from 7 custom 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 → 8192 bytes).
+
+## Motivation
+
+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.
+
+## Specification
+
+### 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 |
+
+### 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.
+
+### 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.
+
+### 4. Resource Size Limit
+
+`MAX_RESOURCE_SIZE` increases from 512 to 8192 bytes, allowing rich zone files with multiple subdomains and record types.
+
+### 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.
+
+### 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.
+
+## Consensus Changes
+
+| Parameter | Before | After |
+|-----------|--------|-------|
+| `MAX_RESOURCE_SIZE` | 512 bytes | 8,192 bytes |
+| `hsTypes` count | 7 (DS-TXT) | 26 (DS-RAW) |
+
+## 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.
+
+## Reference Implementation
+
+- hsd: [PR #952](https://github.com/handshake-org/hsd/pull/952)
+
+## References
+
+- [RFC 1034 - Domain Concepts and Facilities](https://tools.ietf.org/html/rfc1034)
diff --git a/HIP-0019.md b/HIP-0019.md
@@ -0,0 +1,75 @@
+# HIP-0019 : Unclaimed Supply Reallocation to Handshake Foundation
+
+```
+Number:  HIP-0019
+Title:   Unclaimed Supply Reallocation to Handshake Foundation
+Type:    Standards Track
+Status:  Draft
+Authors: Andrew Lee <https://github.com/realrasengan>
+Created: 2026-03-04
+```
+
+## Abstract
+
+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.
+
+## Motivation
+
+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 proposal reallocates these tokens to a Handshake Foundation multisig controlled by long-standing community members, to fund ecosystem development, tooling, and adoption.
+
+## Specification
+
+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.
+
+### Foundation Multisig
+
+The reallocation address is a multisig wallet controlled by the following Handshake Foundation keyholders:
+
+- Andrew Lee ([@2drewlee](https://github.com/2drewlee)), Co-Founder of Handshake, CEO of Purse.io
+- Christopher Jeffrey ([@chjj](https://github.com/chjj)), Co-Founder of Handshake, Lead Protocol Developer
+- Rithvik Vibhu ([@rithvikvibhu](https://github.com/rithvikvibhu)), Handshake Core Developer
+- Mike Michelini ([@skyinclude](https://github.com/skyinclude)), Handshake Community Advocate, Founder of SkyInclude
+- Jordan Koch ([@eskimo](https://github.com/eskimo)), Handshake Ecosystem Developer
+- Namebase Ownership, Namebase
+
+The multisig threshold is TBD (e.g., 4-of-6).
+
+## Consensus Changes
+
+| Parameter | Before | After |
+|-----------|--------|-------|
+| 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 Foundation multisig key management requires operational security practices (hardware wallets, geographic distribution, etc.).
+
+## Reference Implementation
+
+- hsd: [PR #952](https://github.com/handshake-org/hsd/pull/952)
+
+## References
+
+- [HIP 68 - Handshake V2 Proposal](https://github.com/handshake-org/HIPs/discussions/68)
+- [HIP 69 - Burn Baby Burn](https://github.com/handshake-org/HIPs/discussions/69)
+- [PR #927 - Airstop Soft Fork](https://github.com/handshake-org/hsd/pull/927)
+- [ShakeShift Supply Stats](https://shakeshift.com/stats)
diff --git a/HIP-0020.md b/HIP-0020.md
@@ -0,0 +1,45 @@
+# HIP-0020 : Reduce Urkel Tree Interval to 1 Block
+
+```
+Number:  HIP-0020
+Title:   Reduce Urkel Tree Interval to 1 Block
+Type:    Standards Track
+Status:  Draft
+Authors: Andrew Lee <https://github.com/realrasengan>
+Created: 2026-03-04
+```
+
+## Abstract
+
+Reduce the Urkel Tree commit interval from 36 blocks (~6 hours) to 1 block (~10 minutes), making cryptographic name proofs available every block.
+
+## Motivation
+
+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. Reorg recovery is actually simplified. With `treeInterval = 1`, there are no pending tree transactions to replay on reorg.
+
+## Specification
+
+The `treeInterval` network parameter changes from 36 blocks to 1 block across all networks (mainnet, testnet, regtest, simnet). Every block now commits the tree root to the block header.
+
+## Consensus Changes
+
+| Parameter | Before | After |
+|-----------|--------|-------|
+| `treeInterval` (mainnet) | 36 blocks (~6 hrs) | 1 block (~10 min) |
+| `treeInterval` (testnet) | 36 blocks | 1 block |
+| `treeInterval` (regtest) | 5 blocks | 1 block |
+| `treeInterval` (simnet) | 2 blocks | 1 block |
+
+## 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 tree interval reduction has no negative security impact; reorg recovery is simplified since there are no pending tree transactions to replay.
+
+## Reference Implementation
+
+- hsd: [PR #952](https://github.com/handshake-org/hsd/pull/952)