Hacash Maximalist ㄜ

🏛️

[Hacash Maximalist ㄜ @HacMaximalist]

https://t.co/7qukDGeRaA

[Hacash Maximalist ㄜ @HacMaximalist]

Hacash Fullnode v1.2.5 Released! 🚀

Hacash continues to strengthen its core infrastructure. This release focuses on something essential for programmable finance: correct execution, network stability, and more reliable development tools.

Here’s what’s changed and why it matters.

1️⃣ Fitsh Compiler — Critical Control-Flow Fixes

The Fitsh compiler now correctly handles conditional branches (if/else) and loop control (break/continue).

Why is this important?

A compiler translates smart contract source code into executable bytecode. Incorrect jump instructions can cause a contract to follow a different execution path than its developer intended.

In financial applications, where contract conditions may determine transfers, collateral requirements, or liquidations, execution accuracy is fundamental.

This update fixes the compiler’s handling of those control flows, producing corrected bytecode for affected programs.

2️⃣ Fitsh Programming Improvements

The release introduces macro expansion with hygienic local names, along with expanded contract syntax.

These additions make reusable code easier to write while helping prevent unintended variable-name conflicts.

Checked bit-shift operations have also been improved for greater consistency between compile-time and runtime behavior.

The result is a more capable and predictable programming environment for HVM applications.

3️⃣ Network Stability — Important Node Upgrade

The P2P connection magic number has changed.

This means v1.2.4 nodes cannot establish P2P connections with v1.2.5 peers.

Running incompatible versions could split the network and potentially lead to competing chains.

Node operators should upgrade to v1.2.5 as soon as possible.

Importantly, the release notes indicate that block and transaction validation rules have not changed. The main network compatibility change is at the P2P connection level.

4️⃣ Better Transaction Auditing and Mining Reliability

The SDK now provides clearer transaction action descriptions and improved inspection output.

This can help wallets and applications make transaction behavior easier to review.

Mining improvements also introduce outdated-version checks and rebuild block templates when their timestamps no longer satisfy the required rules.

These changes aim to reduce avoidable operational problems.

And as the Hacash ecosystem moves toward real financial use, that kind of work matters.

GitHub:
https://t.co/aF9vNBXtMF

$HAC #Hacash #HVM #SoundMoney

[HacashOrgㄜ @hacashorg]

[Important Release] Istanbul's upgrade marks a perfect finale! v1.2.5 will be a watershed for starting the next on-chain DeFi era. Everyone please update as soon as possible, or it could cause a block mining fork.
https://t.co/xZbfypsaex

[Hacash Maximalist ㄜ @HacMaximalist]

Watching Hacash’s long-term vision gradually become reality is genuinely exciting.

Seeing the HACD Labs Bridge take shape, with HUSD entering the picture, makes me even more optimistic about what’s ahead.

Amazing work, @hacdlabs! 👏

#Hacash $HAC $HACD

[HACD Labs | PoW Coin Launch @hacdlabs]

HACD Labs Bridge is LIVE.

Connecting Hacash PoW assets to the EVM ecosystem.

Bridge HAC and HACD between Hacash and Base, with stablecoin transfers connecting liquidity across both networks.

A new step toward deeper liquidity and PoWFi.

Start bridging: https://t.co/5Fro887mFa

[Hacash Maximalist ㄜ @HacMaximalist]

One of the latest releases in the Hacash upgrade series is up next:

v1.2.4

This release focuses on making contracts running on HVM more controlled and practical.

Two major improvements stand out:

1️⃣ require STRUCTURE IMPROVED

require checks whether the condition necessary for an operation to continue has been met.

For example:

“Continue if the balance is sufficient.”

“Stop the operation if the condition is not met.”

With v1.2.4, require can now carry not only a condition but also an error value.

This allows a contract to provide a clearer explanation of why an operation failed instead of simply stating that “the operation failed.”

Error values are also restricted by the protocol and validated as valid scalar values.

This makes error handling more organized and predictable, especially in complex contracts.

2️⃣ BalanceFungibleBatch

With this release, contracts can read the balances of multiple fungible assets in a single call.

In other words, instead of querying different asset balances one by one, a contract can check them collectively.

This feature enables more efficient contract designs, particularly for financial applications that use multiple assets.

With v1.2.4, bytecode definitions, the metadata structure, execution logic, and the testing infrastructure were also updated to support the new system.

The key point is this:

Hacash is no longer focused solely on adding major features.

It is also refining the details required by real financial applications built on HVM, including error handling, multi-asset balance checks, and more structured execution.

A financial infrastructure becomes usable through more than just big ideas.

Its details must also become reliable, predictable, and developer-friendly.

v1.2.4 is precisely a step in that direction.

Hacash’s programmable financial infrastructure is moving beyond the question of whether it simply “works.”

The question is increasingly becoming:

“How reliably can real financial applications be built on top of it?”

GitHub:
https://t.co/Oomv2RCpbP

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

MoneyNex v0.4.1 is part of an important development for the Hacash ecosystem.

HACD Labs has made it clear:

MoneyNex v0.4.1 lays the foundation for the upcoming HACD Labs Bridge.

Through the bridge, HAC, HACD, and stablecoins will be transferred across blockchains.

The update to MoneyNex is also preparing for this:

• smoother dApp connections
• improved transaction signing
• connected-site management
• more reliable transaction requests
• a new browser sidebar

The structure is clear:

External blockchains
↓
HACD Labs Bridge
↓
MoneyNex
↓
Hacash ecosystem
↓
DeFi and financial applications

The Istanbul Upgrade established the foundation for programmable finance.

The HVM and DeFi engine have been developed.

MoneyNex is strengthening the connection between users and dApps.

The HACD Labs Bridge is opening a new gateway for HAC, HACD, and stablecoins to move across blockchains.

That is why MoneyNex v0.4.1 is not just an ordinary wallet update.

It is one of the stages in which the financial infrastructure built within Hacash’s own blockchain is beginning to connect with external liquidity and other blockchains.

The foundation has been laid.

The tools are being developed.

Now it is time for the ecosystem to connect with the outside world.

$HAC $HACD #Hacash

[Hacash.com @HacashCom]

MoneyNex v0.4.1 is here:

• New browser side panel
• Smoother dApp connections & signing
• Connected sites management
• More reliable transaction requests

Self-custodial. Open source.

Your key to future money.

Get MoneyNex 👇
https://t.co/Lh17Dq61Jw

[Hacash Maximalist ㄜ @HacMaximalist]

Next in the Hacash upgrade series:

v1.2.3

This upgrade is different from the previous ones.

It does not introduce another DeFi feature, VM primitive or contract capability.

Instead, it addresses something even more fundamental:

NETWORK CONSENSUS.

After the Istanbul Upgrade, some nodes had not updated to the latest protocol version.

As a result, the Hacash network was frequently experiencing forks.

This created a serious problem.

Advanced transactions, including DeFi-related transactions, could fail to get confirmed on the correct chain.

At the same time, mining power could be wasted on forks that would eventually become invalid.

So Hacash made a decisive move.

v1.2.3 changes the P2P handshake “magic number.”

What does that mean in simple terms?

Old nodes and updated nodes can no longer continue communicating as if they belong to the same network.

The upgrade effectively forces the network to converge around the latest fullnode version.

Think of it this way:

Hacash had already upgraded the engine.

But some computers were still trying to run the old rules.

v1.2.3 closes that door.

Everyone now needs to speak the same protocol.

WHY IS THIS IMPORTANT?

Because DeFi and programmable finance cannot operate reliably on top of a network that keeps splitting.

Before building:

• DEXs
• lending systems
• smart contracts
• asset markets
• BTCFi infrastructure
• more complex financial applications

the underlying blockchain must agree on one history.

One block.

One state.

One set of rules.

v1.2.3 is about protecting that foundation.

But the most interesting part of the release comes at the end.

Hacash describes v1.2.3 as a:

LONG-TERM STABLE VERSION

following the Istanbul Upgrade.

The release states that capabilities such as the HVM virtual machine have now “basically been solidified.”

And unless major bugs are discovered, the team does not expect frequent fullnode updates in the short term.

That signals an important transition.

For years, much of Hacash’s development focused on building and refining the core protocol:

PoW
consensus
HVM
AST
TEX
HIP-20
P2SH
programmable finance

Now the focus begins to move outward.

The release explicitly says future development will shift toward areas outside the fullnode, including:

BLOCK EXPLORERS

and

DEFI BASIC TOOLS.

That may be the most important message of v1.2.3.

The core is reaching a more stable phase.

The next challenge is no longer simply:

“Can Hacash build the infrastructure?”

The question becomes:

“What can developers now build on top of it?”

In short:

v1.0.10 / Istanbul
→ built the programmable finance architecture

v1.2.0–v1.2.2
→ strengthened DeFi execution and HVM

v1.2.3
→ stabilizes the network around that architecture and prepares Hacash to shift focus toward the ecosystem built on top of it

The foundation has been under construction for years.

Now Hacash is beginning to move from:

BUILDING THE PROTOCOL

to

BUILDING THE ECOSYSTEM.

GitHub:
https://t.co/QqLcynYmv2

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

Next in the Hacash upgrade series:

v1.2.2

After v1.2.1 expanded HVM and strengthened contract security, v1.2.2 focuses on another critical layer:

CRYPTOGRAPHIC TOOLS.

This release adds five new native functions directly into HVM:

• merkle_root
• merkle_multi_root
• secp256k1_recover
• p256_verify
• bitmap_find

Why does this matter?

Because advanced financial applications need more than balances and transfers.

They often need to verify:

• digital signatures
• large sets of data
• membership proofs
• external transaction information
• compact cryptographic commitments

1️⃣ MERKLE ROOT FUNCTIONS

merkle_root and merkle_multi_root allow HVM to work with Merkle-based data structures.

Merkle trees are widely used in blockchain systems because they allow large amounts of data to be represented and verified through compact cryptographic proofs.

In simple terms:

A contract does not always need to process an entire dataset.

It can verify whether certain information belongs to a much larger dataset using a small proof.

This can become useful for:

• proof systems
• batch verification
• cross-chain data verification
• large financial datasets
• bridge-related logic

2️⃣ SECP256K1 RECOVERY

secp256k1_recover is especially interesting.

secp256k1 is the elliptic-curve system used by major blockchain ecosystems such as Bitcoin and Ethereum.

The recovery function allows HVM to recover public-key information from a valid cryptographic signature.

Why is this important?

Because smart contracts can verify who signed a message or transaction without relying only on the normal Hacash account flow.

That can become an important building block for:

• signature-based authorization
• cross-chain systems
• bridge logic
• BTC-related applications
• multi-party financial workflows

This does NOT mean that v1.2.2 suddenly completes Bitcoin integration.

But it gives HVM another tool that can be useful when building systems that need to understand secp256k1 signatures.

3️⃣ P-256 SIGNATURE VERIFICATION

p256_verify adds support for another widely used elliptic-curve signature standard.

This broadens the types of cryptographic signatures HVM can verify.

For a programmable financial system, supporting multiple signature standards can become useful when interacting with:

• external systems
• wallets
• identity systems
• hardware security environments
• cross-chain applications

4️⃣ BITMAP FIND

bitmap_find provides efficient bitmap-based lookup functionality.

This may sound small, but compact bitmap structures can be useful when contracts need to efficiently track:

• membership
• participation
• permissions
• processed items
• validator or signer states

Without wasting unnecessary storage or execution resources.

So what does v1.2.2 represent?

It is not a flashy consumer-facing upgrade.

It is infrastructure.

Hacash is expanding the cryptographic toolbox available directly inside HVM.

The progression is becoming clearer:

v1.2.0
→ stronger DeFi execution

v1.2.1
→ stronger HVM and safer contract inheritance

v1.2.2
→ stronger cryptographic verification inside HVM

This matters because the more Hacash moves toward:

DeFi
cross-chain systems
BTCFi
bridges
complex financial contracts

the more important cryptographic verification becomes.

A programmable financial system must not only calculate.

It must also be able to prove and verify.

v1.2.2 strengthens that side of HVM.

GitHub:
https://t.co/VEaE5rCFN7

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

Next in the Hacash upgrade series:

v1.2.1

After Istanbul established the programmable finance architecture and v1.2.0 strengthened DeFi execution, v1.2.1 continues in the same direction:

Preparing HVM for the broader operation of DeFi smart contracts.

The release focuses on two important areas.

1️⃣ HVM GETS MORE CAPABILITIES

Hacash added new native VM functions together with additional tests.

Native functions are built directly into the virtual machine, allowing smart contracts to use important operations without rebuilding everything from scratch.

The release does not list every new function individually, but the intention is clear:

Expand HVM’s capabilities and test the execution environment more thoroughly as Hacash moves toward more complex DeFi contracts.

For a financial blockchain, this matters.

It is not enough to simply allow smart contracts to exist.

The execution engine underneath them must continue becoming more capable, predictable and well tested.

2️⃣ CONTRACT INHERITANCE BECOMES SAFER

The second change is especially important from a security perspective.

v1.2.1 improves contract inheritance checks so that once a contract has been deployed, its inheritance relationship cannot later be changed.

In simple terms:

If Contract B is built on top of Contract A, that relationship becomes fixed after deployment.

Why does this matter?

Because financial applications may eventually control valuable assets.

Users need confidence that the underlying relationship a contract depends on cannot simply be replaced after deployment.

This makes contract behaviour more predictable and reduces an important class of potential structural risk.

There is also an important network-side message in this release.

Hacash asked node operators to upgrade as soon as possible.

Older nodes could face blockchain mining forks, and nodes experiencing synchronization errors were advised to delete their local block data and resynchronize.

That tells us v1.2.1 was not only about adding contract functionality.

Keeping the network on the same protocol version was also important.

So what does v1.2.1 represent?

It is another step in the maturation of Hacash’s programmable finance stack.

Istanbul:
built the architecture.

v1.2.0:
strengthened DeFi execution.

v1.2.1:
expands HVM functionality, increases testing and makes the contract inheritance model safer.

GitHub:
https://t.co/wHWgMDWfI7

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

Next in the Hacash upgrade series:

v1.2.0

Istanbul introduced Hacash’s programmable finance architecture. v1.1.1 expanded it with Fitsh, L3 preparation and better cross-chain support.

v1.2.0 focuses on strengthening the tools required for real DeFi execution.

1️⃣ LIQUIDATION PRIMITIVES

New Intent capabilities, including use_kind and defer_current, support DeFi contract liquidation.

Liquidation is essential for lending and collateralized finance. If collateral loses value, a protocol must be able to check, recalculate, partially close or liquidate a position.

This creates a foundation for:

• lending and borrowing
• collateralized assets
• vaults
• margin systems
• automated risk management

2️⃣ STRUCTURED MEMORY CONTROL

HVM’s memory-patch mechanism has been reorganized to handle contract memory changes more predictably.

This matters because complex financial contracts rely on many intermediate calculations and state changes.

3️⃣ ASSET ISSUANCE CONTROL

The Asset Meta Action system has been improved. Contracts can now inspect the structure of asset issuance operations.

This connects the asset and contract layers more closely, supporting protocol-issued assets, vault shares, collateralized assets and automated issuance systems.

4️⃣ SAFER ADDRESS HANDLING

v1.2.0 adds automatic address type conversion and version checking.

As Hacash supports normal addresses, P2SH addresses, contracts and programmable account structures, correct address handling becomes increasingly important.

5️⃣ VM COMPATIBILITY

Parts of HVM’s 256 opcode slots were reorganized. As a result, older compiled HVM contracts and P2SH scripts are not bytecode-compatible with v1.2.0.

Developers must recompile contracts and P2SH addresses created with older tools. Using an incompatible address could permanently lock assets.

What does v1.2.0 represent?

Maturation.

Istanbul created the architecture. v1.1.1 expanded its reach. v1.2.0 strengthens the execution engine required for real financial applications.

The progression is clear:

v1.0.0 → programmable finance components
v1.0.4 → PoW and difficulty stability
Istanbul → financial execution architecture
v1.1.1 → L3 and cross-chain foundations
v1.2.0 → stronger DeFi execution

Hacash is moving beyond “Can smart contracts run?” toward a more important question:

“Can they safely execute real financial systems?”

GitHub:
https://t.co/kIfys4uARp

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

Next in the Hacash upgrade series:

v1.1.1

This is the first major protocol upgrade after Istanbul.

Istanbul introduced programmable financial infrastructure to Hacash.

v1.1.1 focuses on making that infrastructure more flexible, developer-friendly, and ready for a broader ecosystem.

The main changes:

1️⃣ PREPARING THE ARCHITECTURE FOR L3

Hacash’s architecture has been reorganized to make its modules more independent and easier to replace or improve.

The goal is to create a stronger foundation for future Layer 3 sidechains and application layers.

In simple terms:

Hacash is no longer focused only on its own main chain.

It is preparing an infrastructure on which other chains and financial applications can operate.

2️⃣ SMART CONTRACTS CAN READ MORE TRANSACTION DATA

Smart contracts can now read:

Transaction Message
and
TxBlob

This allows contracts to understand more than just who sent an amount.

They can also process additional information included in a transaction.

This is especially important for:

• cross-chain bridges
• L2 wallet payment tracking
• transaction references and identifiers

For example, a transfer from another chain can include specific data inside the transaction.

A Hacash contract can read that data and respond accordingly.

This creates an important foundation for cross-chain applications.

3️⃣ DYNAMIC PROTOCOL FEES

v1.1.1 introduces a time-based fee reduction mechanism.

When network activity is low, certain protocol fees can gradually decrease.

A fee reduction is applied every 1,000 blocks, while the discount cannot reduce the fee below 0.1% of the base fee.

The purpose is straightforward:

To make contract deployment, testing, and application development cheaper when the network is not congested.

This can lower the entry barrier for:

• developers
• DeFi projects
• new applications
• testing and deployment

The system may also be improved in the future through on-chain governance.

4️⃣ FITSH

One of the most important additions is Fitsh, Hacash’s native smart contract language.

Its compiler is called:

fitshc

Before this, developers had to work more directly with HVM bytecode and low-level structures.

Fitsh aims to make contract development more readable and accessible.

In short:

Istanbul introduced HVM.

v1.1.1 began building the tools needed to develop applications on top of it.

A powerful virtual machine is not enough for an ecosystem to grow.

Developers also need practical tools and a language they can use efficiently.

Fitsh is designed to fill that gap.

v1.1.1 also includes major infrastructure changes:

• database schema updates
• a new configuration structure
• redesigned P2P networking

Because of these changes, old node data could not be used directly.

Node operators had to delete their previous data, update their configuration, switch to the new P2P protocol, and resynchronize the blockchain.

This means v1.1.1 was not a simple software update.

It was a major protocol upgrade designed to reorganize Hacash’s foundation for the next stage.

In summary:

Istanbul introduced:

PROGRAMMABLE FINANCE

v1.1.1 began preparing it for:

A BROADER AND MORE CONNECTED ECOSYSTEM

L3 preparation
+
cross-chain data support
+
L2 payment tracking
+
dynamic fees
+
the Fitsh smart contract language

Together, these changes show that Hacash is moving beyond a standalone main chain.

It is building infrastructure for financial applications, cross-chain systems, and potentially new chains to operate on top of it.

GitHub:
https://t.co/FTZv81ueng

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

I believe the real story of Hacash begins with the Istanbul Upgrade.

Because this upgrade does not simply add new features to Hacash.

It changes what the system is trying to become.

Before Istanbul, the fundamental question was:

“How can we transfer value securely?”

After Istanbul, the question becomes:

“How can we build a programmable financial system on top of that value?”

To achieve this, Hacash brings several powerful components together within the same architecture:

• HIP-20 enables the creation of new assets
• HVM enables financial logic to be executed
• TEX allows multiple assets to be exchanged atomically within a single transaction
• AST allows transactions to follow different paths based on conditions
• P2SH and Account Abstraction make accounts programmable
• Gas and protocol costs economically price the use of network resources

In theory, this architecture opens the door to:

DEXs
AMMs
lending
borrowing
stable assets
smart wallets
corporate treasuries
tokenized assets
BTCFi
PayFi

But in my opinion, the most interesting part of Istanbul is not any one of these applications.

The truly important point is this:

Instead of forcing everything into a single smart-contract layer, Hacash is attempting to design transaction, asset, account, contract and settlement layers separately.

The goal is not simply to become another blockchain that runs smart contracts.

The goal is to build an auditable and programmable financial infrastructure on top of a PoW-based monetary system.

And if Hacash’s L2 payment network and BTC integration are eventually connected to this architecture at full scale, the importance of the Istanbul Upgrade will become even clearer.

Because at that point, Hacash would no longer be just a network for sending HAC.

It could evolve into a financial protocol attempting to combine money, payments, assets, DeFi and settlement infrastructure within a single system.

GitHub:
https://t.co/f2iw3gLYnD

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

The next upgrade in the Hacash upgrade series is v1.0.4.

Rather than adding new features, this release focused on making the network’s core operation more reliable.

Hacash previously used the LWMA algorithm to adjust mining difficulty. However, this algorithm was causing periodic fluctuations.

At times, the difficulty would drop too much, and blocks could be produced within a few seconds.

At other times, the opposite would happen, and producing a single block could take up to approximately one hour.

This was a serious problem that made it difficult for the network to operate consistently and for transactions to be confirmed on time.

With v1.0.4, Hacash switched its difficulty adjustment system to ASERT at block height 738654.

Why is this important?

In a PoW network, mining power can change constantly.

Some miners join the network while others leave, causing the total hash power to increase or decrease within a short period of time.

If the difficulty adjustment system cannot respond properly to these changes:

• block times become unstable
• transactions are delayed
• the network loses its rhythm
• mining becomes less efficient
• the user experience deteriorates

ASERT is designed to respond more evenly to changes in mining power and bring block production closer to the target interval in a more stable way.

This upgrade also improved Poworker connection stability. Therefore, miners and related software also needed to adapt to the new version.

This is why v1.0.4 holds an important place in Hacash’s development.

With v1.0.0, the first components of Hacash’s programmable finance infrastructure, such as HVM, AST, P2SH and HIP-20, had been introduced.

However, the network on which these features would be built first needed to operate reliably.

v1.0.4 was the upgrade in which Hacash focused on this fundamental requirement.

It aimed to reduce the block-time and difficulty fluctuations experienced in the past. At the same time, it created a stronger foundation for more reliable payment systems, programmable finance applications and DeFi infrastructure in the future.

In short, v1.0.4 did not directly add a new financial application to Hacash.

However, it strengthened the core infrastructure required for Hacash to grow.

Before a blockchain can build new features on top of its network, it must first produce blocks consistently, confirm transactions on time and allow its mining system to adapt to changing conditions.

v1.0.4 strengthened this foundation.

GitHub:
https://t.co/6UjaXGmo6q

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

From now on, we’ll go through Hacash’s major upgrades from past to present and look at how the network evolved step by step.

We start with v1.0.0 — one of the most important turning points.

This release brought technical preview packages for:

• HVM
• AST
• P2SH
• HIP-20

In simple terms, this is where Hacash started preparing to become more than a PoW payment network.

HVM opened the door to programmable financial logic.

AST introduced more advanced transaction flows.

P2SH expanded programmable spending conditions.

HIP-20 prepared the network for native asset issuance.

The release also fixed a serious HACD consensus issue that could block synchronization under certain bidding conditions.

So v1.0.0 was not just another node update.

It was the beginning of Hacash’s transition toward programmable finance and the Istanbul Upgrade architecture.

GitHub:
https://t.co/KhXz4pstTZ

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

Hacash v1.2.3 is out.

This update keeps outdated nodes from splitting the network.

More importantly, HVM and the core system are now largely in place.

Next focus: DeFi, explorer and application tools.

The foundation is ready. Now it’s time to build.

$HAC #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

Hacash; Its target system is much bigger:

• HAC → money
• HACD → scarce PoW asset
• L2 → fast payments
• HIP-20 → new assets
• TEX → atomic swaps and settlement
• HVM → programmable finance
• BTCFi → financial use cases for Bitcoin

#hacash

[Hacash Maximalist ㄜ @HacMaximalist]

@czbinanceprd Unfollow

[Hacash Maximalist ㄜ @HacMaximalist]

@czbinanceprd This is not remain a secret. #Hacash

[Hacash Maximalist ㄜ @HacMaximalist]

@czbinanceprd Bu gizem bana ağır geliyor

[Hacash Maximalist ㄜ @HacMaximalist]

@LCDKripto “Hacash” #HAC kurucusu hiç ortaya çıkmadı, 2018 yılında projeye start verildi ve şuanda kimse yok kendi başına proje çalışmakta, içeriğini anlatmak uzun merak eden gitsin baksın

[Hacash Maximalist ㄜ @HacMaximalist]

@DrWhaleReal Hacash ��