HyperFx Custom Bundler Tracking issue #1363

Activity

1. Wizdave97

   added a sub-issue on Oct 1, 2026

   • [simplex] Bundler whitelists in paymaster #1364
2. Wizdave97

   assigned

   royvardhan

   on Oct 1, 2026
3. Wizdave97

   added a sub-issue on Oct 1, 2026

   • [evm]: Select UserOpHash instead of solver address in solver selection #816
4. seunlanlege

   added sub-issues on Oct 1, 2026

   • [evm]: migrate SimplexPaymaster to EntryPoint v0.9 #1365
   • [evm]: migrate SolverAccount to EntryPoint v0.9 #1366
   • [sdk, simplex]: sign and submit bids against EntryPoint v0.9 #1367
   • [indexer]: index fills executed through EntryPoint v0.9 #1368
5. seunlanlege

   added this to the EntryPoint v0.9 milestone on Oct 1, 2026
6. royvardhan commented on Oct 2, 2026

   

   royvardhan

   on Oct 2, 2026

   Collaborator

   More actions

   On "Decide how bundles are submitted on Polygon and BNB Chain": I think we can use the default public sender (raw) on every chain and leave the private senders out.

   The only reason to submit privately is to stop a pending bundle from being copied and front-run, and #1364 already covers that. The paymaster only sponsors when tx.origin is one of our bundler wallets, so operations copied out of the public mempool fail paymaster validation for anyone else and our bundle still lands. That means there's no BNB sender to write, and no need to set up flashbots, polygonprivate or bloxroute.

   This holds only while the whitelist is set on that chain. If #1364 ends up treating an empty list as "any bundler", we should make sure our wallets are always listed.
7. Wizdave97 commented on Oct 2, 2026

   

   Wizdave97

   on Oct 2, 2026

   MemberAuthor

   More actions

   On "Decide how bundles are submitted on Polygon and BNB Chain": I think we can use the default public sender (raw) on every chain and leave the private senders out.

   The only reason to submit privately is to stop a pending bundle from being copied and front-run, and #1364 already covers that. The paymaster only sponsors when tx.origin is one of our bundler wallets, so operations copied out of the public mempool fail paymaster validation for anyone else and our bundle still lands. That means there's no BNB sender to write, and no need to set up flashbots, polygonprivate or bloxroute.

   This holds only while the whitelist is set on that chain. If #1364 ends up treating an empty list as "any bundler", we should make sure our wallets are always listed.

   With bundler whitelists on paymaster we can use the public mempool on all bnb and polygon. That's what alchemy already does on polygon. Private mempool would be a nice to have if possible for faster transaction inclusion.
8. royvardhan commented on Oct 8, 2026

   

   royvardhan

   on Oct 8, 2026

   Collaborator

   More actions

   Live testnet E2E

   Run on 2026-10-08 on BSC Chapel (97) and Polygon Amoy (80002), governed from Gargantua. The simplex testnet harness from #1375 ran against the HyperFX testnet orderbook. Our rundler (polytope-labs/rundler#3) bundled on each chain, with one solver.

   Setup on testnet

   Gargantua sudo:

   • registered the SimplexPaymaster proxies with addPaymasterDeployment: Chapel 0x9f4a6F1254f27373C2aca5bDd0e48FbA45EA3aeC, Amoy 0x6085a14078B7d26259145a894140f7C8361e02ae;
   • upgraded the IntentGatewayV2 proxy on both chains to 0x38a82f8283a0fAdB763888707aD18fCd34AF719D through executeOnGateway(upgradeToAndCall).

   Both upgrades landed at 12:38 UTC. The new SELECT_SOLVER_TYPEHASH is 0xe706bdab…e09e.

   Results

   All five scenarios were filled:

   Scenario	Fill txs
   same-chain (Chapel)	https://testnet.bscscan.com/tx/0x7e20b4cd0e2ab826dcb12ee8907cd24642d7dc4ae58db3e69be9237a39062f31
   cross-chain (Chapel to Amoy)	https://amoy.polygonscan.com/tx/0x7b37dd0a24f11373081d1cc66ee147095d071b0a27fc68bf10ad4294cbb171d9
   same-solver-levels (Chapel)	https://testnet.bscscan.com/tx/0x241e4fec96fc2a095c38628ccbb44a4fb120b8b1a8205960143539e33a7481de https://testnet.bscscan.com/tx/0xb136288f2f0cbffa50fa7b4738a40477732b4d09b9f310a873dd2a1ccfb5a1b7
   multi-leg-same-input (Chapel)	https://testnet.bscscan.com/tx/0xc44af90dfebe073f4acf13ba668524005828448c6d2891eae6a0837d38cc0612 https://testnet.bscscan.com/tx/0x2cacb0bf2cf4b5922a185360ebdb1fc806026646df56624d9b0e0e1511104d6c https://testnet.bscscan.com/tx/0x4df98330a46c393239e1f4d9a4725387bf1816783c16f3eb27aec74276710326
   onchain-limit (Chapel)	https://testnet.bscscan.com/tx/0xf71c5d76f47bd9108914becf2cb775ede7d40e31bbb6486a65077428b04169af

   Every one of the 8 fills was checked on chain:

   • it was sent by our rundler signer to EntryPoint v0.9;
   • its UserOperationEvent names that chain's SimplexPaymaster with success = 1;
   • the gateway's OrderFilled or PartialFill event is in the same transaction.

   What each PR got from the run

   • [evm, pallet-intents-coprocessor]: bundler allowlist and EntryPoint v0.9 for SimplexPaymaster and SolverAccount #1371
     • SimplexPaymaster on EntryPoint v0.9 sponsored all 8 fills. Each paymaster's deposit dropped by exactly the gas it paid for.
     • The solver re-delegated to the v0.9 SolverAccount 0x7484C6Ff790b898bf7e6960Ffc82f63330445Dc2, and every bid validated through it.
   • [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375
     • userOpHash solver selection ([evm]: Select UserOpHash instead of solver address in solver selection #816) worked through the upgraded gateways.
     • The SDK resolved EntryPoint v0.9 per bid and executed the best bid through our bundler ([sdk, simplex]: sign and submit bids against EntryPoint v0.9 #1367).
     • Simplex posted v0.9-signed limit orders and bid on every order.
     • The on-chain limit held: a payout one unit over the limit was refused with LimitOrderExceeded.
   • feat(chain_spec): add bsc and bsc_testnet, fix paymaster verification gas estimation rundler#2: the Chapel bundler ran on the new bsc_testnet spec.
   • feat: pause idle chain polling and add a paymaster allowlist rundler#3
     • With the paymaster allowlist set, both bundlers refused operations with no paymaster or an unknown one (-32602) and bundled every sponsored fill.
     • Idle pause: each bundler resumed within about a second of an operation and paused again 60 to 75 s after its last bundle.
     • The run surfaced early fee bumps. The cause is upstream code that starts the "not mined after N blocks" countdown at the head the build started on; the idle pause doesn't cause it. It's fixed on #3 in 55ba75f.
   • polytope-labs/hyperfx-orderbook#74: the testnet orderbook accepted all 19 v0.9-signed postings, and the fills above matched them.

   Not covered live yet

   • [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375, several solvers: the scenarios that need more than one solver, namely a partial fill split across solvers and falling back to another solver after a refused bid. The deployed testnet indexer does not know the new SolverAccount, so the orderbook drops new solvers' postings. I'm setting up a local indexer and orderbook to run these.
   • [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375, indexing: live indexing of v0.9 fills, which waits on the testnet indexer deployment.
   • [evm, pallet-intents-coprocessor]: bundler allowlist and EntryPoint v0.9 for SimplexPaymaster and SolverAccount #1371, bundler list: the on-chain bundler list, which is left empty on testnet.
   • [evm, pallet-intents-coprocessor]: bundler allowlist and EntryPoint v0.9 for SimplexPaymaster and SolverAccount #1371, migrate(): it only applies to the mainnet proxies, since the testnet proxies started at version 3.

   Mainnet rollout

   1. Merge [evm, pallet-intents-coprocessor]: bundler allowlist and EntryPoint v0.9 for SimplexPaymaster and SolverAccount #1371.

      • Check that CI on main is green. Nothing changes on chain yet.
      • Rebase [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375 onto main.

   2. Merge feat: pause idle chain polling and add a paymaster allowlist rundler#3 and run one rundler per mainnet chain. Each instance needs:

      • --enabled_entry_points v0.9 --unsafe and a funded signer;
      • --pool.paymaster_allowlist set to that chain's paymaster proxy, with idle pause on;
      • a per-chain --builder.max_blocks_to_wait_for_mine;
      • the default public-mempool sender on every chain, including Polygon and BNB Chain. The bundler list in step 8 makes a copied bundle revert, so no private sender is needed.

      Check that eth_supportedEntryPoints returns only v0.9 and that an operation with no paymaster gets -32602.

   3. Deploy the mainnet contracts on each chain: SolverAccount v0.9, the new IntentGatewayV2 implementation and the new SimplexPaymaster implementation.

      • Add the addresses to the SDK and indexer mainnet config on [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375.
      • Check that SolverAccount.entryPoint() is v0.9 and that the gateway implementation's SELECT_SOLVER_TYPEHASH is 0xe706…e09e.

   4. Upgrade the Nexus runtime to include the [evm, pallet-intents-coprocessor]: bundler allowlist and EntryPoint v0.9 for SimplexPaymaster and SolverAccount #1371 pallet change (set_paymaster_bundlers). Check that the call is in the runtime metadata.

   5. Merge [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375, release the SDK, and deploy the mainnet indexer and the HyperFX mainnet orderbook (with [DOCS] ISMP #74).

      • Check that the app on the new SDK still fills against the old gateways, since the SDK reads the selection format on chain.
      • Check that the indexer lists the new SolverAccount.
      • Hold back the simplex release to solvers, because it delegates to the new SolverAccount, which only works on an upgraded gateway.

   6. Cut over all chains in one governance window.

      • For each chain, send executeOnGateway(upgradeToAndCall(newImpl, "")) and upgrade_paymaster(newImpl, migrate()).
      • Polkadot Hub has no v0.9 EntryPoint, so turn solver selection off there or leave it out.
      • Check on each chain:
        • the gateway implementation and typehash;
        • the paymaster's version() is 3;
        • its v0.9 deposit equals the old v0.8 deposit;
        • the v0.8 stake is unlocking.

      Fills on a chain stop until step 7, so keep the gap short.

   7. Solvers move to the new simplex. It re-delegates to the new SolverAccount at boot, and they point at our bundlers.

      • Solvers need USDC or USDT on every chain, because an allowlisted bundler refuses self-paid bids.
      • Check that a small swap on each chain fills through our rundler signer with the paymaster.

   8. Set the bundler list on each chain with set_paymaster_bundlers, right after the cutover. It must include every rundler signer plus the simulation origin 0x0643866dA50efE0b055Cd15aF95191968c8411b5. Until it is set, someone can copy a bundle from the public mempool and land it first.

      • Check getBundlers() and run another swap.
      • Only remove a signer after it has stopped bundling.

   9. After the 24 h unstake delay, call withdrawStakeV08() on chains that had a v0.8 stake (Ethereum and BSC; Base had none). Check that the v0.9 deposit grew by the stake.
9. royvardhan commented on Oct 8, 2026

   

   royvardhan

   on Oct 8, 2026

   Collaborator

   More actions

   Live testnet E2E: multiple solvers

   These are the scenarios the earlier run couldn't cover. Three solvers ran on BSC Chapel and Polygon Amoy, and every fill went through our rundler (polytope-labs/rundler#3), with SimplexPaymaster sponsoring it.

   The deployed testnet indexer doesn't know the new SolverAccount yet, so these runs used a local HyperFX orderbook (hyperfx-orderbook main, including #74). That orderbook read a local indexer built from #1375. Everything else was live testnet.

   Scenario	Result	Fill txs (Chapel)
   partial	Two solvers filled one order: solver1 paid 9.78 USDC and solver2 the remaining 2.44 USDC, exactly the order's 12.22 USDC minimum	https://testnet.bscscan.com/tx/0xd508c548f96aa9ad3d160e2215354d0f70d2475bde6a26aa38023d20764d1ba6 https://testnet.bscscan.com/tx/0x015acd2d5f66a3f99290ae4436b59a9d856dfb6fed2adb0a5d077a093c4ef662
   onchain-limit-refusal	Solver1's best bid was refused on chain with LimitOrderExceeded, and solver2 filled the order instead	https://testnet.bscscan.com/tx/0x73b5d5b61cbc7bf326928dc50895a8fe5e8706668664a349780270b7a192cc2d

   • The [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375 indexer marked all three solvers as delegated to SolverAccount 0x7484C6Ff790b898bf7e6960Ffc82f63330445Dc2 on both chains, and the orderbook kept all their postings.
   • With this, every testnet scenario has now passed with userOpHash selection and our bundler.
   • What's left to confirm is the deployed indexer and orderbook, which will happen once the testnet indexer is deployed with the [evm, sdk, simplex, indexer]: EntryPoint v0.9 end to end with userOpHash solver selection #1375 config.
10. seunlanlege commented on Oct 9, 2026

    

    seunlanlege

    on Oct 9, 2026

    Member

    More actions

    closed in #1371
11. seunlanlege

    closed this as completedon Oct 9, 2026