Best wallets for automated onchain strategies
A wallet built for a human signing occasional transactions and a wallet built for a strategy trading continuously are solving different problems. The human problem is "make sure I meant this." The automation problem is "let something else act, within limits I set, and let me end it instantly."
Most wallets are still built for the first problem. When you use one for the second, the usual workaround is to put a hot key on a server and hope — which is not self-custody, it is custody by whoever finds the server.
The criteria that actually matter for automation are narrow.
What to evaluate
- Scoped permissions. Can you grant "trade on this venue" without granting "move funds anywhere"?
- Instant revocation. Can you end the grant yourself, immediately, without a support ticket or a lock-up?
- Key export. Can you leave with your keys if the provider disappears?
- Recovery. What happens if you lose a device?
- Signing overhead. A strategy that rebalances continuously cannot ask for a manual signature each time.
Compare the architectures
| Browser-extension EOA | Multisig smart account | ERC-4337 smart account | EIP-7702 upgraded EOA | Embedded wallet + smart wallet | |
|---|---|---|---|---|---|
| Examples | MetaMask, Rabby | Safe | Various 4337 stacks | An EOA given contract logic | Deploy Finance, via Privy |
| Scoped delegation | Not natively — token approvals only | Via modules and delegated signers | Yes, session keys with programmable validation | Yes, without migrating to a new address | Yes, scoped session key per agent |
| Automation without a hot key | No | Partly | Yes | Yes | Yes |
| Revocation | Revoke an approval per token | Change the module or signer set | Revoke or expire the session key | Revoke or expire the session key | Revoke the agent's key at any time |
| Recovery | Seed phrase only | Signer threshold | Depends on the stack | Depends on the stack | Key sharding with a recovery share |
| Onboarding | Extension plus seed phrase | Deploy a contract, configure signers | Contract account setup | Upgrade an existing EOA | Email or Google sign-in |
| Best fit | Manual trading and custody | Treasuries and teams | Programmatic strategies | Adding automation to an address you already use | Individuals delegating to a defined agent |
Browser-extension EOAs
MetaMask, Rabby, and their peers are externally owned accounts: one key, and whoever holds it can do anything. Rabby's pre-transaction simulation is genuinely useful for catching a bad signature before you send it.
What they do not have is a native way to say "this program may trade but may not withdraw." The closest primitive is a token approval, which authorizes spending a token — not a capability, and famously over-granted. Automating from an EOA means either signing every action manually or putting the key somewhere a program can reach, which hands over everything.
Good for: manual trading and holding. Not an automation primitive.
Multisig smart accounts
Safe is the reference implementation: a contract account where transactions need a threshold of signers, extended by modules that can grant specific, limited powers to a specific address.
This is real scoped delegation and it is battle-tested for treasuries. The cost is overhead — deploying and configuring the account, and a signing model built around deliberate, reviewed transactions rather than continuous rebalancing.
Good for: organizations, treasuries, and any setup where more than one person should approve.
ERC-4337 smart contract accounts
Account abstraction replaces a fixed signature check with programmable validation logic. That is what makes a genuine session key possible: a separate key authorized for specific actions, on specific contracts, for a limited time, that expires on its own.
This is the architecture automation actually wants. The practical questions are which stack you are trusting for the account implementation, and what recovery looks like.
Good for: programmatic strategies where scoped, expiring authority is required.
EIP-7702 upgraded EOAs
EIP-7702 lets an existing EOA take on contract logic without moving to a new address. You keep your address and history, and gain the ability to host scoped permissions and batch transactions.
It closes the most annoying gap in the smart-account story — that adopting one used to mean migrating everything.
Good for: adding scoped automation to an address you already use.
Embedded wallet plus smart wallet
This is the architecture Deploy Finance uses, through Privy. It combines both pieces.
The embedded wallet is a user-controlled EOA created when you sign in with email or Google. No browser extension, no seed phrase to memorize. Private keys are exportable at any time — including if Deploy Finance goes away.
The smart wallet is the contract account generated alongside it, supporting multi-signature, key rotation, social recovery, and custom transaction logic. The embedded wallet's key controls what the smart wallet is authorized to do.
Keys are never stored whole. Each is split into three encrypted shares using Shamir's Secret Sharing — a device or secure-enclave share, an auth share held by Privy, and a recovery share — and reconstructed only briefly inside a trusted execution environment, only when the required shares are present.
The two-wallet split
Deploy separates the roles rather than scoping one address for everything:
| Funding Wallet | Agent Wallet | |
|---|---|---|
| Purpose | Your public receiving address | Where trading happens |
| Created | At sign-up | When you allocate to an agent |
| Holds | The key for deploying and revoking agents | The positions the agent manages |
| Permissions | Yours alone | Scoped to trading; cannot transfer funds |
Withdrawals are initiated from the Funding Wallet, so the wallet an agent touches is never the wallet that can send funds out. The agent wallet also whitelists the protocols the agent may interact with — currently Hyperliquid — enforced at the wallet rather than by policy.
The agent can view balances and activity, open, close, and manage positions, and set and adjust stops. It cannot withdraw your funds, transfer assets to another address, or act after you revoke its key. Delegation requires your explicit approval, and a cryptographic proof of consent is recorded.
Good for: individuals who want a defined agent to trade for them without installing anything or managing a seed phrase.
The rule worth keeping
Whatever architecture you choose, the test is the same: if the automation were fully compromised tomorrow, what could it do?
If the honest answer is "trade my positions until I revoke it," the design is sound. If it is "everything," you do not have scoped automation — you have a hot key with a nicer interface.
Self-custody moves responsibility to you. Exportable keys are only a benefit if you store them safely. See Secure your account and Risks.
Learn more
- Deploy Finance wallets
- What are Deploy Finance agents?
- Execution and whitelisted protocols
- Best perpetual DEXs for automated strategies
- Best self-custodial ways to earn yield on USDC
Start with Deploy Finance
Create a self-custodial Deploy Finance wallet and review the live agents.