The Problem

I recently switched from polkadot-v0.20.0 to polkadot-v0.37.0 in order to support V4 Ink Smart contracts.

But I am encountering the following error using the npm package @polkadot/api when batching multiple transactions as such:

await Promise.all(
  txs[addressid].map(async (val) => {
    let tokenId = Math.floor(100000 * Math.random());
    while (tokenIds.includes(tokenId)) {
      tokenId = Math.floor(100000 * Math.random());
    const storageDepositLimit = null;
    const { gasRequired } = await contract.query.mint(
        gasLimit: api?.registry.createType("WeightV2", {
          refTime: MAX_CALL_WEIGHT,
          proofSize: PROOFSIZE,
    const gasLimit = api?.registry.createType("WeightV2", gasRequired)
        { gasLimit },
    val.tokenId = tokenId;

await new Promise((resolve) => {
  api.tx.utility.batch(out).signAndSend(wallet, ({ status }) => {
    if (status.isInBlock) {
      ////console.log`Completed at block hash #${status.asInBlock}`);

RPC-CORE: call(method: Text, data: Bytes, at?: BlockHash): Bytes:: -32000: Client error: Execution failed: failed to instantiate a new WASM module instance: Limit of 32 concurrent instances has been reached".

On my substrate node, I had this error as well:

Ran out of free WASM instances

But I was able to solve this error by using the following flag:

--max-runtime-instance 256

Although the 'Ran out of free Wasm instances' error went away, i still have the Limit of 32 concurrent instances reached error!

my node is running polkadot-v0.37.0 npm packages:

    "@polkadot/api": "9.10.5",
    "@polkadot/api-contract": "9.10.5",

My suspicion

I think this has something to do with the fact that I transitioned from BTreeMap to a Mapping as a way to store values because BTreeMap is limited in how many keys it can store

1 Answer 1


Every time you call contract.query (for gas estimation in this case) an RPC call will be made which each uses its own Wasm instance. You are doing those queries in parallel. This makes sense as it potentially speeds up your code. However, by doing so you are essentially exhausting the resources of the node. A public node would probably throttle your requests and it would work. You can work around this by submitting your queries sequentially instead of in parallel.

Your suspicion is not the root cause. However, it might indirectly causing this issue by making your contract run slower and hence making the query take longer. But this is not really relevant here.

The limit of 32 concurrent instances seems to be hard coded here. You can try changing this value but I am not sure if this config is overwritten somewhere.

  • You are right about this, but what if I am controlling the nodes, is there a place in the substrate-node-template or what of the frame modules to change this limit?
    Mar 22, 2023 at 17:45
  • Added this information to the answer. Mar 31, 2023 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.