[WIP][DO NOT MERGE] Feat: Making SchedulingBase and DeadmanSwitch ERC-6900 compatible

[armanmamyan]

DeadmanSwitchModule

Purpose

Provides account recovery functionality through a nominated trusted party who can regain control of an account after a period of inactivity, preventing permanent loss of access to funds and data.

Problem Solved: Permanent loss of account access due to lost keys/devices
Solution: Trusted nominee can recover account after configurable inactivity period

Key Features:

• ✅ Automatic activity tracking via execution hooks
• ✅ Time-delayed nominee access with ERC-4337 integration
• ✅ Full ERC-1271 signature support for off-chain compatibility
• ✅ Configurable timeout periods and nominee management

Technical Specification

Module Type: Hybrid (Validation + Execution Hook)
Interfaces: IValidationModule, IExecutionHookModule

Core Functionality

1. Activity Tracking: Automatically updates last access timestamp on every transaction
2. Nominee Authorization: Allows nominated address to control account after timeout period
3. ERC-1271 Support: Enables nominee to sign off-chain messages for the account

Configuration Parameters

struct DeadmanSwitchConfig {
    uint48 lastAccess;    // Timestamp of last account activity
    uint48 timeout;       // Inactivity period before nominee access
    address nominee;      // Trusted recovery address
}

Installation Data Format

// abi.encode(uint32 entityId, address nominee, uint48 timeout)
bytes memory installData = abi.encode(1, nomineeAddress, 30 days);

Key Features

• Automatic Activity Detection: Pre-execution hook updates activity on every transaction
• Time-Delayed Access: Nominee can only act after the configured timeout period
• Signature Validation: Full ERC-1271 support for off-chain integrations
• Flexible Configuration: Nominee and timeout can be updated by account owner

Security Features

• Self-Call Protection: Account owner retains full control during normal operation
• Time-Based Validation: Uses ERC-4337 validAfter for UserOperation timing
• Zero-Address Protection: Prevents installation with invalid nominee addresses
• Timeout Validation: Ensures non-zero timeout periods

---

SchedulingBaseModule

Purpose

Abstract base contract providing scheduling functionality for time-based recurring transactions, enabling automation of regular payments, DCA strategies, and periodic operations.

Problem Solved: No native support for recurring/scheduled transactions
Solution: Abstract base for building time-based automation modules

Key Features:

• ✅ Interval-based job execution with comprehensive validation
• ✅ Flexible job management (add, toggle, configure)
• ✅ Abstract pattern for specialized implementations (DCA, payments, etc.)
• ✅ Built-in gas optimization and error handling

Technical Specification

Module Type: Execution (Abstract)
Interfaces: IExecutionModule

Core Functionality

1. Job Management: Create, enable/disable, and track scheduled jobs
2. Interval-Based Execution: Execute jobs at specified time intervals
3. Execution Limits: Define maximum number of executions per job
4. Abstract Pattern: Concrete implementations define specific execution logic

Configuration Parameters

struct ExecutionConfig {
    uint48 executeInterval;           // Time between executions
    uint16 numberOfExecutions;        // Total executions allowed
    uint16 numberOfExecutionsCompleted; // Current execution count
    uint48 startDate;                // When executions can begin
    bool isEnabled;                  // Whether job is active
    uint48 lastExecutionTime;        // Last execution timestamp
    bytes executionData;             // Implementation-specific data
}

Order Data Format

// Fixed-size header (14 bytes) + variable execution data
bytes memory orderData = abi.encodePacked(
    uint48 executeInterval,    // 6 bytes
    uint16 numberOfExecutions, // 2 bytes
    uint48 startDate,         // 6 bytes
    bytes executionData       // Variable length
);

Execution Functions

1. addOrder(uint32 entityId, bytes orderData) - Creates new scheduled job
2. toggleOrder(uint32 entityId, uint256 jobId) - Enables/disables job
3. executeOrder(uint32 entityId, uint256 jobId) - Abstract - Must implement
4. getExecutionConfig(...) - Returns job configuration

Validation Logic

The base module provides comprehensive execution validation:

modifier canExecute(uint32 entityId, uint256 jobId) {
    // Check job is enabled
    // Verify interval has passed since last execution
    // Ensure execution limit not reached
    // Confirm start date has passed
    _;
}

Module-Specific Security

DeadmanSwitchModule

• Nominee Trust: Nominee selection is critical as they gain full account control
• Timeout Selection: Balance between security and usability (recommended: 30-365 days)
• Activity Tracking: All transactions reset timer, preventing selective inactivity

SchedulingBaseModule

• Implementation Security: Concrete implementations must handle execution failures gracefully
• Resource Management: Consider gas costs and account balance for recurring operations
• Timing Attacks: Use block timestamps carefully to avoid manipulation