Update ERC-7656: Update naming for clarity

Merged by EIP-Bot.

ERCS/erc-7656.md

@@ -1,7 +1,7 @@
 ---
 eip: 7656
-title: Generalized Token-Linked Contracts
-description: Define a registry for generic contracts linked to a specific NFT
+title: Generalized Token-Linked Services
+description: Define a registry for generic services linked to a specific NFT
 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: Draft
@@ -13,15 +13,15 @@ requires: 165, 1167, 5313, 6551
 
 ## Abstract
 
-This proposal introduces a variation of [ERC-6551](./eip-6551.md) that extends to all types of contracts linked to non-fungible tokens (NFTs), i.e., contracts owned by a single NFT and thus by the owner of the NFT. It achieves this goal using generic language for functions, errors, and events, and avoids conflicting with the strict restrictions imposed by the original proposal.
+This proposal introduces a variation of [ERC-6551](./eip-6551.md) that extends to all types of services linked to non-fungible tokens (NFTs), i.e., contracts extending an NFT, owned by a single NFT and thus by the owner of the NFT. It achieves this goal using generic language for functions, errors, and events, and avoids conflicting with the strict restrictions imposed by the original proposal.
 
 ## Motivation
 
 [ERC-6551](./eip-6551.md) aims to bind smart accounts to tokens, allowing its registry to deploy accounts owned by a specific tokenID. The issue we attempt to address with this new proposal is that [ERC-6551](./eip-6551.md) explicitly requires any contract deployed via the `ERC6551Registry` to implement `IERC6551Account` and `IERC6551Execute`, i.e., it must be an account. This requirement is underscored by the choices for the names of functions and events in the interface. Additionally, [ERC-6551](./eip-6551.md) specifies that the `ERC6551Registry` smart contract is deployed as a singleton at a specific address on any chain. Due to this centralization of services, projects building on it are prone to consider any contract deployed via that registry that is not an account as spam or invalid.
 
-With this new ERC, we propose a more generic registry that uses generic function/event names to allow the deployment of any kind of contract that makes sense when associated with an NFT, so that the contract is under the full control of the NFT's owner. Since one of this proposal's goals is flexibility, there is no expectation for an `ERC7656Registry` contract to be deployed as a singleton, allowing any project to adjust it to their needs. Consequently, we require that any registry explicitly supports the `IERC7656Registry` interface.
+With this new ERC, we propose a more generic registry that uses generic function/event names to allow the deployment of any kind of contract that makes sense when associated with an NFT, so that the contract is under the full control of the NFT's owner. In comparison with [ERC-6551](./eip-6551.md), since one of this proposal's goals is flexibility, there is no expectation for an `ERC7656Registry` contract to be deployed as a singleton, allowing any project to adjust it to their needs; consequently, we require that any registry explicitly supports the `IERC7656Registry` interface.
 
-The expansion of the registry's capabilities to manage contracts beyond accounts provides several advantages:
+The expansion of the registry's capabilities to manage contracts implementing any kind of service beyond accounts provides several advantages:
 
 - **Flexibility**: Developers can allow NFTs to interact with a broader range of linked contracts, unlocking new use cases and functionalities (lending systems, vested asset distribution, fractional ownership, identity, etc.)
 - **Compatibility**: By ensuring that account-like contracts can still be identified as such, the proposal maintains backward compatibility with [ERC-6551](./eip-6551.md).
@@ -113,10 +113,14 @@ ERC-1167 Footer               (15 bytes)
 <tokenId (uint256)>           (32 bytes)
 ```
 
-Any contract created using a `ERC7656Registry` SHOULD implement the `IERC7656Contract` interface:
+Any contract created using a `ERC7656Registry` SHOULD implement the `IERC7656Service` interface:
 
 ```solidity
+<<<<<<< HEAD
+interface IERC7656Service {
+=======
 interface IERC7656Linked {
+>>>>>>> master
   /**
   * @notice Returns the token linked to the contract
   * @return chainId The chainId of the token
@@ -263,10 +267,10 @@ contract ERC7656Registry is IERC7656Registry {
 }
 ```
 
-A simple implementation of `IERC7656Linked`:
+An example of implementation of `IERC7656Service`:
 
 ```solidity
-contract LinkedContract is IERC7656Linked, EIP5313 {
+contract LinkedService is IERC7656Service, EIP5313 {
 
   function token() public view virtual returns (uint256, address, uint256) {
     bytes memory footer = new bytes(0x60);