Extending Smart Account Kit With Custom Smart Account Logic

Smart Accounts
,
2

Hi Francisco — thanks for the clear description, and nice work getting the full kit (WebAuthn signer + viem + deterministic deployment + Pimlico) working in production. I think what you want to do (add custom contract logic while keeping the Smart Account Kit runtime stack) is a common ask. Below I’ve summarized what I pulled from your message, a high-level compatibility checklist, a suggested approach, and a short list of items we’d need if you want the team to dig in further.

Summary (what you’ve provided)

  • SDK Details: MetaMask Smart Accounts SDK (Gator)
  • SDK Version: not provided — please share if available
  • Platform: Web (viem + WebAuthn signer)
  • Bundler / Paymaster: Pimlico
  • Deployment: Deterministic deployment
  • Goal: Keep Smart Account Kit flow (signer, bundler, paymaster, deployment) but add custom smart-account contract logic (extra methods, validation, modules/hooks, custom execution flows)

Short answers to your numbered questions

  1. Can you replace the default account implementation with your own contract?
  • Generally: yes — you can use a custom account implementation, but it must remain compatible with the runtime assumptions the kit, bundler, and paymaster expect. In many cases it’s simpler and safer to extend via modules/hooks if the default account supports them.
  1. What requirements must the contract fulfill for compatibility?
  • High-level requirements (what the support team will look for):
    • Implement the same entrypoints / validation flow the bundler expects (i.e., the account contract must accept and validate the user-operation / execution format used by the bundler).
    • Support the signature format produced by the WebAuthn signer (or provide a compatible verification path). The account must be able to verify signatures in the same way the default account does.
    • Provide compatible nonce management and replay protection so the bundler/paymaster can sequence ops reliably.
    • Be deployable deterministically by whatever factory/deployer the kit uses (if you rely on deterministic addresses).
    • Expose any hooks the paymaster or bundler use for pre/post validation if they rely on specific behavior.
    • If you change the entrypoint ABI or flow, you’ll need to ensure the bundler and paymaster code paths are adapted (or remain backward compatible).
  1. Documentation / examples
  • There isn’t a one-size-fits-all sample for every custom account. Start with the Smart Account Kit docs and the Builder Hub for examples of modular/customization patterns. If you prefer, we can point to any available Smart Account Kit guides or community examples — please tell me the SDK version and I’ll fetch targeted docs/examples.

Suggested approach (safe path)

  • Option A — Modules/Extension pattern (recommended if supported):
    • Add your application logic as a module or delegate that the default smart account can call. This avoids replacing the account entrypoints and preserves full compatibility with signer/bundler/paymaster.
  • Option B — Custom account contract (if modules insufficient):
    • Mirror the default account’s external entrypoints used by the bundler/paymaster (same ABI/semantics).
    • Ensure signature verification accepts the WebAuthn signatures (or include an adapter function).
    • Keep nonce semantics and deterministic factory behavior the same (or provide a compatible factory).
    • Test thoroughly with a local bundler + paymaster (staging Pimlico) before production rollout.

What would help the support team move faster

  • SDK version number you’re running (Smart Accounts SDK / Gator)
  • Whether you prefer to extend via modules or must replace the full account contract
  • If you’ve already drafted a custom contract: the contract ABI + address (or code snippet of the custom parts), and how you plan to verify signatures
  • Any errors or unexpected behavior you’ve already observed (browser console logs or bundler responses) — include screenshots or logs only if you hit a runtime issue
  • Code init / login snippets (only needed if you run into integration issues)

If you’d like, I can:

  • Review a short snippet of your desired contract changes and flag compatibility gaps
  • Point you to the exact Smart Account Kit docs/examples once you provide your SDK version
  • Escalate to internal support with the details above

Would you like to share the SDK version and whether you’d prefer the module approach or full-account replacement? If you already have a contract snippet, paste the key parts you’re changing (signature verification/nonce/entrypoints) and I’ll review for compatibility.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours