fix: validate SVM optional parameter presence

[Reinis-FRP]

Summary

Adds consistency validation for SVM instructions that can load optional parameters either from instruction data or from the instruction_params account.

The validation requires each optional argument group to be consistently present or absent, and requires that presence to be opposite the instruction_params account presence. This prevents callers from supplying conflicting values through both input paths.

This fix has been reviewed by auditors and has already been deployed onchain.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9b619aa238

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Move fill optional-parameter check before unwrapping

When fill_relay is called with relay_data set to None and the optional instruction_params account omitted, this constraint is never reached: Anchor validates the earlier mint and recipient_token_account constraints first, and both unwrap instruction_params.as_ref().unwrap() while it is None. That inconsistent-parameter case still aborts with a panic/program failure instead of returning InconsistentOptionalParameters, so the new validation should be attached to an earlier account such as state before any constraint reads the optional parameters.

Useful? React with 👍 / 👎.

[Reinis-FRP]

Thanks for flagging this. I checked the actual generated Rust at 9b619aa238bccc89226bc4904b1dcec77a942c77 using Anchor CLI 0.31.1:

anchor expand -p svm_spoke

The generated FillRelay::try_accounts does not validate the ordinary account constraints in struct declaration order. Its relevant processing order is:

1. Deserialize the instruction arguments and parse/extract all account wrappers. This does not evaluate the mint or recipient constraint expressions.
2. Process the fill_status init_if_needed block.
3. Run has_valid_params_presence(...); on the relay_data = None plus omitted instruction_params case, this returns InconsistentOptionalParameters.
4. Only after that, run is_relay_hash_valid(...), which contains the first relevant unwrap.
5. Later, run the mint address constraint and then the recipient ATA constraint, which contain the other unwraps.

This ordering follows directly from the Anchor 0.31.1 generator:

• try_accounts emits field deserialization before the constraints block, and the generated function places deser_fields before constraints (lines 117-135).
• More importantly, generate_constraints emits every init_field before all access_checks for non-init fields. fill_status is the init field here, while mint and recipient_token_account are non-init fields.
• Within each field, Anchor linearizes init, seeds, mutability, and raw/custom constraints before address/token/mint constraints.

The expansion therefore confirms that the presence check is reached before any of these optional-parameter unwraps. Moving it to state is not necessary for this case, and the current placement is safe against the panic described here.

🤖 Reinis Codex coding agent