ATHENA: Admission and Transaction Handling for Efficient Network Architecture

[alichatme]

ATHENA dynamically creates balanced parallel validator groups and intelligently distributes incoming transactions among them. By enabling concurrent validation of independent transactions, ATHENA improves the network's effective transaction processing capacity while preserving the existing consensus mechanism and the unified global ledger.

Thank you for your time and consideration.
A complete TIP draft is available for review and discussion.
Pull Request: #906

[alichatme]

---

tip: XXXX
title: "ATHENA: Admission and Transaction Handling for Efficient Network Architecture"
author: Ali (@alichatme)
status: Draft
type: Standards Track
category: Core
created: 2026-07-11
discussions-to: #905

ATHENA

Admission and Transaction Handling for Efficient Network Architecture

Smarter Admission. Fairer Scheduling. Greater Scalability.

---

---

Introduction

Blockchain networks have made significant progress in security, decentralization, reliability, and practical applications in recent years. Nevertheless, with the increasing number of users and the global expansion of this technology, throughput and scalability remain among the most important challenges facing these networks.

In most blockchain networks, processing capacity is not solely dependent on hardware resources; rather, the distribution of load, transaction scheduling, utilization of validator capacity, and management of transaction inflow also play a determining role in the network's final performance.

In recent years, various approaches have been introduced to increase processing capacity, including block size expansion, consensus algorithm optimization, Layer 2 solutions, Rollups, Sidechains, and Sharding. Each of these approaches, while potentially effective in specific circumstances, typically require changes to one or more fundamental components of the network, including the consensus algorithm, ledger structure, state management model, or transaction execution architecture.

ATHENA has been designed with a different approach

Unlike many parallel validation architectures that primarily focus on increasing transaction execution speed through modifications to the execution engine, consensus algorithm, or ledger structure, ATHENA follows a fundamentally different approach.

In the ATHENA architecture, the focal point is the unified management of the transaction lifecycle—a cycle that begins from the moment an Admission Request is received from the wallet and continues until the transaction's final status is determined according to the Host Protocol and recorded in the global ledger.

By receiving the required information from both the wallet and the network, ATHENA makes all necessary decisions for guiding the transaction before it enters the execution phase. These decisions include analyzing transaction data, dynamically selecting initial validator nodes, forming parallel validation pipelines, determining the execution domain, selecting the most suitable execution engine based on real-time workload monitoring, and issuing the Execution Permit as the authoritative reference for the transaction's validation path.

In this architecture, the Execution Permit is not merely an admission authorization—it is the authoritative validation contract governing the transaction throughout its entire lifecycle. All network components, from initial validation to transaction execution, are required to operate according to the information recorded in this permit, and no independent decision-making regarding changes to the validation path occurs along the way.

One of ATHENA's fundamental innovations is Execution Permit-based conflict management. Unlike conventional approaches that redesign or reschedule the validation path after a conflict occurs, ATHENA manages the continuation of transaction validation by re-verifying the Execution Permit and applying pre-defined policies established in the Host Protocol. In this way, exceptions and conflicts can be managed from the exact point they occurred, without rebuilding the validation cycle.

Furthermore, ATHENA analyzes all conflicts and exceptional conditions, sending analytical reports to the Host Protocol. This feedback is then used to improve admission policies, scheduling, validation path selection, and Execution Permit issuance for subsequent transactions. As a result, the network architecture continuously learns from past transaction execution experiences to optimize future decisions.

Without making any changes to the consensus algorithm, account model, ledger structure, or network validation rules, ATHENA provides the necessary foundation for parallel validation and increased operational capacity of the TRON network through intelligent lifecycle management, optimal utilization of existing resources, targeted transaction routing, and proactive conflict management.

---

---

Unified Transaction Lifecycle Management for Parallel Validation in the TRON Network

The continuous growth of the TRON ecosystem has transformed the network into one of the world's largest public blockchain infrastructures in terms of transaction volume, active accounts, smart contract activity, and on-chain applications. While the current architecture has demonstrated remarkable stability and performance, the long-term evolution of the network—including support for parallel transactions—requires an architecture with a novel mechanism in the admission system, validation, and other network components, without altering the network's validation and consensus protocols. Such an architecture must be capable of scaling beyond the limitations of predominantly sequential validation to keep the network scalable and dynamic for the future.

Parallel validation has become one of the most important research directions in blockchain scalability. Existing approaches—including optimistic execution, dependency analysis, speculative execution, locking mechanisms, access-list scheduling, and object-oriented execution—attempt to improve throughput by resolving conflicts during execution.

However, these approaches were designed around the assumptions of their own blockchain architectures. Applying them directly to TRON would require substantial modifications to the transaction lifecycle, execution engine, or protocol behavior.

ATHENA follows a fundamentally different philosophy.

Rather than redesigning Java-Tron or replacing the execution engine, ATHENA introduces a native admission and validation architecture specifically designed for TRON.

ATHENA performs all critical execution decisions before a transaction enters the execution phase. This approach transforms conflict management from a reactive process into a proactive one.

ATHENA's Role in the New Architecture

In this unified architecture, ATHENA is no longer merely an admission layer—it becomes the complete decision-making center for the entire transaction lifecycle.

ATHENA's responsibilities include:

• Transaction Admission: Receiving the Admission Request and required information from the wallet according to Host Protocol rules.
• Information Analysis: Analyzing the received information, Access List, and other required Metadata for decision-making.
• Applying Network Policies: Applying admission policies and Sender Consistency.
• Dynamic Validator Selection: Dynamically selecting validator nodes for each transaction based on real-time network policies and TRON protocols.
• Creating Parallel Validation Pipelines: Assigning each transaction to a dedicated parallel validation pipeline resulting from dynamic node selection.
• Execution Domain Classification: Determining the execution domain or category of the transaction (TRX, USDT, NFT, General, etc.).
• Workload Monitoring and Engine Selection: Monitoring the load of execution engines in each domain operating in parallel and selecting the execution engine with the lowest processing load at the time of permit issuance.
• Determining Conflict Management Policy: Selecting the appropriate conflict management strategy (Serialization, Optimistic, Locking, or Hybrid) based on transaction type, domain, and network status.
• Issuing Execution Permit: Generating and issuing the Execution Permit containing all the information required for transaction validation, from the selected nodes for initial validation to transaction recording in the ledger, as well as the selected conflict management policy.
• Canonical Copy Storage: Upon permit issuance, storing the Execution Permit in the Canonical Copy for subsequent verification.

With the arrival of a transaction submission request from the wallet to ATHENA, ATHENA's responsibility begins and continues until the transaction's final status is determined according to the Host Protocol and the transaction is finally recorded in the network's global ledger.

Although ATHENA does not perform the transaction execution or consensus operations itself, it is responsible for all decisions related to a transaction's validation path—such as dynamic node selection, domain selection, selection of the parallel execution engine in each domain based on load monitoring, and management of exceptions and conflicts if detected—for the entire transaction lifecycle.

ATHENA's Fundamental Innovation: Execution Permit-Based Conflict Management

Unlike conventional architectures that handle conflict management after a conflict occurs by creating new schedules, building dependency graphs, re-execution, or locking mechanisms, ATHENA introduces a completely different approach.

In ATHENA, conflict management begins before the transaction enters the execution phase.

All decisions related to the validation path, execution domain, execution engine, and conflict management policy are made and recorded at the time the Execution Permit is issued.

For this reason, when a conflict occurs, the network does not need to redesign the validation path or make a new decision. ATHENA manages the continuation of transaction execution simply by re-verifying the Execution Permit and applying pre-defined policies established by the network protocols.

This approach transforms the traditional concept of "post-occurrence conflict management" into "pre-defined permit-based conflict management" —an approach that reduces runtime overhead, prevents re-execution of initial validation, and enables higher scalability without changing the account model, execution engine, or consensus algorithm.

Execution Permit: The Authoritative Validation Contract

ATHENA's core innovation lies in the fact that all stages of a transaction's validation—from permit issuance for the wallet to ledger recording—are determined by ATHENA and recorded in the Execution Permit. This permit acts as the Authoritative Validation Contract for the entire transaction lifecycle.

The Execution Permit includes the following information:

• Permit ID and validity period
• Validator nodes selected for initial validation
• Determined execution domain
• Selected execution engine with the lowest load from each domain
• Other protocol parameters required for the transaction to progress from admission to final recording

After the Execution Permit is issued:

1. Based on the permit, the wallet sends the signed transaction to the designated nodes.

2. After performing initial validation, the nodes send the transaction to the designated domain and execution engine without any new decision-making and solely based on the information in the Execution Permit.

3. The execution engine processes the transaction according to the designated path.

No secondary scheduling decisions, no new execution queues, and no additional routing layers are created at runtime.

All validation and transaction routing stages from the moment the Execution Permit is issued until its status is finalized are pre-determined in the permit, and all network components are required to act accordingly.

All validation stages must be performed in accordance with the Execution Permit issued by ATHENA.

Neither ATHENA nor the network protocols make new decisions regarding the initial path or continuation of transaction validation after the Execution Permit is issued. All stages are executed based on the previously issued Execution Permit. Only in the event of a conflict or exceptional condition does ATHENA manage the continuation of transaction execution according to Host Protocol policies.

In such cases, ATHENA is responsible for managing exceptions, conflicts, or other potential issues that may occur during the transaction execution path.

In these cases, ATHENA does not make new decisions regarding the initial path or continuation of transaction validation; rather, it only manages the continuation of transaction execution in accordance with Host Protocol policies when conflicts or exceptional conditions arise.

ATHENA's main responsibilities in such cases include:

• Managing conflicts detected by execution engines according to Host Protocol policies.
• Re-verifying the Execution Permit in case of interference detection, as a first step and according to Host Protocol rules.
• Determining the most suitable path for continuing transaction execution after a conflict occurs.
• Redirecting the transaction to the same engine, another engine from the same domain, or the General Engine according to Host Protocol policies.
• Executing Retry or Re-execution in cases where Host Protocol deems it mandatory.
• In exceptional circumstances, returning the transaction for issuance of a new Execution Permit, only if such a process is defined by the Host Protocol.
• Preparing analytical reports of occurred conflicts and sending them to the Host Protocol as feedback, with the aim of preventing repeated conflicts to improve or change admission policies, scheduling, and Execution Permit issuance for subsequent network transactions.

Conflict Management in ATHENA Architecture

In this unified architecture, conflict management is performed proactively, relying on information received from the wallet and the network protocol at the time of Execution Permit issuance.

When an execution engine detects a conflict, execution error, or any other exceptional condition according to Host Protocol during transaction validation:

1. The execution engine identifies the conflict and reports it to ATHENA.

2. ATHENA first verifies the Execution Permit, and then based on Host Protocol policies, manages the conflict handling and continuation of transaction validation:

• It first verifies and validates the integrity and completed validation stages based on the Execution Permit to ensure the validation path has still followed the initial decision.
• After verification, ATHENA acts according to Host Protocol policies (e.g., redirecting to Fallback Engine, Retry, or Re-execution).
• If continuing transaction validation is impossible even with the above measures, ATHENA, due to lack of a solution, sends a report to the network, cancels the transaction according to Host Protocol rules, and sends a new permit for retransmission to the wallet.

3. ATHENA prepares an analytical report of each occurred conflict and its management approach and sends it to the Host Protocol to prevent conflict repetition by improving network policies in subsequent permit issuance for future transactions.

4. The network protocol, upon receiving these reports, uses them to improve admission policies, scheduling, and Execution Permit issuance for subsequent transactions, preventing the repetition of the same type of conflict, and accordingly updates permit issuance policies for ATHENA.

When a conflict is detected in a transaction, the transaction is never returned to ATHENA, and conflict resolution policies are pursued from the same stage.

For example, if a conflict is detected in an execution engine, the transaction is resent from the initial validation stage to the General Engine or the correct engine.

The "Plan Once, Execute Once" Principle

This architecture is based on a fundamental principle:

• Planning is done once: ATHENA makes all decisions related to the validation path, domain, engine, and conflict management policy before the transaction enters the network and records them in the Execution Permit.
• Execution follows the recorded plan: All network components (nodes, engines, and Host Protocol) follow the designated path in the Execution Permit without new decision-making.
• Exception management: In case of conflict or any exception, ATHENA manages the continuation of validation from the same stage without transaction return or retransmission, relying on re-verification of the Execution Permit and Host Protocol policies, and sends feedback to the Host Protocol.

This principle reduces unnecessary validation work, minimizes repeated admission processing, and enables conflict management during execution without rebuilding the entire transaction lifecycle.

Key Advantage: Separating Decision-Making from Execution in a Single Layer

With this unified approach, the philosophy of "separating decision-making from execution" is fully implemented in ATHENA:

ATHENA decides:

• When a transaction should enter the network.
• Which nodes should perform initial validation.
• How initial parallel validation pipelines should be created through dynamic node selection.
• Which execution domain the transaction should be sent to after initial validation.
• Which execution engine (with the lowest load) should validate the transaction.
• What approach should be taken if a conflict is detected at any stage based on Host Protocol policies.
• ATHENA's responsibilities in case of conflict or exceptions, and their resolution, follow the policies defined in the Host Protocol, which are predetermined for ATHENA.
• Implementing conflict management policies by ATHENA to guide the transaction to the correct path according to the network protocol and Host Protocol policies.
• Managing conflict at runtime without transaction return, managing the transaction from the exact stage where the conflict was identified.
• Sending analytical feedback from ATHENA to the network for continuous improvement in preventing potential conflicts by identifying and addressing them during Execution Permit issuance.
• The Execution Permit is the sole authoritative validation reference in the network, and all network components are required to act solely according to its provisions without independent decision-making.

As a result, ATHENA is a complete and unified layer that manages all decisions related to transaction validation from beginning to end and also serves as the executor for resolving exceptions and conflicts if detected.

Conclusion

The unified ATHENA architecture offers a native and dedicated approach to parallel validation in TRON, designed based on the specific characteristics of this network. By relying on the Execution Permit as the Authoritative Validation Contract, this architecture makes all critical decisions before execution, and through the complete separation of "decision-making" from "execution," it enables the network to achieve large-scale parallel validation without changing the account model, consensus algorithm, or ledger.

Conflict management in this architecture is transformed from a reactive runtime process into a proactive, planning-based process in which ATHENA, relying on information received from the wallet and the network at the time of Execution Permit issuance, and by determining the transaction path from start to ledger recording, prevents conflicts. Additionally, in case of exceptions, it manages these cases according to Host Protocol policies and sends feedback to the network to modify permit issuance policies and prevent conflict repetition in subsequent permit issuances.

This architecture paves the way for TRON's evolution toward parallel validation without making fundamental changes to the existing infrastructure.

---

---

Economic Impact and Incentive Model

1. The Challenge of Traditional Architectures

In many blockchain networks, increasing the number of nodes beyond a certain threshold does not necessarily lead to an increase in the network's processing capacity. In these architectures, although more validators join the network, the transaction processing path remains limited by the fixed capacity of the network's validation and execution system.

Under such conditions:

• Revenue from fees is distributed among a larger number of nodes.
• The network's operational capacity remains approximately constant.
• The economic return of each node gradually decreases.
• Increased demand typically leads to longer queues and higher fees, rather than an increase in actual processing capacity.

For this reason, in many networks, the growth in the number of validators does not necessarily result in a proportional growth in network capacity.

2. ATHENA's Different Approach

ATHENA examines this issue from a fundamentally different perspective.

In the ATHENA architecture, increasing the number of nodes is not merely about adding more validators—it creates new capacity for expanding parallel validation and increasing the network's operational throughput.

Through unified transaction lifecycle management, ATHENA:

• Receives the required information from the wallet and the network.
• Dynamically selects the initial validator nodes, resulting in the creation of parallel validation pipelines in the network.
• Determines the appropriate execution domain.
• Selects the least-loaded execution engine among those operating in parallel within that domain.
• Issues the Execution Permit.
• Manages the validation path according to Host Protocol policies until the transaction is finally recorded in the global ledger.

Therefore, the addition of new nodes can directly increase the transaction admission and initial validation capacity. Subsequently, the Host Protocol, in response to increased load, can increase the number of execution engines in each domain.

As a result, validation capacity and execution capacity grow in a coordinated manner.

3. Positive Economic Feedback Loop

The ATHENA architecture enables the creation of a positive economic feedback loop.

This loop operates as follows:

1. New nodes join the network.
2. ATHENA organizes them into parallel validation pipelines.
3. Admission and initial validation capacity increases.
4. In response to increased load, the Host Protocol activates more execution engines across different domains.
5. More transactions enter the validation and execution cycle.
6. The number of transactions recorded in the global ledger increases.
7. Total network revenue increases.
8. Increased revenue creates greater incentive for new nodes to join.
9. The cycle repeats.

The stability of this cycle depends on the existence of real demand for incoming transactions and appropriate Host Protocol policies for developing the network's execution resources.

4. Conceptual Example

Assume a network has:

10,000 validator nodes with an approximate capacity of 1,000 transactions per second (TPS).

Now assume the number of nodes increases to 20,000.

In conventional architectures:

• The number of validators increases.
• Processing capacity remains approximately constant.
• Revenue is divided among a larger number of nodes.
• The economic return of each node decreases.

In the ATHENA architecture:

Assume the Host Protocol allows ATHENA, in the event of high incoming transaction demand, to form initial validation pipelines consisting of 200 nodes each, and distribute incoming transactions among these processing pipelines.

In this case, approximately 100 parallel validation pipelines could be formed, which could theoretically increase transaction validation capacity up to 100 times.

This example is provided solely to demonstrate the potential of the architecture and should not be interpreted as a guarantee of actual performance.

ATHENA distributes independent transactions among these parallel initial validation pipelines and, after initial validation, directs each transaction according to the Execution Permit to the relevant execution domain and the least-loaded engine within that domain.

If the network infrastructure, hardware resources, execution engines, and transaction demand all support this level of processing, the network's operational capacity could increase significantly.

5. Economic Impact

In ATHENA, revenue is not merely a function of the number of nodes—it is a function of the network's actual transaction processing capacity.

The more transactions the network can process using parallel validation and parallel execution engines:

• Total network revenue increases.
• Distributable revenue among participating validators increases.
• Economic incentive for investing in network infrastructure and joining new nodes increases.
• Gradual network expansion becomes possible without changing the base architecture.

Therefore, ATHENA transforms the increase in the number of nodes from a potential operational cost into an opportunity for operational capacity growth and economic network development.

6. Scope of This Analysis

The analysis presented in this section is conceptual and architectural in nature.

The actual performance of ATHENA will depend on multiple factors, including:

• Real transaction demand
• Host Protocol policies
• Node hardware capacity
• Execution capacity and the number of parallel engines in each domain
• Network bandwidth
• Implementation quality
• Consensus algorithm overhead
• Network economic policies
• Reward distribution mechanisms

Therefore, ATHENA does not guarantee a specific increase in TPS or validator revenue.

Rather, it provides an architectural framework that, under favorable conditions, can utilize existing network resources more effectively and facilitate the simultaneous growth of:

• Transaction admission capacity
• Parallel validation
• Parallel execution
• Economic efficiency
• Attraction of new nodes
• Development of execution engines
• Overall network operational throughput

All of this is achieved without changing the consensus algorithm, account model, or the unified global ledger.

---

---

Architectural Analysis and Enhancement of Operational Capacity

The ATHENA architecture is based on the premise that, in many blockchain networks, limitations in the admission layer, transaction admission management, initial validation, scheduling, and workload distribution create long queues, increased waiting times, and reduced operational efficiency long before the consensus algorithm reaches its actual processing capacity.

ATHENA addresses these limitations without introducing any modifications to the consensus algorithm, ledger structure, account model, or the network's native validation rules.

Upon receiving a transaction submission request from a wallet, ATHENA collects the information required by the Host Protocol from both the wallet and the network. Based on the current network load, it dynamically forms the initial validation group through dynamic validator selection, determines the appropriate execution domain, selects the least-loaded parallel execution engine within that domain, and records all information required for transaction validation—from admission to final ledger registration—within the Execution Permit.

After the permit is issued, one copy of the Execution Permit is stored in the Canonical Copy for future verification, while another copy is delivered to the wallet. The wallet then submits the signed transaction together with the Execution Permit to the validator nodes specified in the permit.

From this point onward, every network component—including validator nodes, execution engines, and other protocol components—performs validation, execution, consensus, and final ledger registration strictly according to the information contained in the Execution Permit and the rules defined by the Host Protocol, without making any independent routing or scheduling decisions.

If a conflict or any exceptional condition is detected within an execution engine, the transaction is not returned to the beginning of the validation lifecycle. Instead, ATHENA first revalidates the Execution Permit and verifies the validation path already completed, then manages conflict resolution and continuation of the validation process from the same stage according to the policies defined by the Host Protocol.

ATHENA also generates an analytical report for every detected conflict or exceptional condition, describing its cause, the applied resolution strategy, and the final outcome. These reports are delivered to the Host Protocol, enabling it to refine admission policies, scheduling policies, validator selection, execution-domain selection, execution-engine selection, and other Execution Permit issuance policies in order to reduce the likelihood of similar conflicts in future transactions.

Consequently, without modifying the network's consensus algorithm or validation rules, ATHENA increases the network's operational capacity by providing unified transaction lifecycle management, dynamic validator selection, parallel organization of the initial validation process, intelligent execution-domain selection, dynamic selection of the least-loaded execution engine within each execution domain, conflict management based on Host Protocol policies, and more efficient utilization of existing processing resources.

From an architectural perspective, whenever additional validator nodes or processing resources become available, ATHENA introduces no inherent limitation on creating additional initial validation groups or utilizing more parallel execution engines. The expansion of operational capacity is therefore achieved by scaling these resources within the policies and constraints defined by the Host Protocol.

The size of initial validation groups, the number of validator nodes required for each group, the number of execution engines within each execution domain, the evolution of execution domains, and all other operational constraints remain entirely under the control of the Host Protocol to preserve network security, decentralization, stability, and operational efficiency.

As a result, ATHENA does not attempt to increase the theoretical capacity of the consensus algorithm itself. Instead, through intelligent and unified transaction lifecycle management, more effective utilization of existing resources, balanced workload distribution across parallel initial validation groups and parallel execution engines within each execution domain, and conflict management governed by Host Protocol policies, ATHENA provides a scalable architectural framework for increasing the network's operational capacity without modifying its underlying architecture, consensus algorithm, or unified global ledger.

---

---

Comparison of ATHENA with Other Scalability Solutions

Improving scalability has long been one of the primary research objectives in blockchain technology, and numerous architectural approaches have been proposed to achieve this goal. Most existing solutions increase transaction throughput by modifying one or more fundamental components of blockchain architecture, such as the consensus algorithm, ledger organization, execution model, or transaction processing flow.

ATHENA pursues the same objective through a fundamentally different architectural philosophy.

Rather than redesigning the consensus protocol, partitioning the global ledger, modifying the account model, or replacing the native validation mechanism, ATHENA introduces an integrated transaction lifecycle management architecture that intelligently manages transactions from their admission into the network until their final commitment to the global ledger.

Within ATHENA, a transaction begins with an Admission Request submitted by the wallet according to the Host Protocol. ATHENA then collects the required contextual information from both the wallet and the network, dynamically selects the initial validator nodes, forms the initial parallel validation group, determines the appropriate execution domain, selects the least-loaded parallel execution engine within that domain, and generates an Execution Permit that defines the complete validation path of the transaction.

The Execution Permit becomes the authoritative validation contract for the entire transaction lifecycle. One copy is securely stored within the Canonical Copy for future verification, while another copy is delivered to the wallet, allowing the signed transaction to be forwarded to the designated validator nodes.

From this point forward, every component of the network—including validators, execution engines, consensus participants, and other protocol components—processes the transaction exclusively according to the information contained in the Execution Permit and the policies defined by the Host Protocol, without independently redefining the transaction's execution path.

Furthermore, ATHENA introduces a novel Execution Permit–based conflict management mechanism. Whenever execution conflicts or exceptional conditions are detected, ATHENA first re-verifies the Execution Permit and the completed validation path before managing the continuation of transaction processing according to Host Protocol policies. The transaction is therefore managed from the exact stage where the conflict is detected rather than restarting the entire validation lifecycle.

In addition, ATHENA generates analytical reports describing detected conflicts, their causes, applied resolution strategies, and final outcomes. These reports are provided to the Host Protocol as architectural feedback, enabling continuous improvement of future admission policies, scheduling decisions, validator selection strategies, execution domain assignment, execution engine selection, and Execution Permit generation.

Consequently, ATHENA improves the operational capacity of the network through intelligent lifecycle management, dynamic validator selection, parallel initial validation, intelligent execution scheduling, and proactive conflict management while remaining fully compatible with the native blockchain architecture.

Comparison with Sharding

Sharding increases network throughput by partitioning the global state and ledger into multiple independent shards. Each shard maintains its own subset of validators and network state, requiring additional coordination mechanisms for cross-shard transactions.

ATHENA follows a fundamentally different approach.

It never partitions the network state or the global ledger. All validators continue operating on the same global state and unified ledger.

Instead of dividing the blockchain itself, ATHENA dynamically organizes validator nodes into parallel initial validation groups while maintaining a unified consensus process and a single global ledger.

Comparison with Layer 2 Solutions

Layer 2 solutions typically improve scalability by moving a substantial portion of transaction execution outside the main blockchain and recording only the final settlement on Layer 1.

ATHENA adopts a different architectural model.

Transactions remain fully governed by the native protocol of the host blockchain. ATHENA intelligently manages transaction admission, initial validation, scheduling, execution domain selection, execution engine selection, and transaction lifecycle management without moving transaction ownership or validation outside the main protocol.

When supported by the Host Protocol, ATHENA may also direct transactions toward Layer 2 execution environments in addition to Layer 1 execution engines.

Therefore, ATHENA is neither a replacement for Layer 2 solutions nor an alternative to them. Instead, it functions as a complementary architectural layer capable of providing intelligent admission management and transaction scheduling alongside Layer 2 technologies.

Comparison with Block Size Scaling

Some blockchain networks increase throughput by enlarging block size, allowing more transactions to be included in each block. Although this approach may improve throughput, it generally increases hardware requirements, bandwidth consumption, block propagation time, and node synchronization overhead.

ATHENA does not modify block size.

However, it remains fully compatible with any future block size adjustments introduced by the Host Protocol and can simultaneously benefit from larger blocks while continuing to optimize transaction admission, validation, and execution scheduling.

Comparison with Consensus Algorithm Optimization

Some scalability approaches seek higher throughput by replacing or fundamentally modifying the consensus algorithm.

ATHENA intentionally avoids this approach.

Validation, voting, block production, and transaction finalization continue to operate entirely according to the native consensus mechanism of the Host Protocol.

Because ATHENA operates independently of the consensus algorithm itself, future modifications or upgrades to the consensus protocol can be adopted without requiring redesign or architectural changes within ATHENA.

ATHENA's Architectural Position

From an architectural perspective, ATHENA can be viewed as an Integrated Transaction Lifecycle Management Layer operating within Layer 1.

Unlike other scalability approaches:

• Sharding increases capacity by partitioning network state and ledger.
• Layer 2 increases capacity by moving execution outside the main chain.
• Block size scaling increases capacity by enlarging individual blocks.
• Consensus optimization increases capacity by modifying the consensus mechanism.

ATHENA increases the network's operational capacity through intelligent lifecycle management, dynamic validator selection, parallel initial validation, execution domain classification, intelligent execution engine selection, Execution Permit–based validation management, and proactive conflict resolution, while leaving all fundamental components of the blockchain architecture unchanged.

For this reason, ATHENA is designed as a complementary Layer 1 architecture that can coexist with future scalability technologies, provided they remain compatible with the policies and operational constraints defined by the Host Protocol.

---

---

ATHENA Architecture Diagram

In the ATHENA architecture, the transaction lifecycle begins before the transaction enters the network. By receiving the Admission Request, analyzing the initial transaction information, evaluating the real-time network state, and applying Host Protocol policies, ATHENA determines the complete validation and execution path of the transaction before it enters the network. The result of this process is issued as an Execution Permit, which not only authorizes the transaction to enter the network but also defines its complete execution blueprint. From this point onward, all network components are required to process the transaction without making any independent decisions, strictly following the instructions recorded in the Execution Permit and the policies defined by the Host Protocol.

The transaction lifecycle in the ATHENA architecture proceeds as follows:

1. Transaction Preparation in the Wallet

The user enters the required transaction information into the wallet and reaches the confirmation screen.

2. Admission Request Submission

Before the user is allowed to sign the transaction, the wallet sends an Admission Request containing the information required by the Host Protocol to ATHENA.

3. Analysis and Decision-Making by ATHENA

ATHENA, by analyzing the request information, the current network state, and Host Protocol policies, determines the following:

• Dynamic selection of initial validator nodes
• Formation of initial validation groups through dynamic node selection, resulting in the creation of parallel initial validation pipelines
• Determination of the execution domain
• Selection of the least-loaded execution engine from among the parallel engines within that domain
• Determination of the minimum validation difficulty level
• Registration of the Expected Behavior and Outcome
• Issuance of the Execution Permit
• Storage of the Canonical Copy of the permit

4. Receipt of Permit and Activation of Transaction Signing

After the Execution Permit is issued, it is sent to the wallet, and only upon its receipt is the user enabled to sign the transaction.

5. Transaction Entry into the Network

After the user signs the transaction, the wallet sends the signed transaction together with the Execution Permit directly to the designated initial validator nodes. The transaction never enters any public transaction queue (mempool).

6. Execution Permit Verification and Initial Validation

The initial validator nodes first verify the Execution Permit against the Canonical Copy stored in ATHENA. After the permit is confirmed, initial validation of the transaction is performed according to Host Protocol rules.

7. Routing to the Execution Domain and Engine

After successful completion of the initial validation, the transaction is routed according to the Execution Permit instructions to the designated execution domain, and from among the parallel execution engines within that domain, it is delivered precisely to the execution engine specified in the permit.

8. Transaction Execution

The designated execution engine executes the transaction according to Host Protocol rules. All state transitions, smart contract executions, and other native network logic are performed at this stage.

9. Consensus and Final Recording

After execution is complete, the transaction proceeds through the native consensus mechanism of the Host Protocol. Upon reaching Finality, the transaction is recorded in the global ledger together with the Execution Permit, enabling future verification, auditing, and complete reconstruction of the transaction lifecycle or its validation history.

10. Expected Behavior or Outcome Monitoring

In the final stage, ATHENA compares the recorded outcome with the Expected Behavior or Outcome that was defined at the time of Execution Permit issuance. If any discrepancy is observed, ATHENA prepares and sends an analytical report according to Host Protocol policies. The Host Protocol, using this feedback, can review and optimize its policies to reduce the likelihood of similar conflicts and exceptions recurring in the future.

ATHENA Architecture Diagram

                     ┌────────────────────────┐
                     │         User           │
                     └────────────┬───────────┘
                                  │
                                  │ Enter Transaction Details
                                  ▼
                     ┌────────────────────────┐
                     │        Wallet          │
                     │ Confirmation Screen    │
                     └────────────┬───────────┘
                                  │
                                  │ 1. Admission Request
                                  ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                               ATHENA                                        │
│                 Transaction Lifecycle Management Layer                       │
│                                                                             │
│ • Network Analysis                                                          │
│ • Host Protocol Policy Evaluation                                           │
│ • Dynamic Validator Selection                                               │
│ • Validation Pipeline Formation                                             │
│ • Execution Domain Selection                                                │
│ • Least-loaded Parallel Engine Selection                                    │
│ • Expected Behavior Registration                                            │
│ • Execution Permit Generation                                               │
│ • Canonical Copy Storage                                                    │
└───────────────────────────────┬─────────────────────────────────────────────┘
                                │
                                │ 2. Execution Permit
                                ▼
                     ┌────────────────────────┐
                     │        Wallet          │
                     │ Enable User Signature  │
                     └────────────┬───────────┘
                                  │
                                  │ User Signature
                                  ▼
                     ┌────────────────────────┐
                     │        Wallet          │
                     └────────────┬───────────┘
                                  │
                                  │ 3. Signed Transaction
                                  │    + Execution Permit
                                  ▼
              ┌──────────────────────────────────────┐
              │ Initial Validation Nodes             │
              │ • Permit Verification                │
              │ • Initial Validation                 │
              └────────────────┬─────────────────────┘
                               │
                               │ Forward According
                               │ To Execution Permit
                               ▼
              ┌──────────────────────────────────────┐
              │ Execution Domain                     │
              │ Selected Parallel Execution Engine   │
              │        (Least Loaded)                │
              └────────────────┬─────────────────────┘
                               │
                               │ Execute Transaction
                               ▼
                     ┌────────────────────────┐
                     │ Host Protocol          │
                     │ Native Consensus       │
                     └────────────┬───────────┘
                                  │
                                  ▼
      ┌───────────────────────────────────────────────────────────────┐
      │                  Unified Global Ledger                        │
      │                                                               │
      │ • Transaction                                                  │
      │ • Execution Permit (Must be recorded)                         │
      └───────────────────┬───────────────────────────────────────────┘
                          │
                          │ Expected Behavior Monitoring
                          ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                               ATHENA                                        │
│                                                                             │
│ • Compare Expected vs Actual Result                                         │
│ • Detect Exceptions                                                         │
│ • Analytical Report                                                         │
│ • Feedback to Host Protocol                                                 │
└─────────────────────────────────────────────────────────────────────────────┘

---

---

ATHENA Architecture

ATHENA is a Transaction Lifecycle Management Layer that operates before transactions enter the network's consensus process.

Unlike many scalability solutions, ATHENA makes no changes to the consensus algorithm, the unified global ledger, the account model, the asset ownership model, the native validation rules, or the network's economic mechanisms. All consensus processes, block production, final transaction recording, and state management continue to be performed strictly according to the native rules of the Host Protocol.

ATHENA's role is to intelligently manage the transaction lifecycle from the moment an Admission Request is received until the transaction is finally recorded in the global ledger. This management includes collecting required information from the wallet and the network, dynamically selecting initial validator nodes, forming initial parallel validation pipelines, determining the execution domain, selecting the least-loaded parallel execution engine, issuing the Execution Permit, managing conflicts, and providing analytical feedback to the Host Protocol.

One of ATHENA's primary innovations is the introduction of a Proactive Conflict Management mechanism based on the Execution Permit. Unlike conventional architectures—which detect and manage conflicts after transactions are broadcast to the network and the validation process has begun—ATHENA seeks to predict the likelihood of conflicts before issuing the Execution Permit and before the transaction enters the network. It does so by analyzing the real-time state of the network and leveraging insights gained from past conflicts to select the most appropriate validation and execution path for the transaction.

In the event of a conflict or any exceptional condition, ATHENA prepares an analytical report detailing the cause of the conflict, how it was managed, and the final outcome, and provides it to the Host Protocol. This feedback enables continuous improvement of admission policies, validator selection, execution domain selection, execution engine selection, scheduling, and other Execution Permit issuance policies, thereby reducing the likelihood of similar conflicts recurring in future transactions.

To the best of our knowledge, the use of proactive conflict management—performed before the transaction enters the network and before the execution permit is issued, based on the Execution Permit—has not been reported in any known blockchain architecture. If implemented in the TRON network, this approach would represent the first instance of such conflict management in a public blockchain.

In this way, ATHENA increases the network's operational capacity and improves the efficiency of resource utilization through intelligent lifecycle management, all without interfering with the consensus process.

Fundamental Principle of ATHENA Architecture

One of the most important distinctions between ATHENA and many existing architectures is that in this architecture, there are no pre‑formed or permanent validator groups or execution groups.

Each Execution Permit is created independently, based on the current state of the network, Host Protocol policies, the capacity of validator nodes, the capacity of execution engines, and the specific characteristics of the transaction request.

As a result, ATHENA first dynamically selects the initial validator nodes and forms an initial parallel validation pipeline from them. It then determines the appropriate execution domain and selects the least‑loaded execution engine among the parallel engines operating within that domain. All these decisions are recorded in the Execution Permit, which defines the complete validation and execution path for the transaction.

Therefore, in the ATHENA architecture, validation pipelines, execution domains, and selected engines are not fixed architectural components; they are the result of ATHENA's dynamic, real‑time decision‑making at the time of Execution Permit issuance.

Since this process is performed independently for each request, the composition of initial validator nodes, the execution domain, and the selected engine may differ from one transaction to the next. Consequently, no validator node or execution engine can predict permanent membership or anticipate its presence in a specific validation or execution path in advance.

The Execution Permit is not merely an admission authorization; it is the authoritative document that defines the complete validation and execution path of the transaction—from the admission stage to final recording in the global ledger. All network components are required to act in accordance with the information recorded in this permit and the policies defined by the Host Protocol.

Furthermore, before the transaction enters the network, ATHENA analyzes the real‑time network state and leverages knowledge gained from past conflicts to select the most appropriate validation and execution path, thereby reducing the likelihood of conflicts from the outset. This feature transforms conflict management from a reactive process into a proactive one.

For this reason, the ATHENA architecture can be regarded not only as a transaction lifecycle management system but also as the first known framework to introduce the concept of proactive conflict management—based on the Execution Permit and performed before the transaction enters the network—in a public blockchain.

Sequential Transaction Processing

Preserving transaction order is one of the important security components of the TRON network. With the introduction of ATHENA into this network, this advantage remains fully intact.

Based on this mechanism, ATHENA establishes a defined sequential relationship between consecutive transactions from the same account, according to Host Protocol policies. This ensures that a subsequent transaction or a reconstructed transaction cannot bypass the original transaction simply by modifying the fee, changing the submission path, or reaching a node earlier.

The purpose of this mechanism is to create a deterministic and verifiable order for the admission of related transactions into the validation and processing pipeline.

1. Enforcing Order at the Admission Layer

In the ATHENA architecture, transaction ordering is enforced at the Admission Layer through the Execution Permit.

When a transaction from a source account enters the admission process, ATHENA records the processing state of that account.

Until the previous transaction reaches the required state for passing the Admission stage—according to Host Protocol policy—ATHENA will not issue a new permit for the next transaction from the same account.

As a result, an account cannot bypass its previous transaction by submitting a new transaction, nor can it cause the new transaction to enter the validation path earlier.

This rule applies to both individual transactions and Bundles.

2. Independence from Submission Type

Processing order is not determined by submission type.

This means that:

• An individual transaction cannot overtake a previous Bundle.
• A new Bundle cannot overtake a previous individual transaction.
• A Bundle cannot gain priority over a previous request from the same account simply because it contains more transactions or has a different fee.

Therefore, the sequential relationship between requests from the same account is independent of whether the request is submitted individually or as a Bundle.

3. Defense Against Transaction Reconstruction and Replacement

This mechanism provides a defensive layer against scenarios where an attacker reconstructs a valid transaction and creates another version of it.

Even if the reconstructed version is structurally acceptable, the attacker cannot simply submit it through a different path or node to get it ahead of the original transaction. This is because ATHENA will not issue a new permit for the source account until the required processing state of the previous transaction has been established.

Thus, submission time or submission path cannot bypass the sequential relationship established at the Admission Layer.

4. Benefits of Sequential Transaction Processing

• Transparency and Predictability: The sequential relationship of transactions from the same account is clearly defined, making network behavior more predictable for users.
• Reduced Race Conditions: Consecutive transactions from the same account cannot enter the processing path without respecting the defined order.
• Reduced Transaction Reordering: A subsequent transaction cannot overtake a previous one simply by modifying the fee, path, or submission time.
• Enhanced State Integrity: A defined processing order helps prevent inconsistent states and certain Double-Spend scenarios.
• Easier Auditing: The sequential relationship of requests and their processing results can be reconstructed and verified.

5. Relationship with Conflict Management

Sequential Transaction Processing does not replace Conflict Management.

Conflict Management is used to handle conflicts that arise during the processing phase, while Sequential Transaction Processing aims to prevent some of these conflicts from occurring in the first place—specifically those caused by improper order of transactions from the same account—at the Admission Layer.

6. Foundational Principle

Execution Permit issuance MUST respect the protocol-defined processing order of requests originating from the same account. A subsequent transaction or bundle MUST NOT become eligible for admission before the required processing state of its predecessor has been established according to Host Protocol policy.

This principle ensures that the order of transactions from the same account cannot be bypassed simply by creating a new transaction, modifying the fee, changing the submission path, or reconstructing a previous transaction.

---

---

Transaction Lifecycle Management in ATHENA

1. Why Do Next-Generation Blockchain Networks Need Such an Architecture?

First-generation blockchain networks were primarily designed for asset transfers, and nearly all transactions followed the same validation path. However, today's blockchain networks have evolved into infrastructure for executing a wide variety of operations—from asset and token transfers to smart contracts, staking, governance, tokenized asset management, interaction with decentralized applications, and other complex operations.

Each of these transaction types has different characteristics, processing requirements, and execution needs. Under such conditions, using a single fixed validation path for all transactions is no longer sufficient for modern networks and gradually leads to processing bottlenecks, increased queueing, imbalanced load distribution, and reduced operational efficiency.

ATHENA was designed with this perspective in mind. Rather than routing all transactions through a single fixed path, this architecture determines, from the moment a transaction request is received, the appropriate path for that transaction based on the network's real-time state.

2. Transaction Lifecycle Management

In ATHENA, the lifecycle of each transaction begins when an Admission Request is sent and continues until the transaction is finally recorded in the global ledger.

Throughout this lifecycle, ATHENA is responsible for managing, in a unified manner, all decisions that must be made before the transaction enters the consensus process.

These decisions may include:

• Collecting required information from the wallet and the network
• Assessing the real-time state of the network
• Dynamically selecting initial validator nodes
• Forming initial validation pipelines
• Determining the appropriate execution domain
• Selecting the least-loaded parallel execution engine
• Issuing the Execution Permit
• Managing conflicts
• Providing analytical feedback to the Host Protocol

After the Execution Permit is issued, the validation and execution path of the transaction is determined, and other network components continue their operation according to the information recorded in the permit and the Host Protocol rules.

3. Managed Admission

One of ATHENA's fundamental distinctions from conventional architectures is the replacement of Unmanaged Admission with Managed Admission.

In many current networks, the wallet broadcasts a transaction without any awareness of the network's real-time state, and the network attempts to validate, schedule, and manage it after propagation.

In contrast, ATHENA, before the signed transaction enters the network, first examines the network's real-time state and then determines the most appropriate validation and execution path for that transaction.

As a result, the network's input is no longer an unmanaged stream of transactions but a controlled, scheduled, and intelligently directed flow.

4. Execution Permit

In ATHENA, the Execution Permit is not merely an admission authorization.

In practice, this permit serves as the Execution Blueprint for the transaction.

The Execution Permit may contain information such as:

• Responsible validators
• Initial validation pipeline
• Execution domain
• Selected execution engine
• Validation policies
• Execution constraints
• Other Host Protocol-required parameters

As a result, all network components operate precisely according to this execution blueprint, and no component makes independent decisions outside the defined policies.

5. Validation Path Transparency

In many current architectures, once a transaction is recorded in the global ledger, only the final result is visible, and no information exists regarding its validation path.

In contrast, ATHENA enables the validation path to be reconstructable.

For this reason, it is recommended that the Execution Permit or its corresponding Cryptographic Commitment be stored alongside the transaction in the global ledger.

This information enables independent auditing, reconstruction of the transaction execution path, evaluation of validator performance, and analysis of the validation process—even years after Finality.

6. Conflict Prediction Before Transaction Entry

One of the most innovative aspects of ATHENA is conflict management before the transaction enters the network.

In conventional architectures, conflicts are detected only after the signed transaction has entered the network and the validation process has begun.

However, in ATHENA, efforts are made before the Execution Permit is issued and before the signed transaction enters the network—by analyzing the real-time network state and leveraging insights from past conflicts—to predict and minimize the likelihood of conflicts.

When a conflict or exceptional condition is observed, ATHENA provides the Host Protocol with an analytical report detailing the cause, the handling approach, and the final outcome. This enables the Host Protocol to refine admission policies, validator selection, execution domain selection, execution engine selection, and other Execution Permit issuance policies for future requests.

To the best of our knowledge, the use of an architecture that can analyze the likelihood of conflict before the transaction enters the network and before the consensus process begins—and adjust the transaction execution path accordingly—has not been reported in any known blockchain architecture.

7. Adaptive Architecture

ATHENA does not impose any fixed policies on the Host Protocol.

All operational parameters—such as:

• Number of validators per pipeline
• Number of validation pipelines
• Number of execution domains
• Number of execution engines
• Validator selection policies
• Engine selection policies
• Scheduling policies

remain entirely under the authority of the Host Protocol.

Consequently, as the host protocol evolves or its rules change, ATHENA adapts accordingly without requiring any changes to its own architecture.

---

---

Key Architectural Features

The ATHENA architecture is founded on a set of key capabilities that distinguish it from conventional architectures. These capabilities enable unified transaction lifecycle management and optimal utilization of network resources, without making any changes to the consensus algorithm, unified global ledger, account model, or native validation rules.

Expected Behavior and Outcome Tracking

One of the key capabilities of the ATHENA architecture is the introduction of the concept of Expected Behavior for each transaction. This concept transforms the transaction lifecycle from a simple "send and wait for result" process into a fully verifiable cycle encompassing planning, execution, monitoring, and result validation.

Expected Behavior refers to the set of outcomes that, based on the information contained in the Admission Request, the rules of the Host Protocol, and the data recorded within the Execution Permit, are anticipated to be observed upon the transaction's finality in the global ledger.

For example, if a wallet requests to transfer 10 TRX from account A to account B, the Expected Behavior of this transaction would include:

• 10 TRX being deducted from account A's balance;
• 10 TRX being added to account B's balance;
• The transaction having been processed exactly according to the validation and execution path specified in the Execution Permit;
• The final result conforming to the rules of the Host Protocol.

For simple transactions, this behavior is usually highly predictable. Conversely, for more complex transactions—such as smart contract calls—the Expected Behavior may involve a set of state changes, outputs, or conditions defined by the contract itself.

For this reason, ATHENA does not attempt to replace the logic of smart contracts; rather, it receives the necessary information to define Expected Behavior from the Host Protocol and incorporates this into the Execution Permit issuance process.

Monitoring Expected Behavior

As described in the ATHENA architecture, ATHENA's responsibility does not end with the issuance of the Execution Permit. ATHENA monitors the lifecycle of each transaction until its final recording in the global ledger. After a transaction reaches Finality, ATHENA compares the recorded outcome with the Expected Behavior.

• If the observed outcome is consistent with the Expected Behavior, the transaction's lifecycle is considered complete.
• However, if the recorded result deviates from the Expected Behavior, ATHENA registers this as an Exception and sends the necessary report to the Host Protocol.

Investigating the cause of this deviation, determining its origin, and deciding on any subsequent actions remain entirely under the authority of the Host Protocol. ATHENA does not modify any consensus, security, or governance rules.

Impact on Resource Allocation

One benefit of this model is that ATHENA can consider the certainty of the Expected Behavior when issuing the Execution Permit. In general:

• Transactions whose Expected Behavior is simple, deterministic, and highly predictable can be scheduled with the minimum processing resources required by the Host Protocol.
• Transactions whose Expected Behavior is more complex, more sensitive, or dependent on shared network state can be directed, according to Host Protocol policies, to stronger validation paths or allocated more resources.

These decisions are fully governed by the Host Protocol's rules; ATHENA merely implements them through the Execution Permit.

Assisting in Detecting Anomalous Behavior

Monitoring Expected Behavior can serve as an effective tool for detecting anomalous behavior within the network.

If the final result recorded in the ledger deviates from the Expected Behavior, the Host Protocol may consider this event as an indicator for investigating issues such as:

• Abnormal validator behavior;
• Potential presence of a malicious Full Node;
• Execution errors;
• Synchronization issues;
• Other exceptional conditions.

ATHENA only identifies and reports the deviation and makes no independent decisions regarding node maliciousness or the imposition of penalties.

Re-validation Capability

If, after reviewing ATHENA's report, the Host Protocol determines that the result of a transaction is unreliable, it can, according to its own policies, decide to re-process the transaction.

In such a case, ATHENA can issue a new Execution Permit for the same request and select a different validation path.

Comparing the results from the independent execution of a transaction across different paths can provide the Host Protocol with valuable data to analyze the root cause of the discrepancy, verify the transaction's execution, and detect anomalous behavior.

Summary

The concept of Expected Behavior is one of the complementary capabilities of the ATHENA architecture for enhancing the Observability and Auditability of the transaction execution process.

This approach is being employed for the first time in a major network, enabling end-to-end monitoring of the transaction lifecycle from the moment an Admission Request is sent to its final recording in the global ledger. It significantly increases the network's transparency, auditability, and performance analysis capabilities.

In this model, without intervening in consensus, ATHENA uses the information from the Admission Request, the Host Protocol rules, and the Execution Permit to compare the final outcome of a transaction against the Expected Behavior. If any discrepancy is observed, it is reported to the Host Protocol.

This approach not only enables full monitoring of the transaction lifecycle but also provides a valuable tool for error analysis, policy improvement, increased validation transparency, and facilitating the investigation of anomalous behavior. Consequently, anomalous behavior can be detected much faster than in conventional models and examined according to Host Protocol policies, without introducing any changes to the blockchain's consensus mechanism or security model.

Execution Permit–Based Transaction Admission

Eliminating the Public Transaction Waiting Layer

Transaction Admission in Conventional Blockchain Architectures

In conventional blockchain architectures, regardless of the consensus algorithm employed, transaction admission generally follows a common architectural pattern.

After a wallet signs a transaction, the signed transaction is immediately propagated throughout the network and placed into a shared public waiting layer, commonly referred to as the mempool or transaction queue.

This waiting layer temporarily stores incoming transactions until validators or block producers select them for execution.

Consequently, transaction admission and transaction execution are decoupled.

Transactions first become publicly visible to the network, and only afterwards compete for execution resources according to the current processing capacity of the blockchain.

Conventional Architecture



      Wallet

         │

         │ Sign Transaction

         ▼

 ┌───────────────────────┐

 │ Public Waiting Layer  │

 │ (Mempool / Queue)     │

 └───────────────────────┘

         │

         ▼

     Validators

         │

         ▼

      Consensus

         │

         ▼

    Global Ledger

This architectural model introduces several inherent characteristics:

. Signed transactions enter the network before execution resources are allocated.
. All transactions compete within the same public waiting layer.
. During periods of congestion, the waiting layer naturally grows.
. The execution path of a transaction is unknown until validators eventually select it.
. Every network participant can observe the signed transaction while it waits.
. The public waiting layer therefore becomes an architectural component rather than merely an implementation detail.

Transaction Admission in ATHENA

ATHENA fundamentally redesigns transaction admission.

Instead of allowing a signed transaction to enter the network immediately, the wallet first requests permission to execute the transaction.

This request, referred to as an Admission Request, contains only the information required by the Host Protocol for admission decision-making.

No signed transaction exists at this stage.

After receiving the Admission Request, ATHENA evaluates the current operational state of the network together with the policies defined by the Host Protocol and generates an Execution Permit.

The Execution Permit completely defines the transaction lifecycle before the signed transaction is created.

Depending on Host Protocol policy, the permit may specify:

• validation path;
• initial validator chain;
• execution domain;
• execution engine;
• scheduling policy;
• execution constraints;
• conflict-management policy;
• expected behavior;
• validator quorum;
• and any additional execution parameters required by the Host Protocol.

Only after receiving this permit does the wallet digitally sign the transaction.

The signed transaction is then transmitted directly to the validator chain specified inside the Execution Permit.

No public transaction waiting layer exists between the wallet and the designated validators.

ATHENA Architecture



      Wallet

         │

         │ Admission Request

         ▼

 ┌────────────────────┐

 │      ATHENA        │

 │ Admission Layer    │

 └────────────────────┘

         │

         │ Execution Permit

         ▼

      Wallet

         │

         │ Sign Transaction

         ▼

 Designated Validator Chain

         │

         ▼

 Native Consensus

         │

         ▼

  Global Ledger

Unlike conventional architectures, transaction admission in ATHENA is no longer based on placing signed transactions into a shared waiting pool.

Instead, each transaction receives its execution path before entering the blockchain.

From the moment an Execution Permit is issued, the wallet already knows:

• where the transaction must be sent;
• how it will be validated;
• which execution policies apply;
• and which validators are responsible for processing it.

The transaction therefore follows its predefined execution path immediately after being signed.

Architectural Consequences

This architectural redesign introduces several important properties.

1. Elimination of the Public Waiting Layer

ATHENA removes the public transaction waiting layer from the transaction lifecycle.

Transactions no longer wait inside a shared pool before execution.

Execution resources are allocated first; transaction propagation occurs afterwards.

2. Execution Path Determined Before Transaction Creation

Unlike conventional architectures, ATHENA determines the execution path before the signed transaction is even created.

The wallet receives the complete execution instructions in advance through the Execution Permit.

3. Managed Transaction Admission

ATHENA transforms transaction admission from an uncontrolled broadcast model into a managed admission model.

Instead of allowing unlimited signed transactions to enter the network simultaneously, admission is coordinated according to the real processing capacity defined by the Host Protocol.

4. No Global Competition Between Transactions

Transactions no longer compete inside a common waiting layer.

Each transaction follows only the execution path assigned by its own Execution Permit.

5. Elimination of Unnecessary Public Disclosure

Because signed transactions are not propagated before execution resources have already been assigned, unnecessary public disclosure of transaction information is eliminated.

The signed transaction becomes visible only to the validator chain responsible for processing that specific transaction.

Architectural Security Implications

The elimination of the public waiting layer produces important architectural security consequences.

In conventional blockchain systems, the public mempool represents an observation layer where signed transactions remain publicly accessible before execution.

Researchers have discussed various attack scenarios that rely on observing transactions during this waiting period, including front-running, transaction-copying attacks, denial-of-service amplification, and long-term concerns regarding quantum-assisted cryptanalysis of publicly exposed signatures.

ATHENA removes the architectural condition required for such attacks.

Because signed transactions are never placed into a publicly accessible waiting layer:

• there is no public transaction pool to observe;
• there is no global transaction queue to monitor;
• there is no architectural waiting period between public propagation and execution.

Instead, transactions are signed only after execution authorization has already been granted and are delivered directly to the validator chain designated by the Execution Permit.

Consequently, the public observation surface created by conventional mempool architectures no longer exists within ATHENA.

This should not be interpreted as ATHENA replacing cryptographic security.

Rather, ATHENA removes an entire architectural exposure layer while preserving the native consensus, execution engine, and security model of the Host Protocol.

Native Compatibility

Although ATHENA fundamentally redesigns transaction admission, it leaves the blockchain's native execution model completely unchanged.

Consensus, block production, state transition, validator governance, and finality remain entirely under the authority of the Host Protocol.

ATHENA modifies only the admission architecture—not the blockchain itself.

Architectural Summary

ATHENA replaces public transaction broadcasting with permission-based transaction admission.

Transactions no longer wait inside a shared public pool; instead, each transaction receives its execution path before it is signed, allowing it to move directly from the wallet to its designated validator chain.

By eliminating the public transaction waiting layer as an architectural component, ATHENA removes an entire class of exposure inherent to conventional mempool-based designs while remaining fully compatible with the Host Protocol's native consensus and execution model.

Full Execution Permit Verification

One of the fundamental principles of the ATHENA architecture is that the Execution Permit is not merely an admission authorization for a transaction. Rather, it is the official, immutable document governing the complete validation and execution lifecycle of that transaction.

At the time of issuance, the Execution Permit is generated based on the current state of the network and the policies defined by the Host Protocol. It records all decisions made by ATHENA for that transaction. Depending on Host Protocol policies, this information may include:

• Transaction type;
• Validation path;
• Initial validator nodes;
• Execution domain;
• Selected execution engine;
• Scheduling policies;
• Permit validity period;
• Security policies;
• Expected behavior;
• And any other parameters required by the Host Protocol.

Simultaneously with permit issuance, a Canonical Copy of the Execution Permit is recorded within ATHENA and serves as the sole authoritative reference for that transaction.

Full Execution Permit Verification Principle

Before any initial validator node begins the transaction validation process, it is required to perform a complete verification of the entire Execution Permit content against the Canonical Copy stored in ATHENA.

This verification is not limited to checking the Permit ID or the validity of the permit signature. Rather, all information recorded within the Execution Permit must match the canonical version without any discrepancy.

In other words, each validator node must verify that:

• The transaction type exactly matches the type for which the permit was issued;
• The validation path remains unchanged;
• The execution domain is the one originally assigned;
• The execution engine is the one originally selected;
• The set of initial validator nodes exactly matches the permit;
• The scheduling and security policies have not been altered;
• The permit validity period has not expired;
• And all parameters defined by the Host Protocol remain identical to the Canonical Copy.

Any discrepancy—even in a single parameter—invalidates the Execution Permit, and the transaction will be rejected before entering the validation and consensus process.

Significance of This Mechanism

In many conventional blockchain architectures, after a transaction is broadcast to the network, its validation path can no longer be independently verified. Subsequent nodes simply accept the results of previous stages without independent validation.

In contrast, ATHENA, by recording the Canonical Copy and requiring initial validator nodes to perform full Execution Permit verification, ensures that the entire validation process proceeds exactly according to ATHENA's original decision. No part of the validation path can be altered between permit issuance and the start of processing.

For this reason, the Execution Permit can be considered the Official Execution Checklist for the transaction—a document that all network components are required to follow precisely during validation and execution.

Intelligent Transaction Admission and Lifecycle Management

In conventional architectures, after a transaction is broadcast to the network, it enters the validation process, and decisions regarding its execution path are made primarily during the initial stages of processing.

In contrast, ATHENA manages the transaction lifecycle before the transaction enters the network and before the digital signature is ever propagated.

After receiving the Admission Request, ATHENA collects the required information from the wallet and the network according to Host Protocol policies. By analyzing the real-time state of the network—including:

• Available processing capacity of initial validator nodes;
• Status of execution domains;
• Load of parallel execution engines within each domain;
• Transactions currently being processed;
• Execution status of transactions from the same account;
• And other policies defined by the Host Protocol—

and based on the transaction type and the monitored information received from the network, ATHENA determines the most appropriate validation and execution path for the transaction and records all these decisions within the Execution Permit.

The Execution Permit is not merely an admission authorization. It is the document that defines the complete validation and execution path of the transaction—from admission to final ledger recording—and all network components are required to operate according to the information recorded within it and the rules of the Host Protocol.

This approach ensures that every transaction has a defined, verifiable, and pre-planned path before entering the network, preventing sudden congestion, imbalanced load distribution, and inefficient use of processing resources.

Dynamic Resource Orchestration

One of the most important features of ATHENA is its dynamic management of network resources.

In this architecture, no validation pipeline, execution domain, or execution engine is permanently assigned to transactions.

For each Admission Request, ATHENA independently decides—based on the current state of the network, the type and domain of the transaction, and the Admission Request sent by the wallet—the following:

• Which initial validator nodes should be selected;
• How many groups and, consequently, how many initial validation pipelines are required across the network for this volume of incoming transactions;
• Which Execution Domain the transaction should enter after initial validation;
• Which execution engine, among the parallel engines within that domain, has the lowest processing load.

As a result, the execution path of each transaction may differ from the next, even if both belong to the same type of operation.

This architecture ensures:

• Balanced distribution of processing load across available resources;
• Prevention of hot spots;
• Scalability of operational capacity in proportion to resource growth;
• Elimination of predictability regarding transaction execution paths by nodes or other network actors.

In other words, ATHENA transforms the network from an architecture with unmanaged transaction admission into one with Managed Transaction Admission—an architecture in which transaction volume growth and processing capacity growth can be managed in a coordinated and balanced manner.

Conflict Prediction and Mitigation Before Transaction Entry

One of ATHENA's core innovations is proactive conflict management.

In conventional architectures, conflicts are typically detected after the transaction has been broadcast to the network and during its execution.

In contrast, ATHENA attempts to predict the likelihood of conflicts before issuing the Execution Permit and before the transaction enters the network—by analyzing the current state of the network and leveraging insights from previously recorded conflicts to select the most appropriate validation and execution path.

Reports generated from actual conflicts are also sent to the Host Protocol, enabling improvements to admission policies, scheduling, node selection, domain selection, and execution engine selection, thereby reducing the likelihood of similar conflicts recurring in the future.

To the best of this research, such an approach—predicting and managing conflicts before the transaction enters the network and before the execution permit is issued—has not been reported in any known blockchain architecture and is one of ATHENA's primary innovations.

Sender Consistency

ATHENA preserves the logical ordering of transactions for each account without imposing restrictions on other accounts.

If a new request is sent from the same account before a transaction is finalized, ATHENA, in accordance with Host Protocol policies and using the information recorded in the Execution Permit, maintains the logical execution order of transactions for that account.

This restriction applies solely to that account and does not prevent the concurrent processing of transactions from other accounts.

Consequently, while maintaining state consistency for each account, the network's parallel processing capacity is preserved.

Runtime Monitoring and Adaptive Feedback

ATHENA continuously monitors the operational status of various network components.

This monitoring may include:

• Load of initial validator nodes;
• Load of execution domains;
• Status of parallel execution engines;
• Conflict rate;
• Initial validation time;
• Time to reach consensus;
• Time to reach Finality;
• Re-execution rate;
• Load distribution quality;
• And other performance indicators defined by the Host Protocol.

The purpose of this monitoring is not merely to display network status, but to create a continuous learning cycle for performance improvement.

Whenever a conflict or exceptional condition occurs during validation or execution—such as the absence of an expected outcome or deviation from expected validator behavior—ATHENA prepares an analytical report detailing the cause, the handling approach, and the final outcome, and sends it to the Host Protocol.

This feedback can serve as the basis for refining admission policies, scheduling, node selection, domain selection, execution engine selection, and other Execution Permit issuance policies, reducing the likelihood of similar conflicts or exceptional conditions recurring in the future.

Consequently, ATHENA, without directly altering network policies, enables Continuous Improvement of network performance through operational analysis and feedback to the Host Protocol.

All final decisions remain the authority of the Host Protocol, while ATHENA serves as the intelligent monitoring, analysis, and transaction lifecycle management system.

Policy-Driven Transaction Lifecycle Management

One of the most important capabilities of the ATHENA architecture is the transformation of the transaction validation process from a static process into a fully policy-driven one.

In conventional architectures, after a transaction enters the network, validators process nearly all transactions using a similar logic, and validation decisions are made during runtime.

In contrast, ATHENA designs the complete execution path of the transaction before it enters the network, based on policies defined by the Host Protocol, and delivers it to the network in the form of an Execution Permit.

For this reason, ATHENA does not decide how a transaction should be validated; rather, it simply enforces the pre‑defined policies established by the Host Protocol.

Execution Policies Are Defined by the Host Protocol

Modern blockchain networks are no longer limited to simple asset transfers.

Depending on the Host Protocol, a network may support various types of operations, including:

• Native coin transfers;
• Token transfers;
• Smart contract execution;
• dApp interactions;
• Staking operations;
• Voting and governance;
• Multi‑signature transactions;
• State‑sensitive operations;
• Cross‑module operations;
• Any new operation type introduced by the Host Protocol in the future.

Clearly, not all of these transactions can be processed with a single validation policy.

For this reason, validation policies for each transaction type are defined solely by the Host Protocol, and ATHENA has no independent decision‑making logic in this regard.

Execution Permit: The Transaction Execution Blueprint

After receiving the Admission Request, ATHENA evaluates the information received from the wallet, the current state of the network, and the Host Protocol policies, and issues the Execution Permit.

The Execution Permit is, in effect, the Execution Blueprint for that transaction.

Depending on Host Protocol policies, this permit may specify:

• The initial validation path;
• The initial validators;
• The Execution Domain;
• The selected execution engine;
• The minimum validation difficulty;
• Scheduling policies;
• Conflict management policies;
• Exception handling policies;
• Monitoring policies or expected behavior;
• Execution constraints;
• And any other parameters the Host Protocol deems necessary.

From this point onward, network components no longer make independent decisions about how to process the transaction; they simply follow the steps defined in the Execution Permit.

Dynamic Routing

One of ATHENA's fundamental differences from conventional architectures is dynamic routing.

In ATHENA, there is no fixed path for any category of transaction.

Even two completely identical transactions may receive different Execution Permits if the network state has changed.

Therefore, the execution path of each transaction is always a function of two factors:

1. The policies defined by the Host Protocol;
2. The real‑time state of the network.

As a result, the network's execution structure can evolve and adapt dynamically without any changes to the consensus algorithm.

Resource Management Based on Transaction Type

The Host Protocol may define different policies for different transaction types.

For example, it may determine that:

• A simple TRX transfer requires only minimal validation resources;
• A specific token transfer requires a different execution domain;
• Smart contract execution requires more validators;
• Minimum validation difficulty varies by transaction type and category;
• Some sensitive transactions should be validated through dedicated paths or with higher difficulty;
• Certain operations should be routed to a specific execution engine;
• Some transactions should be executed in parallel or sequentially and their results compared.

ATHENA does not define these policies; it merely communicates them to the network through the Execution Permit.

Policy Enforcement Verification

One of ATHENA's most important innovations is that the issuance of the Execution Permit is not the end of its responsibility.

ATHENA monitors the execution of the policies defined in the Execution Permit until the transaction is finally recorded in the global ledger.

At this stage, ATHENA verifies whether the network has acted exactly according to the Execution Permit.

This verification may include checking that:

• The validation path was correctly followed;
• All designated validators participated in the validation;
• The execution domain was respected;
• The designated execution engine performed the validation;
• The expected behavior or outcome was correct and no exception occurred;
• And all other policies defined by the Host Protocol were properly enforced.

If any discrepancy is observed, ATHENA registers it as an Exception and sends the necessary report to the Host Protocol.

Transparency in Network Component Behavior

In conventional architectures, once a transaction is broadcast, there is virtually no independent reference to verify whether network components have acted exactly according to protocol policies.

However, in ATHENA, the Execution Permit becomes an official reference for verifying network behavior.

Consequently, any deviation from defined policies is quickly detected and reported by ATHENA to the Host Protocol.

This feature significantly increases the network's transparency, auditability, and observability.

Architectural Principle

ATHENA never decides what a transaction is or how it should be validated.

All execution decisions are made by the Host Protocol.

ATHENA is solely responsible for managing the transaction lifecycle—from receiving the Admission Request, issuing the Execution Permit, managing the execution path, monitoring policy execution, verifying network behavior, and reporting any discrepancies to the Host Protocol.

For this reason, ATHENA can be regarded as a Policy‑Driven Transaction Lifecycle Management Layer—a layer that, without making any changes to the consensus algorithm, security model, or ledger structure, enables intelligent, dynamic, and verifiable management of the complete transaction lifecycle.

Batch Execution Permit — Optional

ATHENA supports Batch Execution Permit functionality.

This capability allows a source account, after receiving a valid batch permit, to submit a set of transactions as a single Bundle to the network.

In this model, the entire Bundle is considered a protocol-level unit with proper authorization and cryptographic integrity, and can be submitted with a single signature applied to the entire content of the Bundle.

A single signature here does not mean reusing a regular signature for multiple independent transactions. Rather, ATHENA defines a new protocol structure in which the entire Bundle is treated as a single Payload for signing.

As a result, any modification to the signed content—including transaction details, amount, destination, or operation type—will invalidate the Bundle's signature.

The primary purpose of the Batch Execution Permit is to support accounts that need to send a large number of transactions.

This capability is particularly suitable for:

• Cryptocurrency exchanges
• Payment platforms
• Distribution services
• High-volume payment systems
• Professional users

The goal is to reduce permit issuance overhead, reduce the number of messages required at the Admission Layer, and enable sending a large number of transactions as a single Bundle.

Submitting a Batch Request

Instead of sending multiple individual permit requests, a source account can submit a single batch request containing n transactions to ATHENA.

All transactions in a batch request must share the same source account.

A source account may have only one active Batch Execution Permit at a time. Until the associated Bundle is finalized, the source account cannot submit a new batch request.

A batch request may include the following information:

• Source account identifier
• List of transactions
• Recipient of each transaction
• Amount of each transaction
• Asset type
• Operation type
• Smart contract parameters, if applicable
• Any other information required by Host Protocol policies

Transaction Review and Path Assignment

Upon receiving a batch request, ATHENA reviews the transactions according to Host Protocol policies.

ATHENA may determine the validation path and processing requirements for each transaction independently.

Therefore, transactions within a Bundle do not necessarily share the same validation or execution path.

The path for each transaction is determined based on the transaction type and Host Protocol policies, and is authorized by ATHENA.

The core requirement for forming a Bundle is that all transactions share the same source account. Other transaction characteristics may differ, provided that Host Protocol permits the combination.

Batch Execution Permit Issuance

After reviewing the batch request, ATHENA issues a Batch Execution Permit.

This permit may include:

• Batch permit identifier
• Bundle identifier
• List of transactions
• Assigned validation path for each transaction
• Initial validator nodes
• Execution domain
• Execution engine or domain assigned for the Bundle
• Permit validity period
• Information regarding reserved resources or balance
• Other details according to Host Protocol policies

Upon issuance, one copy of the Batch Execution Permit is sent to the wallet, and another copy is stored in the Canonical Copy so that the relevant nodes can verify the authenticity and content of the permit.

Bundle Formation and Signing

After receiving the Batch Execution Permit, the source account forms the authorized transactions into a Bundle.

A single signature is then applied to the entire content of the Bundle and the associated permit information.

Once signed, the Bundle is submitted along with the Batch Execution Permit to the designated validation paths.

Since the entire Bundle content is covered by a single signature, any modification to the committed content will break the cryptographic integrity of the Bundle.

Bundle Processing

The wallet prepares the Bundle containing multiple transactions, signs it with a single signature, and submits it together with the permit to the initial validator nodes specified in the Batch Execution Permit.

The designated nodes first verify the Batch Execution Permit and the Bundle signature.

After the permit and signature are confirmed valid, the transactions inside the Bundle are processed and executed according to Host Protocol rules.

Each transaction may have an independent result:

• Success: State changes related to the transaction are applied.
• Failed Execution: State changes related to the failed operation are not applied, but the Failed result is recorded as a processing outcome.

Therefore, the failure of a single transaction does not mean the failure of the entire Bundle.

Bundle Finalization

Once all transactions within the Bundle have reached a determined processing result, the Bundle is considered Finalized as a single processing unit.

In this state:

• No transaction within the Bundle remains in an undetermined processing state.
• The result of each transaction is independently determined.
• Successful transactions have their State Changes applied.
• Failed transactions do not apply any State Changes for the failed operation.
• The result of each transaction is visible and verifiable for accounting, reporting, and auditing purposes.

Therefore:

Bundle Finalization ≠ All Transactions Successful

Bundle Finalization = All Transactions Have a Determined Final Result

Distinction Between Invalid and Failed Execution

To avoid ambiguity, ATHENA distinguishes between two states:

Invalid Transaction:
A transaction that fails initial admission or validation stages—for example, due to invalid structure, incomplete data, incorrect address, or other issues defined by Host Protocol policies—is identified as an Invalid Transaction.

• If the Bundle itself is identified as Invalid: The entire Bundle is rejected.
• If one or more transactions within the Bundle are identified as Invalid: The Bundle continues its validation path without those transactions.

A report of the Invalid Transaction is sent to the Host Protocol, and the source account is notified.

Failed Execution:
Failed Execution transactions within a Bundle have passed the initial admission stages and entered the processing pipeline, but their execution has completed with a Failed result according to Host Protocol rules.

FBT focuses on the second state—preventing the rejection of an entire Bundle due to one or more Failed Execution transactions.

Fee for Failed Transactions

A transaction that has passed the initial admission stages and entered the processing pipeline has consumed computational and network resources.

Therefore, the Host Protocol may define how fees for such transactions are calculated and collected.

A Failed Execution result does not mean State Changes are applied, but the resources consumed during processing may be subject to fees. These fees are deducted from the source account's balance (similar to Ethereum's approach for failed transactions).

Recording Transaction Results

The result of each transaction within a Bundle must be visible and verifiable.

If a transaction fails after entering the processing pipeline, its Failed result is recorded as part of the final Bundle outcome.

Recording a Failed result does not mean State Changes are applied. It indicates that the transaction was valid, entered the processing pipeline, and completed with a Failed execution result.

This information can be used for accounting, reporting, auditing, and Bundle status review.

Relationship Between Batch Execution Permit and FBT

The Batch Execution Permit and Finalized Bundle Transactions (FBT) are related but distinct concepts:

• Batch Execution Permit: The mechanism for batch authorization and admission.
• FBT: The mechanism for complete Bundle finalization.

The overall flow is as follows:

Account → Batch Admission Request → ATHENA → Batch Execution Permit → Signed Bundle → Validation & Execution → Individual Results → Bundle Finalization

In this model, ATHENA is responsible for issuing the permit and determining the admission path, while the Host Protocol defines the validation rules, transaction execution, resource calculation, and final result determination.

Foundational Principle

A Batch Execution Permit MUST be cryptographically bound to all transactions contained within its associated Bundle.

A valid Bundle MAY contain transactions with different execution outcomes.

An Invalid Transaction MUST NOT prevent the Bundle from being processed, provided the Bundle itself remains valid.

The final Bundle result MUST include an independently verifiable outcome for each transaction contained within the Bundle.

In this way, the Batch Execution Permit enables batch transaction submission while maintaining security, transparency, and complete finalization.

---

---

Transaction Lifecycle in the TRON Network Based on the ATHENA Architecture

In the ATHENA architecture, the transaction lifecycle begins at the moment the user decides to send a transaction through their wallet and ends when the final transaction result is recorded in the global ledger and monitored against the expected behavior or outcome by ATHENA.

In this architecture, transaction admission, validation, execution, and monitoring are all conducted according to Host Protocol policies. ATHENA is solely responsible for managing the transaction lifecycle.

Phase 1: Transaction Preparation and Admission Request Submission

The user enters the required transaction information into the wallet. Depending on the operation type, this information may include:

• Sender address
• Receiver address
• Asset amount
• Asset type (TRX, TRC-20, NFT, etc.)
• Smart contract invocation
• Contract parameters
• Any other information required by ATHENA in accordance with Host Protocol policies

After the information is completed, the wallet displays a transaction summary on the confirmation screen for the user to review before signing.

At this stage, and before the user is allowed to sign the transaction, the wallet sends an Admission Request containing the information required by the Host Protocol to ATHENA.

ATHENA, after evaluating the request, the real-time network state, and Host Protocol policies, issues an Execution Permit upon approval.

Only after receiving a valid Execution Permit does the wallet enable the user to sign the transaction. Consequently, no signed transaction is created or broadcast before receiving admission authorization, and all transactions enter the network from the outset according to the execution path determined by ATHENA.

Phase 2: Analysis by ATHENA

ATHENA simultaneously evaluates multiple sets of information:

1. Information received from the wallet.

2. Additional information required by the Host Protocol for each Admission Request.

3. The current real-time state of the network, including:

• Number of incoming transactions at any given moment
• Available processing capacity of initial validators
• Available processing capacity of execution domains
• Load of parallel execution engines within each domain, individually
• Sender Consistency status
• Any other information required by Host Protocol policies

Phase 3: Execution Permit Generation

After completing its analysis, ATHENA issues an Execution Permit.

This permit serves as the complete execution blueprint for the transaction.

The Execution Permit may include:

• Permit validity
• Dynamic selection of initial validators and the resulting formation of parallel validation pipelines based on real-time network load and Host Protocol policies
• Minimum validation difficulty level
• Execution domain
• Selection of the least-loaded execution engine within that domain, from among the parallel engines
• Application of conflict and exception management policies according to Host Protocol rules
• Recording of expected behavior or outcome within the Execution Permit
• Network behavior monitoring policies, expected transaction outcome, conflict management, and exception handling according to Host Protocol rules
• Any other parameters defined by the Host Protocol

Simultaneously:

• A Canonical Copy of the permit is stored in ATHENA for future verification.
• A copy of the Execution Permit is sent to the wallet for transaction submission to the initial validators.

Phase 4: Completion of Both Network Entry Conditions

In ATHENA, a transaction may only begin entering the network when two independent conditions are met:

Condition 1: The user has signed the transaction.

Condition 2: ATHENA has issued a valid Execution Permit.

Neither condition can substitute for the other. Only after both conditions are satisfied is the wallet authorized to submit the transaction.

Phase 5: Direct Transaction Submission

After both conditions are met, the wallet submits:

• The signed transaction, along with
• The Execution Permit

Directly to the initial validators designated in the Execution Permit.

The transaction never enters any public transaction queue or waiting layer.

Phase 6: Full Execution Permit Verification

Before beginning validation, the initial validators are required to verify the entire content of the Execution Permit against the Canonical Copy stored in ATHENA.

This verification covers all components of the permit. If any discrepancy is found, the transaction is rejected, and the appropriate action is taken according to Host Protocol policy.

After successful Execution Permit verification and confirmation of its full alignment with the Canonical Copy—since all transaction validation and execution stages have been completely and authoritatively defined in this permit—all network components are required to operate without making any independent decisions, strictly following the instructions recorded in the Execution Permit.

Phase 7: Initial Validation

The initial validator nodes selected by ATHENA, upon receiving the transaction along with the Execution Permit and after completing its full verification, perform the following preliminary checks:

• Digital signature validity
• Transaction structure
• Account balance
• Request validity
• Any other checks defined by the network protocol

After successfully completing the initial validation, the designated nodes forward the transaction to the specified execution domain and, among the set of parallel execution engines within that domain, to the exact execution engine designated in the Execution Permit.

Each network component is required, after successfully completing its assigned stage, to deliver the transaction to the next component without making any independent decisions, strictly following the instructions recorded in the Execution Permit.

Phase 8: Routing to the Execution Engine

After initial validation is complete, the transaction is routed exactly according to the Execution Permit to the designated execution domain and execution engine.

No new decisions are made by any node at this stage.

Network members are not authorized to make independent decisions at any stage of validation; all steps must be performed strictly according to the Execution Permit.

Phase 9: Transaction Execution

After successful initial validation, the validator nodes, following the instructions recorded in the Execution Permit, send the transaction to the designated execution domain. Within that domain, the transaction is directed to the specific execution engine identified in the Execution Permit, from among the set of parallel execution engines.

The designated execution engine, upon receiving the transaction, executes it according to Host Protocol rules. All state transitions, smart contract executions, and other native network logic are performed at this stage.

Throughout this process, no network component is permitted to select a new path or execution engine; all steps must be performed strictly according to the instructions recorded in the Execution Permit.

Phase 10: Exception Management

If an exception occurs at any stage of transaction validation:

• ATHENA manages the exception according to the instructions and policies received from the Host Protocol and sends the relevant report to the Host Protocol.
• All components re-verify the Execution Permit.
• A report of the exception or incident is prepared and sent to the Host Protocol.
• If necessary, actions such as transaction cancellation, retransmission, retransmission via a new path, continuation of validation from the same stage without rollback, and other measures are taken—all according to the pre-defined Host Protocol policies for ATHENA's exception handling.

Phase 11: Consensus and Finality

ATHENA has no role in the consensus process, block production, or transaction finalization. After the stages defined in the Execution Permit are completed, all further processing proceeds entirely according to Host Protocol rules and the network's native consensus mechanism. Responsibility for consensus, block production, and final ledger recording rests exclusively with the Host Protocol.

Phase 12: Ledger Registration

After the transaction reaches Finality, it is recorded in the network's global ledger.

In the ATHENA architecture, the Execution Permit is also recorded alongside the transaction in the ledger, preserving a complete record of the lifecycle, validation path, and execution process of that transaction.

Recording the Execution Permit enables independent verification, auditing, full reconstruction of the transaction lifecycle, verification of validation process compliance with Host Protocol policies, and monitoring of expected behavior or outcomes in the future.

Thus, each transaction, in addition to its final result, retains a documented and verifiable history of all its validation, routing, and execution stages—which can serve as the basis for security reviews, incident analysis, and future audits.

Phase 13: Monitoring Expected Behavior or Outcome

This is the final stage of the transaction lifecycle.

After the transaction is recorded, ATHENA compares the recorded outcome with the expected behavior or outcome that was defined when the Execution Permit was issued.

If the result matches the expected behavior, the transaction lifecycle ends.

If not, ATHENA records the discrepancy as an Exception and sends a report to the Host Protocol.

The Host Protocol, based on its own policies, decides how to handle the discrepancy. These decisions may include resolving the discrepancy from the same stage, canceling the transaction, or re-validating via a different parallel path and comparing the results obtained.

Key Feature of This Architecture

In the ATHENA architecture, no transaction is permitted to enter the network before receiving an Execution Permit with its complete validation and execution path fully determined. From the moment the permit is issued until the end of the transaction lifecycle, all network components are required to operate strictly according to the instructions recorded in the Execution Permit, and ATHENA monitors this lifecycle through the final expected behavior or outcome monitoring stage.

---

---

ATHENA Resource Utilization

One of the primary objectives of the ATHENA architecture is to increase the efficiency of existing network processing capacity without making any changes to the native architecture of the Host Protocol.

To achieve this goal, ATHENA—relying on Host Protocol policies and the real‑time state of the network—dynamically selects initial validators, execution domains, and parallel execution engines, and determines the appropriate path for processing each transaction in the form of an Execution Permit.

ATHENA does not alter the role of Super Representatives, the consensus mechanism, block production, or the network's validation structure, nor does it introduce any new class of validators.

The sole purpose of this architecture is to utilize the existing processing capacity of the network more efficiently before transactions enter the consensus process, without modifying the core architecture of the Host Protocol.

Deterministic Execution Principle

One of the fundamental principles of the ATHENA architecture is that every transaction must be processed exactly according to the execution path defined in its Execution Permit.

After the Execution Permit is issued, no network component is permitted to independently modify, reinterpret, or replace any part of the transaction's validation, scheduling, or execution path.

Each network component is responsible solely for performing the stage assigned to it in the Execution Permit, and after successfully completing that stage, it is required to deliver the transaction to the next component strictly in accordance with the instructions recorded in the permit.

Consequently:

• The execution path of every transaction is deterministically defined from the very moment it enters the network.
• Independent decision‑making by network components regarding the execution path is eliminated.
• All stages of transaction validation and execution can be reconstructed and independently verified at any time.
• The entire transaction lifecycle—from admission to final ledger recording—remains transparent, documented, and auditable.

Accordingly, the behavior of each transaction is determined only once—at the admission stage, based on Host Protocol policies—and remains unchanged throughout the transaction lifecycle.

Summary

ATHENA is a policy‑driven transaction lifecycle management architecture that provides an intelligent layer for admission, routing, scheduling, and execution, without making any changes to the Host Protocol's consensus mechanism, governance model, security structure, or native execution logic.

In this architecture, all execution decisions are made according to Host Protocol policies and communicated to network components through the Execution Permit. All network components are required to perform transaction validation and execution steps exactly in accordance with this permit.

In this way, ATHENA not only increases the efficiency of existing processing resources but also enables intelligent transaction lifecycle management, independent verification, full auditability, monitoring of expected behavior or outcomes, and full compatibility with the native architecture of the network.

---

---

Threat Model

The ATHENA threat model defines the security assumptions, scope of responsibility, and the types of threats this architecture is designed to manage or mitigate.

ATHENA is a transaction lifecycle management, admission, scheduling, routing, and execution monitoring layer. It does not replace the Host Protocol's consensus algorithm, validation rules, or security model.

Therefore, the ultimate security responsibility of the network remains with the Host Protocol.

Security Assumptions

This architecture is designed based on the following assumptions:

• The Host Protocol's consensus algorithm is correctly implemented.
• The Finality mechanism is valid.
• Validators operate according to Host Protocol rules.
• Cryptographic algorithms and digital signatures are valid.
• Authentication mechanisms and network access controls are in place.

If any of these assumptions are violated, the responsibility for managing them falls to the Host Protocol.

Threats Addressed by ATHENA

1. Congestion Attacks

Sending a large volume of Admission Requests to reduce network efficiency.

ATHENA mitigates these attacks through intelligent admission management, dynamic scheduling, and balanced load distribution among initial validators, execution domains, and parallel execution engines.

2. Mempool Observation Attacks

In many networks, signed transactions are placed in a public mempool before entering consensus, where they become observable.

In the ATHENA architecture, there is no public mempool.

Transactions are only sent directly to designated initial validators after the Execution Permit has been issued and the user has signed the transaction.

Consequently, the attack surface arising from the public observation of pending transactions is significantly reduced, and the exploitable time window is completely eliminated.

3. Malicious Full Node Behavior

A malicious Full Node may attempt to:

• Send the transaction through a different path.
• Ignore the Execution Permit instructions.
• Alter the order of execution stages.
• Send incorrect information to other components.
• Refuse to forward the transaction to the next network component.

Since all network components are required to verify the Execution Permit against the Canonical Copy, any deviation from the designated path is immediately detectable. The Canonical Copy mechanism, as an immutable reference, enables the detection of malicious behavior even when attempts are made to disregard the permit.

4. Malicious Initial Validator Behavior

Examples of such behavior include:

• Intentional delays
• Non-responsiveness
• Submitting invalid results
• Incomplete participation in validation
• Failure to follow Execution Permit instructions

These behaviors are recorded during ATHENA's monitoring process and reported according to Host Protocol policies. Any deviation from the designated validation process is also detectable through full Execution Permit verification.

5. Unauthorized Path Modification

After the Execution Permit is issued, no network component is permitted to independently change:

• The validation path
• The execution domain
• The execution engine
• Or the order of execution stages.

Any independent modification will be detected during Execution Permit verification and will result in transaction rejection and a violation report.

6. Unexpected Behavior or Outcome

After the transaction is finally recorded in the global ledger, ATHENA compares the actual execution result with the "expected behavior or outcome" recorded in the Execution Permit.

If any discrepancy is observed, ATHENA sends a report to the Host Protocol so that it can decide how to handle the situation according to its defined policies.

7. Attacks Based on Fixed Structures

In many architectures, fixed validation structures can become targets of coordinated attacks.

In ATHENA, the selection of initial validators, execution domains, and execution engines is performed dynamically for each transaction based on Host Protocol policies.

This feature reduces the likelihood of forming predictable structures.

Threats Outside the Scope of ATHENA's Responsibility

The following remain outside ATHENA's scope of responsibility and are managed by the Host Protocol or the network infrastructure:

• Attacks against the consensus algorithm
• 51% attacks or similar
• Cryptographic algorithm weaknesses
• Theft of user private keys
• Compromise of user wallets
• Network layer attacks
• Physical attacks against node infrastructure
• Operating system or hardware defects

Separation of Responsibilities Principle

ATHENA is responsible for:

• Transaction admission management
• Execution Permit issuance
• Scheduling
• Transaction routing
• Initial validator selection
• Execution domain selection
• Execution engine selection
• Exception management
• Monitoring expected behavior or outcomes
• Monitoring the correct execution of policies defined in the Execution Permit
• Transaction lifecycle oversight

In contrast, the following responsibilities remain with the Host Protocol:

• Final validation
• Consensus algorithm execution
• Block production
• Finality
• Global ledger management
• Fundamental network security

Summary

ATHENA significantly reduces the attack surface at the transaction admission and processing layer by:

• Eliminating the public mempool,
• Implementing intelligent admission management,
• Issuing Execution Permits,
• Deterministically defining the transaction execution path,
• Continuously verifying permits,
• Managing exceptions,
• Monitoring expected behavior or outcomes,
• And overseeing the execution of defined policies.

However, ATHENA is not responsible for the consensus algorithm or the fundamental security of the Host Protocol. It serves solely as a complementary layer that manages and controls the transaction lifecycle—from the initial admission request through to final monitoring after ledger recording.

---

---

The Architectural Vision Behind ATHENA

"The true innovation of ATHENA is not parallel execution itself; it is making transaction routing a first-class architectural component of blockchain systems."

Separating Transaction Routing from Transaction Execution

One of the fundamental principles of the ATHENA architecture is the separation of Transaction Routing from Transaction Execution.

In most conventional blockchain architectures, after a transaction enters the network, its validation and execution path is gradually determined based on the internal state of the network. In this model, routing decisions are made concurrently with transaction entry, and different network components make independent decisions throughout the processing pipeline.

ATHENA fundamentally changes this approach.

In ATHENA, before the transaction enters the network, its complete validation and execution path is determined. This path is recorded in the form of an Execution Permit and enters the network alongside the transaction. From that moment onward, all network components are required to follow only the path defined in the Execution Permit—without making any independent routing or execution decisions.

In other words, the Execution Permit is the execution blueprint of the transaction, and all network components are merely executors of that blueprint.

The Intelligent Routing Layer

In this architecture, ATHENA creates an intelligent transaction management and routing layer responsible for selecting the most appropriate processing path before the transaction enters the network.

This layer, based on transaction information, real-time network state, and Host Protocol policies, decides:

• Which initial validator nodes should perform the validation
• Which execution domain the transaction should enter
• Which parallel execution engine within that domain should execute the transaction
• How the complete transaction lifecycle—from admission to final ledger registration—should proceed

As a result, the transaction's path is determined before it enters the network, and all network components simply follow that path.

Independence from Network Processing Capacity

The innovation of ATHENA is not in creating parallel execution engines or increasing the number of validator nodes.

The core innovation is the creation of an independent transaction routing layer.

For this reason, ATHENA has no inherent dependency on the number of initial validator nodes, the number of execution domains, or the number of parallel execution engines.

Whenever the Host Protocol adds new processing capacity to the network, ATHENA can utilize that capacity—without any changes to its internal architecture—to route transactions more effectively.

Therefore, ATHENA imposes no architectural ceiling on the expansion of processing paths.

As network capacity grows, ATHENA can dynamically, balanced, and purposefully harness that capacity in the transaction routing process—without requiring any redesign or modification to its core logic.

Intelligent Addressing: The Core of ATHENA

Although this architecture introduces concepts such as Execution Permits, execution domains, parallel engines, conflict management, behavior monitoring, and auditing, all of these capabilities are built upon a single foundational concept:

Intelligent transaction addressing before network entry.

In essence, ATHENA determines the optimal processing path for each transaction before it enters the network and then communicates that path to all network components through the Execution Permit.

From this perspective, the Execution Permit is not merely an admission authorization—it is the precise address and complete navigation map of the transaction within the network.

This single concept enables parallel validation and execution paths, conflict management, complete lifecycle auditing, and effective utilization of new network capacity.

Architectural Neutrality

ATHENA makes no changes to the consensus mechanism, governance model, ledger structure, account model, or native validation rules.

It also adds no new roles to network components.

All decisions regarding consensus, block production, Finality, and execution policies remain exclusively under the authority of the Host Protocol.

ATHENA's role is simply to determine the most appropriate processing path before the transaction enters the network and to keep all network components aligned with that path throughout the transaction lifecycle.

The Architectural Motto

ATHENA transforms transaction routing into a fundamental architectural component of blockchain systems.

Or, in other words:

ATHENA is the intelligent routing layer—not the execution layer.

All capabilities of this architecture—lifecycle management, parallel validation, execution domain selection, execution engine selection, conflict management, auditing, and behavior monitoring—are natural consequences of this foundational principle.

For this reason, the most important innovation of ATHENA is not the increase in parallel engines, but the introduction of an independent, intelligent, and scalable transaction routing layer that operates before the transaction enters the network—a layer that can evolve alongside Host Protocol capacity growth, without requiring any changes to the base architecture or consensus mechanism.

The true innovation of ATHENA is not parallel execution itself; it is making transaction routing a first-class architectural component of blockchain systems.
ATHENA does not add capacity—it gives every transaction an address.
As the network grows, ATHENA uses every resource by knowing exactly where to send each transaction.

[Federico2014]

Thanks for the detailed proposal, @alichatme. The crypto-agility and mempool-exposure angles are worth discussing, but before this can move forward a few core points need to be grounded in how TRON actually produces blocks. Could you expand on:

1. Merge into a single block. TRON's DPoS has one SR produce each block (~3s slots) — there's no per-transaction "validator group consensus" step. If groups validate in parallel, how are their results merged into one serialized block and applied to a single global state while preserving ordering/finality? This step determines whether the throughput gain is real, and it's currently unspecified.

2. The real bottleneck. On java-tron the TPS ceiling comes mainly from single-threaded execution during block production and state-store contention, not admission queuing. Since ATHENA sits before consensus, how does it relieve those? A prototype/benchmark would be more convincing than the illustrative 100x.

3. Shared contract state. Many transactions touch shared contract storage (e.g. one TRC20 contract). Same-account routing doesn't cover cross-account write conflicts between groups — how are those detected and handled?

4. Canonical Copy. Requiring a permit per transaction and verification against a Canonical Copy adds a new component on the critical path. Could you specify a concrete design and address the censorship / single-point-of-failure and liveness implications?

5. Scoping the quantum claim. The Admission Request still reveals sender/receiver/amount, and the full transaction is still exposed to the selected validators. What exactly is protected relative to a public mempool?

[alichatme]

@Federico2014
Thank you for taking the time to carefully review this proposal. Below are detailed responses to each of your questions

1. Merging Parallel Validation Results into a Single Block
   ATHENA is a pre-consensus admission and scheduling layer. It does not replace TRON's DPoS consensus mechanism, nor does it modify block production, transaction ordering, state transition, or finality.
   Its role is to prepare transactions for the native consensus process—not to replace it.

The processing flow is as follows:

. ATHENA dynamically selects validator nodes and forms temporary parallel validation groups for incoming transactions.

. Each validation group performs preliminary transaction validation, including cryptographic and protocol-level checks that can safely be executed before block production. Depending on the host blockchain protocol, these checks may include:

• Digital signature verification
• Transaction format validation
• Transaction expiration checks
• Protocol-defined admission validations
• Other protocol-defined preliminary verification rules

. Importantly, ATHENA does not execute smart contracts and does not modify blockchain state. Smart contract execution, state transition, conflict resolution, and all state-dependent validation remain entirely under the responsibility of the Super Representative during native block production.

. The validated transaction sets produced by the parallel validation groups are collected and forwarded to the scheduled Super Representative responsible for producing the next block.

. The Super Representative serializes these validated transactions according to TRON's existing block production rules and produces a single canonical block.

. Smart contract execution, state transition, consensus, and finality are then performed exactly as defined by the native TRON protocol.
Therefore, ATHENA does not introduce parallel block production, multiple ledgers, or independent consensus domains. Parallelism exists only during the preliminary transaction validation stage, while block creation, transaction ordering, state transition, and finality remain completely unchanged.
The expected performance improvement comes from offloading a significant portion of preliminary transaction validation from the Super Representative to parallel validator groups. This allows the Super Representative to focus primarily on native block production, smart contract execution, state transition, and final consensus, without modifying the existing DPoS architecture.

2. The Actual Bottleneck in java-tron and ATHENA's Role
   This is a very important and accurate observation. We fully agree that the primary throughput limitations in the current java-tron implementation are related to single-threaded transaction execution during block production and contention around state storage. ATHENA is not presented as a replacement for these mechanisms, nor as a complete solution to these bottlenecks. Instead, ATHENA is designed to optimize the transaction admission pipeline before consensus and complement future execution-layer improvements.

Role 1: Offloading Preliminary Validation
Based on the current java-tron implementation and publicly discussed performance issues:

. Issue #5386 reports that digital signature verification may require more than 30 ms for certain transactions.
. TIP-428 discusses lock contention between transaction processing and block production, where block threads may wait hundreds of milliseconds under heavy load.
These observations indicate that preliminary cryptographic verification and protocol-level admission checks represent a measurable portion of transaction processing before final block production.
ATHENA is designed to distribute these preliminary validation tasks across dynamically formed parallel validator groups before transactions reach the Super Representative. While this does not remove java-tron's execution bottleneck, it is intended to reduce the amount of preliminary validation work performed directly by the Super Representative prior to native block production.

Role 2: Separating Admission from Execution
In the current architecture, the Super Representative performs both transaction validation and block production.
ATHENA introduces a separation between transaction admission and block execution.
Preliminary validation is performed before consensus, while the Super Representative remains fully responsible for:

. smart contract execution,
. state transitions,
. block production,
. and final consensus.

This separation does not change the DPoS protocol, nor does it eliminate java-tron's single-threaded execution model. Instead, it creates an architectural layer that allows future improvements—such as parallel execution engines or state-management optimizations—to integrate more naturally without modifying ATHENA's admission architecture.
We therefore view ATHENA as an architectural optimization of the transaction admission pipeline rather than a replacement for execution-layer optimizations.
Prototype and Performance Evaluation
We fully agree that a working prototype and performance benchmarks are more convincing than theoretical estimates.
The current proposal focuses on the architectural design.
Performance evaluation through a prototype implementation and benchmarking on the TRON Nile Testnet is planned as future work. Once experimental data become available, the measured TPS, latency, resource utilization, and overall performance characteristics will be documented and shared in a future update of this proposal.

3. Shared Contract State and Write Conflicts
   This is an excellent question and addresses one of the most important challenges of parallel transaction processing.
   To address this scenario, a new section entitled "Protocol-Defined Special Transaction Handling" has been added to the proposal.
   The core principle is intentionally simple:
   ATHENA does not attempt to analyze smart contract semantics or detect write conflicts by itself. Instead, it relies entirely on policies defined by the host blockchain protocol.
   The host protocol determines which transaction types require special handling and provides the corresponding classification or parameters to ATHENA. ATHENA simply enforces those protocol-defined policies when issuing an Execution Permit.
   Operation
   After receiving an Admission Request, ATHENA evaluates the information provided by the wallet together with the policies supplied by the host protocol.
   If the protocol classifies a transaction as a Special Transaction—for example:

. transactions interacting with shared contract state (such as TRC-20 contracts),
. multisignature transactions,
. complex smart contract invocations,
. or any future transaction type designated by the host protocol,

ATHENA issues an Execution Permit instructing the wallet to submit the transaction to the complete validator set defined by the host protocol, rather than to a dynamically selected parallel validation group.
For ordinary transactions, ATHENA continues to use its standard dynamic validator selection mechanism and parallel validation architecture.
Advantages
This approach provides several important benefits:

. Eliminates cross-group write conflicts for protocol-designated sensitive transactions.
. Increases confidence for transactions that require broader protocol-level validation.
. Keeps ATHENA architecture simple by avoiding internal dependency analysis or smart contract conflict detection.
. Preserves ATHENA's per-transaction dynamic scheduling model.
. Remains fully extensible, allowing future transaction types to be supported through host-protocol policy updates without requiring modifications to ATHENA itself.

4. Canonical Copy and Its Architectural Role
   Thank you for raising this point.
   The Canonical Copy is intentionally defined in ATHENA as an architectural requirement, not as a protocol-specific implementation.
   ATHENA only requires that every issued Execution Permit has a corresponding canonical reference that can later be verified by the participating validators. How that reference is stored, replicated, protected, and made available is intentionally delegated to the host blockchain.
   This design decision was made for a specific reason:
   ATHENA is designed as a consensus-agnostic scheduling layer, capable of being integrated into different blockchain architectures without imposing a particular storage or networking model.
   Therefore, the host protocol is free to implement the Canonical Copy using whatever mechanism best matches its own architecture, including (but not limited to):

. replicated storage across trusted network nodes,
. distributed databases,
. Byzantine fault tolerant replication,
. blockchain-native storage,
. or any future scalable implementation.

ATHENA does not require a centralized server.
Likewise, censorship resistance, availability, replication strategy, fault tolerance, and liveness guarantees remain responsibilities of the host blockchain, exactly as they are for every other critical protocol component.
From ATHENA's perspective, the only requirement is that validators are able to verify that the Execution Permit they receive is authentic and corresponds to the canonical version issued during the admission phase.
For this reason, the proposal intentionally avoids prescribing a single implementation, allowing each blockchain to adopt the solution that best fits its own trust model and network architecture.

Proposed clarification for the Proposal
Canonical Copy Implementation
The storage and verification mechanism of the Canonical Copy is implementation-defined and delegated to the host blockchain. ATHENA only requires the existence of a verifiable canonical reference for every issued Execution Permit. Replication, availability, fault tolerance, censorship resistance, and storage architecture remain responsibilities of the host protocol.

5. Scope of the Quantum Security Claim
   Thank you for raising this important point.
   ATHENA does not claim to provide post-quantum cryptographic security by itself.
   Its contribution is architectural rather than cryptographic.
   The primary objective is to reduce the exposure of signed transactions before they enter the consensus process.
   Compared with a conventional public mempool:

. signed transactions are not broadcast to the entire network before admission,
. validators only receive transactions after an Execution Permit has been issued,
. transaction dissemination is limited to the validator set designated by the host protocol rather than the entire network.
Consequently, ATHENA reduces both:
. the exposure window during which signed transactions are publicly observable, and
. the exposure surface, by limiting dissemination before consensus.

This architectural change makes attacks that rely on prolonged public exposure of signed transactions—including mempool monitoring, frontrunning opportunities, and potential future quantum-assisted key recovery—significantly more difficult.
However, ATHENA is not a replacement for post-quantum digital signatures.
Long-term resistance against quantum computers ultimately depends on the cryptographic algorithms adopted by the underlying blockchain protocol.
ATHENA should therefore be viewed as a complementary architectural mitigation that reduces exposure, rather than as a cryptographic defense.

Conclusion
The questions raised highlight important aspects of integrating ATHENA with an existing blockchain architecture.
To address them, the proposal has been clarified in several areas:

1. ATHENA is a pre-consensus scheduling layer and does not modify TRON's DPoS consensus, block production process, or global ledger.
2. Validator groups perform only static, state-independent validation, while smart contract execution and state transitions remain entirely under the responsibility of the Super Representative producing the block.
3. ATHENA aims to offload preliminary validation work from the block producer, while acknowledging that improvements to contract execution and state storage remain responsibilities of the underlying blockchain implementation.
4. Transactions requiring special handling are determined exclusively by the host protocol through the Protocol-Defined Special Transaction Handling mechanism, preserving protocol independence while avoiding cross-group state conflicts.
5. The Canonical Copy is defined as an architectural requirement, whereas its storage, replication, availability, and verification mechanisms are intentionally delegated to the host blockchain.
6. ATHENA's quantum-related contribution is architectural rather than cryptographic, reducing transaction exposure before consensus without replacing post-quantum signature schemes.
   We sincerely appreciate the thoughtful review. These questions have helped clarify several aspects of the proposal, and the corresponding explanations have now been incorporated into the specification.

We have also added the following clarifications to the proposal to make this design philosophy more explicit:

---

---

Protocol-Defined Special Transaction Handling

Objective

One of ATHENA's key capabilities is the ability to support specialized transaction processing based on policies and information defined by the host blockchain protocol.

Certain transactions may require a different validation policy due to their nature or security requirements. The classification of these transactions is determined entirely by the host protocol. ATHENA does not define any internal criteria for identifying special transactions.

Depending on the host protocol, these transactions may include (but are not limited to):

. Smart contract calls
. Multi-signature transactions
. Transactions involving shared state
. High-priority or security-sensitive transactions
. Any other transaction type designated by the host protocol for special processing

Operation

When an Admission Request is received, ATHENA evaluates the information provided by the wallet together with the policies and parameters supplied by the host blockchain protocol.

If the host protocol classifies the transaction as a Special Transaction, ATHENA issues an Execution Permit instructing the wallet to submit the transaction to the complete validator set defined by the host protocol, rather than assigning it to a dynamically selected validation group.

For ordinary transactions, ATHENA continues to apply its standard dynamic validator grouping mechanism, allowing parallel transaction validation across multiple execution groups.

Advantages

1. Prevention of Cross-Group Write Conflicts

Processing protocol-defined special transactions through the complete validator set avoids cross-group write conflicts while preserving the native state consistency guarantees of the underlying blockchain.

2. Enhanced Validation for Sensitive Transactions

Transactions designated by the host protocol as security-sensitive or operationally complex are validated using the most comprehensive validation policy defined by the network itself.

3. Reduced Architectural Complexity

ATHENA does not perform complex dependency analysis or attempt to resolve smart contract execution conflicts internally. Those responsibilities remain entirely within the native execution engine of the host blockchain.

4. Consistency with Per-Transaction Decision Making

This mechanism fully aligns with ATHENA's architectural principle of making an independent scheduling decision for each transaction based on the information and policies provided by the host protocol.

5. Future Compatibility

Because the definition of a Special Transaction is entirely controlled by the host protocol, future transaction types can automatically benefit from this mechanism without requiring any modification to the ATHENA architecture.

Host Protocol Independence

ATHENA does not determine whether a transaction is considered special.

The classification of transactions, the applicable processing policies, and the definition of the corresponding validator set are all determined exclusively by the host blockchain protocol.

ATHENA simply enforces those policies by issuing the appropriate Execution Permit.

Consequently, this mechanism fully preserves ATHENA's core architectural principles:

. Protocol Independence
. Minimal Intrusion
. Network Configurability

Summary

ATHENA relies entirely on information and policies provided by the host blockchain protocol to identify transactions requiring special handling.

For such transactions, ATHENA issues an Execution Permit instructing the wallet to submit the transaction to the complete validator set defined by the host protocol, rather than to a dynamically selected validation group.

This approach prevents cross-group state conflicts without modifying the blockchain's consensus mechanism or security model, while preserving ATHENA's parallel validation model for ordinary transactions

---

---

Execution Permit-Based Transaction Admission Lifecycle

In ATHENA, the traditional public mempool model is replaced by an Execution Permit-based transaction admission architecture. Instead of broadcasting signed transactions directly to the network, transaction admission is performed through a lightweight request-evaluation process before any signed transaction is created or propagated.

Under this model, signed transactions never enter the network before receiving an Execution Permit, eliminating the need to expose signed transactions through a public mempool while enabling admission decisions to be made based on the current state of the network.

The transaction admission process is performed as follows:

1. The user prepares the transaction by specifying the sender address, recipient address, transfer amount, and any additional parameters required by the host blockchain protocol.

2. Before the transaction is signed, the wallet sends an Admission Request to ATHENA. This request contains only the information required for admission decision-making. The exact contents of the Admission Request are determined by the host protocol.Because no signed transaction exists at this stage, no cryptographic signature is exposed to the network.

3. ATHENA evaluates the Admission Request according to the policies defined by the host blockchain protocol. These policies may include, but are not limited to:

. Current network load
. Available processing capacity
. Number of active validator groups
. Scheduling policies
. Transaction priority
. Spam-prevention policies
. Rate-limiting rules
. Other protocol-defined admission parameters

4. If the Admission Request satisfies the admission policy defined by the host protocol, ATHENA issues an Execution Permit.The Execution Permit specifies:
   . The permitted execution time window
   . The validator nodes responsible for processing the transaction
   . The applicable scheduling policy
   . Any additional protocol-defined execution parameters

5. A canonical reference of the Execution Permit is stored for subsequent verification.

6. After receiving the Execution Permit, the wallet signs the transaction and submits the signed transaction together with the Execution Permit directly to the validator nodes designated by ATHENA.
   From this point onward, the transaction follows the blockchain's native validation, consensus, block production, and finality procedures without modification.

7. If the processing capacity defined by the host protocol has been reached, ATHENA temporarily postpones issuing new Execution Permits until sufficient processing capacity becomes available.
   During this period, the wallet remains informed of the request status, while no signed transaction has yet been propagated throughout the network.

Consequently, unlike traditional public mempool architectures, the waiting queue consists of Admission Requests rather than publicly visible signed transactions.

Advantages

This admission model provides several important benefits:

. Eliminates the need to expose signed transactions through a public mempool.
. Enables intelligent transaction admission based on the actual processing capacity of the network.
. Prevents premature network-wide dissemination of signed transactions.
. Significantly reduces the exposure window of signed transactions by broadcasting them only after processing capacity has been allocated and an Execution Permit has been issued.
. Provides a native backpressure mechanism, preventing transaction admission from exceeding the processing capacity defined by the host blockchain protocol.
. Preserves compatibility with the existing blockchain architecture by modifying only the admission and scheduling layer.

Architectural Principle

ATHENA separates transaction admission from transaction execution.
Its responsibility is limited to evaluating Admission Requests, allocating processing capacity, and issuing Execution Permits.
Consensus, transaction execution, block production, state transition, and finality remain entirely under the control of the host blockchain protocol.
As a result, ATHENA improves admission efficiency and scheduling flexibility without modifying the blockchain's consensus algorithm, execution engine, or global ledger architecture.

[alichatme]

Possible Future Research Direction Inspired by ATHENA

Dear @Federico2014,

Thank you once again for your thoughtful questions regarding the execution bottleneck in java-tron.

Your comments encouraged us to think beyond the current scope of the ATHENA TIP and explore a possible long-term research direction. While this idea is not part of the current proposal, we felt it might be interesting to share because your question highlighted an important architectural challenge faced by many blockchain systems.

A Possible Future Research Direction

The current ATHENA TIP focuses exclusively on transaction admission and scheduling before consensus.

It does not modify TRON's execution engine, DPoS consensus, block production, or state transition logic.

However, your observation regarding java-tron's single-threaded execution raises an interesting question:

Could future blockchain implementations combine intelligent admission scheduling with parallel execution pipelines while preserving the existing consensus model?

We believe this is an interesting direction that may deserve future research.

The following ideas are intentionally presented only at a conceptual level. We have not explored their complete architectural implications, nor are we proposing them as part of the current ATHENA TIP. They are shared solely to illustrate one possible research direction inspired by your question.

Concept

Rather than processing every transaction through a single execution pipeline, a future architecture could naturally extend ATHENA's existing Admission Layer responsibilities.

In addition to dynamically selecting validator nodes, ATHENA could also classify transactions during the Admission phase according to their execution domain and route them to specialized execution pipelines.

For example:

Native TRX transfers

TRC20 token operations

NFT operations

Staking operations

Governance operations

A General Execution Domain for complex or multi-domain transactions

Transactions that clearly belong to a single execution domain could be processed by dedicated execution pipelines operating in parallel.

Whenever ATHENA cannot safely determine transaction independence—or whenever a transaction spans multiple execution domains—it would simply route the transaction to the General Execution Domain for conventional serial execution.

This approach preserves correctness while allowing independent workloads to execute concurrently.

Illustrative Architecture

ATHENA Admission & Scheduling Layer │ Transaction Classification │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ TRX Pipeline TRC20 Pipeline NFT Pipeline │ │ │ └─────────────┼─────────────┘ │ ▼ General Execution Pipeline (Complex / Multi-Domain Transactions) │ ▼ Single SR Implementation (Internally Supporting Parallel Execution) │ ▼ Existing DPoS Consensus │ ▼ Canonical Blockchain Ledger

Why ATHENA Makes This Direction Possible

One of ATHENA's primary responsibilities is already to perform transaction admission before execution by dynamically selecting appropriate validator nodes according to current network conditions.

During this Admission process, ATHENA naturally has access to information such as:

transaction type

destination contract

sender and receiver

protocol-defined metadata

execution domain indicators

Because this information is already available during admission, transaction classification becomes a natural extension of ATHENA's existing scheduling responsibilities rather than introducing an entirely new architectural layer.

The execution architecture itself, however, would remain an independent research topic outside the scope of the current ATHENA TIP.

Why This Might Be Worth Exploring

Several modern blockchain systems are already investigating different forms of parallel transaction execution, including:

Solana (Sealevel)

Aptos (Block-STM)

Sui

Reth

Although each follows a different architectural philosophy, they all demonstrate that improving execution parallelism is becoming an important direction for future blockchain scalability.

We believe ATHENA's Admission Layer could naturally complement future research in this area by providing intelligent transaction classification and scheduling before execution.

Scope Clarification

To avoid any misunderstanding, we would like to emphasize that this is not an extension of the current ATHENA TIP.

It is not a complete architectural proposal.

It is not a specification.

It is simply a conceptual research direction inspired by your question.

Developing such an architecture would require substantial independent research on execution scheduling, state management, conflict detection, benchmarking, fault tolerance, implementation complexity, and many other engineering challenges.

If the community finds this direction interesting, it would certainly deserve a completely separate proposal and much deeper technical discussion.

Closing Thoughts

The current ATHENA TIP remains focused exclusively on improving transaction admission and scheduling before consensus.

The ideas presented above are shared only as a possible future research direction inspired by your question.

Whether such an execution architecture is ultimately practical remains an open research question, but we believe exploring new approaches to parallel execution will become increasingly important for future blockchain scalability.

Thank you again for raising this important topic. Questions like yours often inspire discussions that extend well beyond the boundaries of a single proposal, and we sincerely appreciate that.

[Federico2014]

Thank you for the clarification and for explicitly keeping this idea outside the scope of the current ATHENA TIP. Parallel execution is certainly worth investigating as a separate research direction.

One important caveat is that transaction type or execution domain alone is not sufficient to establish transaction independence. Two TRC20 transactions may access the same contract storage or account, while transactions classified into different domains may still conflict through shared account state, permissions, resource accounting, system contracts, or other global state. For arbitrary smart contract calls, the actual read/write set may not be known until execution.

A safe parallel execution design would therefore need a deterministic conflict model at the state-key level. Possible approaches include explicit access lists, conservative dependency analysis with serial fallback, or optimistic execution with deterministic conflict detection, re-execution, and commit ordering. Regardless of whether block production is parallelized internally, all validating nodes must reproduce exactly the same state transitions and final state root.

[alichatme]

Dear @Federico2014,

Thank you very much for your excellent and detailed feedback. We fully agree with your analysis.

You are absolutely right that transaction type alone is not sufficient to establish transaction independence, and that any safe parallel execution design must operate at the state-key level with a deterministic conflict model. The approaches you mentioned—explicit access lists, conservative dependency analysis with serial fallback, or optimistic execution with deterministic conflict detection, re-execution, and commit ordering—are exactly the kind of rigorous mechanisms that such a proposal would need to explore.

We also completely agree that the correctness boundary must remain within the execution engine, and that ATHENA's role should be limited to providing classification or scheduling hints, without those hints being treated as proof that transactions can safely execute in parallel.

Thank you as well for outlining the key areas that a separate proposal would need to address. Your list provides an excellent roadmap for future research, including state read/write dependency tracking, deterministic scheduling and commit ordering, conflict detection and re-execution, resource and fee accounting, block validation behavior, failure semantics, and realistic benchmarking.

For now, we remain fully focused on the current ATHENA TIP, which is intentionally limited to the Admission Layer and transaction scheduling before consensus.

Based on your valuable observations, we will continue refining this idea and exploring it further. We also hope to benefit from your insights and technical feedback if this research direction is eventually developed into a separate proposal focused on parallel execution.

We sincerely appreciate the time and expertise you have invested in reviewing this work. Constructive discussions like this not only strengthen the current proposal but also help inspire valuable directions for future blockchain research.

Thank you once again for your thoughtful review and for contributing to such a productive technical discussion.

[alichatme]

ATHENA Proposal — Updated After Technical Review

Following extensive technical reviews and valuable feedback from members of the TRON community, the ATHENA proposal has undergone several architectural refinements to better align with the current TRON architecture and the Java-Tron execution model.

The latest revision introduces a deterministic transaction lifecycle centered around the Execution Permit, clearly separates ATHENA from TRON's native DPoS consensus, and defines a protocol-driven admission model that begins before a transaction enters the network.

The proposal now includes:

. Expected Behavior and Outcome Tracking

. A complete transaction lifecycle, from the wallet to final ledger registration

. Execution Permit as the authoritative execution blueprint for all network components

. A conflict and exception management mechanism fully governed by Host Protocol policies

. Full compatibility with the existing Java-Tron execution architecture, including parallel execution engines, without modifying the consensus mechanism, governance model, or ledger structure

These revisions are intended to improve architectural consistency, technical clarity, and facilitate a more accurate evaluation of the proposal.

We sincerely appreciate the valuable feedback, technical discussions, and support from all members of the TRON community. Every review and suggestion has helped improve ATHENA and move the proposal toward a more mature and production-ready architecture.

[Redchar1992]

Thanks for the invitation. I reviewed the updated proposal from the wallet, SDK, and developer-tooling boundary. I think one architectural fork must be resolved before a detailed implementation review: is ATHENA an optional admission gateway, or a mandatory protocol path?

The current draft says that:

• a wallet cannot sign before receiving an Execution Permit;
• the signed transaction and permit must be sent to designated validators;
• validators must verify the permit against ATHENA’s Canonical Copy;
• all network components must follow the permit;
• the permit is ultimately recorded alongside the transaction.

At the same time, the proposal says ATHENA does not change network validation rules, the ledger, or the native transaction-processing model. These positions do not appear compatible.

If ATHENA is optional, existing wallets and wallet/broadcasttransaction must continue working without a permit. In that case, ATHENA is better described as an off-chain gateway or routing service, and transactions can bypass it. Its security and throughput claims should be scoped accordingly.

If ATHENA is mandatory, it is a protocol change. The proposal then needs to specify:

• canonical serialization and signatures for the Admission Request and Execution Permit;
• how the permit is cryptographically bound to the final transaction ID, network, TAPOS reference block, expiration, timestamp, fee limit, and contract parameters;
• the transaction/protobuf or sidecar representation used to carry and record the permit;
• capability discovery, API endpoints, error codes, retries, and backward compatibility for TronWeb, TronLink, TronIDE, and existing nodes;
• who operates and replicates the Canonical Copy, and what happens during outage, censorship, equivocation, reorganization, or permit expiry;
• governance activation and behavior for upgraded versus non-upgraded nodes.

I would also soften the claim that mempool exposure is “completely eliminated.” Designated validators still receive the signed transaction before finality and can leak, log, or withhold it. The exposure surface may be reduced, but it is not removed.

My suggestion is to split the work into two stages: first, an optional non-consensus reference implementation with real latency, throughput, and failure-mode benchmarks; then, only if the results justify it, a separate Core TIP defining the mandatory protocol and ledger changes. This would give wallets and developer tools something concrete to integrate and evaluate without committing the network to an underspecified critical-path component.

[alichatme]

Dear Redchar1992

Thank you for your thorough and thoughtful review from the wallet, SDK, and developer‑tooling perspective. Your questions and suggestions have been extremely valuable and have helped us examine and clarify several important aspects of the ATHENA architecture. In particular, your proposal for a staged deployment and a reference implementation provides a very practical viewpoint for evaluating this architecture.

Below, we respond point by point to your questions and concerns.

1. Is ATHENA optional or mandatory?

The ultimate goal of ATHENA is to be a Mandatory Protocol Path, not an optional off‑chain gateway.

The core philosophy of ATHENA is that the validation and execution path of a transaction should be determined before it enters the network's processing pipeline. This principle can only serve as an architectural guarantee if transactions are required to pass through this path.

However, we agree with your suggestion about staged deployment. We propose that ATHENA be implemented and evaluated Domain‑by‑Domain, starting with the Testnet. For example:

· A specific execution domain is activated first;
· After performance and stability are evaluated, additional domains are added;
· Eventually, ATHENA becomes the standard path for the entire network.

Thus, Mandatory ATHENA is an architectural principle, but its activation for the whole network can be done step by step. This approach enables real‑world measurement of performance, latency, throughput, failure modes, and resource utilization before network‑wide expansion.

2. Does ATHENA change TRON's native validation and processing rules?

ATHENA does not replace the native rules of the Host Protocol.

What ATHENA changes is the how and when of transaction admission and routing before native processing begins—not the inherent logic of validation, contract execution, or consensus.

Therefore:

· Native validation rules continue to be defined by the Host Protocol;
· Smart contract execution continues according to Host Protocol rules;
· State Transition remains the responsibility of the Host Protocol;
· Consensus and Block Production continue via TRON's native mechanism;
· Finality and ledger recording remain under the control of the Host Protocol.

ATHENA is an Admission and Routing Layer that sits before these stages.

More precisely, ATHENA orchestrates the entry and processing path of a transaction, without replacing the native execution logic or consensus mechanism.

3. Serialization and Signature for Admission Request and Execution Permit

The data structure, serialization, and, if needed, the signing method for the Admission Request and Execution Permit will be defined by the Host Protocol. ATHENA does not impose a mandatory format independent of the Host Protocol.

Details regarding serialization, encoding, and authentication will be determined during implementation, following existing network practices and specified by the Host Protocol.

4. How is the Execution Permit cryptographically bound to the final transaction?

During the Admission Request, the wallet provides the information required by the Host Protocol to ATHENA, including, but not limited to:

· Sender Address
· Receiver Address
· Transaction Amount
· Asset Type
· Contract Identifier
· Contract Parameters
· Timestamp
· Expiration
· Fee Limit
· TAPOS / reference information
· And any other parameters required by the Host Protocol.

The Execution Permit is issued based on this information.

After receiving the Permit, the user signs the transaction, and the wallet submits the signed transaction together with the Execution Permit.

The initial validator nodes are required to verify the transaction details against the information recorded in the Execution Permit line by line.

For example, if the recipient address, asset amount, operation type, or any other parameter recorded in the Permit has been changed, the transaction no longer matches the issued Permit and must be rejected.

Thus, an Execution Permit is issued for a specific transaction and cannot be reused for a different transaction.

This is precisely why the verification mechanism is included in the proposal.

This is a fundamental property of ATHENA:

· The Execution Permit cannot be modified after issuance; any change to the parameters affecting the Permit will cause a mismatch and verification failure.
· After the Execution Permit is recorded, it cannot be edited by ATHENA or any other network component.
· Re‑verification is possible at any stage of transaction execution, especially after a conflict is detected.
· Recording the Execution Permit in the ledger enables future verification and auditing.

5. Data structure for carrying the Execution Permit

How the Execution Permit is carried alongside the transaction—whether via Protobuf, a Sidecar, or any other suitable method—will be determined by the Host Protocol. ATHENA does not impose a specific format as an architectural requirement.

The architectural principle is that the Permit must be transmitted in a verifiable form together with the transaction from start to ledger recording, allowing designated nodes to verify it against the authoritative reference.

6. API, Error Codes, Retry Policy, and compatibility with TronWeb and Wallets

Given the staged approach of ATHENA, this part will be defined during implementation, based on the specific requirements of each network.

Consequently, APIs, Error Codes, Retry Policies, Capability Discovery, and other integration details will be determined according to Host Protocol policies.

These items continuously evolve as the network develops and cannot be defined statically, independently of the Host Protocol.

This includes gradual compatibility with tools such as:

· TronWeb
· TronLink
· TronIDE
· SDKs
· Wallets
· FullNode interfaces

Current TRON documentation defines the API architecture around building, local signing, and then broadcasting the transaction. Therefore, in the ATHENA implementation, this path must be explicitly developed for Admission Request and Execution Permit, with details determined and kept up‑to‑date by Host Protocol policies, given the dynamic nature of the network.

7. Management of the Canonical Copy

The Canonical Copy in ATHENA is an authoritative storage reference for the Execution Permit.

This reference is designed to store Permits and must provide appropriate capabilities for availability and data integrity, including redundancy mechanisms at the storage level, as needed by the implementation.

Initial validator nodes, when verifying a Permit, compare the received version against the reference copy.

This design removes the need to add new responsibilities to regular FullNodes and provides a simple, scalable, and reliable solution for storing the original permits.

Key scenarios are managed according to Host Protocol policy:

· Storage Failure: Redundancy and recovery mechanisms are used.
· Permit Expiration: A new Permit is requested.
· Invalid Permit: The transaction is rejected.
· Conflict or Exception: Referred to ATHENA and the Host Protocol according to defined policies.

The overall architecture, implementation, and execution are described in the proposal, but some details—such as the specific storage solution for the Canonical Copy, error codes, and other implementation specifics—are intentionally left open to allow the network to choose the best solution for its conditions at any time and to enable updates.

8. Governance Activation and behaviour of upgraded vs. non‑upgraded nodes

Since ATHENA is a Mandatory Protocol Path, nodes that do not support ATHENA rules will ultimately be unable to act as valid processing components within the ATHENA‑enabled paths.

However, to reduce migration risk, ATHENA activation can be staged.

At each stage, the Host Protocol determines which execution domains and which software versions are subject to the new rules.

Therefore:

Mandatory architecture does not require a Big‑Bang deployment.

ATHENA can be activated first on Testnet, then in a specific domain, and, after success, additional domains can be added gradually.

9. Mempool Exposure

We agree with your point, and the phrase “completely eliminated” is a general statement.

As you correctly noted, under the ATHENA architecture, validators receive the signed transaction directly from the wallet based on the Execution Permit. The public waiting layer—where a transaction would otherwise wait before entering the processing path—is no longer present.

Although this public waiting layer is removed in ATHENA, the transaction can still be observed at the level of the receiving nodes and other network components.

Therefore, a more precise claim is that ATHENA:

· Eliminates the uncontrolled public transaction admission path;
· Sends the transaction directly to designated components after the Permit is issued;
· Reduces the number of components that have access to the transaction before Finality;
· Reduces the exposure window and surface associated with a public transaction waiting pool.

Removing the mempool in ATHENA means maximally reducing the signature‑exposure window in a public environment. This does not mean complete elimination of transaction visibility; rather, it aims to effectively reduce the timing window and exposure surface related to a public transaction waiting pool.

In addition to reducing the attack window through ATHENA, with TRON's migration to Post‑Quantum signatures and limiting the attack window to a single transaction rather than an entire account via OTAK‑NES, significant steps are being taken to counter the threat of public signature exposure in the mempool, node, or network environment:

· ATHENA: Reducing the timing exposure window.
· Post‑Quantum Signature: Strengthening cryptographic resistance to quantum threats.
· OTAK‑NES (if adopted by the community): Limiting the impact of any attack from the entire account to a single transaction.

OTAK‑NES can confine the impact of any attack from the whole account level to an individual transaction.

Given the TRON community's strong focus on security, the OTAK‑NES proposal is available for review in the relevant Issue. If community consensus is reached, it can be reintroduced into the review cycle and submitted as a Pull Request.

10. Proposal for a two‑stage deployment

We fully agree with the spirit of your proposal, with one minor adjustment.

We define the first stage not as an Optional ATHENA Gateway, but, aligning with your suggestion, as:

Limited Mandatory ATHENA Deployment

That is, ATHENA is initially activated in a limited environment—for example, a specific execution domain on Testnet—mandatorily for that domain.

During this stage, the following can be measured in a real environment:

· Transaction Admission Latency
· Initial Validation Throughput
· Execution Throughput
· Permit Verification Overhead
· Resource Utilization
· Conflict Rate
· Exception Handling
· Failure Recovery
· Scalability

After evaluating the results, additional domains can be gradually added until ATHENA covers the entire transaction admission and routing path of the network.

This model retains the main benefit of your proposal—Reference Implementation + Real‑world Benchmarking—without moving ATHENA away from its core architectural principle of being a Mandatory Protocol Path.

Your suggestion is aimed at implementation and clarifying the technical dimensions of the proposal. We believe that, aligned with your perspective, this path offers the best method for practical evaluation of ATHENA before full network deployment.

We sincerely thank you for your detailed review, technical feedback, and expert opinion. We look forward to further insightful and constructive feedback from you.