diff --git a/docs.json b/docs.json index b77bfbda..4ceb469f 100644 --- a/docs.json +++ b/docs.json @@ -62,16 +62,16 @@ }, "fonts": { "heading": { - "family": "Styrene A", - "source": "/public/fonts/styrene/StyreneA-Regular-Web.woff2", + "family": "Styrene A Medium", + "source": "/public/fonts/styrene/StyreneA-Medium-Web.woff2", "format": "woff2", - "weight": 400 + "weight": 700 }, "body": { - "family": "Styrene A", - "source": "/public/fonts/styrene/StyreneA-Regular-Web.woff2", + "family": "Styrene Light Web", + "source": "/public/fonts/styrene/StyreneA-Light-Web.woff2", "format": "woff2", - "weight": 400 + "weight": 500 } }, "background": { @@ -90,7 +90,9 @@ "perplexity", "mcp", "cursor", - "vscode" + "vscode", + "add-mcp", + "grok" ] }, "integrations": { @@ -332,7 +334,8 @@ "hedera/core-concepts/accounts", "hedera/core-concepts/accounts/account-creation", "hedera/core-concepts/accounts/auto-account-creation", - "hedera/core-concepts/accounts/account-properties" + "hedera/core-concepts/accounts/account-properties", + "hedera/core-concepts/accounts/network-accounts" ] }, "hedera/core-concepts/keys-and-signatures", diff --git a/hedera/core-concepts/accounts.mdx b/hedera/core-concepts/accounts.mdx index 394d902f..ef2817d1 100644 --- a/hedera/core-concepts/accounts.mdx +++ b/hedera/core-concepts/accounts.mdx @@ -27,7 +27,7 @@ You interact with the network by submitting transactions that modify the ledger' > -## FAQ +## FAQs @@ -53,3 +53,4 @@ A Hedera account is a unique entity in the Hedera Network that can hold tokens. If an account is created with an [EVM address](/hedera/core-concepts/accounts/auto-account-creation#evm-address) via [Auto Account Creation](/hedera/core-concepts/accounts/auto-account-creation), it results in a "hollow" account. This account has an account number and alias but no account key. It can accept token transfers but cannot transfer tokens or modify account properties until the account key has been added, completing the account. + diff --git a/hedera/core-concepts/accounts/network-accounts.mdx b/hedera/core-concepts/accounts/network-accounts.mdx new file mode 100644 index 00000000..2a3a82c9 --- /dev/null +++ b/hedera/core-concepts/accounts/network-accounts.mdx @@ -0,0 +1,32 @@ +--- +title: "Network Accounts" +--- + +The Hedera network uses several special, network-controlled accounts for its operations. These accounts are fundamental to the network's fee structure, staking rewards, and overall economic model. + +### Special Accounts Comparison + +| Account ID | Name | Purpose | Accepts Deposits? | Has Keys? | +| :--- | :--- | :--- | :--- | :--- | +| `0.0.98` | Network Admin Fee Account | Receives the majority of network transaction fees (typically 80%). | Yes | Yes | +| `0.0.800` | Staking Rewards Account | Holds funds for staking reward distribution. Receives a portion of daily fees (typically 10%). | Yes (donations) | No | +| `0.0.801` | Node Rewards Account | Holds funds for node reward distribution. Receives a portion of daily fees (typically 10%). | No | No | +| `0.0.802` | Fee Collection Account | Consolidates all transaction fees before daily distribution. | No | No | + +### Account Details + +#### Fee Collection Account (`0.0.802`) + +Introduced in [HIP-1259](https://hips.hedera.com/hip/hip-1259), this account serves as a temporary holding account for all transaction fees. It is fully code-controlled, has no keys, and cannot accept HBAR deposits from users. This design simplifies transaction records and improves network efficiency. + +#### Staking Rewards Account (`0.0.800`) + +This account holds the HBAR that will be distributed to users who are staking their tokens. It receives a portion of the daily accumulated fees from the Fee Collection Account. While it does not have keys, it can accept HBAR donations from the community. + +#### Node Rewards Account (`0.0.801`) + +This account holds the HBAR that will be distributed to node operators for their services. It receives a portion of the daily accumulated fees from the Fee Collection Account. It does not have keys and cannot accept HBAR deposits. + +#### Network Admin Fee Account (`0.0.98`) + +This account receives the largest portion of the daily accumulated fees from the Fee Collection Account (typically 80%). These funds are used to support the long-term growth and development of the Hedera network. Unlike the other special fee accounts, this account has keys and can accept HBAR deposits. diff --git a/hedera/core-concepts/mirror-nodes.mdx b/hedera/core-concepts/mirror-nodes.mdx index f4ff6251..af484f59 100644 --- a/hedera/core-concepts/mirror-nodes.mdx +++ b/hedera/core-concepts/mirror-nodes.mdx @@ -33,6 +33,40 @@ Once a record file is closed, the consensus nodes generate a signature file. The Hedera consensus nodes push new record files and signature files to the cloud storage provider – currently AWS S3 and Google File Storage are supported. Mirror nodes download these files, verify their signatures based on their hashes, and only then make them available to be processed. + +## Understanding Block Streams After [`HIP-1259`](https://hips.hedera.com/hip/hip-1259) + +For Mirror Node and [block stream](/hedera/support-and-community/glossary#block-stream) consumers, [HIP-1259](https://hips.hedera.com/hip/hip-1259) significantly simplifies the data related to transaction fees, leading to smaller block stream files and reduced data ingestion costs. + +### Simplified Fee Structure + +The primary change is the consolidation of all transaction fees into a single transfer to the **Fee Collection Account (`0.0.802`)**. + +- **Before HIP-1259:** Each transaction record contained multiple fee-related transfers, increasing the size and complexity of the block stream. +- **After HIP-1259:** Each transaction record now contains only a single, clear fee transfer to `0.0.802`. This reduces the amount of data per transaction, making block streams more efficient. + +### The Daily Synthetic Transaction + +A new pattern to be aware of is the **daily synthetic distribution transaction**. This is a network-generated transaction that occurs once per day at the end of each staking period. It is responsible for distributing the fees accumulated in `0.0.802`. + +As a block stream consumer, you can identify this transaction by the following characteristics: + +- It will contain a single large debit from account `0.0.802`. +- It will have a long list of credit transfers to node operator accounts, the staking rewards account (`0.0.800`), the node rewards account (`0.0.801`), and the network treasury (`0.0.98`). +- It appears in the block stream like any other transaction. + + + This synthetic transaction is the **only** time you will see funds being transferred out of the [Fee Collection Account](/hedera/support-and-community/glossary#fee-collection-account). All other transactions involving [`0.0.802`](https://hashscan.io/mainnet/account/0.0.802) will be credit transfers into the account. + + +### Benefits for Mirror Node Operators + +- **Reduced Storage Costs:** Smaller block stream files mean lower storage requirements for running a mirror node. +- **Faster Data Ingestion:** Simpler transaction records can be processed more quickly, improving the speed of data ingestion and synchronization. +- **Easier Data Analysis:** The fee structure is more straightforward, making it easier to analyze transaction costs and network revenue. + + + ### Smart Contract Synthetic Logs Starting with [v0.79](/hedera/networks/release-notes/mirror-node#v0.79) of Hedera Mirror Node release, synthetic event logs for Hedera Token Service (HTS) token transactions have been introduced to mimic the behavior of smart contract tokens. Synthetic events are generated for transactions such as: diff --git a/hedera/core-concepts/staking/staking.mdx b/hedera/core-concepts/staking/staking.mdx index 55f42ad0..6c61588c 100644 --- a/hedera/core-concepts/staking/staking.mdx +++ b/hedera/core-concepts/staking/staking.mdx @@ -2,75 +2,61 @@ title: "Staking Program" --- +The Hedera staking program allows you to earn rewards by staking your HBAR to a network node. Staking helps secure the network by contributing to the node's consensus weight (voting power). -The staking feature will be rolled out in four phases. The first two phases are described below, and the final two phases will be available at the start of Phase I. +## Staking Nodes -## **Phase I: Technical Availability \[Complete]** +All consensus nodes run by the Hedera Council distribute rewards to the accounts staked to them. You can find information about each node by visiting a Hedera network explorer or by getting the network [address book](/hedera/sdks-and-apis/rest-api#api-v1-network-nodes). -The staking functionality is now available and live on both the Hedera Testnet and Mainnet as of July 21, 2022. In phase I, users will technically be able to stake their account to mainnet nodes but this will not contribute to a node’s consensus weight (voting power). This initial technical availability release does not reward participants for staking but enables a level playing field whereby all market participants have the possibility to join the staking program and avoids giving an unfair advantage to the first few who stake. +Nodes have a minimum stake and maximum stake. The node's **minimum stake is $0**, meaning there is no minimum HBAR amount required for a node to be eligible for rewards. However, staked HBAR that exceeds the maximum stake does not increase the proportion of rewards returned. The maximum stake for each node is the total number of HBAR divided by the total number of nodes, and this value changes as more nodes join the network. +## Lockup Period -## **Phase II: Ecosystem Development \[Complete]** +There is **no lock-up period** when you stake your account. Your account's entire balance is automatically staked to the selected node or account, and your HBAR remains liquid at all times. There is no "bonding" or "slashing." -During this phase, supported exchanges and wallets will be able to integrate the staking functionality to provide account holders an easy way to stake their HBAR, but will not distribute rewards. In addition, web applications for delegating stake will likely be built for utilization by the retail ecosystem. During this phase, there will be visibility of stake per node, and staking to a node will affect its consensus weight (voting power) with monthly updates. +## Staking Reward Account -## **Phase III: Staking Rewards Program Launch \[Complete]** +The staking reward account [(`0.0.800`)](https://hashscan.io/#/mainnet/account/0.0.800) distributes rewards to eligible staked accounts. Its primary funding comes from the daily distribution from the [Fee Collection Account](/hedera/support-and-community/glossary#fee-collection-account) [(`0.0.802`)](https://hashscan.io/mainnet/account/0.0.802). -The Hedera Council will determine when the Hedera ecosystem has reached a minimum viable set of integrations to enable staking rewards. Once this is determined, the council (through CoinCom) will vote to update the reward rate, and subsequently, the mainnet will be updated with the agreed-upon reward rate. The latest staking reward rate voted on by CoinComm can be found [here](https://hedera.com/blog/hedera-governing-council-votes-to-approve-changes-to-staking-algorithm). +Anyone in the community can also contribute to the rewards pool by transferring HBAR into this account. This account has no keys; any HBAR transferred into it cannot be returned. -Once updated, the staking reward account (0.0.800) will be eligible to distribute rewards earned by stakers, once the rewards threshold of 250M total HBAR has been met. Rewards will continue to be distributed even if, after this time, the balance of account 0.0.800 goes below 250M. +The account must meet a minimum balance before rewards can be distributed. Once this threshold is met, rewards will continue to be paid out as long as there is a balance in the account. -## Phase IV: Complete Staking Implementation +### Staking Rewards -In this phase, 24-hour updates will be released for visibility into the stake per node, and the node uptime feature will be released. This means that instead of updating node stake visibility on a monthly basis, node stake visibility will be updated on a 24-hour epoch interval. When the uptime feature takes effect, staked accounts will not earn rewards when nodes cannot participate in consensus (unavailable or offline). +To be eligible for rewards, your account must be staked for a minimum of **one full staking period (24 hours)**, which begins and ends at midnight UTC. -## **Staking Nodes** +For a staked account to earn rewards, the following must be true: - -The Hedera Council voted to change the min stake value from half of the max node stake value to 1/4 of the max node stake value. - - -All consensus nodes run by the Hedera Council distribute rewards to the accounts staked to them. You can find information about each node in the network by visiting one of the Hedera network explorers or getting the network [address book](/hedera/sdks-and-apis/rest-api#api-v1-network-nodes). In the future, network participation will open up to community nodes and eventually to the public as part of Hedera’s decentralization efforts. - -Nodes have a **minimum stake** and **maximum stake**. The node's minimum stake must be met for the accounts staked to that node to be eligible to earn staking rewards. Staked tokens that go over the maximum stake will no longer impact the proportion of rewards returned. The maximum stake threshold for each node will be the total number of HBAR divided by the total number of nodes in the network. The minimum node stake threshold value will be 1/4 of the maximum node stake value. These values will change as more nodes are added to the network or can change by vote of the Hedera Council. - -#### Example: - -Minimum Stake: ​50,000,000,000 hbars\*(1/26nodes)\*(1/4) +* The staking reward account (`0.0.800`) must have met its initial threshold balance. +* The node the account is staked to must meet the minimum node stake threshold. +* The account must be staked for the entire 24-hour staking period. -Maximum Stake: ​50,000,000,000 hbars\*(1/26nodes) +### Staking Reward Distribution -## **Lockup Period** +With the implementation of [HIP-1259](https://hips.hedera.com/hip/hip-1259), the mechanism for handling fees and distributing rewards has been significantly streamlined to improve network efficiency and simplify transaction records. -There is **no lock-up period** when accounts are staked to a node. Stakers do not need to choose an amount of HBAR to stake from their account. The account's entire balance is staked automatically to the selected node or account. There is no concept of “bonding” or “slashing” of your tokens. The staked account balance is liquid at all times. +Previously, transaction fees were immediately split and distributed to multiple accounts. The new system introduces the **[Fee Collection Account](/hedera/support-and-community/glossary#fee-collector-account) (`0.0.802`)**, a network-controlled account that consolidates all transaction fees. -## **Staking Reward Account** +**How it Works:** -The staking reward account distributes rewards to eligible staked accounts. The staking reward account ID is [0.0.800](https://hashscan.io/#/mainnet/account/0.0.800?type=) on mainnet. Anyone in the community can contribute to the rewards pool by transferring HBAR into that account. This account has no keys, and therefore, any HBAR transferred into this account cannot be returned to the owner. If you choose to contribute to the rewards pool, please make sure to double-check your transfer transaction details. +1. **Collection**: When a transaction is processed, the entire fee is transferred in a single payment to the [Fee Collection Account](/hedera/support-and-community/glossary#fee-collection-account) (`0.0.802`). +2. **Distribution**: Once per day, at the end of each staking period, a single, large synthetic transaction distributes the accumulated fees from the `0.0.802` account to their appropriate destinations, including the Staking Rewards account (`0.0.800`). -The staking reward account needs to meet a minimum balance before rewards can begin to distribute rewards earned to the eligible staked accounts. The minimum HBAR balance threshold for the reward account is 250 million HBAR voted on by the Hedera Council. If this balance is not met staking rewards will not be distributed. You can view the balance of this account by visiting any of the Hedera network explorers. + + + -Once the minimum threshold is met, rewards will continue to be distributed to staked accounts as long as there is a balance in the rewards account even if it falls below the initial minimum threshold. The reward rate will initially be set to zero. The Hedera Council will vote and update the reward rate when the Hedera Staking Reward Program goes live. The latest reward rate can be found [here](https://hedera.com/blog/hedera-governing-council-votes-to-approve-changes-to-staking-algorithm). - -## **Staking Rewards** - -In Phase I, the staking reward rate will initially be zero. The Hedera Council will determine when the Hedera ecosystem has reached a minimum viable set of integrations to enable staking rewards. Once this is determined, the council (through CoinCom) will vote to update the reward rate, and subsequently, the mainnet will be updated with the agreed-upon reward rate. - -Any account can elect to stake to a node or another account. The **minimum staking period** is the minimum amount of time an account needs to be staked to a consensus node before the account is eligible to earn rewards. The minimum staking period is **one day (24 hours).** The staking period begins at midnight UTC and ends at midnight UTC. The Hedera Council defines the staking period. The earned rewards are not transferred to the staked account immediately after an account has been staked for one full staking period. Please see the Staking Reward Distribution section for what scenarios trigger the payment of a reward. - -Accounts staked for less than the defined minimum staking period are not eligible to earn rewards for that period. Nodes and accounts accumulate stake and rewards per whole HBAR. Fractions are rounded down. When a node is deleted, it returns zero rewards. + + #### **Key Takeaway** -For a staked account to be eligible to earn rewards, the following must be true: + This enhancement **does not change the amount you pay** for transactions. It only optimizes how the network processes the fees behind the scenes, resulting in a cleaner experience for users and a more efficient network for everyone. + -* The staking reward account needs to have met the initial threshold balance of HBAR - * Once the minimum threshold value has been met, the rewards account will continue to reward staked accounts even if the balance falls below the initial threshold -* The account the node is staked to meets the minimum node stake threshold value -* The account needs to be staked for the minimum staking period -* The reward rate is voted on by the Hedera Council and updated on mainnet +### Indirect Staking -Rewards will continue to be earned when a node is down or inactive in the first phase. The Council (through CoinCom) has voted to implement a maximum cap of [2.5% annual reward rate](https://hedera.com/blog/hedera-governing-council-votes-to-approve-changes-to-staking-algorithm). The actual reward rate will vary depending on how many HBAR are staked for rewards, but the rate will not exceed the cap. In the future, when nodes are down or inactive the staked account will not be eligible to earn rewards. +Hedera offers a unique feature: **indirect staking**. If account A stakes to account B, and account B stakes to a node, the stake from both A and B increases the node's consensus weight. However, the rewards for both accounts are paid to account B. -This staking system offers an additional unique functionality: **indirect staking**. If account A stakes to node N, then the stake increases the consensus weight of N, and account A is rewarded for every 24-hour period that it stakes. If account A stakes to account B, and account B stakes to node N, then the stake from both A and B will increase the consensus weight of N, but the rewards for both A and B will be received by B. +An account can also optionally decline to earn rewards, though its balance will still contribute to the node's stake. -An account can optionally decline to earn rewards when staked. The account will still be counted towards meeting the node’s minimum stake value. **📣 If you're interested in checking out the wallets and exchanges supporting staking HBAR, head to the** [**Stake HBAR**](/hedera/core-concepts/staking/stake-hbar) **page.** diff --git a/hedera/core-concepts/transactions-and-queries.mdx b/hedera/core-concepts/transactions-and-queries.mdx index 100ea72e..3141dbab 100644 --- a/hedera/core-concepts/transactions-and-queries.mdx +++ b/hedera/core-concepts/transactions-and-queries.mdx @@ -45,13 +45,19 @@ Every transaction on the Hedera network has an associated fee to compensate the Previously, transaction fees were immediately split and distributed to multiple accounts with every transaction. This immediate distribution created challenges. For a simple crypto transfer between two accounts, the system must read and update up to six accounts: the sender, receiver, submitting node, `0.0.98`, `0.0.800`, and `0.0.801`. This increases processing overhead and slows performance. In the [block stream](/hedera/support-and-community/glossary#block-stream), every transaction must record balance changes for all these accounts, inflating data size and storage costs. Users viewing transactions on explorers like HashScan see a complex web of transfers, which can be confusing even with visualizations. -The new system introduces the **Fee Collection Account (0.0.802)**, a network-controlled account that consolidates all transaction fees. +The new system introduces the **Fee Collection Account (`0.0.802`)**, a network-controlled account that consolidates all transaction fees. **How it Works:** 1. **Collection**: When a transaction is processed, the entire fee is transferred in a single payment to the Fee Collection Account (`0.0.802`). 2. **Distribution**: Once per day, at the end of each staking period, a single, large synthetic transaction distributes the accumulated fees from the `0.0.802` account to the appropriate destinations. + + #### **Key Takeaway** + + This enhancement **does not change the amount you pay** for transactions. It only optimizes how the network processes the fees behind the scenes, resulting in a cleaner experience for users and a more efficient network for everyone. + + These destinations include: - **Node Operator Rewards**: Payments to individual nodes for their services. - **Staking Rewards (`0.0.800`)**: Funds allocated to accounts participating in staking. @@ -62,7 +68,45 @@ These destinations include: -This change simplifies the process without altering the actual cost of transactions for users. +### Example 1: Fee Collection in Action (Crypto Transfer) + +Let's look at a standard `CRYPTO TRANSFER` transaction to see how the fee is collected. + +**Transaction Link:** [https://hashscan.io/mainnet/transaction/1771485699.125401461](https://hashscan.io/mainnet/transaction/1771485699.125401461) + +In this transaction, account `0.0.10231006` sends a small amount of HBAR to `0.0.37`. The HBAR transfers clearly show the fee consolidation: + +| Account | Amount | Description | +| :--- | :--- | :--- | +| `0.0.10231006` | **-0.00102456ℏ** | Payer (Sent transfer + fee) | +| `0.0.37` | **+0.00000009ℏ** | Receiver (Node 34) | +| **`0.0.802`** | **+0.00102447ℏ** | **Fee Collection Account** | + + +### Example 2: Fee Collection Across All Transaction Types + +The HIP-1259 fee collection mechanism applies to all transaction types, not just crypto transfers. Let's look at a `SUBMIT MESSAGE` transaction to see the same streamlined process. + +**Transaction Link:** [https://hashscan.io/mainnet/transaction/1771486013.122401000](https://hashscan.io/mainnet/transaction/1771486013.122401000) + +#### Transaction Details + +- **ID:** `0.0.85243@1771485974.183471116` +- **Type:** `SUBMIT MESSAGE` +- **Fee:** `0.00902194ℏ` + +#### HBAR Transfers Breakdown + +This transaction submitted a message to the Hedera Consensus Service. Notice how simple the HBAR transfers are: + +| Account | Amount | Description | +| :--- | :--- | :--- | +| `0.0.85243` | **-0.00902194ℏ** | Payer (Paid the transaction fee) | +| **`0.0.802`** | **+0.00902194ℏ** | **Fee Collection Account** | + +That's it. The entire fee is cleanly transferred to account `0.0.802`. There are no other transfers related to the fee in this transaction, making the record simple and easy to understand. + +### Before vs. After HIP-1259 | Aspect | Before HIP-1259 | After HIP-1259 | | :--- | :--- | :--- | @@ -71,11 +115,6 @@ This change simplifies the process without altering the actual cost of transacti | **Network Overhead** | Higher, due to multiple balance updates per transaction. | Lower, improving overall network throughput. | | **Block Stream** | Larger and more complex. | Smaller and more efficient, reducing costs for mirror nodes. | - - #### **Key Takeaway** - - This enhancement **does not change the amount you pay** for transactions. It only optimizes how the network processes the fees behind the scenes, resulting in a cleaner experience for users and a more efficient network for everyone. - ## Transaction Types @@ -216,7 +255,7 @@ Once a transaction has been submitted to the network, clients may seek confirmat For a more detailed review of the confirmation methods, please check out this [blog post](https://www.hedera.com/blog/transaction-confirmation-methods-in-hedera). -## FAQ +## FAQs @@ -314,3 +353,23 @@ Learn more [here](/hedera/sdks-and-apis/sdks/transactions/create-a-batch-transac
ErrorCodeCauseSolution
BATCH_LIST_EMPTY388Submitting a batch with no inner transactionsAdd at least one inner transaction to the batch
BATCH_LIST_CONTAINS_DUPLICATES389The batch contains duplicate inner transactionsEnsure each inner transaction in the batch is unique
BATCH_TRANSACTION_IN_BLACKLIST390An inner transaction is of a type that's not allowed in batchesOnly use allowed transaction types in batches
INNER_TRANSACTION_FAILED391One or more inner transactions failed during executionCheck the specific error for the inner transaction and fix the issue
BATCH_KEY_SET_ON_NON_INNER_TRANSACTION393`BatchKey` is set on the outer transactionOnly set BatchKey on inner transactions, not on the outer batch transaction
INVALID_BATCH_KEY394The `BatchKey` is missing or invalidEnsure all inner transactions have a valid `BatchKey` set
INVALID_NODE_ACCOUNT_ID341Inner transaction has a nodeAccountID other than 0.0.0Use the batchify() method which automatically sets nodeAccountID to 0.0.0
 + +> #### HIP-1259 FAQs +> +> +> +> This is part of a network enhancement called HIP-1259, which introduced the **Fee Collection Account (0.0.802)**. Instead of splitting fees across multiple accounts with every transaction, all fees are now sent to this single, network-controlled account. This simplifies transaction records and improves network performance. +> +> +> Staking rewards are distributed to individual stakers at the end of each 24-hour staking period. The funds for these rewards are moved into the staking rewards account (`0.0.800`) once per day at the **beginning** of the staking period from the Fee Collection Account (`0.0.802`). +> +> +> No. The Fee Collection Account (`0.0.802`) is a special, network-controlled account that **does not accept HBAR deposits** from users. It has no keys and is designed to only receive network fees. Any direct transfer attempts will be rejected. +> +> +> No. This enhancement **does not change the amount you pay** for transactions. It only optimizes how the network processes fees behind the scenes. The cost of transactions remains the same. +> +> +> The daily synthetic transaction is a single, large, network-generated transaction that occurs once per day at the start of each staking period. It distributes all the fees accumulated in the Fee Collection Account (`0.0.802`) to their final destinations, including the staking rewards account (`0.0.800`), node reward account (`0.0.801`), and the network treasury (`0.0.98`). +> +> \ No newline at end of file diff --git a/hedera/networks/release-notes/services.mdx b/hedera/networks/release-notes/services.mdx index cc54c3d8..0018de4b 100644 --- a/hedera/networks/release-notes/services.mdx +++ b/hedera/networks/release-notes/services.mdx @@ -10,9 +10,9 @@ Visit the [Hedera status page](https://status.hedera.com/) for the latest versio **MAINNET UPDATE: MARCH 11, 2026** - - **TESTNET UPDATE: FEBRUARY 19, 2026** - + + **TESTNET UPDATED: FEBRUARY 19, 2026** + ### [**Build 0.71.1**](https://github.com/hiero-ledger/hiero-consensus-node/releases/tag/v0.71.1) diff --git a/hedera/support-and-community/glossary.mdx b/hedera/support-and-community/glossary.mdx index 2a26496b..32f02f8e 100644 --- a/hedera/support-and-community/glossary.mdx +++ b/hedera/support-and-community/glossary.mdx @@ -464,11 +464,17 @@ The principle that all transactions on a distributed ledger should be treated eq A "fallback fee" in the context of Hedera and smart contracts is a type of custom fee that is charged to the recipient of a token transfer, rather than the sender. This can lead to vulnerabilities in smart contracts if they unknowingly accept a token with a high fallback fee, resulting in a loss of funds. Discussions on mitigation strategies, such as sender-pays models or limits on custom fees, are ongoing. [Here's](https://hedera.com/blog/nft-royalty-fees-hedera-hashgraph) a comprehensive blog post covering fallback fees. +### Fee Collection Account + +--- + +The single, special network account (0.0.802) that consolidates all HBAR network transaction fees before they are distributed daily to reward and treasury accounts. This process, introduced in [HIP-1259](https://hips.hedera.com/hip/hip-1259), simplifies transaction records and improves network efficiency. + ### Fee Collector Account --- -A fee collector account is an account designated to receive transaction fees and [custom token fees](/hedera/sdks-and-apis/sdks/token-service/custom-token-fees) on the Hedera network. The account collects the fees users pay for executing transactions and queries on the network. +A user-designated account that receives custom fees from transfers of a specific token. The token creator defines this account in the token's fee schedule. ### Fiat Currency diff --git a/style.css b/style.css index f852f36b..f797b6dd 100644 --- a/style.css +++ b/style.css @@ -1,65 +1,51 @@ /* ========================= Hedera Styrene Webfonts ========================= */ -@font-face { - font-family: "Styrene A"; - src: url("/public/fonts/styrene/StyreneA-Thin-Web.woff2") format("woff2"); - font-weight: 100; - font-style: normal; - font-display: swap; -} @font-face { - font-family: "Styrene A"; + font-family: "Styrene Light Web"; src: url("/public/fonts/styrene/StyreneA-Light-Web.woff2") format("woff2"); - font-weight: 300; + font-weight: 500; font-style: normal; font-display: swap; } -@font-face { - font-family: "Styrene A"; - src: url("/public/fonts/styrene/StyreneA-Regular-Web.woff2") format("woff2"); - font-weight: 400; - font-style: normal; - font-display: swap; -} @font-face { - font-family: "Styrene A"; + font-family: "Styrene A Medium"; src: url("/public/fonts/styrene/StyreneA-Medium-Web.woff2") format("woff2"); - font-weight: 500; + font-weight: 600; font-style: normal; font-display: swap; } @font-face { - font-family: "Styrene A"; + font-family: "Styrene Bold"; src: url("/public/fonts/styrene/StyreneA-Bold-Web.woff2") format("woff2"); - font-weight: 700; + font-weight: 600; font-style: normal; font-display: swap; } -@font-face { - font-family: "Styrene A"; +/* @font-face { + font-family: "Styrene Black Web"; src: url("/public/fonts/styrene/StyreneA-Black-Web.woff2") format("woff2"); font-weight: 900; font-style: normal; font-display: swap; -} +} */ /* ========================= Global Font Setup ========================= */ :root { - --font-body: "Styrene A", "Inter", "Helvetica Neue", Arial, sans-serif; - --font-heading: "Styrene A", "Inter", "Helvetica Neue", Arial, sans-serif; + --font-body: "Styrene Light Web"; + --font-heading: "Styrene A Medium"; } html, body { font-family: var(--font-body); - font-weight: 400; + font-weight: 500; letter-spacing: -0.01em; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale; @@ -70,19 +56,20 @@ html, body { Hedera type weight rules ========================= */ -/* headings should use Styrene A Medium (not bold) */ +/* headings should use Styrene A Medium */ h1, h2, h3, h4, h5, h6, .prose h1, .prose h2, .prose h3, .prose h4, .prose h5, .prose h6 { - font-family: "Styrene A", "Inter", "Helvetica Neue", Arial, sans-serif !important; - font-weight: 500 !important; /* medium, per Hedera style guide */ + font-family: "Styrene A Medium", sans-serif !important; + font-weight: 400 !important; /* medium */ letter-spacing: -0.015em !important; line-height: 1.3 !important; color: inherit; } + /* body and list text stay light */ p, li, span, .prose p, .prose li { - font-weight: 300 !important; /* light */ + font-weight: 400 !important; /* light */ letter-spacing: -0.01em; } @@ -111,6 +98,7 @@ nav.text-sm ul > * { margin: 4px !important; } + /* shared button styling */ nav.text-sm a[href*="hackathon"], nav.text-sm a[href*="portal"] {