Skip to main content

Introduction

Important Notice About Implementation Location

The single payment functions documented in this section are currently implemented in src/contracts/evvm/EvvmLegacy.sol instead of the main Evvm.sol contract.

Legacy Implementation

This contract includes multiple pay functions, which, although gas efficient, can be complex in code. If you prefer your EVVM to have multiple pay functions, please change the name of the document from EvvmLegacy.sol to Evvm.sol and verify that the services have something similar to this instead of pay.

Background

The EVVM ecosystem provides two approaches for implementing payment functionality:

  1. Simplified Approach (Current Default): Uses a single, unified pay function that handles all payment scenarios through internal logic branching.

  2. Legacy Approach (Multiple Functions): Uses separate, specialized functions for different payment types (payNoStaker_sync, payNoStaker_async, payStaker_sync, payStaker_async).

When to Use Legacy Functions

Consider using the legacy implementation if:

  • Gas Optimization is Critical: The specialized functions can be more gas-efficient for specific use cases since they avoid conditional logic.
  • Clear Function Separation: Your application benefits from having distinct function signatures for different payment types.
  • Integration Requirements: Your existing services are designed to work with multiple specific payment functions.

Migration Process

To use these legacy functions in your EVVM deployment:

  1. Rename the File: Change EvvmLegacy.sol to Evvm.sol in your contract structure.
  2. Update Service Integration: Ensure your services are configured to use the specific function names instead of the generic pay function.
  3. Test Thoroughly: Verify that all payment scenarios work correctly with the specialized functions.
  4. Update Documentation: Make sure your service documentation reflects the use of multiple payment functions.

Function Overview

The legacy implementation provides four main payment functions:

  • payNoStaker_sync: Synchronous payments for non-stakers
  • payNoStaker_async: Asynchronous payments for non-stakers
  • payStaker_sync: Synchronous payments for stakers with rewards
  • payStaker_async: Asynchronous payments for stakers with rewards

Each function is optimized for its specific use case, providing potentially better gas efficiency at the cost of increased code complexity.


The following documentation covers each of these specialized payment functions in detail.