To run a Kaspa devnet node from source, the official rusty-kaspa documentation added a kaspad command using --devnet, unsynced mining, local RPC listeners, and the UTXO index. Pull request #718, merged September 11, 2025, documented this isolated developer setup and warned that block production may begin unevenly while devnet difficulty adjusts.

Key takeaways

• A devnet is an isolated development network; its coins and history are not Kaspa mainnet assets or evidence.
• The merged guide launches kaspad with devnet mode, unsynced mining, loopback RPC endpoints, and UTXO indexing.
• Binding RPC to 127.0.0.1 limits access to the local machine and is safer than exposing a development interface publicly.
• The first blocks may arrive inconsistently while the private network’s difficulty adjusts.
• The pull request added documentation, not new consensus behavior, and developers should use instructions matching their exact rusty-kaspa revision.

What do you need before starting?

Use the official kaspanet/rusty-kaspa repository and follow its current prerequisites for Rust, Cargo, Git, and platform build tools. Work in a separate directory and record the commit or release you test. That revision is part of the result: commands, flags, and data formats can change after a guide is published.

Build only source you have reviewed or obtained from the official repository. A devnet can create wallet and transaction data that look realistic, so label directories, ports, and test credentials clearly. Never import a mainnet seed phrase into a development environment.

The source patch did not specify a production hardware baseline. For a local experiment, monitor CPU, memory, disk use, and logs rather than assuming that a successful launch proves production readiness.

What is the official 2025 devnet command?

Merged rusty-kaspa pull request #718 added this command to the project README:

cargo run --bin kaspad -- --devnet --enable-unsynced-mining --rpclisten=127.0.0.1 --rpclisten-borsh=127.0.0.1 --utxoindex

Run it from the repository root after installing the documented dependencies. Cargo builds the kaspad binary and passes every argument after -- to that binary. The initial build may take substantially longer than a later run because dependencies must be compiled.

Do not copy the command into a mainnet deployment checklist. Its flags intentionally create development behavior, including mining before normal synchronization, and its RPC bindings are selected for a local test workflow.

What does each flag do?

--devnet selects Kaspa’s development-network parameters instead of mainnet or a public testnet. That isolates the experiment and makes it suitable for application tests that should not touch valuable assets.

--enable-unsynced-mining allows mining when the node is not synchronized. The PR explains that this is required on first launch because a newly created devnet has no established network history to synchronize from.

--rpclisten=127.0.0.1 and --rpclisten-borsh=127.0.0.1 bind RPC services to the loopback interface. The documentation says mining software is likely to require the RPC listeners. Because loopback is local-only, another machine cannot connect unless the operator deliberately changes networking and firewall configuration.

--utxoindex enables the UTXO index. The merged README note says it is required in this setup to broadcast mined blocks on the node. Preserve the exact spelling from the command; the explanatory text in the original patch contained a small uxtoindex typo, while the command itself correctly uses utxoindex.

Why can the first blocks be irregular?

Difficulty control responds to observed block production. A fresh private network has little or no recent history and may start with mining conditions that do not match the available local hash rate. PR #718 explicitly warns that it can take time for difficulty to adjust before blocks appear consistently.

That delay is not enough by itself to diagnose a bug. First inspect whether the node finished building, selected devnet, opened the expected local endpoints, enabled the UTXO index, and reports mining activity without fatal errors. Preserve the startup log and exact command when asking for help.

If no progress appears after an appropriate observation period, separate node issues from miner issues. Confirm that the external mining component, if used, targets the devnet node and supported RPC protocol. Do not expose RPC to the internet merely to make a local miner connect.

How do you verify the node safely?

Begin with the process log. It should identify development-network operation and continue running without an unrecoverable database, port, or configuration error. Check that no unrelated application already occupies the intended RPC ports.

Then verify behavior using tooling documented for the same source revision. Confirm that the client reaches the loopback service, identifies the expected network, and observes new devnet blocks or UTXO activity. Keep transaction IDs and log timestamps as test evidence.

Use disposable devnet keys and addresses. The later Kaspa genesis-proof tooling guide covers a different verification task: checking the historical UTXO commitment path. It should not be confused with confirming that a local devnet process started correctly.

What are the main security and testing limits?

Loopback binding is an important default. RPC interfaces can expose control or data that should not be reachable from an untrusted network. If a multi-machine laboratory requires remote access, place it behind explicit firewall rules and an authenticated private network, and consult the current node documentation rather than changing the address casually.

Devnet results also have limited scope. A single-machine network cannot reproduce mainnet peer diversity, latency, adversarial behavior, transaction load, or mining distribution. It is suitable for functional development and deterministic experiments, not for declaring an application mainnet-ready.

When a question remains, record a minimal reproducible case and use a source-linked developer forum. Our article on the Kaspa Q&A launch explains why answers tied to versions, commands, and public evidence are more durable than an isolated chat message.

Frequently asked questions

Are devnet KAS coins worth real money?

No. Devnet data is created for isolated testing and is separate from Kaspa mainnet. Never buy, sell, or represent devnet coins as mainnet KAS.

Why is unsynced mining enabled?

A newly launched devnet has no established peer history to synchronize with. The official 2025 snippet enables mining in that initial unsynchronized state so the development network can begin producing history.

Should RPC listen on a public IP?

Not for this local guide. The documented command binds both listeners to 127.0.0.1. Remote laboratory access requires a separately designed and secured network configuration.

Source and verification note

This guide is grounded in kaspanet’s merged rusty-kaspa PR #718, merged September 11, 2025. The public diff added 18 README lines and includes the exact command, flag notes, and difficulty-adjustment warning reproduced and explained here. Because node software evolves, verify the current README and help output for the exact commit or release you run. This article does not instruct mainnet operation or make mining-return claims.