ERC-7579 modules.

Three precompiled validator modules ship with the network:

• SOCIAL_RECOVERY_VALIDATOR (0x101d) — N-of-M guardian quorum using composite Ed25519 + ML-DSA-65 signatures.
• SESSION_KEY_VALIDATOR (0x101e) — session-bound Ed25519 keys with target / selector allowlists, valid_after / valid_until, per-call and cumulative value ceilings.
• SPENDING_LIMIT_VALIDATOR (0x101f) — on-chain twin of the runtime SpendingPolicyResolver.

All three implement the IValidator trait and are AND-combined by ValidatorRegistry::validate_user_op. Every installed module must approve a UserOperation for the EntryPoint to accept it. Combined window is valid_after = max(...), valid_until = min_nonzero(...).

The four ERC-7579 selectors are byte-identical to Safe, Biconomy Nexus, ZeroDev Kernel, and Rhinestone — calldata is portable across the entire smart-account ecosystem.

SELECTOR_INSTALL_MODULE       = 0x9517e29f
SELECTOR_UNINSTALL_MODULE     = 0xa71763a8
SELECTOR_IS_MODULE_INSTALLED  = 0x112d3a7d
SELECTOR_VALIDATE_USER_OP     = 0xa97bfdd1

SmartAccount carries a validator_modules: BTreeMap<[u8; 20], ValidatorModuleConfig>. There are two install entry points:

• install_validator_module — root-key only, valid before social recovery has been used.
• install_validator_module_with_recovery — required after recovery; demands a guardian quorum proof.

uninstall_validator_module and is_validator_installed are the remaining accessors.

The off-chain SpendingPolicyResolver on AgentRuntime is not the primary control surface. On-chain validator modules enforce custody at signing time. The off-chain resolver is defence-in-depth — it catches drift between protocol-level DelegationScope and the on-chain spending limit, and it lets agent runtimes refuse a payment before minting a UserOperation.