Hamilton, Bermuda, November 11, 2026 — Apex Group Ltd. (“Apex Group”), a global financial services provider servicing more than $3.5 trillion in assets, has joined Hedera Council, contributing its expertise in fund services, digital assets and institutional market infrastructure to the governance of the Hedera public network.

As a Council member, Apex Group will help support the Council’s mission to maintain a trusted, secure and decentralized public network for enterprises and developers worldwide, alongside other leading global organizations.

Apex Group was an early institutional adopter of digital assets and became the first transfer agent and fund service provider to administer regulated securities using distributed ledger technology (DLT) as the book of record. That work opened global private-market funds to broader pools of qualified investors and established the firm’s approach: technology must solve a clear business need and deliver tangible value for clients.

Hedera is a trusted and auditable public network designed to support asset lifecycle events, compliance attestations and settlement coordination. Apex Group will explore opportunities to leverage the Hedera network as part of its broader digital asset and tokenization initiatives.

Marco A. Infuso, Head of Digital Assets, Central Europe, at Apex Group, said:

“Institutional tokenization will scale only when compliance is embedded throughout the asset lifecycle, not added as an afterthought. That principle underpins our use of ERC-3643, the standard for compliant tokenization. By removing technological complexity, we can give clients a seamless experience and the flexibility to hold assets in traditional or tokenized form, with consistent standards of control and protection.”

The appointment reinforces Apex Group’s longstanding commitment to digital assets through Apex Digital 3.0. The all-in-one tokenization solution enables clients to launch, distribute, service and manage digital and tokenized assets within a single ecosystem. Its institutional capabilities span tokenization, stablecoins, regulated transfer agency, investor identity, proof of reserves and digital fund servicing, bridging traditional and on-chain finance.

Mance Harmon, chair of the Hedera Council, said:

“Apex Group combines deep expertise in private-market servicing with a clear vision for digital assets. Its addition strengthens the Council at a pivotal moment, as institutional tokenization moves from experimentation to real-world adoption.”

Apex Group’s membership advances the Council’s goal of maintaining a geographically diverse governing body drawn from industries shaping the future. Council members work together to keep the Hedera public network secure, decentralized and enterprise-ready.

Apex Group joins Hedera Council to advance institutional digital assets was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

HIP-1341 brings the execution-layer features of Ethereum’s Pectra upgrade to the Hedera Smart Contract Service, and they have been live on Hedera Mainnet since Release 77 in September 2026. Smart contracts on Hedera now run on the Prague EVM, with native BLS12–381 cryptography, Ethereum-aligned calldata pricing, and full gas accounting for access lists. Most contracts keep working with no changes. Developers who hardcode gas limits for data-heavy transactions or deploy very large contracts should review the Action Required section below.

Motivation

Native BLS12–381 Cryptography (EIP-2537)

Ethereum activated its Pectra hard fork in May 2025, and Solidity compilers, Foundry, and other EVM tooling now target the Prague EVM that Pectra introduced. Developers expect a contract that works on Ethereum to behave the same way on any EVM network they deploy to. HIP-1341 reviews each of the twelve EIPs in Pectra and adopts the ones that apply to Hedera’s execution layer, so gas costs, precompiles, and transaction behavior stay Ethereum-aligned. EIPs that cover blobs, validators, or the consensus layer do not apply to Hedera’s architecture and are documented as out of scope. This follows the same approach Hedera took for the Cancun upgrade (see HIP-865 and HIP-866).

What’s New in Release 77

BLS12–381 is a pairing-friendly elliptic curve. Ethereum’s validators use it to sign blocks, and many zero-knowledge proof systems are built on it. Its signatures can be aggregated, so thousands of signatures can be checked as one. EIP-2537 adds seven precompiles for BLS12–381 operations. A precompile is a built-in contract at a fixed address that runs native code inside the EVM client instead of interpreted bytecode. HIP-1341 notes that these operations can be written in Solidity, but “the gas costs are prohibitive.” As precompiles, they run at fixed, published gas prices.

Hedera exposes all seven at the same addresses and gas costs as Ethereum:

• 0x0b G1ADD: adds two G1 points. Input 256 bytes. 375 gas
• 0x0c G1MSM: multi-scalar multiplication on G1. Input 160 × k bytes for k pairs. k × 12,000 × discount ÷ 1,000 gas, where the discount factor falls as k grows and is capped at 519 for k above 128
• 0x0d G2ADD: adds two G2 points. Input 512 bytes. 600 gas
• 0x0e G2MSM: multi-scalar multiplication on G2. Input 288 × k bytes. k × 22,500 × discount ÷ 1,000 gas, with the discount capped at 524 for k above 128
• 0x0f PAIRING_CHECK: checks a product of pairings. Input 384 × k bytes. 32,600 × k + 37,700 gas (a two-pair check costs 102,900 gas)
• 0x10 MAP_FP_TO_G1: maps a field element to a G1 point. Input 64 bytes. 5,500 gas
• 0x11 MAP_FP2_TO_G2: maps a field element to a G2 point. Input 128 bytes. 23,800 gas

Solidity has no built-in wrapper for these precompiles, so contracts call them with a low-level staticcall:

// Adds two BLS12-381 G1 points using the EIP-2537 precompile at 0x0b.
function g1Add(bytes memory input) internal view returns (bytes memory) {
    require(input.length == 256, "G1ADD expects 256 bytes");
    (bool ok, bytes memory result) = address(0x0b).staticcall(input);
    require(ok && result.length == 128, "G1ADD failed");
    return result;
}

Why it matters: BLS12–381 verification on-chain is the foundation for Ethereum light clients, cross-chain bridges, staking and restaking protocols, verifiable randomness beacons such as drand, and zk proof verifiers. These can now run natively on Hedera with the same contracts and gas assumptions used on Ethereum.

Calldata Gas Floor (EIP-7623)

Calldata is the input data sent with a contract call or deployment. EIP-7623 sets a minimum gas charge based on how much calldata a transaction carries. Ethereum introduced it to limit block size. HIP-1341 adopts it on Hedera for equivalence: “Although the limit to maximum block size and block gas limit do not directly apply to Hiero, for EVM equivalence, Hiero will also adopt these gas costs.”

Calldata is measured in tokens, and the transaction pays whichever is higher, the standard cost or the floor:

// Adds two BLS12-381 G1 points using the EIP-2537 precompile at 0x0b.
function g1Add(bytes memory input) internal view returns (bytes memory) {
    require(input.length == 256, "G1ADD expects 256 bytes");
    (bool ok, bytes memory result) = address(0x0b).staticcall(input);
    require(ok && result.length == 128, "G1ADD failed");
    return result;
}

Why it matters: BLS12–381 verification on-chain is the foundation for Ethereum light clients, cross-chain bridges, staking and restaking protocols, verifiable randomness beacons such as drand, and zk proof verifiers. These can now run natively on Hedera with the same contracts and gas assumptions used on Ethereum.

Calldata Gas Floor (EIP-7623)

Calldata is the input data sent with a contract call or deployment. EIP-7623 sets a minimum gas charge based on how much calldata a transaction carries. Ethereum introduced it to limit block size. HIP-1341 adopts it on Hedera for equivalence: “Although the limit to maximum block size and block gas limit do not directly apply to Hiero, for EVM equivalence, Hiero will also adopt these gas costs.”

Calldata is measured in tokens, and the transaction pays whichever is higher, the standard cost or the floor:

tokens_in_calldata = zero_bytes + 4 × non_zero_bytes

standard = 21,000 + 4 × tokens_in_calldata + execution gas (after refunds)
floor    = 21,000 + 10 × tokens_in_calldata

gas used = max(standard, floor)

The standard cost also includes contract-creation and access-list charges where they apply. For example, a call carrying 1,000 non-zero bytes with very little execution has a standard cost of 37,000 gas and a floor of 61,000 gas. It is charged 61,000. A call that does meaningful computation already exceeds the floor, so its cost stays the same.

The floor applies to every EVM entry point on Hedera: EthereumTransaction, ContractCall, and ContractCreate. A transaction’s gas limit must cover the floor, or the transaction fails with INSUFFICIENT_GAS. The Hiero JSON-RPC Relay applies the same check before submission, and eth_estimateGas results already include the floor. Unused gas is still fully refunded. See Gas and Fees for the full breakdown.

Why it matters: Gas estimates and cost models built for post-Pectra Ethereum carry over to Hedera without adjustment.

Access List Gas Accounting (EIP-2930)

An access list is an optional field in Type 1 and Type 2 Ethereum transactions. It declares up front which contract addresses and storage slots the transaction will touch. Release 77 applies the full gas rules from EIP-2930 to these lists:

• Each listed address: 2,400 gas, added to the transaction’s intrinsic cost
• Each listed storage key: 1,900 gas, added to the transaction’s intrinsic cost
• Pre-warming: listed entries are marked “warm,” so the first access costs 100 gas instead of the cold rate (2,600 for an account, 2,100 for a storage read)

Each listed entry that the transaction actually uses saves about 100 gas. An entry that is never used adds its full cost, so accurate lists matter. The JSON-RPC Relay does not support eth_createAccessList (it returns error -32601), so access lists are built manually or with client-side tooling. See Access Lists (EIP-2930) for a full example.

Why it matters: Transactions that include access lists are now priced the same way as on Ethereum, so existing tooling and gas optimizations behave as expected.

Initcode Size Limit (EIP-3860)

Release 77 also enforces the initcode limit from EIP-3860. Initcode is the bytecode that runs once to deploy a contract. It is capped at 49,152 bytes. A deployment over the limit fails with CONTRACT_SIZE_LIMIT_EXCEEDED. A CREATE or CREATE2 from inside a contract fails with CODE_TOO_LARGE. The JSON-RPC Relay checks the same limit before submission.

Token and Schedule Facade Bytecode

Hedera token and schedule addresses expose a Solidity interface, called a facade, that forwards calls to the Hedera Token Service and Hedera Schedule Service system contracts. With the Prague EVM, these facades are represented as delegation indicators, the same format EIP-7702 defines. For example, eth_getCode on a token address now returns 0xef0100 followed by the address of the Hedera Token Service system contract (0x167). Direct calls to token and schedule facades work as before, but tools or contracts that inspect bytecode at these addresses will see the new format.

What Is Not Included

EIP-7702 lets an externally owned account (EOA) delegate its execution to smart contract code. This enables batched transactions, sponsored gas, and other smart-account features. On Hedera it is specified in HIP-1340. The functionality ships in Release 77 but is not yet enabled. Type 4 (set-code) transactions are not accepted: the JSON-RPC Relay rejects them with error -32611, and eth_getCode on an EOA continues to return empty code. Enabling HIP-1340 will be announced separately.

The remaining Pectra EIPs do not apply to Hedera’s architecture:

• Blobs (EIP-7691, EIP-7840): Hedera does not support blob transactions (HIP-866)
• Validator and beacon-chain mechanics (EIP-6110, EIP-7002, EIP-7251, EIP-7685): Hedera’s consensus has no Ethereum validators or beacon chain
• Consensus-layer changes (EIP-2935, EIP-7549): these relate to Ethereum’s consensus layer, so Hedera keeps its own block-hash handling
• EIP-7642: an informational networking change

Action Required

Not affected: most contract calls, where execution cost already exceeds the calldata floor; contracts that do not use access lists; and applications that use native Hedera services through the SDKs. No SDK upgrade is required for these changes. Contracts compiled for Cancun or Prague deploy as before.

Affected: developers with hardcoded gas limits on data-heavy transactions, very large deployments, access-list users, and tools that read facade bytecode. Steps:

1. Check gas limits on calldata-heavy transactions. Make sure the gas limit is at least 21,000 + 10 × tokens_in_calldata. Gas limits taken from eth_estimateGas already include the floor.
2. Check initcode size for large deployments. Contracts deployed through the File Service or jumbo Ethereum transactions must have initcode of 49,152 bytes or less.
3. Review access lists. Include only addresses and storage slots the transaction actually uses, and make sure the gas limit covers 2,400 gas per address and 1,900 gas per storage key.
4. Update bytecode checks on token and schedule addresses. Tools that compare bytecode at these addresses should expect the 0xef0100 delegation-indicator format.
5. Set evmVersion explicitly. Hedera runs the Prague EVM. Solidity 0.8.31 and later compile for the newer Osaka EVM by default, so set evmVersion to prague (or earlier) in Hardhat, Foundry, or solc settings.

What This Means for EVM Developers

Release 77 keeps Hedera’s EVM in step with Ethereum’s execution layer. Contracts, gas estimates, and tooling configured for Prague behave the same on Hedera, and cryptographic workloads that depend on BLS12–381 can now run natively. Combined with Hedera’s fast finality and low, predictable fees, this opens Hedera to bridge, light-client, and zk-verification projects that need BLS12–381 support.

FAQ

Do existing contracts need to be redeployed? No. Deployed contracts keep working. Re-test transactions with large calldata and low computation if they use hardcoded gas limits, since the calldata floor can raise their gas usage.

Will gas costs go up? Only for transactions that carry a lot of calldata relative to the computation they perform. Access lists add cost for each listed entry and save gas on each entry the transaction actually uses. Most contract calls see no change.

Can Type 4 (EIP-7702) transactions be sent to Hedera? Not yet. EIP-7702 support is specified in HIP-1340 and is not enabled. Type 4 transactions are rejected until it is.

Does the calldata floor apply to native Hedera contract transactions? Yes. It applies to ContractCall and ContractCreate as well as EthereumTransaction.

Next Steps

Full technical details are in the Hedera documentation, including the precompile table, the calldata floor formula, supported Ethereum transaction types, and Cancun-to-Pectra migration notes:

• Deploying Smart Contracts: Pectra Hard Fork: precompile table, past hard forks, and what changed from Cancun to Pectra
• Gas and Fees: Calldata Floor: the floor formula and worked examples
• HIP-1341: Support for Ethereum Pectra Release
• HIP-1340: EOA Code Delegation (EIP-7702)
• Release 77 Notes: the full list of changes in Release 77

Test Pectra features on Hedera Testnet before taking them to mainnet, and bring questions to the developer community on Discord.

HIP-1341: Bringing Ethereum’s Pectra Upgrade to Hedera was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

The Scaffold HBAR Template Bounty is closed and the judging panel has chosen its winners. Each team wins $2000 in HBAR. These templates are educational starting points. They are unaudited, testnet only, and not financial advice.

The winners

Hedera Governed Operations by SpaceDev

github.com/SpaceUY/hedera-governed-operations

Hedera Governed Operations lets a council approve sensitive operations using Hedera’s native multisig from an account’s threshold key. Each proposal is a scheduled transaction the network executes once enough members sign, with no multisig contract.

npm create scaffold-hbar@latest my-app -- --template SpaceUY/hedera-governed-operations

SaucerSwap Limit Orders by Jagadeesh

github.com/Jagadeeshftw/saucerswap-limit-orders

SaucerSwap Limit Orders is price-triggered: users lock tokens in an on-chain vault and set a price, and the Schedule Service re-schedules the vault’s own checks, so no off-chain keeper runs.

npm create scaffold-hbar@latest my-app -- --template Jagadeeshftw/saucerswap-limit-orders

Custos by Victor Jayeoba

github.com/victorjayeoba/scaffold-hbar-custos

Custos demonstrates scheduled liquidation checks for a leveraged trading contract. Every 30 minutes the Schedule Service calls the contract, which liquidates underwater positions and books its own next run. It runs a Chainlink and Supra dual-oracle guard that refuses a stale price or one more than 5% apart.

npm create scaffold-hbar@latest my-app -- --template victorjayeoba/scaffold-hbar-custos

Recurring Buy by RetailBox

github.com/retailbox-automation/recurring-buy

Recurring Buy is time-triggered: it buys a token on SaucerSwap on a schedule such as hourly or weekly, with no bot or server. It includes a front end for setting up and managing schedules.

npm create scaffold-hbar@latest my-app -- --template retailbox-automation/recurring-buy

Predera by Manish Shivabhakti

github.com/superhbar/prediction-market

Predera is a template demonstrating scheduled settlement for price prediction markets, and the contract books its own settlement through the Hedera Schedule Service. It reads Chainlink price feeds with Pyth as a fallback, and YES/NO positions are HTS tokens that trade on SaucerSwap before settlement.

npm create scaffold-hbar@latest my-app -- --template superhbar/prediction-market

Start with the docs

Start building with these Scaffold HBAR templates or create your own!

Browse the scaffold-hbar docs

These templates were tested on testnet. They have not been audited and are not intended for mainnet use as they stand. Anyone adapting them for production is responsible for their own security review and for compliance with the laws that apply to them.

Meet the Scaffold HBAR Template Bounty winners was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI agents are getting remarkably good at reasoning, planning, and taking action. What they have not had (until now) is safe, programmable guardrails.

Giving an AI agent access to your wallet is not a solution. Handing over private keys introduces risk that no guardrail can fully offset. And relying on human approval for every transaction defeats the purpose of autonomous AI. The result is a gap that has quietly limited what agents can actually do in the real world: they can think, but they cannot transact.

Hedera Agent Accounts are built to close that gap.

Introducing Hedera Agent Accounts: programmable, non-custodial spending accounts on Hedera that give your AI agent the ability to transact autonomously (paying for APIs, accessing data, settling invoices, and making purchases on your behalf) within a set of rules you define, enforced on-chain, with your private keys never leaving your wallet.

What is a Hedera Agent Account?

An Agent Account is a spending account you create for your AI agent, funded from your existing Hedera wallet. Think of it as giving your agent its own budget with strict guardrails; not access to your full account.

Using the Agent Account web app, you connect your existing Hedera wallet, assign an agent to the account, and configure the rules that govern how and where it can spend. Those rules (daily spending limits, per-transaction caps, an approved list of merchants and recipients) are then locked into a smart contract on the Hedera network itself. Not stored on a company server. Not adjustable by anyone except you.

From that point, your agent can transact autonomously within those boundaries, 24/7, without you needing to approve every action.

How it works

Connect your existing Hedera wallet
No new wallet to set up. Agent Accounts work with your existing Hedera account. You provision the account, assign an agent, and set an overall spending allowance; all from the Agent Account app.

Set your rules
Before your agent spends a single dollar, you define exactly how it can operate: a total spend limit, a daily cap, a per-transaction maximum, and an allowlist of recipients and merchants the agent is permitted to pay. These rules are written to a smart contract on the Hedera network and cannot be overridden; not by the agent, and not by Hedera.

Let your agent run
Once configured, your agent handles the rest. It can pay for APIs, access gated data, purchase services, and settle transactions; all without waiting on you. Any endpoint, merchant, or seller that accepts HBAR or USDC on Hedera can receive payment from an autonomous AI agent.

Inspect every action
Every policy, transaction, and agent action is preserved on Hedera’s Consensus Service, giving you a verifiable, tamper-proof audit trail of exactly what your agent did and what you authorized.

Your money stays yours

A few things worth being explicit about, because they matter:

Funds never leave your account until the moment of purchase. The agent does not hold a balance. It sends spend requests to the smart contract, which validates them against your rules and executes the transaction. Nothing moves until the moment a valid, policy-compliant purchase is made.

Your agent never sees your private key. Ever. The Agent Account system is designed so that authorization lives at the smart contract layer; your keys are never exposed to the agent runtime.

You can shut it all down in one click. If you want to pause or revoke an agent’s spending, you can do it instantly from your wallet. No support ticket. No waiting period.

Works with any agent, any token

Agent Accounts are backed by the Agentic Payment Services (an MCP server, REST API, and relayer) which means any AI agent that speaks MCP or REST can plug in. Claude, Cursor, ChatGPT, self-hosted agents, custom-built runtimes; if it can make an API call, it can transact with an Agent Account.

Agents can pay in HBAR, USDC, or other Hedera tokens, making Agent Accounts practical for real-world commerce, not just on-chain activity. Agent Accounts are also compatible with x402 purchases, opening the door to a growing ecosystem of pay-per-request APIs and services.

For API and service providers on the receiving end: payments arrive from verified, policy-bound agents with cryptographic proof of user authorization. No chargeback risk. No signup friction for the agent.

One account per agent

Each AI agent you work with gets its own Agent Account with its own budget and rules. A research agent and a shopping agent do not share funds or permissions; they operate independently, within their own policy boundaries. This separation makes it practical to trust different agents with different levels of access without any of them interfering with each other.

For enterprise teams, companies can run their own Agentic Payment Services endpoint and manage agent spending at an organizational level; with delegated controls, team-wide audit trails, and compliance built in from the start.

What’s coming

Hedera Agent Accounts are coming to testnet in Q4 2026 for limited partner validation, alongside an early release of the Pay-per-API marketplace with initial partner endpoints. Public testnet access follows in Q1 2027, with mainnet availability targeted for Q2 2027, pending security review and legal sign-off.

If you are building AI agents and want early access, or if you run an API or service that wants to accept payments from autonomous agents, we want to hear from you.

Get started with Hedera Agent Accounts

Explore the landing page: hedera.com/agent-accounts

Request early access: hedera.com/agent-accounts/#early-access

Learn more about Hedera AI Studio: hedera.com/product/ai-studio

Join the conversation: discord.gg/hedera

Questions about integration or testing? Email us at ai-studio@hashgraph.com

Introducing Hedera Agent Accounts was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

MirrorNodeAccountBalanceQuery is available now in the JavaScript, Java, and Go Hiero SDKs, giving developers a native way to read an account’s HBAR balance from the Mirror Node REST API without leaving the SDK’s familiar query interface. The new method replaces AccountBalanceQuery, giving developers a first-class SDK method to read balances from the mirror node without hand-rolling REST calls or retry logic themselves. Adopting requires no new dependencies or client configuration changes.

Motivation

Mirror nodes have always exposed account balance data through their REST API, and SDK clients already hold a connection to a mirror network. MirrorNodeAccountBalanceQuery extends the SDK’s native query interface to that data, using the same fluent, typed pattern developers use for every other SDK query. It follows the same convention already established for mirror node queries in the SDK, including MirrorNodeContractCallQuery and MirrorNodeContractEstimateQuery.

What MirrorNodeAccountBalanceQuery Does

MirrorNodeAccountBalanceQuery fetches an account’s HBAR balance from the mirror node’s GET /api/v1/balances endpoint and returns it through the same AccountBalance-style result developers already expect.

Key properties:

• Free. No query payment and no HBAR required to execute it.
• Automatic retries. Transient mirror node errors (5xx responses and network failures) are retried with exponential backoff, using the client’s existing timeout and retry configuration.
• Flexible ID formats. Accepts shard.realm.num, an EVM address, a public key alias, or a contract ID, all through the same setAccountId method. The mirror node resolves every format natively, extending that same flexibility to account lookups made through the SDK.

Migrating in 60 Seconds

For the JavaScript SDK, the change is two lines:

// Before
import { AccountBalanceQuery } from "@hiero-ledger/sdk";

const balance = await new AccountBalanceQuery()
    .setAccountId(accountId)
    .execute(client);

console.log(balance.hbars.toString());

// After
import { MirrorNodeAccountBalanceQuery } from "@hiero-ledger/sdk";

const balance = await new MirrorNodeAccountBalanceQuery()
    .setAccountId(accountId)
    .execute(client);

console.log(balance.hbars.toString());

The same pattern applies in Java and Go, using each SDK’s equivalent import. Java developers reading a contract’s balance pass the contract’s shard, realm, and number through AccountId directly, since MirrorNodeAccountBalanceQuery does not expose a separate contract setter:

// Go
balance, err := hiero.NewMirrorNodeAccountBalanceQuery().
    SetAccountID(accountID).
    Execute(client)

Rust, Swift, and C++ developers can read the same data by calling the mirror node’s GET /api/v1/balances endpoint directly through the client’s mirror network configuration.

Action Required

AccountBalanceQuery’s consensus node endpoint is throttled to zero on testnet and mainnet as of release v0.77 of Consensus Node software, as covered in the companion migration guide linked above, so this migration is not optional for applications that depend on it. Developers currently calling AccountBalanceQuery in the JavaScript, Java, or Go SDKs need to migrate to MirrorNodeAccountBalanceQuery:

1. Update to a recent SDK release: @hiero-ledger/sdk for JavaScript/TypeScript, or the equivalent Java and Go SDK packages.
2. Replace AccountBalanceQuery with MirrorNodeAccountBalanceQuery and remove any separate contract-ID setter call, passing contract IDs through setAccountId instead.
3. Add a short retry or poll, or rely on the transaction receipt, anywhere the application reads a balance immediately after submitting a transaction, since propagation from the Consensus nodes to the Mirror nodes requires a few seconds.

Applications that are not currently calling AccountBalanceQuery are not affected.

SDK Availability

AccountBalanceQuery is deprecated in favor of MirrorNodeAccountBalanceQuery and the mirror node REST API, as outlined in the companion migration guide linked above.

Next Steps

Update to the latest SDK release for the language in use and try MirrorNodeAccountBalanceQuery against a testnet account to confirm it fits the application’s balance-reading logic before rolling it out more broadly.

• SDK reference: MirrorNodeAccountBalanceQuery
• Mirror Node REST API: List Account Balances
• Migrating from AccountBalanceQuery: What You Need to Know
• @hiero-ledger/sdk on npm

Introducing MirrorNodeAccountBalanceQuery: The SDK-Native Migration Path for AccountBalanceQuery was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Code Contribution to facilitate developer participation and experimentation with the new bridgeless cross-ledger protocol
• Hashgraph is also calling for participants to join the Cross-Ledger Early Adopter Program, which offers full access to a Hashgraph-hosted testnet environment for selected participants

24 September 2026 — Hedera has contributed CLPR (pronounced “clipper”), the bridgeless Cross-Ledger Protocol in development by Hashgraph, to Linux Foundation Decentralized Trust (LFDT) as a new lab.

Blockchain networks today largely operate as distinct ecosystems — each with its own consensus rules, token standards and execution environment. Assets issued on one ledger are generally unable to interact natively with another. Workarounds such as bridges and wrapped assets have emerged to address this fragmentation, but can introduce additional security risks, intermediaries and liquidity requirements. CLPR aims to address these challenges with a new approach to cross-ledger interoperability and, through LFDT Labs, is inviting the broader open-source developer community to help shape, test and advance the protocol.

“Cross-ledger interoperability is key to unlocking the flow of value across networks and platforms,” said Daniela Barbosa, General Manager, Decentralized Technologies, Linux Foundation, and Executive Director, LF Decentralized Trust. “As a new LFDT lab, CLPR will leverage open development to shape a protocol that fuels collaboration across the industry. With this contribution, Hedera is once again showing its commitment to vendor neutral, collaborative development of critical shared technologies.”

Bridgeless by design, CLPR uses state proofs to allow ledgers to verify each other’s states directly, with no intermediaries in between. Rather than working around the liquidity fragmentation problem with bridges and relayers, CLPR aims to end the “trapped liquidity era” altogether. It establishes cryptographic trust directly between ledgers so CLPR-enabled applications can move tokens, data, and messages freely and securely across networks without a bridge.

Now, as a LFDT lab, CLPR becomes an openly developed codebase. Developers can experiment with the CLPR codebase in the LFDT Labs GitHub repository and explore different use cases. This gives the project a structured path to grow: LFDT Labs enables participants to refine this early-stage work by building a community, inviting contributions and establishing momentum before a project reaches top-level LFDT project status.

Dr. Leemon Baird, Co-Founder at Hedera and Chief Scientist at Hashgraph, said: “Just weeks ago marked the two-year anniversary of Hedera’s establishment as a founding Premier Member of the Linux Foundation Decentralized Trust, donating the entirety of the Hedera codebase to LFDT as Project Hiero. That commitment to open collaboration is exactly what’s needed to solve one of the industry’s most persistent problems: network interoperability. When underpinning an application, CLPR is designed to fix that cryptographically so data, assets and messages move freely without a single point of failure to attack. Today’s announcement that Hedera is contributing another protocol to LFDT shows that our commitment is only growing, and we’re excited to see how developers experiment with CLPR’s capabilities.”

The contribution of CLPR to the LFDT ecosystem coincides with a call-out for participants to join Hashgraph’s Cross-Ledger Early Adopter Program. Involvement is welcomed from financial institutions, fintechs, asset issuers, liquidity providers, and corporations.

The program is structured to focus on three distinct use cases: Cross-border payments and in-flight FX, cross-ledger settlement, and collateral mobility. This 3-phased virtual program offers full access to a Hashgraph-hosted testnet environment, where participants can move real test assets safely using a CLPR-enabled application layer. Technical participants will also have access to an assigned integration expert to support their progress. The program aims to select participants from a range of countries in order to bake in cross-border regulatory and compliance considerations from the beginning.

To register interest and help shape the Cross-Ledger Early Adopter program ahead of its full market launch, visit hashgraph.com/clpr-early-adopter-program.

ENDS

Get Involved with CLPR

As an LFDT lab, CLPR is open to developers, researchers and organizations interested in exploring cross-ledger interoperability. Community members are invited to review the code, evaluate the protocol’s approach, propose use cases, open issues and contribute to its ongoing development.

CLPR LFDT Lab: LFDT-CLPR · GitHub

Source code: LFDT-CLPR repositories · GitHub

Contributing: GitHub — LFDT-CLPR/governance · GitHub

LFDT Labs: Labs — LF Decentralized Trust

Technical Meetup: An Architectural Deep Dive into New CLPR (Cross-Ledger Protocol) Lab

About Hedera

Hedera is the trust layer of the digital economy, providing fast, secure and efficient distributed ledger technology (DLT) powered by hashgraph technology. With an open-source ecosystem, predictable low-cost fees and carbon-negative operations, Hedera provides developers and organizations with infrastructure for building scalable decentralized applications with real-world impact.

Governed by a diverse council of leading global institutions, Hedera supports innovation across tokenization, AI, digital identity, DeFi and sustainable finance. In 2024, Hedera contributed its network codebase to Linux Foundation Decentralized Trust as Hiero, furthering its commitment to open-source development and community governance.

For more information, visit hedera.com

About Hashgraph

Hashgraph is an enterprise software firm powering the next generation of connected digital markets. The company develops solutions for financial services that leverage hashgraph technology and provides ongoing support to the Hedera public network. Through cross-ledger interoperability, private network infrastructure, and tokenization platforms, Hashgraph enables institutions to issue, trade, and manage assets seamlessly across systems, helping to drive a more connected digital economy.

For more information, visit hashgraph.com

Hedera Contributes Hashgraph-Developed CLPR to Linux Foundation Decentralized Trust Labs was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

Atomic Batch Transactions No Longer Support Smart Contract Calls was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Standfirst

The Scaffold-HBAR Template Bounty opens for registration on Monday September 14th. Build a production-quality template for a real Hedera use case. If it clears the eligibility gate it goes into the Hedera docs with your authorship credited, one command away from every developer starting on Hedera. Five prizes of $2,000 come from a $10,000 pool.

This post is the full brief: what to build, what gets scored, and how the two weeks run.

Register for the template bounty

What you are building

One public repository. A working scaffold-hbar template for a real Hedera use case, structured so that any developer can run one command and have it running locally:

npm create scaffold-hbar@latest --template your-org/your-repo

scaffold-hbar ships with eight built-in templates today. This bounty adds community-authored external templates alongside them. External templates run from any public GitHub repo, so there is no pull request into scaffold-hbar to get merged and nothing to wait on.

What the repository needs:

• A monorepo layout with separate packages/ for contracts and frontend
• A template.json manifest declaring capabilities and defaults. Optional in the docs, required here
• A README.md covering setup, and an AGENTS.md covering AI-assisted use
• At least one Hedera service genuinely in play: HTS, HCS, HSS, or a Solidity contract on Hedera
• One verifiable testnet transaction, evidenced by a mirror node or Hashscan link

The stack is Next.js with Hardhat or Foundry, npm or Yarn workspaces, on Node 20.18.3 or later.

On-chain validation needs a funded testnet account. Grab testnet HBAR from the Hedera Portal faucet before you start.

Which integrations count

Ecosystem integration carries 35 points, the largest single block in the rubric, so it is worth being clear about what that means.

An integration scores well when it is load-bearing: the template does something a developer could not easily build alone, and removing the integration would break the point of the template. An SDK imported and called once to tick a box scores low, as does a self-contained app with no ecosystem surface.

Examples ecosystem integrations:

• DEXes, including SaucerSwap, Lambdaplex and SilkSuite
• Oracles, including Chainlink, Supra and Pyth
• Bridges, including Axelar, LayerZero and CCIP
• Lending protocols and decentralised storage

Some ecosystem protocols have thin or no Hedera testnet deployments. Where testnet is unavailable, a read-only integration or a forked-mainnet integration is acceptable, so a missing testnet deployment is not a reason to abandon a good idea.

Why build one

Your template becomes the default starting point for a use case, reachable by one command from any terminal.

Templates that clear the eligibility gate are listed in the Hedera docs with your authorship credited, and that listing does not depend on winning a prize.

Documentation placement is permanent, so the template keeps sending developers, and traffic, back to your work long after the bounty closes.

Five prizes of $2,000 are available from a $10,000 pool for the highest-scoring submissions.

CTA: Register for the template bounty [registration landing page, URL TBC]

How it works

1. Register. Tell the Hedera DevRel team who you are. Takes two minutes.
2. Join the AMA. Walkthrough of the gate requirements, the rubric, Hedera Harness, and what a strong integration looks like, plus live questions.
3. Build during the two-week window. From September 21st to October 4th. Push to a public repo under an MIT licence.
4. Submit before October 4th closes. Repo link, a Hashscan or mirror node link proving a testnet transaction, the dev-ex survey, and your harness spec and validators if you used the harness.

Expanded authoring docs, an illustrative integrations list, and a self-check script for the eligibility gate all go live in the week before the build window opens.

Key dates

The eligibility gate

Judging runs in two stages. Stage one is a mechanical pass or fail, and every item is required. Nothing reaches the panel until it passes, so run the self-check script before submitting.

• Scaffolds cleanly via npm create scaffold-hbar@latest --template owner/repo
• template.json manifest present and valid
• README.md and AGENTS.md present
• Install, lint and build pass clean from a fresh scaffold
• App boots and core routes return OK
• At least one Hedera service in play, with a verifiable testnet transaction and a mirror node or Hashscan link supplied
• No committed secrets and no committed .env
• MIT licence, original work
• Harness spec and validators submitted, if the harness was used

Every template that clears this gate is listed in the docs with credited authorship, whether or not it places.

How templates are scored

Templates that clear the gate are scored out of 100 by the Hedera DevRel panel.

Build it fast with Hedera Harness

Hedera Harness gives an AI coding agent the context it needs to write working Hedera code: the service APIs, the patterns, and tiered validation. It is strongly recommended for this bounty and it is not required. Templates built without it are judged on exactly the same rubric.

If you use it, submit your harness spec and validators alongside the repo.

Link: github.com/hedera-dev/hedera-harness

Prizes and recognition

$10,000 in total, split as five equal prizes of $2,000, all decided by the panel on the rubric above.

Prizes go only to submissions that clear the eligibility gate. If three templates pass, three prizes are paid and the rest of the pool stays unallocated.

Every template that passes the gate is added to the external templates docs listing with credited authorship, independent of prizes. Winners additionally get a showcase and blog feature.

Questions

Who can enter?

Anyone. No gating, no application review. Existing Hedera experience helps, and the kickoff AMA covers what you need to know if this is your first Hedera build.

Can teams enter?

Yes. Register as a team and give the team size. A prize is a single $2,000 award per winning submission.

How many templates can one person submit?

Each submission is judged on its own. Focus usually scores better than volume, given how much weight the rubric puts on docs quality.

What counts as ecosystem integration?

DEXes, oracles, bridges, lending and storage protocols live in the Hedera ecosystem. The list on this page is illustrative, not a checklist. What matters is that the integration is load-bearing rather than decorative.

What if the protocol I want to integrate has no Hedera testnet deployment?

A read-only integration or a forked-mainnet integration is acceptable. Document the approach in your README.

Do I have to use Hedera Harness?

No. Templates built without it score on the same rubric. If you do use it, submit your harness spec and validators with the repo.

Does the use case have to be original?

The code has to be original work under an MIT licence. The use case does not have to be unheard of. A well-built template for a common pattern is more useful to developers than a novel one nobody needs.

What happens to the template after the bounty?

It stays yours. The docs listing points at your repository, credited to you, and you continue to maintain it.

Closing

Registration opens Monday September 14th and the build window runs September 21st to October 4th. Every template that clears the gate goes into the Hedera docs with your name on it.

Register for the template bounty

Scaffold-HBAR Template Bounty was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR

• Hedera Consensus Service (HCS) is a decentralized, tamper-resistant, fairly ordered event log.
• When HCS is used for what it does best: ordering events, anchoring state changes, and proving data integrity over time, it becomes one of the most valuable trust primitives on Hedera.
• HCS is not a decentralized database.
• If you treat HCS like a database, you will eventually run into painful limitations: no native query engine, no indexing, no easy joins, no simple “current state” lookup, and a lot of manual replay logic.

What HCS actually does

To use HCS, you create a topic and submit messages to it.

Each message submitted to that topic is ordered, timestamped, and finalized by the Hedera network. The result is a durable sequence of events that cannot be rewritten, reordered, or inserted into the past.

That gives developers strong guarantees:

• Messages are fairly ordered by the network.
• Each message receives a consensus timestamp.
• The log is append-only.
• Historical messages are tamper-resistant.
• Anyone can independently verify and replay the event history.

This makes HCS excellent for systems that need a shared, verifiable record of what happened and when.

But it does not make HCS a database.

HCS does not maintain application state for you. It does not index your data, understand relationships between messages, or give you a built-in query layer. If you want to know the current state of an entity, you need to reconstruct that state from the ordered message history.

That is the key architectural difference.

Is HCS a database?

No. HCS is a decentralized, tamper-resistant, fairly ordered event log. Every message submitted to an HCS topic gets a consensus timestamp and a permanent position in an append-only sequence, but HCS does not index that data, understand relationships between messages, or offer a built-in query layer. To know an entity’s current state, you have to reconstruct it by replaying the ordered message history.

Where HCS is strongest

HCS is strongest when it is used as an ordering, provenance, and verification layer. It is ideal for recording that something happened, when it happened, and in what order relative to other events. That makes it valuable for a wide range of systems.

Event sourcing and state transition logs

HCS works well when messages represent state transitions:

• Account credited
• Order created
• Document updated
• Model inference completed
• File hash anchored
• Verification result submitted
• Registry entry changed

In this pattern, HCS is not storing the full application database. It is storing the ordered event history that allows state to be verified or reconstructed.

HCS-20 is a useful example of this model. It uses ordered messages to represent point transactions, allowing balances to be deterministically reconstructed from the message history. The important detail is that the state is derived from the event log; HCS is not acting as a queryable balance database.

Deterministic state reconstruction

Because HCS messages are ordered, multiple parties can replay the same sequence of events and arrive at the same result, assuming they use the same rules.

That is valuable for systems that require independent verification. You can build applications where users, auditors, indexers, or counterparties can verify the state transition history without trusting a single centralized operator. But at production scale, this requires indexing, caching, snapshots, or projections. Otherwise, reconstruction becomes too slow for normal application reads.

Fair ordering of external events

Many systems do not just need to know what happened. They need to know the order in which things happened.

HCS is useful when external events need to be sequenced into a shared, neutral timeline.

Examples include:

• AI execution logs
• Supply chain events
• Compliance attestations
• Multi-party workflows
• Financial process checkpoints
• Agent coordination records
• Cross-system audit trails

In these cases, the value is not that HCS stores every piece of data. The value is that HCS provides a shared ordering and timestamping layer that different parties can trust.

Provenance streams for datasets

A topic can act as a provenance stream for a specific dataset, process, model, or workflow.

For example:

• One topic for changes to a compliance dataset
• One topic for updates to an AI model registry
• One topic for inference execution records
• One topic for document state changes
• One topic for supply chain custody events

The topic becomes the historical record of what changed over time. The actual data can live somewhere else. HCS records the proof (hashes of that content’s state) that the data existed, changed, or was approved at a specific point in time.

The better architecture: HCS plus external storage and indexing

The most effective architecture is not “put everything on HCS.”

The better architecture is:

1. Store large or queryable data in the right external system.
2. Submit hashes, references, state transitions, or compact events to HCS.
3. Use indexers to process HCS messages into a queryable format.
4. Query the external database or index for application performance.
5. Use HCS as the immutable trust record.

Your application gets fast reads, search, filtering, relationships, and analytics from a real database or indexer. Your users, auditors, or counterparties get a tamper-resistant, fairly ordered proof trail from HCS. That is where HCS earns its place.

How should HCS and a database work together in production?

Store large or queryable data in the right external system, and submit only hashes, references, or compact state-transition events to HCS. An indexer processes those HCS messages into a queryable format, so your application queries the database, not HCS directly. That gives you fast reads, search, filtering, relationships, and analytics from a real database or indexer, while HCS stays the immutable trust record, providing a tamper-resistant, fairly ordered proof trail underneath it.

Go deeper: the Mirror Node REST API is how you build the indexing layer this pattern depends on. Start there if you’re implementing this today.

One more thing: the fee structure

In January 2026, the base ConsensusSubmitMessage transaction fee increased from $0.0001 to $0.0008. If you’re using HCS as a query mechanism (firing writes just to derive reads), this changes your unit economics significantly.

HCS is often misunderstood

HCS is sometimes described as a trust layer for applications. That description is accurate, but it can also lead developers toward the wrong architecture.

When people hear “trust layer,” they often assume HCS should be where application data lives. They imagine it as the source of truth that an application can query directly whenever it needs information. That mental model is understandable, but incomplete.

HCS can be an authoritative source of truth, but it is not a queryable database. It does not behave like Postgres or BigQuery. It does not give you a native way to ask:

• What is the current value?
• Give me all records matching this field.
• Join these two datasets.
• Return the latest state for this user.
• Search this topic for a specific object.

Instead, HCS gives you something different and more specific: an ordered stream of messages that can be independently verified and replayed. That is powerful, but only when the architecture is designed around that strength.

Where the database model breaks down

The biggest issue with using HCS as a database is that reads become a reconstruction problem.

In a normal database, you ask for the current value and the database returns it. With HCS, you often need to retrieve messages, parse them, replay them in order, apply your own state transition logic, and derive the answer yourself. That can work at small scale.

A topic with 50 messages is easy to replay. A simple prototype may feel fast enough. The problem appears later, when that same topic grows to 50,000, 500,000, or millions of messages.

The architecture that felt simple during a prototype can become slow, expensive, and difficult to maintain in production.

HCS data has no native query engine

There is no built-in equivalent of SELECT, WHERE, ORDER BY, or JOIN.

If you want all messages where type = “transfer”, your application or indexer has to fetch the relevant message stream, parse the payloads, and filter them itself. HCS stores ordered messages. It does not provide a general-purpose data access layer.

State has to be reconstructed manually

HCS messages are immutable. That is a feature, not a flaw. But it means there is no native “update this row” operation. Instead, each message represents an event or state transition. To determine current state, you need to replay the relevant messages in sequence and apply the rules of your application.

This is the same basic model used in event sourcing, but event-sourced systems typically depend on snapshots, projections, and indexes to make reads efficient. Without that supporting infrastructure, every read can become unnecessarily expensive.

Selective retrieval can become slow

If your application needs to find one specific record inside a large topic, HCS does not automatically give you a fast lookup path.

You can build or use mirror-node-based infrastructure, indexers, or custom projections to improve retrieval. But at that point, you are no longer using HCS as the database. You are using HCS as the ordered event source and another system as the query layer.

That is the right pattern.

Relationships across topics are difficult

Relational databases are designed to connect data. HCS topics are not. If you model one topic as “users” and another topic as “orders,” then trying to answer questions across both topics requires replaying and correlating messages yourself, usually in an external system. That adds complexity quickly.

The more your application needs relationships, joins, search, filtering, or analytics, the more obvious it becomes that HCS should not be the primary database.

Developer experience becomes harder at scale

When something goes wrong in a database-backed application, developers can inspect rows, query tables, review indexes, and debug state directly. When something goes wrong in an HCS-as-database architecture, developers often have to debug replay logic, ordering assumptions, partial indexing, message parsing, and derived state.

That is a much harder developer experience. This does not mean HCS is bad. It means it is being asked to solve the wrong problem.

What happens if I treat HCS like a queryable database?

Reads become a reconstruction problem. Instead of asking a database for the current value, you retrieve messages, parse them, replay them in order, apply your own state transition logic, and derive the answer yourself. A topic with 50 messages is easy to replay, but the same approach at 50,000 or millions of messages becomes slow, expensive, and difficult to maintain in production.

Closing: the mental model shift

The simplest way to think about HCS is this: HCS is not where your application stores data so it can be queried later. HCS is where your application records what happened so it can be trusted later. That distinction should shape the architecture.

Reach for HCS when you need fair ordering, trusted timestamps, tamper-resistant event history, independent verification, auditability, provenance, deterministic replay, or shared truth between parties.

Pair it with an index or a database when you need search, joins, relational queries, high-speed reads, mutable records, large file storage, or analytics.

Those are database and indexing problems. HCS solves the trust problem.

Try it on testnet: write ten state transitions to a topic, then rebuild the current state from the mirror node REST API and compare it against what your application believes. If they agree, you have the pattern.

Ty Smith is a Sr. Product Manager at Hashgraph and Hedera. He has spent years building on HCS and is a contributor to the HCS-1, HCS-2, HCS-14, HCS-16, and HCS-20 standards. Find him on X at @TMCC_Patches. All opinions are his own.

How to unlock the full potential of HCS (and why it is not a database) was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The growth of Hedera Council’s network of Strategic and Community Partners continues, with the addition of two new partnerships. This partnership program leverages the skills, networks and resources of industry leaders to drive real-world adoption of Hedera.

Hedera Council’s latest collaborations expand Hedera’s capabilities for secure, decentralized infrastructure for real-world use cases, while enhancing Hedera’s technical offerings. Hedera’s latest Strategic Partner is WISeKey, a global expert in cybersecurity, digital identity and IoT solutions. As Hedera’s fourth Strategic Partner, WISeKey joins the Global Blockchain Business Council, Halborn and the Institutes RiskStream Collaborative.

Accelerating Authentication and Digital ID on Hedera

Based in Switzerland, WISeKey is strongly embedded in Web3 infrastructure, offering secure authentication and identification solutions for IoT, blockchain and AI. SEALCOIN AG, one of WISeKey’s established subsidiaries, focuses on the development of the SEALCOIN platform, which enables the autonomous exchange of verified, high value data secured by post-quantum cryptography.

“Becoming a Strategic Partner of the Hedera Council reinforces WISeKey’s commitment to building trusted infrastructure for an increasingly connected and autonomous world,” said Carlos Moreira, Founder and CEO of WISeKey Group.

“By combining WISeKey’s expertise in digital identity, cybersecurity, PQC-secure semiconductors and space-based IoT with Hedera’s enterprise-grade distributed ledger technology, we can accelerate the deployment of trusted digital ecosystems where devices, machines and organizations can identify, authenticate and transact securely at global scale. This partnership is an important step in turning decentralized technologies into real-world infrastructure for the digital economy.”

This strategic partnership builds on an existing use case in the Hedera ecosystem. Earlier this year, the Hashgraph Group launched the QAIT Q-Day Security Assessment Platform on the SEALCOIN Quantum Marketplace. The platform was designed to help enterprises, governments and critical infrastructure operators evaluate, monitor and mitigate cybersecurity risks associated with the emergence of quantum computing.

Jonathan Llamas, Chief Product and Strategy Officer at SEALCOIN AG, added: “SEALCOIN was created around a simple premise: billions of connected devices and autonomous machines will increasingly need to transact with each other without sacrificing identity, security or trust. Hedera has been an active contributor to this vision, with a dedicated team of experts from its ecosystem working alongside us in the development of the SEALCOIN platform. By combining trusted device identity with Hedera’s scalable distributed infrastructure, we are building the foundations for machines to authenticate, exchange value and transact autonomously at global scale. This Strategic Partnership is a natural continuation of that collaboration and an important step toward making trusted machine-to-machine commerce a reality.”

Expanding Reach in Latin America

Hedera Council also proudly welcomes its eighth community partner, SpaceDev. The Council’s Community Partners bring strong ecosystem alignment and active participation, while driving adoption and awareness. SpaceDev is a Latin American software company, which has previously leveraged Hedera for its Blockchain for Energy (B4E) platform. This turned carbon-capture initiatives into auditable on-chain assets, replacing manual, error-prone workflows with a standardized, automated pipeline.

As the Council’s newest Community Partner, SpaceDev brings its expertise in delivering digital products that offer secure, real-world solutions. Previously, SpaceDev has created software for platforms including Tether, WalletConnect, Rarible and UFCStrike, among many others.

Currently ranked №2 among Clutch’s top blockchain companies, SpaceDev combines global reach with strong regional roots. Beyond its client work, the company supports the growth of Uruguay and Latin America’s blockchain landscape through educational programs, community events, and social initiatives that broaden access to technology.

Juan Manuel Sobral, CTO and co-founder of SpaceDev and President of the Blockchain Chamber of Uruguay, said: “Joining the Hedera Council Community Partner Program feels like a natural milestone in a story SpaceDev has been writing for years. We grew from Uruguay with the conviction that world-class technology can be created in Latin America, and that technical excellence becomes even more meaningful when it’s shared through education, community, and new opportunities. This recognition belongs to the talented people behind SpaceDev, as well as the clients and partners who have trusted us to bring ambitious ideas to life.”

To learn more about the Hedera Council partnership program, visit hederacouncil.org.

Hedera Council Grows Partner Network with New Strategic and Community Partners was originally published in Hedera Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.