As described, there's an error in the design of the crazy clock. I incorrectly assumed that the low frequency crystal oscillator in the ATTiny45 had the correct capacitive loading for the 12.5 pF 32.768 crystal called for in the design. It turns out, this is not true. As a result, the oscillator runs around 120 ppm fast.

The hardware fix is to add two 15 pF caps, one from each crystal lead to ground. The result is correct loading for the crystal, which is the most desirable outcome.

If you don't want to fix the hardware, however, it is possible to work around the problem in the firmware.

The firmware now has a SW_TRIM facility. This will use a two byte two's compliment integer stored in EEPROM as a correction factor. The value is in tenths-of-a-ppm, and positive numbers slow the clock. So a value of approximately 0x490 (expressed in little endian as 0x90, 0x04) has been experimentally determined to be correct for the current inventory of controllers in the store. The correction factor is written in bytes 0x4 and 0x5 of the EEPROM, immediately adjacent to the 32 bit PRNG seed at addresses 0-4.

Additionally, if you have access to a very accurate PPS signal, such as from a GPS receiver, you can load a special firmware into the controller that will count PPS pulses until a long enough interval goes by that the accumulated error becomes significant. It will then write the error value specific to your controller directly to EEPROM. All you have to do is load a clock firmware after that and it should be accurate to within 0.5 ppm.