Smart-account policies

ERC-7579 validator modules on Tenzro accounts: passkey signers, session keys for agents, spending limits, hardware co-signers and guardian recovery.

Every Tenzro wallet is an ERC-4337 smart account with ERC-7579 validator modules. The modules are the policy: they decide, at signing time and on-chain, which signatures an operation needs and what it is allowed to do. Because the account address is the identity and the modules are the policy, you can add devices, grant agents limited power and recover from loss without the address ever changing.

Modules on every account

Module	Role
WebAuthn validator	The primary signer. Holds each enrolled device's P-256 passkey key and ML-DSA-65 key and requires a hybrid signature with user verification.
Session key validator	Lets an agent or app sign within a narrow scope, for a limited time.
Spending limit validator	Per-transaction and daily ceilings on value.
Social recovery validator	Guardians, a threshold, and recovery with a timelock and veto.
Hardware signer validator	An extra co-signer, such as a hardware wallet or FIDO2 security key, required always or above a value threshold.

Read the modules installed on an account, with their addresses and priorities:

bash

tenzro passkey get-smart-account --account-address 0xYourAccount

Modules combine with AND

Every installed module must approve a user operation for the EntryPoint to accept it. A session key that is inside its scope still fails if the spending limit would be exceeded; a passkey signature still fails if a required hardware co-signer has not signed. The operation's validity window is the tightest of the modules' windows: the latest valid_after and the earliest non-zero valid_until.

The on-chain modules are the control. Agent runtimes also check their spending policy before they build an operation, so an out-of-policy payment is refused early, but that check is a convenience and never the gate.

Session keys for agents

An agent never holds your passkey. You grant it a session key instead: a key held in the agent machine's own hardware (its TPM 2.0 or Secure Enclave), with a scope you set.

Scope	Effect
Selectors	Only these contract functions can be called
Targets	Only these contract addresses can be called
Per-call cap	Maximum value in one operation
Total cap	Maximum value over the key's lifetime
`valid_after`, `valid_until`	The time window in which the key works

bash

tenzro passkey grant-session-key \
  --account-address 0xYourAccount \
  --session-pubkey-hex <agent-session-key> \
  --selectors a9059cbb \
  --targets 0xPaymentContract \
  --max-per-call 1000000000000000000 \
  --max-total 50000000000000000000 \
  --valid-until 1798761600 \
  --label "inference agent"

Granting a session key is a custody change, so your passkey approves it. Revoking is one call, and the agent loses signing power at once:

bash

tenzro passkey revoke-session-key --account-address 0xYourAccount

Session keys on the account sit alongside the agent's own identity. An agent also has a machine DID and a delegation scope that limits which operations, payment protocols and networks it may use. See Agents and Identity.

Spending limits

Set a per-transaction cap and a daily cap in wei. 0 means unlimited. The spending limit validator enforces both on every operation, whoever signs it.

Accounts whose only root is a synced passkey run with reduced limits until a device-bound passkey or guardians are added; see Console and passkey wallet.

Two devices and hardware co-signers

Two-device approval. Set the account's policy to two_credentials and every operation needs signatures from two distinct enrolled devices.
Hardware co-signer. Install a hardware signer that must sign every operation, or only operations above a value threshold:

bash

tenzro passkey add-hardware-signer \
  --account-address 0xYourAccount \
  --device-kind generic \
  --public-key-hex 0x... \
  --required-above-wei 10000000000000000000

Both compose with the other modules rather than replacing them.

Guardians and recovery

The social recovery validator holds the account's guardians and threshold. Recovery installs a new passkey only when the guardians reach their threshold and a timelock passes without a veto from any existing device. See Device linking and recovery.

After an account has been recovered, installing a new validator module needs a guardian quorum proof as well as the new passkey. Before any recovery, the account's own signer can install modules.

Standard ERC-7579 calls

The module-management selectors are the standard ERC-7579 ones, so calldata built by ERC-7579 tooling works unchanged:

installModule(uint256,address,bytes)      0x9517e29f
uninstallModule(uint256,address,bytes)    0xa71763a8
isModuleInstalled(uint256,address,bytes)  0x112d3a7d
validateUserOp(bytes,bytes32)             0xa97bfdd1

Passkey signatures are checked on-chain through the P-256 verification precompile at 0x100 (EIP-7951), and user operations follow ERC-4337 v0.8. An externally owned account can also point its code at a smart-account implementation with EIP-7702; see EVM.

Methods

Method	Access	Purpose
`tenzro_getSmartAccount`	open	Installed modules and deployment state
`tenzro_listSmartAccounts`	open	Accounts known to the node
`tenzro_createCustodyChallenge`	open	Challenge for any change below
`tenzro_grantSessionKey`, `tenzro_revokeSessionKey`	owner	Session keys
`tenzro_setSpendingLimit`	owner	Per-transaction and daily caps
`tenzro_setPasskeyPolicy`	owner	One-device or two-device approval
`tenzro_addHardwareSigner`	owner	Hardware co-signer
`tenzro_addGuardian`	owner	Guardians and threshold

Owner methods need a hybrid passkey signature from a device already on the account, over a single-use challenge bound to the account, the operation and its target. The same calls are available in tenzro-sdk; see Hardware signer SDK.