Skip to main content
This page covers the settings that control how Blnk executes, batches, and locks transactions. For queue names, sharding, retries, and hot-lane routing, see Queue configuration.

​
Transaction settings

Use these settings to control transaction batching, worker behavior, and queued validation. 
BLNK_TRANSACTION_MAX_QUEUE_SIZE=1000
BLNK_TRANSACTION_MAX_WORKERS=10
BLNK_TRANSACTION_INDEX_QUEUE_PREFIX=transactions
BLNK_TRANSACTION_ENABLE_QUEUED_CHECKS=false
DescriptionDefault
BLNK_TRANSACTION_MAX_QUEUE_SIZEIn-memory channel buffer size for the batch worker used by ProcessTransactionInBatches (not a Redis queue depth limit).1000
BLNK_TRANSACTION_MAX_WORKERSConcurrency for batch and reconciliation transaction workers. For the main Redis-backed queued transaction pool, use BLNK_QUEUE_TRANSACTION_WORKER_CONCURRENCY and hot-lane settings instead.10
BLNK_TRANSACTION_INDEX_QUEUE_PREFIXCollection / index name prefix for transaction search documents (e.g. Typesense), not a Redis transaction queue name.transactions
BLNK_TRANSACTION_ENABLE_QUEUED_CHECKSIncludes queued debits when loading balances for pre-transaction validation.false

​
Coalescing settings

Use Coalescing settings to improve performance and throughput under load when working with hot balances. 
BLNK_TRANSACTION_BATCH_SIZE=1000
BLNK_TRANSACTION_ENABLE_COALESCING=true
BLNK_TRANSACTION_DISABLE_BATCH_REFERENCE_CHECK=false
DescriptionDefault
BLNK_TRANSACTION_BATCH_SIZEMaximum number of compatible queued transactions Blnk tries to process in one coalesced batch.1000
BLNK_TRANSACTION_ENABLE_COALESCINGEnables coalesced execution for normal queued transaction processing.true
BLNK_TRANSACTION_DISABLE_BATCH_REFERENCE_CHECKDisables reference validation across a coalesced batch before commit. When false, reference checking stays enabled.false

​
BLNK_TRANSACTION_ENABLE_COALESCING

When Coalescing is enabled, Blnk identifies the queued transactions based on if they share the same source, destination, and currency, batches them in-memory, and applies them in a single commit. This works best when queued traffic arrives in bursts and many transactions overlap on the same balances.

Coalescing for hot balances

Higher throughput on contended balances.

​
BLNK_TRANSACTION_DISABLE_BATCH_REFERENCE_CHECK

This controls whether Blnk validates transaction references across the batch before commit. Leaving it as false (the default) is safer because it helps catch duplicate or conflicting references within the same batch, ensuring that your transactions remain idempotent.
Please note: Disabling reference checks may reduce some overhead, but it also increases the risk of duplicate-reference issues slipping through batched execution.

​
Lock settings

Use these settings to control distributed balance locks for direct and queued transaction processing, including coalesced batch execution. 
BLNK_TRANSACTION_LOCK_DURATION=30m
BLNK_TRANSACTION_LOCK_WAIT_TIMEOUT=3s
DescriptionDefault
BLNK_TRANSACTION_LOCK_DURATIONHow long a distributed balance lock can live once acquired, in seconds (non-zero values).1800
BLNK_TRANSACTION_LOCK_WAIT_TIMEOUTHow long Blnk waits when acquiring transaction balance locks (shared path for direct and queued processing, including coalesced batch execution), in seconds.3

​
BLNK_TRANSACTION_LOCK_WAIT_TIMEOUT

This controls how long a transaction should wait when acquiring a lock before the transaction fails with a lock error. If locks are not acquired in time, the operation fails with a lock error. For a direct (skip_queue=true) request, that is typically returned to the client. For queued work, workers may retry or reject depending on queue settings, e.g. BLNK_QUEUE_REJECT_LOCK_CONTENTION_IMMEDIATELY and BLNK_QUEUE_MAX_RETRY_ATTEMPTS.
Tip: Keep the default value unless transactions regularly outlive the lock window. This config is especially important for transactions that bypass the queue.

​
Hash chain settings

Available in version 0.15.0 and later.
The optional transaction hash chain seals applied transactions into a global tamper-evident sequence. It is disabled by default. When enabled, a background processor backfills unchained rows and appends new transactions after a trailing delay. Run blnk verify-chain from your Core deployment to check chain integrity. In blnk.json, poll_interval and trailing_delay are integer seconds. Environment variables accept Go duration format (for example 5s, 30s). 
BLNK_TRANSACTION_HASHCHAIN_ENABLED=false
BLNK_TRANSACTION_HASHCHAIN_POLL_INTERVAL=5s
BLNK_TRANSACTION_HASHCHAIN_BATCH_SIZE=1000
BLNK_TRANSACTION_HASHCHAIN_TRAILING_DELAY=30s
DescriptionDefault
BLNK_TRANSACTION_HASHCHAIN_ENABLEDEnables the background hash-chain processor.false
BLNK_TRANSACTION_HASHCHAIN_POLL_INTERVALHow often the processor polls for unchained transactions. Env: Go duration (for example 5s). JSON: seconds.5s / 5
BLNK_TRANSACTION_HASHCHAIN_BATCH_SIZEMaximum transactions sealed per processor batch.1000
BLNK_TRANSACTION_HASHCHAIN_TRAILING_DELAYWait time before sealing the newest transactions, so in-flight writes can settle. Env: Go duration (for example 30s). JSON: seconds.30s / 30

Transaction hashing

Per-row hashes, chain verification, and sealed fields.

​
Need help?

We are very happy to help you make the most of Blnk, regardless of whether it is your first time or you are switching from another tool. To ask questions or discuss issues, please contact us or join our Discord community.