Whitelist Request: AIFuturesTradingBot (Arbitrum) Owned by my EOA

Proposals
1

Hey GMX Team :waving_hand:

I’m requesting whitelist approval for my verified smart contract AIFuturesTradingBot deployed on Arbitrum One.
The contract is built to trade safely through GMX V2 using the official ExchangeRouter and OrderVault, but it’s currently reverting due to ROUTER_PLUGIN restrictions — meaning it needs governance-level whitelist approval to interact properly.

:gear: Contract Details

  • Name: AIFuturesTradingBot

  • Address: 0x65D949C99A11e57E570e38290C39C40A11849E32

  • Owner (EOA): 0x9a50D4A4e6F5C39F309e36a81917E0380fa249A8

  • Verifier Contract: 0xe0498Fa64352AB2e97D520E653441EA9e30835d4 (Groth16 ZK Verifier)

  • Exchange Router: 0x602b805EedddBbD9ddff44A7dcBD46cb07849685

  • Order Vault: 0x31eF83a530Fde1B38EE9A18093A333D8Bbbc40D5

    :magnifying_glass_tilted_left: Context & Current Issue

    The bot is fully functional in logic and compiles correctly.
    However, whenever it attempts to interact with GMX V2 routers, the transaction reverts with this error:

    Static raw: 0xa35b150b000000000000000000000000602b805eedddbbd9ddff44a7dcbd46cb078496850000000000000000000000000000000000000000000000000000000000000040
000000000000000000000000000000000000000000000000000000000000000d524f555445525f504c5547494e00000000000000000000000000000000000000

    When decoded, this corresponds to:

    ROUTER_PLUGIN revert — meaning GMX router requires governance-level whitelisting for external smart contracts initiating positions.

    All ERC20 approvals (ExchangeRouter + OrderVault) are done, verified on-chain, and working correctly. The revert only happens because the contract isn’t recognized as an approved plugin as per knowledge.

:puzzle_piece: Purpose & Architecture Summary

AIFuturesTradingBot is a non-custodial, AI-driven trading automation contract that:

  • Integrates with a verified AIPredictor to receive real-time AI predictions for long/short signals.

  • Trades only through GMX V2 official contracts — no custom swap logic or external routers.

  • Is strictly controlled by the owner (no public deposits or open interaction).

  • Implements security best practices:

    • ReentrancyGuard

    • SafeERC20

    • Callback safety checks

    • Explicit execution fee accounting

    • On-chain verified zk-SNARK model integrity verifier

:brain: What It Does

The bot:

  • Uses AI predictions to decide when to open or close WETH positions.

  • Sends trades through GMX’s ExchangeRouter → OrderVault → Market.

  • Handles ETH/WETH execution fee management and callback confirmations safely.

  • Does not hold any third-party funds or expose GMX liquidity.

It simply acts as a smart execution layer for AI-based strategy testing on GMX.

:locked_with_key: Requested Access

Whitelist permission for:

  • ExchangeRouter: 0x602b805EedddBbD9ddff44A7dcBD46cb07849685

  • OrderVault: 0x31eF83a530Fde1B38EE9A18093A333D8Bbbc40D5

This would allow the contract to properly open/close positions and send createIncreasePosition / createDecreasePosition calls without reverting.

:receipt: Verification Links

  • AIFuturesTradingBot.sol: Arbiscan Verified Source

  • Groth16Verifier.sol: Arbiscan Verified Source

  • AI Prediction System (off-chain): Connected Python bot generating verified predictions on-chain.

(GitHub link will be added once repository cleanup and documentation are finalized — all sources already verified on-chain.)

:folded_hands: Closing Note

This contract is purely for testing AI + DeFi integration and advancing automated trading on GMX.
I’ve verified all safety checks and execution paths locally and on a forked Arbitrum environment — everything works except the plugin restriction.

I’d really appreciate approval so we can continue testing this architecture responsibly on Arbitrum Mainnet under GMX V2.

Thank you for your time and for supporting open innovation :heart:
— Abdul Rafay, developer of AIFuturesTradingBot!

2 Likes
2

Thanks for reaching out, Abdul. I’m a bit puzzled as to why this would require its own whitelisted ExchangeRouter and OrderVault, but I can’t oversee your tech implementation. Let me bring in a developer.

1 Like
3

Thanks a lot, Jonezee!

The reason my AIFuturesTradingBot requires its own whitelisted ExchangeRouter and OrderVault access is mainly architectural — the bot manages autonomous AI-driven trading logic that routes orders directly via GMX V2’s router.

Specifically:

  • The bot executes trades programmatically based on AI predictions and ZK-proof-verified model outputs.
  • It uses createOrder() with callbackContract = 0x0 (no plugin) and pre-funds execution fees using sendWnt() and sendTokens().
  • However, GMX V2’s router currently reverts when the bot contract initiates createOrder() without being whitelisted.
    I confirmed this on Arbitrum Mainnet, and the revert data corresponds to ROUTER_PLUGIN:

0xa35b150b000000000000000000000000602b805eedddbbd9ddff44a7dcbd46cb078496850000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000d524f555445525f504c5547494e00000000000000000000000000000000000000
(If the core devs could confirm whether this indeed maps to ROUTER_PLUGIN, that would be extremely helpful.)

Goal of this request:
To allow my deployed bot contract
0x65D949C99A11e57E570e38290C39C40A11849E32
to interact directly with the GMX V2 router and vault, in the same way an EOA trader would — without any external callback or custom plugin logic.

Happy to share the verified contract source, deployment code, or full transaction traces if that helps the review.
Appreciate you looping in a developer, and I’ll be on standby for any further technical questions or clarifications.

1 Like
4

Perhaps the issue is simply that GMX’s ExchangeRouter contract was updated to the new address:

0x87d66368cD08a7Ca42252f5ab44B2fb6d1Fb8d15

Note: Creating orders does not require ROUTER_PLUGIN permissions (or any other).

5

Ah, that makes perfect sense — thank you so much, Jonezee!

You’re absolutely right, I was still using the older ExchangeRouter at:
0x602b805EedddBbD9ddff44A7dcBD46cb07849685

I’ll update my configuration to the new mainnet router address:
0x87d66368cD08a7Ca42252f5ab44B2fb6d1Fb8d15

Just to confirm for safety before redeploying:

  • The new router supports direct contract-based calls to createOrder() and createDeposit() without needing plugin whitelisting or callback contracts, correct?
  • And if the callbackContract parameter is set to 0x0, it will execute as a normal EOA-style trade submission?

Once confirmed, I’ll switch the address, recompile, and redeploy with the updated router reference.
Appreciate your time helping clarify this — that clears up a huge confusion!

6

Confirming your questions for you, allow me to revert on those in a bit

7

Yes it is, no whitelisting is needed

And if the callbackContract parameter is set to 0x0, it will execute as a normal EOA-style trade submission?

Correct!

8

Perfect — that clarifies everything, thank you so much Jonezee!
I’ll switch over to the new router (0x87d66368cD08a7Ca42252f5ab44B2fb6d1Fb8d15) and redeploy my AIFuturesTradingBot accordingly.
Great to know no plugin whitelisting is required anymore and that setting callbackContract = 0x0 will behave as a normal EOA trade submission.
Really appreciate your confirmation!

2 Likes