Network Live

HF-A Technology

Instant Transaction Visibility

HF-A is an optional, decentralized fast transfer rail designed to improve how quickly transactions become visible and usable across the network.

The Basechain remains fully responsible for consensus, validation, and finality. HF-A does not replace or alter these mechanisms. Instead, it introduces a fast path that allows nodes, wallets, and applications to detect and react to new transactions almost immediately.

Source Code (HFA Core): rpc/service/src/hfa.rs

Quick FAQ (Overview)

Is HF-A currently the fastest transaction visibility system in the world?

Based on currently available public data and comparisons with other systems, HF-A appears to be the fastest known transaction visibility system at this time.

How fast does a transaction become visible to the recipient after it is sent?

In most cases, visibility is within about 100 ms. Depending on distance and network conditions, results around 25 ms can also occur.

Is HF-A basically a mempool?

No. HF-A is technically different, especially due to local pre-validation and fast-path handling. It can still interact with mempool data for parts of local pre-validation.

Is HF-A secure?

Yes. HF-A does not replace core consensus, remains optional and backward compatible, and is adaptive and pausable. It also considers abuse scenarios such as on-chain DDoS pressure and false transaction injection attempts.

Which existing technology is HF-A derived from?

HF-A is an original design by Cryptix Network. It was developed independently to improve transaction visibility speed without introducing block spam.

Is HF-A already active?

Yes. HF-A is already active on mainnet and integrated into the web wallet.

Will HF-A continue to be developed?

Yes. Upcoming work focuses on making transactions even faster to use in practice and on accelerating the path toward faster finality.

The section below provides the detailed technical background and measured performance data.

The Problem

In many blockchain systems, transaction confirmation has improved significantly. However, from a user and application perspective, there is still a noticeable delay between submitting a transaction and being able to act on it.

Even when confirmation is fast, systems typically require global agreement before a transaction becomes visible or usable. This introduces unnecessary latency for many real-world use cases. Users care about whether their transaction is visible immediately, not whether it reaches finality in 5 seconds. This highlights a core UX issue across blockchains: perceived speed is not the same as consensus speed. Transactions must be pre-validated and verified and immediately visible to users. In milliseconds, not seconds or minutes.

The Approach

HF-A separates two responsibilities:

  • Final settlement, handled by the Basechain
  • Early visibility and responsiveness, handled by HF-A

Instead of waiting for global consensus, a node can locally validate and temporarily accept a transaction under strict conditions. Once accepted, the transaction is immediately propagated to other nodes.

This allows transactions to become visible and usable as soon as they propagate through the network, rather than only after confirmation.

How It Works (Simplified)

  1. A transaction is submitted to a node.
  2. The node performs full validation and policy checks.
  3. If conditions are met, inputs are locally reserved.
  4. The transaction is accepted into the fast path.
  5. It becomes immediately visible and usable locally.
  6. It is propagated across the network to other nodes.

This process runs independently of Basechain confirmation, which continues in parallel.

What "Fast Confirmed" Means

HF-A introduces a local state called fast_confirmed.

This means:

  • the transaction has been validated
  • inputs are locally reserved
  • the node has accepted it into its fast path

It does not mean:

  • global agreement
  • irreversible settlement
  • final confirmation

Finality remains entirely within the Basechain.

Transaction Visibility (Measured Values)

The following measurements represent observed transaction visibility under normal conditions:

  • Webwallet to Webwallet (same server): ~15-25 ms
  • Within the same country: ~40-50 ms
  • Between nearby countries: ~40-60 ms
  • International (maximum distance, for example USA -> Europe -> Asia): ~120-190 ms

These values reflect healthy nodes and stable network conditions.

In less optimal situations such as network lag or temporary congestion, latency can increase:

  • Degraded conditions: ~300-500 ms

In internal tests so far, such higher latencies have not been observed, but they are considered realistic edge cases in a fully decentralized global network.

For a realistic long-term average, it is reasonable to expect:

  • ~50-100 ms additional overhead compared to ideal propagation values

Interpretation

HF-A operates close to the physical limits of network latency. This means transaction visibility is primarily determined by how fast data can travel between nodes, not by how fast consensus is reached.

As more nodes participate, real-world averages will become clearer and may vary depending on:

  • network topology
  • geographic distribution
  • node connectivity
  • overall network load

Users may also observe periods of increased transaction activity in the explorer during testing phases.

Current Testing

HF-A has already been tested on mainnet with individual nodes.

A broader mainnet stress test is planned to:

  • collect realistic global performance data
  • refine configuration parameters
  • evaluate behavior under sustained load
  • further optimize system performance

Resource Usage and Node Safety

HF-A is designed to operate within strict resource limits.

  • It does not increase blockchain size.
  • All fast-path data is ephemeral and not stored on-chain.
  • It only consumes resources when actively used.
  • There is no standby overhead when inactive.

The system continuously evaluates node conditions such as:

  • CPU usage
  • queue pressure
  • network state

Based on these factors, HF-A can automatically:

  • degrade performance
  • pause temporarily
  • or fully disable itself

This ensures that HF-A will not overload or crash your node.

Even on weaker hardware or slower connections, the Basechain continues to operate normally.

Participation remains fully optional.

Design Principles

HF-A follows a strict set of principles:

  • No second consensus
  • No artificial finality
  • No protocol changes required
  • Fast path is local, bounded, and optional
  • Under load, the Basechain always takes priority
  • Fast functionality can degrade or stop without impact on the network

Developer Perspective

HF-A enables a more responsive interaction model:

  • Wallets can display transactions almost instantly
  • Applications can react in real time
  • User experience becomes smoother and more immediate

At the same time, developers must clearly distinguish between:

  • early visibility (HF-A)
  • final settlement (Basechain)

Outlook

Based on current measurements, HF-A positions CPAY among the fastest systems for transaction visibility observed so far.

Under favorable conditions, transaction visibility approaches the physical limits of network latency. In internal comparisons, no consistently faster systems, whether decentralized or centralized, were identified under similar conditions.

These observations are based on current tests and available data. As the network grows and more measurements become available, results may evolve. Independent comparisons are welcome.

HF-A represents the first step toward a broader Fastchain architecture.

Future stages, currently referred to as HFB and HFC, will focus on further improving:

  • transaction usability
  • responsiveness under load
  • and the speed of finality

The long-term goal is to achieve practical transaction usability and finality in under ~600 ms.

The exact implementation of these next steps is still under active research, with multiple approaches currently being evaluated.