This controls how Blnk behaves when a transaction bypasses the queue, i.e. skip_queue=true cannot acquire its required lock immediately.It tells Blnk how long to wait for the lock to be acquired. If the lock is not acquired within this time, the transaction is rejected.
Tip: Keep the default value unless transactions regularly outlive the lock window.
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
Learn when to use coalescing and how it improves throughput for contended balance flows.
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.
Blnk hashes the source balance ID and assigns the transaction to one of the configured queue shards. More queues allow more unrelated balances to process in parallel.This helps reduce collisions before execution, but it does not replace locking. If many transactions still target the same balances, increasing the shard count alone will not solve the hotspot.See instead: How to handle hot balances.
This controls how many normal queued transaction tasks can execute at the same time.Higher concurrency can improve throughput when work is spread across unrelated balances. It can also increase lock contention when many tasks overlap on the same balances. Increase it gradually and watch for contention before raising it further.
This sets the maximum number of times Blnk will try a queued transaction again after a temporary failure such as lock content, insufficient funds, etc.In simple terms:
If a queued transaction fails for a reason that may clear on its own, Blnk can try it again
If it keeps failing, Blnk stops after this limit instead of retrying forever.
This controls whether Blnk should retry queued transactions that fail because the source balance does not have enough funds.Leave this disabled when an insufficient-funds result should be treated as final. Enable it only when the balance may change shortly after the first attempt, for example:
another queued credit is still being processed
funds are expected to arrive from another part of your workflow
transaction ordering means the balance may be sufficient on a later retry
Hot-lane routing is Blnk’s contention-aware queue routing strategy.Blnk tracks repeated lock-contention events for a specific source|destination|currency pair. When contention crosses the configured threshold, BLNK_QUEUE_HOT_PAIR_LOCK_CONTENTION_THRESHOLD, Blnk promotes that pair into a hot state. New queued transactions for that pair are then routed to a dedicated hot queue instead of the normal queue shards.This helps isolate the hottest balance pairs from the rest of your queued traffic, so they stop disturbing normal queue processing.
This setting changes what queued workers do after a lock-contention failure.When set to true, Blnk rejects the transaction immediately if the required lock is busy. When set to false, the worker treats the failure as retryable and retries it up to BLNK_QUEUE_MAX_RETRY_ATTEMPTS.
Please note: This setting does not affect skip_queue=true transactions.
Enable hot-lane routing when only a few balance pairs keep colliding.
Use a shorter TTL for short bursts so pairs return to the normal queue sooner after traffic settles. Use a longer TTL when the same pairs stay hot for longer periods.
Lower the threshold if hot pairs are not moving into the hot lane fast enough. This makes Blnk promote contended pairs sooner instead of letting them keep slowing down the normal queue.
Only enable immediate rejection when you do not want Blnk to retry lock-contention failures.
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.
Tip: Connect to Blnk Cloud to see your Core data.You can view your transactions, manage identities, create custom reports, invite other team members to collaborate, and perform operations on your Core — all in one dashboard.Check out Blnk Cloud →
