Rate limiter

The following arguments are settings for the rate limiter (spam prevention). The client accumulates one "operation point" every rate_limit_recovery_time milliseconds, up to rate_limit_max_points. You spend one operation point for each authenticated operation.

You can configure this with module args for the lib.ft4.core.accounts module like this:

blockchains:
  my_rell_dapp:
    module: main
    moduleArgs:
      lib.ft4.core.accounts:
        rate_limit:
          max_points: 10
          recovery_time: 5000
          points_at_account_creation: 1

Argument	Description	Default value
max_points	is the maximum number of operation points that can accumulate (and, therefore, the maximum number of transactions you can do at once).	10
recovery_time	(Milliseconds) is the cooling period before an account can receive one operation point.	5000
points_at_account_creation	The points that an account has at the moment of its creation (0 is min).	1

Disable rate limiting like this:

blockchains:
  my_rell_dapp:
    module: main
    moduleArgs:
      lib.ft4.core.accounts:
        rate_limit:
          active: 0

You can override rate limit configuration for specific accounts (including completely deactivating it) by extending the account_rate_limit_config(account): rate_limit_config? function in the lib.ft4.core.accounts module. Return null to use the standard rate limit configuration. For example:

import lib.ft4.core.accounts;

entity admin_account {
    key accounts.account;
}

@extend(accounts.account_rate_limit_config) function(accounts.account) =
    if (exists(admin_account @? { account }))
        accounts.rate_limit_config(active = false)
    else
        null;

Transaction prioritization

By importing the lib.ft4.core.prioritization.default module, you can enable transaction prioritization so that the rate-limiting rules are applied to transactions in the transaction queue, which will have the following effects:

• Accounts with more points will get higher priority for their transactions.
• Accounts with disabled rate limiting will get the highest priority for all their transactions.
• Transactions that the rate limiter would have rejected will be rejected immediately upon submission.
• If the queue becomes full, transactions can be removed from the queue to make room for transactions with higher priority.

You can customize this behavior by importing lib.ft4.core.prioritization instead of lib.ft4.core.prioritization.default and extending the function priority_check(tx_body: gtx_transaction_body, tx_size: integer, tx_enter_timestamp: timestamp, current_timestamp: timestamp): priority_state_v1?.

import lib.ft4.core.prioritization.*;

@extend(priority_check) function(tx_body: gtx_transaction_body, tx_size: integer, tx_enter_timestamp: timestamp, current_timestamp: timestamp): priority_state_v1 {
    // custom logic here

    return no_op_priority_state();
}

The exact details of how to implement this function are beyond the scope of this documentation. Use the default implementation as a starting point.