Hardhat Network automining and state transition timing

Direct answer

Yes — the pending pool stays FIFO across the mode switch, and the switch itself does not touch block height. A transaction received after automining was disabled but before your first evm_mine is neither dropped nor mined early: it waits in the pool and is included, in arrival order, in the next block that gets produced — whether that block comes from a manual evm_mine or from automining being re-enabled.

Height advances only when a block is actually mined. With default parameters, each parameterless evm_mine call produces exactly one block containing all currently pending transactions, so the height increments by one per call no matter how many transactions were queued. While automining is on, the rule is instead one block per incoming transaction.

What I'm confident about vs. what to verify

This describes well-established Hardhat Network behavior on the 2.x line; I have not re-checked a specific release's source for this answer, so confirm the details on your installed version with the steps below.

• The mempool is ordered by arrival (FIFO), not by gas price, and that ordering survives mode switches.
• Disabling automining is a configuration change only: no block is produced and eth_blockNumber does not move.
• The pool is in-memory. If the node process restarts before the pending transaction is mined, that transaction is lost.
• Re-enabling automining makes the next received transaction trigger a block, which drains the pending pool in FIFO order along with it.

Verify in your session

// npx hardhat console (ethers v6 syntax)
await network.provider.send("evm_setAutomine", [false]);
const [signer] = await ethers.getSigners();
const tx = await signer.sendTransaction({ to: signer.address, value: 1n });

// still pending: no receipt, height unchanged
await network.provider.send("eth_getTransactionReceipt", [tx.hash]); // null
const before = await network.provider.send("eth_blockNumber");

await network.provider.send("evm_mine");

await network.provider.send("eth_getTransactionReceipt", [tx.hash]); // mined now
const after = await network.provider.send("eth_blockNumber");        // exactly before + 1

To confirm FIFO ordering specifically, send two or three transactions from different accounts while automining is off, mine once, and check that each transaction's transactionIndex in the new block matches the order in which you sent them.

Two caveats

• Same-sender nonces: while a transaction is pending, a second send from the same account without an explicit nonce can collide with it. Set the nonce explicitly when queueing several transactions from one signer.
• Recent Hardhat versions let evm_mine take optional blocks and interval parameters; with those it can create more than one block. The one-call-one-block rule applies to the parameterless form.

One detail that would change this advice: if interval mining (evm_setIntervalMining) is also active in your session, the pool drains on a timer as well, so a pending transaction may be mined before your manual evm_mine runs. Is interval mining configured here, or is this a pure automine-to-manual switch?