Merge branch 'master' into master

.github/workflows/auto-review-trigger.yml

@@ -56,7 +56,7 @@ jobs:
           files: pr-number.txt
 
       - name: Save PR Number
-        uses: actions/upload-artifact@65d862660abb392b8c4a3d1195a2108db131dd05
+        uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08
         if: steps.check_pr_number_exists.outputs.files_exists == 'true'
         with:
           name: pr-number

.github/workflows/ci.yml

@@ -31,7 +31,7 @@ jobs:
           echo $MERGE_SHA > ./pr/merge_sha
 
       - name: Upload PR Number
-        uses: actions/upload-artifact@65d862660abb392b8c4a3d1195a2108db131dd05
+        uses: actions/upload-artifact@65c4c4a1ddee5b72f698fdd19549f0f0fb45cf08
         with:
           name: pr_number
           path: pr/
@@ -42,12 +42,12 @@ jobs:
 
     steps:
       - name: Checkout EIPs
-        uses: actions/checkout@v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
         with:
           repository: ethereum/EIPs
           path: ''
       - name: Checkout ERCs
-        uses: actions/checkout@v4
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
         with:
           repository: ethereum/ERCs
           path: ERCs

ERCS/erc-7627.md

@@ -4,7 +4,8 @@ title: Secure Messaging Protocol
 description: End-to-end encryption for sending messages between users.
 author: Chen Liaoyuan (@chenly) <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/erc-7627-secure-messaging-protocol/18761
-status: Review
+status: Last Call
+last-call-deadline: 2025-02-18
 type: Standards Track
 category: ERC
 created: 2024-02-19

ERCS/erc-7743.md

@@ -4,7 +4,7 @@ title: Multi-Owner Non-Fungible Tokens (MO-NFT)
 description: A new type of non-fungible token that supports multiple owners, allowing shared ownership and transferability among users.
 author: James Savechives (@jamesavechives)
 discussions-to: https://ethereum-magicians.org/t/discussion-on-eip-7743-multi-owner-non-fungible-tokens-mo-nft/20577
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2024-07-13
@@ -20,32 +20,6 @@ Traditional NFTs enforce a single-ownership model, which does not align with the
 
 ## Specification
 
-### Data Structures
-
-- **Owners Mapping**: A mapping from `tokenId` to an enumerable set of owner addresses.
-
-  ```solidity
-  mapping(uint256 => EnumerableSet.AddressSet) internal _owners;
-  ```
-
-- **Balances Mapping**: A mapping from owner addresses to the number of tokens they own.
-
-  ```solidity
-  mapping(address => uint256) private _balances;
-  ```
-
-- **Providers Mapping**: A mapping from `tokenId` to the provider's address.
-
-  ```solidity
-  mapping(uint256 => address) private _providers;
-  ```
-
-- **Transfer Values Mapping**: A mapping from `tokenId` to the `transferValue` fee.
-
-  ```solidity
-  mapping(uint256 => uint256) private _transferValues;
-  ```
-
 ### Token Creation and Ownership Model
 
 1. **Minting**:
@@ -80,32 +54,18 @@ Traditional NFTs enforce a single-ownership model, which does not align with the
 
    - Transferring ownership adds the new owner to the ownership list without removing current owners. This approach reflects the shared nature of digital assets.
 
-2. **Ownership Tracking**:
-
-   - The smart contract tracks the list of owners for each MO-NFT using the `_owners` mapping.
-
-3. **Provider Fee Handling**:
+2. **Provider Fee Handling**:
 
    - During a transfer, the specified `transferValue` fee is transferred to the provider. The contract must have sufficient balance to cover this fee.
 
-4. **Burning Ownership**:
+3. **Burning Ownership**:
 
    - Owners can remove themselves from the ownership list using the `burn` function.
 
      ```solidity
      function burn(uint256 tokenId) external;
      ```
 
-### Value Depreciation
-
-1. **Value Model**:
-
-   - As the number of owners increases, the value of the MO-NFT may decrease to reflect the reduced exclusivity. This is an optional model and can be implemented at the application level.
-
-2. **Depreciation Mechanism**:
-
-   - The value depreciation model can be defined based on the asset type and distribution strategy. This standard does not enforce a specific depreciation mechanism but acknowledges its importance.
-
 ### Interface Definitions
 
 **Minting Functions**
@@ -152,7 +112,7 @@ Traditional NFTs enforce a single-ownership model, which does not align with the
 
 ### [ERC-721](./eip-721.md) Compliance
 
-The MO-NFT standard is designed to be compatible with the [ERC-721](./eip-721.md) standard. It implements required functions such as `balanceOf`, `ownerOf`, and `transferFrom` from the IERC-721 interface.
+The MO-NFT standard is designed to be compatible with the [ERC-721](./eip-721.md) standard. It implements required functions such as `balanceOf`, `ownerOf`, and `transferFrom` from the `ERC721` interface.
 
 - **Approval Functions**: Functions like `approve`, `getApproved`, `setApprovalForAll`, and `isApprovedForAll` are intentionally disabled or overridden, as they do not align with the MO-NFT multi-owner model.
 

ERCS/erc-7750.md

@@ -4,7 +4,7 @@ title: Decentralized Employment System
 description: An employment system that records employment history.
 author: James Savechives (@jamesavechives) <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/erc-7750-decentralized-employment-system-des/20724
-status: Draft
+status: Review
 type: Standards Track
 category: ERC
 created: 2024-08-04
@@ -290,39 +290,161 @@ interface IDecentralizedEmploymentSystem {
 
 ## Test Cases
 
-1. **Company Creation**:
-   - **Input**: A user calls the `registerCompany("TechCorp", "Technology")` function.
-   - **Expected Output**: A new company is registered with a unique `companyId`, and the `companies` mapping is updated with the company's details (name: "TechCorp", industry: "Technology", owner: caller's address).
-
-2. **Employee Token Minting**:
-   - **Input**: The system owner calls `mintEmployeeToken(employeeAddress, "ipfs://metadataURI")`.
-   - **Expected Output**: A new SBT is minted for the employee with a unique `tokenId`, and the `employees` mapping is updated accordingly.
-
-3. **Contract Creation and Execution**:
-   - **Input**:
-     1. A company with `companyId` `1` calls `createContract(1, 5, 1000, 6, "Software Development", "Failure to meet deadlines")`.
-     2. Both the company and the employee sign the contract by calling `executeContract(contractId)`.
-   - **Expected Output**:
-     1. A new labor contract is created with a unique `contractId`, and relevant mappings are updated.
-     2. The contract status is set to "active" upon execution by both parties.
-
-4. **Salary Deposit**:
-   - **Input**: The company calls `depositSalary(contractId)` with a value of `1000 USDC`.
-   - **Expected Output**: The `escrowBalances` mapping is updated to reflect the deposited amount for `contractId`, securing the funds in escrow.
-
-5. **Salary Payment**:
-   - **Input**: After the contract duration, `releaseSalary(contractId)` is called.
-   - **Expected Output**: The escrowed `1000 USDC` is transferred to the employee's address, and the `escrowBalances` mapping for `contractId` is reset to zero.
-
-6. **Employment Termination**:
-   - **Input**: The company calls `terminateContract(contractId, "Failure to meet deadlines")`.
-   - **Expected Output**:
-     1. The contract status is updated to "terminated" in the `contracts` mapping.
-     2. A termination event is emitted, and the company is no longer obligated to continue salary payments.
-
-7. **Dispute Resolution**:
-   - **Input**: Either party calls `raiseDispute(contractId)`, followed by the assigned moderator calling `resolveDispute(contractId, true)` to favor the employee.
-   - **Expected Output**: The escrow funds are transferred to the employee, and the dispute is marked as resolved in the contract's status.
+1. **Company Creation**
+
+   **Input**  
+   - A user calls `registerCompany("TechCorp", "Technology")`.
+
+   **Expected State Changes**  
+   - A new `companyId` is generated (e.g., `companyId = 1`).
+   - The `companies` mapping is updated:
+  ```solidity
+     companies[1]↦{
+      name="TechCorp",
+      industry="Technology",
+      owner=callerAddress,
+      employeeIds=[ ]
+      }
+  ```
+   - An event `CompanyRegistered` is emitted with the arguments `(1, callerAddress, "TechCorp", "Technology")`.
+
+   **Expected Output**  
+   - **Return Value**: `companyId = 1` (the newly created company ID).
+   - **Event**: `CompanyRegistered` is logged.
+
+2. **Employee Token Minting**
+
+   **Input**  
+   - The contract owner (or an authorized address) calls `mintEmployeeToken(employeeAddress, "ipfs://metadataURI")`.
+
+   **Expected State Changes**  
+   - A new token ID is generated (e.g., `tokenId = 5`).
+   - An internal mapping (e.g., `employeeTokenToOwner`) is updated:
+   ```solidity
+      employeeTokenToOwner[5]↦employeeAddress
+   ```
+   - (Optional) If the implementation tracks metadata, another mapping (e.g., `employeeTokenMetadata`) might store:
+   ```solidity
+      employeeTokenMetadata[5]↦"ipfs://metadataURI"
+   ```
+   - An event `EmployeeTokenMinted` is emitted with `(5, employeeAddress)`.
+
+   **Expected Output**  
+   - **Return Value**: `tokenId = 5` (the newly minted employee token ID).
+   - **Event**: `EmployeeTokenMinted` is logged.
+
+3. **Contract Creation and Execution**
+
+   **Input**  
+   1. A company with `companyId = 1` calls:
+   ```solidity
+      createContract(1,5,1000,6,"SoftwareDevelopment","Failuretomeetdeadlines")
+   ```
+   which returns `contractId`.
+   2. Both the company and the employee call `executeContract(contractId)`.
+
+   **Expected State Changes**  
+   - **Contract Creation**:
+     1. A new labor contract ID is generated, e.g., `contractId = 10`.
+     2. The `contracts` mapping is updated:
+     ```solidity
+        contracts[10]↦{
+          companyId=1,
+          employeeTokenId=5,
+          salary=1000,
+          duration=6,
+          responsibilities="SoftwareDevelopment",
+          terminationConditions="Failuretomeetdeadlines",status="Created"
+        }
+     ```
+     3. The system may also update a per-company or per-employee tracking structure (optional but typical):
+     ```solidity
+        companyContracts[1].push(10)
+        employeeContracts[5].push(10)
+     ```
+     4. An event `ContractCreated` is emitted with arguments `(10, 1, 5, 1000, 6)`.
+   - **Contract Execution**:
+     1. Upon calls from both parties, the contract’s status changes from `"Created"` to `"Active"`:
+     ```solidity
+        contracts[10].status↦"Active"
+     ```
+     2. An event `ContractExecuted` is emitted with `(10)` once both signatures/confirmations are received.
+
+   **Expected Output**  
+   - **Return Value** (from `createContract`): `contractId = 10`
+   - **Event**: `ContractCreated(10, 1, 5, 1000, 6)` upon creation.
+   - **Event**: `ContractExecuted(10)` once execution is confirmed by both parties.
+
+4. **Salary Deposit**
+
+   **Input**  
+   - The company (owner of `companyId = 1`) calls `depositSalary(10)` and sends `1000 USDC` (or equivalent in wei for an [ERC-20](./eip-20.md) token or native token) to the contract.
+
+   **Expected State Changes**  
+   1. The contract’s escrow balance mapping is updated:
+   ```solidity
+      escrowBalances[10]↦1000
+   ```
+   2. An event `SalaryDeposited` is emitted with `(10, 1000)`.
+
+   **Expected Output**  
+   - **Event**: `SalaryDeposited(10, 1000)`
+   - The contract’s internal `escrowBalances[10]` should now be `1000`.
+
+5. **Salary Payment**
+
+   **Input**  
+   - After the contract’s duration or satisfaction of any release condition, `releaseSalary(10)` is called (by the contract or the employee).
+
+   **Expected State Changes**  
+   1. The escrow balance for `contractId = 10` is transferred to the employee token owner (`employeeAddress` associated with token ID `5`).
+   2. The `escrowBalances[10]` is set to `0`:
+   ```solidity
+      escrowBalances[10]↦0
+   ```
+   3. An event `SalaryReleased` is emitted with `(10, employeeAddress)`.
+
+   **Expected Output**  
+   - **Event**: `SalaryReleased(10, employeeAddress)`
+   - The updated `escrowBalances[10]` is now `0`.
+   - The employee’s on-chain balance (or token balance if using [ERC-20](./eip-20.md)) increases by `1000`.
+
+6. **Employment Termination**
+
+   **Input**  
+   - The company calls `terminateContract(10, "Failure to meet deadlines")`.
+
+   **Expected State Changes**  
+   1. The `contracts[10].status` is updated to `"Terminated"`:
+   ```solidity
+      contracts[10].status↦"Terminated"
+   ```
+   2. An event `ContractTerminated` is emitted with `(10, "Failure to meet deadlines")`.
+
+   **Expected Output**  
+   - **Event**: `ContractTerminated(10, "Failure to meet deadlines")`
+   - The `contracts[10]` status is now `"Terminated"`.
+   - No further salary obligations exist unless otherwise specified in dispute-resolution processes.
+
+7. **Dispute Resolution**
+
+   **Input**  
+   1. Either party (company or employee) calls `raiseDispute(10)`.
+   2. The assigned moderator calls `resolveDispute(10, true)` indicating the decision favors the employee.
+
+   **Expected State Changes**  
+   - **Dispute Raised**:
+     1. The contract’s dispute status is noted (implementation-specific, but typically `contracts[10].disputeRaised = true`).
+     2. An event `DisputeRaised(10, msg.sender)` is emitted.
+   - **Dispute Resolved**:
+     1. If `decisionForEmployee == true`, any remaining escrow funds for `contractId = 10` are transferred to the employee.
+     2. A `DisputeResolved(10, true)` event is emitted.
+
+   **Expected Output**  
+   - **Event**: `DisputeRaised(10, msg.sender)`
+   - **Event**: `DisputeResolved(10, true)`
+   - If funds remain in escrow, `escrowBalances[10]` is set to `0`, and the employee receives the outstanding balance.
+
 
 ## Security Considerations