docs: clarify recent SDK session and EIP-7702 behavior

intents/guides/signing.mdx

@@ -8,11 +8,15 @@
   Always fetch a fresh quote immediately before signing. Submitting signatures built from a stale quote will result in an expiry error.
 </Info>
 
+<Warning>
+  Treat `preClaimOps` and other route-derived fields as immutable once the quote is returned. If you need additional pre-claim executions for session enablement or similar flows, include them in the route request via the SDK or orchestrator request rather than mutating the returned route. Mutating these fields after quoting can invalidate the checksum signature.
+</Warning>
+
 Warp uses [EIP-712](https://eips.ethereum.org/EIPS/eip-712) for typed, human-readable signing. The signature scheme depends on the settlement layer used for each bundle element.
 
 ## Signature types
 
 **Permit2 signatures** are used for standard crosschain intents. Each source chain element requires a unique signature. The index of the signature must correspond to the index of the element it signs.
 
 **Intent Executor signatures** are used when the bundle uses the Intent Executor settlement layer (i.e. the user has an ERC-7579 smart account with the Intent Executor installed). These use a different EIP-712 domain — not the standard Permit2 domain. The `getTypedData` function below handles this automatically based on the `settlementLayer` field in the element.
 

intents/use-cases/automated-zaps.mdx

@@ -1,9 +1,9 @@
 ---
 title: "Automated zaps"
 description: "Streamline crosschain deposits, withdrawals, and automated vault actions for EOA users."
 ---
 
 With Rhinestone, you can build app-managed crosschain vault deposits and withdrawals for EOA users. The pattern uses a companion smart account owned by the user, operated by your app via scoped session keys.
 
 There are two execution modes:
 
@@ -97,7 +97,7 @@
 ```
 
 <Note>
 Sessions can be further scoped to specific contract functions (e.g., `deposit` and `withdraw`) and guarded with policies like spending limits or timeframes. See the [Smart Sessions](/smart-wallet/smart-sessions/overview) docs.
 </Note>
 
 ## Instant Execution
@@ -128,7 +128,7 @@
 
 ### Executing the Intent
 
 Once funded, the companion account executes the crosschain intent using the session key:
 
 ```ts
 import { encodeFunctionData, erc20Abi } from "viem";
@@ -167,19 +167,23 @@
     enableData: {
       userSignature: enableSignature,
       hashesAndChainIds: sessionDetails.hashesAndChainIds,
-      sessionIndex: 0,
+      sessionToEnableIndex: 0,
     },
   },
 });
 ```
 
+<Note>
+The SDK handles the session enable pre-claim plumbing during route construction. Do not mutate route-derived pre-claim operations after quoting.
+</Note>
+
 <Note>
 After submitting the intent, poll the intent status until it reaches a terminal state (`COMPLETED`, `FILLED`, `FAILED`, or `EXPIRED`). This typically takes a few seconds for cross-chain settlements.
 </Note>
 
 ## Delayed / Automated Execution
 
 In the delayed flow, the user pre-approves tokens and your app triggers execution later — for example, on a schedule, when a vault matures, or in response to an onchain event.
 
 ### Step 1: User Approves Tokens
 
@@ -221,7 +225,7 @@
 });
 ```
 
 **Execute the crosschain intent** (bridge + vault deposit):
 
 ```ts
 await companionAccount.sendTransaction({
@@ -286,10 +290,10 @@
 
 ## Event Listening Service
 
 For the delayed execution flow, your app implements a service that listens for onchain or offchain events to trigger executions. The service has access to the session key and stored credentials.
 
 <Note>
 The specific events to listen for (e.g., ERC-20 Transfer events, vault maturity events, or offchain triggers) and the service architecture are implementation-specific.
 </Note>
 
 ## Recovery

smart-wallet/chain-abstraction/error-handling.mdx

@@ -4,20 +4,19 @@
 
 ## Account errors
 
 * `Eip7702AccountMustHaveEoaError`: when using EIP-7702, you need to provide an EOA account by passing `eoa` param.
 * `SigningNotSupportedForAccountError`: the account you provided does not support message signing.
 * `WalletClientNoConnectedAccountError`: the `WalletClient` instance you provided is missing a default account. Ensure the wallet is connected and the client has an account.
 * `Eip7702NotSupportedForAccountError`: this account type does not support EIP-7702. Try using a different account implementation or [submit](https://github.com/rhinestonewtf/sdk/issues) a feature request.
 * `AccountConfigurationNotSupportedError`: your account setup is not currently supported. Try using a different account configuration or [submit](https://github.com/rhinestonewtf/sdk/issues) a feature request.
 * `FactoryArgsNotAvailableError`: factory data is not available for this type of account. Most likely an issue with the SDK itself. Please [submit](https://github.com/rhinestonewtf/sdk/issues) a bug report.
 * `SmartSessionsNotEnabledError`: smart session validator is not available. Most likely an issue with the SDK itself. Please [submit](https://github.com/rhinestonewtf/sdk/issues) a bug report.
 
 ## Execution errors
 
 * `SourceChainsNotAvailableForUserOpFlowError`: when using a UserOp flow (e.g., for account recovery), you need to provide a source chain.
-* `UserOperationRequiredForSmartSessionsError`: when using smart sessions, you need to use the UserOp flow.
-* `SessionChainRequiredError`: when using smart sessions, each session needs to define a chain where it is activated.
+* `SessionChainRequiredError`: when using multi-chain smart sessions, you need to specify which chain to prepare the transaction for.
 * `IntentFailedError`: the intent failed (reverted onchain). A common reason is that a swap failed due to price action.
 * `SimulationNotSupportedForUserOpFlowError`: `simulateTransaction` can only simulate intents.
 * `OrderPathRequiredForIntentsError`: when sending an intent, you need to first get the path. When using `submitTransaction`, make sure to call `prepareTransaction` first.
 
@@ -28,7 +27,7 @@
 * `UnsupportedChainError`: the target or the source chain is not supported. See [Unsupported chain id](/intents/guides/error-handling#unsupported-chain-id).
 * `UnsupportedTokenError`: the token you're requesting is not supported. Make sure you're only using supported tokens when setting `tokenRequests`. See [Unsupported token addresses](/intents/guides/error-handling#unsupported-token-addresses).
 * `TokenNotSupportedError`: the token you're requesting is not supported. See [Unsupported token addresses](/intents/guides/error-handling#unsupported-token-addresses).
 * `AuthenticationRequiredError`: make sure you're providing an API key when using mainnets by passing `rhinestoneApiKey` param. See [Authentication is required](/intents/guides/error-handling#authentication-is-required).
 * `InvalidApiKeyError`: the API key you're using has expired or is invalid. See [Invalid API key](/intents/guides/error-handling#invalid-api-key).
 * `InvalidIntentSignatureError`: [Invalid bundle signature](/intents/guides/error-handling#invalid-bundle-signature).
 * `OnlyOneTargetTokenAmountCanBeUnsetError`: when specifying `tokenRequests`, you need to provide the exact token amounts for all except one token.

smart-wallet/core/eip-7702.mdx

@@ -3,12 +3,12 @@
 description: "Add smart account capabilities to an existing EOA without changing its address"
 ---
 
 EIP-7702 lets an existing EOA act as a smart account. It works by delegating the EOA to a smart account implementation, giving it full smart account capabilities while keeping the same address and onchain history.
 
 Use this when your users already have an EOA with assets or history they want to preserve, and you want to unlock modules, session keys, and gas sponsorship without migrating to a new address.
 
 <Note>
 EIP-7702 requires your app to control the delegation target. It is not supported for external wallets (MetaMask, Coinbase, etc.) since those wallets do not allow delegating to an arbitrary contract. For external wallet users, use a [plain EOA](./eoa) or [create a separate smart account](./create-account).
 </Note>
 
 See [What is EIP-7702?](../../home/concepts/smart-eoas-eip-7702) for a conceptual overview.
@@ -22,7 +22,7 @@
 ## Limitations
 
 - **No key rotation**: the EOA is always the root owner. If it's lost or compromised, the account is unrecoverable.
 - **No multisig**: the EOA acts as a root key that overrides any other owner.
 - **Embedded wallets only**: not supported for external wallets.
 
 ## Send an intent
@@ -62,7 +62,7 @@
     ```
 
     <Info>
-    The init signature is valid cross-chain, so you can cache it and reuse it. Always provide it when preparing a transaction — the account may need to be initialised on any of the source or target chains.
+    The init signature is valid cross-chain, so you can cache it and reuse it. Passing `eip7702InitSignature` explicitly is still recommended when you want predictable reuse across chains, but recent SDK versions can also auto-sign the init data for supported flows if you do not provide it.
     </Info>
   </Step>
   <Step title="Prepare the transaction">