Skip to content

Conversation

@azf20
Copy link
Contributor

@azf20 azf20 commented Jun 26, 2025

Currently in the case of an approve swap, the gas estimation for the swap fails - in this case we submit each transaction sequentially. This means execution is slower, but is not blocked

Copy link
Collaborator

@technophile-04 technophile-04 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @azf20!

I was just trying this with example app which we have, and when I click send multiple transactions it says:

Screenshot 2025-06-27 at 6 22 21 PM

To test:

  1. Build and run the dev example
pnpm run build && pnpm run dev 

Send optimism sepolia to burner wallet and click send multiple greeting it shall fail

@azf20
Copy link
Contributor Author

azf20 commented Jun 27, 2025

Thanks for taking a look - did the transaction fail? Just tested locally and it worked for me, but I just pushed a commit which waits rather than getting which I think should fix it

20d33f5

@technophile-04
Copy link
Collaborator

Screen.Recording.2025-07-01.at.1.57.22.PM.mov

(skip to 0:40 sec for the error)

Ok seems like there are multiple problems, when I send the transaction with public RPC (in the example demo we are using public rpc) then it only sends one transaction. I think public rpc is rate limiting the second transaction or something.

With alchemy rpc: just paste this code in example dir wagmiConfig.ts

wagmiConfig.ts
import { connectorsForWallets } from "@rainbow-me/rainbowkit";
import { createConfig } from "wagmi";
import { hardhat, optimismSepolia } from "viem/chains";
import { metaMaskWallet } from "@rainbow-me/rainbowkit/wallets";
import { createClient, http } from "viem";
import { rainbowkitBurnerWallet } from "burner-connector";

// Use this if you want to enable session storage
// rainbowkitBurnerWallet.useSessionStorage = true;

/* Use custom RPC URLs to override wagmi's default RPC URLs if needed */
/* rainbowkitBurnerWallet.rpcUrls = {
  [optimismSepolia.id]: `https://opt-sepolia.g.alchemy.com/v2/${alchemyAPIKey}`,
}; */

const wallets = [metaMaskWallet, rainbowkitBurnerWallet];
const walletConnectProjectID = "3a8170812b534d0ff9d794f19a901d64";
const wagmiConnectors = connectorsForWallets(
  [
    {
      groupName: "Supported Wallets",
      wallets,
    },
  ],

  {
    appName: "scaffold-eth-2",
    projectId: walletConnectProjectID,
  }
);

export const DEFAULT_SEPOLIA_ALCHEMY_API_KEY =
  "oKxs-03sij-U_N0iOlrSsZFr29-IqbuF";

const alchemyUrl = `https://opt-sepolia.g.alchemy.com/v2/${DEFAULT_SEPOLIA_ALCHEMY_API_KEY}`;

export const chains = [optimismSepolia, hardhat] as const;

export const wagmiConfig = createConfig({
  chains: chains,
  connectors: wagmiConnectors,
  ssr: true,
  client({ chain }) {
    return createClient({ chain, transport: http(alchemyUrl) });
  },
});

Here on blockexplorer there seems to be transaction happening nicely but the transaction hash of second transaction which we are getting from viem seems to be different.

Solution which worked for me was having alchemy key + removing the nonceIncrement variable and only let request.nonce be there

@azf20
Copy link
Contributor Author

azf20 commented Jul 1, 2025

thanks for the detail - I removed the nonce increment, as you suggest that doesn't make sense when we're submitting the transactions sequentially. But I am not seeing the same issue with public RPCs, they are working ok for me, are you using the latest branch?

Copy link
Collaborator

@technophile-04 technophile-04 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tysm @azf20! Seems to work now nicely 🙌

Screenshot 2025-07-02 at 5 57 23 PM

@technophile-04 technophile-04 merged commit 4e27f94 into scaffold-eth:main Jul 2, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants