Updated based on feedback + assets for the price analysis chart.

Signed-off-by: Giuseppe Bertone <giuseppe.bertone@hashgraph.com>

Author: Neurone

HIP/hip-1264.md

@@ -58,7 +58,6 @@ Alternative designs considered:
 - As a user, I want to send a specific dollar amount to someone without having to calculate HBAR conversions or worry about price changes between transaction creation and execution (e.g., long lasting scheduled transaction)
 - As a developer, I want to set network fee limits in dollars so that my applications don't fail when HBAR prices change and my preset limits become insufficient.
 - As a developer, I want to avoid conversion bugs in my application by letting the network handle HBAR-dollar calculations at consensus time with provable accuracy and exchange rate.
-- As a developer, I want to my smart contracts to manage and transfer dollar amounts without relying on 3rd party owned oracles.
 
 ## Specification
 
@@ -164,7 +163,6 @@ If a field can be set using a TokenID, that same field can also be set in dollar
 - Transfer amounts in `CryptoTransfer`
 - Custom fees in token creation and updates
 - Scheduled transaction amounts
-- Smart contract value transfers
 
 All existing HBAR amount fields support dollar denomination:
 
@@ -262,11 +260,19 @@ TBD
 
 ## Open Issues
 
-- **Precision Handling**: Specification of decimal precision and rounding rules for dollar amounts
+- **Exchange Rate Oracle Update Frequency**: A [preliminary analysis comparing the current HBAR Oracle with market prices](https://internetofpeers.org/hedera-hbar-exchange-rate-oracle-analysis/release/) (*) shows that the current situation (% gap) is probably good enough for retail use cases. Incrementing the update frequency of the exchange rate would probably be beneficial for enterprise use cases. Switching to a 30-minute update would make a significant difference. With a 15-minute update, enterprises would likely adopt this without hesitation. It is probably important this decision is included in this HIP.
+- **Precision Handling**: Specification of the rounding rules for dollar amounts
 - **System TokenID Range**: Final determination of whether to use `max uint64` and below values or system account range (e.g., `0.0.150`) for fiat currency identifiers
 - **Future Currency Support**: Preparing the field for additional fiat currencies beyond USD
 - **Creating dedicated protobuf fields for HBAR-only fields**: The TokenID solution allow using USD when it is possible to use a token, but it does not allow to define USD for HBAR only fields, like for example max transaction fees.
 
+(*): We'll be able to update the link and point to the hips.hedera.com domain as soon as the first PR is merged.
+
+## Possible evolutions not included in this HIP
+
+- **Support system token IDs on the HTS system contract**: Smart contracts can already call the exchange rate system contract to compute the correct amount of dollars if they want, so having a dedicated token to move around is something useful and _cleaner_ than a custom made integration, but it's not essential having this from the start. This can, though, be implemented with a future HIP if and when the community asks for it.
+- **Future Currency Support**: While preparing the field for additional fiat currencies beyond USD is considered in-topic, actual support for more FIAT currencies is out of this HIP.
+
 ## References
 
 - [Hedera Exchange Rate API Documentation](https://docs.hedera.com/hedera/sdks-and-apis/rest-api#exchange-rates)