Builder intent

build with smart accounts

ZeroDev is a strong default when the product goal is smart-account UX rather than only embedded auth or only multisig operations. It covers Kernel smart accounts, paymasters, bundlers, gas sponsorship, batching, session-key permissions, EIP-7702, and chain abstraction. Privy can provide the user onboarding layer, Base gives a low-cost EVM execution default, The Graph handles app and account event indexing, and Safe supplies operational controls. Biconomy is intentionally listed as a separate alternative rather than preferred or combined by default.

Also available as JSON · Markdown

Recommended stack

transactions_and_paymasters100

Considered and excluded

biconomy — Biconomy is a separate account-abstraction provider and credible alternative, but this intent uses ZeroDev as the primary smart-account stack to avoid mixing provider-specific SDKs and paymaster assumptions.

Risks

Smart-account architecture is provider-specific: verify Kernel version, EntryPoint version, validator/plugin model, bundler RPCs, paymaster behavior, and target-chain support before production.
Gas sponsorship can fail when policies or account-level limits are reached; implement fallback behavior if actions should proceed without sponsorship.
Session keys and permissions can over-delegate account authority if signer, policy, action, spend cap, rate limit, and expiry rules are too broad.
Treat ZeroDev chain abstraction and embedded smart wallet surfaces as beta or rollout-dependent unless the current docs and support channel confirm production readiness for the exact flow.

Next steps

Choose the smart-account owner model: EOA, passkey/WebAuthn, social login via WaaS, or multisig/admin-controlled flows.
Pick Kernel, EntryPoint, validator, and chain targets, then run the ZeroDev quickstart against a project-specific RPC key.
Configure gas sponsorship policies and fallback middleware before shipping gasless transactions.
Define session-key policies with explicit contract allowlists, method allowlists, spend caps, rate limits, and expirations.
If using chain abstraction, verify supported tokens, input chains, output chains, gas-token mode, and plan tier.

Agent-facing output

What the agent receives

The intent page exposes the same structured recommendation shape agents should use: matched intent, stack roles, readiness scores, difficulty, risks, next steps, and registry version.

agent output · application/jsonstructured

{
  "intent": "I want to build an app with smart accounts, gasless transactions, session keys, and better wallet UX",
  "matched_intent": "build-with-smart-accounts",
  "recommended_stack": [
    {
      "slug": "zerodev",
      "name": "ZeroDev",
      "role": "transactions_and_paymasters",
      "readiness_score": 100,
      "integration_difficulty": "medium",
      "reason": "Use ZeroDev for Kernel smart accounts, ERC-4337 and EIP-7702 account flows, paymasters, bundlers, gas sponsorship, batching, and permission/session-key workflows."
    },
    {
      "slug": "privy",
      "name": "Privy",
      "role": "wallet_and_identity",
      "readiness_score": 82,
      "integration_difficulty": "low",
      "reason": "Use Privy if the app needs familiar auth, embedded wallet onboarding, and user account recovery around the smart account flow."
    },
    {
      "slug": "base",
      "name": "Base",
      "role": "settlement_or_execution",
      "readiness_score": 82,
      "integration_difficulty": "low",
      "reason": "Use Base as a low-cost EVM default for smart-account UX; ZeroDev docs and UltraRelay examples include Base and Base Sepolia."
    },
    {
      "slug": "the-graph",
      "name": "The Graph",
      "role": "indexing_and_data",
      "readiness_score": 80,
      "integration_difficulty": "medium",
      "reason": "Index account deployments, UserOps, sponsored actions, permissions, and app events for support, analytics, and agent-readable state."
    },
    {
      "slug": "safe",
      "name": "Safe",
      "role": "supporting_protocol",
      "readiness_score": 80,
      "integration_difficulty": "low",
      "reason": "Use Safe for team treasury, admin actions, emergency controls, and operational approvals around the consumer app."
    }
  ],
  "excluded_candidates": [
    {
      "slug": "biconomy",
      "reason": "Biconomy is a separate account-abstraction provider and credible alternative, but this intent uses ZeroDev as the primary smart-account stack to avoid mixing provider-specific SDKs and paymaster assumptions."
    }
  ],
  "risks": [
    "Smart-account architecture is provider-specific: verify Kernel version, EntryPoint version, validator/plugin model, bundler RPCs, paymaster behavior, and target-chain support before production.",
    "Gas sponsorship can fail when policies or account-level limits are reached; implement fallback behavior if actions should proceed without sponsorship.",
    "Session keys and permissions can over-delegate account authority if signer, policy, action, spend cap, rate limit, and expiry rules are too broad.",
    "Treat ZeroDev chain abstraction and embedded smart wallet surfaces as beta or rollout-dependent unless the current docs and support channel confirm production readiness for the exact flow."
  ],
  "next_steps": [
    "Choose the smart-account owner model: EOA, passkey/WebAuthn, social login via WaaS, or multisig/admin-controlled flows.",
    "Pick Kernel, EntryPoint, validator, and chain targets, then run the ZeroDev quickstart against a project-specific RPC key.",
    "Configure gas sponsorship policies and fallback middleware before shipping gasless transactions.",
    "Define session-key policies with explicit contract allowlists, method allowlists, spend caps, rate limits, and expirations.",
    "If using chain abstraction, verify supported tokens, input chains, output chains, gas-token mode, and plan tier."
  ],
  "generated_with": "composewith.eth",
  "registry_version": "2026.06.10-8752c9d"
}