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.
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.
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?
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.
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?
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
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.
These are good questions in terms of the purpose of reward calls. I’m going to give a quick cop-out answer…
I think that the security benefits of getting the hot keys out of the exposed path is worth doing in the short term.
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.
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, earlier discussions on Discord and during the Watercooler 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.
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.