Hedera is an enterprise-grade public network using hashgraph consensus. This guide covers Hedera-specific features when using DFNS wallets.
Account model
Hedera uses an account-based model with unique characteristics:
Hedera supports two address formats:
| Format | Example | Description |
|---|
| Native | 0.0.123456 | Shard.Realm.AccountNumber format |
| EVM alias | 0x1234...abcd | EVM-compatible address |
Account creation
Hedera accounts must exist on-chain before they can receive assets. Account creation happens:
- Automatically: When you send HBAR to a new EVM address with sufficient amount to cover creation fees
- Via broadcast: Using the
AccountCreate transaction type
When sending to an EVM address, Hedera auto-creates the account if it doesn’t exist. The creation fee is deducted from the transfer amount.
Address assignment
When a DFNS wallet is created, it initially only has an EVM alias. Once the account is created on-chain, Hedera assigns a native address (0.0.xxx). DFNS automatically indexes account creation events and updates the wallet’s address.
A single Hedera transaction can trigger child transactions (e.g., account creation when sending to a new address). DFNS indexes these child transactions and reflects them in the transaction history.
Transfers
Use the Transfer Asset endpoint for all Hedera transfers:
- Native HBAR: Use
kind: Native with amount in tinybars (1 HBAR = 100,000,000 tinybars). Supports native addresses (0.0.123456) or EVM addresses.
- HTS tokens: Use
kind: Hts with the token’s tokenId
- HIP-17 NFTs: Use
kind: Hip17 with the token’s tokenId and serialNumber
All transfer types support an optional memo field.
Token association
Before receiving HTS tokens, an account must associate with the token. This is similar to opt-in on other networks.
Use the Broadcast Transaction endpoint with kind: TokenAssociate to associate with tokens.
Token admin operations
Token admin operations (TOKENWIPE, TOKENBURN, TOKENMINT) appear in wallet history when they affect your wallet’s token balance:
- TOKENWIPE / TOKENBURN: outgoing-only movements — tokens are wiped from or burned by the wallet, with no receiving counterparty.
- TOKENMINT: incoming-only movements — newly minted tokens are credited to the wallet, with no sending counterparty.
These differ from standard HTS transfers, which have both a sender and a receiver.
Address conversion
To convert between address formats:
| From | To | Method |
|---|
| EVM address | Native ID | Query Mirror Node API |
| Native ID | EVM address | Derive from public key |
GET https://mainnet-public.mirrornode.hedera.com/api/v1/accounts/{evmAddress}
Smart contracts
Hedera supports EVM-compatible smart contracts. Use the Broadcast Transaction endpoint with kind: Evm to interact with contracts.
EVM-based ERC-20 and ERC-721 token transfers resulting from these interactions are reflected in wallet history under the HederaErc20Transfer and HederaErc721Transfer kinds, distinct from native HtsTransfer and Hip17Transfer token transfers.
Transaction expiration
DFNS builds native Hedera transactions with a 3-minute expiration: the transaction must be broadcast within 3 minutes of being built, otherwise it expires and must be rebuilt and re-signed. This applies to all native Hedera transactions, including transfers, and gives this much time to sign and broadcast even if the signing infrastructure is temporarily unavailable (for example an unreachable on-prem signer). Transactions submitted as EVM calls through the JSON-RPC relayer do not expire.
SDK integration
For full transaction control, use the DFNS SDK with @hashgraph/sdk. See the Hedera integration example.
