OTAK-NES: A Blockchain Security Architecture for Non-Exposure of Long-Term Authorization Keys

[alichatme]

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:

1. 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.

2. 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.

[alichatme]

---

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) is a blockchain security architecture that prevents long-term authorization keys from ever producing transaction signatures on-chain.

Instead of allowing high-authority keys to sign transactions directly, OTAK-NES introduces one-time authorization keys ("Child Keys") derived from an authorization key according to the TRC-102 hierarchical key derivation model. Each Child Key is authorized through a Merkle Proof against a Merkle Root committed by the account during the Bootstrap process.

Every 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.

The architecture is independent of the underlying signature algorithm. It can operate with existing elliptic-curve signatures as well as future post-quantum signature schemes. Its objective is not to replace signature algorithms, but to eliminate long-term exposure of authorization-key signatures on the blockchain.

One-Time Access Key (Child Key)

A Child Key is a one-time authorization key derived from an account authorization key using the TRC-102 hierarchical derivation model.

A Child Key is considered valid only if:

. it is derived from the account's registered authorization key;
. its membership in the committed Merkle Tree is proven through a valid Merkle Proof;
. it has not previously been consumed.

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 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, the impact is limited to that single Child Key and does not expose the long-term authorization key or compromise control of the account.

---

---

Why Preventing Long-Term Signature Exposure Matters

1. Blockchain Permanently Publishes Digital Signatures

In most blockchain systems, every outgoing transaction permanently records its digital signature as part of the immutable ledger. While these signatures are required for transaction verification, they also become publicly accessible cryptographic artifacts that remain available indefinitely.

Unlike traditional systems where credentials may be rotated or removed, blockchain signatures cannot be deleted once recorded. As computational capabilities evolve, historical signatures remain available for future cryptographic analysis.

Consequently, long-term authorization keys gradually accumulate publicly available signature material throughout the lifetime of an account.

2. Historical Experience Shows That Signature Exposure Can Become a Security Liability

Several incidents across the blockchain ecosystem have demonstrated that weaknesses related to signature generation, nonce handling, implementation bugs, or key management can ultimately result in private-key compromise.

Examples include:

. Nonce reuse vulnerabilities in ECDSA implementations.
. Faulty random number generation.
. Signature malleability issues.
. Weak multisignature implementations.
. Operational key-management failures.

Although these incidents have different root causes, they share one common characteristic:

Once a long-term authorization key repeatedly signs transactions, a permanent public record of its signatures is created.

The larger this historical record becomes, the greater the amount of cryptographic material available for future analysis.

3. Modern Blockchain Research Is Moving Toward Reducing Long-Term Key Exposure

Recent blockchain research increasingly explores methods that reduce direct exposure of long-term authorization keys.

Examples include:

. Ephemeral transaction keys.
. Merkle-committed key sets.
. Zero-knowledge ownership proofs.
. Threshold signature systems.
. Stateless authorization models.

Although these approaches differ technically, they pursue a common architectural objective:

Minimize the number of times a long-term authorization key directly signs publicly visible transactions.

4. OTAK-NES Follows the Same Architectural Principle

OTAK-NES adopts this security philosophy while remaining independent of any particular signature algorithm.

Instead of allowing long-term authorization keys to participate directly in routine transaction signing, OTAK-NES introduces one-time Child Keys derived from authorized account keys.

Each transaction is signed by a unique Child Key whose authorization is verified using:

. a Merkle Proof provided in the transaction, and
. the Merkle Root associated with the account.

After successful confirmation, the Child Key is permanently marked as consumed and cannot authorize another transaction.

As a result:

. long-term authorization keys remain isolated from everyday transaction signing,
. publicly exposed signatures belong only to disposable Child Keys,
. any compromise is limited to a single Child Key rather than the entire authorization hierarchy.

5. Security Benefits

OTAK-NES provides several architectural advantages:

. Long-term authorization keys are isolated from routine transaction signatures.
. Every Child Key is intended for one-time authorization only.
. Security incidents are compartmentalized to individual Child Keys.
. The architecture is independent of the underlying signature algorithm and can operate alongside classical or post-quantum signature schemes.
. Authorization remains verifiable using standard cryptographic proofs without repeatedly exposing long-term signing keys.

Conclusion

OTAK-NES does not attempt to replace existing digital signature algorithms.

Instead, it introduces an authorization architecture whose primary objective is to minimize long-term exposure of high-authority signing keys by transferring routine transaction authorization to disposable, cryptographically verifiable Child Keys.

This architectural separation reduces the amount of long-lived signature material exposed on-chain while preserving public verifiability and compatibility with future cryptographic developments.

---

---

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:

. minimize long-term exposure of authorization keys;
. ensure that publicly exposed signatures belong only to disposable Child Keys;
. confine any future cryptanalytic breakthrough to temporary authorization keys rather than permanent account authorization keys.

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.

. Nonce Reuse:
A nonce reuse event can only affect the corresponding one-time Child Key. Long-term authorization keys remain isolated from transaction signing.

. Replay:
Replay opportunities are reduced by binding each Child Key to a unique authorization state and one-time consumption rules.

. Signature Malleability:
Signature malleability may still exist at the algorithm level, but its practical impact is limited because Child Keys cannot be reused after successful authorization.

. Fault Injection:
Any successful attack is confined to a disposable Child Key rather than exposing long-term authorization keys.

. Side-Channel Attacks:
Information leakage from a Child Key affects only that temporary authorization key and does not directly expose long-term authorization keys.

. Signature Forgery:
An attacker must simultaneously satisfy signature verification and produce a valid Merkle Proof corresponding to the authorized key hierarchy.

. Quantum Cryptanalysis:
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:

. collision resistance;
. second-preimage resistance;
. secure implementation;
. correct tree construction.

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:

. the Child Key;
. its Merkle Proof;
. the transaction signature.

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:

. compact representation of potentially millions of Child Keys;
. logarithmic verification complexity;
. decentralized verification without trusted intermediaries;
. efficient bandwidth and storage usage;
. cryptographic integrity of the authorization hierarchy;
. compatibility with large-scale blockchain systems.

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:

. Any participant can independently verify any historical transaction at any time
. The cryptographic relationship between the transaction, its signature, and the corresponding public key remains publicly verifiable
. Auditors, validators, exchanges, regulators, and users can independently validate historical transactions without requiring access to private keys or trusted third parties

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:

. Every transaction is signed by a one-time Child Key.
. Child Keys are deterministically derived from long-term authorization keys using the blockchain's supported hierarchical deterministic (HD) derivation mechanism
. The Child Key signature is permanently recorded on-chain according to the normal blockchain protocol
. The Child Key public key remains publicly available for signature verification.
. A Merkle Proof included in the transaction proves that the Child Key belongs to the account's authorized key hierarchy
. The corresponding Merkle Root is stored in the account state and remains publicly verifiable

Consequently, any participant can independently verify:

1. the digital signature

2. the validity of the Merkle Proof

3. the inclusion of the Child Key in the authorized hierarchy

4. that the Child Key had not been consumed before execution

5. 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:

. The transaction signature remains permanently stored on-chain.
. Historical verification remains fully possible.
. Merkle Proof validation remains valid indefinitely.
. The consumed status only affects future authorization, not historical auditability

Therefore, OTAK-NES separates authorization validity from historical verifiability.

4. Preservation of Decentralization

OTAK-NES preserves all core decentralization principles.

Specifically:

. Every transaction remains publicly verifiable
. Every cryptographic proof can be independently validated
. No trusted coordinator exists
. No centralized key registry is required
. Every validator reaches identical verification results using only publicly available blockchain data.

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:

. Long-term authorization keys repeatedly sign transactions throughout the lifetime of an account.

. Every signature contributes additional publicly available cryptographic material associated with the same long-term authorization key

In OTAK-NES:

. Long-term authorization keys are reserved exclusively for authorization management
. Daily transactions are performed exclusively by one-time Child Keys
. Every Child Key authorizes only a single transaction before becoming permanently consumed

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:

. publicly verifiable
. cryptographically provable
. permanently auditable,
. independently validated by every node

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:

. a new digital signature algorithm
. modifications to the consensus mechanism
. changes to block production
. changes to transaction ordering
. trusted third parties
. or centralised coordination

Instead, it builds on existing cryptographic capabilities already widely used in modern blockchain ecosystems, including:

. Hierarchical Deterministic (HD) key derivation (BIP32/BIP44, or network‑specific standards such as TRC‑102)
. Merkle Trees
. standard digital signatures
. and existing account‑permission models.

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:

. storing the account's Merkle Root
. recording Bootstrap completion
. maintaining the account's Child Key state
. and tracking the last authorised Child Key index.

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:

. deriving Child Keys
. constructing Merkle Proofs
. creating OTAK‑NES transactions
. and performing Bootstrap initialisation

At this stage, the blockchain can support both authorisation models:

. traditional Access‑Key signatures
. and OTAK‑NES Child‑Key signatures.

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:

. the Child Key signature
. the Merkle Proof
. Child Key membership
. Child Key consumption status
. and sequential Child Key usage.

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:

1. Child Key Support

   The designated domain supports authorisation based on OTAK‑NES Child Keys.

2. 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.

3. 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_REQUIRED error.

   Consequently, after a domain is fully migrated, Access Keys are no longer used for operational transactions in that domain.

4. 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:

   . Domain A → OTAK‑NES‑only
   . Domain B → Dual Validation

   This process continues for subsequent domains.

5. 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:

. be signed by a valid Child Key
. include a valid Merkle Proof
. reference the next valid unconsumed Child Key according to the account state
. and satisfy all network authorisation validation rules.

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:

. Owner Key
. Active Key

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:

. No disruptive network‑wide migration.
. Backward compatibility throughout the transition.
. Phased adoption by wallets, exchanges, validators, and infrastructure providers, allowing safe migration.
. Minimal operational risk.
. Progressive activation as the ecosystem matures.
. No dependency on immediate protocol‑wide adoption.

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.

---

---

Security Benefits Before and After the First Operational Transaction

Before an account performs its first operational transaction, no operational transaction signatures have yet been recorded on the blockchain for that account.

At this stage, the amount of publicly available cryptographic material associated with the account's transaction authorization is minimal. Consequently, the account has a naturally smaller exposure to any present or future attack techniques that rely on analysing large collections of transaction signatures.

This property is not unique to OTAK-NES; it is a general characteristic of newly created blockchain accounts before operational signing begins.

Long-Term Exposure in Conventional Architectures

In conventional blockchain architectures, the same long-term authorization key typically signs every operational transaction throughout the lifetime of the account.

As the account continues to operate, an increasingly large collection of signatures generated by the same authorization key becomes permanently available on-chain.

Although modern digital signature algorithms are designed to remain secure under their intended assumptions, the continuous accumulation of signatures may increase the amount of information available for future analysis if new implementation weaknesses, side-channel techniques, cryptanalytic advances, operational failures, or future computational capabilities emerge.

For this reason, minimizing the long-term exposure of authorization-key signatures represents an independent architectural security objective.

OTAK-NES Approach

OTAK-NES addresses this objective by preventing Access Keys from becoming operational signing identities.

Following successful Bootstrap completion:

. Access Keys no longer directly sign operational blockchain transactions.
. Every transaction is authorized by an independent Child Key.
. Each Child Key possesses its own public/private key pair.
. Each Child Key is valid for exactly one successful transaction.
. After confirmation, the Child Key becomes permanently consumed and can never authorize another transaction.

As a result, the blockchain never accumulates a long-term signature history generated by the same Access Key.

Instead, every recorded signature belongs to an independent one-time Child Key whose operational lifetime ends immediately after successful use.

Containment of Security Incidents

If, at any point in the future, a particular Child Key were compromised for any reason—including implementation vulnerabilities, nonce failures, side-channel attacks, fault injection, operational mistakes, future cryptanalytic advances, quantum computing, or currently unknown attack techniques—the impact remains confined to that single Child Key.

Because that Child Key has already been permanently consumed:

. it cannot authorize another transaction
. it cannot be reused
. it does not expose future operational signing capability
. and compromising it does not grant operational control over Access Keys or other Child Keys.

Accordingly, OTAK-NES does not rely solely on the strength of the underlying digital signature algorithm. Instead, it reduces long-term exposure by redesigning the lifecycle of transaction authorization and by compartmentalizing signing authority across independent one-time Child Keys.

---

---

Motivation and Security Architecture

Long-Term Signature Exposure

In current blockchain architectures, long-term authorization keys typically sign every operational transaction throughout the lifetime of an account. As a result, an ever-growing collection of signatures produced by the same authorization key becomes permanently available on-chain.

Modern digital signature algorithms are designed to provide strong cryptographic security under their current security assumptions. However, no cryptographic algorithm should be assumed to remain immune forever to future advances in cryptanalysis, implementation research, hardware attacks, or computational capabilities.

Furthermore, practical security incidents have repeatedly demonstrated that vulnerabilities may arise not only from weaknesses in mathematical design, but also from implementation flaws, nonce generation failures, side-channel leakage, fault injection, operational mistakes, protocol interactions, or future cryptographic discoveries.

As the number of publicly available signatures generated by the same long-term authorization key continues to increase throughout the lifetime of an account, the amount of cryptographic material available for present and future analysis also increases.

For this reason, minimizing unnecessary long-term exposure of authorization keys constitutes an independent architectural security objective, regardless of the particular digital signature algorithm being used.

OTAK-NES Security Model

OTAK-NES introduces a key lifecycle architecture that separates long-term authorization from routine transaction signing.

Instead of allowing Access Keys to repeatedly authorize blockchain transactions, OTAK-NES delegates operational signing to independent one-time Child Keys.

Under this architecture:

. Access Keys never directly sign routine blockchain transactions.
. Access Keys serve only as the root of trust for deterministic Child Key derivation.
. Every transaction is authorized by a unique Child Key.
. Each Child Key possesses its own independent public/private key pair.
. Every Child Key is valid for exactly one successful transaction.
. After confirmation, the Child Key is permanently marked as consumed.
. The transaction signature remains permanently recorded on-chain according to standard blockchain rules, while the signing Child Key can never be reused.

As a result, signing authority is distributed across many independent one-time keys rather than being concentrated in a single long-term signing key.

Network Architecture

During account initialization, the wallet deterministically derives Child Keys using the TRC-102 hierarchical deterministic derivation standard.

The wallet then:

. Constructs a Merkle Tree containing all authorized Child Keys.
. Computes the corresponding Merkle Root.
. Registers the Merkle Root through the Bootstrap process.
. After Bootstrap completes successfully, the network records the account's Merkle Root, marks bootstrap_completed as true, and from that point onward accepts operational transactions only when they are authorized by valid Child Keys in accordance with the OTAK-NES validation rules.

For every transaction:
. The wallet selects the next unused Child Key.
. Generates the corresponding Merkle Proof.
. Signs the transaction using that Child Key.

Network nodes accept the transaction only if:

. the transaction signature is valid
. the Child Key has not previously been consumed;
. the supplied Merkle Proof is valid
. and the Child Key belongs to the Merkle Root currently stored in the account state.

After successful confirmation:

. the Child Key is permanently marked as consumed
. the transaction and its signature are recorded according to normal blockchain protocols; and
. the Child Key can never authorize another transaction.

Security Properties

OTAK-NES provides several architectural security advantages.

First, long-term Access Keys never produce operational blockchain signatures. Consequently, no long-term signature history of authorization keys accumulates on-chain.

Second, every transaction is cryptographically isolated because each transaction uses an independent one-time Child Key.

Third, if any individual Child Key were ever compromised—for any reason, including implementation vulnerabilities, nonce failures, side-channel attacks, fault injection, operational errors, future cryptanalytic advances, quantum computing, or even currently unknown attack techniques—the impact would remain confined to that single Child Key.

Since the Child Key becomes permanently invalid immediately after successful use, compromising that key does not grant operational control over the account's Access Keys, other Child Keys, or future transactions.

This compartmentalization significantly limits the scope of any individual security incident and substantially reduces long-term exposure of signing authority.

Relationship with Digital Signature Algorithms

OTAK-NES is not a digital signature algorithm.

It is a key lifecycle architecture that operates independently of the underlying signature scheme.

Digital signature algorithms answer the question:

How should a signature be generated and verified securely?

OTAK-NES answers a different question:

How should signing authority be distributed, delegated, exposed, and retired throughout the lifetime of an account?

Consequently, OTAK-NES complements rather than replaces any digital signature algorithm.

It remains compatible with:

. current ECDSA-based systems
. future post-quantum signature schemes
. and any future digital signature algorithm capable of authenticating Child Keys.

Because these technologies operate at different layers of the security architecture, improvements in one layer do not eliminate the value of improvements in the other.

Design Objectives

OTAK-NES was designed to achieve the following objectives:

. eliminate routine exposure of long-term authorization keys
. preserve blockchain transparency and auditability
. maintain compatibility with existing blockchain infrastructure
. avoid modifications to the underlying signature algorithm
. support gradual deployment through phased network upgrades; and
. provide an architecture whose security benefits remain applicable regardless of future developments in digital signature algorithms.

Rather than relying solely on increasingly stronger cryptographic primitives, OTAK-NES reduces long-term exposure by fundamentally redesigning the lifecycle of transaction authorization.

---

---

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:

. Owner Key: the key with the highest level of authority.
. Active Key: an operational authorization 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?

. Active Keys are independent: Each Active Key has a private key distinct from the Owner Key and other Active Keys. Deactivating one Active Key does not affect the Owner Key or other Active Keys.
. Owner Key security is preserved: The Owner Key is never used to sign blockchain transactions, so no operational signature from it is ever recorded on-chain.
. Other Active Keys and the Owner Key remain fully independent: The account can continue using other Active Keys independently if required.
. Compatibility with existing permission models: This method is fully compatible with permission structures such as TIP-16 and TIP-105 in TRON and requires no redesign of the permission model.

Complete process:

1. The user creates an account consisting of an Owner Key and an Active Key with independent private keys.
2. Using the Active Key, the user signs the Bootstrap transaction and registers the Merkle Root corresponding to the Owner Key.
3. After successful confirmation, the network stores the Merkle Root in Bootstrap and, according to OTAK-NES architectural requirements, automatically deactivates the Active Key that registered the Owner Key's Merkle Root.
4. After this Active Key is deactivated, it can no longer sign any transaction.
5. All subsequent transactions are authorized exclusively by Child Keys derived from the Owner Key.
6. New Active Keys may be added to the account using Child Keys derived from the Owner Key, each with its own separate Merkle Tree registered in Bootstrap.

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:

. Account address
. Owner Key Merkle Root
. OTAK-NES security parameters
. Initial ownership proof data

Step 2: Bootstrap Validation

Network nodes verify:

. Initial ownership proof
. Submitted security parameters
. Merkle Root validity
. Protocol compliance

Step 3: Bootstrap Result Recording

After successful consensus:

. The Owner Key's Merkle Root is stored.
. BootstrapCompleted = true is set.
. The Active Key used for Bootstrap is automatically deactivated by the network according to the OTAK-NES architecture after successful completion.

Transaction Validation

For every operational transaction:

Wallet:

. Selects the next unused Child Key.
. Generates the corresponding Merkle Proof.
. Signs the transaction.

Network nodes verify:

. The Child Key signature is valid.
. The Merkle Proof is valid.
. The Child Key belongs to the registered Merkle Root.
. The Child Key index matches last_used_child_index + 1.

After successful confirmation:

. The transaction is executed.
. last_used_child_index is updated.
. The signature is permanently recorded according to normal blockchain rules.
. That Child Key can never authorize another transaction again.

Account Recovery

In OTAK-NES, Access Keys and Child Keys are deterministically derived from the user's Seed.

The network stores neither:

. Private keys
. Seed phrases
. Derivation secrets

During recovery, the wallet:

. Regenerates the Access Keys.
. Regenerates the Child Key hierarchy.
. Rebuilds the Merkle Tree.
. Recomputes the Merkle Root.
. Verifies that it matches the value stored on-chain.

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:

. Add a BootstrapCompleted field.
. Store a Merkle Root for every Access Key — each Access Key has its own independent Merkle Tree.
. Add Merkle Proof validation.
. Maintain last_used_child_index for sequential Child Key validation.
. Automatically deactivate the Bootstrap Active Key after successful Merkle Root registration.
. Reject operational transactions: after full network migration to OTAK-NES (not phased migration), and after Bootstrap completion, only Child Keys are authorized to submit transactions. Therefore, nodes must reject any transaction signed directly by Access Keys and return a CHILD_KEY_REQUIRED error to the wallet.

Security Outcome

After successful Bootstrap completion, all operational signatures published on-chain belong exclusively to Child Keys.

Consequently:

. Access Keys never appear as operational signing identities.
. No long-term signature history from Access Keys accumulates on-chain.
. Every transaction uses an independent cryptographic identity.
. Every Child Key becomes permanently unusable after successful execution.
. Compromising one Child Key does not compromise Access Keys or other Child Keys.
. The impact of any security incident remains limited to a single transaction.
. The account establishes its complete OTAK-NES security model before engaging in normal economic activity.

---

---

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:

. Only transactions authorised by valid, unused Child Keys are accepted.
. Each Child Key must provide a valid signature, a valid Merkle Proof, and proof of membership in the account's registered Merkle Root when submitting a transaction.
. After successful execution, the Child Key is permanently marked as consumed and cannot submit another transaction.

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:

. Has an independent public/private key pair.
. Is cryptographically independent of other Child Keys.
. Is valid for only one transaction.
. Cannot be used to recover the Access Key due to the one-way nature of the derivation process.
. After successful transaction confirmation, its identifier is recorded as Consumed in the network state.
. Only after this status is recorded are the transaction and its signature published according to normal blockchain rules.

3. Merkle Tree Structure

In the OTAK-NES architecture, Child Keys are organised into a Merkle Tree.

The wallet, locally and offline:

. Generates the Child Keys.
. Builds the Merkle Tree.
. Computes the Merkle Root.

During the Bootstrap process:

. Only the Merkle Root is stored in the account state.
. The Child Keys themselves are not stored on the network.
. The network does not retain any version of Child Key public or private keys.

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:

. merkle_root
. bootstrap_completed
. last_used_child_index
. and other information required based on each network's protocols.

5. Transaction Submission Process

For each transaction:

. The wallet selects the first unused Child Key.
. Signs the transaction with it.
. Generates the corresponding Merkle Proof.
. Submits the transaction, signature, and Merkle Proof to the network.

6. On-Network Validation

Upon receiving a transaction, network nodes:

. Verify the digital signature.
. Validate the Merkle Proof.
. Check its correspondence with the Merkle Root stored in the account.
. Confirm that Bootstrap has been completed.
. Verify that the Child Key has not been previously consumed.
. Verify that the Child Key index exactly matches last_used_child_index + 1.

After successful confirmation:

. The transaction is executed.
. last_used_child_index` is updated.
. The transaction signature is permanently recorded according to network protocols.
. That Child Key can never be used again.

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:

. The transaction is executed.
. The Child Key is considered consumed.
. The possibility of reusing it is permanently eliminated.

If an attempt is made to reuse a consumed Child Key:

. The transaction is rejected.
. A CHILD_KEY_CONSUMED error is returned.

8. Child Key Management in the Wallet

All Child Keys are generated completely deterministically.

Consequently:

. All Child Keys can be recovered from a single Seed.
. The wallet can locally generate millions of Child Keys.
. There is no need to register keys separately on the network.
. No additional backup is required.
. Full recovery of the account structure is possible using only the master Seed.

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_index value.

This model:

. Prevents account state growth.
. Keeps the state size of each account constant.
. Does not require pruning or archiving of consumed Child Keys.
. Naturally prevents replay attacks.

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:

. Generates a new set of Child Keys.
. Builds a new Merkle Tree.
. Computes the new Merkle Root.
. Submits a Rotation transaction using one of the authorised Child Keys located in the Rotation Window.

After confirmation:

. The new Merkle Root replaces the previous one.
. last_used_child_index is reset to zero.
. The new Merkle Tree becomes active.
. The previous Merkle Tree is permanently deactivated.
. All unused Child Keys in the previous Merkle Tree become permanently invalid.

11. Account Recovery

All Access Keys, Child Keys, and Merkle Trees are deterministically derived from the user's Seed.

The network never stores:

. The Seed
. Private keys
. Derivation secrets

During recovery, the wallet:

. Regenerates the key structure.
. Rebuilds the active Merkle Tree.
. Synchronises it with the merkle_root and last_used_child_index stored 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:

1. 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.

2. 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:

. The use of one-time Child Keys derived from Access Keys, so that each operational signature is produced independently of the account's long-term authorization keys.
. Ensuring that exposure of a Child Key, by itself, does not expose the Access Key or other Child Keys.
. Preventing replay attacks and Child Key reuse through mandatory sequential indexing of Child Keys.
. Reducing the risk associated with operational-key-level Nonce reuse by using each Child Key exactly once.
. Limiting the impact of any potential exposure to the level of a specific key and transaction, so that exposure of an operational key, by itself, does not imply exposure of the private key controlling all assets of the account.

Security Properties

The OTAK-NES architecture provides several important security advantages:

. Access Keys never sign operational transactions.
. No long-term history of Access Key signatures is created on-chain.
. Each transaction is signed by an independent cryptographic identity.
. Each Child Key can be used only once.
. If a Child Key is compromised, the impact of the attack is limited to that single transaction.
. This incident does not affect Access Keys, other Child Keys, or future transactions.
. The state size of each account remains constant regardless of the number of transactions.
. The account can continue operating indefinitely through successive rotations.

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:

. Merkle Root
. Child Key hierarchy
. last_used_child_index
. Child Key lifecycle

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:

1. A valid Child Key derived from an already-authorized Access Key authorizes the creation of the new Active Key.
2. During this operation, the wallet generates a dedicated Merkle Tree for the new Active Key.
3. The corresponding Merkle Root is registered in the account state.
4. From that point forward, the new Active Key authorizes transactions exclusively through Child Keys derived from its own Merkle Tree.

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:

. a transaction signature,
. a Child Key, and
. the corresponding Merkle Proof.

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:

1. Each signer derives an unused Child Key from its own Access Key.
2. Each signer signs the transaction using that Child Key.
3. Each signer includes the corresponding Merkle Proof.
4. Network nodes validate every signature against the Merkle Root associated with the corresponding Access Key.
5. Once the required signature threshold defined by the Permission is satisfied, the transaction is executed.
6. Every participating Child Key is permanently marked as consumed.

Security Outcome

Using an independent Merkle Tree for every Access Key preserves all core OTAK-NES security guarantees in multisignature accounts:

. Access Keys never directly sign operational transactions.
. Each Access Key maintains an isolated Child Key hierarchy.
. Compromise of one authorization domain does not affect others.
. Existing Permission models remain fully supported.
. Mixed signature algorithms can coexist within the same multisignature account.
. Multisignature accounts remain scalable, deterministic, and fully compatible with future cryptographic evolution.

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:

. Protection against known and emerging threats: The architecture helps protect against known quantum attacks (such as Shor's algorithm), while also reducing exposure to future cryptanalytic advances, implementation vulnerabilities, and side-channel attacks — without requiring any change to the underlying signature algorithm.
. Prevention of replay attacks: Because each Child Key is bound to a unique index and consumed immediately after use, replay attacks become impossible.
. Elimination of nonce reuse vulnerabilities: Each Child Key is used exactly once, eliminating the risk of nonce reuse and private-key recovery through signature analysis.
. Compartmentalization of security incidents: If any individual Child Key is compromised, the impact is confined to that single transaction. The attack does not propagate to Access Keys, other Child Keys, or future transactions.
. Defense against implementation vulnerabilities: Even if a vulnerability exists in the signature algorithm implementation, the exposure is limited to one-time Child Keys rather than long-term authorization keys.
. Protection against side-channel and fault attacks: These attacks typically target the signing process of a specific key. With one-time Child Keys, any successful attack is confined to a disposable key that becomes immediately invalid after use.

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:

. Post-quantum signature algorithms answer: How should a signature remain secure against quantum attacks?
. OTAK-NES answers: How should signing authority be distributed, delegated, limited, and retired throughout the lifetime of an account to minimize long-term exposure?

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:

. Eliminates long-term exposure of Access Key signatures on the blockchain.
. Protects against quantum threats without requiring changes to the signature algorithm.
. Prevents replay attacks through mandatory sequential key consumption.
. Eliminates nonce reuse vulnerabilities by using each Child Key exactly once.
. Limits the impact of any security incident to a single transaction.
. Provides a foundation for defense-in-depth that remains valuable regardless of future cryptographic developments.

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

OTAK-NES 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 any specific future attack or relying on the permanent security of any particular cryptographic primitive, OTAK-NES seeks to minimize public exposure and repeated use of long-term authorization keys, and also 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.

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 this model from the entire account to a specific transaction and the asset associated with that transaction, not all assets of an account. This is enabled through one-time Child Keys derived from Access Keys, based on the OTAK-NES architecture:

. Each operational signature is performed with an independent key.
. The exposure of a single Child Key does not, by itself, provide a direct path to exposing the Access Key or other Child Keys.
. The impact of any potential exposure is, at the architectural level, confined to a single operational key and a specific transaction.
. The exposure of one operational key does not, by itself, compromise the private key with access to the entire account's assets.

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 of a potential signature exposure event from a long-term authorization key and the account under its control to the specific operational 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, or from other factors.

Examples include:

. Incorrect randomness generation
. Nonce generation errors
. Software implementation bugs
. Protocol integration errors
. and Wallet implementation errors

No signature algorithm can claim 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 its assets to the specific transaction and its associated transferred asset.

Side-Channel and Physical Attacks

Practical attacks such as:

. Power analysis
. Timing analysis
. Electromagnetic leakage
. Cache attacks
. Fault injection
. and Hardware implementation attacks

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 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:

. Existing classical signature schemes
. Post-quantum signature schemes
. and Future signature algorithms.

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: 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.

Instead, it provides an independent architectural security layer that reduces risk by minimizing exposure of Access Key signatures and by using Child Keys derived from the account's master keys.

Accordingly, OTAK-NES is designed to be usable alongside both classical and post-quantum signature algorithms.

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 and separation of authorization authority.

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:

. Cryptanalysis
. Hardware capabilities
. Implementation research
. Protocol analysis
. or Techniques not currently foreseen

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:

. The user's master Seed remains confidential
. Hierarchical key derivation operates correctly
. The digital signature algorithm in use provides its intended level of security
. and Merkle Tree construction and verification are correctly implemented.

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.

---

---

Advantages of OTAK-NES in:

. Simplified Migration to New Signature Algorithms
. Simultaneous Support for Multiple Signature Algorithms
. Layer-2 Compatibility

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:

. The previous Access Keys are replaced with a new set of Access Keys.
. A new Merkle Root corresponding to the updated security structure is stored in the account state.
. All future transactions are validated using the new Access Keys and their corresponding Child Keys.

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:

. Previously published signatures remain permanently recorded on the blockchain.
. Replacing Access Keys does not erase the account's historical cryptographic records.
. This approach reduces future signature exposure but does not make the account equivalent to a newly created account with no prior on-chain signature history.

Summary

All three approaches are fully compatible with the OTAK-NES architecture, although they provide different levels of reduction in long-term signature exposure.

. Option 1 provides the greatest reduction because assets are moved to an account with no previous signature history.
. Option 2 also provides substantial reduction while preserving the existing Seed.
. Option 3 offers the greatest operational compatibility by preserving the existing account identity. However, because historical signatures remain permanently recorded on-chain, its reduction in long-term signature exposure is inherently lower than that achieved by the first two approaches.

---

---

[xxo1shine]

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

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

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

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

[Federico2014]

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

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

One engineering difference stands out:

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

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

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

[GordonLtron]

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

[alichatme]

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

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

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

· merkle_root
· bootstrap_completed
· last_used_child_index

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

For each new transaction, nodes verify:

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

After successful transaction confirmation, last_used_child_index is updated accordingly.

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

As a result:

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

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

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

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

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

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

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

The Commit-Reveal proposal by GordonLtron is also very interesting and valuable. 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]

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:

• Child-key lifecycle tracking via "last_used_child_index"
• State growth and storage model
• Replay protection mechanism
• Account lifecycle and recovery model

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]

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]

@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:

1. The relationship between OTAK-PQ and Post-Quantum signature algorithms

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.

2. Mempool exposure

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.

3. Stateful operation and Merkle Tree exhaustion

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. )

4. Existing accounts

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.

5. Bootstrap and account identity

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]

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]

@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]

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]

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]

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:

• Primary focus shifts from "quantum resistance" to "non-exposure of master key signatures."
• The post-quantum aspect remains as a valuable consequence, but not as the primary goal.
• Fundamental revision of the Bootstrap process to completely eliminate any Access Key signature.
• Full proposal text update to reflect this new approach.
• Further simplification of the process wherever possible.

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:

1. 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 m signers can have up to m independent 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).

2. 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]

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_index introduces 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.keys and 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.