ERC-7750 - Decentralized Employment System

Created 2024-08-04
Status Review
Category ERC
Type Standards Track
Authors

An employment system that records employment history.

Abstract

This ERC proposes a Decentralized Employment System (DES) built on the Ethereum blockchain. The DES facilitates the creation and management of companies, records comprehensive employment histories through unique employee tokens, enables the formation and execution of labor contracts, automates salary payments via an escrow mechanism, incorporates a robust moderation system for dispute resolution, and implements a reputation-based review system for both employers and employees. By leveraging blockchain's transparency and immutability, the DES ensures accountability and trust throughout the employment lifecycle, from company creation and hiring to contract fulfillment and termination.

The system operates post employee testing and prior to the final hiring and contract signing. Employees possess a Soulbound Token (SBT) representing their employment history, which companies review before finalizing labor contracts. This token-based approach ensures a secure and verifiable employment record that enhances the hiring process's integrity.

Motivation

Traditional employment systems are centralized, opaque, and often lack trust. The DES aims to introduce transparency, immutability, and trust into the employment process by leveraging blockchain technology. By recording employment history on-chain, enabling decentralized company creation, automating contract enforcement, and providing mechanisms for dispute resolution, the DES promotes a fairer and more transparent employment ecosystem. Additionally, the system streamlines the hiring process by securely managing employment records and automating contractual obligations.

Specification

Solidity Interface

To provide a clear and standardized way for developers to interact with the DES, the following Solidity interface outlines the primary functions and events of the system:

pragma solidity ^0.8.0;

/// @title Decentralized Employment System Interface
interface IDecentralizedEmploymentSystem {

    // Events
    event CompanyRegistered(uint companyId, address owner, string name, string industry);
    event EmployeeTokenMinted(uint tokenId, address employee);
    event ContractCreated(uint contractId, uint companyId, uint employeeTokenId, uint salary, uint duration);
    event ContractExecuted(uint contractId);
    event SalaryDeposited(uint contractId, uint amount);
    event SalaryReleased(uint contractId, address employee);
    event DisputeRaised(uint contractId, address raisedBy);
    event DisputeResolved(uint contractId, bool decisionForEmployee);
    event ContractTerminated(uint contractId, string reason);
    event ReviewSubmitted(uint contractId, uint rating, string comments);

    // Company Management
    function registerCompany(string calldata name, string calldata industry) external returns (uint companyId);
    function getCompany(uint companyId) external view returns (string memory name, string memory industry, address owner, uint[] memory employeeIds);

    // Employee Management
    function mintEmployeeToken(address employee, string calldata metadataURI) external returns (uint tokenId);
    function getEmploymentHistory(uint employeeTokenId) external view returns (uint[] memory contractIds);

    // Labor Contracts
    function createContract(uint companyId, uint employeeTokenId, uint salary, uint duration, string calldata responsibilities, string calldata terminationConditions) external returns (uint contractId);
    function executeContract(uint contractId) external;

    // Payment System
    function depositSalary(uint contractId) external payable;
    function releaseSalary(uint contractId) external;

    // Dispute Resolution
    function raiseDispute(uint contractId) external;
    function resolveDispute(uint contractId, bool decisionForEmployee) external;

    // Contract Termination
    function terminateContract(uint contractId, string calldata reason) external;

    // Review System
    function submitReview(uint contractId, uint rating, string calldata comments) external;
    function getReviews(uint contractId) external view returns (Review[] memory);

    // Structures
    struct Review {
        uint rating;
        string comments;
        address reviewer;
    }
}

Detailed Function Specifications

1. Company Management

a. Company Registration

b. Retrieve Company Profile

2. Employee Management

a. Employee Tokenization

b. Retrieve Employment History

3. Labor Contracts

a. Contract Creation

b. Contract Execution

4. Payment System

a. Salary Deposits

b. Automated Payments

5. Dispute Resolution

a. Dispute Initiation

b. Dispute Resolution

6. Contract Termination

a. Termination Conditions

7. Review System

a. Submit Review

b. Retrieve Reviews

Employment History

  1. Immutable Records: Employment history is maintained as an array of contract IDs linked to each employee's Soulbound Token (SBT). This ensures that all employment records are permanently and immutably stored on the blockchain.

  2. Public Accessibility: Employment history data is publicly accessible through the getEmploymentHistory function, allowing companies to verify an employee's past engagements before finalizing contracts.

Payment System

  1. Salary Deposits: Companies deposit salaries into an escrow managed by the smart contract by calling depositSalary. The contract ensures that funds are securely held until payment conditions are satisfied.

  2. Automated Payments: Salaries are released automatically or upon triggering the releaseSalary function, ensuring timely and condition-based payments to employees.

Moderation and Dispute Resolution

  1. Dispute Initiation and Resolution: Either party can raise disputes, which are then resolved by assigned moderators. Moderators act as impartial arbitrators to ensure fair outcomes based on contract terms and evidence provided.

Firing Employees

  1. Termination Conditions: Companies can terminate contracts based on predefined conditions, with the option for dispute resolution if termination is contested.

Review System

  1. Reputation Scores: Reviews contribute to the reputation scores of both companies and employees, fostering accountability and encouraging positive behavior within the ecosystem.

Rationale

  1. Employee Tokenization:

  2. Utilizing Soulbound Tokens (SBTs) to represent employees ensures that each employee has a unique, non-transferable identity on the blockchain. This design choice enhances the integrity of employment records, making them tamper-proof and verifiable. It also allows companies to access a comprehensive employment history before finalizing contracts, promoting transparency.

  3. Escrow System for Salary Payments:

  4. Implementing an escrow mechanism secures salary payments, ensuring that funds are only released when contractual obligations are met. This system protects both employees and companies by guaranteeing that salaries are available and that payments are contingent on contract fulfillment.

  5. Moderation and Dispute Resolution:

  6. Incorporating a moderation system allows for the resolution of disputes that cannot be automatically enforced by smart contracts. Moderators provide necessary human oversight in complex employment matters, ensuring fair and just outcomes.

  7. Public Employment History:

  8. Making employment history publicly accessible fosters trust and accountability. It allows potential employers to verify past employment and credentials, reducing the risk of fraud and enhancing the credibility of employees within the ecosystem.

  9. Review System:

  10. A reputation-based review system encourages positive interactions and behaviors among users. By allowing both companies and employees to submit reviews, the system promotes mutual accountability and helps build reliable reputations.

Test Cases

  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.

  1. 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.

  1. 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.

  1. Salary Deposit

Input
- The company (owner of companyId = 1) calls depositSalary(10) and sends 1000 USDC (or equivalent in wei for an ERC-20 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.

  1. 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) increases by 1000.

  1. 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.

  1. 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

  1. Contract Integrity: Ensure that all labor contracts are immutable and cannot be tampered with once created and executed.

  2. Fund Security: Salaries are securely held in escrow, and only released based on predefined conditions to prevent unauthorized access or misuse.

  3. Moderator Trust: Implement a decentralized and transparent system for selecting and monitoring moderators to maintain impartiality and trust in dispute resolutions.

  4. Review System: Incorporate safeguards against fraudulent reviews, such as verifying the association of reviews with legitimate contract completions, to maintain accurate and trustworthy reputation scores.

  5. Token Security: Use Soulbound Tokens (SBTs) for employee representation to prevent token transfers and ensure that employment records are securely tied to the respective individuals.

Copyright

Copyright and related rights waived via CC0.