Kaspa Testnet 12 covenants moved KIP-17-oriented code from an integration branch into a separate, participatory test network in early January 2026. TN12 added dedicated network parameters, genesis data, a P2P port, and operator instructions for nodes, mining, and generated transactions. It was an experimental environment with valueless coins, not a Kaspa mainnet activation.

Key takeaways

• Rusty Kaspa PR #802 added Testnet 12 configuration and documentation to the covpp branch on January 4.
• The January 5 guide identified --testnet --netsuffix=12, P2P port 16311, and a node, CPU miner, and Rothschild transaction generator as the test components.
• KASmedia reported on January 6 that TN12 was evaluating covenants introduced through KIP-17-oriented work.
• A testnet can reveal consensus, resource, wallet, and operational problems without putting mainnet funds at risk.
• TN12 participation or a successful test did not guarantee a production activation date, security, or application readiness.

What evidence shows that Testnet 12 was created?

The strongest primary evidence is the Rusty Kaspa review history. PR #802, “Adding testnet 12” merged two commits into covpp on January 4, changing four files: genesis configuration, consensus parameters, network identification, and a new docs/testnet12.md guide. Follow-up PRs #803, #804, and #805 fixed wallet parameters and corrected that guide by January 5.

The January 6 KASmedia report supplied contemporaneous community context and linked the public discussion that described TN12 as covenant testing. KASmedia is a secondary publication; the GitHub diffs establish what code and documentation actually changed.

This layered sourcing matters. A social post can explain intent quickly, while immutable commits let a reader verify configuration, branch, commands, and revision history.

What did Kaspa Testnet 12 covenants test?

KIP-17-oriented covenants allow a UTXO’s spending rules to inspect and constrain selected properties of the transaction spending it. Instead of authorizing only with a signature, a prototype script can require a particular next output, transaction structure, or state transition. Our earlier Kaspa KIP-17 implementation analysis explains the underlying script-engine and activation changes.

TN12 added the network setting in which those rules could encounter real peer-to-peer conditions. Participants could operate nodes on different hardware, mine test blocks, generate transactions, observe synchronization, and report failures. That broadens testing beyond unit vectors because networking, storage, RPC services, wallets, miners, and user configuration all interact.

It still does not prove that every covenant construction is safe. Application-specific contracts need separate reviews for authorization, state transitions, fees, replay behavior, recovery, resource use, and adversarial inputs.

How was the January 2026 test network separated from other networks?

The January 5 version of docs/testnet12.md instructed operators to clone the covpp branch and run kaspad with --testnet --netsuffix=12 --utxoindex. It assigned dedicated P2P port 16311 so TN12 nodes would not automatically peer with the usual Testnet 10 network.

That document is historical and branch-specific; commands and requirements can change after publication. The important design principle is network separation. Distinct genesis data, network identifiers, ports, and address prefixes help prevent experimental nodes from treating mainnet data as test data or vice versa.

Operators were also instructed to use a testnet miner and Rothschild, a load generator that sent funds from a test wallet back to itself at a configured rate. The guide recommended varied transaction rates rather than having every participant create identical load.

Why did hardware and participant diversity matter?

A test run entirely on one developer’s machine can miss failures caused by slower disks, limited memory, geographic latency, intermittent peers, or configuration differences. The TN12 guide encouraged people to describe their hardware and experience in the community testnet channel. Its suggested baseline was 16 GB of RAM, an eight-core CPU, and an SSD with at least 250 GB free, while noting a possible lower-memory setting.

Those figures were participation guidance, not a permanent minimum for Kaspa. A useful test report would capture node version, CPU, RAM, disk type, network location, uptime, transaction rate, synchronization time, resource peaks, rejected transactions, and exact error logs. Without that context, “it worked” or “it failed” is difficult to reproduce.

What could TN12 prove, and what could it not prove?

TN12 could show whether a particular build formed a network, produced blocks, propagated transactions, enforced test covenant rules, and operated under observed loads. Repeated tests could uncover consensus disagreements, performance bottlenecks, wallet incompatibilities, or confusing operator instructions.

It could not by itself establish mainnet safety. Test value has no economic incentive comparable to production funds, participant scale may be smaller, and attackers may behave differently. A clean test period also cannot guarantee the absence of rare bugs. Mainnet consideration requires defined activation rules, code review, stable tooling, migration planning, and evidence collected over time.

How should developers participate safely?

Use only valueless TN12 funds and a fresh key created for the experiment. Never paste a mainnet private key into a test tool, and do not expose node RPC interfaces to the public internet without authentication and network controls. Pin the documented commit or branch, save logs, and report the exact command and environment when filing an issue.

The January guide’s examples are evidence of the original rollout, not an instruction to run an old branch indefinitely. Check the current repository and community testnet channel before joining a later phase. For a wider view of how this work fits with 2025 milestones, see our Kaspa price and fundamentals review.

Frequently asked questions

Was TN12 the same network as Kaspa Testnet 10?

No. TN12 used network suffix 12, dedicated genesis/configuration data, and P2P port 16311 to remain separate from the usual testnet.

Were TN12 coins real KAS?

No. Testnet coins are valueless experimental units. They should never be sold, represented as mainnet KAS, or protected with a reused mainnet key.

Did TN12 confirm a KIP-17 mainnet date?

No. The sources document a testing environment. They do not establish a production activation date or guarantee that the tested design would ship unchanged.

Source and verification note

The assigned source is Jennifer Ghelardini and Nicholas Sismil’s January 6, 2026 KASmedia report. Its TN12 description was checked against primary GitHub evidence: PR #802 and the January 5 documentation state at commit 0add22c. This article describes that dated rollout; later TN12 launches or documentation may differ. No claim of mainnet activation, complete security, or production readiness is made.