Sort-of base 2 to base 6 conversion. Instead of the input being processed as an ordinary binary number, the order of the values of each bit is jumbled up. If you jumbled up the word "MATHS" in the same way, you'd get "STHAM". In other words, instead of the standard "16.8.4.2.1" bit order, input is interpreted in "1.2.8.4.16" order. Output is in standard base 6 of the "custom" input value with Lead as 0 up to Gold as 5.

For example, an input value of b10101 would traditionally represent 1 + 4 + 16 = d21 and map to h33 (Copper-Copper). Under this encoding, it would be 16 + 8 + 1 = d25 and map to h41 (Silver-Tin). It is still a unique 1:1 mapping, and so is valid for this machine.

First shortcut is that the 16 and 8 bits are not handled as individual increments. Instead, the 16 bit is taken as "increment the 6 hexbit twice, increment the 1 hexbit 4 times", and the 8 bit is taken as "increment the 6 hexbit once, increment the 1 hexbit twice". This saves on 15 individual increments.

Overflows are also slow. If you process the bits in the traditional order, you get 8 points where an overflow might be required. If you go in reverse, you get that down to 4. If you use the above positioning you get down to 3. Those points are:
 - After the final upgrade from the 4 bit (the 2nd bit processed)
 - After the final upgrade from the 8 bit (the 3rd bit processed)
 - After the final upgrade from the 2 bit (the 4th bit processed)

There is one opportunity to speed up an overflow as well. Processing of the 8 bit can increment the 1 hexbit twice first, and then while the potential overflow is being processed, the upgrade of 6 the hexbit can happen simultaneously. Little bit of parallel processing saves a few cycles.

Waste is still an issue. I do have a "clean" version of this where fire, salt, and gold waste is wicked over to the disposal glyph, but it has a worse score so here we are.