Secure. Verify. Serve. Build.
Start with the network's real status. L1 mainnet is live; check the mode and payment status before connecting. L2 GPU jobs and agent payments require a later testnet.
1. Mine with a Kaspa-compatible ASIC
MAINNET LIVE — CHECK MODE AND PAYMENT STATUSIceRiver KS0/KS1/KS2/KS3/KS5-class and compatible Bitmain kHeavyHash hardware require no custom firmware. SOLO and PPLNS are operating. Automatic PPLNS payouts are enabled after real payment acceptance.
Create and back up a BTC-K wallet
Download the Windows x64 or macOS arm64 wallet and verify its release files. Generate locally. Record all recovery words offline. Never enter them into a website or pool.
Open the miner dashboard
SOLO uses ports3333-3336. PPLNS uses3332 with automatic payouts enabled. See the full direct-IP/domain URLs and hashrate tiers.
Set the worker identity
Use <complete-btck1s-address>.<unique-worker> as username and x as password. Never enter a wallet unlock password.
Verify, then monitor
Confirm accepted shares, observed hashrate and payout address on the pool page. A green device light alone is not proof of accepted work.
2. Run an independent node
SIGNED RELEASE3.2.13Download the signed 3.2.13 release. Verify SHA256SUMS and the detached signature, chain identity, genesis hash and checkpoint before connecting. Keep RPC on loopback; expose P2P deliberately. See the release verification instructions.
3. Prepare a GPU provider
SPECIFICATION — NOT ACCEPTING PROVIDERSThe L2 provider network is separate from mining. No deposit, stake, license fee or activation payment is currently authorized.
Linux, container runtime, supported NVIDIA drivers, a locally served open model and reliable outbound networking.
Model hash, quantization, VRAM, time-to-first-token, throughput and completion rate.
Registration begins only after a signed provider client, public benchmark protocol and test tokens exist.
4. Build an agent client
EXPERIMENTAL PROFILEDevelopers can design around a payment challenge without buying BTCK today. Keep wallet and model routing as separate modules. A provider publishes a KCU rate; the gateway converts task KCU through a disclosed BTC-K reference into an integer-SatK invoice.
request → KCU quote → HTTP 402 SatK invoice → policy check → local signature
→ network settlement → provider selection → inference
→ signed job receipt → result- Default-deny spending policy
- Per-call, daily and lifetime limits
- Invoice expiry and idempotency
- Private keys never uploaded
- One BTC-K wallet; BTC-K and SatK are display units of the same balance
- 10,000 SatK minimum L2 withdrawal; network fee paid by the system fee reserve
- Model, price, latency and privacy constraints
See the complete design boundaries in the machine-payment and agent-wallet sections.
5. Avoid impersonation and scams
- There is no public DEX, bridge, presale, staking program or GPU activation payment.
- No administrator will ask for a recovery phrase or private key.
- Verify announcements against the release page and artifact hashes.
- Treat unofficial tokens using the Bitcoin K name as unrelated until verified by published chain evidence.