fix: sign proof-bearing validator joins - #405
Merged
Merged
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
MuncleUscles
marked this pull request as ready for review
August 9, 2026 15:40
CON-715 removed ValidatorWalletBlueprint.setOperator in favour of initiateOperatorTransfer + completeOperatorTransfer, so `staking set-operator` fails against a consensus deployment carrying that change: the selector is gone and the call reverts with no decodable reason. set-operator now prefers the two-step flow and falls back to the single call when the wallet does not expose it, so it keeps working against both older and newer deployments. The two halves are also available on their own as `staking initiate-operator-transfer` and `staking complete-operator-transfer`, for deployments whose operatorTransferDelay is non-zero and where one command therefore cannot finish the rotation. The incoming operator has to sign its own possession proof, so its key must be reachable: --operator-account names the keystore entry, otherwise the operator address is looked up locally via findLocalAccountByAddress. Without a match the command takes the legacy path unchanged, which is what keeps existing callers working. Note the proof binding differs from a join: the wallet verifies rotation proofs itself, so createOperatorTransferRegistration builds them against the SDK's getOperatorTransferContext (registrar = the wallet) rather than the factory-bound validator registration context. Requires genlayer-js with initiateOperatorTransfer/completeOperatorTransfer. Verified: npm run build against the linked SDK, and vitest — 782 passing, including three new cases covering initiate+complete, a pending transfer when the delay has not elapsed, and the legacy fallback. tests/libs/keychainManager fails locally only because keytar's native binding is absent under --ignore-scripts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--operatorto match an imported local CLI account--operator-passwordfor non-interactive selected-operator proof signingRoot cause
Consensus #1285 removed the address-only validator join overloads. The CLI still called the retired
validatorJoin({amount, operator})andvestingValidatorJoin({vesting, operator, amount})surfaces, so tooling joins could not enter the proof-bearing validator wallet factory.Validation
npm run buildgit diff --checkDepends-On: genlayerlabs/genlayer-consensus#1290