Getting Started
Two paths. Pick yours.
- Deploying your own network? → You want
kinetic-forge.- Using the
.kinpublic network? → You wantkinetic-daemon.
System Prerequisites
Both paths require the same toolchain.
Required
- Rust toolchain — install via rustup
- C++ compiler — required by the
chiavdfFFI bindings (g++orclang) - GMP library — the Chia VDF engine uses GNU Multiple Precision Arithmetic for large integer math
Ubuntu / Debian:
sudo apt update && sudo apt install build-essential cmake libgmp-devmacOS (Homebrew):
brew install cmake gmpClone and Build
git clone https://github.com/saifmukhtar/kinetic.git
cd kinetic
cargo build --release⚠️ Always build in
--releasemode. The VDF computation is highly sensitive to compiler optimizations — debug mode makes name registrations unbearably slow.
Path A: Deploy Your Own Network
For universities, companies, governments, and communities who want a sovereign namespace under their own TLD.
Step 1: Run kinetic-forge
kinetic-forge is the interactive wizard that generates your network.json — the single file that defines your entire network identity.
./target/release/kinetic-forgeIt will ask you for:
- Your TLD (e.g.
uni,acme,internal) - Your organization's base domain
- VDF difficulty (it will benchmark your hardware automatically)
- Name recycling period (how long idle names survive)
- Whether to enable Phase 2 governance auto-lock
When it finishes, you will have:
- A fully configured
network.json - A generated governance keypair in
./keys/— keep these offline
Step 2: Recompile with Your Network Config
cargo build --release --workspaceAll binaries now have your network's constants compiled in. Every node your users run will share identical cryptographic constants — there is no runtime config drift possible.
Step 3: Launch Your Bootstrap Nodes
Run kinetic-node on at least two stable servers. These are the DHT entry points for everyone on your network:
# On your server:
sudo ./target/release/kinetic-node
# The peer ID is printed to stdout when kinetic-node starts.
# You can also retrieve it from the node's local API:
curl http://127.0.0.1:<node_api_port>/peer_idUpdate bootstrap_nodes in your network.json with these addresses, recompile, and distribute the binaries to your users.
Step 4: Distribute
Users on your network install kinetic-daemon and kinetic-cli built from your network.json. They run the daemon, register names under your TLD, and resolve them natively in their browser — same workflow as the .kin network, but entirely under your control.
→ Full details: Fork Your Own Network
Path B: Use the .kin Network
For developers and builders using the canonical public network — no operator, no fees, no permission required.
Step 1: Launch the Daemon
The kinetic-daemon runs continuously in the background. It handles:
- Your local Kademlia DHT peer connection to the
.kinnetwork - Split-DNS on port
53— intercepts.kinqueries, passes everything else through - Local REST API on
127.0.0.1:16001
Because binding port 53 is a privileged operation on Linux and macOS, run with sudo:
sudo ./target/release/kinetic-daemonOnce running, the daemon logs will confirm it has connected to the bootstrap DHT swarm and initialized the local Sled database.
Step 2: Register Your Name (Two-Phase Protocol)
Kinetic uses a Grind → Commit → Reveal protocol to prevent front-running. No one can snipe your name because the commitment is blind and is published only after the VDF work is done.
Phase 1: Commit & Grind
kinetic register example.kinWhat happens:
- The CLI fetches the latest
drandQuicknet pulse (the randomness beacon) to use as the starting seed. - Starts the VDF computation — your CPU will run at full load. Time depends on name length:
| Name length | Approximate time |
|---|---|
| 8+ characters | ~2 hours |
| 6 characters | ~12 hours |
| 5 characters | ~1 day |
| 4 characters | ~15 days |
- When the math is done, it hashes your name + random salt + drand pulse + your Ed25519 public key into a blind commitment and broadcasts it to the DHT.
- Waits exactly 32 seconds to mathematically lock the front-running barrier.
- Saves your proof to
~/.local/share/kinetic/zones/example.kin.reveal.json
Phase 2: Configure & Publish
Open ~/.local/share/kinetic/zones/example.kin.json and add your DNS records:
{
"name": "example.kin.",
"records": [
{ "type": "A", "value": "YOUR_SERVER_IP" }
],
"target_kid": "did:kin:kid1abc9f7..."
}Then publish to the global network:
kinetic publish example.kinYour name is live globally. Any device running the Kinetic daemon can now resolve example.kin.
Step 3: Test Resolution
Via dig:
dig @127.0.0.1 example.kin AYou should get an instant response with your A record.
Via browser: Open http://example.kin directly in Chrome or Firefox. The daemon intercepts the DNS query transparently — no browser extension needed.
Verify legacy traffic still works:
dig @127.0.0.1 github.com AThe daemon recognizes github.com does not end in .kin and forwards it to your OS system DNS resolver (read from your system config via read_system_conf()). If the system config cannot be read, it falls back to Cloudflare DNS. Normal internet is unaffected.
Step 4: Keep Your Name Alive (Heartbeat)
Ownership is maintained by a continuous cryptographic heartbeat — a signature broadcast to the DHT proving your node is online. The daemon handles this automatically while it runs.
If your daemon goes offline for an extended period, the name enters Grace-Period Escalation — attackers must compute an exponentially harder VDF to challenge it, and you can reclaim it instantly by bringing your daemon back online during the challenge window.
→ Full details: Heartbeats & Stealing
What You Just Did
You registered a name without:
- A credit card
- A username or account
- Permission from a corporation or government
- Paying anyone, ever
Your ownership is secured entirely by cryptographic proofs stored across a global decentralized hash table. No ISP can censor your name. No registry can revoke it. No speculator can outbid you.
Welcome to Kinetic.