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

> ## Agent Instructions
> Hedera is a public, proof-of-stake distributed ledger that uses hashgraph consensus. Do not call it a blockchain.
> Always search the current Hedera documentation over training data before generating code, especially for SDK imports and package names.
> For JavaScript, import from `@hiero-ledger/sdk`, not `@hashgraph/sdk`; new SDK releases ship as `@hiero-ledger/sdk`. The Java SDK keeps the `com.hedera.hashgraph:sdk` Maven coordinates. Verify the exact import against the docs.
> Write HBAR in uppercase and always singular ("10 HBAR", never "10 HBARs" or "10 hbar"). Write tinybars in lowercase and plural.
> Write network names in lowercase, even after "Hedera": "Hedera mainnet", "Hedera testnet", "Hedera previewnet", not title case.
> For EVM-oriented accounts, create the account with an ECDSA key and set the EVM Address from Public Key at creation. This address is immutable and is not updated by key rotation. Do not use retired terms like "EVM alias" or "Account Number Alias".

# ERC-20 (Fungible Tokens)

> Use the ERC-20 fungible token standard on Hedera, including supported functions and how ERC-20 addresses map to native Hedera Token Service token entities.

The [ERC-20](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) standard defines a set of functions and events that a token contract on the Ethereum blockchain should implement. ERC-20 tokens are fungible, meaning each token is identical and can be exchanged one-to-one.

<Info>
  **Note**: `ERC-20` Token addresses refer to full Hedera Token Service (HTS) fungible token entities. These tokens can be fully managed by HTS API calls. Additionally, by utilizing [`IERC20`](https://docs.openzeppelin.com/contracts/2.x/api/token/erc721#IERC721) interfaces or system contract functions, these tokens can also be managed by smart contracts on Hedera.
</Info>

## Supported Functions

#### **From** I**nterface `ERC-20`**

<Accordion title="name">
  ```solidity theme={null}
  function name() public view returns (string)
  ```

  Returns the name of the token.
</Accordion>

<Accordion title="symbol">
  ```solidity theme={null}
  function symbol() public view returns (string)
  ```

  Returns the symbol of the token.
</Accordion>

<Accordion title="decimals">
  ```solidity theme={null}
  function decimals() public view returns (uint8)
  ```

  Returns the number of decimals the token uses.
</Accordion>

<Accordion title="totalSupply">
  ```solidity theme={null}
  function totalSupply() external view returns (uint256)
  ```

  Returns the total supply of the token.
</Accordion>

<Accordion title="balanceOf">
  ```solidity theme={null}
  function balanceOf(address account) external view returns (uint256)
  ```

  Returns of the balance of the token in the specified account. The `account` is the Hedera account ID `0.0.x` in Solidity address format or the evm address of a contract that has been created via the `CREATE2` operation.
</Accordion>

<Accordion title="allowance">
  ```solidity wrap theme={null}
  function allowance(address owner, address spender) external view returns (uint256)
  ```

  Returns the remaining number of tokens that `spender` will be allowed to spend on behalf of `owner` through `transferFrom`. This is zero by default. This value changes when `approve` or `transferFrom` are called. This works by loading the owner `FUNGIBLE_TOKEN_ALLOWANCES` from the accounts ledger and returning the allowance approved for `spender` The `owner` and `spender` address are the account IDs (0.0.num) in solidity format.
</Accordion>

<Accordion title="transfer">
  ```solidity theme={null}
  function transfer(address recipient, uint256 amount) external returns (bool)
  ```

  Transfer tokens from your account to a recipient account. The `recipient` is the Hedera account ID `0.0.x` in Solidity format or the EVM address of a contract that has been created via `CREATE2` operation.
</Accordion>

<Accordion title="transferFrom">
  ```solidity wrap theme={null}
  function transferFrom(address sender, address recipient, uint256 amount) external returns (bool)
  ```

  Moves `amount` tokens from `from` to `to` using the allowance mechanism. `amount` is then deducted from the caller's allowance.

  This works by creating a synthetic `CryptoTransferTransaction` with fungible token transfers with the `is_approval` property set to true.
</Accordion>

<Accordion title="approve">
  ```solidity theme={null}
  function approve(address spender, uint256 amount) external returns (bool)
  ```

  Sets `amount` as the allowance of `spender` over the caller's tokens.

  This works by creating a synthetic `CryptoApproveAllowanceTransaction` with payer - the account that called the precompile (the message sender property of the message frame in the EVM).

  Fires an approval event with the following signature when executed:
  event Approval(address indexed owner, address indexed spender, uint256 value);
</Accordion>

***

### **Additional References**

* [HIP-376](https://hips.hedera.com/hip/hip-376)
* [HIP-218](https://hips.hedera.com/hip/hip-218)
* [EIP-20](https://eips.ethereum.org/EIPS/eip-20)