fix(account-sdk): require factoryData for undeployed smart accounts

[omerbek]

Closes #377.

What changed

• Make getFactoryArgs() throw a clear BaseError when factoryData is missing.
• Add regression coverage for the provided and missing factoryData paths.

Why

When factoryData is undefined, returning { factory, factoryData: undefined } can silently produce no init code for an undeployed account and defer the failure to bundler/EntryPoint simulation. The SDK cannot safely derive Coinbase Smart Account factory data from only a single owner and owner index, so failing early is safer.

Testing

• git diff --check
• corepack yarn workspace @base-org/account test createSmartAccount could not run because the local checkout has no Yarn state/install (Couldn't find the node_modules state file).

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 1 Sum 2

[osr21]

Reviewed the fix — the analysis in #377 is correct and failing early is the right call. The two-branch if returning the same value was clearly unfinished (// TODO: support creating factory data), and silently handing viem { factoryData: undefined } defers the failure to bundler simulation where the error message ("account not deployed" / AA20) gives no hint that the root cause is a missing SDK parameter.

Also agree that deriving factoryData locally is unsafe: createAccount(bytes[] owners, uint256 nonce) needs the full owner set and nonce, and reconstructing that from a single owner + ownerIndex risks computing factory data for a different deterministic address than the one the account object was created with — a silent wrong-account deployment is strictly worse than a thrown error.

One edge case worth verifying before merge: getFactoryArgs() is not only called on the deploy path. viem also calls it when wrapping signatures in ERC-6492 format for undeployed accounts (signMessage/signTypedData on a counterfactual account produce a 6492-wrapped signature embedding factory + factoryData). If any SDK flow signs with an undeployed smart account that was created without factoryData, this change moves the failure from "invalid 6492 signature that fails verification downstream" to "throw at signing time". That's still the better behavior — but it means the error can now surface in sign flows, not just deploy flows, so the error message could mention both. Suggestion:

'Cannot generate factory args for an undeployed smart account: factoryData was not
provided and cannot be derived locally. Deployment and ERC-6492 signing both
require factoryData for undeployed accounts.'

Worth grepping the SDK for getFactoryArgs call sites (including via viem's toSmartAccount internals) to confirm which flows can hit the throw, and adding one test for the signing path if it applies. Otherwise LGTM — the regression tests cover both branches and the behavior change is strictly an improvement in failure locality.