7377: add links

EIPS/eip-7377.md

@@ -91,7 +91,7 @@ Naively, one could design the migration transaction to have a field `code` of ty
 
 ### Cheaper storage
 
-Since the storage is guaranteed to be empty, there is no need to read before write. This means only 20,000 gas is needed to pay for the EIP-2200 `SSTORE_SET_GAS` value. This is a small discount to the normal cost of `22,100`, which is `SSTORE_SET_GAS` plus the EIP-2929 `COLD_SLOAD_COST` of `2100`, because no load occurs.
+Since the storage is guaranteed to be empty, there is no need to read before write. This means only 20,000 gas is needed to pay for the [EIP-2200](./eip-2200.md) `SSTORE_SET_GAS` value. This is a small discount to the normal cost of `22,100`, which is `SSTORE_SET_GAS` plus the [EIP-2929](./eip-2929.md) `COLD_SLOAD_COST` of `2100`, because no load occurs.
 
 ### Intrinsic does not account for contract deployment
 
@@ -120,10 +120,10 @@ As with all sufficiently sophisticated account designs, if a user can be convinc
 ## On `ecrecover`
 
 Applications standards such as [ERC-2612: Permit Extension](./eip-2612.md) have exploited the cryptographic relationship between EOA addresses and their private keys. Many tokens today support this extension, allowing EOAs to approve the transfer of fund from their account using only a signature. Although collisions between EOAs and contract accounts are considered unlikely and [maybe impossible](./eip-3607.md) given today's computing power, this EIP would make it common place for private keys to exist for contract accounts. There are some considerations here regarding security:
-* The obvious attack is a defi protocol deploys some their contract using this EIP and later sign an ERC-2612 message to steal the funds accrued in the contract. This can be avoided by wallets simply not allowing users to interact with protocols deployed in this manner.
+* The obvious attack is a defi protocol deploys some their contract using this EIP and later sign an [ERC-2612](./eip-2612.md) message to steal the funds accrued in the contract. This can be avoided by wallets simply not allowing users to interact with protocols deployed in this manner.
 * It's also worth mentioning that there are concerns around how this EIP will affect the cross chain experience. Ultimately a users private key may still have some control over the account's assets, depending on the exact protocols used on Ethereum and on other chains. It isn't really possible perfectly migrate the EOA at the same time, on all chains. The best thing that can be done is to educate the user that just because their account has been migrated doesn't mean that they are safe to now publicly reveal their private key. This seems like a reasonable request, especially since they'll want to retain the private key in case they want to use the address on any other EVM-like chain.
 
-Something that may alleviate these issues to some degree would be to add an `EXTCODEHASH` check in `ecrecover`. If the recovered account has code, the precompile will revert. This would disallow migrated EOAs from using standards like ERC-2612.
+Something that may alleviate these issues to some degree would be to add an `EXTCODEHASH` check in `ecrecover`. If the recovered account has code, the precompile will revert. This would disallow migrated EOAs from using standards like [ERC-2612](./eip-2612.md).
 
 ## Copyright