LIP: Delegated Reward Calling Discussion Thread

Governance
1

Background: Orchestrators must call reward() every round from the same wallet that holds their bonded LPT and fees, forcing that high-value wallet to stay online and unlocked (a hot wallet) and making multisig orchestrators impractical. Nico Vergauwen started the discussion and shared an initial draft in 2024, but it sat on the backlog until the Protocol R&D SPE provided the dedicated capacity to develop it into the solution in the draft LIP below.

Summary: The LIP lets an orchestrator authorize a separate, low-value address (a “reward caller”) to call reward() on its behalf, via a new setRewardCaller setter and a dedicated rewardForTranscoder entrypoint. The reward caller is scoped to reward() only. It can’t move funds, change configuration, vote, or redirect rewards, which always accrue to the orchestrator. This lets operators keep their main wallet cold and unblocks multisig orchestrators. The change is fully additive, and existing reward() behavior is unchanged.

Full draft: Delegated Reward Calling - draft LIP

Feedback requested: The LIP is currently a draft and open for community feedback. Any thoughts or concerns are welcome. If there’s broad support, it will move to Last Call and a governance poll, and once approved it would ship in one of our monthly protocol releases.

On behalf of the Protocol R&D SPE.

4 Likes
2

This is really great to see, as the ability to have multi-signature Orchestrators can unlock grassroots collaboration on the supply-side of the network.

One question I have: are there plans to also allow delegation of redeemWinningTicket so that an O can delegate both functions that run in-client?

2 Likes
3

This is really great to see, as the ability to have multi-signature Orchestrators can unlock grassroots collaboration on the supply-side of the network.

Hey Chris, good point, I agree that will be a great unlock.

One question I have: are there plans to also allow delegation of redeemWinningTicket so that an O can delegate both functions that run in-client?

There’s no logic in the redeemWinningTicket method preventing a wallet from redeeming a ticket for any orchestrator, as long as the ticket is valid. The recipient is part of the ticket the gateway signs, so the funds are always paid to that orchestrator regardless of who submits the redemption. To use this in the client, run with any gas-funded wallet as ethAcctAddr and set ethOrchAddr to your orchestrator address. You can see it in action in my own tickets.

If you have any other questions don’t hesitate to let me know.

3 Likes
4

Looks good to me. I’ve wanted this since 2021. We’ve come along way but I think this is the final step for security for Os. The main O keys are just too hard to keep safe while calling reward.
This also unlocks another very good option, Hardware Wallets for Orchestrator keys.
New Os can now spin up HD wallets to hold the main keys and delegate reward calling.

The only push back was @dob’s response a long time ago about the purpose of the reward call. It was to signal to delegators that this Orchestrator was active. With this upgrade, we could end up with abandoned Os with 100% calls which could reduce the movement of stake. As an example, @papa_bear (Rest In Piece) could still be calling 100% rewards if he was set up with a reward calling service.

So the next question comes up. Why even call reward at each individual O? Why not just have the initialize round call reward for all Os and skip the need for a reward calling service that everyone could just sign up for?

1 Like
5

PAPA could still be calling rewards today, in fact he was calling it anyways untill his vps lease ended. So what is the difference here setting call reward script with orch native wallet compared to different wallet with similar service? this argument is invalid

6

Great to see this effort to make the smart-contract protocol more versatile.

I am curious if there are concrete downsides to having a fully permissionless reward-calling model, since there’s already precedent with redeeming tickets. The proposal says:

Fully permissionless reward() — the simplest option, but set aside in governance discussion because it removes any requirement for an orchestrator to actively participate in claiming rewards, weakening the link between rewards and real network contribution.

As @Titan-Node and @karolak mentioned, this wouldn’t prevent abandoned orchestrators.

Since there is only a single delegated address allowed, many orchestrators might use the same reward service, making that service a potential point of failure for the network. This is especially an issue if orchestrators move their wallets into cold storage which might not be as easily accessible for an emergency manual reward call. The orchestrator would be doing the right thing by keeping the wallet cold, but a design which implicitly requires the wallet be kept on standby works against the goal. Having multiple delegated addresses on an allow-list could mitigate this, but makes protocol changes more complex (and thus risky).

The protocol changes for permissionless reward calling would be smaller and simpler than the current proposal, so it feels safer unless there are problems beyond abandoned orchestrators.

Non-performing orchestrators are an issue in general, more so than the ones that don’t call reward. Any approach to managing non-performance would also cover the ones that aren’t genuinely calling reward.

I’m not an orchestrator so I don’t have strong opinions one way or the other (and there may be something about the original reasoning that I’m missing) but it seemed like an interesting design decision. If this is an approach that orchestrators actually prefer for their own sense of security then that is fine too.

1 Like
7

These are good questions in terms of the purpose of reward calls. I’m going to give a quick cop-out answer…

  1. I think that the security benefits of getting the hot keys out of the exposed path is worth doing in the short term.
  2. I think the protocol economics related to reward calls may be addressed in some of the updated protocol and incentives alignment research/vision that we’ll talk about at next week’s community meeting.

So I know that’s a bit of a teaser without substance, but just wanted to express support for the proposal for security reasons, while waiting for bigger changes that address some of the weaknesses around non-working nodes earning rewards.

2 Likes
8

Thanks, everyone, for your questions and feedback! @dob and @Karolak have already addressed several points, but I want to briefly explain why the team proposed LIP-118 rather than permissionless or automatic reward calling.

As noted above, we considered those alternatives. However, feedback from community discussions, including this Discord thread and Watercooler conversations, indicated stronger support for retaining the explicit reward call while giving orchestrators a safer way to keep their primary wallet offline. LIP-118 is therefore intended as a minimal, additive security improvement.

The concern that abandoned orchestrators could continue calling rewards is valid. However, as @Karolak pointed out, this is already possible today when an orchestrator uses a separate wallet for ticket redemption while keeping reward calling independent. LIP-118 does not introduce this risk. It primarily removes the need to expose a high-value wallet.

@j0sh, you also raised a valid concern about relying on a single delegated reward caller. We explored supporting multiple callers, but doing so would require a larger and more complex contract change. The current design aims to strike the best balance between improved security, operational simplicity, and minimal protocol risk. That said, we are happy to investigate this option further if a majority of orchestrators consider the single-caller model a significant risk.

The broader question of linking rewards more directly to actual network contribution remains important and, as @dob mentioned, will be part of the discussions later this year. The Protocol team is ready to work closely with the community to implement any broader protocol changes that emerge from the community discussion around this topic. However, because those changes will require further discussion and more time to implement, our recommendation to the community is to proceed with LIP-118 for now and revisit the broader design in a future contract update.

Please don’t hesitate to comment below if anything needs clarification or if there is opposition to this approach.

Rick,
On behalf of the Protocol R&D SPE.

1 Like
9

Thanks for the response @rick

Just to re-state my view, maybe a little more clearly:

  • Agree that multiple delegated addresses or changing the requirement to call reward should be out of scope.

  • It seems that anyone should be able to call reward for anyone else (permissionless), not just delegated addresses.

The reasoning being:

  • Trying to enforce permissions currently weakens the very core of this proposal, for negligible gain.

  • Having a single delegated caller means the orchestrator may need to keep their keys close by for contingencies if the caller is not functioning. Orch keys can’t really be kept cold.

  • Not being able to keep orch keys cold runs counter to the goal of this proposal

  • The operational guidance then becomes murky. Keep keys cold, and potentially miss reward calls if it takes time to retrieve the keys. Keep keys warm, and risk compromise.

  • Delegated callers don’t solve the ghost orchestrator problem and don’t quite allow for cold keys as a best practice. So this proposal, as-is, seems to occupy an awkward middle ground that doesn’t fully solve the problems it sets out to fix.

  • Non-performing orchestrators are a separate and larger problem. So maybe we should not try to address that problem here via permissioned checks. That seems to obviate the one reason for having the delegated address.

  • Permissionless reward calling is actually a smaller protocol change than having a delegated address. No need to store, update or check the sender.

  • Permissionless reward calling would allow for fully cold, offline keys in a vault. This, along with permissionless being a smaller protocol change, feels safer and more operationally robust.

  • I haven’t heard any other arguments for why rewards should remain permissioned, other than as a weak liveness signal.

1 Like
10

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.

11

Thanks @rickstaa

I don’t actually have strong feelings about this, only wanted to understand the design reasoning so please don’t let this hold up the process.

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.

It would be good to explain these edge cases in detail within the proposal, because those can be legitimate reasons for choosing one method over the other. From my current understanding of things, I don’t really see the vectors of concern.

Although I do totally understand the reluctance to reconsider the design if the current proposal has already been audited thoroughly, with sunk costs.

The reward caller is a low-value key that can only call reward(), so keep it somewhere easy to reach

The reward caller may be a service though, not something the orchestrator controls. If that service is unavailable then you need the orchestrator key at hand - not cold.

12

Thanks @j0sh for your response.

It would be good to explain these edge cases in detail within the proposal, because those can be legitimate reasons for choosing one method over the other. From my current understanding of things, I don’t really see the vectors of concern.

Although I do totally understand the reluctance to reconsider the design if the current proposal has already been audited thoroughly, with sunk costs.

I think it might not make sense to add it to the LIP, since it specifies the permissioned design rather than the alternative. If there is appetite to explore the permissionless version, I can have the security team write one up.

To be clear, no known vectors were found directly. It was more a callout that from previous patches we know the timing of the reward call is sensitive, so letting untrusted parties call it adds attack surface that would need a thorough review and might add complexity.

The reward caller may be a service though, not something the orchestrator controls. If that service is unavailable then you need the orchestrator key at hand - not cold.

On the reward caller being a service, that’s a valid point. The intended setup is that the orchestrator holds the caller key itself. It’s low privilege and can only call reward(), so keep a copy somewhere reachable (phone, backup box) and call from there if the host is down, no main wallet needed. A service dependency only arises if you hand the slot to a third party, and even then the worst case is a missed round.

13

LIP-118 is live on-chain and open for voting. Please cast your vote here. The poll runs for another 6 days.

Thanks to everyone who reviewed and shared feedback.

1 Like
14

Curious about the practical side—what’s the rotation process for the reward caller key? Can you just swap it out with a tx, or does it need downtime?