Crypto Trainingblogweb3 security engineering
<- Back to blog

Crypto Training

Smart Accounts in Practice: Deep Technical Comparison of 10 Implementations

A code-first, risk-first deep dive of Coinbase, MetaMask, Thirdweb, Nexus, Light, Kernel, Safe, SimpleAccount, Solady, and Trust smart accounts: signature models, module systems, upgrades, replay controls, and security tradeoffs.

Crypto Training•2026-02-18•19 min read

Smart accounts are no longer one design space. They are a family of security architectures.

Two teams can both say “ERC-4337 smart account” and still ship radically different trust boundaries:

  • single signer vs multi-signer vs delegated authority graphs
  • static wallet logic vs module systems vs diamond/facet dispatch
  • minimal upgrade hooks vs powerful self-upgrade paths
  • strict replay domains vs explicit replayability lanes
  • validation-only plugins vs execution-time hooks with arbitrary code

This post is a deep, code-referenced comparison of the following implementations:

  • Coinbase Smart Wallet
  • MetaMask Smart Account (Delegation Framework DeleGator family)
  • Thirdweb Smart Account
  • Nexus Smart Account
  • Light Smart Account
  • Kernel (ZeroDev) Smart Account
  • Safe Smart Account (v1.5.0 core repo)
  • Simple Smart Account (eth-infinitism/account-abstraction v0.9.0)
  • Solady Smart Account
  • Trust Smart Account (Barz)

The emphasis is features vs risk. For each design, we ask:

  • What capability is being bought?
  • What new exploit or operational surface is being opened?
  • Which control reduces that surface?

Scope and methodology#

I used local source snapshots and pinned each implementation to a specific commit so links stay stable.

Baseline references#

Code snapshots#

  • Coinbase: coinbase/smart-wallet @ 503363d7a7bc1dd38fd6a4cf2e2778203d0a0d5c
  • Light: alchemyplatform/light-account @ 9368be5c9d627c4b8710f5a4c66e4cbff61399a0
  • Kernel: zerodevapp/kernel @ a4b75ee53bd3fc71fa81b8b82d9e078c3d75917e
  • Nexus: bcnmy/nexus @ 7db9b00b7288eaefbe0124abd9ed2daa3f4ae2cc
  • Thirdweb: thirdweb-dev/contracts @ 0da770f27209774061e118401e8b9796ead97ced
  • Solady: Vectorized/solady @ 90db92ce173856605d24a554969f2c67cadbc7e9
  • Safe: safe-global/safe-smart-account @ dc437e8fba8b4805d76bcbd1c668c9fd3d1e83be
  • SimpleAccount: eth-infinitism/account-abstraction @ b36a1ed52ae00da6f8a4c8d50181e2877e4fa410
  • MetaMask: MetaMask/delegation-framework @ b553aae72e4dcb704d927b567d839d38f7546d21
  • Trust: trustwallet/barz @ 86bc46378f5055561d841ca0880c4f4cb1cef988

One architecture, many trust boundaries#

sequenceDiagram participant User as User participant Bundler as Bundler participant EntryPoint as EntryPoint participant Account as Smart Account participant PM as Paymaster User->>Bundler: UserOperation Bundler->>Bundler: Simulation and policy checks Bundler->>EntryPoint: handleOps EntryPoint->>Account: validateUserOp EntryPoint->>PM: validatePaymasterUserOp EntryPoint->>Account: execute or executeUserOp EntryPoint->>PM: postOp EntryPoint->>Bundler: beneficiary payment

All compared systems plug into this broad flow. They differ in where they add complexity.

flowchart TD A[Signature Verification] --> B[Authorization Model] B --> C[Execution Surface] C --> D[Upgrade Surface] D --> E[Operational Controls] A1[EOA only] --> A A2[EOA and ERC1271] --> A A3[EOA and P256 and WebAuthn] --> A B1[Single owner] --> B B2[Multi owner threshold] --> B B3[Delegations and caveats] --> B B4[Module validators and policies] --> B C1[Direct execute] --> C C2[Module executors and hooks] --> C C3[Fallback selector routing] --> C C4[Diamond facets] --> C D1[No upgrade] --> D D2[UUPS] --> D D3[Facet replacement] --> D E1[Timelocks] --> E E2[Guardian approvals] --> E E3[Selector allowlists] --> E

10 implementations, side by side#

ImplementationValidation modelExtensibilityUpgrade modelSignature breadthDominant risk class
Coinbase Smart Walletowner-indexed EOA or P256/WebAuthnLimited built-in owner mgmt + replayable laneUUPSEOA + P256/WebAuthnReplay lane and upgrade path coupling
MetaMask DeleGatorERC-4337 + delegation graph validationDelegationManager + caveat enforcersUUPS-style in proxy patternEOA, multisig, hybrid P256, 7702 variantsDelegation policy/caveat misconfiguration
Thirdweb Accountaccount-permissions-based signer checksPermission system + extension contractsVariant dependentEOA signers with scoped permissionsPermission scope drift and misapproval
Nexusnonce-mode validator routing + prevalidation hooksFull module matrix (validator, executor, fallback, hooks)UUPSValidator-dependentModule composition and hook complexity
Light Accountsimple typed signature prefix dispatchSingle-owner and multi-owner variantsUUPSEOA + contract signaturesSignature type confusion and owner management errors
Kernelnonce-encoded validation modes + permissionsERC-7579-style validators/hooks/executors/fallbackUpgradeable implementation slotValidator/signer module dependentMode/nonce/selector access misconfigurations
Safe v1.5.0multisig EIP-712 tx hash checksModules + transaction/module guards + fallback handlerSingleton + proxy deploymentEOA and contract signaturesModule trust and guard bypass assumptions
SimpleAccountminimal owner ECDSAMinimalUUPSECDSA ownerMissing controls by design (feature poverty)
Solady ERC4337lightweight owner signature pathRich direct ops (delegateExecute, storageStore)UUPSERC1271 nested EIP-712 + ECDSAPowerful primitives becoming footguns
Trust Barzdiamond-routed account + pluggable verification facetsFacets, guardian, lock, migrationDiamond facet replacementsecp256k1 and secp256r1 passkey styleDiamond/facet governance complexity

1) Coinbase Smart Wallet#

What it does#

Coinbase’s design focuses on practical UX features while remaining relatively opinionated:

  • multiple owners stored as bytes (address or pubkey)
  • owner selection by index for compact calldata/signatures
  • EOA and P256/WebAuthn validation paths
  • explicit replayable transaction lane for selected self-calls
  • UUPS upgrades with additional code-existence checks in replayable flows

Key code:

Feature design details#

flowchart TD A[validateUserOp] --> B{callData selector == executeWithoutChainIdValidation} B -- yes --> C[recompute userOpHash without chainId] C --> D[require nonce key == REPLAYABLE_NONCE_KEY] D --> E[check replayable batch for upgradeToAndCall target code exists] B -- no --> F[require nonce key != REPLAYABLE_NONCE_KEY] E --> G[owner index based signature verification] F --> G

Risk profile#

  • Replay lane risk: controlled cross-chain replay is useful, but if the allowlist expands incorrectly, replay scope can widen fast.
  • Upgrade coupling risk: replayable path includes upgrade selector, so upgrade governance quality directly impacts replay risk.
  • Index-owner mismatch risk: index-based signature wrappers reduce calldata, but wrong index resolution creates sharp operational failure modes.

2) MetaMask Smart Account (Delegation Framework DeleGator)#

What it does#

MetaMask’s local implementation is the DeleGator family: smart accounts that combine ERC-4337 execution with a first-class delegation system.

Key code:

Feature design details#

sequenceDiagram participant Caller as Caller participant DG as DeleGator participant DM as DelegationManager participant CE as Caveat Enforcers participant Root as Root DeleGator Caller->>DG: redeemDelegations(permissionContexts, modes, executions) DG->>DM: redeemDelegations(...) DM->>DM: validate signatures and authority chain DM->>CE: beforeAllHook and beforeHook DM->>Root: executeFromExecutor DM->>CE: afterHook and afterAllHook

Risk profile#

  • Delegation graph risk: more expressiveness means more policy states to audit.
  • Caveat enforcer risk: each enforcer is code-level authority shaping execution.
  • Upgrade migration risk: clearing storage by default can brick behavior if migration choreography is poor.

3) Thirdweb Smart Account#

What it does#

Thirdweb leans into signer permissions and factory-driven account registries.

Key code:

Feature design details#

Risk profile#

  • Permission explosion risk: many signer scopes can become hard to reason about during incident response.
  • Target wildcard risk: wildcard target semantics are convenient but dangerous with weak operational controls.
  • Registry/factory consistency risk: signer indexing callbacks must stay in sync with account state transitions.

4) Nexus Smart Account#

What it does#

Nexus is a heavily modular ERC-7579-style account with multiple validation modes and operational safeguards for hook failures.

Key code:

Feature design details#

stateDiagram-v2 [*] --> ValidateMode [*] --> ModuleEnableMode [*] --> PrepMode ValidateMode --> Execute: validator selected from nonce ModuleEnableMode --> Execute: install module then validate PrepMode --> Execute: verify prep signature then initialize Execute --> [*]

Risk profile#

  • Module composability risk: cross-module assumptions can fail in emergent ways.
  • Hook liveness risk: malicious or broken hooks can impede critical paths; emergency uninstall helps but adds operational choreography.
  • Mode parsing risk: nonce-driven multiplexing must be audited as protocol-level parsing logic.

5) Light Smart Account#

What it does#

Light keeps account logic relatively compact while supporting both single-owner and multi-owner variants with typed signature prefixes.

Key code:

Feature design details#

flowchart TD A[signature bytes] --> B[first byte signatureType] B --> C[EOA path] B --> D[CONTRACT path] B --> E[CONTRACT_WITH_ADDR path] C --> F[recover and check owner set] D --> G[ERC1271 check owner contract] E --> H[decode owner address then ERC1271 check]

Risk profile#

  • Signature-type confusion risk: a one-byte type switch is efficient but parser strictness is critical.
  • Owner-set maintenance risk in multi-owner mode.
  • UUPS risk remains: upgrade governance quality determines final safety envelope.

6) Kernel (ZeroDev)#

What it does#

Kernel is an aggressively modular smart account architecture (ERC-7579 style) with validation modes, permissions, signer/policy modules, hooks, and fallback selector controls.

Key code:

Feature design details#

flowchart LR A[nonce] --> B[decode ValidationMode and ValidationType and ValidationId] B --> C{mode} C --> D[default validate] C --> E[enable mode install validation] D --> F{type} E --> F F --> G[validator module validateUserOp] F --> H[permission policies plus signer checks] F --> I[7702 signature check]

Risk profile#

  • Configuration risk dominates: misconfigured selector grants or validator permissions can undermine security assumptions.
  • Module lifecycle risk: install/uninstall data paths are complex and deserve invariant tests.
  • Hook execution risk: any pre/post hook can become critical availability or integrity boundary.

7) Safe Smart Account (v1.5.0 core)#

What it does#

Safe v1.5.0 core remains multisig-first. It is not a “native 4337 account” in this repo; instead, it provides a robust multisig core with module and guard extensibility, and compatibility hooks for contract signatures.

Key code:

Feature design details#

Note on 4337 in this repo snapshot: the explicit 4337 artifact present is a dummy test module/handler, not production wallet logic:

flowchart TD A[Safe execTransaction] --> B[checkSignatures] B --> C[optional Transaction Guard pre-check] C --> D[execute call or delegatecall] D --> E[optional Transaction Guard post-check] F[Enabled Module] --> G[execTransactionFromModule] G --> H[optional Module Guard checks] H --> I[module-triggered execution]

Risk profile#

  • Module trust risk is explicit and intentionally delegated to governance/ops.
  • Guard correctness risk: weak or broken guards can create false confidence.
  • Operational complexity risk grows with each enabled module and fallback handler.

8) Simple Smart Account (Infinitism v0.9)#

What it does#

SimpleAccount is the intentionally minimal reference account pattern.

Key code:

Feature design details#

Risk profile#

  • Feature poverty risk: minimalism reduces attack surface but omits many guardrails required in production ecosystems.
  • Upgrade governance still required due UUPS.
  • No native policy or rich auth model: external integrations must handle many concerns.

9) Solady ERC4337 Smart Account#

What it does#

Solady provides a compact but powerful baseline that many teams either use directly or fork.

Key code:

Feature design details#

Risk profile#

  • Power-feature risk: delegateExecute and storageStore are useful for account programmability, but are footguns if policy layers are weak.
  • Guard bypass risk if custom overrides alter storage/delegate guards incorrectly.

10) Trust Smart Account (Barz)#

What it does#

Trust’s Barz is a diamond-based modular account with extensive facet architecture: account execution, signature facets, migration, guardian controls, lock controls, fallback middleware, and registry gating.

Key code:

Feature design details#

flowchart TD A[Barz fallback] --> B{selector in diamond map} B -- yes --> C[delegatecall facet] B -- no --> D[query default fallback handler] D --> E{handler facet found} E -- yes --> C E -- no --> F[revert function does not exist]
stateDiagram-v2 [*] --> CurrentVerificationFacet CurrentVerificationFacet --> PendingMigration: migrateSignatureScheme PendingMigration --> FinalizedNewFacet: finalizeSignatureMigration after period PendingMigration --> Canceled: cancelSignatureMigration FinalizedNewFacet --> [*] Canceled --> [*]

Risk profile#

  • Diamond complexity risk is fundamental: selector maps + facet lifecycle + storage layout interaction is hard to audit.
  • Recovery/guardian windows improve safety but add liveness and operational error modes.
  • Verification migration safety depends on strict cut validation and robust approval semantics.

Cross-cutting security themes#

1) Replay safety is not one thing#

flowchart LR A[User signature] --> B{Replay scope} B --> C[Chain bound and account bound] B --> D[Chain agnostic but account bound] B --> E[Delegation graph bound] C --> C1[Safe EIP712 tx hash] C --> C2[Solady nested EIP712 ERC1271] D --> D1[Coinbase replayable nonce lane] E --> E1[DelegationManager authority chain]
  • Coinbase explicitly permits selected cross-chain replay lane.
  • Solady and Coinbase both include anti cross-account replay logic in ERC-1271 paths.
  • Delegation systems shift replay reasoning from nonce-only to authority graph state.

2) Extensibility is the largest risk multiplier#

flowchart TD A[Base account] --> B[Add modules or hooks] B --> C[More capabilities] B --> D[More trust edges] D --> E[More upgrade coupling] D --> F[More incident response complexity]

Low-extensibility accounts fail by missing features. High-extensibility accounts fail by misconfiguration and unsafe module governance.

3) Upgradeability is a governance problem first#

  • UUPS everywhere is not equal.
  • The question is: who can trigger it, under what signatures, with what migration constraints, and with what rollback plan.
flowchart TD A[Upgrade entrypoint] --> B[Auth checks] B --> C[Implementation code sanity checks] C --> D[State migration] D --> E[Post-upgrade validation] B --> B1[owner only] B --> B2[self or entrypoint only] B --> B3[module or facet governance flow]

Practical decision framework#

flowchart TD A[What is primary requirement] --> B{Simple custody with low change rate} A --> C{Need delegated permissions and caveats} A --> D{Need ecosystem module composability} A --> E{Need passkeys and consumer UX} B --> B1[SimpleAccount or constrained Light] C --> C1[MetaMask DeleGator] D --> D1[Kernel or Nexus] E --> E1[Coinbase Hybrid style or Trust r1 facet approach]
  1. If your team cannot run strong module governance and incident response, do not start with maximal modularity.
  2. If you need rich delegation, formalize delegation caveat policy review as a first-class security process.
  3. If you need passkeys, budget for signature parsing and verification fuzzing.
  4. If you rely on upgrades, write and test explicit migration playbooks before mainnet.

Risk vs feature scorecard (qualitative)#

ImplementationFeature richnessSecurity review burdenOps burdenBlast radius of misconfig
SimpleAccountLowLowLowMedium
LightMediumMediumMediumMedium
CoinbaseMedium-highMedium-highMediumHigh
Solady baseMedium-highHighMediumHigh
Safe coreHighHighHighHigh
ThirdwebHighHighHighHigh
KernelVery highVery highVery highVery high
NexusVery highVery highVery highVery high
MetaMask DeleGatorVery highVery highVery highVery high
Trust BarzVery highVery highVery highVery high

“Very high” is not “bad.” It means the implementation is powerful and can be secure, but requires disciplined engineering and operations.

Concrete failure modes and why they matter#

The most useful way to compare these systems in audit practice is by asking what actually breaks in production.

flowchart TD A[Feature added for UX or flexibility] --> B[New control path] B --> C[New governance assumption] C --> D[Hidden failure mode] D --> E[Incident class] E --> E1[Unauthorized execution] E --> E2[Funds frozen] E --> E3[Replay or cross-domain misuse] E --> E4[Upgrade lockout or takeover]

Coinbase Smart Wallet#

  • Failure mode: replayable lane allowlist accidentally expanded in future version.
  • Incident class: cross-chain replay of management actions outside intended scope.
  • Why this matters: replayability is a deliberate feature, so every selector in canSkipChainIdValidation is effectively a policy commitment.

MetaMask DeleGator#

  • Failure mode: caveat enforcer logic mismatch between intent and implementation.
  • Incident class: delegated authority overreach.
  • Why this matters: delegation chains are hard to reason about compositionally, and each caveat adds custom semantics.

Thirdweb#

  • Failure mode: signer gets over-broad approved target set or stale permissions.
  • Incident class: unauthorized but syntactically valid account actions.
  • Why this matters: signer-level policy is powerful and can drift operationally even if core validation code is correct.

Nexus#

  • Failure mode: wrong nonce mode or validator routing assumptions in clients.
  • Incident class: denial of service, wrong-module validation, or bypassed expected flow.
  • Why this matters: nonce-mode multiplexing is elegant but increases client and tooling correctness requirements.

Light#

  • Failure mode: signature type byte and payload encoding mismatch.
  • Incident class: validation failures or unintended validation path usage.
  • Why this matters: type-dispatched signatures are compact but unforgiving when integrations are inconsistent.

Kernel#

  • Failure mode: selector grants for a validator/permission set too wide.
  • Incident class: privileged method reachability via an otherwise-valid module.
  • Why this matters: module security depends on both module code and selector authorization topology.

Safe#

  • Failure mode: high-trust module introduced with insufficient review.
  • Incident class: complete Safe takeover through legitimate module powers.
  • Why this matters: Safe’s module model intentionally delegates large authority; this is a governance problem, not a bytecode bug.

SimpleAccount#

  • Failure mode: adopting it in production without compensating controls.
  • Incident class: missing policy constraints and weak operational recoverability.
  • Why this matters: minimal examples are excellent references, not complete risk frameworks.

Solady#

  • Failure mode: exposing delegateExecute or direct storageStore pathways behind weak auth assumptions.
  • Incident class: storage corruption, implementation slot corruption attempts, or unexpected control-plane writes.
  • Why this matters: Solady gives powerful primitives and assumes engineering maturity to constrain them.

Trust Barz#

  • Failure mode: facet cut, migration, guardian windows, and verification facet assumptions diverge.
  • Incident class: ownership model confusion, delayed recovery, or upgrade deadlocks.
  • Why this matters: diamond accounts are systems of systems; safety depends on lifecycle coherence across facets.

Feature-to-risk mapping#

flowchart LR A[Passkeys and P256] --> A1[Better UX and device auth] A --> A2[Complex signature parsing and verification] B[Module systems] --> B1[Composable capabilities] B --> B2[Combinatorial trust edges] C[Delegation graphs] --> C1[Fine grained authority] C --> C2[Caveat policy brittleness] D[UUPS and upgrades] --> D1[Fast patchability] D --> D2[Governance and migration hazards]

A good architecture decision is rarely “pick the most advanced system.” It is usually:

  • pick the smallest feature set that still supports product goals
  • prove operational discipline for the controls that architecture requires
  • add complexity only when the team can absorb its review and incident-response burden

Audit checklist by architecture class#

Minimal account class (SimpleAccount, basic Light)#

  • Validate signature malleability and digest domain assumptions.
  • Confirm upgrade auth and initializer protections.
  • Fuzz execute and batch execution for revert bubbling and authorization.

Permissioned signer class (Thirdweb, Coinbase owner-index model)#

  • Test every signer permission transition and revocation edge case.
  • Validate wildcard target semantics.
  • Confirm no confusion across signer type encodings.

Module-based class (Kernel, Nexus, Safe modules)#

  • Build a complete module graph inventory and allowed call graph.
  • Test hook failures and gas griefing around hook callbacks.
  • Validate emergency uninstall and timelock behaviors under stress.

Delegation/facet-heavy class (MetaMask DeleGator, Trust Barz)#

  • Prove delegation/facet state transitions with invariants.
  • Fuzz authority-chain and caveat/facet cut ordering.
  • Treat migration flows as privileged operations requiring separate threat models.

Final takeaways#

  • “ERC-4337 compatible” does not define your risk profile; your authorization and extensibility model does.
  • The strongest differentiator between these designs is not signature algorithm choice. It is how much policy logic you let execute at validation and execution time.
  • Features and risk scale together. Every step toward modularity and delegation requires an equal step in security process maturity.

If you are selecting an account architecture, start with your operational security budget, then choose the most constrained design that still meets product requirements.