[0xisk]

Types of changes

What types of changes does your code introduce to OpenZeppelin Midnight Contracts?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

Fixes OpenZeppelin/compact-contracts#997

A zkir-v3 build emits [v7] verifier keys, which ledger-v9 accepts only as v4. The insert path fixed every key at v3, so any fragmented deploy of such a contract failed its follow-up insert. The deploy tx itself was unaffected.

Not visible in the diff:

• ledger-v9 exposes the version set only as a type ('v3' | 'v4'), with no runtime list and no constructor that detects the version from the raw key. The candidate list is a Record over that type, so a ledger bump that adds or drops a version fails the build here.
• The version choice is the ledger's: each candidate goes to its constructor, which rejects a mismatched header. Probing arbitrary versions would need matching its error text.
• compact-js's own insert path also hard-codes v3.

PR Checklist

• I have read the Contributing Guide
• I have added tests that prove my fix is effective or that my feature works
• I have added documentation of new methods and any new behavior or changes to existing behavior
• CI Workflows Are Passing

Further comments

The new fixture is the existing Counter increment key rebuilt with compact compile --feature-zkir-v3. Not yet run against a live node; the end-to-end check is the NativeShieldedTokenIssuer live spec in compact-contracts once this is released.

Summary by CodeRabbit

• Bug Fixes
  • Fixed fragmented deployments of contracts compiled with --feature-zkir-v3 so verifier keys are accepted by the ledger, avoiding version-related deployment failures.
  • Verifier keys now retain the version accepted by the ledger, including when a single update contains keys in different formats.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Essentials

Run ID: 764b289a-8165-4905-a7d0-781b93778e70

📥 Commits

Reviewing files that changed from the base of the PR and between 8d505b6 and a00214d.

📒 Files selected for processing (4)

• packages/deployer/CHANGELOG.md
• packages/deployer/src/services/fixtures/counter-increment-zkir-v3.verifier
• packages/deployer/src/services/maintenance-tx.test.ts
• packages/deployer/src/services/maintenance-tx.ts

Included review availability: 2 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour.

---

Walkthrough

The deployer now detects whether each verifier key matches ledger version v3 or v4 before building fragmented-deployment inserts. Tests cover standard [v6] and zkir-v3 [v7] keys, unsupported bytes, and mixed-version updates. The changelog records the fix.

Changes

Verifier Key Version Detection

Layer / File(s)	Summary
Detect and insert verifier-key versions packages/deployer/src/services/maintenance-tx.ts, packages/deployer/src/services/maintenance-tx.test.ts, packages/deployer/CHANGELOG.md	The helper tries ledger versions v3 and v4 and reports an error if neither accepts a key. The update builder uses the detected version for each insert. Tests cover [v6] to v3, [v7] to v4, unsupported bytes, and mixed-version inserts. The changelog describes the fragmented-deployment fix.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: andrew-fleming

Merge Risk: ⚪ Minimal · up to a0021

No actionable merge-blocking risk is established for the verifier-key version fix; it is ready for normal checks.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: assigning the correct version to each inserted verifier key.
Linked Issues check	✅ Passed	The change implements #997 in compact-deployer. versionedVerifierKey tries the ledger-supported v3 and v4 constructors and returns the version accepted by the key header. buildInsertUpdate use…
Out of Scope Changes check	✅ Passed	The changed deployer code directly addresses #997. The added fixtures and tests verify the version-selection behavior. The changelog documents the fix. No unrelated change is evident.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1 …

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

_{A rabbit checks keys by the lantern’s glow
v3 or v4—the right tags show
Mixed keys hop into one update
No stray version can make it through
The burrow rests; deployments proceed}

_{Comment @coderabbitai help to get the list of available commands.}

[pepebndc]

LGTM