Hi team — thank you for the work on the delegation program. I'm evaluating Magicblock ER for a real-money mainnet Solana product and the migration plan is well underway. Before flipping any real-money traffic, I'd like to confirm one operational property that I couldn't find documented:
Question: When a delegated account is held by an ER and the operating validator becomes unresponsive (or chooses not to commit/undelegate), what recourse does the program owner have to recover the account back to base layer?
Specifically:
-
Does commit_frequency_ms (or any timeout) cause an automatic undelegation if no commit lands within some window? If so:
- What window is enforced today on the public mainnet validators (
as.magicblock.app, us.magicblock.app, eu.magicblock.app)?
- Is the auto-expiry observable on-chain, or do we need to query the validator out-of-band?
-
Is there a force_undelegate / claim_back instruction that the program owner (or an end user) can invoke on base layer when the validator fails to cooperate? If yes, please link the canonical reference; if no, what is the recommended runbook for that situation?
-
If neither (1) nor (2) provides recourse: in the worst case where a validator simply ignores undelegate requests, what is the practical bound on how long a delegated account can stay stuck?
For context: I'm planning to delegate per-game PDAs that hold ~100ms-of-game state, NOT funds. The vault PDA itself is never delegated. So the worst-case impact is "a single game session never settles" rather than "player funds locked" — but I still need to document the worst-case clock to set Phase 3 canary alarms appropriately.
Happy to discuss off-issue if any of this is sensitive. Mostly I want to make sure the property is recorded somewhere I can cite during our pre-launch review.
Thanks!
Hi team — thank you for the work on the delegation program. I'm evaluating Magicblock ER for a real-money mainnet Solana product and the migration plan is well underway. Before flipping any real-money traffic, I'd like to confirm one operational property that I couldn't find documented:
Question: When a delegated account is held by an ER and the operating validator becomes unresponsive (or chooses not to commit/undelegate), what recourse does the program owner have to recover the account back to base layer?
Specifically:
Does
commit_frequency_ms(or any timeout) cause an automatic undelegation if no commit lands within some window? If so:as.magicblock.app,us.magicblock.app,eu.magicblock.app)?Is there a
force_undelegate/claim_backinstruction that the program owner (or an end user) can invoke on base layer when the validator fails to cooperate? If yes, please link the canonical reference; if no, what is the recommended runbook for that situation?If neither (1) nor (2) provides recourse: in the worst case where a validator simply ignores undelegate requests, what is the practical bound on how long a delegated account can stay stuck?
For context: I'm planning to delegate per-game PDAs that hold ~100ms-of-game state, NOT funds. The vault PDA itself is never delegated. So the worst-case impact is "a single game session never settles" rather than "player funds locked" — but I still need to document the worst-case clock to set Phase 3 canary alarms appropriately.
Happy to discuss off-issue if any of this is sensitive. Mostly I want to make sure the property is recorded somewhere I can cite during our pre-launch review.
Thanks!