Skip to main content
Locus uses a smart wallet architecture to maintain user control while allowing our backend to sign messages. This is done through a single-signer ERC-4337 account that validates against two possible signers.

User Key

Generated on the user-facing website at creation and never stored on Locus servers.

Permissioned Key

Stored securely in a hardware security module (HSM). Can be revoked by the user at any time.
The user-owned key can revoke access to the permissioned key at any time via revokePermissionedKey(). The permissioned key can rotate itself to a new key via setPermissionedKey(), but only the owner can fully revoke it.
All Locus wallets run exclusively on Base. They are based on ERC-4337 and run gaslessly through our own paymaster system.

Locus Smart Wallet

The Locus Smart Wallet is based on the ERC-4337 contract from Solady with modifications to allow for both keys to sign and the user key to revoke access.
UUPS upgradeability is explicitly disabled — _authorizeUpgrade always reverts — making the implementation immutable.
All user wallets are deployed as deterministic ERC1967 proxies via CREATE2 through the LocusFactory. Wallet addresses are predictable before deployment using LocusFactory.getAddress().

View Implementation

Audit the smart wallet implementation on BaseScan.

Factory

The LocusFactory handles wallet deployment. It extends Solady’s ERC4337Factory and deploys ERC1967 minimal proxies (52 bytes runtime code) with deterministic addresses via CREATE2.
The factory supports single and batch wallet creation, and sets the permissioned key atomically during deployment to prevent frontrunning.

Subwallets

Locus allows agents and users to send funds to email addresses. This is done through a subwallet system to isolate escrowed funds.

How Email Sends Work

1

Initiate Send

createAndFundSubwallet() is submitted as a UserOperation through the EntryPoint, signed by the Locus permissioned key, to deploy a minimal proxy.
2

Fund Subwallet

The subwallet receives the funds the user or agent would like to send to the email address.
3

Email Notification

An email containing a one-time password is sent to the recipient.
4

Claim Funds

The recipient can claim funds to a wallet address of their choosing.

Time-Limited Escrows

Each subwallet enforces a disburseBefore deadline — funds cannot be disbursed after this timestamp, and transferToken will revert with DisbursementDeadlinePassed. This ensures escrows are time-limited.

Subwallet Reuse

Once funds are claimed, the deployed subwallet is deactivated and returned to a reuse pool. When the next email payment is needed, an inactive subwallet is reactivated via activate() rather than deploying a new proxy.
There is a hard cap of 100 subwallet proxies per wallet (MAX_SUBWALLETS).

View Subwallet Implementation

Audit the subwallet implementation on BaseScan.