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.