fix: broken links due to .md ending

pages/docs/bundlers/running-a-bundler.md

@@ -2,12 +2,12 @@
 When a bundler receives a `UserOperation`, it must first run some basic sanity checks, namely that:
 
 * Either the `sender` is an existing contract, or the `initCode` is not empty (**but not both**)
-* If `initCode` is not empty, parse its first 20 bytes as a factory address. Record whether the factory is staked, in case the later simulation indicates that it needs to be. If the factory accesses global state, it must be staked - see [reputation, throttling and banning](../faqs/reputation-throttling-banning.md) section for details.
+* If `initCode` is not empty, parse its first 20 bytes as a factory address. Record whether the factory is staked, in case the later simulation indicates that it needs to be. If the factory accesses global state, it must be staked - see [reputation, throttling and banning](../faqs/reputation-throttling-banning) section for details.
 * The `verificationGasLimit` is sufficiently low (`<= MAX_VERIFICATION_GAS`) and the `preVerificationGas` is sufficiently high (enough to pay for the calldata gas cost of serializing the `UserOperation` plus `PRE_VERIFICATION_OVERHEAD_GAS`)
-* The `paymasterAndData` is either empty, or start with the **paymaster** address, which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the `UserOperation`, and (iii) is not currently banned. During simulation, the paymaster's stake is also checked, depending on its storage usage - see [reputation, throttling and banning](../faqs/reputation-throttling-banning.md) section for details.
+* The `paymasterAndData` is either empty, or start with the **paymaster** address, which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the `UserOperation`, and (iii) is not currently banned. During simulation, the paymaster's stake is also checked, depending on its storage usage - see [reputation, throttling and banning](../faqs/reputation-throttling-banning) section for details.
 * The callgas is at least the cost of a `CALL` with non-zero value.
 The `maxFeePerGas` and `maxPriorityFeePerGas` are above a configurable minimum value that the bundler is willing to accept. At the minimum, they are sufficiently high to be included with the current `block.basefee`.
-The `sender` doesn't have another `UserOperation` already present in the pool (or it replaces an existing entry with the same `sender` and `nonce`, with a higher `maxPriorityFeePerGas` and an equally increased `maxFeePerGas`). Only one `UserOperation` per `sender` may be included in a single batch. A `sender` is exempt from this rule and may have multiple `UserOperations` in the pool and in a batch if it is staked (see [reputation, throttling and banning](../faqs/reputation-throttling-banning.md) section), but this exception is of limited use to normal accounts.
+The `sender` doesn't have another `UserOperation` already present in the pool (or it replaces an existing entry with the same `sender` and `nonce`, with a higher `maxPriorityFeePerGas` and an equally increased `maxFeePerGas`). Only one `UserOperation` per `sender` may be included in a single batch. A `sender` is exempt from this rule and may have multiple `UserOperations` in the pool and in a batch if it is staked (see [reputation, throttling and banning](../faqs/reputation-throttling-banning) section), but this exception is of limited use to normal accounts.
 
 If the UserOperation object passes these sanity checks, the bundler must next run the first op simulation, and if the simulation succeeds, the bundler must add the op to the pool. A second simulation must also happen during bundling to make sure the `UserOperation` is still valid.
 

pages/docs/faqs/reputation-throttling-banning.md

@@ -7,5 +7,5 @@ The stake value is not enforced on-chain, but specifically by each node while si
 ## Un-staked entities
 Under the following special conditions, unstaked entities still can be used:
 * An entity that doesn't use any storage at all, or only the sender's storage (not the entity's storage - that does require a stake)
-* If the `UserOperation` doesn't create a new account (that is `initCode` is empty), then the entity may also use [storage associated with the sender](../bundlers/running-a-bundler.md)
+* If the `UserOperation` doesn't create a new account (that is `initCode` is empty), then the entity may also use [storage associated with the sender](../bundlers/running-a-bundler)
 * A paymaster that has a `postOp()` method (that is, `validatePaymasterUserOp` returns `“context”`) must be staked

pages/docs/understanding-ERC-4337/account-contract.md

@@ -4,7 +4,7 @@ With EOAs, the address is consistent across all EVM networks. As long as the use
 
 Users should be able to deterministically know their account address and keep it consistent on every EVM network irrespective of whether the account has been deployed or not. This means that they can generate an account and start sending funds to it with the knowledge that they'll be able to control those funds at any time, provided they have the correct verification method.
 
-ERC-4337 does this by using the `CREATE2` opcode through a [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) - the [Account Factory contract](./account-factory-contract.md). 
+ERC-4337 does this by using the `CREATE2` opcode through a [Singleton Factory](https://eips.ethereum.org/EIPS/eip-2470) - the [Account Factory contract](./account-factory-contract). 
 For example, here is how you can calculate a `CREATE2` address with ethers.js:
 
 ```