# LIP: Delegated Reward Calling Discussion Thread **URL:** \ **Category:** Governance\ **Created:** [July 3, 2026, 4:27pm UTC](https://forum.livepeer.org/t/lip-delegated-reward-calling-discussion-thread/3278 "2026-07-03T16:27:01Z")\ **Posts on this page:** 1\ **Showing post:** 10
**Author:** ![rickstaa](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.livepeer.org/rickstaa/32/917_2.png) [@rickstaa](https://forum.livepeer.org/u/rickstaa)\ **Post date:** [July 17, 2026, 7:32pm UTC](https://forum.livepeer.org/t/lip-delegated-reward-calling-discussion-thread/3278/10 "2026-07-17T19:32:12Z")
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](https://forum.livepeer.org/t/a-path-to-livepeer-2-0/3291), which aims to link rewards more closely to real validated work. So if no major objections come up (per [LIP-1](https://github.com/livepeer/LIPs/blob/master/LIPs/LIP-1.md)), 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. --- _[View the full topic](https://forum.livepeer.org/t/lip-delegated-reward-calling-discussion-thread/3278)._