Skip to content

Conversation

@jonatascm
Copy link

@jonatascm jonatascm commented Dec 3, 2025

Summary

Introduces a review checklist for SVM payload generation in cross-chain governance actions, covering both the SVM checklist and EVM spell integration.

Rationale

Sky's governance will execute cross-chain actions on SVM via LayerZero bridge. We need systematic review processes for SVM payloads similar to our EVM spell reviews.

Cross-chain governance actions follow this two-stage review process:

  1. SVM Payload Generation

    • SVM instructions payloads are generated and serialized
    • Reviewed using the SVM Payload Generation Checklist
    • Ensures SVM correctness
  2. EVM Spell Integration

    • EVM spell references the SVM payload hex data
    • Bridges the message to Solana via Wormhole/LayerZero
    • Reviewed using the Cross-Chain SVM Payload section in the Star Spell Reviewer Checklist
    • Validates correct payload reference and ordering.

Both checklists work together to ensure end-to-end correctness of cross-chain governance actions.

SVM Payload Generation: https://github.com/keel-fi/crosschain-gov-solana-spell-payloads

Copy link
Contributor

@SidestreamColdMelon SidestreamColdMelon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a brief look, most of the comments are not specific to SVM (as I think all of the checks are). There are a few general suggestions:

  • Perhaps you can make checks more SVM-specific. Otherwise there is no much point of those checks and it's just enough to compare payload.txt verified by the auditor (and found at the commit specified in the external report) with the payload in the spell. This can be described inside star-spell-reviewer-checklist.md via a few points
    • For example, if all of the checks are correct here, but upgrade authority was not passed to the SKY Oapp (which is done outside of the payload generation scripts) or if program bytecode doesn't match – none of the checks listed here doesn't make any sense
  • In the PR description you mention Wormhole, but it's no longer functional and is not planned to be used anymore


**Simulation Execution**

- [ ] Run validation script: **`NETWORK=[network] ts-node ./scripts/SPELL_NAME/validate.ts --file FILENAME`**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in order for the validate output to make sense, its contents first needs to be inspected (with the same attention to addresses as the in the generate-payload file)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll need more context for this one, but as far as I know, there will be an audit reviewing the generation code. We'll only be confirming whether the generated text is correct through simulation and re-running the generation. The process is still under construction

@jonatascm
Copy link
Author

Regarding SVM-specific functionality, there will be an audit for the SVM part. Any calls added should be reviewed before using them in payload generation. So I think, for this list, it's only necessary to validate the correct generation of the payload.

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