Skip to main content

Understanding the Result

After executing the Quickstart and exploring the First Transaction, you now have a collection of JSON artifacts sitting in your workspace.

These artifacts are not mere logs; they are cryptographic evidence.

The Evidence DAG​

The sequence of your transaction formed a Directed Acyclic Graph (DAG) of evidence:

TxPlanArtifact ← SignedTxArtifact ← TxReceiptArtifact

Each artifact points backward to its parent via a parentArtifactId. If any file in this chain is altered, the chain breaks.

Identity and Integrity​

When looking at the Receipt in .hardkas/artifacts/receipts/, you'll notice several IDs. It is critical to understand the strict boundaries between them:

  • artifactId: This is the canonical identity of the artifact within HardKAS. It uniquely identifies the event of the artifact's creation and is used by the HardKAS resolver to locate the file.
  • contentHash: This provides integrity. It is a cryptographic hash of the JSON payload. If you manually edit the JSON file, the contentHash will no longer match the payload, and HardKAS will reject it. (Note: contentHash is never used to locate an artifact, only to verify it).
  • txId: This is the Network Identity. It is the hash generated by the Kaspa protocol itself.

Note on planId: Older HardKAS workflows used a planId. This is now maintained strictly for legacy compatibility when resolving historical plans, but it is not a distinct namespace.

For a deeper dive into these namespaces, read the Evidence Model.

Verifying Integrity​

You don't have to trust that the artifacts on your disk are valid. You can mathematically verify them at any time using the CLI.

Run the following command in your project root:

hardkas verify

What this does: HardKAS scans every artifact in the .hardkas/artifacts/ directory. For each one, it:

  1. Recomputes the contentHash to ensure the file was not tampered with.
  2. Validates the JSON payload against the strict HardKAS schemas.
  3. Verifies that the parentArtifactId links back to a valid, existing artifact in the workspace.

What this proves: This proves the integrity of your workspace. It ensures your local developer evidence has not degraded or been maliciously altered.

What this does NOT prove: hardkas verify checks data integrity. It does not perform transaction replay against the Kaspa consensus engine.

Replay (Simulator Only)​

If you executed the transaction in the Simulator, HardKAS supports deterministic replay. This means HardKAS can recreate the exact state of the universe from the moment the transaction occurred and re-evaluate it.

Current Invariant: Replay is strictly unsupported for transactions executed against a real node (Localnet/Mainnet). If you attempt to replay a real-node receipt, HardKAS will fail-closed and return a REPLAY_MODE_UNSUPPORTED error, because historical state reconstruction is unavailable.

Unknown capability: artifacts