Thanks @j0sh, appreciate your feedback. You’re correct that a fully permissionless reward() implementation is a slightly smaller protocol change: it drops the setter, mapping, and event. It does still need the new rewardForTranscoderWithHint entrypoint to stay non-breaking, since reward() currently mints for msg.sender.
However, from a protocol design perspective it’s the bigger change. Several parts of our protocol were designed and audited with the assumption that the orchestrator is the reward caller, so removing it requires more careful evaluation, as opening reward() (the most complex function in BondingManager) to anyone could introduce timing/ordering and griefing edge cases. LIP-118 already achieves the same goal, a cold main wallet, without changing behavior for everyone or adding new attack surface.
On cold keys: LIP-118 doesn’t force a warm wallet. The reward caller is a low-value key that can only call reward(), so keep it somewhere easy to reach (phone, laptop, backup server) and call from there if its host fails. The main wallet is only needed if you lose that key entirely, which backups make unlikely, so it stays genuinely cold. The only key you keep handy is the throwaway one.
I do agree reward() is only a weak liveness signal, but genuinely strengthening it is a bigger incentive-design change that needs broader community agreement, and is best tackled alongside the Livepeer 2.0 proposal, which aims to link rewards more closely to real validated work.
So if no major objections come up (per LIP-1), as champion I’d still like to move LIP-118 to an on-chain poll to gauge whether there’s enough support among orchestrators, with permissionless left open as a non-breaking follow-up.