Atomic Batch Transactions Drop Smart Contract Calls

Hedera is initiating a major change for developers, announcing a six-month deprecation period for smart contract calls submitted as inner transactions of an Atomic Batch Transaction, with full removal slated for March 2027. Applications that submit an atomic batch containing a smart contract call will be affected, while batches using only native service operations like token, topic, or account transactions will continue to function as before. Standalone smart contract calls and operations for mirror node, relay, and node operators are also unaffected.

The transition arrives in two stages, beginning in September 2026 when the platform will enforce a strict constraint on mainnet. At that point, a batch may contain no more than one smart contract call, and it must be the final inner transaction; any batch violating this positional rule or containing multiple calls will be rejected. Consequently, from March 2027, smart contract calls will no longer be supported as inner transactions of an atomic batch at all, while the batch key model, per-transaction signing, and all-or-nothing execution across native operations remain unchanged.

This change stems from a fundamental architectural gap, as atomic batch transactions have no equivalent construct in the Ethereum Virtual Machine (EVM). A contract call embedded inside a batch can never be made fully equivalent to a direct submission, so moving that logic into the contract layer removes this inconsistency and aligns with the path toward full EVM compatibility. Meanwhile, atomic batch transactions will continue to serve their original purpose of composing Hedera service operations without requiring smart contracts, as outlined in HIP-551.

Developers are urged to review any workload that submits atomic batches and identify those including a smart contract call to confirm they meet the September 2026 constraint. Three migration approaches are available, beginning with composing inside a contract, where atomicity is guaranteed within a single execution frame via system contracts for native operations or direct invocation. Alternatively, developers can use system contracts to reach token, account, and scheduling operations through the Hedera Token Service, Hedera Account Service, and Hedera Schedule Service, expressing entire flows in contract code. Finally, submitting transactions sequentially, rather than atomically, removes the dependency on batch composition where strict all-or-nothing behavior across separate signers is not required. Teams seeking help mapping an existing flow can raise it in the Hedera Discord.

✅ Follow BITNEWSBOT on Telegram, Facebook, LinkedIn, X.com, and Google News for instant updates.

Previous Articles:

• THORChain refuses Bitget’s plea to block hack addresses
• Storm-3168: AI-Orchestrated Azure Attacks Hit Service Principals
• Sensex, Nifty crash over 1,000 points, hit May 2024 lows
• South Korea weighs crypto market-making after JPYC surge
• Nvidia Gains as China Considers RTX 5500 GPU Purchases