Fix reference

ERCS/erc-7656.md

@@ -1,14 +1,14 @@
 ---
 eip: 7656
 title: Generalized Contract-Linked Services
-description: Define a factory for generic services linked to any contract type including ERC-4337 accounts and NFTs
+description: Define a factory for generic services linked to any contract type, including smart accounts and NFTs
 author: Francesco Sullo (@sullof)
 discussions-to: https://ethereum-magicians.org/t/variation-to-erc6551-to-deploy-any-kind-of-contract-linked-to-an-nft/19223
 status: Review
 type: Standards Track
 category: ERC
 created: 2024-03-15
-requires: 20, 165, 721, 1155, 1167, 4337, 6551
+requires: 20, 165, 721, 1155, 1167, 4337
 ---
 
 ## Abstract
@@ -17,7 +17,7 @@ This proposal defines a factory capable of deploying generic services linked to
 
 ## Motivation
 
-Existing standards like [ERC-6551](./eip-6551.md) successfully bind smart accounts to NFTs, allowing registries to deploy accounts owned by specific token IDs. However, these standards have two key limitations:
+Existing projects, like TokenBound Account, successfully bind smart accounts to NFTs, allowing registries to deploy accounts owned by specific token IDs. However, these standards have two key limitations:
 
 1. They often require deployed contracts to implement specific interfaces for handling assets and executing transactions, effectively mandating that the deployed contract must function as an account.
 2. They are restricted to NFTs, while many other contract types (particularly [ERC-4337](./eip-4337.md) accounts) could benefit from similar linking mechanisms to extend their functionalities.
@@ -30,7 +30,7 @@ This ERC proposes a more versatile factory specification that enables the deploy
 
 - **Non-Invasive Enhancement**: Services can add functionality to existing smart accounts without modifying the underlying contract, maintaining compatibility with infrastructure like wallets and indexers.
 
-- **Backward Compatibility**: Maintains compatibility with existing token-bound account standards (ERC-6551) while extending functionality to new use cases.
+- **Backward Compatibility**: Maintains compatibility with existing token-bound account standards while extending functionality to new use cases.
 
 - **Flexible Implementation**: The `mode` parameter enables different linkage types (with or without token IDs) while ensuring consistent deterministic addressing.
 
@@ -116,7 +116,7 @@ bytes12 constant NO_LINKED_ID = 0x000000000000000000000001;
 bytes12 constant LINKED_ID = 0x000000000000000000000000;
 ```
 
-- **LINKED_ID Mode (0x000000000000000000000000)**: Used when linking a service to an NFT or any contract that requires a token/entity ID. This mode ensures compatibility with [ERC-6551](./eip-6551.md), allowing seamless integration with existing token-bound account systems.
+- **LINKED_ID Mode (0x000000000000000000000000)**: Used when linking a service to an NFT or any contract that requires a token/entity ID. This mode ensures compatibility with existing token-bound account systems.
 
 - **NO_LINKED_ID Mode (0x000000000000000000000001)**: Used when linking a service to a contract that doesn't require an ID parameter, such as an [ERC-4337](./eip-4337.md) account. In this case, the `linkedId` parameter is still present in the interface for consistency but SHOULD be set to zero if not used to store alternative data relevant to the service.
 
@@ -139,6 +139,8 @@ ERC-1167 Footer               (15 bytes)
 <linkedId (uint256)>          (32 bytes)
 ```
 
+**Total bytecode size: 183 bytes**
+
 Linked services SHOULD implement the `IERC7656Service` interface:
 
 ```solidity
@@ -174,31 +176,29 @@ The `mode` parameter uses 12 bytes instead of a simple boolean flag because the
 
 ### Deterministic Addressing
 
-[ERC-7656](./eip-7656.md) follows the deterministic addressing pattern established by [ERC-6551](./eip-6551.md), appending immutable data to the contract bytecode rather than storing it in contract storage. This ensures that:
+[ERC-7656](./eip-7656.md) follows a deterministic addressing pattern, appending immutable data to the contract bytecode rather than storing it in contract storage. This ensures that:
 
 1. Linked services have predictable addresses that can be computed off-chain
 2. The factory remains stateless, reducing gas costs
 3. Linked services can be deployed on-demand or even referenced before deployment
 
-### Compatibility with [ERC-6551](./eip-6551.md)
-
-The `LINKED_ID` mode (0x000000000000000000000000) maintains byte-for-byte compatibility with [ERC-6551](./eip-6551.md) token bound accounts. This intentional design ensures that applications built for [ERC-6551](./eip-6551.md) can work seamlessly with [ERC-7656](./eip-7656.md) services in this mode without requiring any modifications.
-
 ### Generic Linking Mechanism
 
 Unlike standards that enforce specific interfaces or behaviors on linked contracts, [ERC-7656](./eip-7656.md) remains agnostic about the implementation details of linked services. This deliberate design choice allows developers maximum flexibility to create specialized services while maintaining a consistent deployment and ownership model.
 
 
 ## Backwards Compatibility
 
-[ERC-7656](./eip-7656.md) maintains compatibility with [ERC-6551](./eip-6551.md) when used with the `LINKED_ID` mode (0x000000000000000000000000). This ensures that existing applications and infrastructure supporting token-bound accounts can continue operating without modification.
+[ERC-7656](./eip-7656.md) maintains compatibility with token bound accounts when used with the `LINKED_ID` mode (0x000000000000000000000000). This ensures that existing applications and infrastructure supporting token-bound accounts can continue operating without modification.
 
 For contracts using the `NO_LINKED_ID` mode (0x000000000000000000000001), specialized interfaces may be required, but the core factory mechanism remains consistent.
 
 
 ## Reference Implementation
 
-See [`ERC7656Factory.sol`](../assets/eip-7656/ERC7656Factory.sol) for an example implementation of `IERC7656Factory`. For convenience, the reference implementation will be deployed at `erc7656.eth` on primary mainnets and selected testnets.
+See [`ERC7656Factory.sol`](../assets/eip-7656/ERC7656Factory.sol) for an example implementation of `IERC7656Factory`. 
+
+For convenience, the bytecode of the reference implementation has been deployed at `0x76565d90eeB1ce12D05d55D142510dBA634a128F` on Ethereum mainnet, and will be later deployed at the same address to all primary mainnets and selected testnets.
 
 An example of implementation of `IERC7656Service`:
 

ERCS/erc-7786.md

@@ -4,7 +4,8 @@ title: Cross-Chain Messaging Gateway
 description: An interface for contracts to send and receive cross-chain messages containing arbitrary data.
 author: Francisco Giordano (@frangio), Hadrien Croubois (@Amxx), Ernesto Garcia (@ernestognw), CJ Cobb (@cjcobb23), Sergey Gorbunov (@sergeynog), joxes (@Joxess)
 discussions-to: https://ethereum-magicians.org/t/erc-7786-cross-chain-messaging-gateway/21374
-status: Draft
+status: Last Call
+last-call-deadline: 2025-08-31
 type: Standards Track
 category: ERC
 created: 2024-10-14

ERCS/erc-7955.md

@@ -242,7 +242,7 @@ The `CREATE2_FACTORY_RUNTIME_CODE` corresponds to the following assembly:
 # CREATE2 reverted, propagate the revert data.
                         # Stack: [address = 0; 0; 32]
 0x0013: RETURNDATASIZE  # Stack: [r.len; 0; 0; 32]              | Push the revert data length onto the stack
-0x0014: DUP1            # Stack: [0; r.len; 0; 0; 32]           | Push 0 on to the stack by duplicating; note that
+0x0014: DUP2            # Stack: [0; r.len; 0; 0; 32]           | Push 0 on to the stack by duplicating; note that
                                                                 # `PUSH0` is intentionally do not used for increased
                                                                 # compatibility with chains that do not implement that
                                                                 # specific opcode

_layouts/eip.html

@@ -84,7 +84,7 @@ <h3>{{ page.description | xml_escape }}</h3>
       {% if page.status != "Review" and page.status != "Last Call" and page.status != "Final" and page.discussions-to != undefined %}
         <tr>
           <th scope="row">Discussion Link</th>
-          <td><a href="{{ page.discussions-to | uri_escape }}" target="__blank">{{ page.discussions-to | xml_escape }}</a></td>
+          <td><a href="{{ page.discussions-to | uri_escape }}" target="_blank" rel="noopener">{{ page.discussions-to | xml_escape }}</a></td>
         </tr>
       {% endif %}
       {% if page.requires != undefined %}
@@ -101,7 +101,7 @@ <h3>{{ page.description | xml_escape }}</h3>
     <div class="alert alert-primary d-flex align-items-center" role="alert">
       <svg class="bi flex-shrink-0 me-2" role="img" aria-label="Info:" style="width:2.5em;height:2.5em;"><use xlink:href="#bi-megaphone-fill"/></svg>
       <div class="text-center w-100">
-        <a href="{{ page.discussions-to | uri_escape }}" target="__blank">This EIP is in the process of being peer-reviewed. If you are interested in this EIP, please participate using this discussion link.</a>
+        <a href="{{ page.discussions-to | uri_escape }}" target="_blank" rel="noopener">This EIP is in the process of being peer-reviewed. If you are interested in this EIP, please participate using this discussion link.</a>
       </div>
     </div>
   {% endif %}