diff --git a/docs/wallet/abstractionkit/13-safe-unified-account.mdx b/docs/wallet/abstractionkit/13-safe-unified-account.mdx
index 963b669..b212a81 100644
--- a/docs/wallet/abstractionkit/13-safe-unified-account.mdx
+++ b/docs/wallet/abstractionkit/13-safe-unified-account.mdx
@@ -79,7 +79,8 @@ The multichain APIs — `signUserOperations`, `signUserOperationsWithSigners`, t
 
 A few differences to be aware of when migrating:
 
-- **The account address changes.** A different Safe module and EntryPoint derive a different counterfactual address for the same owner. Existing v0.7 accounts stay on `SafeAccountV0_3_0`; use `SafeMultiChainSigAccountV1` for new accounts, or migrate a deployed one with [`createMigrateToSafeMultiChainSigAccountV1MetaTransactions`](/wallet/abstractionkit/safe-account-v3#createmigratetosafemultichainsigaccountv1metatransactions).
+- **New accounts get a different address.** A different Safe module and EntryPoint derive a different counterfactual address for the same owner, so `SafeMultiChainSigAccountV1` and `SafeAccountV0_3_0` never refer to the same undeployed account.
+- **Deployed accounts must be migrated first.** Attaching `SafeMultiChainSigAccountV1` to a Safe that was deployed through `SafeAccountV0_3_0` is not sufficient. Two pieces of Safe configuration have to change first: the v0.9 module must be enabled on the Safe, and the Safe's fallback handler must be updated to point at it. Until both land, the account cannot be used on EntryPoint v0.9 and UserOperations sent to it will fail. Build the batch with [`createMigrateToSafeMultiChainSigAccountV1MetaTransactions`](/wallet/abstractionkit/safe-account-v3#createmigratetosafemultichainsigaccountv1metatransactions) and send it as a UserOperation from the v0.7 account itself; once it lands, attach the same address to `SafeMultiChainSigAccountV1`.
 - **The UserOperation type is `UserOperationV9`.** It adds a nullable `eip7702Auth` field to the v0.7 shape; every other field, including the gas fields and the paymaster and factory fields, is unchanged.
 - **Signatures always use the multichain encoding.** `isMultiChainSignature` is set for you, including on single-chain UserOperations — the single-op path signs the leaf SafeOp hash directly rather than a Merkle root. This is handled inside AbstractionKit; you only need it when [formatting a signature yourself](#manual-eip-712-signing-for-a-single-useroperation).
 - **Your bundler and paymaster must serve EntryPoint v0.9.** Check that the v0.9 EntryPoint and the Safe multichain signature module are deployed on your target chains before predicting addresses for them.
diff --git a/docs/wallet/abstractionkit/6-safe-account.mdx b/docs/wallet/abstractionkit/6-safe-account.mdx
index b972467..7192941 100644
--- a/docs/wallet/abstractionkit/6-safe-account.mdx
+++ b/docs/wallet/abstractionkit/6-safe-account.mdx
@@ -43,7 +43,7 @@ import { SafeAccountV0_2_0 as SafeAccount } from "abstractionkit";
 
 ## How to Use
 
-AbstractionKit classes are designed to support the same methods across all versions, ensuring compatibility within the essential classes. This allows developers to move between Safe V2, Safe V3 and the Safe Unified Account seamlessly without breaking functionality or requiring significant code changes. Targeting a different EntryPoint is a change of account class rather than a separate integration — see [Compatibility with Safe Account V3](/wallet/abstractionkit/safe-unified-account#compatibility-with-safe-account-v3). Note that each version derives a different account address for the same owner.
+AbstractionKit classes are designed to support the same methods across all versions, ensuring compatibility within the essential classes. This allows developers to move between Safe V2, Safe V3 and the Safe Unified Account seamlessly without breaking functionality or requiring significant code changes. Targeting a different EntryPoint is a change of account class rather than a separate integration — see [Compatibility with Safe Account V3](/wallet/abstractionkit/safe-unified-account#compatibility-with-safe-account-v3). Each version derives a different counterfactual address for the same owner, so a new account is a different account under each class. An already-deployed Safe keeps the address it has; it needs only its module and fallback handler migrated before another version's class can operate on it.
 
 To initialize a new Safe Account and calculate its address: