HardKAS / local runtime docs

HardKAS Documentation

HardKAS is a deterministic, local-first developer operating system for Kaspa and Igra workflows. It gives developers a reproducible CLI, local runtime, dashboard, artifact engine, RPC diagnostics, wallet adapters and L1/L2 simulation tools without pretending to be a production wallet, consensus client or trustless bridge.

Get Started CLI Reference Security Model GitHub

0.7.9-alpha Kaspa Native Igra-aware Local-first Artifact-first Deterministic tooling

local first run simnet

first run

pnpm install -g @hardkas/cli@alpha
hardkas doctor --json
hardkas capabilities --json
hardkas local wizard
hardkas dev server --open

CLI sessions artifacts dashboard

Alpha boundary. HardKAS is developer infrastructure. It is not production custody software, not a Kaspa consensus implementation, not a hosted relay and not a trustless bridge implementation.

What is HardKAS?

Local runtime

A local developer cockpit around Kaspa/Igra workflows: sessions, dev server, dashboard, SSE invalidation, Docker node orchestration and local state.

Artifact engine

Security: Strict path traversal boundaries prevent reading/writing outside the .hardkas/ workspace.

Plan, sign, send, receipt, trace and replay artifacts with canonical hashes, lineage metadata and reproducibility checks.

Protocol tooling

Kaspa RPC diagnostics, local wallet tools, DAG simulation, Igra L2 profiles, bridge assumption checks and local bridge simulation.

HardKAS is	HardKAS is not
Developer tooling for local Kaspa/Igra workflows.	A production wallet, hosted service or custody platform.
A deterministic artifact workflow for planning, replaying and inspecting transactions.	A Kaspa consensus validator or replacement for rusty-kaspa/kaspad.
A bridge-aware local simulator with explicit assumptions.	A trustless bridge. Trustless exit belongs to the future ZK phase.
An AI-friendly repository with machine-readable capabilities.	A framework that lets agents invent unsupported features.

Prerequisites

Dependency	Required for	Install
Node.js ≥ 22.5	All HardKAS commands (uses `node:sqlite`)	nodejs.org
pnpm	Package installation	`npm install -g pnpm`
Docker	`hardkas node start/stop/reset/logs`	docker.com
Solidity compiler	`hardkas l2 contract compile`	Included via Docker or `pnpm add -g solc`

check your environment

hardkas doctor

hardkas doctor checks for missing dependencies and reports what is needed. Use --json for machine-readable output.

Quickstart

Start with diagnostics. HardKAS is intentionally explicit: ask what the runtime supports, then create the local environment, then run workflows.

New project (recommended)

scaffold

pnpm add -g @hardkas/cli@alpha
hardkas new my-kaspa-app
cd my-kaspa-app
pnpm test
hardkas console

Creates a complete project with config, example scripts, tests, and README. Optional flags: --template basic, --network simnet, --accounts 3 (all defaults).

Existing repo

init local runtime

hardkas init
hardkas local wizard --profile igra
hardkas dev doctor --profile igra
hardkas dev server --open

Recommended default. Use simnet or local profiles while developing. Mainnet signing/funding paths are guarded and should stay explicit.

Mental model

PlanBuild a deterministic tx plan or L2 call plan.

SignUse local dev accounts or wallet adapters.

SendBroadcast through configured RPC or local runtime.

ReceiptRecord observed result as an artifact.

TraceInspect lineage, query store and event history.

VerifyCheck hashes, schema, replay invariants and drift.iterate

iterate

●TxPlanUnsigned intent

●SignedTxSigned artifact

●ReceiptObserved result

●TraceRuntime context

●ReplayInvariant check

Developer flow

Local Igra-aware flow

l2 workflow

hardkas local wizard --profile igra --account bob
hardkas l2 profile validate igra --json
hardkas metamask network --profile igra
hardkas metamask account bob --json
hardkas l2 rpc health --network igra --json

Kaspa L1 local flow

l1 workflow

hardkas node start
hardkas kaspa doctor --json
hardkas kaspa wallet create alice --network simnet
hardkas kaspa wallet create bob --network simnet
hardkas kaspa wallet send alice bob --amount 1 --dry-run

What actually works in 0.7.9-alpha

Status	Systems	Notes
Stable	Core safety: atomic persistence, workspace locks, corruption diagnostics, secret redaction, mainnet guards, encrypted keystore, .gitignore protection.	Hardened local developer state.
Stable	Artifact system: canonical hashing v3, verification, lineage, reproducibility proofs, L1 plan/sign/send/receipt/trace pipeline.	Version metadata excluded from hashing.
Stable	Runtime operations: chaos engine (4 actors), doctor, repair, inspect, rotate, rebuild, verify. Event ledger with AppendCoordinator. Telemetry with rotation.	Deterministic PRNG seeds. Exclusive locks + fsync.
Stable	SDK: policy engine (agent/developer), workspace abstraction, artifacts manager with dry-run, RuntimeContext DI, workflow identity from intent hash.	4 policy dimensions. CLI + agent operable.
Experimental	Localnet fork, GHOSTDAG simulator, DAG scenarios, mass profiler, replay verification.	Research/dev tooling, not consensus.
Partial	L2/Igra tx lifecycle, Docker node orchestration, bridge profiles, SSE dashboard.	SSE reconnect exists; durable cursors do not.
Not implemented	Consensus validation, production wallet, SilverScript/covenants, trustless exit, plugin system.	Do not imply in docs or agents.

Sessions

Sessions bind L1/L2 developer context: wallet names, EVM accounts, selected profiles, bridge plans and local runtime state. In 0.7.9-alpha mutating session paths fail closed on corrupt stores and canonical writes use atomic persistence with parent directory fsync.

Typical use

session context

hardkas session create dev --l1 alice --l2 bob
hardkas session use dev
hardkas session status

Safety model

Corrupt session stores are diagnostic-readable but mutation-blocking.
Workspace locks protect mutating paths.
Secrets should be redacted in CLI error paths.
Session state is local developer state, not custody state.

Dashboard and dev server

The dashboard is a local cockpit that visualizes your entire development runtime in real time. It connects to the dev server via SSE and reacts to CLI state changes instantly.

start the runtime

hardkas dev server --port 7420 --open

Alternatively: hardkas dashboard --start-server starts the server and opens the dashboard in one command.

What you see

Session identity

Active session with L1 (Kaspa wallet) and L2 (EVM account) linked identity. Shows wallet names, addresses, bridge mode, and connection status.

Health panel

Real-time status of Kaspa L1 RPC, Igra L2 RPC, and Docker node. Shows DAA score, block height, network ID. Stale indicators appear after 45 seconds without update.

Wallet sync indicators

MetaMask and KasWare panels show whether the browser wallet matches the active session. Mismatch reasons are displayed when address or network differs.

Runtime event stream

Live SSE log showing session changes, health updates, bridge events, and wallet sync events. Capped at 50 entries. Reconnects automatically with backoff on disconnect.

Bridge laboratory

Simulate Kaspa → Igra bridge payloads locally. Deterministic payload generation, prefix mining simulation, and bridge plan inspection — all without touching a real bridge.

WalletConnect sandbox

Simulated WalletConnect pairing for testing mobile wallet UX. Ephemeral sessions, no real relay traffic. Clearly labeled as laboratory-only.

SSE limitation. The dashboard supports reconnect/backoff, but 0.7.9-alpha does not yet provide durable replay cursors or monotonic event IDs. If the dev server restarts, the event stream resets.

CLI ↔ Dashboard sync

The dashboard is not a separate world — it reads from the same session store as the CLI. Run hardkas session use dev in the terminal and the dashboard updates in real time via SSE. No refresh needed.

example flow

# Terminal 1: start dashboard
hardkas dev server --open

# Terminal 2: interact via CLI
hardkas session create dev --l1 alice --l2 bob
hardkas session use dev
# → Dashboard updates instantly via SSE

Docker node workflow

HardKAS can manage a local Kaspa node through Docker for development. It is a lifecycle helper, not multi-node production orchestration.

hardkas node startStart local node. Supports image override and lock wait flags.

hardkas node status --jsonCheck node status in machine-readable form.

hardkas node logs --tail 100 --followInspect local node logs.

hardkas node restartRestart local node with workspace lock protection.

hardkas node stopStop local node.

hardkas node reset --yesPreview-grade destructive reset of local chain data.

Wallets and local accounts

Kaspa wallets

Local L1 wallets for development: create, list, balance, address and send.

Real dev account store

Persistent encrypted account store using safe password input paths and lock protection.

MetaMask helpers

Local EVM account export and Igra network snippets for developer onboarding.

wallet commands

hardkas accounts real init --json
hardkas accounts real generate --name dev --count 1 --network simnet --password-stdin
hardkas metamask network --profile igra --json
hardkas metamask account bob --json

Architecture overview

Kaspa L1

Sequencing / DA / anchoring

Kaspa L1 provides ordering, data availability and state anchoring. It does not execute EVM smart contracts.

HardKAS

Local deterministic tooling

CLI, sessions, artifacts, query store, dev server, dashboard, adapters, bridge simulation and reproducibility checks.

Igra L2

EVM execution

Igra provides L2 EVM execution within the based-rollup architecture class. HardKAS talks to Igra via configured RPC profiles.

Layer	HardKAS responsibility	Boundary
CLI	Human and machine entrypoint, JSON output, diagnostics, lifecycle commands.	Should not hide unsupported trust assumptions.
Sessions	Local workflow context and state binding.	Not custody, not a production account manager.
Artifacts	Deterministic records of plans, signed payloads, receipts and lineage.	Not consensus proof.
Query store	SQLite read model rebuilt from artifacts and events.	Not a chain archive.
React/dashboard	Local UI over dev-server APIs and SSE invalidation.	React must not become runtime authority.

Artifact lifecycle

HardKAS records developer workflows as content-addressed artifacts. The goal is not just “send a tx”; the goal is to explain what was planned, what was signed, what was observed and whether the local replay still makes sense.

Build planintent + inputs

Signlocal key / adapter

SendRPC submission

Receiptobserved result

Tracequery/runtime view

Verifyhash + lineage

hardkas artifact verify path --strictVerify schema, hash and semantic integrity.

hardkas artifact explain pathHuman-readable operational summary.

hardkas artifact lineage pathShow provenance and operational history.

hardkas replay verify .hardkas/artifacts --jsonCheck local replay invariants over artifacts.

Canonical hashing

HardKAS separates semantic content from operational metadata. Hashes are meant to remain stable across fields like runtime version, file path, indexed timestamp or generated identifiers.

hash pipeline

Artifact JSON
  -> strip semantic exclusions
  -> normalize Unicode/newlines
  -> sort keys recursively
  -> stringify BigInt values
  -> SHA-256 contentHash

Release metadata boundary. hardkasVersion is metadata. It must not change semantic content hashes.

Query store

The query store is a rebuildable SQLite read model over artifacts, lineage, events, replay state and simulated DAG information.

hardkas query store sync --jsonSynchronize filesystem artifacts into the query index.

hardkas query store doctor --migrateCheck integrity and apply pending migrations.

hardkas query artifacts list --schema txPlan --jsonList artifacts with deterministic filters.

hardkas query tx <txId> --explain fullAggregate known data for a transaction.

hardkas query lineage chain <anchor> --whyExplain ancestors or descendants of an artifact.

hardkas query events --domain tx --limit 50Inspect event log entries.

Replay and reproducibility

Replay in HardKAS means local workflow reproducibility: artifact invariants, receipt consistency, divergence indicators and deterministic reconstruction. It does not mean Kaspa consensus validation.

Replay commands

hardkas replay verify path --jsonVerify replay invariants for a directory.

hardkas query replay listList stored receipts.

hardkas query replay summary <txId>Detailed receipt and trace summary.

hardkas query replay divergences --jsonDetect replay divergence indicators.

Boundary

consensusValidation is unimplemented.
Replay is local workflow verification.
Golden hashes and CI matrix prove artifact reproducibility, not chain correctness.

Chaos engine

hardkas chaos formalizes destructive behavior into deterministic, reproducible campaigns. It uses a seeded LCG PRNG (MINSTD) so every campaign is reproducible from its seed.

LockHell

Injects stale locks, zero-byte TOCTOU locks, concurrent rebuilds.

RotBot

Corrupts JSONL streams with truncated JSON, garbage bytes, schema violations.

DriftHunter

Deletes SQLite, mutates projection inputs, verifies rebuild from artifacts.

HumanChaos

Runs invalid commands and operator mistakes to detect raw stack trace leaks.

chaos campaigns

hardkas chaos --runs 300 --seed 1337 --profile smoke
hardkas chaos --runs 3000 --seed 1337 --profile targeted
hardkas chaos --actor LockHell --runs 500 --seed 404
hardkas chaos replay --run-seed 42

Exit code	Meaning
0	No findings.
1	Recoverable findings.
2	Invariant violation (includes raw stack trace leaks).
3	Unsafe configuration refused.
4	Internal chaos engine failure.

Isolation. Chaos runs in an isolated workspace by default and refuses unsafe current-directory destruction without explicit opt-in.

Operator commands

HardKAS is designed to fail loudly and recover explicitly. Operator commands exist so developers do not repair runtime state by hand.

`hardkas doctor`

Full workspace diagnostic: locks, JSONL streams, projection health, anomalies, authority status.

`hardkas repair`

Recover JSONL tails, clear stale locks, rebuild SQLite, quarantine malformed files. Use --dry-run first.

`hardkas inspect`

Report stream sizes, archive segments, workspace metadata and operational status.

`hardkas rebuild`

Rebuild SQLite projections from canonical artifacts. --from-artifacts flag.

`hardkas rotate`

Rotate telemetry archives. Event ledger rotation is intentionally not supported (append-only by contract).

`hardkas verify`

Validate artifacts, semantic bundles and replay-relevant invariants.

No silent recovery. Any automatic repair emits an anomaly or visible operator message. Quiet corruption handling is treated as a runtime bug.

Event ledger and telemetry

HardKAS separates two operational streams with different retention semantics:

Event ledger (`events.jsonl`)

Append-only operational evidence. Never rotated. Each event carries eventId, causationId, domain, and kind. Protected by AppendCoordinator with exclusive locks and fsync.

Telemetry (`telemetry.jsonl`)

Rotatable observability stream. 8 anomaly types: LOCK_CONTENTION, STALE_LOCK_RECOVERY, FS_RETRY, NORMALIZATION_COLLISION, EXTERNAL_MUTATION, PATH_TRAVERSAL_ATTEMPT, ORPHAN_PROJECTION_RECOVERY. Scoped via AsyncLocalStorage.

AppendCoordinator. JSONL persistence uses exclusive file locks (openSync("wx")), spin-wait acquisition, automatic tail repair for corrupted JSON, and fsync after every write.

Kaspa L1 vs Igra L2

System	Role	HardKAS treatment
Kaspa L1	Proof-of-work blockDAG, sequencing, data availability, state anchoring and finality via GHOSTDAG / future DAGKnight model.	HardKAS queries RPC, manages local wallets and simulates workflows. It does not validate consensus.
Kasplex L1	Asset hub for native asset issuance and transfer on Kaspa L1.	Distinguished from Kasplex L2 architecture terminology.
Igra L2	EVM-compatible L2 execution environment in the based-rollup architectural class.	HardKAS provides profiles, RPC health, balance/nonce queries, tx build/sign/send/status and contract deploy planning.
Bridge phases	Pre-ZK → MPC/committee-style assumptions → ZK exit phase.	Pre-ZK bridge workflows are assumption-aware; trustless exit is false until ZK phase.

No EVM on Kaspa L1. HardKAS documentation and examples must preserve this boundary. Execution happens on L2, not on Kaspa L1.

Bridge local simulation

Bridge local commands model developer bridge-entry flows. They are deterministic local simulation utilities, not a production bridge implementation.

bridge local

hardkas bridge local plan --session dev --amount 10 --json
hardkas bridge local simulate --session dev --amount 10 --prefix abc --json
hardkas bridge local inspect <txid> --json
hardkas l2 bridge assumptions --json

Field	Expected meaning
`trustlessExit`	`false` in pre-ZK phase.
`l2BridgeCorrectness`	Unimplemented unless explicitly implemented in source.
`phase`	Used to distinguish current assumption model from future ZK exit.

RPC diagnostics

HardKAS includes L1 and L2 RPC diagnostics so tools and agents can inspect runtime readiness instead of guessing.

hardkas rpc healthCheck Kaspa RPC availability.

hardkas rpc infoShow RPC connection information.

hardkas rpc doctor --endpoints a,bRun endpoint diagnostics.

hardkas rpc dagShow DAG information from node.

hardkas rpc mempool [txId]Inspect mempool status.

hardkas rpc utxos <address>Query UTXOs for an address.

hardkas l2 rpc health --network igra --jsonCheck Igra RPC health.

hardkas l2 profile validate igra --jsonValidate L2 profile configuration.

DAG simulation

DAG commands and query views are research/dev tooling. They are useful to inspect conflicts, selected-path movement and local scenarios, but they are not rusty-kaspa validated consensus parity.

hardkas dag statusView current local simulated DAG status.

hardkas dag simulate-reorg --depth 1Simulate a local DAG reorg.

hardkas query dag conflicts --whyExplain local double-spend conflict analysis.

hardkas query dag sink-pathShow selected path from genesis to sink.

hardkas query dag displacedShow displaced transactions.

hardkas query dag history <txId> --whyTrace simulated DAG lifecycle for a transaction.

CLI reference

The CLI reference is generated from the Commander command tree. Do not maintain flags manually in docs; regenerate from code.

Core and diagnostics

hardkas doctorFull system diagnostic and health report.

--json Machine-readable output

hardkas capabilitiesMachine-readable capability and trust-boundary report.

--json Machine-readable output

hardkas init [name]Initialize HardKAS config in a project.

hardkas new <name>Create project scaffolding.

`--template <type>`	Project template (default: basic)
`--network <name>`	Default network (default: simnet)
`--accounts <n>`	Number of simulated accounts (default: 3)
`--skip-install`	Skip pnpm install

hardkas config show --jsonShow resolved configuration.

hardkas networksList configured networks.

--json Machine-readable output

Development runtime

hardkas dev doctor --profile igra --jsonValidate Igra/local dev readiness.

hardkas dev serverStart local dev server and dashboard.

`--port <n>`	Server port (default: 7420)
`--host <host>`	Bind host (default: localhost)
`--open`	Open dashboard in browser
`--unsafe-external`	Allow non-localhost connections

hardkas dashboard --start-serverOpen dashboard, starting server when needed.

hardkas local wizard --profile igraGuided local setup.

hardkas consoleInteractive REPL with SDK loaded.

`--network <name>`	Network name (default: simnet)
`--accounts <n>`	Simulated accounts (default: 3)
`--balance <sompi>`	Initial balance per account

hardkas run <script>Run TS/JS file with HardKAS harness injection.

`--network <name>`	Network name (default: simnet)
`--accounts <n>`	Simulated accounts (default: 3)
`--balance <sompi>`	Initial balance per account
`--no-harness`	Skip harness injection

hardkas test [pattern]Run project tests with HardKAS test helpers.

`--mass-report`	Show mass/fee report after tests
`--mass-snapshot <label>`	Save mass snapshot for regression
`--mass-compare <label>`	Compare against saved snapshot

Accounts and wallets

hardkas session create <name>Create a local developer session binding L1/L2 identities.

`--l1 <wallet>`	Name of the Kaspa L1 wallet (required)
`--l2 <account>`	Name of the Igra L2 account (required)

hardkas accounts list --jsonList configured accounts.

hardkas accounts balance <identifier> --jsonShow account balance.

hardkas accounts real initInitialize encrypted dev account store.

hardkas accounts real generateGenerate persistent dev accounts.

hardkas accounts real importImport an account safely.

hardkas accounts real session-open <name>Verify keystore access and mark local signing intent.

hardkas kaspa wallet create <name>Create local Kaspa wallet.

hardkas metamask network --profile igraShow MetaMask local Igra network settings.

Kaspa L1 and node

hardkas node startStart Docker Kaspa node.

hardkas node status --jsonCheck node status.

hardkas kaspa doctor --jsonVerify local Kaspa L1 readiness.

hardkas kaspa wallet send from to --amount 1 --dry-runPlan local wallet send.

hardkas faucet <identifier> --amount 1000Local-only funding helper.

hardkas localnet fork --network testnet-10 --jsonFork UTXO state into local simulation preview.

Igra L2

hardkas l2 networks --jsonList L2 profiles.

hardkas l2 profile show igra --jsonShow Igra profile details.

hardkas l2 balance <address> --network igra --jsonCheck L2 balance.

hardkas l2 nonce <address> --network igra --jsonCheck L2 nonce.

hardkas l2 tx build --from ... --to ... --value 0 --jsonBuild L2 transaction plan.

hardkas l2 tx sign plan.json --account bobSign L2 plan.

hardkas l2 tx send signed.json --yesSubmit signed L2 transaction.

hardkas l2 contract deploy-plan --bytecode 0x...Build L2 contract deployment plan.

Artifacts, query and replay

hardkas deploy track <label>Track deployment status and link it to artifacts.

`--network <name>`	Network where deployed
`--tx-id <txId>`	Transaction ID
`--plan <artifactId>`	Reference to plan artifact
`--status <status>`	Deployment status (default: sent)
`--notes <text>`	Notes

hardkas artifact verify path --strictVerify artifact integrity.

hardkas query store sync --jsonIndex artifacts into SQLite read model.

hardkas query artifacts list --limit 100List indexed artifacts.

hardkas query artifacts inspect <target> --explain fullDeep structural analysis.

hardkas query lineage chain <anchor> --whyExplain artifact lineage.

hardkas replay verify path --jsonVerify local replay invariants.

Fork state and test deterministic hashing

localnet

hardkas localnet fork --network testnet-10
hardkas tx plan --to qz... --amount 1000
hardkas tx sign ./artifacts/plan.json --account dev
hardkas verify --strict

sample output

Strict verification:
  Sorting:     byte-level deterministic
  Boundaries:  enforced (.hardkas/ context)
  Hash match:  passed

Replay causal graph from a crashed workspace

replay

hardkas doctor --json
hardkas repair --dry-run
hardkas rebuild --from-artifacts
hardkas replay verify path --json

sample output

Rebuild complete:
  Events parsed:  1542
  Artifacts:      128
  Conflicts:      0

Replay Verification:
  Status:         VERIFIED
  Causal Graph:   intact

Package map

Package / area	Purpose
`@hardkas/cli`	Commander-based CLI entrypoint and command groups.
`@hardkas/core`	Shared core utilities and primitives.
`@hardkas/artifacts`	Canonical artifact schemas, hashing and verification.
`@hardkas/sessions`	Local session state and persistence.
`@hardkas/dev-server`	Local Hono server, health endpoints and SSE invalidation.
`@hardkas/react`	React hooks and provider integration for local dashboard/runtime use.
`@hardkas/bridge-local`	Deterministic local bridge-entry planning and simulation.
`@hardkas/query-store`	SQLite index and query read model.
`@hardkas/wallet-adapter`	Wallet adapter boundary and local wallet connection helpers.
`@hardkas/sdk`	Convenience aggregation surface. Keep browser/runtime boundaries explicit.

Security model

Implemented safety rails

Atomic persistence with temp+rename+fsync behavior.
Workspace locks with stale detection.
Corruption diagnostics and strict mutation paths.
Secret redaction in CLI error paths.
Mainnet guards for signing/faucet/fund operations.
Encrypted dev keystore using Argon2id + AES-GCM.

Explicit non-goals

No production wallet guarantee.
No Kaspa consensus validation.
No trustless bridge exit in pre-ZK phase.
No claim that DAG simulator equals rusty-kaspa.
No hosted relay or cloud runtime.
No hidden mainnet signing.

Main rule. If a feature is not reported by hardkas capabilities --json, agents and docs should not imply that it exists.

AGENT.md rules

HardKAS is designed to be readable by AI coding agents without letting them invent unsupported behavior.

Rule	Reason
Run `hardkas capabilities --json` first.	Prevents agents from assuming features that are not implemented.
Run `hardkas doctor --json` before runtime work.	Captures local environment readiness.
Prefer `--json` for automation.	Keeps machine workflows stable.
Default to simnet/local profiles.	Avoids accidental mainnet mutation.
Do not invent txids, balances, finality or trustlessness.	Preserves protocol honesty.
Respect trust boundaries.	HardKAS is local developer tooling, not production protocol validation.

Examples

Inspect local environment

diagnostics

hardkas doctor --json
hardkas capabilities --json
hardkas networks --json
hardkas config show --json

sample output

HardKAS Doctor

  ✅ Node.js v22.5.0 (≥ 22.5 required)
  ✅ pnpm 9.1.0
  ✅ .hardkas/ exists
  ✅ .gitignore protects .hardkas/
  ⚠️ store.db not found (run hardkas query store rebuild)
  ✅ No stale locks
  ❌ Docker not reachable
  ⏭️ RPC check skipped (no node running)

  Summary: 5 passed, 1 failed, 1 warning, 1 skipped

sample output (truncated)

{
  "version": "0.7.9-alpha",
  "maturity": "hardened-alpha",
  "capabilities": {
    "artifacts": true,
    "deterministicHashing": true,
    "workspaceLocks": true,
    "consensusValidation": false,
    "silverScript": false
  }
}

Create and inspect an L2 transaction plan

l2 tx

hardkas l2 tx build --network igra --from 0x... --to 0x... --value 0 --data 0x --json
hardkas l2 tx sign ./artifacts/l2-plan.json --account bob --json
hardkas l2 tx send ./artifacts/l2-signed.json --yes --json
hardkas l2 tx receipt <txHash> --json

sample output

L2 transaction plan:
  Network: igra
  From:    0xbob...
  To:      0xreceiver...
  Value:   0
  Status:  planned

Signed artifact:
  Artifact: l2-signed-tx
  Hash:     sha256:8f2c...

Send result:
  Status: accepted
  TxHash: 0xa1b2c3d4e5f6...

Index and explain artifacts

query

hardkas query store sync --strict --json
hardkas query artifacts list --sort createdAt:desc --limit 20
hardkas query artifacts inspect <contentHash> --explain full
hardkas query lineage chain <artifactId> --why

sample output

Query store sync
  Indexed artifacts: 42
  New records:       3
  Strict mode:       passed

Latest artifacts
  tx-plan     sha256:91ab...
  signed-tx   sha256:2f7c...
  receipt     sha256:19ed...

Lineage
  TxPlan → SignedTx → Receipt → ReplayCheck

SQLite query store diagnostics and event tracing

query store

hardkas query store doctor --migrate
hardkas query events --domain tx --limit 10
hardkas query tx 0xa1b2... --explain full

sample output

Store Doctor:
  Migrations:  up to date
  Schema:      v4
  Health:      passed

Tx Explain:
  TxId:       0xa1b2...
  Domain:     tx
  Events:     [PlanCreated, Signed, Broadcast, ReceiptObserved]
  Lineage:    Plan → Signature → RPC
  Replay:     Deterministic match

FAQ

Does HardKAS execute EVM on Kaspa L1?

No. Kaspa L1 does not execute EVM smart contracts. EVM execution belongs to Igra/Kasplex L2 architecture. HardKAS preserves this distinction.

Is the bridge trustless today?

No. Pre-ZK bridge workflows are assumption-aware. Trustless exit only applies once the ZK phase exists and is explicitly implemented.

Is the DAG simulator consensus-equivalent?

No. It is research/dev tooling for local scenarios. It is not differential validation against rusty-kaspa and not a consensus proof.

Can agents use HardKAS safely?

Yes, if they follow the AGENT.md pattern: inspect capabilities and doctor output first, use JSON outputs, and never assume unsupported capabilities.

What should be linked from the website?

README, CLI reference, what-actually-works status page, AGENT.md, security model, release checklist and examples.

HardKAS Documentation

What is HardKAS?

Local runtime

Artifact engine

Protocol tooling

Prerequisites

Quickstart

New project (recommended)

Existing repo

Mental model

Developer flow

Local Igra-aware flow

Kaspa L1 local flow

What actually works in 0.7.9-alpha

Sessions

Typical use

Safety model

Dashboard and dev server

What you see

Session identity

Health panel

Wallet sync indicators

Runtime event stream

Bridge laboratory

WalletConnect sandbox

CLI ↔ Dashboard sync

Docker node workflow

Wallets and local accounts

Kaspa wallets

Real dev account store

MetaMask helpers

Architecture overview

Kaspa L1

HardKAS

Igra L2

Artifact lifecycle

Canonical hashing

Query store

Replay and reproducibility

Replay commands

Boundary

Chaos engine

LockHell

RotBot

DriftHunter

HumanChaos

Operator commands

hardkas doctor

hardkas repair

hardkas inspect

hardkas rebuild

hardkas rotate

hardkas verify

Event ledger and telemetry

Event ledger (events.jsonl)

Telemetry (telemetry.jsonl)

Kaspa L1 vs Igra L2

Bridge local simulation

RPC diagnostics

DAG simulation

CLI reference

Package map

Security model

Implemented safety rails

Explicit non-goals

AGENT.md rules

Examples

FAQ

`hardkas doctor`

`hardkas repair`

`hardkas inspect`

`hardkas rebuild`

`hardkas rotate`

`hardkas verify`

Event ledger (`events.jsonl`)

Telemetry (`telemetry.jsonl`)