Account Abstraction

Account abstraction (AA), or more formally known as ERC-4337 in the EVM ecosystem, is the means of execution on the blockchain through smart contract wallet. This wallet's signature validation and execution flow differs depending on the chain's architecture. In general, the user-signed userop are added to to a dedicated mempool and executed on-chain by solvers.

Ethereum Virtual Machine (EVM)

Lamina base uses a simple account wallet provided by eth-infinitism's ERC-4337 repo. Lamina has also been tested and has proven compatibility with other smart contract wallet schema such as Banana Wallet, Soul Wallet, SAFE, Forum Wallet, and others. aour analysis showed the most gas efficient design for Lamina base user operations was semi or full custodial smart contract wallets deployed with a ERC-1967 proxy.

The key difference between AA wallets regarding execution are plugin/hooks/preOp/postOp calls, paymaster integration, function selectors, and initialization code (initCode). This means the protocol API does the heavy lifting to route the user's calldata and wrap it to be executed on the respective AA wallet.

Plugins/hooks/preOps/postOps calls are operations that executes similarly to of a solidity modifier on the smart contract level. These can execute before the body code of userOp callData or afterwards. Lamina route it's hooks in the most compatible way.

These operations can be embedded on the smart contract level or can be the AA wallet calling a multicall that calls preOp/postOp calls around the primary call target. The later is preferred since we can use 100% of the existing architecture or ERC-4337 EntryPoint.

---

TON Virtual Machine (TVM)

Through our research we have found that TVM operates transactional operations non-atomically. This differs from the EVM and SVM architectures. But why does this matter? Normally to call crosschain we use a callback executed after the execution of the userops calldata execution on the smart contract wallet. Since we can not do this we need to be creative with both our smart contracts and infrastructure. The current transaction structure is a 267 bit domain, 124 bit nonce, 256 bit hash, dynamic calldata, and 65 bytes signature.

cell slice1 = begin_cell()
    .store_uint(domain, 256) ;; upper 267
    .store_uint(escrow_tx_id, 256) ;; lower 267 . 124 bit 
    .store_uint(user_op_hash, 256)
.end_cell();

1. The solver executes the transaction on the EntryPoint contract, for now only a simple whitelist for solvers.

2. The EntryPoint then calls the smart wallet proxy, which will validate the transaction and then execute.

3. Once the transaction completes execution on a future block the state of the relevant contracts will be tested for the correct new values within acceptable range, then call the EntryPoint to execute a callback call on the PayMaster contract.

4. Our backend listens to and digests messages to this contract to call crosschain to our other supported blockchains.

5. The solver will then get paid out as normal