Skip to content

fix: write a subgraph withdraw outcome only once the Gateway holds it - #524

Open
KSlashh wants to merge 1 commit into
devfrom
audit/6-1-withdraw-status
Open

KSlashh wants to merge 1 commit into
devfrom
audit/6-1-withdraw-status

Conversation

@KSlashh

@KSlashh KSlashh commented Nov 9, 2026

Copy link
Copy Markdown
Collaborator

Audit item M32. Open against dev.

WithdrawHappyPath, WithdrawUnhappyPath and WithdrawDisproved entities from the subgraph were written straight to OperatorTake1, OperatorTake2 and Disprove. A terminal status takes the graph out of graph_scan and obsoletes the instance's other graphs, so a wrong or compromised subgraph could make the node stop challenging a graph that is still open, and the operator's Take-2 would go through.

  • Before any database work, each withdraw outcome is checked against gateway_get_withdraw_data(graph_id): Take outcomes need Complete, Disproved needs Disproved. An outcome the Gateway does not hold is dropped with a warning; the graph stays followed on Bitcoin, where its real outcome is still observed.
  • A failed lookup fails the block range, which is fetched again on the next tick.

Tests: outcomes for withdraws still Processing or already Disproved are dropped, matching ones are kept, and a failed lookup is an error. Node tests and clippy pass.

Validation results above are recorded in the zkm PR notes. Branch scope and diff formatting were checked locally; builds and tests were not rerun during publication.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants