docs: require migration before attaching Safe Unified Account to a deployed Safe - #83
docs: require migration before attaching Safe Unified Account to a deployed Safe#83Sednaoui wants to merge 2 commits into
Conversation
The migration note was folded into the "account address changes" bullet, which framed it as an addressing detail. For a Safe already deployed through SafeAccountV0_3_0 it is a prerequisite: the v0.9 module must be enabled and installed as the fallback handler before the account works on EntryPoint v0.9, and the migration batch has to be sent from the v0.7 account itself. Give deployed accounts their own bullet, and say so on the Safe Account index too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 20 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 (2)
📝 WalkthroughWalkthroughSafe Account documentation now distinguishes address changes for new account versions from module migration requirements for deployed accounts, including the migration path to ChangesSafe account versioning and migration
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/wallet/abstractionkit/13-safe-unified-account.mdx`:
- Line 83: Update the migration guidance in the paragraph beginning “Deployed
accounts must be migrated first” to describe enabling the v0.9 module and
updating the Safe’s fallback handler as separate configuration steps. Preserve
the existing migration command, UserOperation flow, and attachment instructions,
but remove wording that says the module is installed as the fallback handler.
In `@docs/wallet/abstractionkit/6-safe-account.mdx`:
- Line 46: Update the compatibility paragraph around the “Each version derives a
different account address” statement to limit that claim to counterfactual
address derivation for new or undeployed accounts. Explicitly preserve that an
already-deployed Safe keeps its existing address and requires only module and
fallback-handler migration before another version’s class operates on it.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 15b7771b-4820-418c-b106-6d927d863e0c
📒 Files selected for processing (2)
docs/wallet/abstractionkit/13-safe-unified-account.mdxdocs/wallet/abstractionkit/6-safe-account.mdx
Enabling the v0.9 module and updating the Safe's fallback handler are two distinct configuration changes; the previous wording ran them together. Also scope the differing-address claim to counterfactual derivation. An already-deployed Safe keeps its address across a migration — all three migration MetaTransactions target the existing account address — so the unqualified statement wrongly implied the address moves. 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>
…unt (#228) * docs: clarify SafeMultiChainSigAccountV1 works as a single-chain account 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> * docs: require migration before attaching this class to a deployed Safe 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> * docs: separate the two migration steps in the account docs 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> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Summary by CodeRabbit