Enable Threshold (1-of-N) Support in HTS Precompile

[mgarbs]

Enable Threshold Keys Support in HTS updateTokenKeys Precompile

This update adds support for using threshold keyswithin the updateTokenKeys HTS precompile function, allowing developers to set token keys with multiple signatories directly in smart contracts. While complex keys are supported in the SDK, this enhancement allows on-chain token management with multi-signature and threshold-controlled permissions, expanding flexibility for applications requiring decentralized control over token keys.

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	2e4a81d
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/67a4cdf82412fa00082e300b
😎 Deploy Preview	https://deploy-preview-1069--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Neurone]

Hi @mgarbs , it seems to me we solved all the pending issues. From my PoV we can proceed.

[lukelee-sl]

From a technical point of view, I do not think this can be accommodated without system contract versioning as you would be potentially breaking existing contracts because of the need to redefine the KeyValue struct. If this is indeed the case, then we need to decide if this feature should be included in the next HTS contract version.

[stoyanov-st]

I totally agree with @lukelee-sl, this is a great candidate for the contract versioning initiative.
Also, does it make sense to include the solidity struct changes with the HIP?

[Neurone]

I agree that this is a good fit for the new contract versioning initiative.

@lukelee-sl I don't think we need to make an explicit reference to this detail in the HIP, especially if the new process is going to be the new norm, but just in case, feel free to suggest some changes.

@stoyanov-st Yes, we need to make as many details explicit as possible, but they can be just an example and the real struct can be defined later. The guidelines for a HIP are to make explicit any changes that affect the operation of the network, including interfaces. In this case, if we maintain compatibility with old contracts, as we will now do with the versioning system, we can more easily skip all the details on the Solidity side, but it's good to have them as an initial idea and as a reference for developers reading the HIPs in the future. If there are major changes during development, we can always update the HIP with the correct interfaces, but if there are major changes, we will need to do a new HIP release.

[stoyanov-st]

After carefully reviewing this HIP, the smart contracts team has agreed on several discussion topics that need to be addressed for the clarity and understanding of this feature. Those are:

1. Solidity Structure Updates

• A review of existing Solidity structures is necessary to ensure compatibility with the proposed changes.
• Notably, due to recursion issues in KeyList we must determine whether to modify existing structures or introduce new ones to handle key management more efficiently.
• If we follow the protobuf definitions for the structs modification there would be additional validation for the threshold = 1 that would require an appropriate response code for the unsuccessful scenarios.
• Also, KeyHelper.sol needs adjustments.

2. Other Threshold Limitations

• While a threshold of 1 is the obvious limit, we need to address the more complex scenarios, such as a threshold within a threshold.
• Defining these limitations early will help avoid ambiguity in implementation, misinterpretations and potential security concerns.

3. Specification of Key Usage for Signing Transactions

• A clear specification is needed regarding who signs transactions and which keys are used in different scenarios or a reference to an existing specification.

4. System Contract Address

• As this feature is going to be leveraging the System Contract Versioning, there needs to be a section stating the address that is going to be exposing it.

Considering the impact that this proposal is going to make, we need to be careful and also be able to foresee most of the implications that it is going to produce.

To fix this problem, replace the no-op .replace(/'/g, "'") and .replace(/"/g, '"') calls with replacements that actually target unicode smart quotes, substituting them with regular ASCII single ' and double " quotes, respectively. Specifically:

• Change the patterns to match the unicode smart quotes: ‘ (U+2018) and ’ (U+2019) for single quotes, and “ (U+201C) and ” (U+201D) for double quotes.
• Replace them with the ASCII equivalents (' and ").
• Remove the unnecessary no-op replacements.

All changes should be made in the block of code that does the replacements (lines 45–56 in scripts/validateHIP.js). No new imports or dependencies are required.

---

To fix this issue, update all redundant .replace(/'/g, "'") and .replace(/"/g, '"') calls to actually target the typographic/smart quote Unicode characters commonly found in documents, replacing them with plain ASCII equivalents. Specifically:

• Replace left/right single quotes (‘ is U+2018, ’ is U+2019) with '
• Replace left/right double quotes (“ is U+201C, ” is U+201D) with "
  This should be done in the replacement block for lines 44-56 in scripts/validateHIP.js.
  No new imports or dependencies are needed.

---

The fix requires identifying the intended problematic characters (smart quotes), and replacing them with correct ASCII equivalents. Specifically:

• Lines like .replace(/"/g, '"') should target the Unicode smart quotes, for example, replacing U+201C (\u201C) and U+201D (\u201D) with ".
• Instead of .replace(/"/g, '"'), use .replace(/\u201C/g, '"') and .replace(/\u201D/g, '"').
• Clean up redundant replacements of ' as well, if applicable (so-called "smart" single quotes U+2018/U+2019).
• Only modify the draftHip clean-up chain in scripts/validateHIP.js (lines 45–56).
• No new imports required.
• No change to overall functionality, only correct the character replacement.

---

To fix the problem, the code should replace specific Unicode quote characters (such as left/right smart quotes) with their ASCII equivalents (' and "), rather than replacing the ASCII quote with itself. The affected region is lines 48–56 in scripts/validateHIP.js. Specifically, the code should use the corresponding Unicode code points for smart quotes — e.g., replace ‘/’ with ', and “/” with " — not generic ASCII quotes.

To implement these changes, update the relevant .replace() calls to properly match and convert Unicode smart quotes to ASCII quotes. No additional imports or custom methods are required; all replacements can be done using JS regular expressions.

To fix the problem, locate the .replace(/'/g, "'") on line 54, which is intended to convert smart single quotes (such as U+2019) to ASCII apostrophes. Change the regular expression so it matches the correct Unicode code point(s) for smart quotes—for example, \u2019 (right single quotation mark), \u2018 (left single quotation mark), and possibly others—then replace them with the simple ASCII apostrophe ('). No additional imports are needed as this uses JavaScript's built-in string and regex support. Only change the code on or near line 54 for this correction.

---

To properly standardize double quotes in the HIP text, we should replace all forms of "smart quotes" with the standard ASCII double quote character ("). This means explicitly targeting Unicode characters such as “ (LEFT DOUBLE QUOTATION MARK, U+201C) and ” (RIGHT DOUBLE QUOTATION MARK, U+201D). Lines 50, 51, 55, and 56 currently use /"/g, which matches only the ASCII double quote, but they should use /[“”]/g to replace these Unicode types. Thus, in file scripts/validateHIP.js, lines 50, 51, 55, and 56 should match these Unicode smart quotes and replace with ".

No external dependency is needed; only native JavaScript regex.

---

General fix:
Remove or correct the .replace lines where the code attempts to replace a substring with itself (/"/g, '"') for both single and double quotes. Instead, the code should explicitly match and replace smart/curly quotes (such as “, ”, ‘, ’) with the ASCII equivalents. This will ensure that all variants of smart quotes are handled correctly for JSON and downstream processing.

Specifics:

• On lines 48–56, correct the regexes so that all Unicode smart quotes are matched, and are replaced with ASCII ' or " as appropriate.
• Remove all lines that simply .replace(/'/g, "'") or .replace(/"/g, '"') unless they're meant to revert something that was previously mapped incorrectly (which seems not to be the intent here).
• Add correct regex replacements for smart quote characters:
  • Single quotes: ‘ (U+2018), ’ (U+2019)
  • Double quotes: “ (U+201C), ” (U+201D)

Implementation details:
Edit line 45–56 in scripts/validateHIP.js to:

• Replace .replace(/‘|’/g, "'") // smart single quotes
• Replace .replace(/“|”/g, '"') // smart double quotes
• Remove any duplicate or no-op replacements.

No new imports are necessary.

---