Skip to main content
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:

​
Address formats

Hedera supports two address formats: DFNS wallets have both formats - the native address is assigned when the account is created on-chain.

​
Account creation

Hedera accounts must exist on-chain before they can receive assets. Account creation happens:
  1. Automatically: When you send HBAR to a new EVM address with sufficient amount to cover creation fees
  2. 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: Example query to get native account ID from EVM address:

​
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.
Last modified on June 12, 2026