I’m building a trading dApp where users can open futures positions with Stop Loss (SL) and Take Profit (TP) levels. When the price reaches SL or TP, the trade should close automatically.
However, in my current implementation, when SL/TP is hit, MetaMask automatically opens a confirmation popup. The trade only closes after the user clicks “Confirm.”
Expected behavior:
SL/TP auto-close should happen without any MetaMask popup and without user confirmation. Only manual trade closure should require MetaMask.
I want guidance on the correct approach:
Is MetaMask able to auto-confirm a transaction?
Should SL/TP auto-close be executed by a backend keeper/bot using its own wallet instead of the user’s MetaMask signer?
What is the recommended architecture for automatic executions in an ethers.js + MetaMask dApp?
Purpose:
To understand the correct pattern for implementing automated SL/TP trade closures without requiring MetaMask confirmation, and confirm if this must be handled by a backend keeper/bot instead of the user’s wallet.
Hi pheonixdevelopers — thanks for the clear description. You’re asking about architecture (not a MetaMask bug) and whether MetaMask can auto-confirm transactions for automatic SL/TP closures. Short answer and recommended approach first, then extra options and resources.
Summary of what you provided (for the support team)
SDK details: Generic question (ethers.js dApp + MetaMask front end)
SDK version: not provided
Platform: Browser dApp using ethers.js with MetaMask as the user signer
Attachments: screenshot of MetaMask confirmation popup included
Key point (must-know)
MetaMask cannot auto-confirm or auto-sign transactions. MetaMask is intentionally user-driven and will always prompt the user to review and confirm transactions/signatures. There is no supported API to bypass that confirmation for security reasons.
Recommended architectures for automatic SL/TP execution (no MetaMask popup)
Backend keeper/bot (common, simple)
Run a server-side keeper bot that monitors price conditions. When SL/TP triggers, the keeper uses its own funded wallet (private key stored securely on the server) to call your contract’s close function and pay gas.
On-chain patterns: implement a public closePosition function that anyone (keepers) can call when conditions are met. Optionally reward the keeper with a bounty or gas reimbursement from the contract.
Pros: simple, reliable, no user UX friction. Cons: the keeper wallet is centralized and must be secured.
Decentralized keeper networks (recommended if you want less maintenance)
Use existing services: Chainlink Automation (Keepers), Gelato, or OpenZeppelin Defender Autotasks to monitor conditions and execute transactions. These services send transactions themselves (no MetaMask popup for the user).
Pros: lower ops burden, battle-tested. Cons: service fees and some centralization depending on provider.
Meta-transactions / relayer / user-signed authorizations (gas payer is the relayer)
The user signs an off-chain authorization (EIP-712 typed data) when opening the position. That signed payload authorizes a third-party relayer or keeper to execute the close on-chain later. The relayer submits the tx and pays gas. The contract verifies the user signature and closes the position.
Pros: trust-minimized (user explicitly authorized the action), keeps user control, no MetaMask popup at execution time. Cons: requires contract support for verifying signatures and relayer infrastructure. This pattern is used for “gasless” or delegated interactions.
Which to choose
If you control the contract and want fast, easy implementation: backend keeper or a keeper service calling a public close function + incentive is the fastest.
If you want a stronger trust model and avoid giving a centralized admin the ability to close positions: use signed authorizations (EIP-712) and relayers or a decentralized keeper network.
Minimal ethers.js example for a backend keeper (node) — runs without MetaMask
Keeper uses private key and provider (no MetaMask signer):
const { ethers } = require(‘ethers’);
const provider = new ethers.providers.JsonRpcProvider(RPC_URL);
const keeperWallet = new ethers.Wallet(process.env.KEEPER_PRIVATE_KEY, provider);
const contract = new ethers.Contract(CONTRACT_ADDRESS, CONTRACT_ABI, keeperWallet);
// when SL/TP observed
await contract.closePosition(positionId, { gasLimit: 300_000 });
Notes and security considerations
Keep the keeper private key in a secure vault (KMS, HashiCorp Vault, AWS Secrets Manager). Rotate keys, monitor usage, and limit funds in keeper wallets.
Make sure your contract has proper authorization checks and reentrancy/gas safety.
If you use relayer/meta-tx patterns, defend against replay attacks (nonces) and require EIP-712 typed data for clear signed intent.
Provide a fuller code example for an EIP-712 signed-authorization flow and contract verification
Show how to modify your contract to allow a public closePosition(…) with a keeper bounty
Recommend keeper network options depending on chain (L1 vs L2)
Do you control the smart contract for positions? If so, would you like a sample EIP-712 flow or a node keeper script for your chain (and which chain)? I can provide the next steps or code samples accordingly.
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours
