Bitkub Blockchain Technology adopted AutoMQ to power its system of ‘THBK’ under the Enhanced Regulatory Sandbox - Programmable Payment on AWS — achieving 97% blockchain block utilization, 100% uptime, and significant cost savings.
"Since replacing our previous Kafka service with AutoMQ, we've achieved 100% uptime with zero production incidents. AutoMQ's S3-based architecture gives us the cost efficiency and instant elasticity that a 24/7 blockchain platform demands. It has become the backbone connecting our off-chain services to on-chain transactions, and we look forward to expanding more use cases on it as our THBK programmable payment ecosystem grows."
— Nuttapatprom, Technology Director, Bitkub Blockchain Technology
A Sandbox for Testing Programmable Payment That Runs on the Blockchain
Bitkub Blockchain Technology (BBT) is building something unusual, under the approval of the Bank of Thailand (“BOT”) under the Enhanced Regulatory Sandbox Program, for testing of a payment system where real money moves on a real blockchain.
BBT is the blockchain infrastructure arm of Bitkub Capital Group Holdings, the parent company behind Thailand's largest cryptocurrency exchange. While the exchange handles trading, BBT's job is different — it builds the infrastructure that makes blockchain useful for everyday commerce. The company developed KUB Chain, an EVM-compatible Layer-1 network, and on top of it launched the Programmable Payment token, namely “THBK”, with the value of 1 THBK equals to 1 THB under the Enhanced Regulatory Sandbox for Programmable Payment.
THBK is not a speculative token. It is being tested for escrow payments, asset tokenization, and cross-chain bridging. Merchants like Villa Market, Jaymart, and Casa Lapin already participate. When a customer pays with THBK, the transaction must flow through a full pipeline — from the user's app, through backend validation, into a message queue, through transaction preparation, and finally onto the blockchain — all in real time, operating within a robust framework designed for total accuracy and uninterrupted service at every step of the transaction.
That pipeline is where this story begins.
The Problem: A Blockchain That Was 90% Empty
Every block on KUB Chain has a gas limit of approximately 90 million, which translates to roughly 400 transactions per block. In theory, that is plenty of capacity. In practice, without optimization, only about 10% of each block's capacity would typically be utilized.
The reason is structural. A blockchain does not accept transactions the way a database accepts writes. Each transaction must be signed by a wallet, submitted to the network, and packed into a block within the gas limit. With a standard approach — sending transactions sequentially from a single wallet — most of the block's capacity goes unused. The transactions trickle in too slowly to fill the available space before the block closes.
For a payment system processing deposits, withdrawals, enterprise settlements, and merchant transactions around the clock, this was not just an efficiency problem. It was a throughput ceiling that would eventually limit how many users and merchants THBK could serve.
The fix could not come from the blockchain side — the gas limit is a protocol-level constraint. It had to come from the infrastructure that feeds transactions to the chain. Specifically, it had to come from the message queue sitting between BBT's application services and the blockchain.
The Architecture: Off-Chain Meets On-Chain
To understand why the message queue matters so significantly, we need to look at how the THBK system is built.
The Off-Chain Layer
The off-chain layer is a standard microservices architecture. Users interact with BBT's applications via APIs, and requests flow through a gateway into backend services that handle the core business logic:
-
Bank Adapter — receives deposit and withdrawal status updates from payment gateway partners, keeping the system in sync with traditional banking rails
-
KUB Wallet — Automatically processes daily withdrawals for enterprise clients at midnight.
-
THBK transaction and NFT messaging — handles core token transfer and digital asset messages
-
Notification service — pushes real-time updates to end users and partners (banks, merchants)
This part of the system looks like any well-built fintech platform. The complexity is in what happens next.
The On-Chain Layer
When a transaction needs to be committed to KUB Chain, it crosses into a fundamentally different environment — one governed by gas limits, block intervals, and wallet nonces. The message queue is the bridge between these two worlds. Every transaction that reaches the blockchain must first pass through it.
BBT's team realized that the key to unlocking block utilization was not on the blockchain — <span class="mark">Instead, it was about how transactions were queued, batched, and dispatched. They needed a message queue that could:</span>
-
Handle the full off-chain business messaging (deposits, withdrawals, notifications) with financial-grade reliability
-
Feed the on-chain transaction pipeline with enough throughput and flexibility to support multi-wallet parallel submission and batch optimization
-
Run 24/7 with zero downtime — because a stuck queue means stuck payments
Their existing Kafka infrastructure — a commercial managed service — was handling the basics, but it carried high fixed costs, limited elasticity, and operational overhead that distracted the team from their core blockchain work. They needed something better.
Why AutoMQ
BBT chose AutoMQ because its architecture directly addressed the constraints they were hitting.
Zero Migration Risk
AutoMQ implements the full Apache Kafka protocol. Every existing topic, consumer group, and microservice integration — Bank Adapter, Wallet KSBK, notification pipelines — migrated with zero code changes. For a team running regulated financial infrastructure, this was the prerequisite: any new platform had to be a drop-in replacement, not a re-architecture.
S3-Based Storage, Stateless Brokers
AutoMQ stores data on Amazon S3 instead of local disks. Brokers hold no persistent state. This eliminates the disk management, replica synchronization, and data rebalancing overhead of traditional Kafka — and drops storage costs significantly, since S3 is a fraction of the price of EBS volumes.
Instant Elasticity
Stateless brokers mean scaling takes seconds, not hours. No data needs to move when a broker is added or removed. For a payment platform where transaction volumes fluctuate with market activity and merchant promotions, this means the infrastructure responds to demand rather than being sized for worst-case peaks.
Fully Managed, Fully Controlled
AutoMQ runs in BBT's own AWS account via the BYOC (Bring Your Own Cloud) model. BBT keeps full control of its data and network; AutoMQ handles cluster operations — upgrades, scaling, monitoring, incident response. The engineering team can focus on blockchain products instead of Kafka maintenance.
Lower Cost
S3 storage, no cross-AZ replication traffic, and elastic scaling add up to meaningful savings compared to the previous Kafka service. BBT pays for what it uses, not for peak-capacity reserves.
The Result: 97% Block Utilization
With AutoMQ in place, BBT's team rebuilt the transaction pipeline. The message queue now powers a multi-stage optimization process:
-
Requests enter the queue — After API validation, payment requests are published to AutoMQ topics
-
Consumers track state — Dedicated consumers read from the queue and maintain pending transaction state
-
Multi-wallet distribution — A Transaction Adapter distributes pending transactions across multiple sender wallets, parallelizing on-chain submission
-
Batch optimization — Transactions are grouped to maximize gas utilization within each block
-
On-chain submission — Optimized batches are submitted to KUBChain
The outcome speaks on two levels.
At the infrastructure level, AutoMQ delivered exactly what BBT needed from a Kafka replacement: 100% uptime with zero production incidents since October 2025, 100% Kafka protocol compatibility requiring zero code changes during migration, and meaningful cost savings through S3-based storage and elastic scaling on AWS.
That infrastructure stability is what made the business result possible. With a message queue that never drops, never stalls, and scales on demand, BBT's team could push the transaction optimization pipeline to its full potential — achieving 97% block utilization, up from roughly 10%. In practical terms, the same blockchain now processes nearly 10x more transactions per block. For a regulated THBK under the Enhanced Regulatory Sandbox - Programmable Payment serving a growing merchant network, that is the capacity headroom needed to scale confidently.
Currently, AutoMQ handles all of BBT's real-time messaging across 7 to 12 consumer groups — from payment gateway integration and enterprise settlements to transaction notifications for banking partners and end users. These are not experimental workloads. They are the production backbone of a programmable payment.
What's Next
The foundation is proven. Now BBT is building on it:
-
More financial use cases — As the Bank of Thailand approves additional testing of THBK under the Enhanced Regulatory Sandbox - Programmable Payment, BBT will add more consumer groups and topics to handle new transaction types
-
Cross-chain expansion — THBK bridging to JFIN Chain is already underway, with potential expansion to additional blockchain networks
-
A growing merchant ecosystem — As more partners join to utilize and incorporate THBK in their use cases, AutoMQ's elastic architecture ensures the messaging layer scales without re-architecture
Each new use case is an incremental addition to a platform that has already demonstrated 100% uptime and zero incidents in production. The hard part — proving the architecture works under real financial workloads — is done.
About AutoMQ
AutoMQ is a cloud-native, fully Kafka-compatible streaming platform built on object storage. By decoupling compute from storage and using S3 as the primary persistence layer, AutoMQ delivers significant cost reduction, instant elasticity, and zero-downtime operations — while maintaining 100% compatibility with existing Kafka clients, tools, and ecosystems.
Learn more at <u>automq.com</u>.