CI rehearsal only (do not merge)

[michael-moffett]

Fork CI only. Do not merge.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Adds test-only cheatcode for mint configuration.

The PR appears safe to merge, with a non-blocking test gap for newly created plain Token-2022 mints.

Findings

1.  Plain Token-2022 path lacks coverage ▶

Summary

The PR adds surfnet_setMint to create or patch SPL Token and Token-2022 mints, including a confidential-transfer mint extension, and exposes the method through the Node SDK.

• Existing extension data and excess lamports are intended to be retained during updates.
• The new plain Token-2022 mint path needs a downstream-use test.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A["surfnet_setMint"] --> B{"Mint exists?"}
  B -- No --> C["Create initialized mint base"]
  B -- Yes --> D["Read existing mint and extensions"]
  C --> E["Apply supplied base fields"]
  D --> E
  E --> F{"Confidential update?"}
  F -- Yes --> G["Add or update Token-2022 extension"]
  F -- No --> H["Pack base while retaining extension bytes"]
  G --> I["Validate owner and fund rent"]
  H --> I
  I --> J["Write account"]

Loading

_{Reviews (1) · Last reviewed commit: "feat(core): surfnet_setMint cheatcode wi..."}

[greptile-apps]

Plain Token-2022 path lacks coverage

A new Token-2022 mint created without confidential is stored as an 82-byte base mint. The tests cover building a confidential extension from that layout, but not using the plain mint in a Token-2022 instruction or adding the extension in a later setMint call. A test of both steps would protect this distinct creation path from regressions.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!