I ran into the nesting exception while attempting to bond more and will work around it until the Leger app is updated to support proxy action. Is there an approximate timeframe for this revision?
Hi Al, I communicated this issue to Zondax and they assured me all the nesting functionalities will be working as of 9420, which is being deployed tomorrow (15th June).
The next staking dashboard update is also being deployed imminently, that contains much better proxy support.
1 Like
@ross Thank you for the feedback Ross. Great news! I will be able to try again in a couple more days.
1 Like
Hi @ross. Are there plans to increase the palletās version given the breaking changes? (also created an issue in GH)
1 Like
Deployment Timeline Confirmed
The corresponding referendum Ref 221 was submitted in Kusama and it is scheduled to be enacted on the 03/07/2023 (block #18625000).
Ref 18 was submitted in Polkadot and it is scheduled to be enacted on the 18/07/2023 (block #16450000).
1 Like
Hi @ross , I have the following use case for a validator:
- stash account on ledger
- controller account on a different ledger
I set the controller back to stash and then set the former controller account as a staking proxy, then attempted to set a new session key with the proxy. However, I got an error āCall nesting not supportedā. I am using the last version of the ledger kusama app.
What can I do? Has this use case been considered at all? Thanks in advance.
Hi @nicolasochem, it sounds like the Ledger apps need to update their session key extrinsics with nesting support, which they are very responsive to given that it is requested on their repo: GitHub - Zondax/ledger-kusama: Kusama app for Ledger Nano S and X
The strategy undertaken with staking dashboard is to ensure Ledger is 100% compatible with the extrinsics that the dashboard relies on, unfortunately the validator use case is yet to be explored with staking dashboard specifically. When it is though, we need to ensure Ledger is fully working before we roll out validator based tools into production.
1 Like
These changes indeed simplify the handling of controllers by ensuring that the controller account is always the same as the stash account. This can make the system more straightforward and potentially reduce complexity for users and developers.
Itās important to consider the implications of such changes, especially in terms of backward compatibility and user experience. You mentioned that this could enable UIs to offer a migration prompt for existing stakers to set their controller account to their stash via the updated set_controller.
Hi bawev, thanks for the positive thoughts.
You mentioned that this could enable UIs to offer a migration prompt for existing stakers to set their controller account to their stash via the updated set_controller.
Correct, calling set_controller now will always set the controller record to the stash account. Staking dashboard has had this prompt for around 5 months now in an effort to draw down the unique pairs. Other UIs have their own roadmaps and priorities, so we have not really witnessed a big up-take of the deprecation prompt ecosystem wide.