Skip to main content

Withdrawal Functions (No Mate Staking)

This section provides information about functions within the EVVM contract designed for withdrawing tokens to an external network without requiring the transaction executor (msg.sender) to be an sMATE staker. Consequently, the executor does not receive MATE rewards or the specified priority fee for processing these withdrawals.

These functions facilitate transferring tokens held within the EVVM system's internal balances to a recipient address on another blockchain network, utilizing integrated bridging solutions (like Axelar, CCIP, Hyperlane, LayerZero).

The functions are divided based on nonce type: withdrawalNoMateStaking_sync (using the synchronous nonce mechanism) and withdrawalNoMateStaking_async.

Nonce Types

For more details on synchronous and asynchronous nonces within the EVVM contract, refer to the Nonce Types section.

withdrawalNoMateStaking_sync

Function Type: external
Function Signature: withdrawalNoMateStaking_sync(address,address,address,uint256,uint256,bytes,uint8,bytes)
Function Selector: ``

Initiates a synchronous withdrawal of tokens for a user (from) to an external network address (addressToReceive) via a specified bridging solution. This version uses the synchronous nonce system for the from user and does not provide MATE rewards or the specified priorityFee to the transaction executor (msg.sender).

Parameters

Parameter NameTypeDescription
fromaddressThe address of the user whose funds (internal EVVM balance) are being withdrawn.
addressToReceiveaddressThe destination address on the external network where the tokens should be received.
tokenaddressThe contract address of the token being withdrawn.
amountuint256The quantity of token to withdraw and bridge.
priorityFeeuint256A fee specified by the from user. Note: In this NoMateStaking function, this fee is not paid to the executor (msg.sender).
signaturebytesThe EIP-191 signature from the from user authorizing this specific withdrawal action (signing details like recipient, token, amount, fee, bridge solution, and sync nonce).
_solutionIduint8Identifier for the bridging solution to use: 1=Axelar, 2=CCIP, 3=Hyperlane, 4=LayerZero.
_optionsbytesBridge-specific parameters encoded as bytes (for LayerZero execution only).
Signature Structure Reference

For details on how the signature is constructed, refer to the Withdrawal Signature Structure section. Ensure the synchronous identifier (52896a1f) is used.

Execution Methods

This function can be executed by any address (msg.sender), regardless of sMATE staking status.

Fisher Execution

When the executor is the fisher:

  1. The user sends the payment request to the fishing spot
  2. The fisher captures the transaction and validates all parameters
  3. The fisher submits the transaction to the contract for processing

Direct Execution

When the executor is the user or a service:

  1. The user/service submits their transaction directly to the contract

Workflow

Failure at validation steps typically reverts the transaction. The steps execute in the specified order.

  1. Signature and Nonce Verification: Verifies the signature provided by the from user using an internal function ( verifyMessageSignedForWithdrawal). This process validates the signature against the expected withdrawal data and implicitly checks that the user's current synchronous nonce (nextSyncUsedNonce[from]) matches the nonce covered by the signature. Reverts if the signature is invalid or the nonce does not match.
  2. Token Verification: Verifies that the token address provided is not the address of the native MATE token. Reverts if attempting to withdraw the native token via this method.
  3. Balance Verification: Verifies that the internal EVVM balance of the from address for the specified token is sufficient to cover the amount. Reverts if the balance is insufficient.
  4. Limit Verification: Checks the withdrawal amount against predefined limits for the from user:
    • If the token is ETH (or WETH representing native ETH), verifies the amount does not exceed a specific limit (1 ETH). Reverts if the ETH limit is exceeded.
    • If the token is an ERC20 token, uses an oracle or DEX pool ( UniswapV3 via estimateAmountUsingUniswapV3Pool) to estimate the amount's value in ETH and verifies this value does not exceed the general withdrawal limit (maxAmountToWithdraw.actual). Reverts if the value limit is exceeded.
  5. Reducing User Balance: Reduces the from user's internal EVVM balance for the specified token.
  6. Message Construction: Constructs the data payload for the cross-chain message using abi.encode. The encoded parameters are:
    • Recipient: Uses addressToReceive if it's not address(0), otherwise defaults to the from address.
    • Token: The token address being withdrawn.
    • Amount: The amount being withdrawn.
    bytes memory messagePayload = abi.encode(
    (addressToReceive == address(0) ? from : addressToReceive),
    token,
    amount
    );
  7. Calling the Bridging Solution: Calls the internal makeCallCrossChain function, providing the _solutionId and necessary parameters (like addressToReceive, token, amount, _options). This initiates the cross-chain message/transfer via the selected bridge provider. Reverts if the makeCallCrossChain function itself fails.

withdrawalNoMateStaking_sync__Fisher withdrawalNoMateStaking_sync__Direct


withdrawalNoMateStaking_async

Function Type: external
Function Signature: withdrawalNoMateStaking_sync(address,address,address,uint256,uint256,bytes,uint8,bytes)
Function Selector: ``

Initiates a synchronous withdrawal of tokens for a user (from) to an external network address (addressToReceive) via a specified bridging solution. This version uses the asynchronous nonce system (requiring an explicit nonce parameter) for the from user and does not provide MATE rewards or the specified priorityFee to the transaction executor (msg.sender).

Parameters

Parameter NameTypeDescription
fromaddressThe address of the user whose funds (internal EVVM balance) are being withdrawn.
addressToReceiveaddressThe destination address on the external network where the tokens should be received.
tokenaddressThe contract address of the token being withdrawn.
amountuint256The quantity of token to withdraw and bridge.
priorityFeeuint256A fee specified by the from user. Note: In this NoMateStaking function, this fee is not paid to the executor (msg.sender).
nonceuint256The specific asynchronous nonce provided by the from user for this transaction's replay protection. Must be unique and unused for this user's async transactions.
signaturebytesThe EIP-191 signature from the from user authorizing this specific withdrawal action (signing details like recipient, token, amount, fee, bridge solution, and sync nonce).
_solutionIduint8Identifier for the bridging solution to use: 1=Axelar, 2=CCIP, 3=Hyperlane, 4=LayerZero.
_optionsbytesBridge-specific parameters encoded as bytes (for LayerZero execution only).

Execution Methods

This function can be executed by any address (msg.sender), regardless of sMATE staking status.

Fisher Execution

When the executor is the fisher:

  1. The user sends the payment request to the fishing spot
  2. The fisher captures the transaction and validates all parameters
  3. The fisher submits the transaction to the contract for processing

Direct Execution

When the executor is the user or a service:

  1. The user/service submits their transaction directly to the contract

Workflow

Failure at validation steps typically reverts the transaction. The steps execute in the specified order.

  1. Signature Verification: Verifies the signature provided by the from user using an internal function ( verifyMessageSignedForWithdrawal). Reverts if the signature is invalid.
  2. Nonce Verification: Verifies that the explicit nonce provided in the parameters has not already been used by the from address by checking the asyncUsedNonce[from][nonce] mapping. Reverts if the nonce has already been marked as used.
  3. Token Verification: Verifies that the token address provided is not the address of the native MATE token. Reverts if attempting to withdraw the native token via this method.
  4. Balance Verification: Verifies that the internal EVVM balance of the from address for the specified token is sufficient to cover the amount. Reverts if the balance is insufficient.
  5. Limit Verification: Checks the withdrawal amount against predefined limits for the from user:
    • If the token is ETH (or WETH representing native ETH), verifies the amount does not exceed a specific limit (1 ETH). Reverts if the ETH limit is exceeded.
    • If the token is an ERC20 token, uses an oracle or DEX pool ( UniswapV3 via estimateAmountUsingUniswapV3Pool) to estimate the amount's value in ETH and verifies this value does not exceed the general withdrawal limit (maxAmountToWithdraw.actual). Reverts if the value limit is exceeded.
  6. Reducing User Balance: Reduces the from user's internal EVVM balance for the specified token.
  7. Message Construction: Constructs the data payload for the cross-chain message using abi.encode. The encoded parameters are:
    • Recipient: Uses addressToReceive if it's not address(0), otherwise defaults to the from address.
    • Token: The token address being withdrawn.
    • Amount: The amount being withdrawn.
    bytes memory messagePayload = abi.encode(
    (addressToReceive == address(0) ? from : addressToReceive),
    token,
    amount
    );
  8. Calling the Bridging Solution: Calls the internal makeCallCrossChain function, providing the _solutionId and necessary parameters (like addressToReceive, token, amount, _options). This initiates the cross-chain message/transfer via the selected bridge provider. Reverts if the makeCallCrossChain function itself fails.

withdrawalNoMateStaking_async__Fisher withdrawalNoMateStaking_async__Direct