> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Hedera

> Network-specific features, signature kinds, supported assets, and integration requirements for Hedera wallets on the DFNS platform.

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:

| Format    | Example         | Description                      |
| --------- | --------------- | -------------------------------- |
| Native    | `0.0.123456`    | Shard.Realm.AccountNumber format |
| EVM alias | `0x1234...abcd` | EVM-compatible address           |

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

<Note>
  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.
</Note>

### 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.

```mermaid theme={null}
flowchart LR

    A[Wallet created on DFNS] --> |EVM address creation| B[EVM alias only]
    B --> |Account created| C[Native address]
    C --> |Creation event indexed| D[DFNS indexes updates]


```

<Tip>
  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.
</Tip>

## Transfers

Use the [Transfer Asset](/api-reference/wallets/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](/api-reference/wallets/sign-and-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 |

Example query to get native account ID from EVM address:

```
GET https://mainnet-public.mirrornode.hedera.com/api/v1/accounts/{evmAddress}
```

## Smart contracts

Hedera supports EVM-compatible smart contracts. Use the [Broadcast Transaction](/api-reference/wallets/sign-and-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](https://docs.hedera.com/hedera/sdks-and-apis/sdks). See the [Hedera integration example](https://github.com/dfns/dfns-sdk-ts/blob/m/examples/libs/hedera/basic-tx/main.ts).

## Related resources

* [Hedera broadcast examples](/api-reference/broadcast/hedera)
* [Hedera signing examples](/api-reference/sign/hedera)
* [Supported networks](/networks)
* [Hedera documentation](https://docs.hedera.com/)