Skip to main content

Pali smart accounts

Pali smart accounts are contract wallets that Pali can create, connect, and operate for the user. The everyday UX can feel like a normal wallet account: review the dapp request, approve with a passkey or wallet key, and Pali submits the transaction. Under the hood the account is modular, so authorization and recovery can be upgraded without replacing the account address.

For non-technical users, the important idea is simple:

  • One account address: the smart account is the address dapps see and funds are held there.
  • Flexible sign-in: a passkey, a wallet-owned ECDSA key, or a co-managed policy can authorize actions.
  • Better recovery options: guardian recovery can replace the active validator after a timelock.
  • Batch actions: multiple contract calls can be approved as one reviewed action.
  • Clear wallet prompts: Pali shows what a dapp is asking for before creating or changing the account.

Technical model​

The current Pali account design is based on ERC-7579-style modules and ERC-4337-style execution encoding:

  • PaliSmartAccount is the account contract. It executes calls, validates signatures through installed validator modules, and exposes EIP-1271 signature checks.
  • PaliSmartAccountFactory derives deterministic account addresses and deploys accounts with initial modules.
  • Validator modules decide who can authorize actions. Pali currently supports ECDSA, P-256 WebAuthn passkeys, and a composite validator.
  • Executor modules add account features that are not ordinary signatures. Pali currently uses a guardian recovery executor.
  • Pali stores durable account metadata locally so it can reconstruct deterministic accounts by wallet anchor, account index, chain, factory, and module configuration.

The factory creates the account with a bootstrap wallet-owned ECDSA validator first. If a dapp requested a passkey or another supported validator, Pali deploys the account and then performs a wallet-signed module replacement. This keeps deployment deterministic and gives Pali a known local signer for the first on-chain setup action.

Two roles: validators sign, guardians recover​

ERC-7579 separates module roles, and Pali leans into that separation deliberately:

  • Validators check signatures for normal account approvals, such as passkeys, ECDSA signatures, and composite policies.
  • Executors can execute account actions through an installed module. Pali's guardian module requires the configured guardian threshold and a delay. The guided wallet flow uses it to replace the active validator; the on-chain module is not limited to that UI action.

Guardians are therefore a delayed account authority, not risk-free contacts. A compromised threshold can threaten account control and funds. The current owner can react during the delay, but must get a protective action confirmed before malicious execution. See the guardian recovery guide for setup, Disable guardian recovery, and optional email alerts.

Composite signing policies​

The composite validator combines child validators under a threshold, which turns one account into a policy engine:

  • 1-of-N — any of several authenticators can approve. Convenient for personal accounts with a passkey on each device.
  • t-of-N — a quorum must approve. The natural shape for shared treasuries, desks, and team-controlled accounts.
  • N-of-N — every configured validator must approve. Maximum-assurance accounts.

Pali currently collects locally available builtin child approvals until the configured threshold is met. Nested composites and external or cross-device approval collection are not supported by this wallet version. Guardian recovery remains independent of the active validator policy. See Smart accounts and validators for the supported policy shapes.

Validator agility and post-quantum readiness​

On configured networks, Pali supports wallet-owned ECDSA, P-256 WebAuthn passkeys, SLH-DSA and composite validators. The relevant on-chain modules must be deployed and the required local keys or credentials available. Replaceable modules also allow later signature schemes to be adopted on the same account address. Changing the validator does not move its funds, history or integrations.

The same agility extends to recovery. The guardian module verifies ECDSA approvals from normal addresses and ERC-1271 approvals from contract accounts. Pali can collect approvals from local key-based guardians and deployed local smart-account guardians it can sign for, including SLH-DSA accounts. The guardian's own policy governs that signature; an external guardian unavailable as a local signing account needs an external approval flow.

Why passkeys matter​

Passkeys use WebAuthn. Most platform passkeys sign with ES256, which is ECDSA over the P-256 curve. A normal EVM EOA uses secp256k1, so a passkey is not a normal Ethereum private key.

Pali's P-256 WebAuthn validator lets the smart account verify passkey proofs on-chain. The user approves with the browser or operating system passkey UI, while the passkey private key stays inside the authenticator or platform account.

For institutions and teams​

Institutions should treat Pali smart accounts as account infrastructure, not only as a passkey login flow. The useful controls are operational:

  • Use passkeys for lower-friction onboarding when a user should not handle a raw private key.
  • Use wallet-owned ECDSA or composite validators when a team, hardware wallet, or controlled owner set must co-authorize actions.
  • Use guardian recovery for a delayed replacement path when the active authenticator is lost.
  • Keep gas payer accounts funded because the current Pali flow uses wallet-paid deployment and execution.
  • Document who controls each validator, who the guardians are, and what the recovery delay means for the user.

The wallet UI is intentionally explicit when a dapp requests an external ECDSA owner. That address can approve future account actions, so Pali shows it separately and requires acknowledgement before continuing.

Dapp method​

Dapps request creation with wallet_prepareSmartAccount:

const account = await window.ethereum.request({
  method: 'wallet_prepareSmartAccount',
  params: [
    {
      label: 'Trading account',
      authenticator: { id: 'p256-webauthn' },
    },
  ],
});

If no authenticator is supplied, Pali defaults to a passkey-backed account. Dapps may request an ECDSA validator, but Pali distinguishes wallet-owned ECDSA owners from external addresses. External owner addresses are shown explicitly and require an extra user acknowledgement because those addresses can approve future smart-account actions.

Supported networks​

Pali smart accounts work on compatible EVM chains where the Pali smart-account infrastructure exists at the addresses Pali expects. The shipped wallet config includes known deployments, and Pali can also deploy the required infrastructure for the active EVM network from the wallet itself. If the network exposes the canonical CREATE2 deployer, open Pali Settings, go to Advanced, and use Smart account setup to deploy the missing factory and module contracts.

Passkey validators need P-256 WebAuthn verification support. Many modern EVM environments expose this through a P-256/passkey precompile, but integrators should verify chain support before relying on passkey validators.

NetworkChain idStatus in this Pali build
zkTanenbaum57057Configured for the Pali smart-account factory and modules.
zkSYSProduction config dependentIntended production target once the factory and module addresses are ready for the production network.
Other compatible EVM chainsChain-specificUse Pali's in-wallet Smart account setup flow to deploy the required infrastructure when the network has canonical CREATE2 support.

If a dapp calls wallet_prepareSmartAccount before the active chain has the required contracts available to Pali, Pali rejects the request instead of creating local-only metadata.

User control​

Browser or operating system passkey creation sheet
After wallet review, the browser or operating system handles WebAuthn passkey creation when the selected validator is passkey-based.

The user sees the requesting site, account label, requested authenticator, and any external ECDSA owner addresses before approving. The browser or OS shows the WebAuthn prompt when Pali needs a new passkey credential. Pali shows deployment, module installation, and confirmation progress before the smart account is connected to the dapp.

Dapp-initiated onboarding: review the request, confirm, and the smart account is live.

Standards references​

Pali smart accounts follow the same standards family described above: