Repository navigation
OTAK-NES: A Blockchain Security Architecture for Non-Exposure of Long-Term Authorization Keys #890
Description
Eliminating public signature exposure of an account when sending a transaction to the network, in order to shift the threat model from the entire account and all assets under its control to the specific transaction and the specific asset being transferred — using the OTAK-NES security architecture — is now available to the community.
Preventing threats based on the exposure of private-key signatures of an account when sending a transaction to the network, and reducing the risk of exposing the assets held by those keys, is now implementable on blockchain networks based on the OTAK-NES architecture.
Protection of transactions during on‑network validation can be achieved through different approaches:
-
Post‑Quantum Signatures: This model increases computational hardness, but it cannot, by itself, shift the threat model from the entire account to a specific transaction.
-
OTAK‑NES Architecture: In addition to shifting the threat model from the level of all assets under control to the level of the specific asset being transferred, OTAK‑NES takes an important step in advancing blockchain security. Beyond this, the architecture contributes to reducing the risk of public signature exposure on the blockchain in several other important ways, including but not limited to:
. Using one‑time Child Keys derived from Access Keys, so that every operational signature is performed with an operational key that is independent of the account's long‑term authorization keys.
. Ensuring that a compromised Child Key does not, by itself, expose the Access Key or any other Child Key.
. Preventing reuse of Child Keys and reducing the risk of replay attacks through mandatory sequential Child Key indexing.
. Preventing nonce reuse issues at the level of each operational key, by using each Child Key exactly once.
. Limiting the impact of any potential exposure from the entire account level to a single key and a specific transaction, so that the exposure of one operational key does not, by itself, compromise the private key with access to the entire account's assets.
This architecture, designed with long‑term blockchain security objectives in mind, is now ready to enter the formal review and acceptance process as a Pull Request, following the completion of the revision period and subject to positive feedback from security experts. We always welcome technical feedback, comments, and suggestions.
Activity
alichatme commentedon Jun 7, 2026
tip: XXXX
title: OTAK-NES: A Blockchain Security Architecture for Non-Exposure of Long-Term Authorization Keys
author: Ali (@alichatme)
status: Draft
type: Standards Track
category: Core
created: 2026-06-07
discussions-to: #890
Summary
OTAK-NES: One-Time Access Keys – Non-Exposure Security
Long-Term Exposure of Published Signatures to Future Threats
Every account in a digital asset network, when transferring assets—even in very small amounts—signs a transaction using its private key and submits the generated signature to the network for validation.
This signature is exposed to various network components during transaction propagation and validation, including nodes. After the transaction is confirmed, the signature, along with transaction-related data, is permanently recorded in the blockchain history.
Consequently, each time a private key is used to sign a transaction, a new sample of cryptographic data associated with that key is made available to future adversaries. This data remains accessible for a very long period of time.
If an attacker were able to recover the private key corresponding to an account from a published signature and other related public data—using future quantum computers, Shor's algorithm, future advances in mathematics or computational power, cryptanalytic progress, implementation errors, or software bugs—the threat would not be limited to the past transaction or the transferred asset. Access to the private key would mean access to the account's signing authority and, therefore, to all assets held by that account.
In other words, the core problem is not merely the security of a transaction that has already occurred; rather, the exposure of a long-term private key can compromise the security of all assets that remain under the control of that same key.
This creates a critical characteristic in architectures based on long-term signing keys: a single key may be used over many years to sign numerous transactions, leaving the entire account's authorization dependent on one persistent key.
OTAK-NES Architecture: Shifting the Threat Model from the Entire Account to a Single Transaction
OTAK-NES is designed to eliminate this dependency. In this architecture, keys that have access to account assets (Access Keys) are not used to sign operational transactions. Each transaction is signed by an independent one-time key (Child Key).
All Child Keys have private keys distinct from the Access Keys and from other Child Keys of the account, and each Child Key is permanently deactivated after a single use.
Therefore, even in a scenario where an operational Child Key is compromised in the future, the scope of that event is limited to that specific Child Key and its operational authority, and it does not extend to the Access Key or other Child Keys of the account.
A Paradigm Shift in the Threat Model
This proposal introduces one-time access keys (or "Child Keys" for short) to the blockchain network.
A Child Key introduces a fundamental paradigm shift in blockchain security: it changes the threat model from the entire account and all assets under its control to a single transaction and the specific asset being transferred.
In conventional blockchain architectures, the exposure of a single operational signature from an Access Key can put all account assets at risk.
Under the OTAK-NES security architecture, long-term authorization keys of an account (Access Keys) do not directly produce operational transaction signatures on-chain.
Instead of allowing Access Keys to sign transactions directly, OTAK-NES introduces one-time authorization keys ("Child Keys") derived from an Access Key according to the TRC-102 hierarchical derivation model. Each Child Key is authorized through a Merkle Proof against a Merkle Root committed to during account creation and the Bootstrap process.
Each Child Key is valid for exactly one successful transaction. After that transaction is accepted by the network, the Child Key is permanently marked as consumed and cannot authorize another transaction.
This architecture achieves a critical security property: if a Child Key or its signature is compromised in the future, the potential impact at the network and account level is limited to that operational key, that transaction, and the specific asset being transferred—not to all account assets.
Consequently, the Access Keys of the account and the assets under their control are not exposed when a Child Key is compromised.
If, in the future, an attacker could recover the private key of a Child Key using advanced cryptographic methods or new computing technologies, because the Child Key's private key is distinct from all Access Keys of the account, the incident would only affect that specific consumed Child Key. Since that key has already been deactivated:
Consequently, the OTAK-NES architecture limits the impact of any possible security incident to a single Child Key, the specific asset being transferred (not all account assets), and prevents its spread to other components of the account.
This architecture is independent of the underlying signature algorithm. It can operate with existing signature algorithms as well as future post-quantum signature schemes. Its objective is not to replace signature algorithms, but to eliminate continuous exposure of authorization-key signatures and fundamentally change how the scope of a potential threat is contained on the blockchain.
Non-Exposure of Access Key Signatures
The principle of non-exposure of signatures from keys with access to all assets of an account (Access Keys), although currently considered an optional aspect in some blockchain architectures, may become an important security requirement for blockchain architectures over time, as computational sciences advance and highly powerful computers, including quantum computers, emerge.
Beyond the above, there is another fundamental question:
Why would one refrain from limiting the potential scope of a compromise during transaction submission and signature publication—from the entire account and all assets under its control, to that specific transaction and the specific asset being transferred?
Even if we assume that a transaction signature alone provides complete cryptographic security and that publishing that signature creates no direct threat to the account's private key—although no signature algorithm, including post-quantum schemes, has ever made such a claim—the transaction may still be observed or processed by various network components before finalization and block inclusion, including:
Therefore, even with a very strong signature algorithm, the exposure of a transaction and its signature in the public network environment represents an independent layer of exposure that cannot be eliminated solely by increasing the strength of the signature algorithm.
This raises another question:
Why should blockchain architectures not reduce the threat model as much as possible—from the entire account and all assets under its control—to the smallest operational unit, namely a specific operational key and a specific transaction?
The OTAK-NES security architecture is introduced precisely on this principle: reducing the potential scope of a compromise at the account level. It is designed for implementation on existing blockchain networks.
This approach can, in the long term, be regarded not only as a security feature, but as an architectural principle and a security standard for blockchains.
Blockchains that have adopted user security and asset protection as one of their fundamental principles can move toward evaluating and, subject to technical validation, implementing the OTAK-NES architecture.
One-Time Access Key (Child Key)
A Child Key is a one-time authorization key derived from an account Access Key using the TRC-102 hierarchical derivation model, or similar models based on the same principles in other networks.
A Child Key is considered valid only if:
Any transaction that does not satisfy these conditions MUST be rejected during transaction validation.
After a transaction is successfully accepted, the corresponding Child Key is permanently marked as consumed in the network state and can never be reused.
Only Child Key signatures appear in the blockchain transaction history. Long-term authorization keys never participate in normal operational transaction signing, thereby significantly reducing exposure to attacks that rely on analysis of long-lived signatures.
Consequently, even if the signature of a previously used Child Key is compromised in the future:
How OTAK-NES Architecture Defeats Signature Analysis Threats — Even When They Become Practical at the Network and Account Level, Including but Not Limited to Quantum Threats — at 4 Levels
First, the importance of the OTAK-NES security architecture and the non-exposure of the account's public key.
In all digital signature systems, whether classical (such as ECDSA) or post-quantum (such as ML-DSA, Falcon), transaction verification depends on network components having access to the signer's public key. In other words, for a node or validator to verify that a transaction was genuinely signed by the private key holder, it must have the corresponding public key. Therefore, the public key is either included directly in the transaction or made available to nodes in some form to complete the verification process. This principle is identical for both classical and post-quantum signature algorithms, and the network's signature algorithm does not change the fundamental requirement of "public key exposure."
The Role of the Public Key in Signature Analysis Threats, Including Quantum Threats
Based on the latest published research on signature analysis threats — including but not limited to quantum threats — there is a critical difference in how an attacker can compromise a signature to analyze and recover the private key when both the public key and the signature are available:
To better understand the importance of analyzing the threat to both the public key and the signature simultaneously, it is useful to review the account creation process in a blockchain:
Private Key: The wallet first generates the account's private key by producing a secure random value appropriate for the network's signature algorithm.
Public Key: The public key is then derived from the private key using a one-way function.
Digital Signature: The signature is generated using the signature algorithm and the private key, applied to the message or its hash.
As described, both the signature and the public key share a common characteristic: they are both derived from the private key.
Having both the signature and its corresponding public key provides an attacker with a significant advantage in signature analysis threats, including quantum threats. This gives the attacker two paths toward the same goal.
The public key is exposed along with the signature when a transaction is sent to the network. An attacker can use it immediately or store it for later analysis.
Access to signatures is always possible, as signatures are typically recorded permanently in the blockchain history.
Analysis of the Critical Window
From the moment a transaction is sent to the network, its public key becomes accessible to various network components — such as the mempool, nodes, block producers, validators, and other network participants.
Any of these components, or any attacker with access to this data, can collect the public keys associated with Access Keys of accounts across the network and store them for future analysis and threats. This data can be used immediately or at any later time for targeted attacks.
Preventing the exposure of the Access Key's public key can create an independent defensive layer, because the public key of the Access Key — which controls account assets — is not published on the network under the OTAK-NES security architecture and therefore does not fall into the attacker's hands.
The OTAK-NES Solution for Non-Exposure of Public Keys on the Network
OTAK-NES pursues as one of its main goals not only preventing the exposure of private keys, but also preventing the exposure of the public keys of keys that have access to account assets.
This architecture intelligently neutralizes this threat at the network level:
1. Key Separation: Access Keys and Child Keys Are Distinct
In OTAK-NES, two types of keys with completely different roles are defined:
2. The Process of Non-Exposure of Access Key Public and Private Keys in the OTAK-NES Architecture
Under the OTAK-NES security architecture, the wallet creates two keys when the account is created:
With the requirement that both keys have independent and distinct public/private key pairs.
After account creation, under the OTAK-NES architecture, the first transaction is limited to the Active Key transaction for registering the Owner Key's Merkle Root in Bootstrap. After the Owner Key's Merkle Root is successfully registered, the registering Active Key is deactivated by the network according to the OTAK-NES protocol. From that point on, all operational transactions — such as creating a new Active Key for the account or sending a transaction — are accepted and validated by the network only and exclusively through Child Keys. Any transaction sent with an Access Key is rejected with a
CHILD_KEY_REQUIREDerror.Each time a new transaction is sent, a new Child Key is generated by the wallet from the Access Keys according to TRC-102, with public and private keys distinct from the main key. It signs the transaction and sends it to the network. After the transaction is confirmed, the Child Key is deactivated and then recorded in the network history.
Consequently, under the OTAK-NES architecture, when a transaction is sent, the Child Key's public key and signature are exposed to network components or potential attackers — not the Access Key's public key and signature.
How a Quantum Attack on an Account Is Thwarted at Four Levels Under OTAK-NES, Even If a Child Key Is Compromised
Assume an attacker, having obtained a Child Key's transaction signature and public key, succeeds — in a very short time, such as a fraction of a second — in recovering the corresponding Child Key's private key.
(This is a security assumption for analysis and does not imply that quantum computers are capable of such speed.)
Key Question: With this private key, can the attacker send a new transaction to the network?
Level 1: The Recovered Key Is Not the Access Key
Assuming the signature analysis succeeds, the quantum computer in this scenario calculates and obtains the Child Key's public and private key.
However, this public/private key pair does not belong to the account's Access Key. Therefore, recovering a Child Key's private key does not mean recovering the Access Key or gaining direct access to all account assets.
Level 2: Creating a New Child Key
Even with a Child Key's private and public key, the attacker cannot use that same Child Key to create a new valid operational transaction.
Each Child Key in OTAK-NES is used for a single, specific transaction and is one-time-use only. After successful transaction confirmation, the Child Key is marked as consumed and can no longer be used to send a new or repeated transaction.
The private key of Child Key i does not, by itself, generate or reveal the private key of Child Key i+1.
Level 3: The Asset Being Transferred Remains Safe Even If Signature Analysis Threats — Including but Not Limited to Quantum Threats — Become Practical
During the Child Key transaction confirmation process, two scenarios are possible if a signature analysis threat becomes practical:
1. Transaction Confirmed: The transferred asset is sent to the destination account before the attacker can complete the signature analysis and discover the private key.
Therefore, recovering the Child Key's private key after transaction confirmation does not give the attacker new authority to access the sent asset or the assets controlled by the Access Keys.
2. Transaction Not Confirmed: The asset has not yet been transferred, and the transaction is still in the validation process.
If we assume the attacker could reconstruct the Child Key transaction using the same public and private key and resend it to the network in a fraction of a second, even in this hypothetical scenario, the key recovery time is never truly zero. Even under the most conservative assumption — treating this time as effectively zero — the reconstructed transaction would still enter the network's validation process after the original Child Key transaction.
Under the current design of the TRON network, it is not possible for an attacker to send a reconstructed transaction ahead of the original transaction.
As a result, the reconstructed transaction is placed in the transaction queue after the original transaction. Once the original transaction is confirmed, the reconstructed transaction, under the OTAK-NES architecture, encounters a
CHILD_KEY_CONSUMEDerror.Other blockchain networks can also add this independent defense layer by supporting OTAK-NES and, provided they enforce sequential transaction ordering.
Level 4: The Account Continues Operation with the Same Level of Security
Assuming the Child Key has been recovered and its public and private keys are in the attacker's possession, the main Access Key remains uncompromised.
Child Keys are one-time-use, meaning they are deactivated after their first use. Additionally, Child Keys have public and private keys that are distinct from the Access Keys. Therefore, even if a Child Key's public and private keys are discovered, the account can continue normal operation on the network with the same level of security as before.
This security property under the OTAK-NES architecture is the strongest reason for its adoption.
The Best Approach to Protecting a Network from Future Signature Analysis Threats, Including but Not Limited to Quantum Threats
The best approach for a network to remain protected from future signature analysis threats — including but not limited to quantum threats — is to use multiple independent defensive layers, rather than relying on a single cryptographic layer alone.
Using a post-quantum signature algorithm provides one strong defensive layer against such threats.
However, if one day this cryptographic layer is broken by an attacker using an analytical threat, the important question becomes:
How will the network protect assets and transactions after the cryptographic layer is broken?
The answer is clear:
Consequently, even if an attacker can recover a Child Key's private key, breaking the cryptographic layer alone is not sufficient to mount a successful attack.
OTAK-NES as a Complementary Security Layer
OTAK-NES cannot and should not replace post-quantum signature algorithms on its own.
However, in combination with them, in addition to reducing the information available for attacking keys with direct access to account assets, and by prohibiting direct Access Key transaction submission and using one-time Child Keys, OTAK-NES creates a new architectural security layer.
More importantly, the OTAK-NES architecture attempts to answer the following question:
If quantum threats one day become practical — even with a powerful post-quantum signature algorithm — what mechanism will the network have to maintain secure operation and defeat the attack?
OTAK-NES answers that breaking one operational key should not mean breaking the account.
Even if an attacker can recover a Child Key's public and private key, the consumed Child Key should not be reusable for a new transaction, and the main Access Key should not be exposed to attack.
Therefore, if a network supports:
Breaking the primary cryptographic layer will not lead to account compromise or asset theft.
Minimum Required Defense Layers for a Secure Network
The Importance of Layered Security
Recent blockchain research and market trends indicate that users are increasingly choosing networks that meet minimum security standards and have a clear roadmap for future security enhancements.
Conversely, networks that lack these fundamental requirements or a transparent strategy for addressing future security threats may experience user migration toward more secure alternatives. This trend has intensified in response to security incidents—including various signature analysis threats (including but not limited to quantum attacks), digital asset thefts due to network security flaws, software bugs, and other vulnerabilities—demonstrating that "security" has become a key selection criterion for blockchain users.
The Most Prominent Threat with High Publicity: Quantum Threats
Quantum security for a blockchain cannot be defined merely by selecting a post-quantum signature algorithm. A secure network must be able to protect users, keys, transactions, accounts, and the network itself across multiple independent layers. A weakness in one layer should not necessarily lead to the complete failure of other layers.
Under modern approaches, blockchain security can be viewed as a multi-layered defensive architecture. Each layer addresses a specific level of threats, and if one layer is weakened, other layers—depending on the threat model and architectural dependencies—can still protect assets and network functionality.
Even the best wallet and the best signature algorithm are insufficient for ensuring security in today's world. A network must have appropriate multi-layered defense mechanisms at the protocol level.
A secure network must be able to:
1. First Defense Layer: Network Signature Algorithm
Why Should Networks Migrate from ECDSA to Post-Quantum Signatures?
The security of digital signatures in blockchain networks depends on whether an attacker can derive the private key from public keys and published signatures, or forge a valid signature.
In ECDSA, security is based on the difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP). This problem is sufficiently hard for current classical computers, but a powerful quantum computer running Shor's algorithm could solve it efficiently.
Therefore, if an attacker gains access to a sufficiently capable quantum computer, simply increasing ECDSA key sizes cannot address the fundamental problem. The real solution is migrating from ECDSA to a Post-Quantum Cryptography (PQC) signature algorithm—one whose security is based on a different mathematical problem that is resistant to known quantum attacks.
Why Increasing ECDSA Key Size or Hardness Doesn't Provide Quantum Immunity
The difference lies in the type and structure of signature algorithms. Post-quantum signature algorithms are developed with fundamentally different designs compared to ECDSA, specifically to resist signature analysis threats including but not limited to quantum threats.
Increasing ECDSA key size—for example, from P-256 to P-384 or P-521—can only increase classical security. However, due to the inherent vulnerability of ECDSA to quantum attacks (especially Shor's algorithm), even making computations harder or keys larger cannot make it resistant to quantum threats.
The Role of OTAK-NES on the ECDSA Signature Algorithm
Shor's algorithm and similar algorithms for signature recovery require both the signature and the account's public key. OTAK-NES not only prevents the exposure of private keys but also prevents the exposure of Access Key public keys, shrinking the threat scope from the entire account to the specific asset being transferred. If the network supports sequential transaction validation, OTAK-NES can defeat a quantum attack at four levels even if the attack succeeds.
The Real Solution: Post-Quantum Signature Algorithms (PQC)
To counter signature analysis threats—including but not limited to quantum threats—post-quantum signature algorithms can be used, which are built on different mathematical foundations, including:
These algorithms, despite their post-quantum resistance, come with costs such as increased key and signature sizes. For example, the ML-DSA-44 signature size is approximately 2,420 bytes, while ECDSA signatures are typically much smaller.
Therefore, migrating from ECDSA to PQC is not merely about using "larger keys"; it means changing the security foundation of signatures from a problem that Shor's algorithm can solve to a structure designed to resist quantum threats.
The signature algorithm is one of the most important defense layers for a network. However, it should not be assumed that the signature algorithm is the first and last defense layer, and that migrating to post-quantum signatures alone provides all necessary protection.
A network should use an algorithm whose security level can be evaluated based on public analysis, established standards, and specific parameters. In the post-quantum domain, simply seeing the label "Post-Quantum" on an algorithm does not mean that all schemes are equal in terms of security, maturity, parameters, implementation complexity, or confidence levels.
NIST has finalized FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA as post-quantum signature standards. FALCON is also being standardized as FN-DSA, and the PQC ecosystem continues to evolve.
Therefore, "post-quantum readiness" should be accompanied by several questions:
Major Families of Post-Quantum Signature Schemes
At the architectural level, post-quantum signature schemes can be categorized based on their underlying mathematical assumptions:
a) Lattice-based Schemes
b) Hash-based Schemes
c) FALCON / FN-DSA
NIST Security Categories for Post-Quantum Signature Algorithms
NIST does not rank post-quantum algorithms from first to fifth; instead, it defines a Security Category for each parameter set.
These categories indicate the computational resources required to break a specific parameter set. In summary:
However, an important note: these numbers do not mean that a Category 5 algorithm provides exactly "256 bits of quantum security." This categorization is a comparative metric for attack difficulty that NIST uses to evaluate different parameters.
A higher Category does not automatically mean an algorithm is "absolutely better" for all use cases. Increasing security levels typically comes with increased key size, signature size, processing time, and storage and transmission costs.
Therefore, in a blockchain network, algorithm selection is not based solely on the highest Security Category; the required security level, key and signature sizes, generation and verification speed, bandwidth, transaction capacity, and storage costs must also be considered simultaneously.
Why Does NIST Assign Security Levels to Post-Quantum Signatures?
When we say an algorithm is post-quantum (PQC), it does not mean the algorithm has "absolute immunity" or a fixed number like 100. The concept of PQC is that the algorithm is designed to resist known quantum attacks; however, no cryptographic algorithm can be declared immune forever and against all types of attacks with a fixed number.
For this reason, NIST uses Security Categories instead of saying an algorithm has "90% or 100% immunity."
What Is the Floor and Ceiling of This Categorization?
In NIST's five-tier framework:
However, this by no means implies that Category 5 represents the "highest possible security in the world" or a mathematical ceiling for cryptographic security. NIST defined these five levels solely for standardization and comparison.
Therefore, we should not say:
Category 5 = 100% quantum immunity
But rather:
Category 5 = A very high level of attack difficulty that, within NIST's framework, is comparable to the difficulty of a full key search against AES-256.
Why Isn't a "100% Immunity" Signature Produced?
Because cryptographic security is not an absolute and fixed property. The security of an algorithm depends on factors such as:
An algorithm that is highly secure against the best known attacks today could be broken by a new attack method discovered in the future. For this reason, cryptographic standards use security levels and specific security assumptions rather than claiming "100% immunity."
If a Blockchain Wants Maximum Practical Security, What Should It Do?
The solution is not simply to push an algorithm to Category 5 and then claim the network is "100% quantum-safe." A blockchain must create a multi-layered defense architecture:
Conclusion
The real goal of a blockchain should not be to reach a hypothetical number like "100% immunity." The goal should be to create the greatest possible practical and provable security margin against the relevant threat model.
In simple terms:
PQC does not mean "absolute security"; PQC means shifting the security foundation to a structure designed to resist known quantum attacks.
And Category 5 is not the end of security; it is the highest level NIST has defined within this five-tier framework for comparison.
Why Should a Network Still Adopt OTAK-NES Even If It Supports Post-Quantum Signatures?
2. Second Defense Layer: Sequential Transaction Validation
Sequential transaction validation can be an important security layer in network architecture.
In a model with ordered confirmation, the network can establish a specific sequential relationship between related transactions, ensuring that a later transaction cannot invalidate the result of a previous one simply by arriving at a node earlier or using mechanisms like fee manipulation to push a reconstructed transaction ahead of the original.
However, transaction ordering alone does not prevent all types of MEV or front-running attacks, as these depend on the mempool model, ordering policy, consensus, and transaction execution.
Ordering Does Not Prevent Batch Processing
An important point: ordered confirmation does not necessarily mean "only one transaction at a time." A large exchange or service can prepare and send many transactions as a batch.
For example:
In this model, the network treats that transaction batch as a single transaction for ordering purposes, maintaining transaction order regardless of whether transactions are submitted individually or in batches. What matters is maintaining the sequential validation relationship based on transaction arrival, regardless of whether they are submitted singly or in groups.
Sequential validation can be effective against a range of attacks, including:
Additionally, sequential validation in a network supporting the OTAK-NES architecture ensures that even if a quantum attack succeeds and an attacker reconstructs a transaction in a fraction of a second, they cannot insert the reconstructed transaction ahead of the original.
Furthermore, since each Child Key is only authorized for one transaction under OTAK-NES, after successful network validation, the Child Key is deactivated and then recorded in the network history. Therefore, a reconstructed transaction entering validation after the original transaction will be rejected with a
CHILD_KEY_CONSUMEDerror.3. Third Defense Layer: Wallet Security
A wallet is not just a user interface; it is responsible for key lifecycle management, signature generation, key selection, and transaction information display.
A secure wallet should, at account creation, not only create two keys with distinct public/private key pairs but also distribute operational permissions between them.
For example:
The core principle is:
"The key used for long-term account recovery and control should not be the same key that signs everyday transactions."
In TRON, the Account Permission and Active Permission concepts allow for the separation of certain account authorities, making the signature and permission system part of the security model.
Why Should the Wallet Periodically Change the Active Key If the Network Does Not Support OTAK-NES?
If an Active Key signs all transactions throughout an account's lifetime, a large number of signatures from that key will accumulate on-chain over time. Therefore, the wallet can implement an important defense policy:
"An account's operational key should not be repeatedly exposed beyond a specific time period or number of transactions."
The operational key of an account can be periodically replaced with a new key to prevent signature accumulation on the blockchain. In a proper design, the wallet should:
OTAK-NES Advantage in Preventing Access Key Signature Accumulation
Under the OTAK-NES security architecture, Access Keys with control over account assets are never permitted to send transactions directly to the network. All submitted transactions must use Child Keys derived from the Access Keys.
If a signature is sent directly using an Access Key, nodes will reject the transaction under the OTAK-NES architecture and return a
CHILD_KEY_REQUIREDerror to the wallet.Therefore, with network support for OTAK-NES, the need to periodically rotate Access Keys to prevent signature accumulation is completely eliminated, as Access Keys are no longer authorized to sign network transactions under this architecture.
4. Fourth Defense Layer: Long-Term Digital Asset Storage
An Account That Only Receives Assets Has a Different Attack Surface
To understand the importance of security architecture, we must consider a simple blockchain account. An account can be created, have an address, and receive assets without ever performing an outgoing transaction.
In this state, the blockchain only needs an account identifier or address to attribute incoming assets. The account is identified by an address, and a transfer transaction, after signing and validation, changes the account's asset status without requiring the destination account to be online.
The important security point:
"Receiving assets is not the same as spending assets."
As long as the account only receives assets, the only information published about the account on the blockchain is its address or identifier. Therefore, there is no data available on-chain to enable signature analysis threats or algorithms like Shor's algorithm.
This highlights a key principle: if an Access Key is not used in public or operational transactions, no signature history for that key exists for future analysis.
Everything changes with the first outgoing transaction. With the first transaction from the account, a signature is recorded in the network history, and the Access Key's public key is exposed for validation purposes.
The Best Defense Layer for an Account with a Very High Balance
If an account is created to hold a large amount of assets for long-term storage, one of the strongest strategies to reduce the signature analysis attack surface is:
"Avoid sending any operational outgoing transactions from that account if at all possible."
The reason is simple: before the first outgoing transaction, only the account identifier is publicly available. With the first transaction, the necessary data for signature analysis—including the public key and signature—becomes accessible to attackers.
Each new transaction generates more cryptographic data, which is recorded as transaction history and becomes available to potential attackers.
This principle is very similar to the foundation of the OTAK-NES security architecture: non-exposure of Access Key signatures. In OTAK-NES, keys with access to account assets are not used to sign operational transactions. All operational transactions are performed using one-time Child Keys derived from the Access Keys.
OTAK-NES: A Defense Layer for the Network and Account
OTAK-NES does not claim to replace:
Rather, it is a complementary architectural layer that redesigns the signing authority lifecycle.
In the OTAK-NES architecture:
Therefore, OTAK-NES addresses precisely where other layers do not provide a complete answer or coverage:
In conventional architectures, a long-term key may sign hundreds, thousands, or even millions of transactions during an account's lifetime.
In the OTAK-NES security architecture, each transaction is submitted with a one-time Child Key. After successful network validation, the Child Key is deactivated, and only then is its signature recorded in the network history.
This change provides an important architectural advantage:
"If a Child Key is compromised for any reason, the attacker faces a temporary, disposable operational key, not a key that has produced thousands of public signatures over the years and has access to all account assets."
Post-quantum signature algorithms attempt to counter future threats by making cryptography harder. Meanwhile, OTAK-NES limits the attack impact by shrinking the threat scope and, in the presence of sequential transaction validation, attempts to defeat an attack even if it succeeds.
These are two different problems. They complement each other but do not overlap. Additionally, OTAK-NES answers a critical question:
What If the Signature Algorithm Is Broken One Day?
If an attacker in the future can:
In conventional architectures, compromising an Access Key can be extremely dangerous because the same key may have a long history of operational authorizations and could still be valid for future transactions.
In OTAK-NES, the architectural goal is that:
This is the philosophy of multi-layered defense in a network with the help of the OTAK-NES architecture.
Core Security Principles of the OTAK-NES Architecture
The core security principles of the OTAK-NES architecture are founded on the following pillars:
1. Non-Exposure of Direct Access Key Signatures on the Network
Under the OTAK-NES architecture, nodes validate exclusively transactions signed with a Child Key. Any transaction sent directly from an account's Access Keys to the network is returned to the origin with the CHILD_KEY_REQUIRED error. As a result, the Access Key signature is never recorded in the blockchain history.
2. Restricting All Submitted Transactions to Child Keys
After migration to OTAK-NES, all transactions submitted to the network are sent only with Child Keys that are derived from one of the account's Access Keys, in accordance with the TRC-102 standard and compatible with the network's intended post-quantum signature algorithm.
Under the principles of the OTAK-NES architecture, after the network's full migration, transaction acceptance is restricted exclusively to transactions signed with a Child Key, and any other transaction — including those sent with an Access Key — is rejected with the CHILD_KEY_REQUIRED error.
3. Seed Ownership and Child Key Derivation from Access Keys
Only the legitimate owner of the account who possesses the Seed can derive Child Keys from the Access Keys.
The process of deriving a Child Key from the account's Access Key depends not only on the private key, but also on two other fundamental components — Seed (as the ultimate root) and Chain Code (as the inseparable component of the Extended Private Key).
The importance of the Seed and Chain Code becomes evident when we recognize that an attacker, even by recovering a signature and obtaining the private key, cannot extract the Seed and Chain Code from the private key through reversing the derivation process. The standard derivation path from the Seed to the private key is a one-way function, designed in such a way that its reversal is not possible.
The private key alone is not sufficient to generate a Child Key. The Chain Code is the inseparable component of this equation, derived solely from the Seed and held by the wallet and the owner.
Under the requirements of the OTAK-NES security architecture — and even under normal network conditions — the Chain Code is never stored, exposed, or transmitted in transactions, blocks, or network state. It is obtained solely from the Seed and held by the owner and the wallet.
"This is because Child Key generation, under the TRC-102 standard, depends on the Chain Code."
4. The Attacker's Inability to Obtain the Information Required for Child Key Derivation
In other words, even if the attacker has access to all public network information (including the Merkle Tree, consumed Child Key information, and Account State), they still cannot construct a Child Key in accordance with the OTAK-NES architectural requirements and send a valid transaction to the network, because they do not possess the Child Key derivation material — including, but not limited to, the Chain Code and Extended Private Key. And even if the attacker sends a transaction directly with the recovered private key to the network, under the requirements of the OTAK-NES architecture, the transaction is rejected by the network and returned to the origin with the CHILD_KEY_REQUIRED error.
This distinction is critically important:
Consequently, even if an attacker in the future can recover the ECDSA private key of an old account from its historical signature, this recovery cannot automatically provide them with the information required to generate Child Keys under the OTAK-NES architecture; provided that the network has fully migrated to the OTAK-NES architecture.
This is the very barrier that OTAK-NES has erected between "account signature recovery" and "obtaining the material required for Child Key derivation to submit a transaction" for the attacker.
Important Note: The core security principles of the OTAK-NES architecture are not founded on the classification, encryption, or concealment of information such as:
They are not founded on this; although this information is not publicly available to everyone, and designing a mechanism whereby the attacker cannot access any public information about the Merkle Tree or consumed Child Keys can be part of the architectural approach in the future.
The Role of Chain Code in the Security of Child Key Derivation in the OTAK-NES Architecture
In the OTAK-NES architecture, Child Keys are generated using the standard Hierarchical Deterministic (HD) Key Derivation mechanism. In this mechanism, the private key alone is not sufficient to generate a Child Key; rather, the parent key — which in OTAK-NES plays the role of the Access Key — is used in the derivation process in the form of an Extended Key that includes at minimum the Private Key and the Chain Code.
The Chain Code is a 32-byte value that, in the BIP32/TRC-102 derivation process, serves as a cryptographic input to HMAC-SHA512. Therefore, the Chain Code is not merely a simple "Salt"; it is part of the Extended Key structure and one of the essential components for deriving Child Keys.
For this reason, possessing a private key alone does not mean possessing the information required to construct a Child Key.
The conceptual structure of the derivation path is as follows:
The Seed, private key, and Chain Code play distinct roles in this structure, and possessing a private key recovered from a signature by an attacker does not, by itself, enable the recovery of the Seed. In other words, the standard derivation path from the Seed to the private key is a one-way function, designed in such a way that its reversal is not possible.
This point becomes particularly significant in the OTAK-NES quantum threat scenario.
Let us assume that an old TRON account has previously conducted transactions with ECDSA and has neither started nor completed the migration process to the OTAK-NES architecture or post-quantum signatures on the network.
Upon reaching Quantum Zero Hour, an attacker can use a historical ECDSA signature and Shor's algorithm to recover the ECDSA private key corresponding to that signature.
In this case, the attacker may gain access to the following:
However, this information does not automatically include the following:
Therefore, as explained, given the one-way nature of the Hierarchical Deterministic (HD) Key Derivation functions, the construction path from the Seed to the private key — based on the blockchain's original design and not on the requirements of the OTAK-NES architecture — is designed to be one-way, and this design is such that reversing this process is not possible.
Consequently, by recovering the signature and obtaining the private key, the attacker cannot obtain the Seed — and thus the items required for constructing a Child Key, including but not limited to the Chain Code.
In this model, only the legitimate owner of the account — who possesses the Seed and, consequently, the Chain Code and Extended Private Key required for derivation — can create the key hierarchy (or key tree structure) in their wallet and derive a new valid Child Key from the account's private key; whereas an attacker who merely possesses the private key will not have such a capability.
Practical and Decentralized Solution of the OTAK-NES Security Architecture for Quantum Day Zero
A practical solution for networks with accounts that have not completed the migration process; when the quantum threat materializes.
In the worst-case scenario, the quantum threat has materialized and the network has halted the confirmation of ECDSA transactions. A quantum attacker, by recovering the signature of a non-migrated account, possesses the public and private keys of that account. Let us assume that an old account has previously conducted transactions with ECDSA and has neither started nor completed the migration process to the OTAK-NES architecture or post-quantum signatures on the network.
Upon reaching Quantum Zero Hour, an attacker can use a historical ECDSA signature and signature-analysis algorithms — including Shor's algorithm — to recover the ECDSA private key corresponding to that signature.
In this case, the attacker may gain access to the following:
However, this information does not automatically include the following:
Therefore, as explained, given the one-way nature of Hierarchical Deterministic (HD) Key Derivation Functions, the construction path from the Seed to the private key — based on the blockchain's original design and not on the requirements of the OTAK-NES architecture — is designed to be one-way, and this design is such that reversing this process is not possible.
Consequently, by recovering the signature and obtaining the private key, the attacker cannot obtain the Seed — and thus the items required for constructing a Child Key, including but not limited to the Chain Code.
"In this model, only the legitimate owner of the account — who possesses the Seed and, consequently, the Chain Code and Extended Private Key required for derivation — can create the key hierarchy (or key tree structure) in their wallet and derive a new valid Child Key from the account's private key; whereas an attacker who merely possesses the private key will not have such a capability."
Under the OTAK-NES architecture, only Child Keys derived from an Access Key are authorized to submit transactions to the network; consequently, only the wallet that holds the original Seed can reproduce the required Extended Private Key and Chain Code locally and securely, derive a Child Key compatible with the network's post-quantum signature algorithm from the account's Access Key, and successfully send the asset transfer transaction to a secure destination account.
The Attacker's Defeat at Two Levels, Along with Two Achievements for the Account Owner, on "Quantum Day Zero" Under the OTAK-NES Security Architecture
In the worst-case scenario, when the quantum threat has materialized and the account owner has neither started nor completed the migration process to OTAK-NES or the post-quantum signature algorithm, the OTAK-NES architecture guarantees two achievements for the account owner while simultaneously defeating the attacker at two levels:
First: The two levels at which the OTAK-NES architecture defeats the attacker in spending the assets of the account whose signature they have recovered.
Level One: The Attacker's Inability to Access the Derivation Material (Seed, Chain Code, and Extended Private Key)
Even with possession of the recovered private key, the attacker cannot access the Seed; because the Hierarchical Deterministic (HD) Key Derivation process is designed to be one-way (this limitation is based on the fundamental principles of blockchain, and not on the requirements of the OTAK-NES architecture), and its reversal is mathematically and cryptographically impossible.
Consequently, the attacker cannot obtain the account's Seed by creating a reverse process from the recovered private key.
The essential components for constructing a Child Key — such as the Chain Code and Extended Private Key — are held solely by the owner and the owner's wallet, and are also necessary and essential for deriving a Child Key from the private key; the attacker, even assuming signature recovery, remains deprived of access to the components required for Child Key derivation.
Result: At the very first step, even with possession of the account's private and public keys, the attacker still lacks the information required to construct a Child Key and, consequently, is still unable to send any valid transaction to the network.
Level Two: The Network's Rejection of Access Key Transactions, Under the OTAK-NES Security Architecture
Given the recovery of the signature and the acquisition of the account's private and public keys, the attacker cannot send a transaction directly to the network; because the network, due to its full migration to OTAK-NES, does not confirm transactions sent directly with an Access Key and returns them to the origin with the CHILD_KEY_REQUIRED error.
Under this architecture, all transactions submitted after the network's migration to OTAK-NES are restricted to Child Key transactions, and the network returns transactions sent directly by Access Keys to the origin with an error.
Result: Under the requirements of the OTAK-NES architecture, the attacker remains deprived of sending a valid direct transaction to the network.
Second: The two achievements that OTAK-NES guarantees for account owners on "Quantum Zero Day."
The legitimate account owner still has the ability to transfer assets to a secure account.
In the described scenario, the network has migrated to post-quantum signatures and no longer validates ECDSA transactions. At this stage, the account owner and wallet possess all the material required to construct a Child Key. The source account generates a Child Key from its Access Keys — and, of course, compatible with the network's post-quantum signature algorithm — and by sending this transaction, transfers the assets to a secure account belonging to the owner.
The attacker — even with possession of the private key and public key that they have recovered through the analysis of ECDSA signatures recorded in the account's transaction history and now hold — still cannot spend the assets of the account belonging to the recovered signature.
Details of Asset Transfer by the Owner to a Secure Account
In the Quantum Zero-Day scenario, when an account has not completed the Bootstrap process in this architecture, or the potential migration to post-quantum signatures:
The only data the network has about the owner's account is the account address, which is derived from the hash of the ECDSA public key and is stored in the network State.
When the owner, using the Seed and Chain Code, generates a Child Key compatible with the post-quantum algorithm and sends the transaction to the network, the network has no way to verify and link the transaction between the Child Key and the owner's account.
Reason: The account has not completed the migration to OTAK-NES; therefore:
Importance of This Challenge for a Network
This issue is not merely about asset transfer in a specific scenario. One of the main goals of OTAK-NES is to enable the network in the future to employ new signature algorithms alongside the current signature algorithm, without leaving the core account logic dependent on any specific signature algorithm.
The importance of OTAK-NES lies precisely in this dynamism.
With a proper Bootstrap mechanism, and by placing the Merkle Root of accounts in the network State, it is possible to generate Child Keys compatible with various signature algorithms and use them to send transactions.
In combination with other architectures such as ATHENA, it is also possible to determine in real time, based on network policies or threat level, which signature algorithm transactions should be sent with to the network — whether globally or per account. With the Merkle Root recorded in the network State, nodes can correctly identify which account sent a Child Key transaction.
Therefore, Bootstrap is not merely an initial step for activating OTAK-NES; it is a gateway for an account to enter, in the future, a dynamic architecture for managing signature algorithms.
If such a mechanism had been considered from the beginning under the OTAK-NES architecture as part of the base design for the network, the network would have had the necessary dynamism and flexibility not only for the Quantum Zero-Day scenario but also for confronting future cryptographic threats.
Quantum Zero-Day is not the first challenge for blockchain, and it will likely not be the last. In the future, new threats, cryptographic algorithms, and even security requirements may emerge that we are unaware of today. We must take steps today for that day.
Solution for Transferring the Owner's Assets to a Secure Account, When the Network Supports OTAK-NES
In the "Quantum Zero Day" scenario, the network has migrated to the OTAK-NES architecture, and confirmation of ECDSA-signed transactions has been halted. Under these conditions, there exist accounts that:
Key Question: How can these accounts transfer their assets to a secure account?
Critical point:
This Address:
However, matching the Public Key to the Account Address alone is not proof of ownership; because in the Zero-Day scenario, the attacker may also possess the ECDSA Private Key and Public Key.
Therefore, the ZK Proof must, in addition to matching the ECDSA Public Key with the Account Address, prove that the ECDSA Key and the presented PQ Child Key are derived — according to the protocol's derivation rules — from the same valid Secret Derivation Material.
Thus:
After Quantum Zero Day, all accounts with bootstrap_completed = false enter the Legacy-Inactive state.
At the moment of Quantum Zero-Day activation, only accounts that existed before the activation of this mechanism and have bootstrap_completed == false are transferred to the Legacy-Inactive state. New accounts created after Quantum Zero-Day must follow the mandatory OTAK-NES and PQ creation/activation path, and are not subject to the Legacy-Inactive emergency path.
Why is incoming prohibited?
Why is outgoing unlimited?
Staked assets: Owner must be able to unstake.
Staking rewards: Owner must be able to claim rewards.
DeFi: Owner must be able to exit smart contracts.
Multiple destination accounts: Owner may transfer assets to several accounts.
Transaction failure: If a transaction fails for any reason, the owner must be able to try again.
Full Process Diagrams
Step 1: Network State at Quantum Zero Day
Step 2: Owner — Proof Preparation
Step 3: ZK Proof Generation
Step 4: Sending Outgoing Transactions
Step 5: Network Validation
Step 6: Final Outcome
What the attacker has:
What the attacker lacks:
Technical Argument:
To transfer assets from the account, the owner must create a Child Key — which requires the Chain Code derived from the Seed, in accordance with the TRC-102 standard and compatible with the network's post-quantum signature algorithm — and send the transaction via ZK Proof.
Under OTAK-NES, the attacker cannot send a transaction directly to the network using the Access Key from the recovered private and public keys.
Even for a Zero-Day transfer, the attacker would need the account's Secret Derivation Material, the Chain Code derived from it, child key derivation mechanisms, and a ZK Proof — whereas he has only obtained the account's public and private keys.
If the network has not migrated to OTAK-NES:
Therefore, the network must have already adopted OTAK-NES to recognize Child Keys and ZK Proofs as valid validation mechanisms.
Feature Benefit
Architectural cleanliness ZK Proof is recorded in history (consistent with blockchain)
Flexibility Unlimited outgoing transactions (unstake, rewards, transfers, ...)
Security against the defined scenario Attacker lacks Secret Derivation Material and cannot build a valid ZK Proof
No Pre-Registration Address is the public connection point; ZK proves the cryptographic relationship
Preserves user trust in blockchain Enables asset transfer to a secure account
Prevents asset lockup Incoming to Legacy accounts is prohibited
Simplicity Only one rule in the protocol
Final solution for "Quantum Zero Day":
Identified Signature-Related Attacks in Blockchain Systems
Throughout the history of blockchain systems, numerous attacks have exploited weaknesses in digital signature generation, cryptographic implementations, or signature verification mechanisms. The following summarizes the most relevant categories of signature-related attacks.
1. Nonce Reuse Attacks
In ECDSA, if two signatures are generated using the same nonce (k), the corresponding private key can be recovered mathematically.
Several academic studies have demonstrated that nonce reuse has exposed thousands of private keys across multiple blockchain ecosystems, resulting in severe financial losses.
2. Replay Attacks
Replay attacks occur when a valid signature intended for one transaction or context is reused in another context.
Without sufficient contextual binding, an attacker may reuse previously valid signatures to authorize unintended operations.
3. Signature Malleability
ECDSA signatures are inherently malleable.
An attacker may generate an alternative valid representation of the same signature without knowing the private key, potentially causing replay scenarios or transaction consistency problems if protocols do not properly normalize signatures.
4. Fault Injection Attacks
Fault injection attacks intentionally disturb the signing process through hardware manipulation, voltage glitches, clock modifications, laser injection, or similar techniques.
Such attacks may reveal sensitive information or cause abnormal signature generation.
5. Side-Channel Attacks
Side-channel attacks attempt to recover secret information by observing physical characteristics of the signing process, including timing behavior, power consumption, cache activity, or electromagnetic emissions.
These attacks are particularly relevant for hardware wallets and dedicated signing devices.
6. Signature Forgery
Signature forgery attacks attempt to construct signatures that satisfy protocol verification without possessing the legitimate private key.
Although modern signature algorithms are designed to prevent such attacks, implementation flaws or protocol weaknesses may increase practical risk.
7. Quantum Cryptanalysis
Future large-scale quantum computers executing algorithms such as Shor's algorithm may threaten classical public-key cryptography, including ECDSA, by making recovery of private keys from exposed public keys theoretically possible.
OTAK-NESA is not a post-quantum signature algorithm and does not replace post-quantum cryptography.
Instead, its objective is architectural:
For complete quantum resistance, OTAK-NESA is intended to complement future post-quantum signature algorithms rather than replace them.
8. Examples of Recent Incidents
Recent blockchain security reports continue to demonstrate that signature-related vulnerabilities remain an important practical concern.
Incidents involving weak nonce generation, compromised signing infrastructure, replay vulnerabilities, and exposed signing keys illustrate that long-term signature exposure continues to represent an important attack surface across blockchain ecosystems.
How OTAK-NESA Mitigates These Threats
Rather than modifying the underlying signature algorithm, OTAK-NESA changes the authorization architecture.
Long-term authorization keys never participate in routine transaction signing. Instead, every transaction is authorized using a disposable Child Key whose membership is verified through a Merkle Proof.
A nonce reuse event can only affect the corresponding one-time Child Key. Long-term authorization keys remain isolated from transaction signing.
Replay opportunities are reduced by binding each Child Key to a unique authorization state and one-time consumption rules.
Signature malleability may still exist at the algorithm level, but its practical impact is limited because Child Keys cannot be reused after successful authorization.
Any successful attack is confined to a disposable Child Key rather than exposing long-term authorization keys.
Information leakage from a Child Key affects only that temporary authorization key and does not directly expose long-term authorization keys.
An attacker must simultaneously satisfy signature verification and produce a valid Merkle Proof corresponding to the authorized key hierarchy.
OTAK-NESA minimizes long-term authorization-key exposure and is designed to operate alongside future post-quantum signature algorithms.
Conclusion
OTAK-NESA does not attempt to eliminate every cryptographic attack at the signature algorithm level.
Instead, it introduces a security architecture in which permanent authorization keys remain isolated from routine transaction signing while disposable Child Keys are used for transaction authorization.
As a result, the impact of many well-known signature-related attacks can be significantly reduced and confined to temporary authorization keys, while the long-term exposure of permanent authorization keys is minimized.
This architectural approach is independent of the underlying signature algorithm and can therefore operate alongside both existing classical signature schemes and future post-quantum signature algorithms.
Why Merkle Trees?
Merkle Trees have become one of the fundamental cryptographic building blocks of modern blockchain systems. Their primary purpose is to provide efficient, verifiable, and scalable authentication of large collections of data without requiring every participant to process the entire dataset.
Rather than serving only as a storage optimization mechanism, Merkle Trees enable decentralized systems to verify integrity, detect unauthorized modification, and authenticate individual elements using compact cryptographic proofs.
Adoption Across Blockchain Systems
The widespread adoption of Merkle Trees across major blockchain platforms demonstrates their importance as a general-purpose cryptographic authentication mechanism.
Bitcoin
Bitcoin uses a Merkle Tree to summarize every transaction contained within a block into a single Merkle Root, which is stored in the block header.
This design allows Simplified Payment Verification (SPV) clients to verify the inclusion of individual transactions using only a Merkle Proof instead of downloading the entire block, significantly reducing bandwidth and storage requirements.
Ethereum
Ethereum extends the concept by employing Merkle Patricia Tries to authenticate the complete blockchain state, including accounts, balances, storage, and smart contract data.
State transitions are verified by computing new authenticated state roots after transaction execution, allowing every node to independently verify network consistency.
Layer-2 Scaling Systems
Modern Layer-2 protocols, including optimistic and zero-knowledge rollups, extensively use Merkle Trees to authenticate large batches of off-chain transactions while publishing only compact commitments to the base blockchain.
This dramatically improves scalability without sacrificing cryptographic verifiability.
Data Availability Systems
Projects focused on modular blockchain architectures and data availability also rely on Merkle Trees to allow nodes to verify data integrity without downloading complete datasets.
Security Properties of Merkle Trees
Merkle Trees provide several important security properties that have made them a standard component of blockchain architecture.
Data Integrity
Any modification to a single leaf changes every hash along the authentication path up to the Merkle Root.
Consequently, unauthorized modification becomes immediately detectable.
Efficient Verification
Membership verification requires only a compact Merkle Proof rather than the complete dataset.
Verification complexity grows logarithmically with the number of leaves, making the mechanism highly scalable.
Decentralized Verification
Every node can independently verify cryptographic proofs without relying on trusted third parties or centralized databases.
Scalability
Merkle Trees allow authentication of extremely large datasets while maintaining relatively small proof sizes, making them practical for blockchain systems with millions of authenticated objects.
Security Considerations
Like every cryptographic construction, Merkle Trees inherit the security assumptions of their underlying hash functions.
Their practical security therefore depends primarily upon:
Modern blockchain implementations mitigate known implementation risks through standardized tree construction rules and well-established cryptographic hash functions.
Why OTAK-NESA Uses Merkle Trees
OTAK-NESA adopts Merkle Trees because they provide an efficient and decentralized mechanism for authenticating large sets of disposable authorization keys without requiring every key to be stored or transmitted during transaction validation.
Instead of registering every Child Key individually, OTAK-NESA commits the complete authorization set through a single Merkle Root.
Each transaction carries only:
Network nodes verify membership by comparing the supplied proof against the committed Merkle Root stored in the account state.
This approach provides several architectural advantages:
Merkle Trees within the OTAK-NESA Architecture
Within OTAK-NESA, the Merkle Tree is not merely a data structure.
It serves as the cryptographic commitment representing the entire authorization hierarchy.
Long-term authorization keys remain isolated from routine transaction signing, while temporary Child Keys are authenticated through Merkle Proofs.
This architecture enables scalable one-time authorization without exposing permanent authorization keys during normal blockchain operation.
Auditability
1. Auditability in Conventional Blockchain Systems
One of the fundamental properties of blockchain systems is that every transaction remains permanently verifiable.
Each transaction contains a digital signature that is permanently recorded on-chain. As a result:
This permanent public verifiability is one of the foundations of blockchain transparency and decentralization.
2. How OTAK-NES Preserves Auditability
OTAK-NES does not change the auditability model of blockchain systems.
Instead, it changes which keys are exposed through transaction signatures.
Under OTAK-NES:
Consequently, any participant can independently verify:
the digital signature
the validity of the Merkle Proof
the inclusion of the Child Key in the authorized hierarchy
that the Child Key had not been consumed before execution
the complete transaction history of the account
No trusted third party is introduced, and no additional off-chain information is required.
3. Auditability After Child Key Consumption
After a transaction is finalized, the Child Key is marked as Consumed.
This state transition prevents future reuse of that Child Key.
Importantly:
Therefore, OTAK-NES separates authorization validity from historical verifiability.
4. Preservation of Decentralization
OTAK-NES preserves all core decentralization principles.
Specifically:
The Merkle Root stored in the account state acts as the immutable commitment to the authorized Child Key hierarchy, while Merkle Proofs provide efficient membership verification.
5. Difference from Conventional Blockchain Authorization
In conventional blockchain systems:
In OTAK-NES:
As a result, long-term authorization keys no longer accumulate large numbers of publicly exposed transaction signatures over the lifetime of the account.
The transparency, auditability, and decentralized verification properties of blockchain remain unchanged.
Only the authorization architecture changes.
6. Conclusion
OTAK-NES preserves every property required for public blockchain auditability.
Every transaction remains:
The architecture simply replaces repeated exposure of long-term authorization keys with independently verifiable one-time authorization keys.
This preserves blockchain transparency while significantly reducing the long-term exposure of high-authority authorization keys without sacrificing decentralization or auditability.
Easy Implementation (Non‑mandatory)
One of the advantages of OTAK‑NES is its ability to be deployed easily and incrementally. Rather than requiring a disruptive, one‑time network‑wide migration, this model proposes a gradual adoption path that allows blockchain networks to introduce the new architecture while preserving backward compatibility throughout the transition.
This section describes one possible deployment strategy. It is provided as an implementation recommendation, not as a protocol requirement.
Minimal Protocol Requirements
OTAK‑NES does not require:
Instead, it builds on existing cryptographic capabilities already widely used in modern blockchain ecosystems, including:
As a result, OTAK‑NES introduces a new authorisation architecture rather than replacing the underlying cryptographic infrastructure.
Phase 1 — Bootstrap Infrastructure
The first deployment stage introduces only the supporting infrastructure required by OTAK‑NES.
At this stage, the network becomes capable of:
No changes are made to normal transaction authorisation.
All existing transactions continue to be signed using the conventional authorisation keys.
From a user's perspective, the network behaves exactly as before.
Phase 2 — Wallet Support
Once the Bootstrap infrastructure is in place, wallet software can begin supporting OTAK‑NES.
Wallets become capable of:
At this stage, the blockchain can support both authorisation models:
This enables gradual ecosystem adoption without disrupting existing users.
Phase 3 — Dual Validation in a Specific Domain
In this model, a specific domain is first selected. During the transition period, transactions in that domain can be validated using either authorisation model.
If a transaction in the chosen domain is signed using the conventional authorisation model, validation proceeds exactly as it does today.
If the transaction is authorised using OTAK‑NES, nodes additionally verify:
Both authorisation models remain usable within the chosen domain during this phase. This allows wallets, infrastructure providers, and the network to migrate safely to the new architecture.
The dual‑validation period is limited and temporary — it is not permanent. Once the network is confident in the stability and correct functioning of OTAK‑NES in that domain, it should make OTAK‑NES enforcement mandatory for that domain.
Phase 4 — Domain‑by‑Domain Expansion
Under this proposal, migration to the OTAK‑NES architecture is performed domain by domain, rather than all at once.
Each domain goes through the following cycle:
Child Key Support
The designated domain supports authorisation based on OTAK‑NES Child Keys.
Dual‑Validation Period
During this period, transactions in the domain can be validated using either authorisation model:
Access Keys
or OTAK‑NES Child Keys
This period lasts until the network is satisfied that OTAK‑NES is stable and ready for enforcement in that domain.
OTAK‑NES Enforcement in the Domain
After the transition period ends, the network establishes OTAK‑NES as the sole authorisation model for that domain.
In this state, transactions that do not satisfy OTAK‑NES requirements are rejected with a
CHILD_KEY_REQUIREDerror.Consequently, after a domain is fully migrated, Access Keys are no longer used for operational transactions in that domain.
Expansion to the Next Domain
Once migration of the previous domain is complete, the next domain enters its dual‑validation period.
Thus, at any given time, it is possible that:
This process continues for subsequent domains.
Full OTAK‑NES Coverage
This model continues until all domains of the network have migrated to OTAK‑NES. Ultimately, as the architecture expands to the entire network, OTAK‑NES becomes the sole operational authorisation model.
Domains such as transfers of a specific asset type, token transfers, staking, governance voting, and smart‑contract interactions can each enter this process according to their own readiness and requirements.
Phase 5 — Full OTAK‑NES Authorisation
After a domain has been fully migrated, and ultimately after all target domains have been covered and OTAK‑NES is deployed network‑wide, network nodes accept only transactions that satisfy OTAK‑NES validation requirements.
Specifically, an OTAK‑NES transaction must:
Following successful Bootstrap completion and full migration of a domain to OTAK‑NES, Access Keys no longer function as operational transaction‑signing identities for that domain.
Operational transactions in that domain are authorised exclusively through valid Child Keys derived from the corresponding Access Key.
The only exception is the initial Bootstrap transaction in networks that do not support Zero‑Knowledge proofs for Merkle Root registration. In such blockchain networks, wallets create two keys with different private keys simultaneously during account creation:
The Active Key then registers the Merkle Root corresponding to the Owner Key, and after successful Bootstrap completion, that Active Key is automatically deactivated by the network in accordance with OTAK‑NES requirements.
After each domain is fully migrated, long‑term Access Keys no longer produce operational on‑chain signatures for that domain.
In migrated domains, all subsequent account operations — including permission updates, Merkle Tree rotation, and multisignature transactions — are authorised according to OTAK‑NES rules, exclusively through valid Child Keys derived from the Owner Key or Active Keys, in line with the network's protocols.
Advantages of Incremental Deployment
The staged deployment model offers several important advantages:
Most importantly, blockchain networks may introduce OTAK‑NES gradually without interrupting existing operations or forcing all participants to migrate immediately.
Architectural Flexibility
OTAK‑NES intentionally separates the architecture from its deployment strategy.
The security model remains identical regardless of whether a blockchain adopts OTAK‑NES immediately or through multiple deployment phases.
Consequently, each blockchain ecosystem may choose a migration schedule that best fits its governance model, infrastructure maturity, operational constraints, and security objectives.
This approach provides the flexibility needed for gradual migration to OTAK‑NES and does not require networks to adopt the architecture all at once.
Secure Bootstrap Protocol
Native OTAK-NES Approach Compared with Zero-Knowledge-Based Designs
From a theoretical perspective, one of the most ideal methods for proving ownership without disclosing sensitive information is the use of Zero-Knowledge Proof systems. This technology can prove the validity of a claim to the network without revealing confidential information, making it one of the most advanced tools in modern cryptography.
However, integrating a complete Zero-Knowledge infrastructure directly into a Layer-1 blockchain requires new cryptographic components, including specialized proving systems, verification logic, and significant protocol-level engineering changes. Furthermore, generating and verifying Zero-Knowledge proofs in many applications entails considerable computational cost and implementation complexity.
OTAK-NES follows a different architectural approach. The objective of this architecture is not to compete with or replace Zero-Knowledge technologies, but to provide a native and innovative solution that is simpler and more compatible with existing blockchain architectures, capable of delivering a significant portion of the desired security benefits without relying on Zero-Knowledge infrastructure.
To achieve this goal, OTAK-NES leverages existing network capabilities, including the Permission model, public derivation, Merkle Trees, one-time Child Keys, and minimal account-state extensions. This approach seeks to prevent long-term exposure of signatures from keys with the highest level of authority while maintaining compatibility with the current network architecture, thereby substantially reducing the attack surface.
Should networks in the future adopt complete Zero-Knowledge infrastructure, OTAK-NES can serve as a complementary security layer alongside them. Thus, these two approaches are not competitors; they can complement each other in future architectures.
The Merkle Root Registration Challenge in Bootstrap
The core mission of OTAK-NES is to prevent the disclosure of Access Key signatures. However, the network cannot register a Merkle Root without a signature from an Access Key, and without the Merkle Root, Child Key validation is impossible.
OTAK-NES Solution for Networks That Do Not Yet Support Zero-Knowledge: Deactivating the Active Key After Merkle Root Registration in Bootstrap
In blockchain networks such as TRON, wallets can create two keys simultaneously during account creation, each with its own independent private key:
Although some implementations may allow both permissions to share the same private key, OTAK-NES requires the Owner Key and Active Key to be generated from independent private keys in order to preserve their security independence.
This capability already exists in TRON (based on TIP-16) and is technically feasible in other blockchain networks as well.
Solution: Instead of using the Owner Key to register the Owner Key's Merkle Root, OTAK-NES uses the Active Key created alongside the Owner Key during account creation. After the Owner Key's Merkle Root is successfully registered in Bootstrap, this Active Key is immediately and automatically deactivated by the network according to the OTAK-NES architecture.
What does deactivation mean? It means the network removes the Active Key that registered the Owner Key's Merkle Root from the account's permitted list (Permission.keys). Therefore, even if a future threat targets this signature or an algorithm succeeds in recovering the private key of this Active Key, it cannot be used to sign any valid transaction because the network no longer recognises that key as a valid signer.
Why does this solution work?
Complete process:
Security outcome: This method cannot completely eliminate the publication of an Access Key signature, but it fully neutralizes the long-term operational impact of that signature and preserves the long-term security model of the account.
Step-by-Step Description
Step 1: Wallet
At account creation, the wallet creates an Owner Key and an Active Key with independent private keys.
The wallet derives a predefined set of Child Keys from the Owner Key according to a hierarchical deterministic derivation standard (e.g., TRC-102).
The wallet constructs the Owner Key's Merkle Tree.
The wallet computes the corresponding Merkle Root.
The wallet submits the Bootstrap Request for the Owner Key using the account's Active Key, not the Owner Key.
The Bootstrap Request includes:
Step 2: Bootstrap Validation
Network nodes verify:
Step 3: Bootstrap Result Recording
After successful consensus:
BootstrapCompleted = trueis setTransaction Validation
For every operational transaction:
Wallet:
Network nodes verify:
last_used_child_index + 1.After successful confirmation:
last_used_child_indexis updated.Account Recovery
In OTAK-NES, Access Keys and Child Keys are deterministically derived from the user's Seed.
The network stores neither:
During recovery, the wallet:
Previously consumed Child Keys cannot be reused after recovery because network validation always relies on
last_used_child_index.Required Protocol Changes
To support OTAK-NES, the protocol requires:
BootstrapCompletedfield.last_used_child_indexfor sequential Child Key validation.CHILD_KEY_REQUIREDerror to the wallet.Security Outcome
After successful Bootstrap completion, all operational signatures published on-chain belong exclusively to Child Keys.
Consequently:
OTAK-NES Architecture
1. Access Key Restriction After Bootstrap Completion
In the OTAK-NES architecture, if the network does not support Zero-Knowledge proofs for the initial Merkle Root registration during Bootstrap, the wallet creates an account with both an Owner Key and an Active Key simultaneously during account creation, each with its own independent private key.
Although some implementations or wallets may allow assigning a shared private key to both the Owner Key and the Active Key, OTAK-NES does not permit this model. It defines the creation of the Owner Key and Active Key with independent private keys as an architectural requirement, to ensure that the independent security of these two keys is fully maintained.
The first transaction, according to the OTAK-NES security architecture, is the Bootstrap transaction, signed using the Active Key created at account creation. This transaction is exclusively used to register the Merkle Root of the Owner Key, thereby authorising transactions signed by Child Keys derived from that Owner Key.
After the Owner Key's Merkle Root is successfully registered in Bootstrap, the network deactivates the Active Key.
This transaction is identified at the network level as an initialisation transaction, not as a regular fee-based transaction.
Therefore, after account creation, nodes reject any transaction signed by Access Keys (other than the Active Key Bootstrap transaction for registering the Owner Key's Merkle Root) as an unsuccessful transaction, returning it to the account.
From this point forward:
All operational transactions must be signed with Child Keys and submitted to the network. Consequently, network nodes return any transaction signed using Access Keys (other than Child Keys) as unsuccessful.
Thus, after the successful registration of the Owner Key's Merkle Root by the Active Key and its subsequent deactivation:
Therefore, after full migration to OTAK-NES, Access Keys no longer function as operational transaction signing identities. Their role is limited to maintaining the root of trust and deriving authorised Child Keys.
This architectural restriction ensures that long-term authorisation keys do not continuously produce transaction signatures on-chain, thereby eliminating the accumulation of long-term signature exposure while preserving full blockchain transparency, auditability, and decentralised verification.
In a phased deployment model, networks may temporarily support both Access-Key-based signatures and Child-Key-based signatures derived from Access Keys during the migration period, and can plan the gradual migration based on domain or transaction type. However, after full OTAK-NES activation, direct transaction signing by Access Keys for operational activities is permanently disabled, and any transaction submitted without a Child Key signature is returned to the wallet as unsuccessful.
OTAK-NES is founded on the principle of non-exposure of Access Key signatures.
In this architecture, keys with account authority, including the Owner Key and Active Keys, are never directly used to sign operational on-chain transactions.
These keys act solely as the Root of Trust and provide the basis for hierarchically deriving Child Keys in the wallet.
After successful Bootstrap completion, all account operations are performed exclusively through Child Keys.
If a transaction signed directly by an Access Key is submitted, network nodes must return that transaction as unsuccessful.
2. Child Key Generation
The wallet derives a set of Child Keys from the Access Keys using a hierarchical deterministic derivation standard (such as TRC-102 on TRON).
Each Child Key:
3. Merkle Tree Structure
In the OTAK-NES architecture, Child Keys are organised into a Merkle Tree.
The wallet, locally and offline:
During the Bootstrap process:
The Merkle Root serves as the cryptographic root of trust for validating all Child Keys of that account.
4. Information Stored in Account State
The network does not need to store a list of Child Keys.
The OTAK-NES-related state for each account includes only the following minimal information:
5. Transaction Submission Process
For each transaction:
6. On-Network Validation
Upon receiving a transaction, network nodes:
last_used_child_index + 1.After successful confirmation:
In this process, nodes do not need to reproduce the derivation process or verify the cryptographic relationship between the Access Key and the Child Key.
7. Child Key One-Time-Use Model
Each Child Key can be used only once.
After successful confirmation:
If an attempt is made to reuse a consumed Child Key:
CHILD_KEY_CONSUMEDerror is returned.8. Child Key Management in the Wallet
All Child Keys are generated completely deterministically.
Consequently:
9. Child Key Tracking Model
OTAK-NES does not require maintaining a set of consumed keys, a bitmap, or a list of used Child Keys.
Instead, the network only maintains the
last_used_child_indexvalue.This model:
10. Rotation Window
To prevent the exhaustion of Child Keys in a Merkle Tree, OTAK-NES introduces the concept of a Rotation Window.
The Rotation Window is a portion at the end of each active Merkle Tree that is unusable for ordinary transactions and is reserved exclusively for Merkle Tree replacement.
When the wallet enters the Rotation Window, it automatically:
After confirmation:
11. Account Recovery
All Access Keys, Child Keys, and Merkle Trees are deterministically derived from the user's Seed.
The network never stores:
During recovery, the wallet:
merkle_rootandlast_used_child_indexstored in the network state.12. Shifting the Threat Model from the Entire Account and All Assets Under Its Control to the Specific Transaction and Asset Being Transferred
OTAK-NES provides a fundamental change in the blockchain threat model. Instead of allowing the exposure of an operational signature to potentially threaten the entire account and all assets under its control, the architecture limits the potential impact to the specific transaction and the specific asset being transferred. This capability is now available to the community.
OTAK-NES enables a reduction in the risk of exposing assets controlled by private keys by preventing the routine public exposure of signatures produced by those keys. The architecture is designed for practical implementation on existing blockchain networks.
Protection of submitted transactions during the network's internal validation process can be approached through different methods:
Post-Quantum Signatures: This approach increases computational resistance against quantum attacks, but by itself cannot reduce the threat model from the entire account to a specific transaction.
OTAK-NES Architecture: Beyond limiting the scope of the threat from the level of all controlled assets to the level of the asset being transferred, this architecture provides an important contribution to blockchain security. Key contributions of the architecture toward reducing the risk of public signature exposure include:
Security Properties
The OTAK-NES architecture provides several important security advantages:
13. Multisig Account Support Through Independent Merkle Trees
OTAK-NES fully supports multisignature accounts while preserving its fundamental security principle: Access Key signatures must never be exposed during normal account operation.
In a multisignature account, a Permission may contain multiple Access Keys, each with its own weight and signing authority. Rather than sharing a single Merkle Tree across all Access Keys, OTAK-NES assigns an independent Merkle Tree to every Access Key.
Each Access Key therefore maintains its own:
This separation allows every Access Key to operate independently while remaining fully compatible with the existing Permission model.
Bootstrapping Additional Access Keys
During account creation, the Owner Key and its initial Active Key follow the Bootstrap procedure defined by OTAK-NES.
When an additional Active Key is later added to the account, the process follows the same architectural principle:
As a result, every Access Key owns an independent authorization domain without affecting the operation of other keys.
Architectural Advantages
Independent State Management
Each Access Key advances through its own Child Key sequence independently. Consumption of Child Keys associated with one Access Key has no effect on the state of any other Access Key.
Security Isolation
If an individual Access Key or one of its Child Keys is ever compromised, the impact is confined to that Access Key's own authorization domain. Other Access Keys, their Merkle Trees, and their Child Key hierarchies remain unaffected.
This compartmentalization is a fundamental security property of OTAK-NES and significantly reduces the scope of any individual security incident.
Simplified Verification
Each signer submits:
Network nodes validate each proof only against the Merkle Root registered for that specific Access Key. No cross-tree verification or coordination between different Merkle Trees is required.
Scalable Permission Architecture
Additional Access Keys can be introduced without modifying existing Merkle Trees or Child Key hierarchies. Every newly added Access Key simply receives its own independent Merkle Tree and begins operating within its own authorization domain.
This enables multisignature accounts to scale naturally while preserving deterministic validation.
Algorithm Independence
Because every Access Key owns an independent Merkle Tree, different Access Keys may employ different digital signature algorithms if supported by the network.
For example, one Access Key may authorize Child Keys using ECDSA while another uses a future post-quantum signature algorithm such as ML-DSA or Falcon.
This flexibility allows gradual migration to newer signature schemes without requiring changes to the overall OTAK-NES architecture.
Multisignature Transaction Flow
For a multisignature transaction:
Security Outcome
Using an independent Merkle Tree for every Access Key preserves all core OTAK-NES security guarantees in multisignature accounts:
This architecture extends the OTAK-NES security model to multisignature accounts without altering the underlying Permission framework while maintaining the protocol's core objective of eliminating long-term operational exposure of Access Key signatures.
14. A Distinct Approach to Security Architecture
Core Principle:
Non-Exposure of Long-Term Authorization Keys
The OTAK-NES architecture is built on a fundamental security principle: long-term authorization keys should never be repeatedly exposed through operational transaction signing.
Rather than focusing on making a single cryptographic algorithm harder to break, OTAK-NES eliminates the primary long-term attack surface by ensuring that Access Keys — the keys with the highest level of authority over an account — never publish signatures on the blockchain during routine operations.
Beyond Post-Quantum:
A Broader Security Framework
While post-quantum signature algorithms (such as ML-DSA, Falcon, or SLH-DSA) aim to resist quantum attacks by increasing cryptographic complexity — with larger signatures and higher verification costs — OTAK-NES takes a fundamentally different path.
Post-quantum signatures address quantum threats by hardening cryptography. OTAK-NES addresses the broader problem of long-term signature exposure by changing the authorization architecture itself.
This architectural separation provides multiple security benefits:
OTAK-NES as a Foundational Security Layer
OTAK-NES is not a new signature algorithm. It is a key lifecycle architecture that can operate alongside any signature scheme — whether classical ECDSA, post-quantum Falcon, or any future cryptographic algorithm.
This architecture provides a foundational security layer that reduces long-term exposure, limits the impact of security incidents, and preserves blockchain transparency, auditability, and decentralization.
In simplified terms:
Because these operate at different architectural layers, they reinforce rather than replace one another — they do not overlap or compete. Combining strong cryptographic algorithms with a compartmentalized key lifecycle architecture provides a more resilient security model than relying on either approach alone.
Conclusion
OTAK-NES offers a comprehensive security architecture that:
Whether a blockchain uses classical ECDSA, post-quantum signatures, or any future algorithm, OTAK-NES provides an independent security layer that reduces the long-term exposure of its most critical authorization keys while preserving the transparency, auditability, and decentralization that make blockchains trustworthy.
Threat Model
The OTAK-NES architecture is designed under the assumption that the long-term security of blockchain accounts depends not only on the strength of the underlying digital signature algorithm, but also on the duration of signing authority exposure and the size and scope of a threat.
Rather than assuming that attacks on a private key will not occur, or relying on the permanent security of a specific signature type or cryptographic primitive, or assuming that a transaction signature alone provides complete cryptographic security for an account and that publishing it creates no direct threat to the account's private key—although no signature algorithm, including post-quantum schemes, has ever made such a claim and in practice such a claim has never been absolutely proven—OTAK-NES seeks to minimize public exposure and repeated use of long-term authorization keys, and to reduce the scope of a potential security threat from the entire account and all its assets to the specific transaction and the specific amount of assets being transferred—not to all assets of an account. This is achieved by distributing operational signing authority across one-time keys (Child Keys) through the OTAK-NES architecture.
This approach introduces a fundamental innovation in blockchain security architecture. To the extent that a review of prominent blockchain architectures has been conducted, no other common architecture has limited this threat model from the entire account level to a specific transaction and asset in this manner.
Accordingly, the architecture considers the following threat classes.
Shift in Threat Model: From All Account Assets to a Specific Transaction and Its Corresponding Asset
In conventional architectures, the exposure of a single operational signature can threaten the entire account and all assets under its control.
OTAK-NES limits the scope of this threat from the entire account to a specific transaction and the asset associated with that transaction—not to all assets of an account. This is enabled through one-time Child Keys derived from Access Keys, based on the OTAK-NES architecture:
Non-Exposure of Access Key Signatures
The principle of non-exposure of signatures from keys with access to all assets of an account (Access Keys), although currently considered an optional aspect in some blockchain architectures, may become an important security requirement for blockchain architectures over time, as computational sciences advance and highly powerful computers, including quantum computers, emerge.
Beyond the above, there is another fundamental question:
Why would one refrain from limiting the potential scope of a compromise during transaction submission and signature publication—from the entire account and all assets under its control, to that specific transaction and the specific asset being transferred?
When the exposure of an account signature can, in the presence of an exploitable weakness in the algorithm, implementation, or other security conditions, become a threat to the private key and consequently to all account assets, we must also recognize that an account signature is not only visible after being recorded on the blockchain; rather, there are multiple points along the path to transaction finality where it can be observed, processed, and exposed.
A transaction, from creation and propagation to finalization and permanent block recording, may be received, relayed, temporarily stored, or processed by various network components and related infrastructure, including:
-and Intermediate services and infrastructure that receive, forward, or submit transactions for validation.
Therefore, a transaction signature may be visible and subject to analysis at multiple points along the transaction propagation and processing path, before the transaction is finalized and permanently recorded in the blockchain history.
This further highlights the importance of the OTAK-NES architecture, because its objective is not merely to reduce the duration of signature exposure, but to eliminate the use of Access Keys as transaction signing keys and transfer this role to independent, one-time Child Keys.
In this architecture, even if an operational Child Key is exposed during a transaction, that key only authorizes that specific transaction and is permanently deactivated after confirmation, while the Access Key is never used to sign operational transactions and no signature from it is ever published on the network.
Therefore, even with a very strong signature algorithm, the exposure of a transaction and its signature in the public network environment represents an independent layer of exposure that cannot be eliminated solely by increasing the strength of the signature algorithm.
This raises another question:
Why should blockchain architectures not reduce the threat model as much as possible—from the entire account and all assets under its control—to the smallest operational unit, namely a specific operational key and a specific transaction?
The OTAK-NES security architecture is introduced precisely on this principle: reducing the potential scope of a compromise at the account level. It is designed for implementation on existing blockchain networks.
This approach can, in the long term, be regarded not only as a security feature, but as an architectural principle and a security standard for blockchains.
Blockchains that have adopted user security and asset protection as one of their fundamental principles can move toward evaluating and, subject to technical validation, implementing the OTAK-NES architecture.
Long-Term Signature Exposure
In conventional blockchain architectures, long-term Access Keys may repeatedly sign operational transactions over many years; as a result, signatures generated by the same authorization key are permanently recorded in the network history.
This creates an accumulating set of cryptographic data tied to the account's private key, with each transaction providing additional analytical information to attackers.
OTAK-NES counters this growing analytical exposure by ensuring that Access Keys do not directly sign routine operational transactions after successful Bootstrap. In this architecture, operational transactions are authorized through independent, one-time Child Keys.
This limits the scope and magnitude of a potential signature exposure event from an authorization key with access to account assets and all account assets, to a temporary key and the specific transaction associated with it.
Implementation Vulnerabilities
Security flaws may arise from weaknesses in the mathematical design of a digital signature algorithm, from implementation errors, from reliance on network components for transaction visibility and processing, from unauthorized leakage or copying, or from other factors.
Examples include:
No signature algorithm has ever claimed to be resistant to all known and unknown threats or to be prepared for all future attack vectors. Although signature algorithms—especially post-quantum signature schemes—are designed according to rigorous security standards and requirements, their security remains dependent on cryptographic assumptions, design, implementation, and both current and future threat landscapes.
OTAK-NES does not attempt to completely eliminate such vulnerabilities.
Instead, by ensuring that operational transactions are authorized through independent, one-time Child Keys, it seeks to limit the potential impact of such vulnerabilities from the entire account and all its assets to the specific transaction and the specific asset being transferred.
Side-Channel and Physical Attacks
Practical attacks such as:
may target implementations of digital signature algorithms.
If such an attack compromises a specific Child Key, OTAK-NES is designed to limit its operational impact to the related authorization event and the specific transaction, rather than to the private key of the entire account and all its assets. This is because Access Keys with control over all assets are not used to sign operational transactions in this architecture. Additionally, each Child Key is used only once for a specific transaction and becomes unusable for subsequent operational authorization.
Protection against specific side-channel attacks remains dependent on the security of the wallet implementation and the signature algorithm in use.
Future Cryptanalytic Advances
Future advances in cryptanalysis may reveal weaknesses that are currently unknown.
These advances may affect:
OTAK-NES does not depend on predicting which algorithms may become vulnerable in the future.
Instead, by distributing operational signing authority across independent, one-time Child Keys rather than centralizing routine transaction signing on a single long-term operational key, it reduces long-term signature exposure from the entire account to a smaller component, namely a specific transaction with limited associated assets.
Quantum Computing
Large-scale quantum computers may in the future threaten classical signature cryptography, and continued development and evaluation of post-quantum signature schemes will remain essential to addressing future threats.
OTAK-NES is not a replacement for post-quantum signature algorithms and does not by itself provide post-quantum cryptographic security. At the same time, the architecture can support stronger and more secure signature algorithms against future threats, including quantum threats.
OTAK-NES provides an independent architectural security layer that reduces risk by minimizing exposure to Access Key signatures and by using Child Keys derived from the account's master keys.
Accordingly, OTAK-NES is designed to be usable alongside any signature algorithm, whether classical or post-quantum.
When Child Keys use a suitable post-quantum signature scheme, the two mechanisms can provide complementary protections: the signature scheme provides cryptographic resistance against quantum attacks, while OTAK-NES provides key isolation, separation of authorization authority, and reduction of the threat scope.
Unknown Future Attack Techniques
No security architecture can assume that all future attack vectors are already known or that it can fully address all future threats.
New attack methods may emerge through advances in:
OTAK-NES adopts a defensive architectural approach rather than relying on assumptions about specific attacks.
By minimizing long-term exposure of authorization keys and isolating operational authority through one-time Child Keys, the architecture seeks to reduce the potential consequences of both known and unknown future threats.
Security Assumptions
OTAK-NES is based on the following assumptions:
OTAK-NES does not replace these mechanisms.
Instead, it introduces an additional architectural security layer that, independently of the signature algorithm in use, reduces long-term exposure and reuse of transaction signing authority.
Security Objective
The primary objective of OTAK-NES is not to make digital signatures cryptographically stronger.
Its objective is to minimize long-term exposure of high-authority authorization keys and to separate operational authorization authority through one-time Child Keys.
By separating authorization authority from operational signing authority, OTAK-NES seeks to reduce the scope of a potential compromise from a long-term authorization key and the assets under its control, to the level of a specific operational key, a specific transaction, and the specific asset being transferred.
This principle limits the potential consequences of compromising an operational key, while maintaining architectural compatibility with both current and future digital signature schemes.
In essence, this is not merely a change in how keys are managed—it is a fundamental change in how the threat itself is defined, contained, and reduced in scope on the blockchain.
Advantages of OTAK-NES in:
One of the architectural advantages of OTAK-NES is that it separates key lifecycle management from the underlying digital signature algorithm.
OTAK-NES does not define a new signature algorithm. Instead, it defines how Access Keys, Child Keys, Merkle Trees, and transaction authorization are managed. Consequently, the same architecture can operate with different signature algorithms without changing the OTAK-NES security model.
Simplified Migration to New Signature Algorithms
Blockchain networks inevitably evolve. As new digital signature algorithms become available, networks may wish to migrate from existing schemes to newer ones.
In conventional architectures, migrating to a new signature algorithm often requires replacing the long-term signing authority used for every operational transaction.
Under OTAK-NES, however, each Access Key maintains its own independent Merkle Tree and its own hierarchy of Child Keys.
As a result, a newly introduced Access Key may use a different signature algorithm while existing Access Keys continue operating with their original algorithm until migration is complete.
This enables gradual migration rather than requiring every account to transition simultaneously.
Simultaneous Support for Multiple Signature Algorithms
Because each Access Key is associated with its own Merkle Tree, different Access Keys within the same account — or across different accounts — may use different digital signature algorithms.
For example, one Access Key may derive Child Keys using ECDSA, while another Access Key derives Child Keys using a post-quantum signature scheme.
During transaction validation, network nodes simply verify the signature according to the algorithm associated with the corresponding Access Key and validate the supplied Merkle Proof against that key's registered Merkle Root.
This architecture naturally supports heterogeneous cryptographic environments without introducing conflicts between different signature schemes.
Incremental Network Deployment
OTAK-NES also enables phased deployment at the network level.
Rather than requiring immediate migration of every transaction type, a network may progressively expand support for the new signature algorithm based on transaction categories.
For example, support may initially be introduced for a limited category of transactions before being extended to additional transaction types as wallets, infrastructure providers, and network software adopt the architecture.
Similarly, networks may temporarily support multiple signature algorithms simultaneously during migration until older algorithms are eventually retired.
Layer-2 Compatibility
OTAK-NES is compatible with Layer-2 architectures because its trust model is based on cryptographic authorization rather than a specific execution environment.
Whether transactions are executed directly on Layer-1 or processed through Layer-2 protocols, Child Keys, Merkle Proofs, and Access Key separation remain applicable provided that the corresponding protocol supports transaction authorization using this architectural model.
Consequently, OTAK-NES can serve as a common authorization architecture across Layer-1 and Layer-2 systems while remaining independent of the underlying execution model and signature scheme.
Architectural Benefit
By separating authorization architecture from the signature algorithm itself, OTAK-NES provides long-term flexibility.
Networks may adopt stronger signature algorithms, support multiple algorithms simultaneously, deploy migrations incrementally, and extend the same authorization model to Layer-2 systems without fundamentally redesigning the lifecycle of account authorization.
OTAK-NES Approach for Reducing Signature Exposure in Existing Accounts Prior to Full Deployment
For accounts created before the full deployment of OTAK-NES that already have a history of outgoing transactions, several adoption paths can be defined, each providing a different level of reduction in long-term signature exposure.
A fundamental characteristic of blockchain systems is that signatures published on-chain are permanent and cannot be removed after confirmation. Consequently, any account that has already produced on-chain signatures before the activation of OTAK-NES will permanently retain part of its historical cryptographic footprint.
OTAK-NES enables a significant reduction in the future exposure of such accounts. However, the degree of reduction depends on the adoption path selected.
Option 1: Create a New Account with a New Seed
In this approach, the user generates a completely new Seed and creates a new account.
After completing the Bootstrap process and activating the OTAK-NES security model, all assets are transferred from the original account to the new account, and operational use of the original account is discontinued.
This provides the highest possible reduction in long-term signature exposure because the new account begins its operational life without any previous on-chain signature history. Consequently, the assets become completely separated from the cryptographic history of the original account.
The only cost of this approach is the need to securely manage and back up a new Seed.
Option 2: Create a New Account Derived from the Same Seed
In this approach, the user keeps the existing Seed but creates a new account using a different derivation path defined by the TRC-102 hierarchical deterministic derivation standard.
Example:
"m/44'/195'/0'/0/1"
The derived account has an independent public/private key pair while remaining recoverable from the same Seed.
After creating the new account and completing Bootstrap, assets are transferred from the original account to the newly derived account.
This approach avoids generating a new Seed while providing a completely new set of Access Keys and Child Keys for future operations.
If the derived account has no previous on-chain signature history before entering operational use and its Bootstrap process is completed according to the OTAK-NES architecture, its long-term signature exposure will be significantly lower than that of the original account.
Option 3: Preserve the Existing Account Identity
In this approach, the account address remains unchanged while a new set of Access Keys is assigned to the existing account.
After the account operates under the OTAK-NES architecture, the permission structure can be updated through an "AccountPermissionUpdateContract" transaction signed by a valid Child Key together with its corresponding Merkle Proof.
After successful confirmation:
This approach is particularly suitable for accounts whose address, operational history, public identity, or external integrations must be preserved.
However, it should be noted that:
Summary
All three approaches are fully compatible with the OTAK-NES architecture, although they provide different levels of reduction in long-term signature exposure.
xxo1shine commentedon Jun 10, 2026
@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:
These details would help assess the scalability and practical deployability of the design.
Federico2014 commentedon Jun 10, 2026
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:
nonceas the Merkle leaf index. Nonce naturally increments per transaction, so a node verifiesmerkle_proofagainst(merkle_root, nonce)— no separate "consumed key set" storage. State overhead is zero.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 commentedon Jun 10, 2026
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 commentedon Jun 10, 2026
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:
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. Drawing on similar experiences in other blockchains, a hash-based mechanism represents a highly intelligent approach to mitigating the risk of information exposure in the mempool.
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, as a separate TIP, would be beneficial not only for OTAK-PQ but for 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.
alichatme commentedon Jun 18, 2026
Thank you everyone for the valuable feedback.
Based on the technical discussions in this thread, the proposal has been updated to clarify several implementation details, including:
These updates are intended to improve clarity and accurately reflect the OTAK-PQ validation model while preserving the original security objectives of the proposal.
I appreciate all the constructive feedback and look forward to further review.
Redchar1992 commentedon Jun 29, 2026
Having read through the thread, I agree with the direction and with the concerns already raised — @xxo1shine on state growth / consumed-key tracking, @Federico2014 on the EIP-8202 Ephemeral parallel and the mempool exposure window, and @GordonLtron's commit-reveal idea. A few additional points that build on those:
1. The signing layer remains ECDSA, so this is complementary to PQC, not a substitute. Even setting the mempool issue aside, the security pivot here is "hash-preimage resistance protects the root, while ECDSA still protects each transaction." So an active quantum adversary can still forge the in-flight transaction (the point @Federico2014 raised), and commit-reveal / short expiration (@GordonLtron) shrinks but doesn't remove that window — the committed ECDSA signature is still revealed eventually. A more complete path would anchor the signing layer itself with a hash-based one-time signature (Lamport/Winternitz/XMSS-style), which is post-quantum by construction, rather than keeping ECDSA child keys under a quantum-safe Merkle root. It would help to state explicitly that OTAK-PQ targets harvesting of dormant/historical keys and is intended to compose with NIST PQC signatures (e.g. a hybrid ECDSA+ML-DSA scheme), not replace them.
2. Statefulness is an operational hazard beyond exhaustion. Adopting the nonce-as-index approach removes the consumed-set storage, but the scheme is still stateful in the XMSS/LMS sense: the wallet must never sign two transactions at the same index. How is that guaranteed across multi-device wallets, restore-from-seed/backup, and concurrent signing? Index reuse here is catastrophic (two ECDSA signatures under sibling leaves), so the spec should define how clients coordinate the index, and what the re-bootstrap flow is once leaves are exhausted — including how the new Merkle root is committed without an Access Key signature appearing on-chain.
3. Existing accounts and the identity model. The protection only applies to keys that have never signed on-chain; TRON's large base of already-active addresses (and migration option 3, rotation) keep their historical exposure, so this doesn't address the systemic risk for existing value on its own. It would also help to specify the address / account-identity model when each transaction carries a different child public key (address derivation, multisig/permissions, TRC-20 allowances, explorers), and to give the Bootstrap ownership proof in cryptographic detail — since that is the one step that must establish control of the root without publishing an Access Key signature.
As a low-overhead transitional layer this is a reasonable design; scoping the quantum guarantee precisely (dormant-key harvesting vs. active adversary) and positioning it relative to NIST PQC signatures would make the proposal considerably stronger.
alichatme commentedon Jun 29, 2026
@Redchar1992
First, I sincerely thank you for taking the time to review this proposal in detail and for providing such thoughtful technical feedback.
I also appreciate the earlier discussions initiated by @xxo1shine, @Federico2014, and @GordonLtron. Their comments, along with yours, have helped us improve several parts of the proposal.
As a result of the community feedback received during this discussion, the proposal has been updated to clarify several implementation details, including Merkle Tree lifecycle management and long-term account operability.
Regarding your specific points:
We fully agree that OTAK-PQ is not designed as a replacement for standardized Post-Quantum signature algorithms.
The goal of OTAK-PQ is different.
As explained throughout the proposal, OTAK-PQ addresses a different layer of the problem: eliminating the exposure of Access Key signatures on the blockchain. This architectural model protects account assets against both known quantum threats such as Shor's algorithm and unknown but potential future threats related to the exposure of Access Key signatures on the blockchain, by using one-time Child Keys derived from the Access Keys.
The proposal also examines the trade-offs between replacing current signature algorithms with NIST PQC-standard signatures and introducing a lightweight architectural layer such as OTAK-PQ.
Current blockchain networks are designed around relatively lightweight signature schemes. Replacing every transaction with Post-Quantum signatures — which are significantly larger — would impose additional bandwidth, storage, verification, and synchronization costs across the network.
OTAK-PQ offers a complementary architectural risk reduction with minimal protocol overhead, while remaining fully compatible with future migration to standardized Post-Quantum signatures.
Post-Quantum signatures address the threat by making cryptography harder, while OTAK-PQ addresses it by preventing the exposure of Access Key signatures — protecting against both known and unknown future quantum threats.
Even after native PQ signatures are widely deployed, the security properties provided by OTAK-PQ — including the non-exposure of Access Key signatures, one-time operational Child Keys, deterministic recovery, and precise key lifecycle separation — will remain valuable.
We therefore view OTAK-PQ as complementary to future PQ signatures, not as a competitor to them.
We agree that mempool exposure is a real limitation in current blockchain architectures and is not specific to OTAK-PQ.
However, we deliberately kept this proposal focused on its core objective, rather than extending its scope to transaction propagation.
As suggested during the discussion, a hash-based Commit-Reveal mechanism is a promising approach to mitigating mempool exposure without requiring changes to the underlying signature algorithm.
Since such a mechanism would benefit the entire TRON ecosystem — not only OTAK-PQ — we believe it is better suited as a separate, independent TIP.
Thank you for raising this point.
Following community discussion, we have expanded the proposal by adding a dedicated "Rotation Window" section — as the tenth item under the OTAK-PQ Architecture section — which specifies the complete Merkle Tree replacement lifecycle.
The updated version now specifies:
· When a new Merkle Tree should be prepared.
· How Merkle Tree replacement is authorized.
· How the new merkle_root is recorded.
· Why Access Keys never participate in on-chain signing.
· How last_used_child_index is reset.
· How recovery after rotation remains deterministic.
Instead of allowing an active Merkle Tree to become fully exhausted, OTAK-PQ reserves a protocol-defined Rotation Window near the end of each active tree.
Child Keys within this reserved window are exclusively dedicated to Merkle Tree replacement and cannot be used for ordinary account transactions.
This ensures that the protocol always retains sufficient authorization capacity to securely activate the successor tree before exhaustion occurs.
Consequently, Merkle Tree replacement is enforced by the protocol itself, rather than relying solely on wallet implementation behavior.
The text added to the proposal:
( 10. Rotation Window
Purpose
To ensure uninterrupted long-term account operation and eliminate the possibility of exhausting an active Merkle Tree, OTAK-PQ introduces a Rotation Window.
A Rotation Window is a reserved range of Child Keys located at the end of every active Merkle Tree. Child Keys within this window MUST NOT be used for ordinary account transactions and are reserved exclusively for Merkle Tree Rotation.
The size of the Rotation Window is protocol-defined or implementation-dependent. For example, an implementation MAY reserve the final 5% of Child Keys for this purpose.
Rotation Procedure
Wallet software SHOULD continuously monitor the remaining number of available Child Keys.
When the active Merkle Tree enters the Rotation Window, the wallet SHOULD automatically:
· Deterministically generate a new set of Child Keys according to the TRC-102 standard.
· Build a new Merkle Tree.
· Compute the corresponding Merkle Root.
· Create and submit a Merkle Tree Rotation transaction using a valid unused Child Key belonging to the Rotation Window.
This process is intended to occur automatically without requiring user intervention.
Wallet implementations MAY notify the user after a successful Merkle Tree Rotation, but user confirmation is NOT required for the protocol-defined rotation process.
Rotation Validation
Upon receiving a Merkle Tree Rotation transaction, network nodes MUST verify that:
· The transaction signature is valid.
· The signing Child Key belongs to the currently active Merkle Tree.
· The provided Merkle Proof is valid.
· The Child Key belongs to the Rotation Window.
· The Child Key has not been previously consumed.
· The submitted rotation request satisfies all protocol validation rules.
Network nodes MUST reject any ordinary transaction signed by a Child Key belonging to the Rotation Window.
After successful confirmation:
· The stored merkle_root is replaced with the new Merkle Root.
· last_used_child_index is reset to zero.
· The new Merkle Tree becomes the active tree.
· The previous Merkle Tree is permanently deactivated.
· Any remaining unused Child Keys belonging to the previous Merkle Tree become permanently invalid.
Transactions signed by Child Keys belonging to any previously deactivated Merkle Tree MUST be rejected.
Recovery
Because both Access Keys and all Merkle Trees are deterministically derived from the user's master Seed according to the TRC-102 standard, no additional backup material is required.
During account recovery, the wallet regenerates the currently active Merkle Tree from the master Seed and synchronizes its operational state using the merkle_root and last_used_child_index stored in the network State.
Security Properties
The Rotation Window preserves the core OTAK-PQ security model while enabling unlimited long-term account operation.
Specifically:
· Access Keys never participate in signing on-chain transactions.
· No Access Key signature is ever exposed during the rotation process.
· Account ownership remains unchanged.
· Unlimited Child Key generation is supported through successive Merkle Tree Rotations.
· The per-account State size remains constant regardless of the number of rotations performed.
· Merkle Tree replacement is authorized exclusively by valid one-time Child Keys.
By reserving a Rotation Window at the protocol level, OTAK-PQ guarantees that Merkle Tree replacement is enforced by the protocol itself rather than relying solely on wallet implementation behavior.
Consequently, an active Merkle Tree can never become fully exhausted while still retaining sufficient authorization capacity to securely activate its successor. )
We also agree that previously exposed ECDSA accounts remain historically exposed.
This is not specific to OTAK-PQ.
A similar migration challenge exists for any future adoption of standardized Post-Quantum signatures, since historically recorded on-chain signatures cannot be retroactively withdrawn.
For this reason, the proposal clearly defines multiple migration paths for existing accounts, while providing full protection for newly bootstrapped OTAK-PQ accounts whose Access Keys never publish signatures on-chain.
The Bootstrap protocol, ownership establishment, recovery procedure, and account identity model are described in detail within the proposal.
One of the core design objectives of OTAK-PQ is to ensure that Access Key signatures never appear on the blockchain — not even during the Bootstrap process.
Consequently, even account ownership proofs and transaction submissions are established without exposing Access Key signatures, preserving the proposal's long-term security assumptions.
Thank you again for your thorough review and constructive discussion.
Your feedback has directly contributed to improving the specification of this proposal, and several sections have been clarified and expanded as a result.
We truly appreciate the opportunity to refine the design through community review.
Redchar1992 commentedon Jun 30, 2026
Fair enough on all three — the PQ-signature size/storage cost is a real constraint, mempool exposure does belong in its own TIP, and the Rotation Window addition addresses the key-exhaustion path. I'll concede the complementary-layer framing.
One thing worth making explicit in the text, then: that OTAK-PQ's guarantee is reducing exposure/harvest of dormant keys, not protecting the in-flight transaction — so it composes with a future PQC-signature track rather than substituting for one. Scoping the claim that precisely is what keeps it from being read as "TRON is quantum-safe" once it ships. Nice work iterating on this.
alichatme commentedon Jun 30, 2026
@Redchar1992
Thank you for your thoughtful feedback and for following the discussion so closely.
We completely agree that clearly defining the security scope is important. OTAK-PQ is designed to eliminate long-term reusable signing authority by ensuring that Access Keys never publish signatures on-chain. Its primary objective is to reduce the long-term exposure and harvesting risk associated with dormant keys, rather than to protect transactions while they are in flight.
Protection against mempool exposure belongs to a different problem domain and can be addressed independently through mechanisms such as hash-based Commit-Reveal or future protocol improvements. Likewise, OTAK-PQ is fully compatible with future NIST-standardized post-quantum signature algorithms and is intended to complement them rather than replace them.
Based on the valuable feedback received throughout this discussion, we have also added the following clarification to the proposal to make this design philosophy more explicit:
A Distinct Approach to Quantum Threats
Post-Quantum signature algorithms (such as ML-DSA) aim to resist quantum attacks by making the underlying cryptography harder — increasing signature sizes and verification costs. OTAK-PQ takes a fundamentally different approach.
Rather than strengthening the signature algorithm itself, it eliminates the primary long-term attack surface by ensuring that Access Keys, which control account assets, never publish a signature on the blockchain.
In other words, post-quantum signatures address quantum threats by hardening cryptography, whereas OTAK-PQ addresses them by eliminating long-term signature exposure.
This architectural separation helps protect against known quantum attacks, such as Shor's algorithm, while also reducing exposure to future cryptanalytic advances, without requiring any change to the underlying transaction signature algorithm.
Thank you again for your constructive comments and for helping improve the proposal.
alichatme commentedon Jul 11, 2026
Thank you again for the valuable technical discussion around OTAK-PQ.
One of the most valuable points raised during this discussion was the mempool exposure issue. We agreed that this concern is important, but also that it falls outside the primary scope of OTAK-PQ, whose objective is to eliminate long-term reusable signing authority rather than redesign the transaction propagation layer.
Based on your feedback, we decided to study this problem as an independent protocol proposal.
As a result, we have submitted a new TIP proposal introducing ATHENA, together with its discussion issue:
Proposal (PR):
#906
Discussion (Issue):
#905
ATHENA proposes an independent transaction admission and scheduling layer that aims to improve transaction admission, dynamic scheduling, processing efficiency, and network throughput while also reducing the transaction exposure window in the mempool—without modifying the consensus algorithm, global ledger, or validation rules.
The motivation for separating this work from OTAK-PQ was to keep both proposals focused on their respective responsibilities while allowing each design to evolve independently.
Your previous comments directly motivated this work, and we would sincerely appreciate it if you could review the ATHENA proposal as well. Your technical feedback has been extremely valuable throughout this process, and we would be grateful for any additional comments or suggestions.
Thank you once again for your time and thoughtful reviews.
alichatme commentedon Jul 31, 2026
We sincerely thank everyone who reviewed OTAK-PQ and contributed to the technical discussion.
We fully understand and respect the TRON development team's decision to continue its current post-quantum work under TIP-899, and we sincerely wish the team success in implementing and deploying it.
We would like to clarify one final point about the original motivation behind OTAK-PQ.
The fundamental goal of OTAK-PQ was not simply to introduce post-quantum cryptography. From the beginning, its core principle was to reduce the long-term exposure of high-authority account keys by preventing Access Key signatures from being published on the blockchain.
The post-quantum security benefit is an important result of this architectural approach.
For this reason, OTAK-PQ was designed from the beginning as a complete account lifecycle, covering Secure Bootstrap, initial ownership establishment, one-time Child Keys, transaction execution, account recovery, and Merkle Tree rotation. The goal was to ensure that the keys with the highest level of authority over an account would never become part of the blockchain's permanent signature history.
We fully agree that post-quantum signature algorithms provide an essential path toward protecting blockchain transactions against known quantum threats. We therefore support TRON's move toward protocol-level post-quantum signature support and consider this direction both necessary and inevitable.
At the same time, we believe that reducing the long-term exposure of signatures associated with high-authority keys remains a valuable security principle, regardless of which signature algorithm is used.
From our perspective, even a highly secure signature algorithm, when its signatures are permanently published on a blockchain, leaves cryptographic data available to future adversaries. Therefore, reducing—and where possible eliminating—the long-term exposure of signatures associated with high-authority keys can provide an independent and complementary security layer against future threats. This is precisely the problem that OTAK-PQ was designed to address.
We also recognize that implementing OTAK-PQ at the protocol and ecosystem level is considerably more complex than integrating a new post-quantum signature algorithm. This complexity comes directly from its architectural objective: preventing Access Key signatures from being published on the blockchain and reducing the long-term exposure of high-authority account keys.
However, OTAK-PQ is not a competing or alternative signature algorithm to post-quantum algorithms. It is a different security architecture that can have an independent purpose and value even alongside a post-quantum signature algorithm.
We also recognize that implementing such an architecture would require significant effort in implementation, testing, maintenance, and review. Given that TRON is currently pursuing a clear path toward post-quantum signature support under TIP-899, we respect the TRON development team's decision to focus its current efforts on that direction.
If the TRON community does not currently see sufficient need for an additional architecture focused on effectively reducing long-term signature exposure, we fully respect that position.
There have already been efforts in some blockchain architectures to reduce or prevent signature exposure with relatively low overhead. However, this has not yet been widely pursued as an independent and continuous architectural approach. We designed OTAK-PQ with this perspective in mind, addressing the issue as a complete architecture covering the account lifecycle from beginning to end.
We are therefore glad to have contributed OTAK-PQ as a technical proposal to the community. The feedback we received was extremely valuable and encouraging. It helped transform a relatively unfamiliar idea, through deep technical discussion, into an architecture with a clearly defined path covering the entire account lifecycle. We sincerely appreciate everyone who contributed to its development and refinement through their questions, criticisms, and suggestions.
Ultimately, we will respect whichever direction the TRON development team chooses.
If circumstances change in the future and the ecosystem determines that reducing the long-term exposure of on-chain signing authority provides additional value, we would be ready to revisit the proposal and defend its design again.
Once again, we sincerely thank everyone for their time, expertise, technical feedback, and constructive discussion, which helped us develop and improve OTAK-PQ.
alichatme commentedon Aug 1, 2026
Following the valuable and in-depth feedback we received during this discussion — especially the points raised by Federico2014 and others — we have decided to review the proposal's primary focus and approach.
Our mistake: In the original OTAK-PQ version, we placed too much emphasis on the "quantum-resistant" aspect. This overemphasis caused the core value and fundamental principle of the architecture to remain somewhat in the background.
But what is the core principle? The core of this architecture is "non-exposure of signatures from keys with the highest level of authority over an account on the blockchain." The post-quantum aspect is a valuable consequence of this architecture, not its primary objective.
Why is this important? Signature exposure on the blockchain is not merely a theoretical concern for a quantum future. There are real and serious threats that endanger accounts today:
Nonce Reuse: In ECDSA algorithms, if two signatures are produced with the same Nonce, the private key can be easily extracted. This issue has led to billion-dollar thefts in recent years. Research has shown that over 3,600 private keys across multiple blockchains were extractable due to this vulnerability.
Replay Attacks: A valid signature can be reused across different networks or at different times. These attacks have been observed in numerous projects.
Malleability Attacks: The mathematical properties of elliptic curves allow an attacker to modify a valid signature and produce another valid signature.
Cryptographic Library Vulnerabilities: Even well-known libraries sometimes have vulnerabilities that cause signatures to be incorrectly validated or sensitive information to be leaked.
Does migrating to post-quantum algorithms solve all these problems? No. Even with migration to post-quantum algorithms like Falcon or ML-DSA, the Nonce issue still exists. In Falcon, random Nonce usage is mandatory, and any error or repetition can expose the key. In ML-DSA, fault attacks can also cause Nonce reuse. In other words, changing the signature algorithm does not solve the signature exposure problem; it merely shifts it to another level.
Fundamental Bootstrap Revision: One of the most important changes we will apply in this revision is the fundamental resolution of the Bootstrap problem. In the previous version, the Bootstrap process required an initial signature from the Access Key, which was performed without fees and without being recorded in the transaction history. In the new version, the account does not remain in a pending state, and Bootstrap will be redesigned so that no Access Key signature is ever published — neither during Bootstrap nor in any subsequent transaction. This is achieved by sending the Merkle Root and public key in the Bootstrap Request, followed by proof of ownership through the first Child Key.
What have other blockchains done? In the Ethereum ecosystem, EIP-8202 with a similar approach (Ephemeral secp256k1) seeks to reduce reliance on long-term signatures. Additionally, Account Abstraction-based designs (such as EIP-4337) also use one-time keys to enhance security and flexibility. This shows that the blockchain community is gradually recognizing the importance of "non-exposure of master key signatures."
Our Decision: Based on all the above, we have decided to revise the proposal under the new name OTAK-NES: One-Time Access Keys — Non-Exposure Security.
Key Changes:
Relationship with TIP-899: TIP-899 focuses on changing the signature algorithm (to PQC). OTAK-NES focuses on changing the account architecture so that Access Keys never publish a signature on the blockchain. These two approaches are complementary and can be used together. Even after TRON migrates to PQC, OTAK-NES will remain an independent security layer that prevents Nonce-related attacks and signature exposure.
Two additional clarifications regarding the multisig concerns raised earlier:
Multisig Integration: In OTAK-NES, each key listed in an Active Permission (or Owner Permission) can independently register its own Merkle Tree during Bootstrap. This means a multisig account with
msigners can have up tomindependent Merkle Trees. During a multisig transaction, each signer signs with a Child Key from their own tree and provides the corresponding Merkle Proof. The network validates each proof against the Merkle Root associated with that signer's Access Key, ensuring full compatibility with TRON's existing multisig model (TIP-16 and TIP-105).Separate Merkle Tree per Access Key: Using a separate Merkle Tree for each Access Key ensures independent key state (each key maintains its own
last_used_child_index), isolation in case of compromise (one compromised key does not affect others), simplified validation, scalability, and full support for mixed multisig (different keys can use different signature algorithms). This design preserves the security and flexibility of OTAK-NES while maintaining complete compatibility with TRON's Permission model.The full revised proposal text will be posted in this Issue soon.
We sincerely thank everyone who helped us better understand the core direction of this architecture through their critiques and suggestions.
Federico2014 commentedon Aug 3, 2026
Thank you for the clarification and for reframing the proposal around non-exposure security. Separating OTAK-NES from post-quantum migration makes its objective clearer. However, after evaluating the revised design against the current java-tron architecture, we believe it would have a substantial impact on the protocol and would be very difficult to implement safely.
OTAK-NES is not simply an additional signature algorithm. It introduces a new stateful authorization model and would require fundamental changes to the transaction format, Permission validation, account state, transaction ordering, multisig processing, consensus rules, wallets, and SDKs. In particular, the proposed
last_used_child_indexintroduces per-key ordering into TRON’s current transaction model, which has no account-level nonce. Its behavior would need to be defined consistently for pending, failed, expired, and same-block transactions, as well as block reorganizations.The revised Bootstrap process also does not yet establish a verifiable relationship between the submitted Merkle Root and the existing account’s Access Key. A signature from the first Child Key only proves control of a leaf in the submitted tree; it does not prove that the tree was authorized by the account owner. Solving this while preserving the existing account address and never publishing an Access Key signature would require an additional cryptographic binding mechanism, which would further increase protocol complexity.
In addition, the current Permission model directly matches recovered signer addresses against
Permission.keysand accumulates their weights. Since a Child Key does not match the registered Access Key, OTAK-NES would require an entirely new consensus validation path from the Child Key and Merkle proof to the original Permission Key and its weight. Therefore, the proposed multisig design cannot currently be considered fully compatible with the existing Permission model.Overall, the proposal affects many fundamental parts of the protocol and introduces significant consensus, compatibility, and implementation challenges. It may therefore be difficult to move forward without a complete revised specification and a detailed protocol-level assessment covering the Bootstrap mechanism, state transitions, compatibility, migration, performance, and security implications.
[-]TIP: OTAK-PQ — One-Time Access Keys for Quantum-Resilient Account Security[/-][+]OTAK-NES: A Blockchain Security Architecture for Non-Exposure of Long-Term Authorization Keys[/+]alichatme commentedon Aug 3, 2026
Dear @Federico2014
Thank you for your detailed technical review and constructive feedback throughout this discussion.
We carefully examined all the points you raised and acknowledge that your observations were highly technical and insightful — especially regarding the Bootstrap process, which you correctly identified as a fundamental challenge. The issue of linking the Merkle Tree to the actual account owner was a critical point, and your feedback prompted us to revisit and revise our Bootstrap approach.
Based on your comments and those of other community members, we have updated the architecture and begun a comprehensive revision of the proposal. We have always valued your insights and guidance, and we consider it an honor to have had the opportunity to discuss and collaborate with you.
Once the revision is complete, we would be grateful to receive your feedback, suggestions, and any solutions you may propose for the issues you identify. Your perspective has been invaluable to us throughout this process, and we look forward to continuing to learn from your expertise and guidance.
Thank you once again for the time you dedicated to us, your technical depth, and your constructive criticism.
With respect,
[Ali]
alichatme commentedon Aug 6, 2026
Thank you to everyone who participated in this discussion. The comprehensive revision of OTAK-NES, based on the valuable feedback received from the community, is now complete.
The updated document is available in this issue and is now ready for another round of technical review, with all identified issues addressed and fundamental improvements made, including:
Once again, thank you for your previous feedback and continued engagement.
Federico2014 commentedon Aug 10, 2026
Thank you for the clarification. From the protocol complexity, performance, and post-quantum security perspectives, the current design still has several important issues.
Protocol complexity
OTAK-NES is not only a key-management extension. It introduces a new stateful authorization model affecting the transaction format, account state, Permission validation, multisig processing, mempool behavior, block validation, and chain reorganization.
Each Access Key requires an independent
merkle_rootandlast_used_child_index. The protocol must define how this state is created, updated, removed, rotated, and rolled back.Child Key addresses do not match the Access Key addresses stored in
Permission.keys. Therefore, validation requires a new mapping path from Child Key and Merkle Proof to the original Permission Key and its weight.The strict
last_used_child_index + 1rule effectively introduces a per-key nonce. Its behavior remains unclear for concurrent, pending, failed, expired, reverted, same-block, and reorganized transactions.Bootstrap, Merkle Tree rotation, Permission updates, and multisig transactions all introduce additional consensus state transitions. In multisig transactions, several Child Key indices must be updated atomically.
Although the proposal states that transaction ordering does not change, sequential Child Key consumption creates account-level ordering and head-of-line blocking.
Performance and scalability
Every signature requires additional transaction data: Child public key, index, Merkle Proof, parent Access Key reference, and related metadata.
Merkle Proof size and verification cost grow as
O(log N). In multisig transactions, this overhead is repeated for every signer.The design avoids a growing consumed-key list, but it still adds persistent state for every Access Key, including its root, index, Bootstrap status, and rotation information.
Sequential indices reduce transaction concurrency. If transaction
iremains pending, transactioni + 1cannot be accepted without additional gap or replacement rules.Bootstrap and rotation introduce additional state writes and validation paths.
When combined with post-quantum signatures, the Merkle Proof overhead is added on top of the already larger PQ signature and public-key sizes.
The proposal currently provides no concrete measurements for transaction-size growth, verification latency, state growth, multisig overhead, or impact on block throughput.
Post-quantum security
OTAK-NES is not itself post-quantum secure when Child Keys use ECDSA. The Child public key and signature are exposed while the transaction is in the mempool.
A sufficiently capable quantum attacker could recover the Child private key before confirmation and submit a competing transaction using the same Child Key and index. Marking the key as consumed after confirmation is too late to prevent this attack.
The architecture mainly reduces the historical exposure of long-term Access Keys. It does not protect in-flight transactions and should not be described as protection against Shor’s algorithm without changing the underlying signature algorithm.
Protection of the Access Key also depends on the HD derivation scheme. The specification must show that exposure or compromise of a Child Key cannot reveal its parent Access Key.
Merkle Tree security is also affected by quantum search attacks, so the hash function, output size, domain separation, and tree construction must be explicitly defined.
The Bootstrap transaction still exposes an Active Key signature before that key is deactivated. Therefore, the claim that Access Key signatures are never published is not strictly correct.
Overall, OTAK-NES may reduce repeated long-term key exposure, but this benefit comes with substantial protocol complexity, additional transaction and verification overhead, reduced transaction concurrency, and limited protection against actual quantum attacks on transactions before confirmation.
alichatme commentedon Aug 11, 2026
Dear Federico,
Thank you for your thorough review and for the depth and precision of your technical questions. This level of technical discussion is extremely valuable to us and helps clarify the distinction between the overall OTAK-NES architecture and the protocol details required for a possible implementation on the TRON network.
The questions you raised primarily concern the following areas:
State size versus ordering semantics
Account state lifecycle (creation, update, removal, rotation, and rollback)
Child Key to Permission Key mapping and its weight in Permission.keys
Behavior of last_used_child_index + 1 in concurrent, pending, failed, expired, and reorg scenarios
Performance, scalability, and concrete benchmarking
Bootstrap behavior and Active Key signature exposure
Clarification of the "constant state" claim
Post-quantum security and mempool exposure
HD Derivation and Parent-Child security
Merkle Tree security against quantum search attacks
As is evident, a significant portion of these questions concern precise protocol behavior, state transitions, validation rules, performance characteristics, and other implementation-level considerations for deploying OTAK-NES on the TRON network.
To address these points, we have prepared a technical document consisting of eight parts. Each part addresses a specific implementation-related question raised in your review and provides additional clarification of how the proposed architecture could be defined at the protocol level.
At the architectural stage, OTAK-NES is intended to describe the overall security model and its underlying principles. The implementation details, however, require a more specific protocol definition and should ultimately be evaluated in the context of an implementation-oriented proposal for the network.
We therefore appreciate this level of technical review. The questions you raised provide a clear framework for identifying the implementation details that would need to be further specified and evaluated.
The following sections present the eight technical parts addressing the points raised in your review.
1. State Lifecycle Management
This section defines the lifecycle of OTAK-NES-related state for each Access Key.
Create
When a new Access Key is added to an account using a Child Key derived from the Owner Key, a Bootstrap process is initiated for the new Access Key.
Upon successful completion of the Bootstrap process, the network creates a new OTAK-NES state entry for that Access Key, including:
merkle_root: the Merkle Root of the Child Key tree associated with the Access Key.
last_used_child_index: the index of the last consumed Child Key, initialized to zero.
bootstrap_status: the Bootstrap status, marked as completed.
rotation_information: information describing the state of any ongoing or pending Merkle Tree rotation.
Update
After each successful transaction is confirmed on-chain, the network atomically updates last_used_child_index to the index of the Child Key used by that transaction.
This update occurs as part of the transaction's state transition and is committed together with the transaction.
Remove
If an Access Key is removed from the account's Permission list through an AccountPermissionUpdateContract transaction, the network permanently removes the corresponding OTAK-NES state entry for that Access Key.
All Child Keys associated with the removed Access Key become permanently invalid and cannot be used to authorize future transactions.
Rotate
When the active Merkle Tree reaches its defined Rotation Window, the wallet automatically submits a rotation transaction.
After successful confirmation of the rotation transaction, the network:
replaces the stored merkle_root with the new Merkle Root;
resets last_used_child_index to zero; and
marks the previous Merkle Tree as permanently inactive.
The new Merkle Tree then becomes the active authorization tree for that Access Key.
Rollback
In the event of a blockchain reorganization (reorg), the network state reverts to the state associated with the last valid block.
Using the existing SnapshotManager mechanism, any OTAK-NES state changes introduced by transactions in reorged blocks are rolled back atomically.
This ensures that:
last_used_child_index returns to its previous valid value;
Child Keys consumed by transactions in reorged blocks become available again; and
any Merkle Root replacement introduced by a reorged rotation transaction is reverted.
Therefore, OTAK-NES state remains consistent with the canonical blockchain state after a reorganization.
2. Child Key to Permission Key Mapping
Because Child Key addresses are distinct from the Access Keys stored in Permission.keys, the network must follow a defined mapping path during transaction validation:
Transaction → Child Key → Merkle Proof → Registered Merkle Root → Associated Access Key → Permission Entry → Weight
The mapping process is as follows:
The network receives a transaction containing a Child Key signature and its corresponding Merkle Proof.
The network uses the Child Key and the provided Merkle Proof to verify that the Child Key is a valid member of the Merkle Tree corresponding to a Merkle Root registered in the account state.
Once the corresponding registered Merkle Root is identified, the network determines the Access Key associated with that Merkle Root.
The network locates the Permission entry (Owner or Active) containing the associated Access Key and retrieves its assigned weight.
The network applies the retrieved weight to the multisignature threshold calculation.
This mapping establishes a deterministic relationship between the Child Key used to authorize a transaction and the original Access Key represented in the account's Permission.keys structure.
The approach is compatible with the existing Permission model, including the structures defined by TIP-16 and TIP-105, and does not require replacing or redesigning the underlying Permission.keys model.
3. Performance and Scalability Analysis
OTAK-NES adds additional data and validation steps to each transaction. The resulting overhead is expected to be manageable, but its exact impact depends on the final transaction encoding, implementation, hardware environment, block limits, and workload characteristics.
The estimates below are therefore preliminary architectural estimates and are provided to illustrate the expected order of magnitude. They are not intended to replace measurements from an implemented prototype.
Merkle Proof Size
For a balanced binary Merkle Tree using 256-bit hashes:
For a Merkle Tree containing approximately 1 million Child Keys (depth ≈ 20), a Merkle Proof requires approximately 20 hashes × 32 bytes = 640 bytes.
For a Merkle Tree containing approximately 1 billion Child Keys (depth ≈ 30), a Merkle Proof requires approximately 30 hashes × 32 bytes = 960 bytes.
These figures represent the Merkle Proof itself and do not include the Child Key, index, Access Key reference, or other transaction metadata.
Verification Cost
A Merkle Proof for a tree of approximately 1 million Child Keys requires approximately 20 hash operations.
As a preliminary estimate, this represents a relatively small computational cost compared with public-key signature verification. For reference, an ECDSA verification may typically require substantially more computation than a sequence of approximately 20 hash operations.
Exact verification latency will depend on the implementation and execution environment and will be measured through the planned PoC benchmark.
Estimated Transaction Size Overhead
A single OTAK-NES transaction is expected to include additional data such as:
Child Public Key: approximately 33 bytes
Child Index: approximately 4 bytes
Merkle Proof: approximately 640 bytes for a 1-million-Child-Key tree
Parent Access Key reference: approximately 4 bytes
Additional metadata: approximately 20 bytes
This results in an estimated protocol-level overhead of approximately 700 bytes per transaction under the 1-million-Child-Key example.
The exact serialized size will depend on the final transaction format and encoding.
Preliminary Block Throughput Estimate
For illustration, assuming:
a 1 MB block size, and
an average standard transaction size of approximately 200 bytes,
a block could contain approximately 5,000 standard transactions before accounting for other protocol overhead.
If approximately 700 bytes of OTAK-NES data were added to each transaction, the resulting transaction size would be approximately 900 bytes, corresponding to roughly 1,100 transactions per 1 MB block under this simplified model.
This is an illustrative capacity estimate rather than a measured throughput result. Actual throughput will depend on transaction composition, serialization, signature verification cost, block-processing limits, and implementation details.
Multisignature Overhead
For a multisignature transaction with m signers, the Merkle Proof and associated Child Key data are expected to be provided for each OTAK-NES signer.
For example, in a 2-of-3 multisignature transaction, if two signers use OTAK-NES and each contributes approximately 700 bytes of additional data, the estimated additional overhead would be:
2 × 700 bytes ≈ 1,400 bytes
This is an estimate of the OTAK-NES-specific signer overhead and does not represent the complete serialized size of the multisignature transaction.
Preliminary Estimates and PoC Benchmark
The numerical values presented in this section are preliminary estimates intended to provide an initial assessment of the expected performance and scalability characteristics of OTAK-NES.
A Proof of Concept (PoC) will be used to establish empirical measurements for:
Transaction size growth
Merkle Proof verification latency
Signature and combined validation latency
Account-state growth
Multisignature overhead
Block-processing and throughput impact
Bootstrap and Merkle Tree rotation costs
Where practical, the PoC may be evaluated in a TRON-compatible test environment, including the Nile test network, before production-level conclusions are drawn.
The measured results will be used to refine the final protocol parameters and replace preliminary estimates with implementation-based measurements.
4. Information Stored in Account State
OTAK-NES-related account state is bounded and grows only with the number of registered Access Keys, rather than with the number of transactions or consumed Child Keys.
Key Point
The OTAK-NES state does not grow on a per-transaction basis. Consuming additional Child Keys does not create additional persistent state. State growth is limited to the number of registered Access Keys and their associated authorization structures.
For each Access Key, the estimated OTAK-NES-related state includes:
merkle_root: 32 bytes
last_used_child_index: approximately 4–8 bytes
bootstrap_status: approximately 1 byte
rotation_information: approximately 4 bytes
This results in an estimated total of approximately 40–45 bytes per Access Key, depending on the final state encoding.
Under the current TRON Permission model, an account may contain a maximum of 1 Owner Key and 8 Active Keys, for a total of 9 Access Keys.
Accordingly, the maximum OTAK-NES-related state under this model is approximately:
9 × 45 bytes ≈ 405 bytes per account
Therefore, although the account state is not strictly constant, its OTAK-NES-specific growth is bounded and linear with respect to the number of registered Access Keys (maximum 9 under the current Permission model) and does not increase with the number of transactions or consumed Child Keys.
This design avoids the need to maintain a growing list of consumed Child Keys while retaining sufficient state to enforce sequential Child Key authorization.
5. Post-Quantum Security Clarification
OTAK-NES is not a post-quantum signature algorithm. It does not replace, compete with, or attempt to substitute post-quantum signature schemes such as ML-DSA, Falcon, or SLH-DSA.
OTAK-NES is not a signature layer. It is an authorization and security architecture designed to reduce the long-term exposure of authorization-key signatures.
Blockchain networks should continue to migrate toward stronger and, where appropriate, post-quantum signature algorithms as those technologies become available. OTAK-NES is designed to remain compatible with different signature schemes rather than depending on a specific signature algorithm.
The architectural contribution of OTAK-NES is:
OTAK-NES reduces the long-term exposure of Access Key signatures. Post-quantum security depends on the signature algorithm used by the Child Keys.
When Child Keys use a classical signature algorithm such as ECDSA, OTAK-NES does not provide post-quantum protection against attacks on in-flight transactions or against the exposure of signatures and public keys in the mempool.
This distinction is fundamental to the security model: OTAK-NES addresses key exposure and authorization architecture, while post-quantum cryptography addresses the cryptographic security of the underlying signature scheme.
However, OTAK-NES is designed to be fully compatible with post-quantum signature algorithms. When a network supports a suitable PQC signature scheme, Child Keys may use that scheme for transaction authorization.
This allows the two security layers to complement each other:
OTAK-NES limits the long-term exposure and reuse of authorization keys.
Post-quantum signatures provide resistance against quantum attacks on the underlying signature mechanism.
Together, they can provide both architectural key-isolation benefits and post-quantum cryptographic protection.
Accordingly, future implementations may combine OTAK-NES with post-quantum signature schemes for Child Keys, providing a migration path in which the authorization architecture does not need to be fundamentally redesigned when the underlying signature algorithm is upgraded.
Child Keys may use a post-quantum signature scheme when supported by the network.
6. HD Derivation Security
OTAK-NES uses deterministic hierarchical key derivation based on standards such as BIP32/BIP44 and, where applicable, TRC-102 on TRON.
The security of the Parent–Child relationship depends on the selected derivation scheme and the exact derivation path. To provide strong isolation between Child Keys and their parent authorization keys, OTAK-NES uses Hardened Derivation at the security-critical levels of the derivation hierarchy.
A representative derivation structure is:
m / purpose' / coin_type' / account' / change / address_index
The exact derivation path and the hardened/non-hardened status of each level will be explicitly defined by the final OTAK-NES implementation specification.
Security Properties
Child Private Key Isolation
A Child Private Key derived through the hardened portion of the hierarchy cannot be used by itself to derive or recover the Parent Private Key. Therefore, exposure of an individual Child Private Key does not by itself compromise the corresponding parent authorization key.
Child Public Key Isolation
At hardened derivation boundaries, Child Public Key information alone is insufficient to derive the corresponding Parent Private Key. The derivation design therefore prevents a Child Public Key from providing a practical path to recovery of the Parent Private Key.
Chain Code and Extended Public Keys
OTAK-NES does not require the network to store or publish wallet-level Chain Codes or Extended Public Keys (xpub). These values remain under wallet control and are not part of the on-chain authorization state.
Derivation Requirement
The final OTAK-NES specification will explicitly define the derivation standard, derivation path, hardened boundaries, and key-isolation requirements.
In particular, the specification must ensure that compromise of an individual Child Key does not provide a practical mechanism for recovering or compromising its Parent Access Key.
Conclusion
Parent–Child security in OTAK-NES is therefore a property of the chosen derivation standard, derivation path, and hardened boundaries, rather than an assumption made by the OTAK-NES authorization model itself.
When implemented with an appropriate hardened derivation structure, compromise of an individual Child Key does not compromise the Parent Access Key.
7. Merkle Tree Quantum Security
Quantum search algorithms such as Grover's algorithm can reduce the effective preimage security of cryptographic hash functions and therefore must be considered when evaluating the long-term security of a Merkle Tree.
With appropriate parameter selection, this reduction remains manageable for currently foreseeable quantum computing capabilities.
Hash Function and Output Size
The current OTAK-NES design uses SHA-256 as its baseline hash function, with a 256-bit output.
Grover's algorithm theoretically reduces the generic preimage security of an ideal n-bit hash function from approximately 2^n to 2^{n/2} operations. For SHA-256, this corresponds to an effective generic preimage security level of approximately 2^{128} quantum operations.
This remains an extremely high security level and is not considered practically achievable with foreseeable quantum computing technology.
Future implementations may adopt a hash function with a larger security margin, such as SHA-512, if required by the network's long-term security policy.
Domain Separation
OTAK-NES uses explicit domain separation between leaf nodes and internal Merkle nodes.
Leaf and internal-node inputs are encoded differently before hashing so that a value intended for one level of the tree cannot be interpreted as a valid input for another level.
For example, a domain-separated construction may use distinct prefixes for leaf and internal-node hashing:
H(0x00 || leaf_data)
and
H(0x01 || left_hash || right_hash)
The exact encoding and domain-separation constants will be defined by the final protocol specification.
This construction prevents structural ambiguity between leaf data and internal-node data and strengthens the integrity of the Merkle Tree construction.
Tree Construction
The OTAK-NES Merkle Tree uses a binary tree structure with a defined maximum depth appropriate for the supported Child Key namespace.
The final specification will explicitly define:
Leaf ordering
Leaf encoding
Internal-node encoding
Padding rules
Empty-node handling
Tree depth
Hashing rules
Domain-separation constants
These rules ensure deterministic Merkle Root generation and unambiguous Merkle Proof verification across all network nodes.
Quantum Security Considerations
The security analysis of the Merkle Tree will consider the relevant generic quantum attacks, including:
Preimage attacks
Collision attacks
Second-preimage attacks
Quantum search attacks against the underlying hash function
The security of the Merkle Tree is therefore not treated as independent of the underlying hash function. Its security level is derived from the cryptographic properties of the selected hash function and the exact tree construction.
Specification Commitment
The next version of the OTAK-NES specification will explicitly define:
The selected hash function
Hash output size
Leaf and internal-node domain separation
Leaf encoding and ordering
Padding and empty-node rules
Merkle Tree construction
Merkle Proof format
Quantum security considerations, including preimage, collision, and second-preimage resistance
This makes the Merkle Tree construction deterministic, independently verifiable, and suitable for formal security analysis.
8. Bootstrap Clarification
The statement that “Access Key signatures are never published” is not entirely accurate and should be clarified.
The correct formulation is:
Operational Access Key signatures are not continuously exposed.
For networks that do not support Zero-Knowledge-based registration, OTAK-NES requires a one-time Bootstrap signature during account initialization. This signature is used to register the Merkle Root associated with the Access Key.
After the Bootstrap transaction has been successfully validated and committed to the blockchain state, the Bootstrap Active Key is automatically and permanently deactivated according to the OTAK-NES protocol rules.
This means:
Long-term Access Keys are not used for routine transaction signing after OTAK-NES Bootstrap has been completed.
The Bootstrap signature is a single, isolated exception that occurs only during account initialization.
After successful Bootstrap, the Bootstrap Active Key is removed from the account's authorized signing keys and can no longer authorize subsequent transactions.
Other Owner and Active Keys remain independent and are not affected by the deactivation of the Bootstrap Active Key.
Subsequent operational transactions are authorized exclusively through the OTAK-NES Child Key mechanism.
This approach provides a practical Bootstrap mechanism for networks that have not yet adopted Zero-Knowledge-based registration while preserving the intended long-term security model of OTAK-NES.
Correct statement:
Operational Access Key signatures are not continuously exposed. For networks that do not support Zero-Knowledge-based registration, a one-time Bootstrap signature may be exposed during account initialization, after which the Bootstrap Active Key is automatically and permanently deactivated following successful Bootstrap validation and state commitment.
We would also like to thank the TRON community for providing us with the opportunity to introduce, discuss, and refine this proposal.
If further implementation details are required for deploying OTAK-NES on the network, we would be glad to proceed with a new Pull Request (PR), shifting the proposal from a general architectural design toward a formal proposal for the TRON network and allowing the implementation details to be reviewed in greater depth.
With the guidance and technical expertise of the TRON developer community, this process would allow us to work together with you and other developers to complete the final specification.
We welcome this level of technical review and look forward to continuing our collaboration with the TRON developer community in the next stage of the proposal.
xxo1shine commentedon Sep 10, 2026
@alichatme, thank you for continuing to refine the proposal and for clarifying its security boundaries and implementation details.
We recognize the goal of reducing long-term authorization-key exposure and containing the impact of an individual operational key compromise. However, for TRON's current post-quantum migration, we favor prioritizing standardized post-quantum signatures.
First, when Child Keys still use ECDSA, an attack window remains between transaction broadcast and confirmation. If an attacker recovers the child private key during this window, they can sign a competing transaction using the same Child Key, index, and Merkle Proof. One-time consumption prevents reuse, but it does not guarantee that the transaction accepted first is the user's original transaction. A Merkle membership proof alone also does not restrict authorization to the amount and recipient of that original transaction.
Second, sequential indices, key rotation, Bootstrap, atomic multisig updates, and reorg rollback require a new set of stateful authorization rules. Even without storing a consumed-key list on-chain, these rules still affect transaction concurrency, wallet coordination, and consensus validation. The performance figures provided so far remain estimates and are not yet sufficient to establish that the additional security benefits justify these costs.
For these reasons, we do not currently recommend making OTAK-NES a prerequisite for, or an alternative to, post-quantum migration. If you continue exploring this direction, we suggest first providing a complete specification and a standalone prototype. In particular, comparing direct use of PQ signatures with OTAK-NES combined with PQ signatures—in terms of incremental security benefits, transaction overhead, throughput, and recovery complexity—would help establish whether introducing this architecture into the core protocol is justified.
alichatme commentedon Sep 10, 2026
Dear @xxo1shine
We appreciate your technical approach in raising questions that stem from the depth of the architecture.
The points you have raised are entirely valid and demonstrate a deep understanding of the challenges involved in implementing security architectures at the protocol level. Allow us to address each of your three concerns separately:
In the example you provided, you noted that if a Child Key is signed with ECDSA, an attacker within the window between Broadcast and Confirmation could, by recovering the Child's private key, sign a competing transaction with the same Child Key, the same Index, and the same Merkle Proof. And the Merkle Proof alone is not restricted to the amount and recipient of the original transaction.
Let us first explain the core security principles of OTAK-NES upon which the architecture is built:
The most important principle of Child Key construction: An attacker cannot construct a new Child Key merely by possessing the private and public keys recovered from a signature.
In the OTAK-NES architecture, the standard Hierarchical Deterministic (HD) Key Derivation mechanism is used to generate Child Keys. In this mechanism, the private key alone is not sufficient to generate a Child Key; rather, the parent key (which in OTAK-NES is the Access Key) is used in the derivation process in the form of an Extended Key containing at least the Private Key and Chain Code.
Chain Code is a 32-byte value that plays the role of an encrypted input for HMAC-SHA512 in the BIP32/TRC-102 derivation process. Therefore, Chain Code is not merely a simple "Salt"; it is part of the Extended Key structure and one of the essential components for deriving Child Keys.
For this reason, having a private key alone does not mean having the necessary information to construct a Child Key.
Our supplementary response, assuming the attacker replaces the Child Key:
a) The first advantage of OTAK-NES — as you yourself correctly pointed out — is that recovering the signature of a Child Key means limiting the attack scope to that specific transaction, and not to the Access Key and consequently the entire account's assets.
The primary goal of OTAK-NES, as you also noted, is to reduce the exposure of long-term keys and limit the attack scope to a specific transaction — not to completely eliminate the attack window. In the current architecture and with the network's current signatures, the compromise of an Access Key means the entire account and all its assets are at risk. In OTAK-NES, this scope is limited to a single transaction and a specific asset due to the use of Child Keys.
b) The technical solution for this window, in combination with sequential rules:
With Sequential Transaction Ordering and Child Key Index Matching (last_used_child_index + 1) active, the network validates transactions sequentially. Therefore:
As explained, in this scenario, the attacker is defeated.
More detailed, step-by-step explanation:
If we also add the ATHENA architecture to the example you provided, even the possibility of the attacker changing the amount and substituting the address is eliminated.
This is because, under the ATHENA architecture, every transaction is sent along with an Execution Permit. The Execution Permit includes items such as the sender and recipient addresses, the asset amount, and other details. A copy of it is stored in the Canonical Copy, and during the validation stages, the Execution Permit is verified at least at one stage; if the address has been changed, the transaction is returned.
In the proposal we presented on the TIP-899 page, we consistently referred to the golden combination of three architectures:
We discussed in detail the migration challenges and the advantages of combining these three architectures.
c) In the Post-Quantum scenario:
When Child Keys are signed with a post-quantum signature algorithm (such as FN-DSA-512) — and this is while the OTAK-NES architecture is completely independent of the underlying signature layer — the quantum attack window is completely closed, because the quantum attacker cannot recover the Child's private key even with a large time window.
d) Regarding the limitation of Merkle Proof to the amount and recipient:
Given that the ATHENA architecture has been introduced to the network, and transactions — after ATHENA's implementation — are sent along with an Execution Permit that includes items such as the recipient and sender addresses, the amount, the asset type, and predictable behavior, and this permit is verified at least at one stage,
the accompaniment of a transaction with a verifiable permit adds countless security advantages to the network. Although we did not correctly address or introduce this in the proposal, we intend to address the security advantages of this method in the same proposal at the earliest opportunity and add the prepared text to the proposal.
And as we mentioned at the beginning of the text, the core security principles of the OTAK-NES architecture are based on:
The other values you mentioned, although not public, are not inaccessible to an attacker either, and we have not based the OTAK-NES security assumption on them.
The text of the core principles of the OTAK-NES architecture will be promptly prepared based on your suggestion and added to the proposal.
However, your point is entirely correct. In the current version of OTAK-NES, the Merkle Proof only proves the Child Key's membership in the authorized tree, not the restriction of the amount and recipient.
This can be proposed as an additional security feature in future versions — for example, by adding a Commitment to the amount and recipient in the Merkle Proof, or using Zero-Knowledge Proofs to prove transaction restrictions. This suggestion can be considered in the design of the next version of OTAK-NES.
Your point is correct that OTAK-NES introduces new Stateful rules. But let us break it down:
a) What is added:
Item Type of Impact
last_used_child_index State at account level — Replay prevention
merkle_root State at account level — Membership validation
bootstrap_completed Flag — Architecture activation
Sequential Index Matching Validation rule — Transaction ordering (which currently also exists in the network)
Rotation Window Wallet rule — Tree rotation
b) What is not stored:
c) Key advantage:
Using last_used_child_index instead of a complete list means:
d) Accepting the costs:
To reduce costs, we proposed the easy migration method and included it in the proposal text, and through a phased migration approach, we made the architecture's implementation as easy as possible.
We accept that these rules require wallet coordination, Concurrency redesign, and validation. However, we believe these costs are justified compared to the fundamental security benefit (preserving the assets of non-migrated accounts on quantum day-zero).
This text was published a few moments ago in full on the TIP-899 page and will be added to the proposal at the earliest opportunity:
#899
Your point is entirely fair. The current figures are estimates and are not sufficient to justify the costs.
Our proposal:
We are prepared, in the next stage, to:
Criterion Direct PQ OTAK-NES + PQ
Incremental security benefit Baseline + Preserving non-migrated accounts' assets on day-zero
Transaction overhead Low Medium (Merkle Proof + Index)
Throughput High Evaluable (requires Prototype)
Recovery complexity Low Low (Seed-based)
This comparison will serve as the basis for deciding whether to justify or not justify the introduction of this architecture into the protocol core.
The Quantum Day-Zero Challenge
The most important point we would like to emphasize is the quantum day-zero challenge:
This text was sent a few moments ago on the following page and will be added to the OTAK-NES proposal at the earliest opportunity:
#899
In this text, it is explained that:
If the quantum threat materializes and the network has migrated to OTAK-NES, even accounts that have not completed or begun the migration process will be immune to asset theft, because:
This capability is the answer to a challenge for which NIST and other leading networks have so far not found a decentralized solution.
We are proud to announce that this architecture provides a scientific and decentralized solution for transferring the assets of accounts that, prior to the quantum attack's materialization, have not completed or begun the migration process to the post-quantum signature or the OTAK-NES architecture — that is, at "quantum hour-zero," the moment the quantum attack is realized and becomes practical.
This text will be added to the proposal at the earliest opportunity.
Summary and Final Proposal
We fully agree that:
At present, TRON's priority should be migration to standard post-quantum signatures.
But migration with the correct technical approach and based on security principles.
In our view, the best approach is to add post-quantum signature support capability to the network as the first priority.
And second, complete migration by active users, in such a way that a new account is created with the signature algorithm added to the network, and assets are transferred to the new account.
However, one challenge remains in the network: accounts that, prior to the quantum attack's materialization, did not complete the migration process by creating a new account or an alternative process. The OTAK-NES architecture can be the solution for these accounts.
Our proposal for the next stage:
We are prepared to cooperate technically with this network's engineers at any stage that the TRON team deems necessary.
Respectfully,
AliChatme@
xxo1shine commentedon Sep 11, 2026
@alichatme, the premise that “the original transaction is broadcast first, so it must be confirmed first” needs to be reconsidered. Broadcasting a transaction to a node does not mean it has reached a block producer or secured an immutable confirmation order.
For example, under the quantum-attack assumptions you describe, a user could submit a transaction to a malicious node. That node could withhold the original transaction, recover the exposed Child private key, and use the same Child Key, Index, and Merkle Proof to sign a replacement transaction with a different recipient or amount, then broadcast it to block producers. If the replacement is confirmed first, it consumes the index, and the user's original transaction would instead be rejected with
CHILD_KEY_CONSUMED.This attack does not require deriving a new Child Key or obtaining the Seed or Chain Code. You have confirmed that the current Merkle Proof establishes membership in the authorized tree but does not bind the original transaction's amount or recipient. Sequential indexing therefore ensures that an index can be consumed only once; it does not ensure that the transaction consuming it is the one originally signed by the user. The absence of fee bidding does not provide that guarantee either.
I suggest explicitly retaining this security limitation: when ECDSA Child Keys are used, OTAK-NES alone does not prevent transaction replacement following private-key recovery before confirmation. If addressing this requires post-quantum signatures or an additional authorization mechanism from ATHENA, their security assumptions should be specified separately rather than treated as protection already provided by the current OTAK-NES design.
alichatme commentedon Sep 11, 2026
Dear @xxo1shine
Thank you for raising this scenario. Allow us to address it in two parts.
First — Clarification on How Transaction Propagation Works in a Decentralized Network
The premise that "a user could submit a transaction to a malicious node, that node could withhold the original transaction" requires further clarification. In a decentralized blockchain network, a transaction is not sent to a single node. It is broadcast to the network.
Even if a user submits a transaction through a specific RPC endpoint, that transaction is immediately propagated across the P2P network via the gossip protocol and becomes accessible to the vast majority of nodes within a fraction of a second. The scenario in which a single malicious node can withhold a transaction from the entire network requires that node to effectively control the P2P propagation layer — which, in a decentralized network with thousands of nodes, is practically infeasible.
It is worth noting that this scenario is not specific to OTAK-NES. Under the same assumption — a malicious node capable of withholding a transaction — the current TRON architecture, as well as TIP-899 on its own, would face the identical limitation. This is a network-layer concern, not a limitation introduced by OTAK-NES.
Second — Separation of Responsibilities: OTAK-NES vs. Network Threat Model
The scenario you describe falls within the Network Threat Model, not within the OTAK-NES architecture's scope of responsibility. The OTAK-NES threat model explicitly states that it assumes the underlying network operates in a decentralized manner with a majority of honest nodes. It is not designed to protect against a fully compromised network layer.
If we were to design a solution for every possible scenario involving a malicious node — censorship, withholding, propagation manipulation, RPC-level attacks — we would be addressing issues that belong to the network layer and consensus layer, not to the key lifecycle architecture.
That said, we acknowledge that this concern is valid in principle, and we believe it can be addressed through the combination of architectures we have proposed:
· ATHENA introduces the Execution Permit and Canonical Copy, which ensure that the transaction's authorized parameters (sender, recipient, amount, asset type) are cryptographically bound and verified at least at one stage of validation. Any attempt to substitute the transaction with different parameters would be detected and rejected during permit verification.
· In the post-quantum scenario, when Child Keys are signed with a PQ algorithm, the attack window described is completely eliminated — because the quantum attacker cannot recover the Child private key even with an unlimited time window.
Third — On the Value of This Discussion
We fully agree with your suggestion that this limitation should be explicitly acknowledged, and we appreciate the technical precision with which you have framed it. At the same time, we believe it is important to distinguish between:
· Limitations inherent to the OTAK-NES architecture — which we have addressed and continue to refine.
· Limitations inherent to any decentralized network — which apply equally to all architectures, including the current TRON model and TIP-899 alone.
We are prepared to document this distinction clearly in the OTAK-NES proposal, and to work with the TRON team on the appropriate treatment of network-layer threat scenarios within the broader post-quantum migration architecture.
Thank you again for the constructive technical dialogue.
Respectfully,
AliChatme@
xxo1shine commentedon Sep 17, 2026
@alichatme, this does not require the malicious node to control the entire P2P propagation layer. When a user submits a transaction through a single RPC service, the node behind that service is the original transaction's first entry point into the network. That node can withhold the original transaction while using the recovered Child private key to construct and broadcast a replacement transaction.