Disable MetaMask Popups for Auto Stop Loss/Take Profit Closures in ethers.js dApp

Embedded Wallets (Web3Auth)
2

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)

  1. 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.

  2. 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.

  3. 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.

Resources

If helpful, I can:

  • 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