Smart contract calls submitted as inner transactions of an Atomic Batch Transaction enter a six-month deprecation period, with removal planned for March 2027. Atomic batch transactions remain fully supported for composing native Hedera service operations. Developers who include a smart contract call in a batch should plan to move that logic into a contract during the deprecation window, where ordering and outcome are predictable within a single execution.
Who is Affected
This change affects applications that submit an atomic batch containing a smart contract call as an inner transaction.
Developers are not affected if their batches contain only native service operations such as token, topic, or account transactions. Those batches continue to work as they do today. Smart contract calls submitted as standalone transactions are unaffected. Mirror node, relay, and node operators need to take no action.
What’s Changing
The change arrives in two stages.
- As of September 2026: a batch may contain no more than one smart contract call, and it must be the final inner transaction in the batch. Batches that place a smart contract call in any other position, or that contain more than one, are rejected.
- From March 2027: smart contract calls are no longer supported as inner transactions of an atomic batch.
Everything else stays the same, including the batch key model, per-inner-transaction signing and fees, all-or-nothing execution across native operations, and the inner transaction limit.
Why This Change Is Happening
Atomic batch transactions have no equivalent construct in the EVM, so a contract call embedded inside one can never be made fully equivalent to the same call submitted directly. Moving that call into the contract layer removes this gap and keeps contract execution on a path toward full EVM compatibility, where a single execution frame governs ordering and outcome. Atomic batch transactions continue to serve the purpose HIP-551 describes, composing Hedera service operations without requiring smart contracts.
What You Need to Do
- Review any workload that submits atomic batch transactions and identify batches that include a smart contract call.
- Confirm that those batches satisfy the September 2026 constraint of no more than one smart contract call, in the final position.
- Move the contract logic to one of the approaches below before the deprecation period ends.
Three approaches are available today
Compose inside a contract. Deploy a contract that performs the sequence of calls it needs and invoke it directly. Composition happens within a single Ethereum Virtual Machine (EVM) transaction, so the atomicity is guaranteed by the smart contract.
Use system contracts for native operations. Token, account, and scheduling operations are reachable from EVM code through the Hedera Token Service (HTS), Hedera Account Service (HAS), and Hedera Schedule Service (HSS) system contracts, so many flows can be expressed entirely in contract code.
Submit sequentially. Where strict all-or-nothing behavior across separate signers is not required, submitting transactions sequentially, not atomically, removes the dependency on batch composition.
Timeline
- September 2026: the deprecation period opens. The one-contract-call constraint takes effect on mainnet.
- March 2027, estimated: the deprecation period closes and the removal takes effect.
Reminders, or potential changes related to this change, will be communicated throughout the six-month deprecation period.
Developers running batch workloads should review any batch that includes a smart contract call and plan the move to contract-level composition during the deprecation window. Teams wanting help mapping an existing flow can raise it in Discord.
Resources and Support
- HIP-551: Batch Transactions
- Create a Batch Transaction
- Hedera Smart Contracts documentation
- Hedera Discord for migration questions
- FAQ’s
