Chia Timelord Signage Troubleshooting: Stop Missing Points and Protect Your Rewards

• 64 signage points fire every 10 minutes — miss too many and you lose your shot at block rewards entirely.
• Missing fewer than 100 signage points per day is generally normal; anything above 100 needs your attention right away.
• Most problems come down to four culprits: a slow CPU, a desynced full node, a clock that’s drifted, or a misconfigured config.yaml.
• Your first diagnostic stop is always debug.log — setting it to INFO level unlocks the data you need.
• Running your own software timelord doesn’t mean your proofs get selected — ASIC timelords are faster, but your farm can still run cleanly alongside them.
• Tools like Chiadog can monitor your farm 24/7 and alert you when signage point gaps appear before they become a serious problem.

Chia timelord signage troubleshooting comes down to two things: is your machine producing VDF proofs fast enough, and is your full node actually keeping pace with the network? When either breaks down, signage points go missing, your farm sits idle, and rewards slip away. This guide walks you through every layer — from log reading to hardware to config fixes — so you can get your farm healthy again. According to official Chia documentation, missing 100 or more signage points per day signals a problem that needs investigation.^[5]

What Timelords and Signage Points Actually Do

Before you can fix a problem, you need a clear picture of how these pieces fit together. A timelord is a special service that runs a Verifiable Delay Function — a CPU-intensive math calculation that cannot be sped up by parallelism. The timelord’s job is to produce these calculations at a steady drumbeat so the rest of the network has a reliable clock to farm against. Each completed VDF calculation is released as a challenge that farmers use to check their plots for a winning proof of space.^[12]

The 64-Point Rhythm That Drives Chia Farming

Every 10-minute sub-slot on the Chia network is divided into exactly 64 signage points, one arriving roughly every 9.375 seconds.^[1] When your timelord reaches each of those points, it publishes a VDF output and proof. Your full node picks that up and broadcasts it to your harvester, which then scans your plots and checks whether any of them qualify for a proof of space at that moment. If you miss a signage point — for any reason — your harvester never gets the challenge signal and you are simply not in the lottery for that round. Every missed signage point is a missed chance to win a block reward, and there are 9,216 of them every single day.

How Timelords Decide Which Chain to Follow

Your timelord is always tracking what Chia calls the “heaviest chain” — the chain with the most accumulated proof-of-space weight. It keeps a cache of upcoming blocks to infuse and broadcasts challenge points as it reaches them. One important detail: timelords run three VDF chains in parallel, which means they need at least three fast CPU cores just to keep pace.^[4] If any of those cores get throttled, shared with a heavy background process, or run hot and clock down, the timelord will start falling behind. The official Chia documentation notes that “at least three fast CPU cores are necessary to advance the blockchain at an efficient rate,” and extra cores are needed to generate the associated proofs.^[2]

Quick Troubleshooting Reference: What Symptom Points to What Cause

Reading Your Logs: The First Step in Chia Timelord Signage Troubleshooting

You cannot troubleshoot what you cannot see. By default, Chia ships with log output set to WARN level, which means most of the useful information about signage points never gets recorded. Your first move is to open ~/.chia/mainnet/config/config.yaml and find the farmer: section. Inside it, look for the logging: block and change the log_level value from WARN to INFO. (Note: log_level appears multiple times in config.yaml — you want the one nested under the farmer: section specifically.)^[6] Save the file and restart your node. Now your debug.log will start recording the data you actually need.

What Healthy Logs Look Like

In a healthy farm, you should see lines like this appearing every 9–10 seconds in your debug.log:

Finished signage point 14/64

And from your harvester, look for lines showing plot lookup times under 5 seconds:

INFO  1 plots were eligible for farming ... Found 0 proofs. Time: 0.46s. Total 200 plots

Seeing Found 0 proofs is completely normal — it just means no plots won that round. What you want to confirm is that the lookup happened, it was fast, and signage points are ticking through steadily. A gap of significantly more than 9.375 seconds between consecutive signage point timestamps is a likely indicator of a missed point — and if gaps exceed 30 seconds you have almost certainly missed multiple points in a row.

Log Lines That Signal Real Problems

Watch for these specific patterns and take them seriously. The string "Don't have RC Hash" means your node does not yet have the Reward Chain hash for an incoming signage point — it’s slightly behind the chain tip and will ignore those signals until it catches up.^[7] If you see this message only occasionally, it’s minor. If it’s flooding your logs, your node is struggling to stay synced. Similarly, if your timelord logs show repeated socket disconnects, failed reconnects to the full node, or explicit warnings about failing to produce VDF output in time, those are urgent flags. Cross-reference the timestamps in your full node logs (when challenges and signage points arrive) against your timelord logs (when VDF proofs are published). A persistent delay of more than a couple of seconds between those timestamps means your VDF computation is lagging behind the network pace.

CPU, Hardware, and VDF Speed: The Engine Under Your Timelord

The timelord’s VDF is a sequential math operation — it cannot be split across multiple cores to go faster on a single chain. What matters most is single-core clock speed. A machine that is technically “powerful” but has all its cores pinned on plotting, transcoding, or other parallel workloads will deliver poor timelord performance. The same goes for any machine running aggressive power-management profiles, where the CPU downclocks when it detects low load. VDF computation is deceptively steady — it doesn’t spike, so power managers often throttle it — but the calculation is time-sensitive and any slowdown compounds into missed signage points.

Software Timelord vs. ASIC Timelord: What You Should Expect

In October 2023, Chia Network activated its first batch of ASIC timelords on mainnet. A single ASIC reaches 800,000–1,000,000 IPS, and running three as a cluster pushes that figure even higher — roughly four times faster than the best software timelords, which top out at around 260,000 IPS on the fastest CPUs.^[3] The network uses whichever timelord proof arrives first. This means your software timelord may be producing valid proofs but simply losing the race — the ASIC wins, your proof is ignored, and it can look like your timelord isn’t working when it actually is. This is not a problem with your farm. Your harvester still receives signage point challenges from the fastest timelord (via your full node), and your farm still participates normally. Running a software timelord provides valuable network redundancy and is encouraged, but don’t mistake “my proofs aren’t selected” for “my timelord is broken.”

“It’s important to emphasize that even though the fastest timelords are now ASICs, any user with a CPU can be a timelord, to provide fallbacks in the unlikely case that each of the ASIC timelords go down, or becomes malicious.” — Chia Network, Timelord Algorithm Documentation^[2]

Software Timelord vs. ASIC Timelord: Side-by-Side Comparison

Full Node Health and Network Connectivity

Your timelord is only as good as the full node it connects to. A timelord that is technically functioning but attached to a desynced or poorly peered node is useless — it won’t receive accurate chain state and won’t broadcast its proofs to anyone meaningful. Before blaming VDF speed for your problems, confirm that your full node is fully synced and showing a healthy peer count. Port 8444 being open and properly forwarded through your router is one of the single biggest factors in node stability.^[11] A closed port means your node can only make outgoing connections, not accept incoming ones. That leads to fewer peers, less stable sync, and a higher rate of missed signage points at the farmer level.

The target_peer_count Setting and Low-End Hardware

If you are farming on a Raspberry Pi or any other low-power single-board computer, your node may be handling too many peer connections simultaneously. Each peer connection consumes CPU and memory for message handling, and when a large batch of network messages arrives at once, the node can fall behind processing signage points before they expire. Lowering the target_peer_count value in config.yaml — from its default of 80 down to 30–40 for constrained hardware — reduces this congestion without meaningfully hurting your network connectivity.^[10] Many Raspberry Pi farmers report that this single change eliminates persistent signage point gaps.

Clock Skew and NTP Synchronization

Chia’s network is time-sensitive by design. If your system clock drifts significantly from real world time, your node may log signage points with incorrect timestamps, causing them to appear duplicated, out of order, or attributed to the wrong sub-slot. The fix is simple but easy to overlook: ensure your operating system’s NTP time synchronization is enabled and working. On Linux, timedatectl status will tell you if NTP sync is active. On Windows, check the Internet Time settings in Date & Time. After correcting clock drift, restart your Chia node so it re-establishes peer connections with accurate timestamps.

Case Study: A community member on the Chia Network GitHub (Issue #1796) reported experiencing 22 consecutive missed signage points on a Raspberry Pi 4 4GB. After investigation, the root cause was the VDF verification function verify_n_wesolowski consistently returning false for every wesolowski attempt — a symptom of insufficient CPU capacity to complete VDF verification before the timelord’s stop signal.^[10] This is a documented limitation of running a full node and timelord on low-power single-board hardware.

Config.yaml Settings That Affect Timelord Signage Performance

Beyond peer count, your config.yaml holds several other settings worth reviewing when you’re doing chia timelord signage troubleshooting. The timelord section specifies which host and port the timelord connects to. If you have moved your full node to a different machine or changed your network layout, an outdated IP or port reference here will cause silent disconnections that are hard to trace. Double-check that the vdf_server host and port settings match the actual address of your full node. Also confirm that there are no firewall rules between your timelord process and full node service — even on the same machine, iptables rules or software firewalls can block the inter-process communication.

Compressed Plots and the Plot Filter Reduction in Chia 2.0

If you have upgraded to compressed plots, there is an additional layer of latency to monitor: plot decompression. Compressed plots require your CPU or GPU to do additional work at each signage point to decompress the proof-of-space data before the harvester can evaluate it. The Chia 2.0 release cut the plot filter in half, which doubled the number of plots evaluated at each signage point.^[8] If you are using compressed plots, this additional evaluation load compounds with decompression overhead — and if your decompression hardware is already running near its limit, it can push your plot lookup times above the 5-second threshold, causing your harvester to time out on proofs even when the signage points themselves are arriving correctly. Use the harvester latency graph in the Chia GUI’s farm health dashboard to spot this pattern.

Monitoring Tools for Ongoing Chia Farm Health

Manual log checking is a solid starting point, but for farms running continuously, automated monitoring is a much better long-term approach. Chiadog is a widely used open-source watchdog that reads your debug.log in real time and sends you push alerts whenever signage points are skipped, your node loses sync, or plots go missing.^[9] Setting it up takes about 15 minutes and provides the kind of 24/7 visibility that prevents small problems from becoming big ones. The Chia GUI’s built-in farm health dashboard (introduced in version 2.0.0) also displays missing signage points, sync status, plots passing filter, and harvester latency in a single view^[8] — making it the easiest starting point for most farmers.

Conclusion

Getting on top of chia timelord signage troubleshooting is really about building a reliable, well-monitored stack — fast CPU cores dedicated to VDF work, a fully synced and well-peered full node, a synchronized system clock, and log visibility set to INFO so you can see what is actually happening. Most issues resolve when you address the obvious bottlenecks: underpowered hardware, closed ports, or a config that hasn’t been revisited since the farm was first set up. Start with your logs, cross-reference signage point timestamps against your timelord output, and work through the decision table above to narrow down your root cause quickly. Your rewards depend on being in every lottery — and with a healthy timelord and node, you will be. Check the official Chia farm health docs for the latest guidance, and join the #farming-and-plotting channel on the Chia Discord if you hit an edge case that isn’t covered here.

Chia Timelord Signage Troubleshooting FAQs

What causes missing signage points in Chia farming?

Missing signage points in Chia farming are most often caused by an overloaded harvester, an unstable or poorly peered full node, slow plot lookup times exceeding 5 seconds, or a desynced system clock. According to official Chia documentation, missing 100 or more signage points per day indicates a real problem that needs investigation, while occasional misses are completely normal.

How does chia timelord signage troubleshooting differ from general farm troubleshooting?

Chia timelord signage troubleshooting specifically focuses on whether the timelord service is producing VDF proofs fast enough to keep pace with the 9.375-second cadence, and whether those proofs are reaching the rest of the network through a synced full node. General farm troubleshooting covers a wider area including plot validity and harvester connectivity, while timelord-specific issues center on CPU speed, core availability, and the timelord-to-full-node connection.

How many signage points should I be missing per day on Chia?

A healthy Chia farm misses very few signage points per day — single-digit numbers from minor network blips are considered normal. Chia’s documentation states that missing 100 or more signage points per day signals a significant issue with your setup, such as hardware limitations or network instability that should be diagnosed and resolved.

Why does my timelord seem to be running but my proofs are never selected?

Your software timelord may be producing valid VDF proofs that simply arrive after faster ASIC timelords have already published theirs — the network uses the fastest proof and ignores the rest. This is expected behavior and does not affect your farm’s ability to participate in signage point challenges; your harvester still receives the fastest timelord’s broadcast and responds normally.

What is the “Don’t have RC Hash” error in my Chia debug.log?

The “Don’t have RC Hash” message means your full node does not yet have the Reward Chain hash for an incoming signage point, usually because it’s slightly behind the chain tip at that moment. Occasional instances are harmless, but if this message floods your logs, your node is struggling to stay synced and you should check your port 8444 forwarding, peer count, and confirm you are running the v2 database.

Chia Timelord Signage Troubleshooting Citations

1. Chia Network. “Signage and Infusion Points.” Chia Documentation. https://docs.chia.net/chia-blockchain/consensus/chains/signage-and-infusion-points/
2. Chia Network. “Timelord Algorithm.” Chia Documentation. https://docs.chia.net/chia-blockchain/consensus/timelords/
3. Chia Network. “Timelord Architecture.” Chia Documentation. https://docs.chia.net/chia-blockchain/architecture/timelords/
4. Chia Network. “Three VDF Chains.” Chia Documentation. https://docs.chia.net/chia-blockchain/consensus/chains/three-vdf-chains/
5. Chia Network. “Checking Farm Health.” Chia Documentation. https://docs.chia.net/reference-client/troubleshooting/checking-farm-health/
6. Chia Network. “Logging Reference.” Chia Documentation. https://docs.chia.net/reference-client/troubleshooting/logging-reference/
7. Chia Network. “Farming FAQ.” Chia Documentation. https://docs.chia.net/reference-client/troubleshooting/farming-faq/
8. Chia Network. “Version 2.0.0 Release.” Chia Network Blog. https://www.chia.net/2023/08/24/version-2-0-0-release/
9. Martomi. “Chiadog – A Watchdog for Chia Farms.” GitHub. https://github.com/martomi/chiadog
10. Chia Network. “Missing Signage Points: Issue #1796.” GitHub – chia-blockchain. https://github.com/Chia-Network/chia-blockchain/issues/1796
11. Chia Network. “Missing Signage Points Metric: Discussion #16464.” GitHub – chia-blockchain. https://github.com/Chia-Network/chia-blockchain/discussions/16464
12. Chia Network. “Challenges.” Chia Documentation. https://docs.chia.net/chia-blockchain/consensus/chains/challenges/