docs: clarify SafeMultiChainSigAccountV1 works as a single-chain account - #228
Conversation
The class doc opened with "Safe account variant that supports multi-chain signatures via Merkle trees" and never mentioned single-chain use, and both single-op signing methods were documented as signing "for multi-chain". Read cold, that says a normal single-chain signature is not available from this class. It is: the single-op path signs the leaf SafeOp hash directly rather than a Merkle root, and the multi-chain flag only selects the signature encoding. An integrator evaluating EntryPoint v0.9 concluded from these comments that adopting this class meant "different signature machinery, a separate integration" rather than selecting a different account class. Lead with the single-chain case, state the API compatibility with SafeAccountV0_3_0 explicitly, note that the multi-op methods are additive, and flag the one thing that does change — the derived account address. No behaviour change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 12 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdated ChangesSafe multi-chain signing documentation
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 69fd3ad0fd
ℹ️ 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".
| * class instead of `SafeAccountV0_3_0` targets EntryPoint v0.9 — it is not a | ||
| * separate integration. The multi-op methods ({@link signUserOperations}, |
There was a problem hiding this comment.
For an already-deployed Safe used through SafeAccountV0_3_0, selecting this class at the same account address is not sufficient: the v0.9 module must first be enabled and installed as the fallback handler. The migration helper in SafeAccountV0_3_0.ts explicitly requires sending its disable/enable/set-fallback batch through the old v0.7 account, so describing this as merely selecting a class can lead users to submit operations against a module their Safe has not enabled.
Useful? React with 👍 / 👎.
The previous wording covered only counterfactual addresses, so "selecting this class targets EntryPoint v0.9" could be read as sufficient for an already-deployed Safe. It is not: a Safe deployed through SafeAccountV0_3_0 has neither the v0.9 module enabled nor installed as its fallback handler, and UserOperations sent before the migration batch lands will fail. Separate API compatibility (real) from account interchangeability (not real), and point at createMigrateToSafeMultiChainSigAccountV1MetaTransactions, noting its batch must be sent from the v0.7 account itself. Also qualify the constructor doc, whose "existing or new account" is where this mistake would be made. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Enabling the v0.9 module and repointing the Safe's fallback handler are two distinct configuration changes; the wording ran them together. Also note that a deployed Safe keeps its address across the migration — the differing address applies to counterfactual derivation for new accounts only. Mirrors candidelabs/developer-docs#83. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2 participants
Summary by CodeRabbit