Skip to main content

How to Sign a Transaction

Signing takes a TxPlanArtifact and authorizes its inputs, generating a SignedTxArtifact.

Standard Developer Signing​

In developer workflows, you typically sign using deterministic accounts provisioned by hardkas init (like alice).

hardkas tx sign my-plan.json \
  --account alice \
  --out signed.json

What happens:

  1. HardKAS reads my-plan.json and verifies its contentHash.
  2. It fetches the private key for the local alice account.
  3. It applies Kaspa-compliant signatures to every input defined in the plan.
  4. It links the new SignedTxArtifact to the plan via parentArtifactId.

Checking the Planner Provenance​

Before signing a plan in automated environments, you may want to verify how the plan was constructed using the CLI:

hardkas explain my-plan.json

Look for the Planner Authority in the explanation. If you require absolute parity with Kaspa Core node behavior, you might assert that the plan was generated by KASPA_WASM_GENERATOR rather than SYNTHETIC_SIMULATOR (if using the SDK against a real node).