Transaction Options

This section consolidates the settings that determine how transactions are formed and executed.

---

TRANSACTION.COMPUTE_UNIT_LIMIT

Description: Defines the maximum number of Compute Units (CU)that a transaction can use.

Currently it's possible to specify a static value. In the future modes for automatic, dynamic value setting will be added, calculated from conditions for each transaction.

• DEFAULT — the base compute unit limit (in Compute Units). Typical ranges:

  • 500,000 – 700,000 CU — standard transactions

  • A too low value may lead to the error ComputeBudgetExceeded.

• DLMM_MAX_BINS — the maximum number of binsthat a DLMM pool can process in a single transaction.

  • The larger the value, the more CU the transaction may consume

Example:

# Computational budget limits for transaction execution.
# Future: automatic CU limit management mode for each transaction will be added
[TRANSACTION.COMPUTE_UNIT_LIMIT]
# Base CU limit (500k-700k typical, up to 1.4M)
DEFAULT = 500000
# Max bins to traverse (~10-15k CUs per bin, recommend 5-10)
DLMM_MAX_BINS = 5

Notes:

• The value affects the transaction's cost and its priority. The lower the COMPUTE_UNIT_LIMIT, the lower the transaction cost and the higher its priority.

---

TRANSACTION.COMPUTE_UNIT_PRICE

Description: Defines the price per Compute Unit in micro-lamports (1 lamport = 10⁶ micro-lamports). This parameter directly affects priority fee — the higher the price, the higher the chance of the transaction being included in the next slot.

Options:

• DEFAULT — the default value (in micro-lamports).

Only the "DEFAULT"mode is available at the moment, which uses the user-specified value. (dynamic modes will be added in the future, for example, ADAPTIVE and MARKET_BASED and others)

Example:

# Priority fees for validator transaction inclusion
[TRANSACTION.COMPUTE_UNIT_PRICE]
# Priority fee in micro-lamports per CU.
# Future: dynamic strategies based on network conditions will be added
DEFAULT = 1310101

---

TRANSACTION.LENDING

Description: Defines the use of flash loans within arbitrage transactions. Allows using liquidity from lending protocols to increase deal size without needing to hold a large balance in the wallet.

Options:

• ENABLED — enables or disables the use of flash loans.

• PROGRAM — the identifier of the lending service (for example, "KAMINO").

• AMOUNT — the borrow amount in lamports.

Example:

# Flash loan configuration for atomic borrow-arbitrage-repay execution
[TRANSACTION.LENDING]
# Enable flash loans in transaction
ENABLED = true
# Lending protocol.
# Currently: KAMINO
# Future: JUP LEND and other protocols
PROGRAM = "KAMINO"
# Flash loan amount in SOL (value automatically converted to lamports)
AMOUNT = 500

Notes:

• Flash loans solve the problem of insufficient liquidity in arbitrage.

• Using flash loans increases Compute Units the transaction's.

• In the future it is planned to add support for other lending services and descriptions of their terms (fee, gas cost, etc.).