7377: fix list issue

EIPS/eip-7377.md

@@ -120,6 +120,7 @@ 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](./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.