diff --git a/RIPS/rip-7560.md b/RIPS/rip-7560.md
index 338d436..1cc4543 100644
--- a/RIPS/rip-7560.md
+++ b/RIPS/rip-7560.md
@@ -13,8 +13,8 @@ requires: 4337, 6780
 
 ## Abstract
 
-Combining the [EIP-2938](./eip-2938)
-and [ERC-4337](./eip-4337)
+Combining the [EIP-2938](https://eips.ethereum.org/EIPS/eip-2938)
+and [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337)
 into a comprehensive Native Account Abstraction proposal.
 
 We propose splitting the Ethereum transaction scope into multiple steps: validations, execution,
@@ -75,7 +75,7 @@ smart contracts. This, however, is impossible without an addition of Native Acco
 
 ### New Transaction Type
 
-A new [EIP-2718](./eip-2718) transaction with type AA_TX_TYPE is introduced. Transactions of this type are referred to as
+A new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction with type AA_TX_TYPE is introduced. Transactions of this type are referred to as
 “AA transactions”. Their payload should be interpreted as:
 
 ```
@@ -274,7 +274,7 @@ in order for the transaction to be considered valid for a given position in a bl
 
 In terms of block validity, all validation and execution frames may read and write any state when included in the block.
 However, the AA transactions in the mempool SHOULD be bound by storage access rules to avoid DoS on block builders.
-These rules are defined in [ERC-7562](./eips/eip-7562).
+These rules are defined in [ERC-7562](https://eips.ethereum.org/EIPS/eips/eip-7562).
 
 In all top-level frames, the global variables have the following meaning:
 
@@ -562,8 +562,8 @@ There is a number of behaviours that define transaction-wide effects in Ethereum
 This list includes, but is not limited to:
 
 * Tracking `accessed_addresses`
-* [EIP-1283](./eip-1283) Gas metering for SSTORE
-* [EIP-1153](./eip-1153) Transient storage opcodes
+* [EIP-1283](https://eips.ethereum.org/EIPS/eip-1283) Gas metering for SSTORE
+* [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153) Transient storage opcodes
 
 Any such behaviour has separate effects in the "Validation Virtual Transaction" and "Execution Transaction".
 
@@ -792,9 +792,9 @@ It will enable all existing EOAs to benefit from the improved UX features like g
 
 In the future, this can be used to pay gas for transactions that add code to the EOA addresses,
 once Ethereum implements changes like the ones proposed in
-[EIP-5003: Insert Code into EOAs with AUTHUSURP](./eip-5003),
-[EIP-6913: SETCODE instruction](./eip-6913) and
-[EIP-7377: Migration Transaction](./eip-7377).
+[EIP-5003: Insert Code into EOAs with AUTHUSURP](https://eips.ethereum.org/EIPS/eip-5003),
+[EIP-6913: SETCODE instruction](https://eips.ethereum.org/EIPS/eip-6913) and
+[EIP-7377: Migration Transaction](https://eips.ethereum.org/EIPS/eip-7377).
 
 ## Backwards Compatibility
 
@@ -808,7 +808,7 @@ The assumption that `tx.origin` is the address that pays for the current transac
 Any code that expects a single top-level execution frame for an Ethereum transaction will have to accommodate
 the new transaction type.
 
-[EIP-3607](./eip-3607) introduces a ban on transactions from senders with deployed code.
+[EIP-3607](https://eips.ethereum.org/EIPS/eip-3607) introduces a ban on transactions from senders with deployed code.
 This limitation does not apply to AA_TX_TYPE transactions.
 
 ### Migration path for existing ERC-4337 projects and further roadmap