Kaspa mining

The two markets

A proof-of-work coin runs two markets at once. The coin market reprices on buyer and seller mood: exchanges, leverage, attention, fear. It can move before lunch. The machine market moves on hardware: miners order ASICs, wait for production, wait for shipping, find hosting, wire power, tune firmware, join pools. None of that happens in an afternoon.

Price can fall while hash rate keeps rising, because machines ordered months earlier are still arriving on trucks. Hash rate can fall while the network sits far above where it stood a year prior. Used ASIC prices can collapse after new production overshoots demand that already cooled.

Miners chase margin. Holders chase an exit or hold through it. Buyers chase a price they can stomach. ASIC makers chase order volume. None of them has to be irrational: the lag between the two markets does the rest of the work. The July snapshot above carries that lag in one panel, a price downtrend and a multi-year hash-rate buildout, both true at once.

Visual shelf: market lag and miner margin

Cycle model

Coins and ASICs heat and cool at different times

@Themooseisloos5 has framed Kaspa's coin-and-ASIC cycle as a Carnot-engine style model. The metaphor is secondary. The lag it's pointing at is the mechanism worth tracking, and it cycles through four phases.

Kaspa compressed several discovery phases that took Bitcoin years into one short window: fair launch, fast emissions, GPU mining, an ASIC transition, exchange discovery, and price discovery all landed close together, followed by a large mining buildout. Bitcoin's early distribution, hardware maturation, exchange access, and public understanding all spread out over a much longer stretch. Compression cuts both ways. A bigger up and a bigger down both become more likely, and whether that produces a stronger base is not visible in real time. It shows up one, two, five years later, if it shows up at all.

Kaspa's fast emission schedule moves supply toward its cap quickly, which is part of the hard-money thesis. The same speed front-loads distribution pressure. Early miners and early participants earned coins by running hardware, with no allocation sold up front. That's the fair-launch case. It also means the early market absorbs a steady flow of coins moving from early miners and holders into later buyers: some take profit, some miners sell to cover power and hardware bills, some holders panic, some accumulate. Fair distribution on paper can still produce an ugly chart.

Conviction usually gets tested on the downside. The upside tests it too, since rallies tempt profit-taking the same way drawdowns tempt capitulation. Both directions move coins from one kind of holder to another.

Visual shelf: the cycle as a picture

Concept sketches, not dated charts. Price, DAA score, reward, hash rate, and supply move constantly; the snapshot panel above carries the dated numbers.

None of these establish current price, hash rate, DAA score, supply, reward, exchange depth, ASIC supply, or miner distribution.

ASICs buy security, with a bill attached

A Kaspa attacker cannot rent generic cloud compute and point it at the network.

They need specialized KHeavyHash machines, electricity, facilities, cooling, firmware, logistics, and a pool or solo-mining path. Every one of those steps takes time and leaves a trail. The attack has to leave the spreadsheet and enter a supply chain.

The same specialization that prices out an attacker prices out most ordinary participants too. Control settles with ASIC manufacturers, large buyers, cheap-power operators, firmware vendors, pools, and hosting sites. Used markets and more independent operators spread that control back out. A handful of dominant actors pull it in again.

Proof of work turns digital security into a physical bill. Electricity, hardware, heat, buildings, freight, capital, and time all get paid before a block gets mined. Proof of stake asks holders to lock the asset and follow validator rules. Proof of work recruits a different cast: miners carrying power bills, hosting contracts, repair costs, firmware choices, debt, and taxes, running machines that age in the real world. That friction is the security model, and it is also why mining behaves like an industry with payment terms instead of a balance sitting in a contract.

Visual shelf: attack cost and physical inputs

Judging the charts

One chart, several stories

Go deeper: linear charts hide the thing people actually care about

A move from $10 to $20 and a move from $10,000 to $20,000 are both 2x. The dollar amounts feel wildly different. The percentage effect on a holder's position is identical.

Log scale fits a young network better than linear. An 80% drawdown looks like death on a linear chart. On a log chart, the same drawdown can read as one violent move inside a much longer compounding path.

The eye tracks distance on the page. The portfolio tracks percentage change.

Drawdowns are still real losses for whoever is holding them. A top buyer sees a straight loss. An early holder may be looking at a brutal drawdown measured from absurd gains. Someone who bought early and never sold can be living through both pain and life-changing profit in the same chart.

Go deeper: market cap is not a pile of cash

Market cap is total supply marked at the marginal price. It isn't a pool of cash sitting somewhere.

A 20% price drop does not mean sellers extracted 20% of the market cap in cash. A small amount of selling can move price a long way once buyers step back. A liquidation can dump coins into market inventory that takes the market weeks or months to absorb. Sellers can keep leaning on the order book because they need liquidity before they need conviction.

Market cap looks like a pool of money. Price is set at the edge, where the next buyer meets the next seller.

Active float sets selloff pressure: how many coins are actually for sale, how urgent those sellers are, and how deep the buyers sit at each price rung. Total supply matters for the monetary story. Float matters in a selloff.

A large liquidation keeps reshaping the market long after the candle closes, as coins move from one kind of holder into another kind of inventory. The wallet-level story needs stronger sourcing before naming actors.

Go deeper: miners do not get to be pure believers

A holder can decide to sit still. A miner has bills: electricity, hosting, hardware debt, repairs, taxes, pool fees, upgrades. Thin margins turn a believer into a seller regardless of conviction.

Mining paid extremely well when price outran hash rate, and ASICs got expensive because that revenue opportunity was real: some machines ran tens of thousands of dollars during the hot phase. Operators with that cost basis recoup it partly by selling coins.

Miner selling is a line item, the same as the power bill.

Fees are the second revenue source

Issuance pays miners first. Fees have to matter later: that's the central security-budget question.

As the block reward declines, miners need meaningful revenue from transaction fees, coin value, or both. Toccata widens the design space that could generate that fee demand: covenants, covenant IDs, ZK proof verification, sequencing commitments, and based-app foundations.

Primitives are not usage. The fee side still needs shipped applications, users who come back, accepted transactions, and demand for blockspace that outlasts a launch campaign.

One use case is enough, if it repeats. One thing generating repeat demand for settlement, ordering, proofs, assets, or payments can reprice blockspace and pull fees into the security budget, and finding that thing is the open part of the experiment.

Visual shelf: issuance handing off to fees

Evidence

What would prove strength or weakness

Whether Kaspa is in a healthy compression phase or a deeper failure phase is not knowable in real time. Anyone claiming otherwise is selling certainty the data does not have. Price alone is too narrow a signal. Hash rate alone is too narrow. Read them next to ASIC prices, pool distribution, miner revenue, emissions, fees, and builder activity.

Solo mining

Point your own ASIC at your own node

An ASIC and a node don't talk to each other directly. Your miner speaks Stratum; your Kaspa node speaks Kaspa RPC. The Rusty Kaspa Stratum Bridge is the translator that sits between them.

Shares only prove the miner is talking to the bridge. A block reward arrives when the hardware finds a valid block, and solo variance means that can take a while even on working hardware.

The beginner setup

One computer runs both the node and bridge. Keep two terminal windows open on that computer, then open the miner's web screen in a browser.

1. Download the Rusty Kaspa zip for the node computer.
2. Extract the zip and open a terminal in the folder holding the binaries.
3. Download the sample bridge config from the repository and save it as bridge/config.yaml there. The archive does not include one.
4. Terminal window A runs kaspad. Leave it open.
5. Terminal window B runs stratum-bridge. Leave it open.
6. The bridge dashboard opens at http://127.0.0.1:3030/ on the node computer.
7. The miner points to the node computer's local IP plus port 5555.
8. The miner username is the Kaspa receive address plus a worker name.
9. The dashboard should show a worker, shares, and hashrate.

Keep the node, bridge, and miner on the same local network for the first setup. Do not expose RPC, dashboard, or Stratum ports to the public internet while learning.

Before touching the miner

Which Rusty Kaspa file do I download?

Use the official Rusty Kaspa v2.0.1 release page and grab the archive matching the computer that will run the node and bridge.

Skip the GitHub Source code zip and the WASM SDK zip: those build from source or target browser apps, and neither matches this setup.

Get from zip file to working folder

Every command below runs from the folder holding the extracted binaries.

"Open a terminal in that folder" means whichever directory holds kaspad and stratum-bridge: the top of the extract on Windows, the bin subfolder on macOS and Linux. None of the three archives carries a config file, so put the downloaded sample at bridge/config.yaml under that same directory before running the bridge.

Which instructions apply to you?

Step 1. Open terminal window A and run the node

Get into the folder holding the binaries first. On Windows, open the extracted folder in File Explorer, click the address bar, type powershell, and press Enter. On macOS or Linux, open Terminal, type cd , drag the bin folder from inside the extract into Terminal, and press Enter.

Run the node command for your system, and leave this window open. The bridge needs the node running continuously to fetch templates and submit blocks.

.\kaspad.exe --utxoindex --rpclisten=127.0.0.1:16110

./kaspad --utxoindex --rpclisten=127.0.0.1:16110

Templates from an unsynced node point at stale chain state, so let sync finish before judging mining results. If a node already runs with custom flags, keep those flags and add the RPC listen setting only if the bridge can't reach the node. The official bridge docs use 127.0.0.1:16110 for the node RPC address.

.\stratum-bridge.exe --config bridge/config.yaml --node-mode external

http://127.0.0.1:3030/

netstat -ano | findstr :5555

$env:RUST_LOG="info,kaspa_stratum_bridge=debug"

chmod +x ./stratum-bridge
./stratum-bridge --config bridge/config.yaml --node-mode external

http://127.0.0.1:3030/

lsof -i :5555

RUST_LOG="info,kaspa_stratum_bridge=debug" ./stratum-bridge --config bridge/config.yaml --node-mode external

.\stratum-bridge.exe --config bridge/config.yaml --node-mode inprocess -- --utxoindex --rpclisten=127.0.0.1:16110

./stratum-bridge --config bridge/config.yaml --node-mode inprocess -- --utxoindex --rpclisten=127.0.0.1:16110

Step 3. Find the node computer's local IP address

The miner needs the local network address of the computer running the bridge, usually something like 192.168.x.x or 10.0.x.x.

ipconfig

ipconfig getifaddr en0

hostname -I

Step 4. Point the ASIC at the bridge

Open the miner's web screen. If you don't know the miner's IP address, check your router's connected-device list or the manufacturer's setup tool. Type the miner IP into a browser, sign in, and find the mining or pool configuration page.

Use the bridge computer's local IP address and one of the Stratum ports from the sample config, starting with port 5555.

A Kaspa address already starts with kaspa:, so the username field ends up looking like kaspa:kaspa:.... That duplication matches the official bridge format; it's not a typo. Some miner screens expect a URL prefix instead. The official bridge docs give the pool URL as <your_pc_IPv4>:<stratum_port>; if a miner rejects that format, check its manual for the exact Stratum URL syntax it wants.

Sources

Source notes

The coin-and-ASIC cycle framing is credited to @Themooseisloos5's X posts. Price, hash-rate, supply, and protocol-status claims use the sources listed above.