TIP: OTAK-PQ — One-Time Access Keys for Quantum-Resilient Account Security

[alichatme]

I would like to propose OTAK-PQ (One-Time Access Keys), a quantum-resilience oriented account security architecture for Tron.

OTAK-PQ reduces long-term exposure of account access keys by using one-time child keys, Merkle-based validation, and a secure bootstrap process. The design aims to limit the impact of future cryptographic and quantum-computing threats while remaining compatible with existing signing algorithms and future post-quantum migration paths.

Draft proposal attached for discussion and review.

Pull Request: #891

[alichatme]

---

tip: XXXX
title: One-Time Active Keys for Post-Quantum Security (OTAK-PQ)
author: Ali (@alichatme)
status: Draft
type: Standards Track
category: Core
created: 2026-06-07
discussions-to: #890

Summary

This TIP adds the capability of One-Time Access Keys (or "child keys" for short) to the Tron network.

One-Time Access Key (or "Child Key"):

(One-Time Access Key):
A key that is derived from one of the account’s Access Keys according to the TRC-102 standard, and whose membership in the account’s authorized key set is proven via a Merkle Proof and the Merkle Root recorded in the network’s State. Each one-time access key, after its first successful use, is permanently considered consumed and can no longer be used to create a valid transaction. The signature of the transaction associated with this key is published on the blockchain and becomes part of the transaction history only after its inactive status has been recorded in the network.

. Based on this architectural model, with the addition of the child key to the blockchain network, each account is only permitted to send transactions by signing using a child key.
. If a transaction is signed and sent with a key that is not a valid child key whose membership can be proven via a Merkle Proof, network nodes must reject the transaction without recording the signature and return the OTAK-PQ error in the validation response.
. Based on this error code, wallets can display an appropriate guidance message to the user; for example:
“This transaction is not compatible with OTAK-PQ security requirements. Please use a wallet version that supports child keys.”

. After sending a transaction with a child key to the network and its confirmation by nodes, the status of the child key changes to Consumed. After this status is recorded in the network State, the transaction and its corresponding signature are published on the blockchain and in blockchain explorers according to network protocols.

. This feature significantly reduces Tron’s exposure to threats based on key recovery from the history of recorded signatures on the network.
Because even if an attacker breaks the signature of a child key transaction, they will not gain access to the account’s assets controlled by the Access keys.

Security features of an account before its first outgoing transaction

When a new account is created on the Tron network, until the first on-chain signature is published, its exposure to certain threat scenarios based on quantum computing is significantly reduced, subject to the following factors:

1. Condition of non-disclosure of public key in signature form:

. As long as an account’s or wallet’s transaction history contains only deposit operations and no outgoing transaction has been made from it.
In the absence of recorded signatures on the blockchain, no data is available to execute public-key recovery algorithms.
Therefore, the exposure to attacks based on signature analysis is significantly reduced at this stage.
. In this state, only the hash of the public key, i.e., the address, is visible and available for the account.

. Hence, it can be concluded that such wallets in the short term, i.e., before sending the first transaction to the network, will have much lower exposure to certain threats based on signature analysis.

2. Critical moment: the account’s first transaction

. As soon as any outgoing transaction is made (even a partial transfer of assets), the public key is automatically recorded on the blockchain in the form of a signature.
. If quantum computers with sufficient operational capability and the ability to effectively execute Shor’s algorithm at the required scale become a reality, recovering the private key from the public key will become theoretically possible.

. Obviously, this threat extends to all remaining assets in the account.

. This proposal introduces a new security model for Tron network accounts in which Access keys do not participate in the signing process of on-chain transactions and their signatures are not published on the network.
For each transaction, the wallet derives a child key from the Access Keys, generates the corresponding Merkle Proof, and signs the transaction with that child key and sends it to the network.

Each child key is valid for only one transaction, and its validation is performed by nodes at the moment of transaction processing.

The validity of the child key is proven through the Merkle Proof provided in the transaction and the Merkle Root stored in the account. Nodes do not need to reconstruct the TRC-102 derivation process or validate the mathematical relationship between Access Keys and Child Keys.

The process is defined as follows:

1. Nodes check that the transaction signature has been provided by a valid child key; otherwise, the transaction is rejected.
2. Nodes check that the child key has not been used before and that its status in the network State is not in the Consumed state.
3. If the signature is valid and the Merkle Proof validation against the Merkle Root stored in the account State succeeds, the transaction enters the confirmation phase.
4. After the transaction is confirmed, the child key is marked as consumed (one-time-use). This status is recorded in the network state.
5. The transaction and its corresponding signature are recorded and viewable on the blockchain and explorers like TronScan according to standard network protocols.

Limited scope of each security incident

Even if, in the future, an attacker is able to recover the private key of a child key using advanced cryptographic methods or new computing technologies, this incident will only affect that specific consumed child key.
Since that key has already been deactivated:
. It cannot be reused.
. It cannot sign a new transaction.
. No active operational permission is attached to it.
. The security of other child keys is not affected.
. It does not alone provide enough information for the attacker to recover the account’s Access Keys.
Consequently, the OTAK-PQ architecture limits the impact of any possible security incident to a single child key and prevents its spread to other components of the account.

Abstract:

Shor’s algorithm in quantum computing has the ability to solve the discrete logarithm problem and thus can theoretically threaten security based on elliptic curves (ECC/ECDSA). In the current Tron architecture, transaction signatures are permanently recorded on the blockchain, which can increase the cryptographic attack surface in the long term.

Proposed OTAK-PQ model

This proposal presents a security model based on Key Layer Separation, in which:

. Access keys never directly participate in signing operational network transactions.

. Access keys are used only for deriving child keys at the wallet level.

. Each transaction is signed with a Child Key.

. After the transaction is processed by nodes, the Child Key is marked as consumed.

. After the child key is deactivated, the transaction signature is published on the network history.

Network mechanism

In the OTAK-PQ architecture, the wallet locally generates a set of Child Keys according to the TRC-102 standard.
. A Merkle Tree of the child keys is constructed.
. The resulting Merkle Root is recorded in the network State through a Bootstrap process.
. After successful Bootstrap completion, the account transitions from the Bootstrap Pending state to Active.

For each transaction:

. The wallet selects a new unused Child Key.
. Generates the corresponding Merkle Proof.
. Signs the transaction with that Child Key.

Network nodes accept the transaction only if:

. The signature is valid.
. The Child Key has not been consumed before.
. The Merkle Proof is valid.
. The Child Key belongs to the Merkle Root stored in the account.

After transaction confirmation:

. The Child Key is recorded as consumed in the network State.
. The transaction is published on the blockchain according to standard network protocols.
. The Child Key can no longer be reused.

Role of Access Keys in the OTAK-PQ security model

Access Keys have no direct role in signing network transactions and are used only at the wallet layer to generate child keys.
Consequently:
. No direct signatures from Access Keys are recorded in the public history of blockchain transactions.
. Each child key has its own independent key pair, but is deterministically derived from the Access Key.
. Even if a Child Key is compromised, access to the main account is not possible.

Cryptographic separation of Access Keys and child keys

In the OTAK-PQ architecture, both Access Keys and child keys are deterministically generated from the user’s master Seed according to the TRC-102 standard.
Although all these keys are derived from a common root, from a cryptographic and operational perspective, each child key has its own independent key pair and acts as a separate cryptographic identity.

Important feature of OTAK-PQ: operational independence of child keys

Each child key has its own independent public and private key and is used only to perform a single transaction.
After the transaction is successfully processed by network nodes, the child key is recorded as Consumed in the network State and becomes permanently operationally invalid.

Motivation

In the current Tron architecture:

. One active authorized key can sign thousands of transactions.
. Signatures remain on the blockchain forever.
. Breaking one signature can lead to permanent control of the main account by the attacker.
. The main account key is exposed many times over time.

Proposed solution: using child keys (OTAK-PQ)

. Access Keys are used solely as the Root of Trust to generate child keys.
. The wallet deterministically generates a set of child keys according to the TRC-102 standard and records their Merkle Root on the network during the Bootstrap process.
. Each transaction is signed by a separate child key.
. The validity of each child key is verified through the Merkle Proof and the Merkle Root stored in the network State.
. After the first successful use, the child key is permanently marked as consumed.
. If the private key of a child key is recovered or broken from its recorded signature, the attacker will only gain access to that consumed key, and because it is deactivated after use, there is no valid way to access assets controlled by the Access Keys or other child keys.

Brief overview of all existing solutions for facing the quantum threat

1. Changing the signature algorithm to Post-Quantum (e.g., ML-DSA)

. Advantages: Long-term security, provided no new breaking algorithms like Shor or more powerful computational computers are discovered.
. Disadvantages: Requires changing the entire protocol, increased signature size, high cost, increased computational cost, signature verification and node resource consumption, extra load on network nodes.

2. Child keys (OTAK-PQ)

Advantages:

. Almost no need to change the current network signature algorithm.
. No significant decrease in transaction throughput and processing speed.
. No significant processing overhead for nodes.
. Compatible with current Tron infrastructure.
. Usable and compatible with current and future signature algorithms.
. Easy migration to new cryptographic algorithms if needed.
. Drastic reduction in the impact of attacks based on key recovery from recorded signatures, by limiting the validity of each signature to a single-use child key.
. Usable as a complementary security layer even if the network migrates to post-quantum algorithms.

Disadvantages:
. Requires wallets to support the OTAK-PQ architecture.
. Requires adding a Bootstrap mechanism for initial account setup.
. Requires storing the Merkle Root and validating Merkle Proofs at the network protocol level.
. Requires maintaining the consumed status of child keys in the network State.
. Increased implementation complexity compared to the traditional model of direct signing with Access Keys.

Goal of this proposal

This proposal changes the transaction signature generation and validation process on the network as follows:
Access Keys
↓
Child key derivation and Merkle Proof generation
↓
Transaction signing by child key
↓
Signature and Merkle Proof validation by nodes
↓
Transaction execution
↓
Mark child key as consumed
↓
Public broadcast of transaction and child key signature on the network

Consequently, even if an attacker in the future can analyze a transaction signature or recover the private key corresponding to a child key:
. That child key will no longer be valid, because after transaction confirmation it is recorded as consumed in the network State.
. The child key is permanently deactivated after its first use and cannot be reused to create a valid transaction.
. The relationship between the child key and the Access Keys according to the TRC-102 standard is a one-way function; therefore, recovering Access Keys from a child key is not possible.
. The data used to prove initial account ownership during the Bootstrap process is not part of the account’s operational history; only the final validation result is stored in the network State.
. Each child key, past or future, is cryptographically independent of other child keys, and compromising one child key has no impact on the security of the Access Keys or other child keys.

Secure Bootstrap Protocol

Necessity

. In the OTAK-PQ security model, the fundamental principle is non-publication of Access Key signatures on the blockchain. Since network nodes need a proof-of-ownership mechanism to accept the initial Merkle Root and activate the account’s security structure, the account creation process in OTAK-PQ differs from the current Tron model.
. For this purpose, this proposal adds a new stage called the Secure Bootstrap Protocol to the Tron protocol.

Account states in OTAK-PQ

OTAK-PQ accounts can be in one of two states:
Bootstrap Pending
Active

Stage One: Creating the account security structure

The wallet, locally and offline:
. Generates Access Keys from the Seed.
. Derives a set of child keys according to the TRC-102 standard.
. Builds a Merkle Tree of the child keys.
. Calculates the Merkle Root.
Then the wallet sends a Bootstrap Request to the network. Because the account is in the Bootstrap Pending state and has no assets to pay fees, this transaction is processed by nodes as a fee-exempt transaction. The Bootstrap Request includes:

· Account address
· Merkle Root
· OTAK-PQ security parameters
· Initial account ownership proof

Stage Two: Bootstrap validation

Network nodes receive the Bootstrap Request and:
. Verify the validity of the initial ownership proof.
. Validate the structure of the submitted data.
. Reach consensus on accepting or rejecting the request.
In this stage, validation data is used only for the verification process, and the bootstrap request signature is not published in the public network transaction history.

Stage Three: Recording the Bootstrap result

After nodes reach consensus:
The account’s Merkle Root is recorded in the network State.
The BootstrapCompleted field is set to true.
The account status changes from Bootstrap Pending to Active.
Only the validation result is stored in the permanent network State; the temporary data used for initial ownership proof does not become part of the account’s operational history.

Restriction for accounts in Bootstrap Pending state

In the inactive state, account Access Keys are only permitted to send a bootstrap request transaction to the network.

. Wallets are not allowed to display the account number to users before the account is activated.

. A newly created account remains in the Bootstrap Pending state from the beginning to the end of the activation process.

. Accounts will not enter the network operational cycle until the Bootstrap process completes successfully.

In the Bootstrap Pending state:
. The Merkle Root is not yet finally recorded.
. The initial ownership proof process is not yet complete.
. OTAK-PQ rules are not yet active.
. The account is not allowed to receive or send assets.
. If assets are sent to an account in the Bootstrap Pending state, the transaction is recorded as a pending transfer, and the assets cannot be used until the Bootstrap process completes successfully. After the account is activated, the assets are added to the destination account’s balance. If Bootstrap is not completed within the time period specified by the protocol, the status of these assets will be determined according to network rules.
This restriction ensures that no account has a balance or economic activity on the network before completing the OTAK-PQ security process.

Account activation

After successful Bootstrap completion:
. The account is able to receive assets.
. OTAK-PQ rules are activated for the account.
. Access Keys are no longer permitted to directly sign operational network transactions.
. All account operations will be performed through valid child keys.

Transaction validation

For each transaction:
. The wallet generates a new child key.
. Calculates the corresponding Merkle Proof.
. Signs the transaction with that child key.

Nodes:
. Validate the signature.
. Match the Merkle Proof against the Merkle Root stored in the account.
. Check that the child key has not been consumed before.

After confirmation:
. The transaction is executed.
. The child key is marked as consumed.
. The signature published on the blockchain corresponds only to that child key and occurs after the child key has been deactivated.

Account Recovery

In the OTAK-PQ model, all Access Keys, the Merkle Root, and child keys are deterministically generated from the user’s master Seed according to the TRC-102 standard.
Therefore, the network does not need to store private keys, child keys, or derivation paths.
In case of device or wallet loss:

. The user enters their master Seed.
. The wallet regenerates the Access Keys.
. The child key tree structure is regenerated, and the calculated Merkle Root is matched against the value stored in the network State.
. All unused child keys will be regeneratable.
. The consumed status of child keys is determined via the network State, and keys marked as Consumed cannot be reused even after account recovery.

Because the derivation process is completely deterministic, account recovery requires no additional information beyond the Seed.
Consequently, OTAK-PQ retains all HD Wallet capabilities and does not introduce a new recovery mechanism.

Required changes to the Tron protocol

To support OTAK-PQ, the following protocol-level changes are required:

. Add Bootstrap Pending state for newly created accounts.

. Add a new Bootstrap Request message or transaction to record the initial account Merkle Root.

. Add a BootstrapCompleted field in the account state.

. Store the Merkle Root in the account State as the Root of Trust for child key validation.

. Add Merkle Proof validation mechanism in nodes.

. Add mechanism for consumption and permanent deactivation of child keys after first successful use.

. Prevent Bootstrap Pending accounts from receiving assets until Bootstrap completes successfully.

. Enforce a protocol restriction that, after Bootstrap completes, direct signing of operational account transactions by Access Keys is disallowed.

Security outcome

In the OTAK-PQ architecture, after the Bootstrap process is complete, all signatures published on the blockchain belong to child keys.

Consequently:

. Access Keys are not used in signing operational account transactions, and no direct signature from them is recorded in the network’s operational history.
. Each signature corresponds only to a temporary child key.
. Each child key becomes operationally invalid after use.
. Compromise of one child key has no impact on the security of the Access Keys or other child keys.
. The impact of any possible attack is limited to a single transaction.
. The account receives the full OTAK-PQ security structure before entering the network’s economic cycle.

OTAK-PQ architecture

1. Fundamental principle of the architecture

OTAK-PQ is based on the principle of “non-publication of Access Key signatures.”
In this architecture, keys with access to the account (Access Keys), including the Owner Key and Active Keys, are never directly used to sign on-chain transactions.
Access Keys act solely as the account’s Root of Trust and provide the basis for generating the child key structure at the wallet level.
After the Bootstrap process completes successfully, all account operations are performed exclusively through child keys.
If a transaction signed directly by one of the Access Keys is sent, network nodes must reject the transaction and return an OTAK-PQ error.

2. Child key generation

The wallet uses the TRC-102 standard (based on BIP44) to deterministically generate a set of child keys from the Access Keys.

Conceptual example:

Seed
↓
Access Keys
↓
Child Key #0
Child Key #1
Child Key #2
…

Each child key:
. Has its own independent public and private key.
. Is considered cryptographically independent of other child keys.
. Is valid for only one transaction.
. Due to the one-way nature of the derivation process, recovering Access Keys from it is impossible.
. After successful transaction confirmation, the child key identifier is recorded as Consumed in the network State. Only after this status is recorded is the transaction and its corresponding signature published on the blockchain.

3. Merkle tree structure

. In the OTAK-PQ architecture, child keys are organized into a Merkle Tree.

The wallet locally and offline:
. Generates the child keys.
. Creates the Merkle Tree.
. Calculates the Merkle Root.

During the Bootstrap process:
. Only the Merkle Root is recorded in the account State.
. Child keys are not stored on the network.
. The network does not retain any version of child private or public keys.

The Merkle Root serves as the account’s cryptographic root of trust for validating all child keys.

4. Storage structure of the Merkle Root in the account

In the OTAK-PQ architecture, the network does not need to store the list of child keys. The only information stored in the account State is:

· merkle_root: the root of the child key Merkle tree.
· bootstrap_completed: the status of Bootstrap completion.

The precise implementation details of the above data structures at the protocol level require review by the Tron core development team, and if this TIP is accepted, the final design will be carried out by them.

5. Transaction submission process

For each transaction:
. The wallet selects an unused child key.
. Signs the transaction with that key.
. Calculates the Merkle Proof for that key.
. Sends the transaction, signature, and Merkle Proof to the network.

The process is as follows:

Access Keys
↓
Child key derivation
↓
Merkle Proof generation
↓
Transaction signing
↓
Send to network

6. On-network validation

Network nodes, upon receiving a transaction:

. Verify the digital signature of the transaction.
. Validate the provided Merkle Proof.
. Check that the Merkle Proof matches the Merkle Root stored in the account State.
. Check that the account is in Active state and Bootstrap is completed.
. Check that the child key has not been consumed before.
. After successful transaction confirmation, the child key identifier is recorded as Consumed in the network State. Only after this status is recorded are the transaction and its corresponding signature published on the blockchain.
. In this process, nodes have no need to rebuild the derivation process or check the cryptographic relationship between the Access Key and the child key.

7. One-time use key consumption model

Each child key can be used only once.

After successful transaction confirmation:
. The transaction is executed.
. The child key identifier is recorded in the network State as consumed or nullifier.
. The possibility of reusing that key is permanently eliminated.

If an attempt is made to reuse a consumed key:
. The transaction is rejected.
. An OTAK-PQ error is returned.

8. Child key management in the wallet

Child key generation is completely deterministic.

Therefore:
. All child keys can be generated from a single Seed.
. The wallet can generate millions of child keys locally.
. There is no need to register keys separately on the network.
. There is no need to maintain multiple independent backups.
. Full recovery of the account structure is possible only with the master Seed.

Threat Model

The main security principles in OTAK-PQ are designed to reduce the exposure level of keys that have access to account assets (Access Keys) and to limit the impact of signatures visible on the blockchain.

In the ECDSA signature algorithm, every signature recorded on the blockchain can, in the presence of future computational threats (including quantum computing scenarios), be used as data to analyze and recover the private key.

Additionally, repeated use of a key to produce multiple signatures increases the risk level over time. Recovery of even one signature gives the attacker access to all assets.

This design in the OTAK-PQ security model ensures that:

. No signature from Access Keys is ever published on the blockchain.
. No key list is stored in the network State.
. Compromise of one child key does not affect other keys.
. Replay attacks are effectively neutralized.
. The impact of any possible attack is limited to a single transaction.
. The network can validate an unlimited number of child keys without storing millions of keys.

Consequently, OTAK-PQ shifts the account security model from reliance on long-term keys to a structure based on one-time-use keys, Merkle Proofs, and a Root of Trust.

The main goal of the OTAK-PQ security model is not to eliminate risk entirely, but rather:

. Limit the impact of any disclosed signature to a single transaction.
. Eliminate the reusability of signing keys.
. Reduce the attack surface against long-term analysis of signatures (including quantum threats).
. Transaction signatures are generated only by child keys.
. Access Keys (Owner/Active Keys) are never directly used to sign on-chain transactions.
. Each child key is systemically deactivated (inactive) after use, and only then is its signature published on the network.
. Child keys provide only temporary operational permission to perform a single transaction and are not part of the account’s long-term control structure.

Consequently, even if a recorded signature is disclosed:

. The key corresponding to that signature is limited to a past transaction.
. No active authority remains for that key to perform a new transaction.
. The account’s security control remains at the level of the Root of Trust and the Merkle Root structure recorded for the account.

Analysis of the impact of quantum attacks

Assume an asset transfer transaction is signed with a child key.

. The transaction is confirmed by network nodes and the assets arrive at the destination account.
. The child key is deactivated immediately after confirmation, then the transaction history is recorded on the blockchain and the signature is published.

In the above assumption, if in the future an attacker is able to:

Analyze the recorded signature, or recover the corresponding key (even assuming quantum computational capability).
This access will be limited solely to a consumed key that:

. Is no longer in an active state on the network.
. Cannot sign a new transaction.
. No longer has any assets under its control.
Therefore, the impact of the attack is limited to the historical level and does not extend to the control level of the account.

Scope of security coverage

OTAK-PQ protects against:

. Reducing exposure of long-term keys on the blockchain.
. Limiting attack impact to a single transaction.
. Preventing reuse of past signing keys.
. Reducing the impact of historical signature analysis in future scenarios.

OTAK-PQ does NOT protect against:

. Theft of Seed Phrase or recovery phrase.
. Compromise of the user’s device (malware / keylogger).
. Phishing or social engineering attacks.
. Real-time attacks before final transaction confirmation.
. Network layer or communication infrastructure attacks.
. Risks arising from analysis of transaction signatures recorded before the account migrates to OTAK-PQ.

Comparison of the OTAK-PQ security model with Post-Quantum algorithms

#Post-Quantum algorithms such as:

CRYSTALS-Dilithium
Falcon
SPHINCS+
are designed to counter quantum computing threats and attempt to ensure security by making the cryptographic problem harder.

General characteristics of these algorithms:

. Increased signature and key sizes compared to ECDSA.
. Increased computational cost of verification in nodes.
. Increased memory and bandwidth consumption.
. Relative decrease in throughput compared to lighter signatures.

In blockchain networks, these costs directly affect:
. TPS
. Latency
. Node resource consumption.

Impact of OTAK-PQ on network speed

OTAK-PQ, instead of trying to increase cryptographic complexity, focuses on reducing the exposure level of sensitive keys. In this model:

. The underlying signature algorithm (e.g., ECDSA) remains unchanged.
. Signature size and transaction structure do not change.
. Node processing load remains nearly constant.
. No extensive changes to the consensus layer are required.

Therefore, OTAK-PQ can act as a complementary security layer, not a replacement for existing signature algorithms.

Staged architecture for the future

OTAK-PQ can act as a transition layer between the current architecture and a possible future migration to Post-Quantum cryptography.
Especially in current conditions where:

. Computational infrastructure is still limited.
. Full migration to heavy PQ algorithms has high operational costs.

Adopting the OTAK-PQ security model as an alternative solution results in:

. Reduced exposure level.
. Maintaining network performance without noticeable degradation.
. Preparing account structures for future migration.

Easy migration with OTAK-PQ

In current blockchain architectures, the account identity, public key, and signature algorithm are directly dependent on each other. This dependency makes migrating from current signature algorithms like ECDSA to Post-Quantum algorithms such as:

Falcon
Dilithium
SPHINCS+

a complex and costly process, because:

. The structure of public keys and signatures changes.
. Verification logic must be updated.
. Typically, simultaneous support for multiple algorithms (Hybrid mode) is required.

This can increase node processing load and reduce network efficiency.

Migration challenges

1. In traditional models:

. The account key is directly dependent on the signature algorithm.
. Changing the algorithm requires changes at the protocol and network consensus level.
. Coexistence of multiple algorithms increases operational complexity.
These factors can lead to:
. Increased validation latency.
. Increased node resource consumption.
. Decreased network throughput.
. Complexity in the gradual migration process.

2. Role of OTAK-PQ in simplifying migration

In OTAK-PQ, the account structure is designed such that transaction signing operations are separated from the long-term ownership layer of the account.

The conceptual model is as follows:

Seed
↓
Access Keys
↓
Merkle Tree
↓
Merkle Root (stored in State)
↓
One-Time Child Keys
↓
Transaction Signatures

In this architecture, Access Keys act as the Root of Trust, and operational transactions are only signed by child keys.

This means:

. Child keys act as the operational signing layer.
. Long-term keys (Access Keys) are not used at the on-chain signature level.
. The signature layer is partially decoupled from the account identity layer.

Reason for facilitated migration in the OTAK-PQ security model:

. This relative decoupling makes it possible to generate child keys with different algorithms in the future.
. The signature layer can be upgraded without changing the core account structure (Seed and Ownership).
. Migration to new algorithms can be performed primarily at the child key layer and transaction signing mechanism, without necessarily requiring fundamental changes to the account ownership model, Seed model, or account recovery process.

For example:

. Current state: Merkle Root based on a set of ECDSA child keys.
. Future: Merkle Root based on a set of Post-Quantum child keys such as Falcon, Dilithium, or other network-approved algorithms.
In both cases, the account ownership model, Bootstrap process, and Seed-based recovery mechanism can remain essentially unchanged.

While:

. The master Seed remains unchanged.
. The account ownership model is preserved.
. The permission structure remains extendable.

Architectural conclusion

OTAK-PQ, by transferring the responsibility of signing transactions to child keys, enables the creation of a flexible layer for the future evolution of cryptographic algorithms.

This approach can:

. Reduce the direct dependency of an account on a single signature algorithm.
. Simplify the gradual migration path.
. Allow the network to adapt to future algorithms with minimal changes to the core structure.

Method for migrating existing accounts to OTAK-PQ after full network deployment

For users who have an active account and a history of outgoing transactions before OTAK-PQ activation, several migration paths with different levels of risk reduction can be defined.

The important point is that signatures recorded on the blockchain are permanent and cannot be deleted after publication. Therefore, any account that had on-chain signature history before OTAK-PQ deployment will always retain part of its cryptographic history.

OTAK-PQ enables significant risk reduction for existing accounts, but the degree of risk reduction is not the same across different migration methods.

Method One (highest level of risk reduction and recommended method)

Create a new account with a new seed

In this method, the user generates a new Seed, creates a completely new account, and activates the account.

After activation, assets are transferred from the old account to the new account, and operational use of the old account is stopped.

Advantages of this method:

. No transaction signature history from the old account.
. Complete separation of assets from the old account’s cryptographic history.
. Highest level of risk reduction against long-term threats.

The cost of this method is simply managing and safeguarding the new Seed.

Method Two (risk reduction without needing a new seed)

Create a new account from the same seed

In this method, the user uses the same existing Seed and creates a new account via a new derivation path in the TRC-102 standard.

Example path:

m/44'/195'/0'/0/1
The new account has independent public and private keys and can be recovered with the same Seed.

After creating the new account, assets are transferred from the old account to this new account.

Advantages of this method:

. No need to create a new Seed.
. Maintains compatibility with the current backup structure.
. Creates a new key set for future activities.

If the new account has no on-chain signature history before migration and its Bootstrap process is completed according to OTAK-PQ, its exposure to threats based on signature analysis will be significantly lower than that of the original account.

Method Three (preserving existing account identity)

Replace the account’s Access Keys

In this method, after transferring assets to the OTAK-PQ structure, the user can, via an AccountPermissionUpdateContract transaction signed by a valid child key and its corresponding Merkle Proof, replace the account’s Access Key set with a new set of Access Keys.

After the changes are recorded, the new Merkle Root corresponding to the new account security structure is stored in the network State, and future transactions will be validated based on the new structure.

This method can be useful for accounts that have a known identifier, activity history, or operational dependencies.

However, it should be noted that:

. Past signature history remains on the blockchain.
. Replacing keys does not erase past cryptographic records.
. This method can reduce some future risks, but it does not turn the account into the equivalent of a newly created account with no on-chain signature history. Because past signature history remains on the blockchain, exposure related to those records will not be completely eliminated, although the account’s future activities will be conducted under the OTAK-PQ security model.

Author: Ali (@alichatme)

[xxo1shine]

@alichatme Interesting idea. Overall, the proposal seems to shift the problem from long-term signature exposure to on-chain state consistency and key lifecycle management. It would be helpful to provide a more complete state management model so the engineering feasibility can be evaluated more thoroughly.

In addition, the proposal introduces a fairly heavy state management and validation workflow (Merkle proof verification, child-key lifecycle tracking, and consumed-state consistency management). A more detailed complexity analysis would be valuable, including:

• How consumed child keys are represented and tracked on-chain.
• The expected on-chain state growth model over time.
• Validation overhead introduced by Merkle proof verification.
• Storage, synchronization, and pruning costs for full nodes.
• The operational complexity of replenishing or rotating child-key sets once they are exhausted.

These details would help assess the scalability and practical deployability of the design.

[Federico2014]

Thanks for this well-structured proposal. The security architecture is clearly articulated, and the threat model boundaries are honestly drawn.

There is a closely related design in the Ethereum ecosystem worth referencing: EIP-8202's Ephemeral secp256k1 scheme (scheme_id 0x01). The two proposals share the same core approach — deterministic child keys from a master seed, Merkle root stored on-chain, Merkle proof submitted with each transaction — and rely on the same security pivot: shifting from "ECDSA discrete log hardness" (quantum-breakable) to "hash preimage resistance" (quantum-safe).

One engineering difference stands out:

• EIP-8202 Ephemeral uses transaction nonce as the Merkle leaf index. Nonce naturally increments per transaction, so a node verifies merkle_proof against (merkle_root, nonce) — no separate "consumed key set" storage. State overhead is zero.
• OTAK-PQ proposes explicit consumed-key tracking in network State. This introduces unbounded state growth that would need a pruning/archival strategy — the exact concern @xxo1shine raised.

The nonce-as-index approach might be worth adopting here, as it sidesteps the consumed-set state problem entirely while preserving the same security guarantees.

A second point: the EIP-8202 discussion identified mempool exposure as the unresolved weakness of ephemeral secp256k1 — the public key is visible in the mempool during the block interval before confirmation, and a sufficiently fast quantum attacker could crack it and front-run. This proposal claims that "the signature is published only after the child key is deactivated," but that ordering is not enforceable at the protocol level unless the network moves to encrypted mempools (which would be a separate, major change). Worth clarifying whether this scenario is accepted as an explicit non-goal, or if there is a proposed mitigation.

[GordonLtron]

Regarding the mempool vulnerability raised above: If encrypted mempools are out of scope, a Commit-Reveal envelope could mitigate the quantum front-running vector without heavy consensus changes.
Phase 1 (Commit): The user broadcasts a hash of the transaction payload and the intended child key, securing their place in the sequence without revealing the ECDSA signature.
Phase 2 (Reveal): The actual signature and Merkle Proof are broadcasted only after the Commit is packed. A quantum attacker cannot retroactively alter the Commits already secured in the preceding blocks. Alternatively, heavily restricting the Expiration parameter for OTAK-PQ transactions could shrink the mempool exposure window to a duration unfeasible for near-term quantum decryption.

[alichatme]

I sincerely thank all of you for this deep and valuable technical discussion. The feedback regarding state growth, child key lifecycle management, replay prevention, and mempool exposure has been extremely helpful.

I would like to clarify an important point about the consumed child key tracking model in OTAK-PQ.

In the OTAK-PQ architecture, the network does NOT store any consumed-key set, bitmap, or list of used child keys. As explained in the proposal, the OTAK-PQ-related state per account is minimal and includes only:

· merkle_root
· bootstrap_completed
· last_used_child_index

The validation model is based on mandatory sequential ordering of child keys.

For each new transaction, nodes verify:

1. The transaction signature is valid.
2. The Merkle Proof is valid against the Merkle Root stored in the account.
3. The provided child key exactly matches the next expected index.

After successful transaction confirmation, last_used_child_index is updated accordingly.

In fact, last_used_child_index serves the same role as a nonce in the EIP-8202 model, but specifically for the child key lifecycle and without requiring transaction history scanning for account recovery.

As a result:

· No list of consumed keys is maintained.
· No bitmap or consumed-key set is required.
· No state growth occurs per transaction.
· The OTAK-PQ-related state size per account remains constant regardless of transaction count.

Therefore, no pruning or archival mechanisms are needed for consumed child keys.

This sequential index model also naturally prevents replay attacks, because any transaction referencing a previously used child key will be rejected during validation.

Thank you also for referencing EIP-8202 and the Ephemeral secp256k1 discussion. The conceptual similarities are understandable, but OTAK-PQ is not merely a transaction validation model. This proposal defines a complete account lifecycle including Bootstrap Pending, Bootstrap, Active State, Recovery Model, and Migration Path.

Unlike many other similar proposals, OTAK-PQ ensures that Access Keys are never exposed on the blockchain – not even during the Bootstrap process, where the Bootstrap request signature is not recorded. Therefore, even if a future quantum computer were able to break the signature of one or more Child Keys, it would still not be able to recover the Access Keys or control the account, because:

· Access Keys have never published a signature on the blockchain.
· The relationship between Access Key and Child Key is a one-way function.
· Each consumed Child Key is immediately deactivated.

Regarding mempool exposure, we fully agree that this is a real limitation of current blockchain architectures and is not specific to OTAK-PQ.

The Commit-Reveal proposal by GordonLtron is also very interesting and valuable. This model could reduce the information exposure window in the mempool without requiring changes to the signature algorithm.

However, in the current version of OTAK-PQ, we prefer to keep the proposal focused on its core objective: eliminating reusable signing authority and creating complete separation between Access Keys and the operational child key lifecycle.

A general-purpose Commit-Reveal mechanism may be worth exploring as a separate, independent TIP in the future — a solution that would likely benefit not only OTAK-PQ but the entire TRON ecosystem.

Thank you all again for this constructive and valuable technical discussion. I look forward to hearing more of your expert and insightful feedback.