Unlocking New Possibilities with Hedera Batch Transactions

Batch Transactions on Hedera transform how developers build decentralized applications by bringing enterprise-grade transaction composability to native network services. This capability unlocks sophisticated workflows previously requiring smart contracts, positioning Hedera as the platform of choice for applications demanding both transactional integrity and performance at scale.

The Power of Batch Transactions

With the implementation of HIP-551: Batch Transactions, the Hedera network now enables developers to execute multiple operations as a single atomic transaction with ACID (Atomicity, Consistency, Isolation, and Durability) properties. Complex multi-step operations either complete entirely or fail completely, eliminating partial execution scenarios that create inconsistent states or security vulnerabilities.

By enabling atomic execution across different Hedera services without requiring smart contracts, batch transactions significantly simplify development workflows while enhancing both security and user experience. Batch transactions provide the atomicity guarantees needed for sophisticated decentralized applications while maintaining Hedera’s performance advantages.

Let’s dive into HIP-551 and learn more about what this means for users and developers.

HIP-551 at a Glance: Enabling Atomic Transaction Execution

Batch Transactions enable developers to group multiple transactions into a single atomic operation that succeeds or fails as a complete unit. This capability means a series of interdependent HAPI calls can now be executed with guaranteed consistency, ensuring all changes are applied together or none at all to enable the development and execution of secure multi-step workflows.

• All-or-Nothing Transaction Execution: Create more resilient applications by eliminating partial completions where systems may be left in inconsistent states.
• Simplified Developer Workflows: Multi-step operations no longer require manual coordination between separate transactions.
• Enhanced Security for Multi-Step Transactions: BatchKey mechanism ensures only authorized entities can assemble and submit transaction batches.
• Elimination of “Sandwich Attacks”: Malicious actors are no longer able to inject transactions between related and interconnected transactions.

Let’s explore deeper into some of the key features of this new functionality.

Key Features

Batch transactions introduce several powerful capabilities that transform how developers can structure complex operations or workflows on Hedera. At the core of this implementation is a carefully designed architecture that balances security, flexibility, and performance for a refined user and developer experience.

Transaction Integrity: The Self-Contained Unit Principle

Transaction Integrity ensures each inner transaction within a batch functions as a self-contained unit. While these transactions maintain their individual integrity, they’re executed as part of an atomic unit where all succeed or none do. This design maintains the familiar transaction model while adding powerful transaction composition capabilities.

BatchKey Security: Creating Chains of Trust

The introduction of the BatchKey prevents malicious actors from tampering with transaction batches. This key signals the trusted signer who can finalize the batch, ensuring that transactions can only be submitted as a complete unit and preventing individual operations from being executed outside their intended context. The BatchKey must be present in all inner transactions and the batch itself must be signed by all specified BatchKeys, creating a secure chain of trust.

Nested Structure: The Inner vs Outer Transaction Model

The Inner vs Outer Transaction structure clearly separates responsibilities within the batch. Inner transactions are individually signed, pay their own fees, and maintain their own authorization requirements. Meanwhile, the outer AtomicBatch transaction has its own payer and signatures, incorporating the inner transactions as part of its signed bytes. This nested structure maintains Hedera’s existing security model while enabling atomic execution.

Atomic Processing: Ensuring Consistent State Transitions

Batch Transaction Processing follows a consistent model where all transactions must succeed for the batch to be committed. If any inner transaction fails, the entire batch is rolled back, though fees for processed transactions are still applied. This implementation ensures consistent state transitions while maintaining Hedera’s economic model.

Transparent Economics: The Fee Management Approach

Fee Management maintains clarity and predictability by charging each inner transaction separately based on its specific operation type. The outer batch transaction also incurs its own fees for handling the batch, creating a transparent cost structure that aligns with the value provided.

Together, these features create a robust framework for atomic transaction execution that maintains backward compatibility while significantly expanding Hedera’s capabilities for complex workflow implementation.

Practical Use Cases: Transforming How Developers Build on Hedera

HIP-551 enables a wide range of use cases that were previously highly complex or impractical to implement without smart contracts:

Account-bound Tokens

By unfreezing an account, transferring a token — both fungible and non-fungible — and immediately freezing the account again in a single atomic operation, users and developers are enabled to create truly non-transferable digital assets: soulbound tokens.

• Example Application: A university issuing digital diplomas must ensure the issued credentials remain permanently associated with the graduate’s verified wallet.

Complex Token Flows

Combine multiple token operations such as wiping, minting, and transferring tokens into a single atomic transaction. This is particularly valuable for regulatory compliance or complex treasury operations.

• Example Application: A stablecoin issuer needs to implement compliant token upgrades in an uninterrupted sequence of transactions, which can be accomplished by atomically wiping old tokens and minting new ones to the same accounts in a single batch transaction without risking partial execution.

Cross-Service Operations

Execute operations across different Hedera services in a single transaction, such as transferring tokens while simultaneously recording the transfer details to a consensus topic.

• Example Application: A supply chain application could update token ownership of goods while logging the entire transaction history to an immutable HCS topic, ensuring perfect alignment between asset state and documentation.

Compliance Operations

Enable robust regulatory workflows by combining compliance operations. For example, batch transactions allow KYC granting, token transfers, and subsequent KYC revocation in a single atomic operation. This prevents scenarios where tokens might be transferred from a revoked KYC account before they can be properly wiped, closing potential compliance gaps.

• Example Application: A tokenized securities platform executing KYC grants, transfers, and revocations atomically to eliminate compliance gaps.

Approval Workflows

Implement secure multi-party approval processes using the BatchKey mechanism. Corporate treasury operations requiring multiple approvals can use batch transactions to ensure that all required signatories have approved a complex series of operations before any part executes.

• Example Application: A DAO treasury management system requires a specific approval workflow before token transfers occur. Using batch transactions, all approvals and transfers can happen atomically.

These use cases demonstrate how batch transactions bring sophisticated workflow capabilities to Hedera’s native services, enabling more complex applications without requiring smart contracts while maintaining strong guarantees about execution consistency and security

Developer Guide

Let’s take a look at a code snippet that demonstrates how to compose and execute a batch transaction using the Hedera SDK. In this scenario, we’ll create an atomic operation that mints an NFT, distributes fungible tokens to multiple accounts, pauses a token, and submits a message to a consensus topic — all in a single batch that either succeeds completely or fails completely.

Prepare the NFT mint transaction with batch configuration using .batchify()

console.log('Submitting batch HTS operations (mint NFT, distribute FT, pause FT)...');

const mintBatch = await new TokenMintTransaction()
.setTokenId(nftTokenId)
.setMetadata([Buffer.from('Luxury Watch #1')])
.batchify(client, operatorKey);

Prepare the token distribution transaction that transfers fungible tokens to multiple recipients.

const distributeBatch = await new TransferTransaction()
.addTokenTransfer(ftTokenId, operatorId, -TOTAL_SHARES)
.addTokenTransfer(ftTokenId, aliceId, ALICE_SHARES)
.addTokenTransfer(ftTokenId, bobId, BOB_SHARES)
.addTokenTransfer(ftTokenId, charlieId, CHARLIE_SHARES)
.batchify(client, operatorKey);

Prepare the token pause transaction to freeze token operations.

const pauseBatch = await new TokenPauseTransaction()
.setTokenId(ftTokenId)
.batchify(client, operatorKey);

Prepare the consensus message transaction to record the operation on-chain.

const messageBatch = await new TopicMessageSubmitTransaction()
.setTopicId(topicId)
.setMessage(message)
.batchify(client, operatorKey);

Compose all prepared transactions into a single atomic batch.

const batchTx = new BatchTransaction()
.addInnerTransaction(mintBatch)
.addInnerTransaction(distributeBatch)
.addInnerTransaction(pauseBatch)
.addInnerTransaction(messageBatch);

Execute the batch transaction on the network.

const batchResp = await batchTx.execute(client);

Retrieve and display the overall batch execution status.

const batchReceipt = await batchResp.getReceipt(client);
console.log(`Batch status: ${batchReceipt.status}`);

Query each inner transaction’s receipt to verify individual operation results.

console.log('Querying inner transaction receipts...');

for (const txId of batchTx.innerTransactionIds) {
const r = await new TransactionReceiptQuery()
.setTransactionId(txId)
.execute(client);
console.log(` - Inner tx ${txId.toString()}: status=${r.status}`);

This example illustrates the core workflow for implementing batch transactions. Each individual transaction is prepared using the .batchify() method, which configures it for inclusion in a batch by setting the appropriate BatchKey and node account marker. These prepared transactions are then added to a BatchTransaction object, which handles the atomic execution.

After execution, developers can query both the overall batch receipt and individual inner transaction receipts, providing complete visibility into the success or failure of each operation while maintaining the atomic guarantee that all operations succeed together or fail together.

Technical Implementation

The technical design of batch transactions strikes a careful balance between flexibility, security, and backward compatibility. At its core, the implementation introduces a new AtomicBatchTransactionBody that can contain multiple inner transactions, executed as a single atomic unit. This structure preserves the integrity of individual transactions while ensuring they succeed or fail as a group.

Inner transactions maintain their own integrity within the batch, with each containing its own signatures, fees, and authorization requirements. To designate a transaction as part of a batch, inner transactions set their nodeAccountID to 0.0.0 (a special marker value) and must include a batchKey. This key is crucial for security, as it designates the trusted entity authorized to assemble and submit the batch. The outer batch transaction must be signed by all batchKey signers specified in the inner transactions, establishing a chain of trust.

Code Snippet

// Define the BatchKey - the trusted entity that can finalize the batch
const batchKey = PrivateKey.generateED25519();
const operatorKey = PrivateKey.fromString(process.env.OPERATOR_KEY);

// Create Inner Transaction 1: Token Mint
// Inner transactions set nodeAccountID to 0.0.0 (special marker value)
const innerTx1 = await new TokenMintTransaction()
  .setTokenId("0.0.12345")
  .setMetadata([Buffer.from("NFT Metadata")])
  .setNodeAccountIds([]) // Empty = 0.0.0 marker for batch
  .batchify(client, batchKey); // Includes batchKey

// Create Inner Transaction 2: Token Transfer
// Each inner transaction maintains its own: Signatures, Fees, and Authorizations 
const innerTx2 = await new TransferTransaction()
  .addTokenTransfer("0.0.12345", "0.0.100", -1)
  .addTokenTransfer("0.0.12345", "0.0.200", 1)
  .setNodeAccountIds([]) // 0.0.0 marker for batch
  .batchify(client, batchKey); // Must include same batchKey

// Create Outer AtomicBatch Transaction
// The outer transaction:
// - Has its own payer and signatures
// - Incorporates inner transactions as part of signed bytes
// - Must be signed by all batchKey signers
const atomicBatch = new BatchTransaction()
  .addInnerTransaction(innerTx1)
  .addInnerTransaction(innerTx2)
  .freezeWith(client)
  .sign(batchKey); // Signed by batchKey - establishes chain of trust

// Execute as single atomic unit
// All succeed together or all fail together
const response = await atomicBatch.execute(client);
const receipt = await response.getReceipt(client);

console.log(`Batch Status: ${receipt.status}`);
console.log(`All operations executed atomically`);

The architecture includes clear rules for transaction processing: inner transactions cannot themselves be batch transactions, they must have unique transaction IDs within the batch, and they cannot be scheduled transactions. These constraints ensure predictable execution behavior. When a batch executes, transactions are processed in sequence, with each creating its own transaction receipt and record. If any inner transaction fails, the entire batch is rolled back, although fees for processed transactions are still charged.

Fee handling follows a straightforward model where each inner transaction pays its own fees based on its type, while the batch transaction also incurs fees for handling the overall batch. This approach maintains economic alignment with the value provided. The implementation includes appropriate limits on batch size, with constraints on both the number of transactions (capped by configuration and the current limit of 50 child transactions) and the total byte size (restricted to the maximum transaction size of 6KB).

When working with the Mirror Node API, batch transactions are fully traceable, with records for inner transactions including a parentConsensusTimestamp that links them to their parent batch transaction. This ensures complete auditability while enabling developers to understand the relationships between operations. The SDK design includes a new BatchTransaction class that allows developers to easily compose transactions into batches while maintaining familiar API patterns.

Ecosystem Impact and Future Directions

Batch transactions position Hedera at the forefront of blockchain interoperability and developer experience by enabling complex multi-step operations without requiring smart contracts. This capability significantly expands what’s possible with Hedera’s native services, allowing developers to implement sophisticated business logic with strong atomicity guarantees. For enterprise users, this means reduced complexity and enhanced security for regulatory compliance, asset management, and multi-party approvals. For dApp developers, it means cleaner code, more predictable behavior, and the ability to create seamless user experiences that weren’t previously possible without complex workarounds.

Looking ahead, batch transactions lay the groundwork for further enhancements to Hedera’s transaction model. While the current implementation provides solid foundations for atomic execution, future improvements could address open issues like detailed failure reporting for inner transactions and expanded batch size limits. The community is also exploring how batch transactions might integrate with other Hedera features such as scheduled transactions for time-based atomic operations. As developers begin incorporating batch transactions into their applications, we anticipate discovering new patterns and use cases that will further shape Hedera’s evolution toward an increasingly powerful and developer-friendly platform.

Resources

HIP-551 Documentation: https://hips.hedera.com/hip/hip-551
Atomic Transactions Chains: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/531

Unlocking New Possibilities with Hedera Batch Transactions was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.