docs: add new HIP-1261 simple fees

docs.json

@@ -445,6 +445,7 @@
                 "group": "Transactions and Queries",
                 "pages": [
                   "hedera/core-concepts/transactions-and-queries",
+                  "hedera/core-concepts/transactions-and-queries/simple-fees",
                   "hedera/core-concepts/transactions-and-queries/transaction-properties"
                 ]
               },
@@ -875,6 +876,7 @@
                       "hedera/sdks-and-apis/rest-api/network",
                       "openapi.yaml GET /api/v1/network/supply",
                       "openapi.yaml GET /api/v1/network/fees",
+                      "openapi.yaml POST /api/v1/network/fees",
                       "openapi.yaml GET /api/v1/network/exchangerate",
                       "openapi.yaml GET /api/v1/network/nodes",
                       "openapi.yaml GET /api/v1/network/stake"

hedera/core-concepts/smart-contracts/gas-and-fees.mdx

@@ -23,7 +23,9 @@ As noted in [HIP-410](https://hips.hedera.com/hip/hip-410), this maximizes compa
 
 ## Gas Schedule and Fee Calculation
 
-Gas charges apply to `ContractCall`, `ContractCreate`, and `EthereumTransaction`. Other smart contract-related transactions (e.g., `ContractDelete`, `ContractGetInfo`) use standard Hedera network, node, and service fees in HBAR.
+Gas charges apply to `ContractCall`, `ContractCreate`, and `EthereumTransaction`. Other smart contract-related transactions (e.g., `ContractDelete`, `ContractGetInfo`) use the standard [Simple Fees](/hedera/core-concepts/transactions-and-queries/simple-fees) model, a base fee plus extras for node, network, and service components, paid in HBAR.
+
+For gas-consuming transactions (`ContractCall`, `ContractCreate`, `EthereumTransaction`), gas is an "extra" in the service fee component. The gas extra covers EVM execution costs. All other fee components (node fee, network fee, and the non-gas portion of the service fee) follow the base-fee-plus-extras model.
 
 Gas fees for EVM transactions consist of:
 

hedera/core-concepts/tokens/hedera-token-service-hts-native-tokenization/custom-fee-schedule.mdx

@@ -78,11 +78,11 @@ Royalty fees function as a convenience feature, but the network cannot enforce r
 Understanding the difference between custom fees and standard transaction fees in HBAR is crucial for token issuers and developers working with Hedera.
 
 * **Custom fees** are designed to enforce complex fee structures, such as royalties and fractional ownership. These fees can be fixed, fractional, or royalty-based and are usually paid in the token being transferred, although other Hedera tokens or HBAR can also be used. You can configure up to 10 custom fees to be automatically disbursed to designated fee collector accounts.
-* On the other hand, **transaction fees** in HBAR serve a different purpose: they compensate network nodes for processing transactions. These fees are uniform across all transaction types and are paid exclusively in HBAR. Unlike custom fees, which can be configured by the user, transaction fees are fixed by the network.
+* **Transaction fees** in HBAR serve a different purpose: they compensate the network for processing transactions. These fees follow a [base fee + extras model](/hedera/core-concepts/transactions-and-queries/simple-fees) defined in the network's fee schedule (system file `0.0.113`). While the fee structure varies by transaction type (each has its own base fee and applicable extras), the fee schedule is set by the network's governing authority, not by individual users. Transaction fees are paid exclusively in HBAR.
 
 ### **Key Differences**
 
-The table below summarizes the key differences between custom fees and transaction fees.
+The key differences are that custom fees offer flexibility and can be paid in various tokens to any account, while transaction fees follow a network-defined schedule and go to the network and node operators, paid only in HBAR. The table below summarizes the key differences between custom fees and transaction fees.
 
 <table><thead><tr><th>Feature</th><th>Custom Fees</th><th>Transaction Fees</th></tr></thead><tbody><tr><td><strong>Purpose</strong></td><td>Enforce token-specific fee structures (e.g., royalties, taxes)</td><td>Compensate network nodes for transaction processing</td></tr><tr><td><strong>Who Collects?</strong></td><td>Designated fee collector(s)</td><td>Hedera network nodes</td></tr><tr><td><strong>Currency</strong></td><td>HBAR or HTS fungible tokens</td><td>HBAR only</td></tr><tr><td><strong>Configurability</strong></td><td>Fully configurable by token issuer</td><td>Fixed by the network</td></tr></tbody></table>
 

hedera/core-concepts/transactions-and-queries.mdx

@@ -220,6 +220,10 @@ The transaction fee for the child transaction is included in the record of the p
 
 **Queries** are processed only by the single node to which they are sent. Clients send queries to retrieve some aspect of the current consensus state, like an account balance. Certain queries are free, but generally, they are subject to fees. The full list of queries can be found [here](/hedera/sdks-and-apis/sdks/queries).
 
+<Info>
+Under the [Simple Fees](/hedera/core-concepts/transactions-and-queries/simple-fees) model, queries can have node, network, and service fee components. However, many common queries (e.g., `TransactionGetReceipt`, `CryptoGetAccountBalance`) are marked as **free** in the fee schedule. For non-free queries, the SDK creates a payment transaction to cover the fees.
+</Info>
+
 A query includes a header that includes a normal HBAR transfer transaction that will serve as how the client pays the node the appropriate fee. There is no way to give partial payment to a node for processing the query, meaning if a user overpaid for the query, the user will not receive a refund. The node processing the query will submit that payment transaction to the network for processing into a consensus statement to receive its fee.
 
 A client can determine the appropriate fee for a query by asking a node for the cost, not the actual data. Such a `COST_ANSWER` query is free to the client.