The Igra Caravel testnet began a staged rollout on July 21, 2025 as an EVM-compatible Layer 2 experiment connected to Kaspa Testnet 10. Its launch plan moved from network activation to selected node operators and then public access; current Igra documentation now labels Caravel sunset and directs testers to newer networks.

Key takeaways

• KASmedia reported Caravel activation at Kaspa TN10 DAA score 206,700,000 on July 21, 2025.
• Igra planned three stages: network activation, software distribution to selected testers, and public node access.
• The environment targeted Ethereum-compatible tooling and used testnet iKAS; it was not Kaspa Layer 1 mainnet.
• Bridge, attestor, and throughput statements were project claims to be tested, not independent security guarantees.
• Igra’s current network documentation marks Caravel sunset, so old connection instructions should not be treated as active guidance.

What launched on July 21, 2025?

KASmedia’s contemporaneous report Crypto, Finally Legal! included a technical section on Igra Labs. It said the Caravel testnet would activate against Kaspa Testnet 10 at DAA score 206,700,000 and described the system as an EVM-compatible Layer 2.

The distinction between layers is essential. Caravel was an Igra environment designed to use Kaspa testnet in its architecture; it was not a feature switch that added the Ethereum Virtual Machine to Kaspa Layer 1. Applications interacted through Igra’s chain, RPC, contracts, attestors, and bridge assumptions.

The report also described testnet token creation and later wrapping of TN10 KAS into iKAS. Test assets are for software experiments. They are not mainnet KAS and should never be represented as carrying guaranteed monetary value.

How was the Caravel rollout phased?

The announced plan had three operational stages. First came activation on TN10. Second, Igra intended to distribute node software to a selected group of early testers roughly seven to ten days later. Third, after another period of feedback, it planned to make node software publicly available and invite broader participation.

That sequencing reduced the blast radius of early failures. A limited group could observe synchronization, RPC behavior, block production, contract execution, and operational faults before public access. It also meant that “launched” did not imply every user could immediately run a node or rely on stable interfaces.

Dates in a rollout plan are targets, not proof of completion. Strong verification requires release artifacts, hashes, repository commits, reachable RPC endpoints, explorer data, and issue history for each stage.

What did EVM compatibility allow builders to test?

EVM compatibility lets developers use familiar Solidity contracts and Ethereum JSON-RPC libraries. Useful testing goes beyond a sample deployment: check chain IDs, gas estimation, receipts, logs, contract verification, nonces, websockets, and documented differences from Ethereum.

Bridges add a separate state machine. A tester should record the Kaspa testnet entry transaction, Igra-side mint or credit, timing, amount conversion, retry behavior, and what happens when either RPC endpoint is unavailable. A one-way test bridge should never be described as permissionless two-way withdrawal unless the implementation and documentation demonstrate that property.

Our earlier Kaspa testnet roundup explains why each Layer 2, wallet, bridge, and application must be evaluated as a separate component rather than inheriting Kaspa Layer 1’s security claims.

What were attestor nodes supposed to do?

The July report said Igra would bring attestor nodes online after activation. Depending on the protocol, they could support execution, reporting, or Layer 2 agreement. Their trust model must come from Igra’s specification and code, not the label “validator.”

Operators should ask how attestors join, what they sign, how conflicting claims are handled, what penalties can occur, and which party can upgrade contracts or pause bridges. A staking or slashing mechanism can shape incentives, but it does not prove that faults are detectable or that recovery is decentralized.

The source relayed a target of more than 1,000 transactions per second. That was a project objective and testing motivation. A credible throughput result would state transaction type, hardware, node count, duration, latency distribution, failure rate, and whether data and settlement costs were included.

How could testers participate safely?

Use a new wallet created only for the test environment. Never import a seed that controls mainnet KAS, and never send mainnet funds to an address presented by a testnet faucet or bridge. Confirm the network name, chain ID, RPC endpoint, explorer, and contract address through current official Igra channels before signing.

Record reproducible evidence: client version, node commit, timestamp, transaction hash, expected result, actual result, logs, and minimal reproduction steps. Remove keys, tokens, personal data, and IP details before posting a bug report. A failure in a browser wallet or Igra RPC should not be labeled a Kaspa consensus failure without tracing the component boundary.

Developers who need Layer 1 context can use the Rusty Kaspa Workshop #3 guide to understand pruning, consensus services, and repository structure before interpreting node behavior.

What evidence would show that Caravel was progressing?

Useful indicators include independent nodes, reproducible releases, resolved critical issues, stable RPCs, verified contracts, bridge reconciliation across both layers, and public incident reports. Transaction counts need a disclosed workload and methodology.

User counts and social engagement also need context. One automated tester can create many transactions, while a small number of careful developers can find important faults. A testnet’s purpose is learning, not producing a vanity metric.

Most importantly, public testing is not a security audit. Bridges and upgrade controls deserve independent review because a fault can affect custody even when the underlying Kaspa testnet behaves correctly.

Is the Caravel testnet still the current Igra network?

No. Igra’s current Network Info documentation lists Caravel with chain ID 19416 and marks it “Sunset,” directing users to the newer Galleon testnet. That current status does not invalidate the historical July 2025 rollout; it prevents an old article from sending readers to retired infrastructure.

Current builders should use the network and software named in current official documentation. Historical RPC URLs, faucets, and bridge addresses can remain reachable or be repurposed, so they should not be copied from archived announcements.

Frequently asked questions

Was Caravel a Kaspa mainnet hardfork?

No. It was an Igra Layer 2 testnet connected to Kaspa Testnet 10. It did not activate EVM execution on Kaspa Layer 1 mainnet.

Did iKAS equal mainnet KAS?

Testnet iKAS represented value inside the experimental environment. Test tokens carry no guaranteed mainnet value, and bridge trust assumptions must be assessed separately.

Does a sunset label mean the test failed?

Not necessarily. Testnets are often replaced as architecture and software evolve. The meaningful record is what was learned, fixed, documented, and carried into successor networks.

Source and verification note

The dated launch source is KASmedia’s July 21, 2025 report, Crypto, Finally Legal! Major Crypto Bills Pass, specifically its Igra Caravel section. Current status, chain ID, RPC type, and successor guidance were cross-checked against Igra’s official network documentation. Project performance and security statements remain attributed claims, not independent audit conclusions.