## Background
Sometimes, you don't want a transaction to be sent right away. For example, there might be an NFT mint that starts tomorrow at 7AM, but you don't want to wake up at 7AM to mint the NFT. With fun.xyz's automated actions, you can schedule a transaction at 7AM, pre-sign it, and make sure it only executes when the NFT mint opens.

This document explains the design decisions and the architecture of Automated Actions. This includes smart contract design, sdk changes, server changes, storage changes(dynamoDB), and a new service that simulates transactions and sends them to bundler.

## Tenets
Availability: When an automated action is scheduled, it should be executed as soon as the validation condition is true
Scalability: We want to minimize the costs are are paying to aws, dynamoDB, our api server, and the cost of rpcs for simulation

## Customer Experience
### Creating an Automated Action
Each automated action is based off of a module, which is a smart contract that plugs into funwallet.sol. Each automated action module has two functions `validate(bytes calldata data)` and `execute(bytes calldata data)`

contract AutomatedAction {
    function validate(bytes calldata data) public returns(bool){
    
    }
    
    function execute(bytes calldata data) external {}
}

The validate function will repeatedly be called, and the execute will be called as soon as validate returns true for that specific `data`.

### Sending an Automated Action
Automated Actions are sent from the SDK. When sending a transaction, a user can specify `automatedAction=true` in {Insert correct function from sdk here} and the transaction will be sent to the automated actions database instead of to the bundler

### The Automated Action being executed
The automated action userOp will sit in the database and the corresponding `validate()` function will be called. When validate returns true, the userOp will be sent to the bundler.

## Architecture

## Api Server Changes
### /createAutomatedAction
Parameters:
- chainId: number
- actionType: ActionType
- userOp: UserOperation
- moduleAddress: string
- data: BytesLike
- walletAddress: string

Creates an entry in the FunWalletAction DynamoDB
- status: Enum {Pending, Cancelled, Success, Failed}
returns actionId
### /deleteAutomatedAction
- actionId: string
- chainId: string

Deletes an entry in the FunWalletAction DynamoDB
We could also just use the existing delete method

### /executeAutomatedAction
- actionId: string
- chainId: string
- entryPointAddress: string

## Database Schema
We are using the same database `FunWalletAction` as the one being used in M of N transactions.

@table(FUN_WALLET_ACTION_TABLE_NAME)
export class FunWalletAction {
    @hashKey()
    actionId: string

    @rangeKey()
    chainId: string

    @versionAttribute()
    version: number

    @attribute()
    actionType: ActionType

    @attribute()
    authType: AuthType

    @attribute()
    groupId: string

    @attribute()
    message: string

    @attribute()
    walletAddr: string

    @attribute()
    nonce: string

    @attribute()
    userOp: UserOperation

    @attribute()
    status: FunWalletActionStatus

    @attribute()
    proposer: string

    @attribute()
    proposedTime: number

    @attribute()
    executedBy: string

    @attribute()
    executedTime: number

    @attribute()
    relatedActionIds: string[]

    @attribute()
    signatures: Signature[]

    @attribute()
    lastUpdatedTime: number
    
    ## These are new fields
    @attribute()
    data: string
    
    @attribute()
    moduleAddress: string
}

Might need to add a some key that lets us only query the actions that are relevant to automatedActions
## Cron Job
Tbh not sure what aws service to use here, but essentially we would:
1. Fetch all Actions from dynamoDB
2. For each action, check moduleAddress.validate(data) which is an onchain call. If this returns true, then send the userOp to the bundler. If this returns false, do nothing
## SDK
First class action vs sendTxLater
## Implementation Plan
- Write Demo smart contracts for automated actions(done)
- Create api server changes
- Create SDK changes
- Create Cron Job server

Do we every verify nonces in useroperations? If so, do we just check that the nonce has not been used in the past? If we check that the nonce > previous nonce + 1, automated actions will only be able to work in the order that you create automated actions in. If not, this might be a security issue, but not for automated actions

Is the dynamoDB live?

What do we use sendTxLater for? if that is true, can we just send the automated action to the database?