Before you start
Choose a guide for your question: adding public identifiers, organizing devices across projects, checking reward periods or investigating failed refreshes.
Where can I check multiple Macs running IOTA together?
Add each Mac's public Miner ID to see reported activity, yesterday's rewards and lifetime totals. Sign in to sync; pair the optional Mac agent for local heartbeats and control.
How can I track several projects on one machine?
Create one device card, then manually link its IOTA, XID / MMM, fly.ai or other supported identifiers. Each project keeps its own status and reporting period. XID wallet balance and fly.ai monthly points are wallet totals, excluded from device daily earnings. Matching Worker names are not merged automatically.
When should I use IOTA Watch or an official dashboard?
Use IOTA Watch to check saved identifiers together, organize cross-project device cards and inspect reward records. Use the relevant official app or dashboard to install miners, start or stop jobs, inspect local logs, claim rewards or change platform account settings.
Can rewards from different projects be added together?
Check currency, period and ownership. IOTA uses preceding-day attribution, io.net a UTC day, Golem rolling 24 hours and fly.ai monthly points. Balances, points and different periods are not comparable as the same day's device income.
Do I need an account, a wallet connection or a subscription?
Public lookups and a local device list can be used without private keys or seed phrases. Google sign-in syncs your list. Free supports 3 devices per project; Pro supports 100, with new subscriptions at US$2.99/month or US$16.99/year. Private io.net and Vast.ai data requires sign-in and platform read credentials; real-account integration still needs further verification.
Which projects are supported, and can I request another?
Project pages cover IOTA Train at Home, XID / MMM, Quantus, fly.ai, Nosana, Akash, io.net, Vast.ai, Golem, NOID, Acurast, Pearl, Monero, Ethereum Classic, Ravencoin, Zcash, Kaspa and Midstate MDS, with only the metrics provided by each source. io.net and Vast.ai require account authorization and real-account integration remains under verification. Sign in to request an unlisted project using the page footer, once per account per day.
Does old data or zero rewards mean my device has failed?
Check the last successful fetch time and source first. Failed refreshes preserve previous results; missing fields are not filled with zero. A valid IOTA daily total of zero may mean no matching accounted records yet. Old samples and zero throughput alone do not prove that a device is offline. Inspect runtime logs in the official app on that machine.
Is this IOTA Layer 1 or an official wallet?
No. IOTA Watch is an independent, read-only monitor, primarily for Macrocosmos IOTA Train at Home (Bittensor SN9), with separate XID / MMM, Quantus and fly.ai pages. It is not IOTA Foundation Layer 1, Firefly or an official wallet for any of these projects.
Which projects does IOTA Watch support?
IOTA shows Train at Home device activity and accounted rewards. XID shows xCoin / MMM pool workers, hashrate and explorer balance. Quantus shows mainnet blocks and indexed block rewards. fly.ai shows monthly public wallet points, which are not device-level daily cash earnings.
Do all projects use the same address?
No. IOTA uses a public Miner ID / SS58 hotkey; XID uses a checksum-valid xpa1r mainnet payout address; Quantus uses the public Wormhole mining address; fly.ai uses a public payout wallet address beginning with 0x. Private keys, seed phrases and inner hashes are not required.
Do project lists sync through Google?
Yes. Sign in with Google in the device overview to sync devices and linked IOTA, XID, Quantus and fly.ai projects. Free supports 3 devices per project; Pro supports 100 per project. The overview has no additional total device limit. Signed-out lists remain in the current browser only.
Do Quantus block rewards cover all pool payments?
No. This monitor reads the mainnet miner block-reward index, not the pool’s complete participant payment ledger. Pool users should also check transfers to their personal address in the official explorer. No recent block rewards does not establish that a device is offline.
IOTA · Where do I find my Miner ID?
Open IOTA Train at Home on the device, select Miner, and copy the complete Miner ID. Use the public SS58 hotkey address, not a private key, seed phrase, or a row number on this site.
Can I manage a Mac and recover stopped training?
Public Miner ID lookup reads official reports only. An optional installed and paired Mac agent adds heartbeats, queue and worker state, remote start/stop/restart and agent updates. Logs require a separate opt-in. Agent 1.0.5 supports stopped-training recovery, off by default and available without Pro.
How are yesterday's rewards counted?
IOTA Watch labels IOTA as Yesterday's rewards by attributing the next accounting day's records to the preceding date in UTC+8. For example, records dated October 17 appear under October 16. Only pending and settled count; frozen and future timestamps are excluded. This display convention does not prove the actual training date or the date funds reached a wallet.
IOTA · What does the IOTA unit mean?
Here IOTA refers to the Train at Home subnet alpha token used by the upstream reward API. It is not a TAO amount and not IOTA Layer 1. The dashboard also shows a USD estimate from the public SN9 market price; that is not an official settlement rate. Lifetime rewards use the total earned amount; paid amounts are not added again.
IOTA · How current are the numbers?
Device status is checked about every 30 seconds; rewards about every two minutes. Official sample time and the time this site fetched the data are different. Manual refresh has a 15-second cooldown.
IOTA · Does zero throughput mean the device is offline?
No. It may be waiting or not participating in the sampled run. A website refresh failure is also different from a device failure. Use the IOTA app for local diagnostics.
IOTA · Do I need an account?
No. Without signing in you can keep up to 3 devices per project on Free in this browser. Sign in with Google to bind up to 3 devices per project on Free, or 100 per project on Pro to the account and open the same list on another device.
IOTA · Can I use the same list on a phone?
Sign in with the same Google account, or export the list and import it in the other browser. The unsigned local list does not sync by itself.
IOTA · Why is a reward value missing?
Unavailable or malformed data is shown as unknown, not zero. Overall totals show partial coverage when not all devices have usable reward data.
IOTA · What does refresh interrupted mean?
This site could not finish a successful official read for more than five minutes. Last good numbers stay on the cards. It does not prove the device is offline.
IOTA · What is SN9?
SN9 is Bittensor subnet 9 (IOTA Train at Home). The reward token is the subnet alpha, also called IOTA here. It is not TAO and not IOTA Layer 1.
IOTA Train at Home queued or 0 tokens/s: what to check
A queue, a running training process and actual contribution are different signals. Check each source and timestamp; no queue position does not prove training has begun.
IOTA training stopped with the app open: Mac auto-recovery
Mac agent 1.0.5 can attempt recovery after the training process has stopped for two minutes. An open app is not proof of training; recovery cannot fix insufficient memory or guarantee contribution.
Guides & troubleshooting
All guidesXID mining with MMM: Mac mainnet setup and monitoring
XID is the xCoin token and MMM is the Mac miner. Set mainnet, an xpa1r address and the current pool in MMM, then save that same public address on the XID monitor. The page does not start mining.
Setup and monitoringQuantus QTC mining on Mac: mainnet sync and monitoring
On a Mac, confirm --chain mainnet and a node at the chain tip, then save the public wormhole address. Planck is retired. A running process is not QTC.
Data and rewardsIOTA vs XID / MMM vs Quantus on Mac: training and mining
Compare tasks, public identifiers, reward units and monitoring scope to choose the right entry point without combining currencies or device counts.
Setup and troubleshootingHow to start IOTA Train at Home and monitor rewards
Start training in the official app, then monitor its public Miner ID. IOTA Watch is an independent monitor, not the training client or an IOTA Layer 1 wallet.
Queue and zero throughputIOTA queued or 0 tokens/s: wait or restart?
Keep training on when a recent log still says queued. Read the sample time before treating 0 tokens/s as a failure. Throughput freshness and the agent task status can disagree.
Stop and auto-recoveryIOTA training stopped but the app is open: check and recover
An open window is not proof of training. Check the button, fresh logs, and throughput time. Auto-recovery is off by default and does not need Pro. A Stop from the site will not start training again.
Mac monitoringPearl PRL on Mac: check pool hashrate, workers and rewards
See whether the Mac miner points at Kryptex or LuckyPool, then select that same source in PRL monitoring. The ledgers do not stand in for each other, and a Kryptex username is not a prl1 address.
Address not foundNOID address not found: InnovLab and Parano1d pool checks
Not found usually means the address, the pool, or the lack of accepted shares. The monitor asks Parano1d Pool first and InnovLab only after a miss or a failure. The two ledgers are not merged.
Applying for another tierIOTA Iron to Bronze or Silver: application and eligibility checks
Another tier goes through the official compute application, with a public coldkey and real hardware. Acceptance is emailed. IOTA Watch Pro, a new Miner ID, or repeated restarts do not replace that review. No published fixed wait or score bar is stated.
Tiers, eligibility, and layersIOTA Iron, Bronze, Silver and Gold: tiers, eligibility and layers
A tier is a name for a run group. Eligibility comes from official review and that run. A layer is one slice of the model pipeline. None of the three is a Mac model, and none is a fixed daily amount. A missing label stays unknown.
What to checkHow to check Midstate MDS pool rewards, addresses and units
Paste the 64-character lowercase MSS address the miner is using. MDS monitoring reads one LuckyPool ledger: unpaid (locked plus unlocked), cumulative paid, a rolling 24-hour block allocation, nonces/s, and workers. Other pools are not added in.
Check rewardsHow to check BNT mining rewards: Blocknet addresses and payments
Paste the full mainnet payout address Seine resolved. Read hashrate, the immature estimate, confirmed unpaid, queued payment and cumulative paid as separate lines. Shortnames, other pools and USD quotes are outside this page.
Hashrate and payoutsHow to check CSD mining hashrate and G-pools payments
Look up a public addr20 to see the G-pools 1-hour hashrate, unpaid balance, confirming amount, and lifetime paid. Coins stay on the whole address.
TensorCash guideTensorCash monitoring: five pools, workers and TSC balances
Choose your mining pool to see address-level throughput, workers and unpaid balance. Sign in to save addresses with their pool.
TensorCash lookupHow to check TensorCash pool workers and throughput
Look up a TSC address on the pool you use, then compare workers, reporting windows and throughput units.
TensorCash lookupTSC wallet balance vs pool unpaid balance and daily rewards
Separate chain balances, pool accounting and payouts when reading TensorCash mining records.
TensorCash lookupTensorCash address not found, missing workers or stale data
Check the address, selected pool, original source and timestamps before interpreting missing TSC data.
Practical checksAcurast phone replacement and shared manager rewards
Processor identities identify phones, while manager rewards may cover several processors. If old and new phones share a manager, assigning the full manager total to both device cards would duplicate the same reward.
Practical checksAcurast free, frozen and total balance accounting
Frozen amounts describe restrictions on balances rather than a new asset outside the total. Wallet holdings also differ from manager paid rewards. Adding total, free and frozen figures indiscriminately double-counts funds.
Practical checksAkash GPU allocation ratio versus actual utilization
Allocated GPUs divided by total GPUs describe a capacity snapshot. They do not measure kernel utilization, hours occupied over the day or the share of revenue already settled.
Practical checksAkash provider endpoint changes versus identity changes
A provider endpoint change is different from an akash1 identity change. A new access URL alone does not establish a new earnings history. A new identity likewise does not prove that old leases migrated automatically.
Practical checksIdentify privacy Blocknet BNT versus BLOCK and Bancor
Here BNT refers to the privacy PoW network at blocknetcrypto.com. The names Blocknet and BNT also appear in unrelated projects. Prices, explorers and reward rules from old BLOCK or Bancor must not be substituted.
Practical checksBNT local daemon status versus pool share activity
Daemon reachability, wallet synchronization and miner share submission are different states. A local tool such as bntop and a public pool observe different scopes. A responding node alone does not prove that a pool worker is submitting work.
Practical checksCKPool best share difficulty versus a Bitcoin block
Best share records the highest share difficulty in a reporting scope. It is neither a BTC amount nor proof of a valid block. A Solo outcome must be reconciled against an actual block and its reward transaction.
Practical checksOrganize CKPool addresses without duplicating worker hashrate
Address totals and the workers underneath them are hierarchical views of the same work. Adding both duplicates hashrate. A payout-address change also requires separating observations before and after the transition.
Practical checksCSD addr20 records across different mining pools
The same addr20 identifier does not merge pool ledgers. Shares, unpaid amounts and payment history remain source-specific. Changing a miner endpoint does not transfer a G-pools balance into another pool.
Practical checksCSD chain balances do not establish a pool account
A chain balance shows asset holdings, not that a particular pool received shares for that address. Ordinary transfers, payments from another pool and current mining activity can coexist without creating an account on the selected source.
Practical checksERG P2PK address changes and historical pool payments
One wallet application can manage several addresses while the pool still accounts by the submitted payout address. A new P2PK address does not automatically inherit the old address’s workers, unpaid balance or lifetime payouts.
Practical checksERG raw amounts, decimals and displayed rewards
A raw integer can represent the smallest unit while a display reports ERG. A different magnitude does not establish a reward surge. Applying decimal conversion twice to an already normalized field is equally incorrect.
Practical checksETC pool switching without losing track of unpaid balances
The same ETC 0x address can have independent ledgers on different pools. Changing the connection routes future shares; it does not automatically clear the old unpaid balance or transfer it into the new pool.
Practical checksETC payment thresholds, payout cycles and receipt checks
Reaching a displayed amount does not establish that an on-chain payout was sent. Check whether it is payable balance, the pool’s current conditions, its payment cycle and whether a transaction actually exists.
Practical checksETHW mining and non-native pool payout reconciliation
A pool may offer payment in another asset, but native ETHW monitoring does not automatically cover every conversion path. Mining accrual, conversion and receipt are separate stages of the same value, not three additional rewards.
Practical checksETHW payouts when a wallet displays the wrong network
Identical 0x formatting does not establish that the wallet is viewing ETHW. Ethereum, ETC and ETHW maintain separate records, so selecting another network can show a different balance for the same address string.
Practical checksFind fly.ai points after a monthly rollover
The current leaderboard can start a fresh period when the month changes. Previous points, monthly allocations and claims are separate records. A lower current-month figure alone does not show that the previous month was deleted.
Practical checksReconcile fly.ai allocation, claim and wallet receipt
Monthly allocation is not the same as wallet receipt. Identify whether the page shows points, an allocated amount, claim availability or a completed claim. Each describes a different stage, and none should silently replace another in a reward total.
Practical checksGolem provider history after a Node ID change
A Node ID identifies the provider, while its payout wallet is another configuration field. Reinstallation can leave the same wallet associated with a different node identity. Separate public statistics do not establish loss of wallet funds.
Practical checksWhy Golem rolling 24-hour GLM can decrease
A rolling 24-hour window continuously drops older records. A decrease can mean an earlier payment left that window, not that funds were debited or that today’s Hong Kong income became negative.
Practical checksio.net reward history after a Device ID change
A device nickname is not the IO Explorer Device ID. If reinstallation or registration changes that ID, a shared nickname does not automatically move the old ID’s rewards into the new record.
Practical checksio.net UTC rewards versus Hong Kong calendar dates
This monitor reads io.net daily block rewards by UTC date. Hong Kong is eight hours ahead. During early Hong Kong hours, the source’s UTC day differs from the local calendar date, so date labels across projects may refer to different intervals.
Practical checksIOTA contribution after a new training run starts
Live throughput belongs to the selected training run; accounted rewards can cover earlier runs. A new run, a layer change or re-entry into a participant list can change the current contribution display. A smaller live value alone does not establish that previously recorded rewards were removed.
Practical checksWhy IOTA reward USD values change without new tokens
The USD figure is a token amount multiplied by a market estimate. A refreshed quote can change that figure without any additional training reward. It is not a cash balance or a guaranteed execution price. Read the native IOTA amount first, followed by the quote source and its timestamp.
Practical checksKAS mining with non-native payouts: keep assets separate
Mining network, accounting asset and payout asset can differ. A non-native payout must retain its own denomination. BTC amounts are not KAS amounts, and a native KAS address lookup cannot establish a different payout asset’s wallet balance.
Practical checksKAS ASIC replacement with a reused worker label
A pool worker label is not an ASIC serial number. Reusing it after replacement can mix old and new shares within an averaging window. That mixed average cannot directly validate the new ASIC’s advertised performance.
Practical checksMDS miner upgrades and reusable MSS payout identity
A software upgrade and a payout-identity change are different actions. Midstate reusable MSS addresses and one-time WOTS addresses are not interchangeable. Check current pool instructions before carrying an old configuration into a new miner.
Practical checksMDS solo: payout labels and pool statistics
A mining-mode prefix is distinct from the underlying wallet address. LuckyPool instructions identify SOLO with solo:ADDRESS. Sharing an underlying address does not make statistics from different payment modes interchangeable.
Practical checksNOID pool switching and outstanding balances
Pools maintain separate ledgers. Reusing an o1 payout address does not move the old pool’s unpaid balance into the new pool when the miner endpoint changes. A shared chain address is not a shared pool account.
Practical checksNOID confirmation differences across source snapshots
Nodes and pools observed at different times can show different confirmation counts. Chain confirmation, pool maturation and payout are separate stages. A confirmation count is not a device’s daily earnings.
Practical checksNosana job retries, executions and reward counting
Jobs, execution attempts and payments are not interchangeable row counts. A retry after a failure can belong to one job lifecycle. Two log entries alone do not establish two settled NOS rewards.
Practical checksNosana history after replacing a host identity
Reinstallation does not necessarily change the host identity; compare the actual address first. If the public key changed, old jobs remain associated with the old identity. A shared machine nickname does not merge two network identities.
Practical checksCompare PRL pool payment methods without inventing hourly income
Payment methods distribute risk and accounting differently. Verify the current PRL pool, mode and fee documentation. A historical PPS report from one pool does not establish guaranteed hourly income on another pool’s SOLO service.
Practical checksPRL shared worker names and physical device attribution
Multiple machines using the same address and worker label can appear as one pool row. That aggregate cannot reveal each machine’s measured earnings. Dividing it equally by the number of devices would create an unsupported attribution.
Practical checksCompare Quantus local sync height with the network
A progressing network does not establish that your local node is synchronized. The explorer shows the network view; local node status or logs show your own progress. Both records must refer to the same mainnet.
Practical checksKeep Quantus reward history when changing addresses
Changing configuration does not migrate reward history to a new address. A pool payout identifier and a Wormhole reward address can also belong to different lookup paths. Record their relationship before replacing either saved record.
Practical checksRVN worker renaming and overlapping hashrate windows
Pool averages retain historical shares, so an old RVN worker label may not drop to zero immediately after a rename. A KawPoW worker name is a share label rather than a verified physical-device identifier.
Practical checksMatch RVN pool payouts with wallet transactions
A pool payout is a transfer, while rolling 24-hour rewards are an accounting window. A payment can include earlier accumulated balances, so receipt today does not mean the entire amount was earned today.
Practical checksTensorCash N/s versus PoI/s: compare the source units
Miners and pools can expose different throughput units. N/s and PoI/s are not interchangeable merely because both are rates per second. Conversion requires an explicit source definition and the conditions under which it applies.
Practical checksTensorCash paused pools and historical payout records
A retained pool website or old statistics page does not prove that it still accepts mining. Current operation, API readability and historical payouts are separate facts. A static online label is insufficient when a current notice says otherwise.
Practical checksVast.ai Machine ID changes and host income history
Host accounts, nicknames and Machine IDs describe different scopes. After hardware replacement or registration, compare IDs before attributing income. A reused name does not establish continuity of a machine’s revenue record.
Practical checksReconcile Vast.ai machine income report intervals
Contract rates, rental duration and income reports are different records. A current offer does not rewrite historical revenue. Reconcile reports by Machine ID and explicit start and end times, not only a date label.
Practical checksMMM worker renaming and XID pool history
A worker name labels the origin of pool shares; it is not a hardware serial number. After a rename, the pool may retain the old label while new shares arrive under the new one. Two rows during that reporting window do not establish that two machines are mining.
Practical checksTrace an XID pool payout to the mainnet explorer
Pool paid totals, payout transactions and wallet displays are three separate reconciliation points. Start with the individual payment and its public transaction reference. Comparing a lifetime paid total directly with the wallet’s current spendable balance mixes payment history with later transfers and other wallet activity.
Practical checksXMR payout address changes and old pool balances
Pools account by the payout identifier supplied to them. Changing it does not merge the old record into the new one. Different subaddresses may belong to one wallet without becoming one pool account.
Practical checksPrivacy when sharing an XMR pool monitoring link
Monero’s on-chain privacy does not make a pool statistics link information-free. A public lookup can expose worker labels, hashrate and payment statistics. A device nickname may also reveal a location or employer.
Practical checksZEC pool payouts before moving funds to a shielded address
A pool payment to a transparent address and a later wallet transfer into shielded funds are separate activities. This transparent-address monitor does not track shielded balances. An unavailable shielded balance does not cancel the original payout record.
Practical checksZEC address replacement and old worker history
A worker record belongs to the pool and payout address used when shares were submitted. Replacing a t address can create separate histories even if the worker label stays unchanged.
Practical checksKeep ZEPH mining rewards separate from ZSD and ZRS
Assets in the Zephyr ecosystem do not share one unit simply because they share a protocol. Native ZEPH mining statistics cannot be added directly to stable-asset or reserve-share quantities, nor valued with one interchangeable quote.
Practical checksZEPH immature balances after changing pools
Switching pools does not automatically mature an old pool balance or move it to the new source. Its accounting stage and maturation rules remain those of the original pool.