Skip to main content

payNoStaker Functions

The payNoStaker functions enable single payments where the transaction executor (msg.sender) is not required to hold staking tokens. This provides a more accessible execution model compared to staking-required payment functions.

A key characteristic of these functions is that the priorityFee parameter is not utilized in non-staker payments, simplifying the transaction structure for users who don't participate in the staking mechanism.

These functions are available in two variants: synchronous (_sync) for sequential transaction ordering and asynchronous (_async) for flexible transaction ordering. For details on nonce types, see Nonce Types in EVVM. For signature details, see Payment Signature Structure.

payNoStaker_sync

Function Type: external
Function Signature: payNoStaker_sync(address,address,string,address,uint256,uint256,address,bytes)
Function Selector: 0x4faa1fa2

Executes a single, synchronous payment without requiring the executor (msg.sender) to hold staking tokens. It uses an implicitly managed synchronous nonce. The executor does not receive the priorityFee or rewards.

Parameters

FieldTypeDescription
fromaddressThe address of the payment sender whose funds are being transferred and whose signature/nonce are validated.
to_addressaddressDirect recipient address. Used when to_identity is empty.
to_identitystringUsername/identity of the recipient. If provided, the contract resolves it to an address via the NameService.
tokenaddressThe token address for the transfer.
amountuint256The quantity of tokens to transfer from from to the recipient.
priorityFeeuint256Additional fee for transaction priority (not used in non-staker payments).
executoraddressAddress authorized to execute this transaction. Use address(0) to allow any address to execute (sender-only restriction removed).
signaturebytesCryptographic signature (EIP-191) from the from address authorizing this payment.
note

There is no explicit nonce parameter; the synchronous nonce is automatically managed and validated as part of the signature verification process.

Execution Methods

The function can be executed in two ways:

Fisher Execution

  1. A user signs the payment details and sends the request (parameters + signature) to a fishing spot.
  2. The fisher (who must hold staking) captures the transaction and validates the request.
  3. The fisher submits the transaction to the function for processing.

Direct Execution

  1. The user or any authorized service directly calls the payNoStaker_sync function.
  2. If an executor address is specified, only that address can submit the transaction.
  3. If executor is set to address(0), anyone can execute the transaction with a valid signature.
tip

When using a service as the executor, we recommend specifying the service's address in the executor parameter for additional security.

Workflow

  1. Signature Verification: Validates the signature against the from address and other parameters using verifyMessageSignedForPay. This includes checking that the synchronous nonce matches the expected next nonce for the from address. Reverts with InvalidSignature on failure.
  2. Executor Validation: If executor is not address(0), checks that msg.sender matches the executor address. Reverts with SenderIsNotTheExecutor if they don't match.
  3. Resolve Recipient Address: Determines the final recipient address:
    • If to_identity is provided (not empty), resolves the identity to an owner address using verifyStrictAndGetOwnerOfIdentity from the NameService contract.
    • If to_identity is empty, uses the provided to_address.
  4. Balance Update: Executes the payment transfer using the _updateBalance function, sending amount of token from the from address to the resolved recipient address. Reverts with UpdateBalanceFailed on transfer failure.
  5. Nonce Increment: Increments the synchronous nonce counter for the from address to prevent replay attacks.
info

For more information about the signature structure, refer to the Payment Signature Structure section.

payNoStaker_sync generic transaction flow


payNoStaker_async

Function Type: external
Function Signature: payNoStaker_async(address,address,string,address,uint256,uint256,uint256,address,bytes)
Function Selector: 0xf4e1895b

Executes a single, asynchronous payment without requiring the executor (msg.sender) to hold staking tokens. Asynchronous execution uses an explicit nonce parameter, allowing for out-of-order processing relative to other async transactions from the same sender. The executor does not receive the priorityFee or rewards.

Parameters

FieldTypeDescription
fromaddressThe address of the payment sender whose funds are being transferred and whose signature/nonce are validated.
to_addressaddressDirect recipient address. Used when to_identity is empty.
to_identitystringUsername/identity of the recipient. If provided, the contract resolves it to an address via the NameService.
tokenaddressThe token address for the transfer.
amountuint256The quantity of tokens to transfer from from to the recipient.
priorityFeeuint256Additional fee for transaction priority (not used in non-staker payments).
nonceuint256Custom nonce value for transaction ordering and replay protection.
executoraddressAddress authorized to execute this transaction. Use address(0) to allow any address to execute (sender-only restriction removed).
signaturebytesCryptographic signature (EIP-191) from the from address authorizing this payment.

Execution Methods

This function can be executed by any address since it doesn't require the executor to hold staking tokens:

Direct Execution

  1. The user or any authorized service directly calls the payNoStaker_async function.
  2. If an executor address is specified, only that address can submit the transaction.
  3. If executor is set to address(0), anyone can execute the transaction with a valid signature.
tip

When using a service as the executor, we recommend specifying the service's address in the executor parameter for additional security.

Workflow

  1. Signature Verification: Validates the signature against the from address and other parameters using verifyMessageSignedForPay. Reverts with InvalidSignature on failure.
  2. Executor Validation: If executor is not address(0), checks that msg.sender matches the executor address. Reverts with SenderIsNotTheExecutor if they don't match.
  3. Async Nonce Verification: Checks if the provided nonce has already been used for the from address by consulting the asyncUsedNonce mapping. Reverts with InvalidAsyncNonce if the nonce has already been used.
  4. Resolve Recipient Address: Determines the final recipient address:
    • If to_identity is provided (not empty), resolves the identity to an owner address using verifyStrictAndGetOwnerOfIdentity from the NameService contract.
    • If to_identity is empty, uses the provided to_address.
  5. Balance Update: Executes the payment transfer using the _updateBalance function, sending amount of token from the from address to the resolved recipient address. Reverts with UpdateBalanceFailed on transfer failure.
  6. Nonce Marking: Marks the specific asynchronous nonce as used (true) for the from address in the asyncUsedNonce mapping to prevent replay attacks.
info

If you want to know more about the signature structure, refer to the Payment Signature Structure section.

payNoStaker_async generic transaction flow