The Kinetic Network Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Human-readable names are useful only when users can discover and remember them. In open networks, however, a free human-readable namespace is vulnerable to front-running, dictionary registration, and long-term squatting. Existing systems commonly introduce recurring fees, centralized registries, or external identity verification to control these attacks.¶

Kinetic takes a different approach. It treats name ownership as a locally verifiable cryptographic state. A registrant proves a name claim by completing a sequential VDF computation bound to a commitment, an external randomness beacon value, and the registrant's public key. Ownership remains live through signed heartbeat records. If heartbeats stop, the name becomes increasingly available for challenge according to deterministic reclamation rules.¶

Kinetic is not a Domain Name System (DNS) replacement. It does not directly map names to addresses. The network protocol specified here maps a name to an owner identity key. Higher-layer documents can define identity documents, service manifests, content routing, and application semantics.¶

This Internet-Draft is an individual contribution and is intended to start discussion on the protocol design, wire formats, threat model, and interoperability requirements.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

The following terms are used throughout this document:¶

Name:

A human-readable Kinetic name, such as "example.kin".¶

Owner key:

A public key that controls a Kinetic name. This document assumes Ed25519 [RFC8032] unless another signature algorithm is explicitly negotiated by a future specification.¶

Commitment:

A digest that hides the requested name until the corresponding VDF has been computed.¶

Reveal:

A signed record that discloses the name, commitment inputs, VDF output, VDF proof, and owner key.¶

Heartbeat:

A signed freshness assertion from the owner key that keeps the name active.¶

Lease record:

The complete verifiable ownership payload for a name, including reveal material and the most recent valid heartbeat.¶

Challenge:

A VDF-backed attempt to claim an inactive or expired name.¶

Beacon:

A publicly verifiable randomness source. This document uses drand as the initial beacon profile.¶

DHT:

A Kademlia-like distributed hash table used as an untrusted storage and retrieval substrate.¶

3. Protocol Overview

The Kinetic lifecycle has four phases:¶

1. Commit: the claimant creates a hidden commitment to the name, beacon round, salt, and owner key.¶

2. Delay: the claimant evaluates a VDF over the commitment.¶

3. Reveal: the claimant publishes a signed lease record containing the VDF output and proof.¶

4. Maintain: the owner publishes signed heartbeats. If heartbeats stop, other participants can attempt deterministic challenge and reclamation.¶

The DHT is not trusted to decide ownership. It only transports records. Clients and peers decide validity by applying the deterministic validation rules in this document.¶

4. Cryptographic Primitives

5. Name Registration

commitment = SHA256("KINETIC-COMMIT-v1" ||
                    name ||
                    salt ||
                    beacon_round ||
                    beacon_randomness ||
                    owner_public_key)

difficulty = Difficulty(name, beacon_round, parameter_set)

{
  "type": "kinetic.reveal.v1",
  "name": "example.kin",
  "salt": "base64url...",
  "beacon_round": 1234567,
  "beacon_randomness": "base64url...",
  "owner_public_key": "ed25519:base64url...",
  "vdf": {
    "suite": "vdf-wesolowski-classgroup-v1",
    "difficulty": 10000000,
    "input": "base64url...",
    "output": "base64url...",
    "proof": "base64url..."
  },
  "signature": "base64url..."
}

6. Heartbeats and Liveness

An active owner maintains a name by publishing heartbeat records. A heartbeat is a signed statement over the name, owner key, current beacon round, and a monotonic nonce.¶

{
  "type": "kinetic.heartbeat.v1",
  "name": "example.kin",
  "owner_public_key": "ed25519:base64url...",
  "beacon_round": 1234600,
  "nonce": 42,
  "signature": "base64url..."
}

A validator MUST reject a heartbeat unless:¶

• The signature verifies under the current owner key.¶

• The heartbeat name matches the associated lease record.¶

• The beacon round is valid and not older than the previous accepted heartbeat for the same lease record.¶

• The nonce is greater than the previous accepted nonce for the same lease record.¶

This document does not require a heartbeat every beacon round. Exact heartbeat intervals are deployment parameters and MUST be included in the active parameter set.¶

7. Reclamation and Challenges

If a valid heartbeat has not been observed for a name within the configured active interval, the name becomes inactive. Inactive names can be challenged by computing a challenge VDF whose difficulty is derived from the elapsed beacon rounds since the last valid heartbeat.¶

The challenge difficulty function has the abstract form:¶

challenge_difficulty =
  ChallengeDifficulty(name, last_heartbeat_round, current_round, parameter_set)

The function SHOULD make very recent inactive names expensive to challenge and older inactive names less expensive to reclaim. The function MUST be deterministic.¶

A successful challenge does not by itself prove that the old owner has lost the name. A deployment MAY define a challenge response window during which the previous owner can publish a fresh heartbeat to invalidate the challenge.¶

8. DHT Storage and Retrieval

Kinetic uses a DHT as an untrusted data transport. A node receiving a Kinetic record MUST validate the record before storing or forwarding it as a valid record.¶

To reduce single-key censorship risk, a lease record SHOULD be stored at multiple deterministic keys:¶

dht_key_i = SHA256("KINETIC-DHT-v1" || name || i)

where i is an integer in the range 0..M-1. The replication count M is a deployment parameter. Clients SHOULD query multiple keys and take the union of returned records before applying local validation and selection.¶

9. Record Selection

When a client obtains multiple valid lease records for the same name, it MUST select a single winning record deterministically.¶

This document defines the following provisional ordering:¶

1. Prefer the valid record with the earliest beacon round used in the initial reveal.¶

2. If two records use the same reveal beacon round, prefer the record whose VDF output has the smallest XOR distance to the next valid beacon randomness value after the reveal round.¶

3. If records remain tied, prefer the lexicographically smallest canonical record digest.¶

This ordering is intended to remove network latency as a deciding factor. A future version of this document should analyze whether earliest-round selection creates undesirable long-range behavior and whether checkpointing or bounded history rules are needed.¶

10. Light Client Resolution

A light client need not participate in the DHT. It MAY obtain records from one or more untrusted HTTPS gateways. Gateways are data transports only. They do not decide ownership and need not be trusted.¶

A light client resolving a name SHOULD:¶

1. Query at least three independently operated gateways.¶

2. Request records for all deterministic DHT keys for the target name.¶

3. Validate all returned records locally.¶

4. Apply the deterministic record selection algorithm.¶

5. Return the selected owner key or report that no valid record was found.¶

A gateway can censor by omission, but it cannot forge valid records without the owner key and VDF proof. Querying multiple independent gateways reduces omission risk.¶

11. Parameter Sets

Kinetic deployments require shared parameters, including:¶

• name syntax rules;¶

• VDF ciphersuite;¶

• registration difficulty function;¶

• challenge difficulty function;¶

• heartbeat interval;¶

• challenge response window;¶

• DHT replication count; and¶

• accepted beacon network identifiers.¶

This draft intentionally marks the concrete parameter set as provisional. Interoperable public deployments MUST NOT claim conformance to a final Kinetic profile until these parameters are fully specified.¶

12. IANA Considerations

This document has no IANA actions.¶

A future version might request registries for Kinetic record types, VDF suites, signature suites, beacon profiles, and well-known service identifiers.¶

13. Security Considerations

Kinetic assumes that adversaries can observe, delay, replay, omit, and inject DHT traffic. Correct implementations MUST treat the network and gateways as untrusted.¶

Commitments are intended to prevent front-running. The beacon value prevents precomputation before the referenced round. Binding the owner key into the commitment prevents a third party from reusing another claimant's completed VDF under a different key.¶

The VDF difficulty is the primary Sybil-resistance mechanism. If the VDF is parallelizable, incorrectly parameterized, or too cheap for the target deployment, attackers can register names at scale. Public deployments require empirical calibration, independent cryptographic review, and a clear upgrade story.¶

The DHT can be attacked through eclipse, spam, storage exhaustion, and censorship by omission. Implementations SHOULD validate before storing, replicate records across deterministic independent keys, rate-limit invalid traffic, and avoid treating any single gateway or peer as authoritative.¶

Heartbeat loss can occur for benign reasons such as device failure, key loss, network partition, or long-term offline use. Challenge parameters that are too aggressive can cause accidental loss of names. Parameters that are too lenient can preserve abandoned names indefinitely.¶

Private keys control names. A compromised owner key allows an attacker to publish valid heartbeats and update higher-layer identity bindings. Users need secure key storage and recovery mechanisms. Those recovery mechanisms are out of scope for this document.¶

Beacon dependence creates availability and governance questions. If the configured beacon becomes unavailable or distrusted, implementations need a deterministic transition path. This draft does not yet specify that path.¶

14. Privacy Considerations

Kinetic records are public. Heartbeat cadence can reveal that an owner is online or offline. Gateway queries can reveal user interest in specific names. Clients concerned with privacy should query multiple names together, use privacy-preserving transports where available, and avoid sending identifying metadata to gateways.¶

15. Operational Considerations

Operators of gateways and DHT nodes should expect invalid traffic. They should apply strict parsing, bounded memory use, record-size limits, signature verification before storage, and per-peer rate limits.¶

Implementations should expose clear diagnostics for VDF verification failures, beacon verification failures, stale heartbeats, and conflicting lease records.¶

16. References

Appendix A. Acknowledgements

The protocol design discussed in this document draws on prior work in Kademlia-style routing, verifiable delay functions, threshold randomness, and self-authenticating records.¶

Author's Address