A reference architecture for enterprise applications on Hedera

Every Hedera transaction is paid for by an account and authorized by signatures that satisfy the keys involved: the payer, and any account, token or topic key the transaction touches. Keys can be single keys, key lists or nested threshold structures, and ECDSA secp256k1 is the recommended type for new accounts⁶.

Separate the signing service from the business application for three reasons. Policy lives in one place, so the rule that a mint above a threshold needs a second approver is enforced before any signature exists. Key material stays inside an HSM or KMS boundary that the application never sees. And every signature produces an audit event that can later be matched with the network's own record.

Use different payer accounts for different workloads. A dedicated fee account per application, funded by treasury with alerts on low balance, keeps one runaway integration from draining the HBAR that every other flow depends on.

A Hedera transaction ID combines the paying account with the transaction's valid start time, and the network uses it to detect duplicate submissions¹. That makes it a natural idempotency key: generate it once, persist it with the business event before submitting, and resubmit the same signed bytes when a call times out. A fresh ID on retry is how one payment becomes two.

Transactions are valid for a window of up to 180 seconds from their valid start; if consensus is not reached inside it, the transaction expires and must be rebuilt and re-signed¹. Receipts are free and records carry the fuller outcome, but the network keeps both for only a short period, so long-term evidence should come from mirror nodes¹². Retry logic therefore has three branches: resubmit unchanged while the window is open, rebuild after expiry, and stop for a person when the status is a business failure rather than a transport one.

All network services are throttled, on previewnet, testnet and mainnet alike⁷. Treat a throttling response as back-pressure: back off, keep the queue in the orchestration layer and alert when it grows, rather than letting each caller retry independently.

Consensus nodes process transactions; mirror nodes store history and answer queries, without taking part in consensus, and anyone can run one². Hedera hosts public REST and gRPC mirror endpoints, but describes the mainnet one as non-production and rate-limits it per IP address, pointing production users to commercial providers or their own deployment³.

For most enterprises the choice is between a commercial mirror provider and a self-run node. A provider is faster to adopt; a self-run node gives you control over retention, query patterns and data residency, at the cost of storage and operations. Either way, abstract the read path behind your own interface so you can switch, and reconcile network state against the internal store on a schedule. The accounting side of that reconciliation is covered in reconciling Hedera transactions with your ERP.