fix(sysgo): set respectedGameType=42 on original ASR after FDG deploy #330
Conversation
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
fakedev9999
added a commit
to succinctlabs/op-succinct
that referenced
this pull request
Jan 12, 2026
- Remove WaitForGameOfType workaround (no longer needed) - Use WaitForGameCount(1) since respectedGameType is now correctly set to 42 in the submodule The root cause (respectedGameType mismatch) is fixed in the optimism submodule: succinctlabs/optimism#330
fakedev9999
added a commit
to succinctlabs/op-succinct
that referenced
this pull request
Jan 14, 2026
- Remove WaitForGameOfType workaround (no longer needed) - Use WaitForGameCount(1) since respectedGameType is now correctly set to 42 in the submodule The root cause (respectedGameType mismatch) is fixed in the optimism submodule: succinctlabs/optimism#330
After deploying OP Succinct FaultDisputeGame contracts, update the original AnchorStateRegistry's respectedGameType to 42. This ensures that withdrawals via the original OptimismPortal2 recognize OP Succinct games as valid for finalization. Without this fix, the portal's respectedGameType returns 1 (default), but OP Succinct creates games with type 42, causing withdrawal finalization to fail with "game type mismatch" errors.
…t compatibility OPSuccinctFaultDisputeGame only has l2BlockNumber(), not l2SequenceNumber(). Since for standard FaultDisputeGame l2SequenceNumber() == l2BlockNumber() (simple delegation), using l2BlockNumber() works for both game types.
Match op-succinct's ShortTimeout pattern for consistency with other e2e tests. The 90-second timeout was insufficient for the FP proposer to create games covering the withdrawal block.
20 minutes was insufficient for ZK proving to catch up to the withdrawal block. CI showed 23 games created in 20 min covering blocks 11→241, but withdrawal was at block 279. At ~11.5 blocks/min rate, needed ~3.3 more minutes. Increasing to 40 minutes (matching LongTimeout pattern) provides safe margin for variance in proving times.
fakedev9999
force-pushed
the
taehoon/set-respected-game-type-42
branch
from
606f3ff to
7c4d87e
Compare
…drawal The withdrawal test was failing with Panic(0x32) - array out-of-bounds because the prove transaction attempted to execute in the same block as game creation. The OptimismPortal requires block.timestamp > disputeGameProxy.createdAt(). Add WaitForBlock() call after forGamePublished() returns to ensure we're not in the same block as game creation before building proof parameters. This matches the upstream op-e2e pattern.
The withdrawal proof test was failing with Solidity Panic(0x32) (array out-of-bounds) because we captured game parameters before waiting for the next L1 block, but a new game could be created during or after that wait. This caused us to use stale game data. The fix follows the upstream op-e2e pattern: 1. Wait for a suitable game to exist 2. Wait for the next L1 block (for timestamp check) 3. Re-fetch game info fresh to avoid stale data
Move parameter computation inside the retry loop so each attempt uses the latest game data. A new game may be created during retries that actually includes the withdrawal in its L2 state. The previous approach computed parameters once before the loop, meaning all retries used stale parameters from an older game.
The previous fix moved forGamePublished() inside the retry loop, but forGamePublished has a 40-minute timeout which blocked the 30-second outer timeout. This caused the test to fail immediately when waiting for a suitable game. Fix by: 1. Call forGamePublished() once BEFORE the retry loop (blocking wait for a suitable game to exist) 2. Inside the loop, use new proveWithdrawalParametersLatestGame() that calls findLatestGame() directly (non-blocking) to get fresh game data This ensures: - We wait for at least one suitable game before trying to prove - Each retry gets the latest game data without blocking - New games created during retries are picked up immediately
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
After deploying OP Succinct FaultDisputeGame contracts, update the original AnchorStateRegistry's respectedGameType to 42. This ensures that withdrawals via the original OptimismPortal2 recognize OP Succinct games as valid for finalization.
Problem
Solution
Call
setRespectedGameType(42)on the original AnchorStateRegistry after FDG deployment, using the Guardian key.Changes
op-devstack/sysgo/superroot.go: AddsetRespectedGameTypeFnfunction selectorop-devstack/sysgo/deployer_succinct.go: Add helper function and call it in FDG deploymentTest plan