Information for Players on the Cryptix Universe Test Server
Starting today, we will begin partially switching the game servers to an international regional setup for testing purposes.
This means that regional server selections such as EU, Asia, and USA will become available, providing players with better ping and more stable connections.
How the Server Structure Works
Cryptix Universe uses several different types of servers:
* Auth Server — Handles authentication and login.
* Master Server — Stores the database, accounts, and player data.
* Game Servers — Handle the actual gameplay.
This structure allows us to scale the game efficiently and quickly add new servers in additional regions.
For players, it does not matter on which server an account was created or which regional game server they use. Player data remains the same across all servers.
For example, you can play on EU #1, log out, and then connect to USA #2. You will still have the same character, items, progress, and account data.
Every game server connects to the Master Server in the background. This means that players never have to start again when switching servers.
The main purpose of the regional game servers is to provide:
* Better ping and connection quality
* More available player slots
* Stable servers during periods of higher activity
* Faster expansion into new regions
Playing With Other Players
Players connected to different game servers cannot see each other in the game world.
For example, players on EU #1 cannot directly see or play with players on USA #1 or Asia #1, because these are separate game servers.
When you want to play together with friends, you must connect to the same server. There will be a simple and automatic option to switch to the correct server.
However, the following systems are not tied to a specific game server:
* Marketplace and Auction House
* Friend lists
* Private messages
* Account and character data
These systems will display the same information on every server. Only the direct gameplay world is separated between individual game servers.
Important Notice During Development
Please note that EU #1 is the main development server.
New features, updates, and experimental changes will usually appear there first.
The other regional servers will only be started temporarily for testing during the development phase and may not always be available.
https://github.com/Fl4sh9174/Fl4shMiner/
There is new mining software for Cryptix OX8.
Please note that these are external developers/providers. The Cryptix team is not affiliated with the providers.
We’ve made good progress on Cryptix Universe; the controls are ready and will support:
Mouse + keyboard
Mouse only
All controllers
All touch devices / smartphones
We’ve also made strides in graphics and accessibility:
The game can theoretically be played on any device.
All smartphones
All computers, regardless of architecture
All operating systems
We’ve even tested it on an Amazon Fire Stick and a smart TV, and it works
It works wherever there is a browser; no installation is required.
Graphics:
We’ve integrated a new mode that allows players to choose between a bird's-eye view (isometric) and a close-up view (third-person). Players can decide which perspective they prefer, though the third-person view requires more graphics performance.
Graphics Performance:
Vsync, high FPS, and adjustable graphics settings are all supported. The graphics system can even scale models down so that the game runs on virtually any old device or smartphone. However, the game can also upscale to 4K and higher.
Bandwidth/Data:
We rely on procedurally generated models, meaning there are almost no model files to download; instead, they are calculated directly by the CPU. As a result, there is minimal demand for graphics memory or high-end hardware.
We have just reached 66% of all CPAY coins that will ever exist.
From here, the remaining supply becomes increasingly scarce due to the emission schedule and ongoing reward reductions.
Stay tuned — the Cryptix Network keeps building.
Two bugs in the web wallet have been fixed:
1. Sometimes, after sending a standard CPAY transaction, an attempt to send another transaction would trigger an "insufficient CPAY" error, requiring the wallet to be reloaded. This bug has been fixed.
2. In the event of chain reorganizations, the web wallet might fail to recognize them, displaying incoming tokens as outgoing instead. This bug has also been fixed.
New Feature:
A "Details" button has been added; it displays total CPAY and all token holdings, including calculations in both CPAY and dollar values. This provides a quick overall summary.
We have now developed a full-featured bridge for exchanges (CEXs). It provides everything an exchange needs for CPAY; all that remains is to connect the backend to the user IDs.
It has already undergone extensive testing and is fully functional for production; however, it is not yet a battle-tested system, so it requires monitoring.
And an Exchange connection can be established seamlessly. It only requires user IDs (addresses, if available; otherwise, they are generated).
It also offers optional full payload support, as well as full atomic token support—including receiving, sending, and hot wallet functionality for tokens. You simply select a token via its ID, and the Cryptix address serves as the token address as well.
https://github.com/cryptix-network/cpay-cex-bridge
A short user video for the Cryptix Atomic System and Webwallet.
https://x.com/Punitix_Network/status/2069735335085699522
Here are the Winner of the Atomic Video Challenge:
1st Place
25,000 CPAY + 50 CXT Token
You as a player skin in the new Cryptix Universe game
Your name or pseudonym and your desired fictional low-poly appearance will be added to the game forever.
Discord Genesis Member tag
Winner: @goma
2nd Place
15,000 CPAY + 50 CXT Token
Discord Genesis Member tag
Winner: @Punits
3rd Place
10,000 CPAY + 50 CXT Token
Discord Genesis Member tag
Winner: @火炎瓶
Progress on the Cryptix Universe game is going well. We have now implemented private messaging, teams, friend lists, a spectator mode (accessible without registration), a daily fee share draw (where server fees are distributed to players who have completed their daily quests), and many other features. It will be very comprehensive right from launch, ensuring all key functions are included. There are also more cosmetic items, emojis, animated dances, and the like; while these may seem like small details, they really define the game world.
There is now a subpage with more detailed information about the upcoming Cryptix Universe blockchain/play-to-earn game.
https://cryptix-network.org/cryptix-universe-game
Explorer:
The explorer now shows which Node ID found a specific block.
Example block: View example block
Web Wallet new:
Several bugs have been fixed:
Fixed responsive optimization for smartphones in the Atomic Swap section.
Fixed an issue where the token name appeared twice when adding a token with an optional label.
Fixed an issue where some group messages could be missed during live operation. The web wallet now scans back up to 10 blocks during live operation, ensuring that group messages are no longer missed. Standard private messenger messages were not affected by this issue.
Please note: Browsers may sometimes terminate the connection if a tab remains inactive or minimized for an extended period. As a result, a group message may still fail to appear during live operation in rare cases. To prevent this, I recommend enabling the Awake setting in the web wallet options. This should help avoid the issue.
We may look into further optimizations in the future, although it is questionable whether this would consume too much data and processing power when running in the background on smartphones. For now, it may be best to keep this as a user-selectable setting, especially since private messages are not affected.
Some smaller bugs have also been fixed.
Web Wallet 2 old / legacy:
A rate limiter bug has been fixed.
A bug affecting seed recovery has been fixed.
All functions have been verified for compatibility with the new node version.
The old wallet remains fully compatible with its original feature set, excluding Atomic and Messenger.
However, I still do not recommend using the old wallet system, as the new web wallet has supported old legacy seeds since the last update.
Token Explorer:
Previously, it was not possible to view the full activity history. This is now fixed, and the complete activity history can now be viewed.
We are opening a new community event for the Cryptix Atomic System.
Your task is simple:
Create a public video showing the Atomic system in action.
You can record your screen, film with your phone, use a computer or smartphone. Everything is allowed.
You can choose one or more of the following video types:
1. Atomic Swap Speed Challenge
Create a token with Atomic Swap and make your first trade, buy or sell, in under 2 minutes.
2. Wallet + Token Challenge
Create a new wallet and then create a token in under 2 minutes. Atomic Swap is optional here.
3. Deep Explanation Video
Create a deeper video explaining the token system, Token Explorer, normal Explorer, and how everything works. There is no time limit for this video.
If you need CPAY to create a token, you can get free coins from the faucet:
https://faucet.cryptix-network.org/
If you need a fast Wallet:
https://wallet.cryptix-network.org/
You may also show the faucet in your video.
Video rules:
You can speak in the video, use an AI voice-over, or simply add text. Speaking is not required.
The video can be in any language.
Your video must be uploaded publicly somewhere, for example Twitter / X, YouTube, Facebook, or another public platform.
Please tag CPAY and, if possible, link to the Cryptix website:
https://cryptix-network.org/
Your followers or reach do not matter. You can even create a new Twitter / X account for this event. Just use a few relevant tags.
You can create only one video, or you can create all three video types.
Each valid video gives you 1 ticket for the prize draw.
1 video = 1 ticket
2 videos = 2 tickets
3 videos = 3 tickets
The winners will be selected with a random generator using the correct number of tickets.
Prizes
1st Place
25,000 CPAY + 50 CXT Token
You as a player skin in the new Cryptix Universe game
Your name or pseudonym and your desired fictional low-poly appearance will be added to the game forever.
Discord Genesis Member tag
2nd Place
15,000 CPAY + 50 CXT Token
Discord Genesis Member tag
3rd Place
10,000 CPAY + 50 CXT Token
Discord Genesis Member tag
The event starts today and runs for 7 days.
Submissions are open until June 25, 2026.
Post your public video URL as proof in the new Atomic Video channel on Discord.
https://discord.cryptix-network.org/
Show the world what the Cryptix Atomic system can do.
The standard Explorer has now been upgraded to version 1.2. It now offers full Atomic and Messenger functionality, along with many other new features—such as an "outs" preview, a quick hashrate/price overview, and robust responsive/smartphone optimization.
https://explorer.cryptix-network.org/
And:
You can now see a quick overview of the latest Atomic transactions on the standard Explorer's homepage.
There is also a new Atomic sub-page featuring a more extensive list, allowing you to track recent activity:
https://explorer.cryptix-network.org/atomic
And:
In the standard explorer, you can now identify payloads within transactions and see what actions they performed on the blockchain—whether for Atomic or Messenger. This information is now available for every transaction on the respective sub-page.
And:
The standalone Token Explorer has also received several enhancements.
https://token.cryptix-network.org/
We have just re-checked all test nodes and seed servers (Rust + Go) and analyzed all the logs. Not a single node across the entire network showed a token data mismatch (state hash)—an issue that would have been flagged during the P2P check. This means there isn't a single node in the network experiencing problems or determinism errors.
The system has remained stable so far.
You wouldn't believe how nervous we were during the hard fork; things can always go wrong, no matter how much testing is done. Mainnet is a different beast compared to Testnet. However, everything on the chain is perfectly fine for all nodes. There are just a few users still running the old node version and trying to connect; these attempts are being rejected due to the outdated protocol. But I did anticipate that some users wouldn't update their nodes in time.
Long story short: everything is green and functioning flawlessly from a technical standpoint. Naturally, we need to monitor the situation for a few more days, but the likelihood of an error cropping up now is very low.
We have just checked all logs across all nodes—Windows and Linux, Rust and Go nodes. Everything is working. Token/asset states and P2P health checks are also functioning. Everything is green.
The hard fork was successful.
Messenger Group:
This is the official community group.
ID: 93947405d9a3fa6677cd5b1bdf42be89735665eb92aec95c76d54aa93615c683
Password: cryptix
This is the official Community Token:
ID: dfbb776ba10517ad8fd967cf07582c47494e0b925900f1f0f86f36b3902742c4
https://token.cryptix-network.org/token/dfbb776ba10517ad8fd967cf07582c47494e0b925900f1f0f86f36b3902742c4
Let’s Talk About Play-to-Earn and Blockchain-Based Gaming
The typical Play-to-Earn model is simple: someone plays a game and receives rewards, such as coins. Most of these projects are basic 2D games that resemble an old Super Mario game on the Game Boy.
We believe this is the wrong approach:
1. A game should be fun and entertaining. It should not feel like work or become repetitive and boring.
2. Simple reward-based gameplay can easily be automated. A bot or AI can play the game, allowing the financial system to be exploited.
3. Where do the rewards come from? You may be able to attract players with rewards, but what happens if the game becomes popular? Who pays for those rewards, and how can the system remain financially sustainable?
4. The rewards for individual players are usually extremely small. Nobody wants to play for an entire hour to earn ten cents—or spend an entire day playing for a few cents. It simply does not make sense.
For these reasons, and many others, this traditional approach cannot succeed in the long term.
A successful Play-to-Earn game must support itself economically while also providing communication, multiplayer interaction, visibility, competition, entertainment, strong communities, and meaningful incentives. The exact structure of the game and the activities performed within it are secondary to these fundamental requirements.
We are already developing our own concept. It is somewhat complex, but I will explain it anyway:
Players can become stronger, for example by upgrading their items. These upgrades require something that can be earned through gameplay, such as fragments.
Players can use fragments to upgrade their items, making their characters stronger. The stronger a player becomes, the more fragments they can earn—or the faster they can earn them.
Fragments can be sold and traded through a marketplace where the players themselves determine the price through supply and demand.
This creates an economy and gives every player an important decision:
Do I sell my fragments, or do I use them to upgrade my character so that I can farm even more fragments at a faster rate?
This is similar to staking in cryptocurrency:
Do I sell my coins, or do I stake them to earn more?
However, within a game, this decision can have much greater leverage and produce a much faster and more visible effect.
Does this create a Pay-to-Win effect because players could simply purchase fragments?
Yes and no.
Fragments must first be farmed by real players. They cannot simply be purchased out of thin air. Furthermore, when many players want to buy fragments, the price increases. The players themselves decide how many fragments they are willing to sell and at what price.
Yes, it is possible to use CPAY to accelerate your progress—but only when other players are willing to sell the required fragments.
The players themselves determine how strong the Pay-to-Progress dynamic becomes.
This creates a real player-driven economy.
Of course, progression is also determined by items and levels, which are influenced by gameplay time and organic progress. However, items should also be tradable and exchangeable.
Something like soulbound items for earned equipment should not exist. Soulbound systems are an invention of extremely capitalistic gaming companies designed to maintain control over items and generate even more revenue.
But why would players buy or sell fragments?
The reason to sell them is simple: players can earn coins—potentially a significant number of coins, especially during the early stages when only a limited number of fragments exist.
The reason to buy them is faster progression and greater leverage. Players can use fragments to increase their earning potential and later earn even more fragments, or they can pursue immediate returns.
It creates an investment-based decision between long-term progression and receiving coins immediately.
Is this enough to create a sustainable economy?
Yes, it could already be enough—but it can be improved further.
The marketplace could charge a fee on every trade. For example, it could collect a 2% fee from all transactions.
This revenue could be used to finance the servers, continue developing the game, maintain the infrastructure, and fund other necessary expenses. In many cases, this alone could already be sufficient, especially when combined with cosmetic content sold through an in-game shop.
But here is the main point:
What if the best players received part of those marketplace fees?
For example, 50% of the total marketplace fees could be distributed among the players with the greatest progression.
At that point, we would no longer be talking about rewards worth only a few cents. We would be talking about potentially significant amounts.
It would also create a much stronger incentive for players to progress.
The more players use the game, the greater the total amount of marketplace fees becomes. If the game achieves a real breakthrough, these fees could potentially reach thousands of dollars per day.
And it is important to remember that all of this would be generated through a game.
This is a different kind of Play-to-Earn.
The player decides how far they want to go, how much they want to achieve, when they want to sell something, and at what price.
They can decide whether they simply want to sell resources or whether they want to reach the top and receive a share of the game’s total revenue.
With an integrated wallet and a blockchain-based game, this becomes relatively simple because users can automatically receive their share through the blockchain. They can also use the marketplace with real coins.
There is no KYC process and no bank transfer.
Sell something on the marketplace and receive CPAY directly.
Purchase something and pay with CPAY directly.
Valuable items should also be verifiable through the blockchain.
Unique hashes can be stored inside signed blockchain payloads. When you purchase a powerful item on the marketplace, you can verify that it is authentic, unique, and legitimate.
Nobody should be able to create items from nowhere or clone them.
The item exists on-chain—for example, as a hashed token with a total supply of exactly one.
All of this functionality will be supported by our blockchain following the hard fork.
And at this point, we introduce Cryptix Universe:
A blockchain-based Play-to-Earn game with real wallets, real coins, and a real marketplace, where the players determine the economy and receive a share of the game’s total marketplace revenue.
Our goal is to introduce a new idea and a new form of innovation to Play-to-Earn and blockchain gaming.
It should not be a system designed primarily to make developers rich. It should be a system in which players can genuinely participate in Play-to-Earn and potentially earn meaningful amounts.
We began developing Cryptix Universe approximately six months ago, and an early prototype already exists.
There is still a great deal of work to be done. The models, animations, sounds, visual effects, and many other elements still need to be refined.
However, the most important core systems are already implemented:
Multiplayer
PvP
PvE
Server chat
Marketplace
In-game shop
Wallet system
Cryptix Universe is also a browser game.
There is no traditional installation process and no need to download large game files. It can be played directly through a browser on different devices or installed as a Progressive Web App.
It is also responsive and designed to work on smartphones.
The game uses procedural geometry for its graphics and models, meaning:
No traditional asset pipeline or external asset hosting.
No large model or texture downloads.
No long download times.
Everything is versioned directly as code, resulting in a very small bundle size and extremely fast loading times.
Skins, colors, proportions, and other properties can be modified directly in the code without requiring Blender.
Do not underestimate what this approach can achieve in terms of graphics, gameplay, and overall scale.
We are using WebGPU and other modern technologies. Many people would be surprised by how much gaming performance and visual quality can now be achieved directly inside a browser.

Don’t forget: you need to replace/update your All-in-One software, wallets, and nodes within the next 4 days.
Otherwise, you will not be able to connect after the hard fork, as the P2P protocol has changed.
Here are the new files:
Linux / Windows:
Rust Node with CLI Wallet:
https://github.com/cryptix-network/rusty-cryptix/releases
Go Node with Wallet Daemon:
https://github.com/cryptix-network/cryptixd/releases
All-in-One Software:
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v.3.0.2
GUI / Desktop Wallet for Linux and Windows:
https://github.com/cryptix-network/cryptix-gui-wallet/releases/tag/v.1.1.16
Browser Extension:
https://cryptix-network.org/assets/downloads/cpay-browser-extension.zip
Web Wallet #1:
https://wallet.cryptix-network.org/
Final and ready with full Atomic support.
Web Wallet #2 legacy system:
No Atomic support, only normal transactions. No Messenger.
Web Wallet #1 supports old legacy seeds. You can also use the seeds from Web Wallet #2 there.
Please note: you should clear your browser data, then reload with CTRL + F5 and log in again with your seed. Otherwise, bugs, slow loading times, or poor performance may occur.
If you have installed the Web Wallet as a PWA, whether on desktop or smartphone, the same applies: delete the app, open it in the browser, clear the browser data, reload, and install it again.
I recommend using Google Chrome as the browser, as it offers the best performance. This matters both on smartphones and computers, especially if you install the wallet as a PWA, because the browser used for the installation is also relevant for the PWA.
For the All-in-One software, I recommend deleting the entire old “All-in-One” folder and then re-entering your wallet seed.
Before doing so, make sure to save your current seed and copy out any custom configurations, such as mining or node settings.
Alternatively, you can overwrite the old folder, which preserves your existing data. However, because of the new wallet database system and possible cache-related issues, I recommend replacing the “All-in-One” folder completely.
Also: the Stratum Bridge and mining software do not require an update.
Pools also do not need an update, except that the node itself must be replaced.
Please note: we have activated the autoban system on the seed server. Anyone still running the wrong node at the hard fork will be automatically banned.
Here is the timer:
https://cryptix-network.org/cryptix-atomic-hardfork
Important note about the Go Node:
The Go Node does not support creating new Atomic transactions.
It can only be used for normal transactions and mining.
It does not include the RPC extensions for Atomic.
It works for pools, but it still uses the Atomic Storage System v1, which may cause high RAM usage later when larger amounts of Atomic data exist.
We may extend the Go Node to the Storage v2 system and add the RPC interfaces in the future, but this is currently not on the todo list.
Those were the final updates. Everything is now complete.
Don’t forget: you need to replace the All-in-One software, nodes, and wallets before the hard fork.
https://bitcointalk.org/index.php?topic=5585366.0
Hey everyone, I’ve posted some release info for Atomic here on BitcoinTalk. Please give it a good boost with comments and share it on Twitter, etc.
I think it covers the key points for new users.
The wallet system includes a new feature that allows outgoing transactions to be blocked for 24 hours. A "panic setting" already existed to destroy all data; this new feature offers a middle ground, enabling the wallet to be locked locally on the device for 24 hours in the event of security concerns.
We are preparing our frontend for the hard fork:
The Token Explorer demo mode has been disabled; demo data will no longer be available until the release.
All "coming soon" markers are being removed from the website.
The roadmap is being updated.
The text "Note: Tokens/Messenger are currently not active on mainnet yet" is being removed from the web wallet.
Please note, however, that these features will only become active upon the hard fork in approximately five days ( https://cryptix-network.org/cryptix-atomic-hardfork ). We are making these changes to the text and functionality now to ensure a smooth transition.
Regarding the Community Token:
Since there were no real proposals, we will use this:
Cryptix Community Token (CXT)
As previously mentioned: Creator fee 0%
Curve determined by vote: Aggressive
Regarding the Hardfork:
Starting with the Hardfork, we will run a community event for approximately 3 days.
In the general group chat within the Messenger (Messenger tab), random users will receive CPAY tips at random times and in varying amounts. To participate, you simply need to be visible in the chat by posting a message. This gives you a chance to receive free CPAY.
In the token's group chat (Community Token), there will also be token airdrops. The requirement is the same: simply post a message so you are visible in the chat. Random users will receive random amounts at random times.
Participation is completely free and voluntary. While sending a message in the Messenger requires a transaction, the cost is only the standard mining fee, which is extremely low. Less than 0.0005 CPAY is sufficient for a message.
Users who do not have any CPAY can claim free coins from the Faucet. We will refill the Faucet for several days after the Hardfork so that new users can obtain free CPAY and test the ecosystem.
With the 3 CPAY available daily from the Faucet, users can:
Send many messages in public and token chats.
Test transactions.
Test buying and selling.
Create up to 2 tokens.
Regarding Tokens:
We will extensively test the system by using the Community Token and performing a large number of buy and sell operations. At the same time, we will also trade random user-created tokens.
The goal is to stress-test the Mainnet immediately after release, identify potential issues under real-world conditions, and ensure the system is battle-tested from day one.
New Discord Channel: 🎞・atomic-token
A new Discord channel called #atomic-token is now available. If you create a token, you can post its image, token ID, or other relevant information there.
Please do this responsibly and ethically.
The following is not allowed and will be removed:
Offensive, racist, discriminatory, or otherwise inappropriate token names or metadata. (The wallet already includes a bad-word filter, which will be expanded further before release.)
Profit promises or unethical promotion such as "10000x Token", "Guaranteed Profit", or similar claims.
Spam (post your token only 1x)
If you share your token, please present it in a neutral manner. If it serves a community, project, idea, or has a specific utility, feel free to explain its purpose and use case instead of focusing on price speculation.
Tokens are automatically listed in the Token Explorer: https://token.cryptix-network.org/
Tokens appear there automatically within 60 seconds of being newly created. There is intentionally no sorting by volume, value, or the like; the list is sorted by recency. The newest tokens appear at the top, as the aim is to provide a neutral explorer.
Exbitron appears to be shutting down — I just saw it.
https://app.exbitron.com/
If you have coins there, you can still log in and withdraw them. But you should do it as soon as possible.
Now, what can I say? It is damn sad. Exbitron supported us back then when MecaCex betrayed us. During our release phase, Exbitron was a real rescue for us.
Eskal told me several times about the problems, including that the server costs were becoming overwhelming and that Exbitron as a platform no longer really made sense because the support was missing. I also had no solution for him.
Exbitron really had a lot of bad luck and faced many attacks. And they simply did not have enough support.
Because of that, it was probably already clear that this day would come eventually. I think it is sad.
It will become harder for small new projects. It will create more centralization. It will give the bigger exchanges even more power.
But this is exactly the point I keep repeating:
Support small things, otherwise they will not survive.
Whether it is exchanges, listing sites, pools, or cryptocurrencies — support them.
Things that are worth supporting should actually be supported. Otherwise, they all end up disappearing into nothing.
Crypto is going through a hard time, especially now, with the current scam season — and yes, we really are in one.
So:
It is sad to see Exbitron go. The crypto world will miss it.
-
And I call on you, the users, to finally support smaller exchanges.
Who lists the new coins you mine (often even free of charge)? It’s the small exchanges. Not Binance. Not MEXC.
What are you going to mine when there are no small exchanges left to list your mining coins?
Support small exchanges, even if you pay 1–2 dollars more.
If we don’t support them, they won’t survive. And if they disappear, new mining projects will suffer too.
Support what supports you and your World.
If you still have CPAY on Exbitron, send it out. Exbitron is shutting down completely soon. Also, the hard fork is in five days, and I don't think Exbitron will be updating the nodes. That means once the hard fork happens, you won't be able to withdraw your coins from Exbitron anymore. We have already removed Exbitron from the website, dashboard, marketserver, etc.
Cryptix Atomic Hardfork Announcement
It is time: Cryptix Atomic is coming on DAA 33,739,200.
The official DAA for the hardfork has now been announced, and a new page has been added to the website with a countdown, exact date, and time information.
https://cryptix-network.org/cryptix-atomic-hardfork
Important:
You must replace your Go nodes and Rust nodes within the next few days, before the hardfork.
There is nothing complicated to do. Simply delete the old binaries and replace them with the latest ones. Alternatively, rebuild the binaries from the latest source code.
The nodes must be updated before the hardfork. If you continue using an old node, you will no longer be connected after the hardfork. Also, the new seed-node autoban system may automatically ban outdated nodes after several failed connection attempts.
New Go node code:
https://github.com/cryptix-network/cryptixd/releases/tag/v0.17.1
New Rust node code:
https://github.com/cryptix-network/rusty-cryptix/releases/tag/v0.17.1
The Go node continues to work for standard mining and transactions. The Rust node is required for full Atomic support.
Ready-to-use executables / binaries will be released within the next few hours. The new All-in-One software will also be released (tomorow).
Mining software does not need to be replaced. Only the node / wallet software must be updated.
In group chats—whether private, public, or token-gated—it will be possible to send a tip to a user. This tip will then be displayed within the chat.
This is a useful feature for community group chats as well as for verified OTC.
With private messages, coins are already sent directly along with the message; this functionality is now available for group chats as well
And Fully decentralized L1 airdrops are now possible, too—simply via the token group chat.
The Cryptix Messenger will be expanded with decentralized chat room and group chat functionality. All chat rooms are powered by the on-chain Cryptix Messenger technology and work fully decentralized, without any server infrastructure, L2 indexer, or similar centralized components.
Messages in these chat rooms do not require the 0.25 CPAY transaction fee. Only the small regular transaction fee applies. This makes decentralized communication possible directly on-chain, with messages becoming globally visible in less than one second.
There will be three different types of chat rooms:
1. Atomic Token Chat Rooms
When an Atomic Token is created, it will automatically receive its own token chat room.
In this chat room, every user can write messages using their wallet. This enables direct decentralized communication around a specific token, without relying on external platforms, servers, or indexers.
2. Public Group Chats
Public group chats will also be introduced, such as a public, unencrypted chat room for the Cryptix community.
Everyone will be able to participate and read messages if they want to, directly through the web wallet. This enables censorship-resistant and decentralized communication for the community.
3. Private Group Chats
In addition, we are currently working on a feature that will allow the Messenger to support private group chats directly.
These private group chats will not be end-to-end encrypted, since there are multiple participants in a group chat and the participants may change over time. Instead, private group chats will be created individually, and a password can be set.
Only users with this password will be able to send, decrypt, and read messages.
The password is defined once when the chat room is created. After that, the creator receives a QR code or chat room ID, which other users can use to join. If they have the correct password set by the creator of the chat room, they can participate and read the messages.
This means the chat room is encrypted using the chosen password. The password is only required once when entering the chat room and does not need to be entered again afterward.
Let’s talk about new things that are currently being discussed for the next hard fork — not the upcoming one:
Mining Atomic Tokens
Create your own tokens with a single click, which can then be mined using SHA3, BLAKE3, or our native OX8 hash. Native L1 tokens that can be mined would be something entirely new. Potentially, they could also be tradable via Atomic Swaps.
Mining / PoW Atomic NFTs
Unfortunately, NFTs have largely died since the rise of AI. AI can generate and spam NFTs every second, which has turned digital art into spam. At the same time, it has become almost completely worthless, with prices falling into nothingness. That is very unfortunate, because digital art does have a legitimate reason to exist.
That is why we want to enable native L1 NFTs that can only be minted through computational power, where the difficulty and requirements help support their value. We could give NFTs a unique ID / mining hash and store it, proving that the generation was backed by real computational work within the chain.
NID Atomic NFTs
This technology already exists in the Member Area and allows digital images to simultaneously serve as encryption. We want to integrate this technology into the blockchain for real utility.
Atomic NFT Swaps
NFTs should be directly tradable in a decentralized way through our Swap / DEX programming on L1.
Staking
There is still some uncertainty here as to whether we should offer simple staking, for example with 10% of the block reward, or move toward a PoS + PoW system with a 50/50 distribution in order to additionally secure the network through staking.
Stealth / Anonymous Transactions
We have already presented this system before, where we want to offer stealth addresses by allowing SPAY and CPAY to exist separately within the same chain. SPAY can only be created through the use of CPAY.
Zero-Knowledge / ZK Functions
Several approaches for meaningful zero-knowledge usage within the blockchain are being evaluated, especially in relation to the stealth systems. ZK functions could play an important role in improving privacy, verification, and usability without exposing unnecessary information on-chain.
While zero-knowledge technology is often seen as highly complex, we believe that certain targeted use cases can be integrated in a practical and efficient way, especially when the scope is clearly defined. This area will therefore continue to be researched carefully as part of the broader privacy and stealth transaction roadmap.
Quantum Security
Quantum-safe signatures are costly in terms of performance and bandwidth. Even though it is not yet necessary to upgrade, because there is no immediate threat, we should begin making initial plans and implementations for this.
However, this is an unpleasant topic because of the transition phase with wallet systems. Again, the difficulty is not the implementation itself, but the transition phase. A blockchain has to support both the old and the new system for a certain period of time. That involves a lot of fine-tuning and is unpleasant.
In addition, the increased bandwidth per signature is indeed a problem. However, with our one-second block time and our current bandwidth, including a lot of reserve capacity, we do not see this as problematic for us. Other cryptocurrencies, however, may face serious issues here.
P.S.: A long block time does not protect against quantum attacks. Once the public key is known, the wallet can be cracked within minutes or even seconds. A long block time would only protect against mempool attacks — and even that would no longer be true if quantum computers scale or achieve lucky hits.
HFB
Our HF system is ultimately intended to become the fastest transaction system in the world, where only global latency and hardware determine the speed.
With the earlier release of HFA, we already achieved the fastest transaction visibility. With HFB, we already have the fastest transaction pre-execution. HFB is the advanced mempool and pre-construction system, where transactions create a chain even though they have not yet been executed.
Atomic Swaps will use this system in the upcoming hard fork, and that will serve as the mainnet test before we apply it to all transactions. The final step will then be HFC, which will enable extremely fast confirmations — completely without block spam and centralization.
On-Chain Alias System
The alias system is intended to be moved on-chain through a native L1 function.
Important note:
These are things on our research list. Some have not yet been explored in great depth, while others already have a complete technical integration plan. In any case, these are topics that have been looked at more deeply, but they are not promises yet.
After the release of Atomic Tokens, Atomic Swaps, and the Messenger, we want to continue working on these areas. There will also be a stronger focus on the web wallet / native hosted wallet and all-in-one software.
With every hard fork, Cryptix will move more and more toward becoming its own economic system. The Messenger and Atomic Tokens / Swaps are the foundation for doing more than simple transactions. The blockchain should offer a home for everything — whether mining, transactions, communication, DeFi, or other things.
And everything must be native L1. There must never be a need for an L2 indexer or a server. The most important areas must also work without them.
L2, whether partial or complete, is not a solution for crypto. If crypto requires L2, then crypto has no added value. It becomes the same as centralized banking systems, which would make crypto essentially useless — while banking systems are at least regulated and may even be safer or run by more ethical people.
So L2 is not an option for anything in crypto — without compromise. Anyone who builds technology in a way that requires L2 has not understood the origin and purpose of crypto.
Let’s talk about Real World Assets, or RWA.
RWA connect real-world value with digital tokens. These can be assets such as real estate, company shares, commodities, machines, inventory, or other valuable goods. The basic idea is simple: a real asset from the physical world is represented digitally, making it easier to manage, transfer, and use.
A good example is real estate. Imagine a building with 10 apartments, and each apartment is divided into 10 digital shares. That would create 100 digital RWA shares in total. Each share can represent a defined value or claim, for example based on rental income, sale proceeds, or participation in the asset.
The major advantage is digital transferability. If someone owns a share, they can technically send or transfer it with ease. The blockchain transparently shows which token belongs to which address. This creates new possibilities for digital ownership records, faster transfers, and more efficient markets.
RWA make real-world value more flexible. Assets that were previously difficult to divide or trade can be split into smaller digital units. This could give more people access to asset classes that were often only available to larger investors. At the same time, processes such as administration, proof of ownership, and transfer can become much more efficient.
Until now, however, implementing RWA has often been complex. Many projects tried to represent every asset through individual smart contracts. This created many separate solutions, each with its own logic, review requirements, and technical complexity. This is exactly where Atomic takes a different approach.
Atomic does things differently.
With Atomic Tokens, there is no need for individual smart contracts for basic token functions. The most important functions, such as mint, burn, and transfer, are possible through a unified native token logic. This makes creating and using tokens simpler, clearer, and more robust.
All Atomic Tokens follow the same basic rules. This means that a new contract logic does not need to be developed, reviewed, and understood for every single asset. Complexity is reduced, and a unified foundation for digital assets is created.
Another important point is the deterministic data state. Atomic data is directly integrated into the chain logic. Nodes follow the same rules and validate the same data. If a node accepted invalid or conflicting data, it would no longer be able to correctly follow the valid chain state. This creates a clear, unified, and verifiable state across the network.
For RWA, this is especially interesting. Real-world assets need a digital representation that is simple, transparent, and reliable. Atomic can provide exactly this technical foundation: native tokens, clear rules, and unified data logic without unnecessary smart contract complexity.
This opens up many possibilities. Real estate shares, company shares, commodities, or other real-world values could be represented as Atomic Tokens. Ownership structures can be displayed transparently, transfers can happen faster, and the management of digital shares can become much more efficient.
Future liquidity is also an exciting aspect. RWA could later be connected with swap systems. This could create markets for tokenized real-world assets, where shares can be traded and exchanged more easily. With a still-small market capitalization, this may be more of a future use case for now, but technically the direction is very interesting.
The strength of Atomic is that it can make RWA simpler and more accessible. Instead of requiring separate smart contracts and custom technical solutions for every asset, Atomic provides a native token infrastructure with clear functions and unified logic.
This means Atomic can make an important contribution to making Real World Assets more practical. Real-world value can be represented digitally, transferred more easily, and used more efficiently. That is the potential: Atomic connects real-world assets with a clear, simple, and robust token structure.
RWA have long been a strong idea with difficult implementation. Atomic can simplify that implementation and give the concept a new foundation: real value, digital shares, native token logic, and a transparent state directly within the protocol.
Atomic is fully decentralized — even if third-party launchpads emerge.
Atomic Tokens & Swaps are not tied to a single website or platform. Every Atomic token can be traded through the local wallet or web wallet, no matter where it was created.
That means:
No centralized website can block trading.
External launchpads are optional.
Users can trade locally, directly from their wallet.
The real state comes from L1/node data, not from a platform database.
Even if one website goes offline, trading can continue.
Launchpads may compete on UX, charts, tools, branding and community — but they all share the same open L1 market.
A platform may filter tokens by its own platform tag, but the token itself remains open. Users can copy the asset ID, add it to the wallet in a few clicks, and trade it directly.
Atomic is not just a website.
Atomic is open L1 trading infrastructure.
Atomic Swap Tokens can also be freely sent from wallet to wallet. They are not locked inside a specific platform and can be used freely across the ecosystem.
They can also be integrated by exchanges, since a dedicated wallet daemon and WASM module are available for listing and infrastructure support.
Atomic token trades in 100 ms within a fully decentralized system.
This was a live test on the testnet using a server with a 50 ms ping. With a local wallet, execution can be even faster.
The measurement was taken in the web wallet from the moment the Sell button was pressed until the transaction was submitted through the nonce mechanism and confirmed. In other words, this reflects the actual user experience people can expect after release.
Who is faster in a native Layer-1 consensus-based token system without indexers, Layer-2 solutions, or centralized servers?
This is exactly why we focus on lean, framework-free frontend engineering and direct performance optimization instead of relying on unnecessary abstractions. By keeping the implementation close to the runtime, we maintain full control over latency, bandwidth usage, bundle size, transaction flow, wallet interaction, and UI responsiveness.
This level of efficiency comes from disciplined engineering: minimal dependencies, optimized network handling, efficient nonce management, lightweight code paths, and careful control over every performance-critical operation. No TypeScript or anything like that—pure Vanilla JavaScript.
Let’s talk about payloads, on-chain data, and decentralization.
One of the most important design questions in any blockchain system is how to choose safe limits for payloads, token data, smart contract data, and transaction data. If these limits are chosen incorrectly, they can create serious decentralization pressure and may lead to long-term structural problems.
The core issue is simple:
on-chain data volume × BPS × relay traffic
In other words: data is not only added to blocks. It also has to be received, validated, stored, indexed, and relayed through P2P connections to other nodes.
Let’s take a simple example.
Assume a network produces around 2.5 MB of block data per second. This could happen, for example, with 10 BPS and 250 KB per block, or with 1 BPS and 2.5 MB per block.
For a normal node with around default outpeers = 8, under sustained full load, a realistic bandwidth budget could look roughly like this:
Per second:
Download: around 3–5 MB/s
Upload: around 2–6 MB/s
Total: around 5–11 MB/s
Per day:
Download: around 260–430 GB/day
Upload: around 170–520 GB/day
Total: around 430 GB to 0.95 TB/day
These numbers are estimates, not exact protocol constants. But they show the magnitude of the problem.
When bandwidth, storage, disk IO, and CPU requirements increase too much, smaller home nodes will have a harder time keeping up. Over time, this can push the network toward larger operators, VPS providers, and data centers.
At that point, running a node may no longer be economically reasonable for ordinary users. If a node consumes a large part of a home internet connection, or if the connection is not sufficient in the first place, many users will simply stop running nodes. Hardware costs, electricity costs, storage requirements, and bandwidth limits all become part of the centralization pressure.
This is a potentially serious decentralization risk.
At some point, the system may start moving away from “everyone can independently verify and participate” toward a high-end server network, where only people with the right infrastructure, bandwidth, and budget can realistically operate full nodes.
Yes, high fees can limit abuse to some degree. They can help against targeted payload spam or payload-based DDoS attacks. But fees do not fully protect against genuine demand.
If many real users want to use the system, full blocks can still happen. Users may still pay high fees if the application is valuable enough. We saw this on Ethereum, where users paid extremely high fees because demand was high.
So the question is not only: “Can fees prevent spam?”
The bigger question is:
What happens if the allowed limits are actually used?
Protocol design must consider the worst case, not only the best case. If a system allows a certain amount of on-chain data, then that amount must be treated as possible. The network should remain healthy even when the available capacity is used, not only when usage stays low.
This is how we approached the design in Cryptix for Atomic.
Currently, in Atomic, a transaction can contain around 2 KB of payload, which is roughly 1.6 KB of usable payload after transaction overhead. At the same time, the maximum block mass is 500,000, and the network runs at 1 BPS.
Under sustained full load, a normal node with around 8 outpeers would be expected to handle roughly:
Per second: around 0.3–2.0 MB/s total traffic
Per day: around 26–173 GB/day total traffic, depending on relay behavior, overhead, and real network conditions.
This is still real load, but it is much more realistic for ordinary hardware and weaker internet connections.
In addition, we introduced a new Virtual Lag technology. This allows lazy loading and supports slower nodes or nodes that temporarily fall behind. The goal is to make Atomic much more forgiving for low-end environments.
Cryptix is designed so that Atomic can work with slow internet, a 2-core CPU, low RAM, and weak storage such as SD cards. This does not mean every possible device will perform equally well under all conditions, but the design goal is clear: the system should remain accessible to ordinary users, not only high-end server operators.
Bandwidth is also not the only issue.
You also have to consider read and write operations. Even 2.5 MB/s of pure block data can become heavy when it passes through validation, storage, indexing, database writes, cache layers, and relay logic. Even with batching, this is serious work.
CPU load also matters. Data usually has a purpose. It may need to be validated, interpreted, executed, hashed, indexed, or proven. So beyond bandwidth, storage IO and CPU requirements can become even more dangerous.
Another crucial point is forward-looking thinking: in the near future, many systems will need to be migrated to quantum-secure standards — for instance, requiring quantum-secure digital signatures or similar technologies. Unlike current methods, these will demand vastly greater data volumes. Furthermore, implementing quantum-secure hardware is expensive. Any organization that is already scaling its infrastructure to its absolute limit today has likely overlooked the future and failed to take these factors into account.
This is why we intentionally designed Atomic conservatively. We want to avoid repeating mistakes that earlier systems already made. Decentralization is not only a slogan. It has to be protected at the parameter level.
After mainnet, we may increase certain limits in a future hardfork, but only based on real mainnet data and real observed performance. If capacity is increased, it should be done with lane limits and intelligent resource separation, not by blindly increasing global limits for every type of data.
The goal is simple:
More capacity, but not at the cost of decentralization.
A blockchain should not become a system where only data centers can participate. Ordinary users must still be able to independently verify, run nodes, and take part in the network.
Smart Contracts, Native Assets, and What These Terms Actually Mean
Let’s talk about smart contracts, native assets, and related terms.
In the crypto world, these words are often used very loosely. Sometimes this happens because of misunderstanding, and sometimes it is done deliberately for marketing. As a result, many users end up with the wrong technical impression.
1. What are full smart contracts?
Not every programmable transaction and not every programmable UTXO model is automatically a full smart-contract system.
Programmable UTXOs, scripts, or transaction conditions can contain smart-contract-like logic. But that does not automatically make them what many people technically mean when they talk about a full smart-contract platform.
A real smart-contract system is not only about executing code. It also needs a consensus-relevant data and state system. In other words, it needs a state that nodes can understand, validate, store, sync, and process in a reproducible way.
Put simply: programmable execution alone is not yet a complete smart-contract system. Programmable execution together with a native, consensus-relevant state and storage system comes much closer to what is technically understood as full smart contracts.
2. Where is the real work in smart contracts?
Many people think the hard part is executing the code. But in most cases, that is not the main challenge.
The truly complex part is the data and storage system behind it: deterministic execution, persistent state, pruning, syncing, replay, reorg behavior, data availability, state growth, performance, protection against abuse and DoS, and long-term scalability.
A simple VM or script execution layer can be built relatively quickly by a good team. A robust, secure, and scalable state and storage system is a completely different level of complexity.
That is where the real work is.
3. Can you avoid having a native storage system?
Technically, yes.
But then you often lose exactly what blockchains are supposed to be strong at: decentralization, security, and a trust-minimized user experience.
If a system does not have native, consensus-relevant state or its own data model, it usually needs external infrastructure in practice. This can include indexers, servers, archive nodes, L2 systems, offchain data sources, or centralized APIs.
So yes, execution may theoretically happen on L1. But if practical usability still depends on external infrastructure, then one has to be honest about it.
If a user cannot meaningfully reconstruct or use the relevant state without external indexers, archive servers, or offchain dependencies, then it is not a fully native smart-contract experience.
It may be a fast solution. But that does not automatically make it professional or decentralized.
4. What does “native” really mean?
“Native” should not simply mean: “It somehow runs on L1.”
Technically, native means that the protocol or the ledger understands the function itself.
If something is only represented through a smart contract, it is not automatically a native asset or a native function. It is a smart-contract-based solution.
That can still be useful. But technically, it is not the same thing.
5. Native tokens vs. smart-contract tokens
This is where a lot of confusion happens.
A smart-contract token is a token whose logic and balances are managed by a smart contract. The ledger primarily knows the contract and its storage.
A native token, on the other hand, is directly part of the ledger or protocol model. The system understands these assets itself and does not treat them merely as entries inside a contract state.
Important: native tokens do not mean that every single token has to be hardcoded into the node software. What matters is whether the asset system itself is natively supported by the ledger.
If tokens are only created and managed through smart contracts, they are smart-contract tokens — not native tokens.
The important distinction
We should clearly separate programmable transaction logic, full smart contracts with state and storage, native ledger assets, smart-contract-based assets, and external indexers or offchain dependencies.
In marketing, these terms are often mixed together.
Programmable UTXOs suddenly become “smart contracts.” Smart-contract tokens suddenly become “native tokens.” L1 execution suddenly becomes a supposedly fully native solution, even though external indexers or offchain systems are required in practice.
This is exactly where people should stay critical.
My point
Do not let yourself be blinded by terminology.
When a project talks about “native tokens,” “native NFTs,” “native messengers,” or “smart contracts,” you should check what actually exists in the protocol and in the node code.
The key questions are: Does the ledger have a native asset model? Is there consensus-relevant state? Is there a real storage system? Can nodes validate and reproduce the state themselves? Is the system meaningfully usable without trusted external indexers? Or does practical usage depend on servers, APIs, archive nodes, or offchain systems?
Marketing can claim many things.
Code lies less.
So do not only pay attention to the words. Check what has actually been implemented technically.
Covenant-based L1 programming and infrastructure for future verifiable programs are not the same thing as full-fledged native smart contracts, native tokens, and native NFTs—such as a global smart contract platform. And smart contract-based tokens are not native tokens. Any reputable developer would agree with this
The developer information for Atomic and the Messenger is now on GitHub:
https://github.com/cryptix-network/rusty-cryptix/blob/main/docs/messenger/README.md
https://github.com/cryptix-network/rusty-cryptix/blob/main/indexes/atomicindex/README.md
https://github.com/cryptix-network/rusty-cryptix/blob/main/indexes/atomicindex/TRADING_FLOW.md
If you use the messenger through the web wallet, there will be automatic security modules in place.
If a user tries to send you harmful content such as script injections, iFrames, code, or anything else intended to track you or trigger malicious execution, the wallet will automatically detect and block it immediately. This will also be visible in the message through a [blocked-html] tag, so you can see that someone attempted it. We have blocked a long list of potentially harmful methods.
However, I still recommend using the messenger whitelist function to block messages from unknown users directly. There is never 100% security. For large wallets, it is best to completely disable the messenger / payload functions in the settings. This way, you will not receive any messages or data from other users in the first place.
I would separate the main coin wallet, especially if it holds larger amounts, from the messenger wallet. You can create and connect multiple wallets for this purpose.
That said, the protection against these kinds of attacks is strong. At release, only emojis and URLs, which will be linked directly to external pages, will work. Everything else will be filtered out, including:
HTML/script tags such as script, iframe, object, embed, svg, math, style, link, meta, img, video, audio, form, input, button, and base.
Event handlers such as onerror=, onclick=, and onload=
Dangerous protocols such as javascript:, vbscript:, and data:
Obfuscation through HTML entities, JS escapes, fullwidth characters, and hex/decimal byte runs.
Control characters and excessively long content.
Viruses/files currently cannot be delivered through the messenger as executable attachments, because the messenger only processes text/payload bytes and does not render anything as a file, image, or HTML.
However, always be careful with social engineering. A user could try to pressure you into taking actions that are harmful. And NEVER use the browser console to paste commands or code if you do not understand exactly what you are doing.
Current Status: The stress tests and lag tests have passed—even after many days and hundreds of thousands of transactions. The mempool tests are also complete, and the final optimizations have been implemented.
All that remains now is to harden the reorg logic and conduct the UTXO pruning resync/sync tests (Token Pruning Tests are done); after that, we will be ready to release the hard fork.
You can now create Paper Wallets / Reserve Wallets directly on your local computer via this webpage section. Afterward, you can download the data as a PDF or PNG file - or print directly. It utilizes the new seed system and supports 12- and 24-word seeds.
https://cryptix-network.org/paper-wallet
Strengthening BlockDAG Consensus for State-Commitment Systems
During recent Cryptix Atomic testing, we identified and fixed an architectural limitation in the original BlockDAG consensus integration.
The issue was not that BlockDAG parallelism is flawed. Parallel blocks, multiple tips, red/blue ordering, delayed validation, merge behavior, and side branches remain core strengths of a BlockDAG design.
The limitation was more specific:
The original BlockDAG architecture was sufficient for basic DAG ordering, but not strong enough for advanced state-commitment systems.
Cryptix Atomic requires block headers to commit not only to the UTXO state, but also to Atomic token state:
commitment = H(UTXO state, Atomic state)
That changes the requirements.
A known DAG tip is not automatically a valid virtual-state candidate.
A pending block is not automatically safe for mining-template construction.
A red block is not the same as an invalid block.
And a consensus-disqualified block must never influence future virtual state.
The edge case was that, in the previous model, a disqualified block could still remain part of the virtual/mining tip set. Even if it was not selected as the selected parent, it could still influence the local virtual view used by miners to build new block templates.
With extended state commitments, this is dangerous. Two honest nodes can share the same DAG topology but compute different future state commitments if one includes a disqualified tip and the other excludes it. That can cause honest miners to create blocks that look valid locally but are rejected by the rest of the network.
We fixed this by separating known DAG topology from virtual-state eligibility.
A block can still remain known in the DAG for topology, diagnostics, and history. But once consensus marks it as disqualified, it is removed from anything that can shape future virtual state or mining templates.
This does not weaken BlockDAG.
It does not remove normal parallel tips.
It does not treat red blocks as invalid.
It does not discard valid side branches.
It only removes one unsafe assumption:
known tip ≠ valid virtual-state candidate
This rule is now enforced in both implementations:
• Rust nodes prune disqualified blocks from body tips
• Go nodes prune disqualified blocks from consensus tips
• Both skip disqualified blocks during virtual-parent selection
• Locally mined/submitted blocks are validated through virtual processing before relay
• Atomic replay, nonce conflicts, parallel blocks, and reorg behavior are covered by regression tests
The broader lesson:
Classic BlockDAG consensus is powerful for parallel block ordering. But once you add committed application state, token logic, or smart-state layers, the consensus engine must know not only which blocks exist, but also which blocks are allowed to influence the next virtual state.
The underlying BlockDAG code was not originally designed for proper native data handling such as tokens or true smart-contract-style state. With Cryptix Atomic, we resolved this limitation and adapted the BlockDAG integration accordingly.
BlockDAG remains the right direction — but for advanced state systems, the old model was too limited. This upgrade closes that gap.
1. Messenger
The decentralized, L1-native Cryptix Messenger (encrypted) will be activated and will be fully usable from that moment on.
2. Free Payloads
Free payloads can be attached to transactions, currently with a limit of 2 KB per transaction. Please note that with payloads, a higher fee per byte is paid to miners. This enables free off-chain technologies that are connected through L1 transactions.
3. Transactions with simple Data
Transactions with a subject, invoice number, or similar information will be possible. Note: Not encrypted.
4. Atomic Tokens
The decentralized, native L1 tokens will be activated. Anyone will be able to create a token via the Webwallet or CLI Wallet without smart contracts or technical knowledge. Optionally, this can also be done with the Atomic Swap system.
5. Atomic Swaps
The decentralized, native L1 swap system for tokens will also be activated. This allows tokens to be traded in a decentralized way against CPAY. Optionally, this can also be done with a Lock Gate.
6. Block Header and Sync System
It will be possible to sync data without external indexers. You could describe it as an L1 indexer for off-chain systems.
7. Autoban System
Nodes can activate an autoban system. This system bans malicious nodes or attacks against the blockchain, such as reconnect spam, dust attacks, or DDoS attacks.
8. Strong Node ID System
When starting, nodes must generate a unique PoW-based Node ID, which they use to identify themselves to other nodes and to sign blocks when they are forwarded via P2P.
Blocks without a valid signature will be rejected by other nodes.
In addition, there will be a new RPC interface that allows the last 1,000 block finders with their Node ID to be viewed. This will also be visible in the dashboard. This makes it possible to detect 51% attacks and strong node dominance.
Nodes will not be able to connect to other nodes without a valid Node ID. Nodes verify whether the ID is valid and whether the required difficulty has been reached.
In case of abuse, the autoban system bans both the Node ID and the IP address. This makes attacks very expensive.
9. Quantum-Safe Handshakes
Handshakes and connections will be quantum-safe using ML-KEM-1024. This is not the most relevant change, but since we changed the protocol anyway, we integrated it directly.
10. Antifraud System
We will have the option to block nodes from mining in cases of possible 51% attacks that are decided by the community, and to ban their ID and IP address.
After the recent incidents involving the attacker who worked together with Rplant and took over 90% of the network, this is necessary until we have a larger network with more miners.
The system can be completely disabled flexibly as soon as we have more miners and more hashrate.
The related data is delivered by the seed and is secured and signed with a private key. The system is connected to the official community-led Antifraud System, and only entries there have an effect.
Every case will be voted on by the community, and every user can submit a case. The system is only relevant for mining attacks.
The Rplant pool will be completely excluded starting from the hardfork because of the previous incidents. Therefore, I recommend switching pools soon.
Additional Notes
There are many other smaller changes, such as fixes for issues in the old WASM and various extensions, but the points above are the most important ones.
1. What needs to be replaced?
Nodes / Daemons
Nodes or daemons need to be replaced with either the Rust Node or the Go Node. Otherwise, participation in the network will no longer be possible after the hardfork.
Rust Node:
The Rust Node is recommended because it includes Atomic Storage Version 2. This storage system has significantly lower RAM usage and is strongly optimized for maximum load as well as large state data in the future. It is designed to handle hundreds of gigabytes of states. In addition, it includes auto-repair functions and deeper replay capabilities, up to the Atomic Genesis for archive nodes.
Go Node:
The Go Node will continue to work for mining, receiving transactions, and sending transactions. However, it will not be possible to use extended features such as Messenger, payloads, or tokens. The Go Node is only integrated for syncing and mining. It uses Atomic Storage Version 1, which means higher RAM usage.
Mining Software / Stratum Bridge / Pools
Mining software, the Stratum Bridge, and pools do not need to be replaced. The old files will remain valid.
Wallets
Webwallet
Webwallet 1:
The Webwallet will most likely need to be reinstalled as a PWA app, because devices often do not replace cached files properly, even when cache-buster files are used.
When using the Webwallet in the browser, a CTRL hard refresh should be performed. After that, the transaction history should be deleted using the button available in the settings. The best option, however, is to simply delete the browser data and log in again. Please make sure to back up the seed before doing this.
Webwallet 2:
Webwallet 2 will continue to work, and clearing data is normally not required. However, it will not provide Messenger, token transactions, or payload functionality. It will only support normal sending and receiving of transactions.
Browser Extension, Desktop Wallet, CLI Wallet
The browser extension, desktop wallet, and CLI wallet must be replaced.
CLI Wallet Rust:
The Rust CLI Wallet provides the full token and payload functionality. It also includes a wallet daemon listener for tokens, which can be used by exchanges, for example. In addition, it now provides a general daemon service for normal transactions.
CLI Wallet Go:
The Go CLI Wallet will continue to support normal transactions, but the new features will not be available.
Android PWA App Wallet:
The Android PWA App Wallet should be deleted and reinstalled if data is cached. This depends on the device, but I recommend doing it.
Android App Wallet:
The Android App Wallet does not need to be replaced for now, but it still needs to be tested. For the time being, it will not offer deeper functionality for Messenger and tokens. This is planned for later, although it is currently unclear whether we will integrate token functionality into the existing app or start directly with a completely new app.
The Android app has several bugs and architectural issues. For example, when coins are sent from another wallet, such as the Webwallet, and the Android app is opened afterwards, it no longer finds the current UTXOs. This is because the UTXO scan / address scan during resync is missing, or rather, there is no real resync behavior at all.
This is similar to the Explorer and the old Webwallet. At some point, it no longer makes sense to continue building on that foundation, because it needs to be programmed professionally from the ground up. The current Android Wallet does not provide a good foundation for this. However, this is a lot of work, so it is still questionable whether we will first integrate tokens into the current app or directly rebuild it from scratch.
At the moment, I recommend installing the Webwallet as a PWA app. It is much more robust and offers more functionality. We have also optimized it more strongly for responsive usage in the latest changes.
What is the current status?
We have tested the Go Node and Rust Node for syncing, the hardfork transition, resyncing, Atomic Replay, mining, cross-node mining, the mempool, HFA, Messenger, and payloads. We have also performed simple stress tests with several global nodes, as well as global stress tests for token swaps.
What is still missing?
The Atomic pruning sync test is still missing and will take place tomorrow. General pruning tests for IDB will take place the day after tomorrow. After that, the final stress tests will be performed, where we will push the blockchain to its limits. These will take place after the last pruning tests.
Overall, we are actually very close to the end. We developed a new storage system for Rust because the old one required too much RAM over longer periods of time. With the new system, every node can continue to participate, even with low RAM. In addition, we can now handle very large token data. This was originally planned for the next hardfork, but it is better to include it now rather than too late.
Anyone who wants to review the new storage system can find it here. Improvement suggestions are welcome:
https://github.com/cryptix-network/rusty-cryptix/blob/main/indexes/atomicindex/src/storage_v2.rs
We just completed testing of the latest changes in the Webwallet and Rust Node.
Over the last few days, we implemented several major improvements:
- Token swap transactions can no longer be replaced or overwritten through higher priority fees — not even from other nodes, not just on the same node
- Parallelization and scaling across different tokens and swap pools
- Parallel submission of transactions for the same token / swap
- The Webwallet can display both the mempool and futures
- The Webwallet can seamlessly build ahead based on current mempool transactions
- The Webwallet now displays values directly based on mempool activity
These changes significantly increased protection against bots and transaction snipers, while also massively improving scalability. No matter how many users are trading, transactions will still be properly queued even during completely full blocks. The user barely notices the blockchain itself — swaps react within milliseconds to changing values.
This pushed the hardfork timeline back by a few days, but it was absolutely worth it. Especially the parallel submission of swaps is a huge breakthrough. This is exactly the area where smart contract based technologies usually start throwing errors, determinism breaks, transactions fail, or funds get stuck. Those types of issues simply cannot happen in our architecture because we control the mempool directly as a native L1 chain. Technically, this gives us a very strong advantage.
The difficult part is explaining the technology behind it. Over time, users will understand how many problems from current systems this actually solves, and how much additional security and anti-bot protection it provides. But new systems have always needed time for adoption and understanding.
We are now back to the final testnet phase again — the delay only cost us a few days overall.
The Webwallet also received several additional improvements and performance optimizations, including sounds, toaster popups, mute mode, settings, and various UX enhancements.
We reached 63 % of the total Supply in this moment.
Next Reward Reduction in 7 Days: -5.61%
Read more about how we strive to prevent fraud in Atomic Token Swaps:
https://cryptix-network.org/cryptix-atomic-security
Get fast access to Atomic Token functionality. Create, mint, and trade your token in under 20 seconds directly from the wallet.
Let’s talk about decentralized finance.
With Atomic Token, we followed the original Bitcoin vision — at least partially. Of course, building something this complex directly into consensus is not entirely “Bitcoin style,” but the philosophy behind it matters.
What we mean is the original idea behind Bitcoin in its early years:
The user was never supposed to depend on external services.
The user was supposed to be part of the network itself.
The original Bitcoin client was:
a wallet,
a full node,
a network participant,
and partly infrastructure itself,
all within a single program.
Satoshi’s original vision was much closer to an all-in-one decentralized software stack or interface — not merely a wallet that could send coins, but software that actively participated in the entire ecosystem directly.
Early Bitcoin systems were often slow, technically rough, and had poor UX. That is where they struggled.
As a result, external providers gradually took over — many of them because there was financial incentive in becoming infrastructure intermediaries.
And today?
A large part of the modern “Web3” ecosystem has drifted away from the original idea entirely:
MetaMask + Infura,
centralized RPC providers,
centralized indexers,
hosted APIs,
frontends deployed on Vercel or Cloudflare,
centralized sequencers,
centralized relayers.
Technically, many of these systems became semi-centralized again.
But that was never supposed to be the vision of crypto.
The client itself should be part of the infrastructure.
That is the critical point many people ignore.
Another issue is that the industry constantly speaks about “decentralized finance” as if crypto itself is automatically decentralized.
But where exactly is it decentralized?
In many cases, decentralization exists more in branding than in architecture.
Most systems still depend on trusted parties, centralized infrastructure, hosted services, or even KYC providers.
If users must trust centralized servers to index balances, provide state data, relay transactions, or supply blockchain access, then the system is not truly decentralized finance.
The same applies to many so-called DEXs.
If the bridge or interaction layer between assets is centralized, then the system itself still contains centralized trust assumptions.
Yes, multisignature systems can partially reduce trust requirements — we faced similar challenges with the Cryptix DEX — but even then, many implementations remain pseudo-decentralized rather than fully decentralized.
When two completely independent blockchains need to interact, some form of interface layer becomes technically unavoidable. There are real engineering limitations.
However, for token-to-native interactions on the same network, many of these trusted intermediaries are not actually necessary.
Still, the industry continues to market such systems as “decentralized” while relying heavily on centralized indexers, APIs, relayers, hosted infrastructure, and providers that hold enormous trust power — often without transparency or meaningful accountability.
That is not the original vision of crypto.
With Cryptix Atomic, we set out to address one of the fundamental problems in the crypto industry:
To demonstrate that tokens and decentralized finance are genuinely possible without relying on centralized infrastructure disguised as decentralization.
In this regard, our implementation is fundamentally different.
We do not simply claim to follow the original Bitcoin philosophy while simultaneously building systems dependent on centralized indexers, RPC providers, Layer-2 trust assumptions, hosted infrastructure, or hidden intermediary layers.
We implement the principle at the architectural level.
We do not market “decentralized finance” while the entire ecosystem remains dependent on trusted bridges, centralized APIs, relayers, or custodial infrastructure behind the scenes.
We aim to build decentralized finance in practice — not merely in branding.
And the protocol was never designed as an extraction mechanism intended to enrich insiders through hidden infrastructure dependencies, excessive fees, or artificial trust layers.
Our approach is fee-free by design, except for the TX fee for miners.
The objective was never to create another pseudo-decentralized ecosystem that appears decentralized on the surface while remaining dependent on centralized trust layers underneath.
The objective was to move as much functionality as technically possible directly into the network itself — so that the client once again becomes part of the infrastructure, much like originally envisioned during Bitcoin’s early era.
That is the difference between decentralization as marketing and decentralization as architecture.
There is now a new "Keep Alive" setting for the Web Wallet / PWA Wallet.
This feature is designed to prevent browsers from killing tabs and disconnecting connections when the wallet is inactive. This also applies to smartphones when the wallet is installed as a PWA app.
When the setting is enabled, the wallet is kept alive for a longer time, allowing it to continue running as a background process. For example, on a smartphone you can open the wallet, minimize it, and let it continue running in the background. This allows you to receive notification sounds for incoming messages or transactions.
I just tested it on a smartphone and it worked well.
However, the behavior depends on which browser was used to install the PWA (I tested it with Chrome on Android). It is also unclear whether the connection will stay alive permanently or only for a limited time, such as 1 or 3 hours.
In any case, we implemented the maximum possible keep-alive functionality using several different methods. The feature is disabled by default and is mainly intended for smartphones.
Atomic Swaps / Liquidity Token Swaps always operate on the currently valid pool state. Once a buy or sell transaction has been successfully accepted, the pool state is updated immediately. This prevents the same pool state from being used multiple times.
If multiple users attempt to buy or sell the same token at the exact same time, only the transaction that gets finally accepted by consensus will succeed. All competing swaps based on the previous pool state automatically become invalid (“stale”) and are not executed.
No coins or tokens are lost in this process. A stale transaction simply means that the swap was not executed successfully. The user can then request a new quote and resubmit the swap.
To handle these situations smoothly, the web wallet includes a retry system. If multiple users submit a transaction simultaneously, only one can succeed on the current pool state. In such a case, a retry popup appears automatically. This popup continuously fetches the latest pool data every 300 milliseconds, allowing the user to instantly retry the transaction with updated data in a single click. Furthermore, this makes it possible for users to buy and sell at the exact amount they actually saw—rather than receiving 10% less than what they saw in the preview.
Additionally, an optional Auto-Retry mode is available. This system automatically rebuilds and resubmits swaps using the newest pool state and quotes. Its purpose is to keep execution fair and prevent bots or high-frequency users from gaining a significant speed advantage over normal users.
A higher priority fee cannot overwrite already accepted swaps. Within the standard web wallet flow, a competing pending swap transaction on the same node also cannot simply replace another pending swap with a higher fee. This keeps transaction ordering on the same node as fair and neutral as possible.
Across different nodes, temporary differences in pending transactions or competing blocks can still occur. However, during final consensus, only one valid swap transition for a specific pool state can succeed. All competing transactions or blocks automatically become stale and are no longer applied.
The web wallet is directly connected to the seed server, which acts as a central distribution hub by maintaining connections to many nodes simultaneously. This helps maximize synchronization speed and execution efficiency for swaps and market data. The seed server RPC is also public, allowing developers and users to connect externally if desired. Users may additionally run their own nodes, which can further improve local execution speed and data propagation.
Overall, the system is designed to keep the pool state, liquidity, and token infrastructure fully consistent while protecting against duplicate executions, conflicting swaps, and unfair replacement behavior. The goal is to provide a trading environment that remains as fair and reliable as possible for all users.
We have the advantage of being L1-based rather than relying on smart contracts; consequently, we have been able to implement protective mechanisms and additional features. This, in turn, facilitates fairer conditions for swaps and trading compared to smart-contract-based centralized platforms.
And: Regarding the auto-retry or retry mechanism: Typically, this is not required; however, if many users simultaneously buy or sell the same token—for instance, within the same 200 milliseconds—then the system will prove beneficial. Otherwise, it is not relevant.
We simply tried to solve problems that exist on other platforms—focusing more on users and fairness than on maximizing profit. Since we don't charge any fees for the system anyway, this means we make no profit. It is free technology.
1.
Since users have repeatedly entered their seed words incorrectly—and subsequently wondered why they could not see their Cpay—we have now implemented a seed word verification feature.
Please pay close attention to this feature: if a word is highlighted in red, it cannot be a valid seed word—it is incorrect. This is because the system checks whether the word exists within the official wordlist.
2.
You can now import and use the legacy keyphrases (seeds) from Weballet 2 (the old Weballet) within the new Webwallet system.
Regarding this: Please note that this feature is experimental; I have only tested it briefly. It displays all Uxots, and standard transaction functions—such as sending and receiving—work correctly, as do addresses, etc. In short, I have tested the core functionality, and it works.
Nevertheless, I recommend creating a new seed within the new Weballet and transferring your coins to a modern BIP seed. The new Webwallet is also significantly faster and more optimized for this Seeds.
Please note: I will not be working on making this faster or better. I only integrated it to make it easier for users to swap their wallets. Also, you may have to wait a bit before you can make transactions.
The new Web Wallet version / upgrades are all finished.
Performance has increased significantly — sending transactions is now almost instant. You can try it yourselves by sending 1 CPAY to each other.
There are also many new settings available now, including the requested “max CPAY amount for sending without password” setting.
Translations have been expanded as well.
The Sync / Resync function is finished.
Everything related to Messenger / Tokens / Token Swaps is also completed.
The new update is already deployed on the Web Wallet server.
Please note:
There have been many changes to the local databases and new features that generate things such as Messenger keys.
You must at least reload the Web Wallet tab using CTRL + F5 and then clear the transaction history. That is the minimum requirement.
If that is not enough, you must clear all browser data and cookies related to the Web Wallet completely. I strongly recommend doing this.
Before doing so, download and back up your seed / keyphrase so you can log in again afterward.
If you need your transaction data, download it beforehand — there is a function for this in the settings.
For PWA app installations on smartphones or computers, you absolutely must delete the PWA app and reinstall it. Make sure to back up your seeds beforehand as well.
After that, you must open the Web Wallet again in the browser and reinstall it. Before reinstalling, clear the website data in the browser, otherwise it may reinstall the old version again.
We do have strong cache busters, but depending on the browser and PWA behavior, this may not work perfectly. That’s why reinstalling and clearing the data is the best way to ensure fresh and clean data.
And important:
Use Chrome. All browsers work, but Chrome currently provides the best performance. In our tests between Opera and Chrome, the difference during syncing was huge — Chrome was twice as fast.
For PWA installations as well:
Install Chrome on your smartphone, open the Web Wallet through Chrome, and install it via Chrome. Yes, this can make a very large difference.
You can already do all of this now — the Web Wallet and the server node are already running the new versions. Everything is already supported.
When the hardfork happens, you will have to do this anyway, so it is better to do it now rather than later.
And for those still using Web Wallet 2, the old legacy Web Wallet:
It will continue to work in the future, but it will not receive new features such as Messenger, Tokens, or Token Swaps.
So if you want to use the new features, you should migrate to the new wallet system. I would recommend it anyway.
We are now entering the final step before the hardfork:
We will run another global testnet for approximately one week and perform blockchain stress tests. Any bugs found during this phase will be fixed. After that, the hardfork will happen.
Please note:
The Bug Bounty is still active. So far nobody has reported anything truly relevant yet.
If you want the 1 million CPAY reward — go for it.
The Web Wallet has now received major new features and significant improvements.
The biggest change is the completely new sync system. The wallet now differentiates between a first login and a re-login. A first login means the very first login on a new device where no wallet data exists yet. A re-login is when you log in again later after being offline.
During the first login, syncing now runs fully in the background and in multiple stages. This means you can already use the wallet while it is still syncing and immediately see your balance. The sync process no longer blocks actions like sending coins.
The sync process now works in several steps. First, the wallet performs a fast scan that detects all UTXOs and downloads the required basic transaction data, regardless of how old the UTXOs are. After that, the wallet downloads heavy data for those UTXOs such as payloads, messenger messages, token information, and generates realistic transaction dates. Then the wallet scans recent blocks depending on the configured depth in settings and downloads transactions that are not directly connected to UTXOs. Finally, it downloads extended data for those transactions as well, including messenger messages, payloads, and token data. Once all of this is completed, the wallet is fully synced.
After the initial sync, re-logins become extremely fast because only the difference since the last login or latest received transaction needs to be scanned. The first login can still take up to around 5 minutes until all data is fully available, but balances are usually visible after around 3 seconds and the wallet becomes usable after around 5 seconds. A fresh re-login after being offline for a few hours usually only takes around 10 seconds until all data is fully updated.
A major advantage is that this entire system works without indexers or external servers, meaning it also works fully with local wallets. You can now restore your complete transaction history across multiple devices, including payloads, messenger data, and token information. Tokens that were previously used are automatically restored on new devices, so they no longer need to be added manually every time. Messenger chats are also automatically reconstructed, meaning you can use the messenger on one device and later log into another device and still have the exact same chats available there.
There are still some limits depending on the node type. Pruning nodes only store around the last 2.2 days of blockchain data, while archive nodes allow full historical reconstruction from the beginning.
The wallet now also includes progress bars for the sync process and a skip option for deeper block scans. However, we recommend simply letting it run because it no longer blocks the wallet and only takes longer during the very first sync. There are also settings available to disable certain history functions or even disable the full transaction history entirely if desired.
The Messenger system was also heavily improved. Previously, all chats were rebuilt from scratch during every login, which became too slow for users with large chat histories. Chats are now cached locally for instant loading. The cache is not stored as plain text — it is encrypted and sealed with the user's own messenger identity and stored securely within the account context.
Transaction confirmation handling was optimized as well. Previously the wallet made separate node requests for every single transaction confirmation update, which caused unnecessary performance overhead. This system was redesigned and now performs significantly faster.
Transaction dates were also improved. The wallet now calculates realistic blockchain dates for transactions, including during first syncs. Previously the wallet relied on local device receive times, which caused all synced transactions to appear with the same timestamp.
Reaction times throughout the wallet are now much faster too. Sending transactions previously sometimes caused delays of 2–3 seconds because additional node data had to be requested first. This behavior was redesigned, and transactions now appear almost instantly in the mempool after pressing send. This improvement is especially important for the upcoming Atomic Swap and Token Swap systems.
Translations across the wallet were also heavily expanded.
At the moment we are still improving the live event logic — meaning the systems responsible for handling updates while the wallet is actively online. Performance and reaction times there still need additional optimization because this is also important for the Atomic Swap system. Once this part is finished, the Web Wallet itself is essentially complete.
Please note that we are currently developing directly on the production system. This is necessary so the Web Wallet continues functioning before the hardfork and immediately after it. While this is the best long-term approach, it also means you may temporarily encounter bugs or error messages until everything is fully finalized. Some backend socket proxies for the new endpoints still need adjustments because the system currently uses anti-DDoS token protections and the new block scans require significantly more server resources. Without additional changes, the protection system would automatically ban users because of the scan load.
So in short: temporary errors are possible during this phase, but sending and receiving transactions continues to work normally.
Later, once everything is finalized, you will need to perform a hard browser refresh using CTRL + F5 and then clear your transaction history. Otherwise there is a very high chance of running into bugs because of outdated cached wallet data. Ideally, once the rollout is fully complete, simply clear all browser data for the wallet once and log in again fresh. For now, this is not required yet until development is fully finished.
But the best thing about these updates is this: you can now transfer and sync states and data between your devices. All your devices will have the exact same data — provided you log in regularly. And all this works completely without an indexer or server.
There are now new options in the Web Wallet to load transaction data during sync — for example when logging in on a new device for the first time. This means the wallet will download and restore the complete data history.
Additionally, there is now a “deep data” function, which will later be required for Messenger, Tokens, and other advanced features.
This makes it possible to restore and view all transactions across all devices. The same applies to the Messenger system, where chats and messages will be available on multiple devices as well.
The syncing and loading process has also been completely redesigned.
When logging in, the wallet first loads the account balance, making the wallet immediately usable.
After that, it loads the lightweight data such as transactions, and then finally the deep data like payloads, tokens, and Messenger data.
Everything loads sequentially in the background without blocking the wallet. You can already send and receive coins while the sync process is still running.
Important to note:
Only the amount of transactions configured in the settings will be loaded. The default is the latest 500 transactions (which should be enough for most users). This can be increased, but higher values may reduce wallet performance.
The same logic also applies when logging in again after being offline for several days, meaning wallet resyncing works the same way.
Current test results with the 500 transaction setting:
Fast loading of core wallet data within ~3 seconds
Deep loading of Tokens and Messenger within ~10 seconds
Wallet usable after ~1–2 seconds
There will still be several upcoming changes to the Web Wallet to further improve performance. Because of that, temporary bugs may still occur until development is fully finalized.
We are currently preparing the Web Wallet completely for the upcoming hardfork.
All features are already implemented and working, but we still need to optimize performance for fast requests — especially for Swap usage and Messenger functionality.
Please regularly use CTRL + F5 to refresh wallet data (both in the Web Wallet and the All-in-One software).
For PWA installations, you may need to:
Remove the installed app
Reopen the wallet in the browser
Clear browser data/cache
Reinstall the PWA
This ensures you receive the latest version in case cache busting does not work correctly and old data remains cached.
More updates and changes are still coming, so this is only necessary for now if you want to use the latest version or if you experience bugs or lag issues.
After the hard fork, tokens will support an optional swap function. This means anyone can create tokens — including liquid tokens with built-in swaps and custom pricing curves.
Because of that, here are a few important things you should understand:
First of all: only use the swap system if you actually know what you’re doing. Otherwise, you will risk losing money. Token trading is not gambling — and if you treat it like that, you’ll most likely lose.
Also keep in mind that tokens are extremely volatile. Most tokens will have very low CPAY liquidity, which means prices can move fast and unpredictably.
If you still want to use the system, pay attention to this:
The lock gate is not a guarantee of safety. A creator can set a small lock while still controlling a large portion of supply or CPAY. So don’t rely on that alone.
Always understand the pricing curve. Basic curves are safer and easier to follow. Aggressive curves are, as the name says, very aggressive. Custom curves are the highest risk — they offer full flexibility, but can behave in ways that are hard to predict. You can view every curve in the web wallet, including a visual graph. If you don’t understand it, don’t use it.
Check token distribution. Look at how many holders exist and how much supply each holds. Large holders can dump and crash the price. Also be aware that creators can split tokens across multiple wallets to fake decentralization. There is a holder analysis tool that checks wallet connections, but it’s not 100% reliable.
There will be anti-bot features in the web wallet, but keep in mind: this is L1-native. Bots can still interact directly via RPC without using the wallet at all. So frontend protection is limited.
There’s also a risk indicator in the web wallet to help you — but it’s only a basic signal. New tokens will almost always show as high risk, and it’s not a full analysis.
How the system works
The idea is simple: anyone can create a token in a few clicks — no smart contract knowledge, no audits. Everything is validated directly by the blockchain. Optionally, tokens can be created with CPAY liquidity, linking them to CPAY.
Reality check
Systems like this can be used for speculation, similar to platforms like Pump.fun — but how it’s used is up to each individual user.
Trading always involves risk. Over time, profits come at the expense of other participants. Not everyone can win.
And like in any financial system, there will always be people trying to exploit or manipulate others. No system can fully prevent that.
Final rule (most important):
Never use money or CPAY that you actually need in real life.
And never treat trading like gambling — because that’s how you lose.
I’ve been told that Kaspa is now introducing native tokens (L1) and similar features.
At least that’s what some users are promoting, for example on Twitter, to make others bullish.
But to spoil it right away: once again, this is just typical “Kaspa marketing” and does not reflect reality.
TOCCATA introduces several capabilities.
It allows covenants, meaning a UTXO can define how it may be spent in the future.
It also enables state-carrying UTXOs, where state can be encoded in the script public key, covenant ID, output structure, or possibly payload/script data.
Nodes can validate state transitions by checking during spending whether an old UTXO has been correctly transformed into new ones.
It can enforce local invariants, such as requiring a counter to increase by one, ensuring a covenant only propagates the same covenant ID, or enforcing rules on the sum of outputs.
Additionally, it extends the scripting engine and makes these kinds of rules consensus-relevant.
However, what it cannot do is more important.
There is no global mapping of address to balance, no native token registry in consensus, and no core module that defines something like “Token X has supply Y.”
Standard Kaspa nodes do not automatically track KRC-20 balances, and they also do not store the full history permanently due to pruning.
A node does not store everything, but it does store the current UTXO set.
If your state is contained within an unspent UTXO, then it is L1-relevant.
If your state needs to be reconstructed from historical data, payloads, or inscriptions, then you need an indexer.
In short, TOCCATA can enforce L1-style rules for UTXO-based programs, but it does not make KRC-20 tokens native core tokens.
It does not make KRC-20 native consensus assets.
In the end, when it comes to KRC-20-style tokens, this remains a non-native token layer rather than a native L1 asset system.
It has been reworked and improved, but it is still not native and not L1.
It does not introduce native assets.
For token systems, it is an intelligent externally interpreted layer built on top of L1 covenant capabilities.
Without indexers or external interpretation (L2), KRC-20-style balances will not function as native balances.
If you cannot or do not want to build true L1 solutions, then this is probably one of the best L2 approaches available.
TOCCATA brings L1-enforced covenant/script logic and UTXO-local state, but it does not bring native L1 token balances or L1 assets, a native asset registry, or an ERC-20-like global token state machine.
My conclusion is simple: TOCCATA is L1 for covenant/script validation, but not L1-native for assets.
The token/assets layer remains non-native unless the token state machine itself is part of consensus and committed by block validation.
There is no “L1.5”: either token balances and supply are consensus state, or they are externally interpreted, pure L2.
This isn’t an opinion – it’s architecture.
And these false marketing claims are truly sad because there are people who can’t read code and believe them.
At best, this is technically misleading; at worst, it is used to create false bullish expectations.
As evidence: the UTXO structure has no token field, the TransactionOutput has no token field, and the transaction itself only contains a payload but no token state.
The payload is not validated as a token protocol, and TOCCATA validates covenants rather than KRC-20 balances.
The covenant context itself is local to transactions and UTXOs, and standard nodes do not retain full history due to pruning.
And that can’t be compared to Cryptix Atomic.
We really programmed native L1 tokens/assets.
We don’t need an indexer.
We don’t need a server.
Even the web wallet can be used in local-only mode.
It is really L1 and decentralized.
Atomic Tokens + Swaps are now live on GitHub.
We are looking for real, practical exploits before mainnet.
Examples:
CPAY inflation (e.g. 1000 → 1001)
Token inflation / double spend
Buy/Sell rounding arbitrage
Vault / liquidity drain
Fee or claim exploits
Consensus inconsistencies,
Requirements:
Must be reproducible in practice (no theory-only)
Include steps + proof of impact
Rewards:
Minor (e.g. rounding): 100,000 CPAY
Major (financial exploit): 1,000,000 CPAY
If you can extract value from the system — we’ll pay.
https://github.com/cryptix-network/rusty-cryptix
On the homepage in the transaction history, there is now an option to clear the history. This option is also available in the wallet settings.
When you use it, old and unnecessary transaction history will be deleted. Nothing else is affected—no settings, no login data. Only the history is removed.
I recommend that everyone use this feature if you no longer need the old data. Doing so can make the web wallet load up to 10x faster and improve overall usability. If you have many transactions (for example, more than 500), loading times can otherwise be significantly slower.
We have already added new features that load data gradually to improve performance, but clearing unnecessary data still reduces the number of requests and improves speed.
The new features for tokens and the messenger use deeper block header scans. This is already active in the web wallet, as we are running the latest node version on the seed servers.
If you have many UTXOs, you should also regularly consolidate (compound) your transactions, as this can otherwise slow down wallet loading. There is now a new button in the wallet settings (“Send all to receive address”), which ensures that your coins are sent back to your main address instead of random change addresses.
Long story short:
Clear your transaction history if you don’t need it
Consolidate your UTXOs if you have many
Your web wallet will load much faster and be significantly more responsive.
Especially if you actively use the messenger later and have a lot of tokens. It's unnecessary data you're using and unnecessary processing power you're using. Especially on smartphones.
There's now a setting in the web wallet. If you activate it, you don't need to enter a password or fingerprint to send transactions. We introduced this because it was annoying to constantly have to enter a password for Atomic Swap transactions. For quick trades, it should execute the transaction immediately. The option is disabled by default. You can find it in the security section of the wallet settings (Send transactions without password/fingerprint confirmation).
The Token Explorer is now live at:
https://token.cryptix-network.org/
More about it:
The Explorer currently uses demo data so it can be viewed and tested. Real token data will be available at release, and the demo data will be removed.
The Token Explorer will display all tokens created on the blockchain, regardless of whether they are swap tokens or not.
Tokens can be searched and found via a search field. There is also a filter to show only swap tokens. Sorting is based on recency.
The goal is to provide a neutral explorer / data source for tokens — not a platform like Pump.fun or anything similar. As developers of Cryptix, we should not operate such platforms. We only provide neutral technology, not a trading platform or similar services.
The web wallet will enable trading and swapping, but it will not directly display unknown or new tokens. Users will need to paste the Token ID manually. Tokens can be discovered via the Explorer. This approach helps us avoid regulatory issues in the long term and ensures we remain neutral as developers.
For this reason, the Token Explorer also does not include prioritization or ranking — only sorting by recency. This is intentional to maintain neutrality.
So:
New token discovery → Token Explorer
Trading / Swapping → Web wallet (copy the Token ID from the Explorer into the web wallet and save it)
Separating data access and trading functionality is intentional.
There will be no platform like Pump.fun developed by the Cryptix team. This space is open for external providers — anyone who wants to build such a platform can do so. The REST APIs, RPC interfaces, and blockchain data fully support such development — and even go far beyond that, as can be seen in the web wallet screenshots.
If anyone has technical questions, feel free to contact me.
But what’s in it for a platform operator? Quite simple: trading fees.
Atomic swap tokens allow up to two wallet addresses to be defined at creation, which can split fees 50/50. The fee itself can be freely set between 0.1% and 10% (or even set to zero).
This allows platform operators, for example, to set a 0.2% fee for their tokens and then split that fee between the creator (user) and themselves as the platform operator.
There is also a platform tag when creating tokens, allowing platforms to filter their own tokens. Everything is decentralized.
Curves are freely selectable — whether basic, aggressive, or custom. With custom curves, platform operators can experiment and find optimal configurations. This flexibility was intentionally designed.
And no matter where a token is created, it can always be traded via the web wallet — whether it was created through the web wallet or a platform. Just paste the ID and you're ready to go.
Users can trade via a platform, but they don’t have to. Everything remains decentralized and can even be hosted locally. Tokens can always be transferred, regardless of where they were created.
These are real, usable tokens — not “frozen” tokens that can’t actually be transferred, as is the case with some current platforms like Pump.fun (to my knowledge). The web wallet provides full functionality for this.
Current status:
Messenger - all complete
Atomic Token - all complete
Atomic Swaps - all complete
Token Explorer - all complete
Webwallet Upgrades - all complete
We are currently fixing minor bugs, implementing consent features, and completing external audits. So, the wait is almost over.
It will only take a few more days, and then everything will be finished. Then there will be a 6-day global testnet, and after that, we will perform the hard fork. Please note that all users must replace their nodes within 7 days of the announcement. The upcoming update is a hard fork.
Our mathematical curve for Atomic Swaps / Atomic Tokens is now complete.
The core mathematical formula is:
x * y = k
where:
x = virtual CPAY reserve
y = virtual token reserve
k = x * y
Initial state
For S = maxSupply:
x0 = 2,500,000 CPAY
y0 = 1.2 * S
k = x0 * y0
Cumulative buy curve without fee
If q tokens have already been purchased from the curve:
CPAY(q) = x0 * q / (y0 - q)
i.e., substituted:
CPAY(q) = 2,500,000 * q / (1.2S - q)
Or as supply share p = q / S:
CPAY(p) = 2,500,000 * p / (1.2 - p)
Exact buy formula per trade
For a purchase with net Δx CPAY:
x' = x + Δx
y' = ceil(k / x')
token_out = y - y'
With fee:
fee = floor(gross_in * fee_bps / 10000)
Δx = gross_in - fee
Exact sell formula per trade
For a sale of Δy tokens:
y' = y + Δy
x' = floor(k / y')
gross_cpay_out = x - x'
With fee:
fee = floor(gross_cpay_out * fee_bps / 10000)
cpay_out = gross_cpay_out - fee
This is the base curve.
There is an optional aggressive mode. This mode uses the following values:
x0 = 2,000,000 CPAY
y0 = 1.05 * S
k = x0 * y0
This is the base curve; there is an optional aggressive mode.
This mode then uses these values:
fixed 2.0M CPAY / 1.05x supply
It is also possible to define a custom curve with individual values:
fixed 1.0M-8.0M CPAY / 1.01x-1.50x supply
https://cryptix-network.org/cryptix-atomic-token
We have technically revised the mathematical curve — or more accurately, replaced the old curve completely with a new approach.
The new curve starts relatively smooth and stays much closer to the actual CPAY liquidity. As more of the token supply is bought, the curve becomes increasingly aggressive. Near the upper supply range, it becomes very aggressive. It does not create an extreme leverage effect, but the effect is clearly noticeable. Early buyers still have the best position.
It is easier to understand through values than through words:
Token Supply bought -> CPAY needed, without fees:
1 token at start -> ~2.083 CPAY, if max supply is 1M
5% supply -> ~108,914 CPAY
10% supply -> ~227,273 CPAY
25% supply -> ~657,895 CPAY
50% supply -> ~1,785,714 CPAY
75% supply -> ~4,166,667 CPAY
90% supply -> ~7,500,000 CPAY
99% supply -> ~11,785,714 CPAY
99.99% supply -> ~12,500,000 CPAY
The curve factor is set to:
virtual_token_reserves = max_supply * 6 / 5
So the virtual token reserve is 1.2x of the selected max supply. This means the displayed token value is much better backed by real CPAY liquidity than before.
For liquidated tokens / Atomic Swap Tokens, the max supply can be selected within this range:
Minimum: 100,000 tokens
Default: 1,000,000 tokens
Maximum: 10,000,000 tokens
Decimals: 0
The recommended default is 1,000,000.
Choose 100,000 if you want fewer tokens and a higher value per token.
Choose 10,000,000 if you want a larger supply for a community or meme token.
Choose 1,000,000 if you simply want a balanced, tradable token.
The curve adapts to the selected max supply. Economically, the curve behaves the same whether the token has 100k, 1M, or 10M max supply. Only the number of token units changes.
For tokens without a liquidity bridge, the max supply can still be freely selected, including uncapped supply.
We intentionally disabled decimals for Atomic Swap Tokens because decimals add unnecessary complexity and make deterministic handling more error-prone. For tokens without a bridge, decimals can still be freely selected.
The curve was not easy to design, especially because we had to consider the current CPAY supply, the current CPAY value, the fast-changing supply situation, and possible future value changes of CPAY.
CPAY could be worth half as much in the future, or it could be worth 5 times more. That is not a price promise, but it is something the curve needs to be able to handle. The goal was to build a curve that can work with today’s values, but also with possible future values, while still allowing normal users to participate.
That is why the curve is designed so that one liquidated token can absorb up to roughly 12.5 million CPAY.
At the current CPAY value, that is around 6,250 USD. If CPAY reaches 0.001 USD, it would be around 12,500 USD.
We currently only have around 320 million CPAY circulating supply. If someone bought a much larger amount of CPAY, for example 20 million CPAY, the CPAY price could move significantly. Based on Safetrade data, that could theoretically push CPAY toward much higher values, for example around 0.50 USD per CPAY.
At that point, the bridge could absorb around 6.25 million USD per token through real CPAY liquidity.
This is only the real liquidity absorbed by the curve. It is not the token price and not the token market cap.
So overall, I think we made a good choice. The curve is strong enough to handle possible future CPAY growth, but still accessible enough so that normal users can participate early.
We currently have a few bugs to fix; for example, it is possible for people to intentionally overpay for tokens. Even though nobody would normally do that — why would they? — the system still needs to prevent it. But the curve is already working very well and smoothly. And the user interface is fun to use; it is very responsive, even with global nodes.
We are currently working on a new feature for our token / liquidity bridge called Rug Pull Guard. But what does this feature actually do?
Around 90% of scams on platforms like Pump.fun are classic rug pulls. A user creates a token, buys into it, and as soon as the first real external buyer enters, everything is instantly sold off, leaving no liquidity behind. The buyer ends up with a 60–90% loss within seconds. In some cases, scam creators even use bots to make the holder list look more distributed instead of showing a single owner.
We aim to make this type of behavior ineffective. How?
Tokens can optionally be created with the Rug Pull Guard enabled. If activated, the creator must define a fixed CPAY amount that has to be reached once before tokens can be sold again. For example, a new token must accumulate at least 1,000,000 CPAY in liquidity before selling becomes unlocked. This is somewhat similar to token minting platforms—but instead of requiring a certain supply to be minted, this system requires a certain level of liquidity (in CPAY) to be reached.
This system does not prevent rug pulls 100%, but it makes them significantly harder and less attractive. Scammers now need to reach a minimum liquidity threshold, meaning the typical strategies used on platforms like Pump.fun no longer work in the same way on our system.
Additionally, this enables the creation of tokens with real ICO-like launches. Fake releases—where liquidity is drained immediately at launch—are no longer possible. The token creator has no control over the system or the liquidity itself, only over the tokens they personally purchased. During the initial creation, the creator can still buy at the lowest price, since the price increases along the bonding curve with each CPAY invested. This means it can still be profitable for creators, especially when combined with trading fees they receive. However, completely draining liquidity at launch is no longer possible—this is prevented by the system.
We also plan to integrate an anti-bot system into the web wallet to prevent bots from using it, although this has not yet been implemented. This will only partially help, since the bridge system itself is decentralized and can be accessed directly via RPC using bots and custom nodes—no web wallet is required. Still, it adds an extra layer of friction, so we consider it worthwhile.
There are also users who run different bot strategies: they buy every new token with small amounts (e.g. $1–$10) and instantly dump as soon as someone else buys in, generating profit across many tokens. This could be countered using the Rug Pull Guard—for example, by creating tokens designed specifically to trap such bots. These tokens would attract bot buys but never reach the required liquidity threshold, meaning bots cannot exit. After multiple failed attempts, bots would run out of CPAY.
To protect real users, clear warnings can be added, such as “do not buy – antibot token,” or automatic alerts triggered by specific metadata tags. Bots like those operating on Pump.fun would not recognize or respect these signals and would likely fall into these traps, while human users could be informed and avoid them.
The Rug Pull Guard will be an optional feature but highly visible to users, acting as a strong trust signal. Bots and scammers are unlikely to create or interact with tokens that have this guard enabled. That said, it’s important to be clear: this system does not provide 100% protection. However, it significantly improves the situation and makes rug pulls far less efficient.
Another advantage is that ICO-style launches become fairer. For example, depending on the bonding curve, a scammer might need to commit 10M CPAY in order to extract 1M CPAY—making scams far less attractive.
As mentioned, this is not a complete solution, but rather a Rug Pull friction layer. We are currently working on implementing and testing this system.
Atomic Token / Liquidity Bridge / Token Launch DEX
An important point that needs to be clearly explained is which configuration options are available for Atomic Tokens — especially the difference between tokens created with and without the liquidity bridge.
Token without Liquidity Bridge:
Tokens that are created without the liquidity bridge offer flexible configuration options.
You can define between 0 and 18 decimal places.
The supply mode can be either uncapped or capped.
In capped mode, there are no enforced minimum or maximum limits — the creator has full freedom to define the total supply.
A critical limitation must be understood:
A normal token cannot later be converted into a liquidity bridge token. If liquidity functionality is required, it must be enabled at the moment of creation.
The Web Wallet makes this process extremely simple.
Only two fields need to be filled: the token name and ticker. Everything else is preconfigured. A single checkbox determines whether the token will use the DEX / liquidity bridge or not.
Both standard tokens and liquidity tokens are Layer 1 assets.
This means they can be listed on centralized exchanges as well. The Rust CLI wallet already includes a wallet daemon specifically designed for exchange integration. It fully supports both token operations and bridge functionality.
Token with Liquidity Bridge:
Liquidity tokens follow a stricter rule set due to their integrated market mechanism.
They do not support decimals.
The total supply must be defined between 1,000 and 1,000,000 tokens.
A minimum of 1 CPAY must be provided as initial liquidity, mainly as an anti-spam measure.
Trading is handled directly against the liquidity curve.
Users can buy and sell using CPAY in arbitrary amounts, with support for up to 8 decimal places.
Additional Mechanics:
The liquidity curve guarantees that liquidity exists until the very last token.
This means a buyer will always be able to purchase, and a seller will always be able to exit — there is no scenario where liquidity drops to zero.
However, profit and loss occur naturally through changes in the CPAY reserve.
This is real trading behavior: early participants benefit, late participants may incur losses.
The system does not use an order book.
Instead, it relies on a mathematical pricing curve — conceptually similar to platforms like Pump.fun, but implemented differently.
Our curve is intentionally softer at the beginning.
This reduces the efficiency of automated trading bots and creates a more gradual price discovery phase.
Fees:
There are no special fees for token creation.
Only standard transaction fees apply, calculated per byte, typically around 0.0003 CPAY.
Liquidity tokens do not introduce additional fees either.
The only requirement is the initial liquidity deposit of at least 1 CPAY.
Optional Trading Fee:
Token creators or platforms can define an optional trading fee.
This fee can range from 0.1% to 10% per trade.
It is possible to configure one or two fee recipients.
This allows flexible monetization models:
Platform operator + creator
Platform only
Creator only, for example when using the Web Wallet directly
Two independent creators in a zero-trust setup
Fees can be claimed once they exceed 0.0001 CPAY.
However, they should always be higher than the transaction fee to avoid losses — the Web Wallet enforces safeguards to prevent this.
Common Question: Is this like Pump.fun?
No.
We are not providing a trading platform.
As developers, we only provide the underlying technology and protocol-level functionality.
The Web Wallet allows buying and selling against the liquidity bridge, but only if the token ID is known.
A neutral token explorer will exist to display all tokens, but without ranking, promotion, or platform-driven trading incentives.
A better question would be:
Can this system achieve similar functionality?
The answer is yes — but fundamentally different.
This system operates directly on Layer 1 and is integrated into the consensus.
There are no smart contracts, no central execution layer, and no prioritization mechanisms.
It is not a smart contract system.
It is part of the protocol itself.
Every validator executes the same logic.
This creates a major difference compared to systems like Pump.fun.
There is no centralization.
No need to trust operators or token creators.
Only the open-source code and the network consensus must be trusted.
All tokens are created under identical rules and validated by every node.
That said, integrating such functionality directly into the consensus layer is a bold decision.
To the best of our knowledge, this approach is unique and comes with risks — including potential exploits, bugs, rounding issues, or edge-case failures.
The system has been thoroughly tested, but real validation will only occur under full mainnet conditions with high user activity.
For Developers and Platforms:
Anyone who wants to build on top of this system can do so.
The Rust node implementation is already available on GitHub, though still undergoing refinement.
A WASM version is also provided, making it easy to build platforms where execution happens locally on the user side.
Pricing Curve:
The system uses a Constant Product Market Maker model.
x = CPAY reserve
y = remaining token supply + 1
k = x * y
The curve starts relatively soft and becomes extremely steep toward the end.
As an approximation:
50% of the supply costs about 1x the initial reserve
90% costs about 9x
99% costs about 99x
The final token becomes extremely expensive due to the built-in floor mechanism, using remaining supply + 1.
Buy Mechanism:
fee = floor(cpay_in * fee_bps / 10,000)
net_in = cpay_in - fee
x_after = x + net_in
y_after = ceil(k / x_after)
token_out = y - y_after
new_remaining_pool_supply = y_after - 1
new_curve_reserve = x_after
Sell Mechanism:
y_after = y + token_in
x_after = floor(k / y_after)
gross_cpay_out = x - x_after
fee = floor(gross_cpay_out * fee_bps / 10,000)
user_cpay_out = gross_cpay_out - fee
new_remaining_pool_supply = remaining_pool_supply + token_in
new_curve_reserve = x_after
Final Note:
Tokens can be highly volatile.
Financial losses are possible and can occur very quickly.
Anyone participating in trading should fully understand the risks.
Never trade with funds that are needed for essential expenses.
To say it short:
The logic is embedded directly in the protocol (Layer 1). Not as a smart contract like Ethereum, not as a platform like Pump.fun.
Token without Liquity Bridge: This is essentially a "normal asset" – comparable to ERC-20, but without smart contracts. Verified by the Chain.
Token with Liquidity Bridge: This is more of a "built-in market" than just a token.
This is not "just a new feature," but an attempt to move DeFi directly into Layer 1.
It will radically simplify token launches. It will make platforms like Pump.fun obsolete. But it's also courageous. Most chains deliberately avoid this path because changes to the consensus are extremely risky. We'll try it anyway - We are still "small" now, so we can still implement such an innovation.
Warning about Listing Manager Scammers:
Yesterday, we were contacted by a supposed listing manager from KuCoin, a user named @Athena_Kucoin.
At first glance, everything looked legitimate — the profile picture, the username, and the overall appearance.
KuCoin even provides a way to verify whether a manager is official, so we checked it. The official website appeared to confirm that this was indeed a verified KuCoin manager.
However, things quickly became suspicious.
The listing offer we received was oddly written, and many of the statements felt unprofessional and manipulative — clear signs of potential social engineering.
So I decided to dig deeper and asked for confirmation via an official KuCoin email address, in this case [support@kucoin.com](mailto:support@kucoin.com).
When I received the email, I checked its source code to verify the sender.
Sure enough, it was fake: “No valid SPF, DKIM not aligned.”
This means the sender was not authentic — the email was 100% spoofed.
I confronted the scammer with this, and the response was: “That’s normal, we use external servers.”
That is complete nonsense — if that were true, those servers would be properly registered and authenticated.
To push further, I suggested opening a ticket directly through KuCoin’s official support system and asked them to respond there.
At that point, the scammer immediately blocked me — they knew they had no way out.
Additionally, the email contained a tracking pixel image intended to monitor my activity.
Fortunately, my email client blocks such tracking by default.
Still, this was another clear sign that the email was malicious and not official.
What makes this case particularly concerning:
Email spoofing itself is nothing new — which is why you should always check the source code of emails and verify SPF and DKIM authentication.
However, what is alarming here is that this scammer appeared in the verified manager list on KuCoin’s official website.
That is highly unusual and dangerous.
It means such verification lists can no longer be blindly trusted.
How the scammer managed to get listed there is currently unclear, but it represents a serious security vulnerability.
Projects could easily fall victim to such scams — not everyone is familiar with these techniques or as cautious.
The incident has already been reported to KuCoin, and they are currently investigating the matter.
A central challenge in continuous quantum measurement is to determine how much
information about a quantum state can be extracted from a single measurement realization. Read More:
Quantum State Multi-Channel Continuous Measurement
The web wallet now includes new files and features, which are already finalized for the upcoming hard fork. The token and messenger functions are already complete, and the web wallet has received the corresponding update.
However, some devices may experience cache issues, meaning parts of old files might still be stored. If you encounter problems, please try the following:
Perform a hard refresh in the web wallet using CTRL + F5
If that doesn’t resolve the issue, clear your browser data
For the PWA app, you may need to reinstall the app if problems persist.
For the all-in-one software, you can also try CTRL + F5.
Please note: there will be another update for the DEX bridge function, depending on whether it will be included in the upcoming hard fork.
There may still be bugs, as the web wallet includes thousands of new lines of code. If you find any issues, please report them. However, everything has been thoroughly tested, so there should be no major bugs.
Quantum security is a recurring topic in the cryptocurrency space, and many users worry about waking up one day to find that a secret quantum computer has already “cracked” their coins. To put this into perspective: based on current knowledge, there is no evidence that such a quantum computer exists today—at least not one capable of breaking the cryptographic systems used in modern cryptocurrencies. Major players like Google estimate that there is still a window of time to adapt existing systems, often placing this somewhere around 2030. However, this should not be interpreted as a fixed deadline—progress could be either slower or faster.
At the moment, quantum security is also heavily used as a marketing narrative. Some projects present themselves as “quantum-safe,” even though there is no immediate threat. At the same time, there has been a noticeable rise in social engineering attacks exploiting this topic—fake projects or manipulated software designed to lure users. This makes quantum security not only a technical issue but also a gateway for human-targeted attacks.
The core technical risk lies in public-key cryptography. A sufficiently powerful quantum computer could use Shor's algorithm to derive a private key from a public key and thereby forge signatures. Since today’s cryptocurrencies rely on schemes like Elliptic Curve Cryptography, they would be directly affected. That said, not every address is automatically vulnerable. In many systems, the public key is initially stored only in hashed form and becomes visible only when a transaction is made. The real risk arises when a public key is exposed—for example, when spending coins or reusing addresses.
The general solution is known: adopting post-quantum cryptography. The real challenge, however, is not the integration of new cryptographic schemes, but the migration of existing systems. Wallets need to be updated, existing funds must be transferred into new secure structures, and the networks themselves require consensus upgrades. This transition is complex and will take time.
A critical issue in this context is the significantly larger data footprint. While current signatures are typically around 64 bytes, quantum-safe signatures—such as those from Falcon—range roughly between 700 and 1500 bytes. This represents an increase by a factor of 10 to 20 per signature. Since each transaction contains one or more signatures, this directly impacts the entire data structure. Transactions become larger, mempool storage requirements increase, bandwidth demands across peer-to-peer networks grow, and validation becomes more computationally intensive.
At high transaction rates, the effect becomes even more pronounced. For example, a network processing 2000 transactions per second could see several megabytes per second of additional overhead from signatures alone. These data must not only be stored but also propagated between nodes and validated in real time. This affects bandwidth, RAM, CPU, and long-term storage. For a high-performance Layer 1, this becomes a real architectural challenge. It cannot simply be dismissed by pointing to Layer 2 solutions—if scalability is expected on the base layer, the solution must also be implemented there.
With a block time of one second and the current transaction throughput, this challenge is still manageable with optimizations and architectural adjustments—but it is close to the limit. Higher speeds, in my view, are not technically feasible with current technology in a truly decentralized network. Over the past weeks, we have also worked closely with a professor specializing in quantum technology, gaining valuable insights to guide our planning for upcoming updates. Even if the architecture does not need to be implemented immediately, it must be designed now. Otherwise, current architectural decisions could lead to long-term constraints or dead ends. To be clear: we do not expect fundamental issues when introducing quantum security.
In summary, quantum security is a real but long-term concern. The primary vulnerability lies in public-key cryptography, not in hash functions or mining (with some limited exceptions). There is no immediate danger, but in the long run, a migration to quantum-resistant cryptography will be necessary. At the same time, it is important to recognize that the topic is currently being heavily used for marketing and, in some cases, for fraudulent activities. A sober, technically grounded perspective is therefore essential.
Current Status of the Hardfork:
Messenger:
The messenger is now fully completed and ready for use. Encryption, web wallet/frontend, L1 code, and testing — everything is finalized and officially complete. It runs without errors.
We designed the frontend (the visual layer) to be as user-friendly as possible. No overengineering. This removes complexity immediately, even though there is very heavy technology running underneath. It is simple to use despite being based on blockchain/crypto technology — the user doesn’t notice any of that.
It’s important to highlight that this is the first true L1 messenger that operates without external servers, indexers, or any off-chain components. Messages are delivered in about 1 second, and with Fastchain even in 50–200 ms worldwide. Encryption starts automatically from the second message onward. It works directly from the web wallet, even with a local node, since it is true L1.
There have been many experimental projects in this direction, but I have not found any fully finished, truly usable product. What exists are experiments, off-chain indexer messengers, and some smart contract-based messengers — but no real, fast, encrypted, fully functional L1 messenger. That makes us the first at release.
This is a major step forward for the crypto space, as it enables anonymous, decentralized, censorship-resistant communication. Whether we are the first or not — every blockchain should offer this. In today’s world, such communication tools are extremely valuable and will become essential in the future.
Token System:
Tokens are also working flawlessly — minting, creating, burning, and sending. Everything is easy to use, with complexity handled entirely in the background.
Anyone can create a token within seconds directly on the real L1 chain. These tokens could theoretically even be listed on a CEX, since the wallet daemon is designed to support them.
Again, there are no indexers or L2 dependencies. Tokens exist purely on L1 and are tied directly to consensus. Nodes store token data and validate/replay independently. Everything works via the web wallet, including self-hosting with your own node. No external servers are required.
It also works with pruned nodes and syncs from them — no archive nodes are needed. Token data includes cleanup mechanisms to keep storage size small.
Unlike originally planned, Atomic Tokens now have no data limit. The technology was implemented differently than initially designed. Tokens use a unified, validated logic — all tokens follow the same rules. No complex smart contracts, no need for audits. Clean, standardized, and safe tokens without hidden risks in contracts.
The token system is complete and usable. The only remaining steps are international testnet testing and targeted stress/error testing to verify robustness. Otherwise, everything is finished.
L1 DEX / Bridge for Tokens:
This is a major component. With this technology, tokens can be created directly via a liquidity bridge.
This means when a token is created, the creator owns it, but can immediately buy it with CPAY, increasing its value. Other users can also buy and sell the token against CPAY in a decentralized way.
This is different from minting, as it uses a mathematical curve to determine pricing — otherwise, the token price would remain constant. With this curve, the token price can rise and fall in CPAY value.
The bridge will be integrated directly into the token section of the web wallet. Again, it works entirely on L1, without external servers, and no one has control over the system.
Is it the same as Pump Fun? No. Pump Fun relies on centralized servers, which allow prioritization of users during trading. Due to such issues and potential market manipulation, Pump Fun operators are currently facing legal challenges.
Our system does not allow prioritization and requires no centralized servers. Users can operate it via a self-hosted wallet. Additionally, we will not provide an information dashboard or trading platform. That is intentional.
Our goal is not to promote speculative trading platforms, but to enable decentralized trading and liquidity provisioning — allowing tokens to be used without smart contract knowledge or reliance on CEXs. Creating a token in seconds and being able to trade it against CPAY is the focus.
While our system could technically enable similar use cases as Pump Fun, we will not market it that way. Trading will only be possible via the web wallet, and users must know the token ID.
There will be a token explorer where all tokens can be viewed — including price, liquidity, ID, creation date, etc. However, trading will not be possible directly from the explorer. Users will find tokens there and then trade them via the web wallet.
This separation is intentional — both for regulatory reasons and to maintain credibility. It also helps avoid attracting scam ecosystems like rug-pull tokens and bot abuse, which would otherwise create massive overhead in fraud prevention.
The bridge is currently in development and has not yet been tested. It should soon be ready for testing. After that, we will make a final decision on whether it will be included in the upcoming hardfork. This is not yet finalized, also due to technical considerations.
Summary:
The token system and messenger system are fully complete and usable, and will definitely be released soon.
Only the bridge system is still under evaluation. Once that is finalized, the hardfork will follow.
I was told that Kaspa is supposed to already have a real on-chain L1 messenger, advertised as:
“Encrypted, Decentralized and Fast P2P Messaging Protocol & Application built on top of Kaspa.”
This refers to KaChat or Kasia (https://github.com/K-Kluster/Kasia).
Naturally, this caught my interest, so I took a closer look—especially since I was surprised that the node itself doesn’t even contain relevant payload fields required for a true L1 messenger. I already suspected something was off beforehand, but straight to the conclusion:
Claim 1: “All messages are encrypted”
However, broadcasts are explicitly constructed in plaintext (account-service.ts (line 536)) and parsed as strings (block-processor-service.ts (line 401), block-processor-service.ts (line 405)). So this claim is already incorrect. While encryption could theoretically be handled at an external layer (directly in the app), the statement in the README is simply false. In their actual code, it is not encrypted.
Claim 2: “P2P Messaging Protocol”
“P2P Messenger” here does not mean direct peer-to-peer communication like with WebRTC/libp2p, but rather an on-chain payload protocol.
Main chat flow: the UI calls sendMessageWithContext (useMessageComposer.ts (line 105)) → encrypts for the recipient (wallet.store.ts (line 396)) → then sends it to the sender’s own address (account-service.ts (line 810), account-service.ts (line 811)).
For self-messages, outputs are empty (transaction-generator.ts (line 39)). Receiving works via block scanning + alias filtering (block-processor-service.ts (line 56), block-processor-service.ts (line 78), block-processor-service.ts (line 196)).
This means messages are not actually sent to a wallet address / wallet (P2P). Instead, it only pretends to do so, and later ALL blocks must be scanned using an indexer to search for the recipient. This happens entirely off-chain—it is pure L2. Without an L2 indexer, nothing would work at all, and with this approach, there is no real P2P.
Claim 3: “No central server”
This is only partially true in practice.
Historical sync runs via an indexer API (historical-syncer.ts (line 41), historical-syncer.ts (line 82), historical-syncer.ts (line 110)). The app actively sets an indexer base URL (useOrchestrator.ts (line 50)). By default, it points to centralized kasia.fyi infrastructure (.env.production (line 9), .env.production (line 12)).
It is configurable (you can run your own node/indexer), but by default it is centrally preconfigured (network.store.ts (line 98), LockedSettingsModal.tsx (line 252), LockedSettingsModal.tsx (line 404)).
This means users typically rely on an external server operated by a centralized third party. Alternatively, to receive messages, they would need to host their own indexer server 24/7. In short: without a central server, you cannot receive messages. That is not what decentralization should look like.
Final technical conclusion:
Unfortunately, this appears once again to be technical misrepresentation aimed at impressing non-technical users. This is dangerous if users actually believe and trust such claims. In reality, none of the statements hold up—check the code, I have explicitly pointed out the relevant files and sections.
Result:
The product is marketed as a fully encrypted, decentralized P2P messenger, but the code reveals more of an on-chain messaging system with partial plaintext communication and a de facto dependence on centrally pre-configured infrastructure.
Technically weak, ethically questionable marketing.
Next Block Reward Reduction:
2026-04-20 23:41:43 UTC
Reward: 4.20448207 CPAY -5.61%
5 Days left to the next Reduction.
Let’s talk about data transfer and performance for the upcoming update (payloads / messenger).
The following values assume a constant 24/7 maximum load on the blockchain and nodes.
Storage:
Without payload, the system uses around 75–79 KiB/s (about 77–81 kB/s), which results in roughly 6.2–6.5 GiB per day.
With a 2 KB payload, this increases to about 111–115 KiB/s (around 113–118 kB/s), or approximately 9.1–9.5 GiB per day.
Out of this, the pure payload data at 2 KB per transaction accounts for about 96–102 KiB/s, which equals roughly 7.9–8.4 GiB of payload data per day.
Nodes prune data approximately every 2.2 days, so storage is not a concern for regular nodes and is only relevant for archive nodes. Even under full load (full mempool, full blocks, maximum payload usage), a pruning node should not exceed about 20 GB of data. Under normal conditions, it is typically around 2 GB.
Bandwidth (per node):
Without payload, bandwidth usage is around 77–81 kB/s (≈ 75–79 KiB/s).
With 2 KB payload transactions, it rises to about 113–118 kB/s (≈ 111–115 KiB/s).
In a mixed scenario with 50% payload transactions, it averages around 108 kB/s (≈ 106 KiB/s).
Actual P2P node traffic is higher due to relaying data to peers. With the default setting of 8 outbound peers (--outpeers=8), total traffic is roughly between 0.8 and 1.1 MiB/s under full load.
In practice, it is usually much lower, around 300 KiB/s. The number of peers can also be reduced if needed. There are occasionally a few extra kilobytes, for example for quantum-safe handshakes, etc. But that's not worth mentioning.
Overall, node participation remains decentralized because the system requires relatively low storage and bandwidth. It is currently very efficient. While throughput can be increased later to support more transactions per second, this is not necessary at the moment. As long as there is not even 10% organic usage, there is no need to focus on scaling or spend time on it yet.
Since there have been questions about the Vault in the web wallet:
The Vault is encrypted via the wallet file, which means the data cannot simply be read. It must first be decrypted using your password.
How secure is this?
If you selected strong encryption when creating the wallet, it uses PBKDF2-SHA256 with 500,000 iterations and a 32-byte salt.
If you also use a strong password—for example, 20 characters long and not based on easily guessable words—then the security is extremely high.
Even specialized IT forensics companies with ultra-high computing power would not be able to crack the contents. It would take thousands of years.
So even if someone gains access to your computer, they cannot read the data without the password—no matter who they are. Even professional companies cannot break it with current hardware.
The only requirement is that your password is strong and that you selected strong encryption when creating the wallet.
And the data is stored only locally on your computer, not on any server. This also applies when using the web wallet.
It seems MecaCex / FinanceX / BitGoGet, etc., are back with yet another fraudulent exchange.
BitGoGet was shut down, and now the new platform WikaEx has appeared.
The code is not comparable; it's using code obfuscation again.
The menu uses the same languages again.
It allows launching tokens directly again.
Similar functions to the old exchanges.
There's a 99% chance it's the same scammers trying to defraud people again. Even though I can't prove it 100%: Don't use the exchange; you'll likely be scammed.
here is it: https://wikaex.com/
The website now displays the current balances of your donation wallets, with data updated every 10 minutes. A conversion tool for BNB and CPAY to US dollars is also available, giving you a quick and transparent overview.
Donate
We have now reached 61% of the total supply,
and within the next ~8 months we expect to reach 80%.
A hard fork is coming soon, bringing a major security upgrade as well as the L1 Messenger.
On top of that, several other important developments are already planned, and some are already in active development.
Now that we have stabilized the off-chain side and built all core modules to be user-friendly and reliable,
we are in a strong position to focus on faster on-chain development.
There will likely be multiple hard forks over time as the project continues to evolve.
Another topic we will increasingly address is quantum security.
In our view, it may not be critical yet, but it will become a serious subject in the coming years.
We do not want to wait until the last moment to prepare for that.
With the upcoming hard fork, we also plan to introduce quantum-secure node handshakes via ML-KEM-1024.
This is not a headline feature and only a small part of the overall upgrade,
but it is a useful improvement.
Since we are already working on the P2P protocol and upgrading it as part of the hard fork,
it makes sense to include it right away.
But this post is really about something else.
It is time to seriously think about marketing, community growth, and expanding our reach.
It is also time to think about larger exchanges in the future.
Safetrade is a very good exchange, it works reliably, and we are genuinely grateful to be listed there.
But progress must continue.
We need more visibility, more reach, and more users.
We are still at an early stage,
but we are now in a position where we can break through important milestones much faster than before.
The challenge is that all of this comes with significant costs.
Marketing, larger exchange listings, stronger social presence, and broader visibility all require funding,
and not a small amount.
One of the questions we hear most often is: “When is the next exchange coming?”
This is understandable.
More marketing, more reach, and more exchange exposure could have a strong positive effect on the project
and potentially on the coin’s value as well.
That is not a promise of profit, but it is the reality of how growth and visibility can influence a project.
The real question is: where should that money come from?
We are a community project.
We are a fair mining project.
For more than a year, developers have been covering the costs of servers and many other necessary expenses
out of their own private funds.
That includes software, licenses, domains, infrastructure, and more.
Not a single dollar from the donation wallet has been used so far.
Everything has been funded privately.
In other words, developers are effectively paying so they can work on the project without compensation.
And that is completely fine.
This is a voluntary, open-source, community-driven project.
It is about technology, progress, and crypto — not about quick enrichment.
That part is exactly how it should be.
However, it is not realistic to expect developers to also provide thousands of dollars
for major exchange listings, large-scale marketing, or similar expansion efforts.
That is where the community has to become part of the process.
We currently have around 1,600 users here,
but only a very small number of people have contributed donations to the project so far —
and those donations are for the project itself, not for the developers personally.
At the same time, many miners, traders, and users have made very strong profits over the past months,
especially during the price increase.
Some users, and this is known for a fact, made thousands of dollars in a single day.
Yet contributions back into the project have remained extremely limited.
If only 60% of the users here — around 1,000 people — donated just $10 each,
we would quickly have around $10,000 available for marketing, exchange growth, and other important steps forward.
If used efficiently, that amount could already make a real difference.
That is why we are asking the community to support the next stage of the project through donations.
These funds will be used only for increasing reach and covering relevant project-related growth expenses.
They will not be used for personal enrichment or developer profit.
If you are able and willing to contribute more, that is appreciated.
If you can only contribute a small amount, that is absolutely fine as well.
Every contribution helps, even if it is only $5.
Everyone can be part of moving the project forward.
And of course, stronger growth, better reach, and improved project positioning
may also contribute to a stronger long-term project status and possibly a higher coin value as well —
but again, this is not a profit promise.
https://cryptix-network.org/support-cryptix
Be careful with new coins. There was apparently an incident today involving a coin called:
CARBONSPHERE
This coin made a lot of promises and heavily promoted itself as “quantum-secure.” However, when users reviewed the code, they found that it appeared to be incomplete. There were also no seeds or proper network connections, and the mining code didn’t seem legitimate either.
I was sent the code (just a few hours later, both the Git repository and the website were deleted). After reviewing it, it strongly looked like fake or placeholder code. This kind of setup is often used to distribute trojans to users in order to compromise wallets.
I can’t say this with absolute certainty, since the malicious parts weren’t directly visible in the source code—but the code itself wasn’t complete. That suggests the compiled binaries may have contained different, hidden content that can’t be inspected. I also chose not to test it in a sandbox, especially since everything was already taken down shortly after release.
Please be very careful about what you download and run on your computer. And if you really want to take risks, at least don’t use the same machine where you store your private data, passwords, or crypto wallets.
Stay safe in the crypto space—there are clearly malicious actors out there again spreading trojans.
The hard fork is approaching. At the moment, we are still finalizing the new security system within the nodes. This includes the following enhancements:
Nodes must now generate a unique ID at startup. This ID is not a random value; it is created using a public key, private key, PoW nonce, and a signature. The creation of this ID is a one-time process and requires computational power. It takes between 2 and 10 seconds during startup. After the hard fork, nodes will no longer communicate with participants that do not have such an ID.
The handshake must be signed. In addition, every submitted block must be signed. Submitting a block without a signature will not be possible—there must always be a node that vouches for that block. This prevents bans from being bypassed using bridge nodes, because the bridge itself must sign and can therefore be banned. It also enables immediate detection of potential future 51% attacks.
A new endpoint will be added to the REST API, allowing you to view how strongly nodes are distributed based on block findings and their associated IDs.
The address manager (i.e., addresses used for gossip) has also been updated. Only valid addresses with a valid ID can now be submitted. There is an automatic ban system: if someone attempts to submit without an ID or with an invalid ID, they will be automatically banned by nodes. The same applies to on-chain DDoS attempts, reconnect attacks, and similar behavior. These bans are based on both the ID and the IP address.
The antifraud system is also integrated. If an ID or IP address is listed in the antifraud system, those nodes can no longer connect. If they are already connected, they will be disconnected.
The antifraud system is public, including IP data—hidden entries are not possible. All entries remain community-driven and are voted on. If the antifraud server goes down, there is a gossip-based fallback: nodes share the data among themselves. In this case, no single node decides; instead, consensus from more than 50% of nodes is required.
The data is signed with a key, and nodes verify both the data and the signatures. This means nodes cannot simply add their own data. They can only propagate valid, signed data and vote on which dataset is correct in the event of a server failure. If a node does not have the correct dataset or has modified it, other nodes will ban it—making manipulation effectively impossible. Additionally, the dataset itself is required for signature validation.
There are many more enhancements, primarily focused on security and protecting the blockchain from potential attacks. These changes are designed to prevent exploits like those we have seen in recent weeks.
Is this 100% secure? Nothing is ever 100% secure. Every system has weaknesses, no matter which one. However, bypassing or exploiting this system is highly unlikely.
Note: The antifraud system does not interfere with transactions or wallets. It operates purely on the off-chain network layer. However, it introduces a community-driven access control mechanism for node participation and aims to prevent abuse as effectively as possible.
Achieving strong security without directly interacting with the blockchain is inherently challenging. Our approach is designed to maximize security while preserving the non-custodial nature of the system. Furthermore, in this system all users have a vote; no single authority decides everything.
Furthermore, we will introduce quantum attack-proof handshakes with ML-KEM-1024.
Let's talk about the Messenger:
The Cryptix Messenger is not a Marketing Tool - its a new Era of Communication Something truly significant.
A real Layer-1 messenger is being built for high-speed communication and real-world usage. Cryptix Messenger is not just another messaging app — it represents a completely new form of communication infrastructure.
The system provides full end-to-end encryption, operates without centralized servers, and cannot be censored or stopped by any central authority.
What makes Cryptix Messenger unique is its architecture. Unlike traditional messaging platforms that rely on company-owned servers, Cryptix Messenger operates directly through the Layer-1 blockchain, using a user’s local wallet and local node to interact with the network.
There is no webserver connection required. Communication happens directly through the decentralized network itself.
Cryptix Messenger turns a wallet into an identity. Instead of accounts tied to emails or phone numbers, communication endpoints are cryptographic wallet addresses.
With Cryptix Messenger, users can:
send coins
send messages
send coins together with messages in a single transaction
Communication and value transfer become part of the same decentralized protocol.
Many users may initially think this is simply another messaging application. But it is far more than that. Cryptix Messenger is a fully decentralized communication layer built directly on Layer-1.
This changes how communication works at a fundamental level.
The technology is also open source. Other developers will be able to build on top of it, extend it, and use the underlying technology in their own projects.
The system itself is modular, allowing cryptographic methods to be replaced or upgraded over time. While the current implementation already uses extremely strong encryption, the architecture is designed to evolve alongside advances in cryptography.
Cryptix Messenger is not just another messenger.
It represents a new model for global communication — one where privacy, decentralization, and freedom of communication are built directly into the infrastructure itself.
And: Free, uncensored, and anonymous communication is a human right.!
One important topic regarding the messenger was how to handle the UTXO system. Unlike account-based blockchains, a wallet does not consist of only one fixed address. Instead, users can have multiple sending and receiving addresses within the same wallet. This happens for several reasons, such as change addresses where the remaining balance of a transaction is automatically sent back to a newly generated address, privacy mechanisms where wallets create new receiving addresses to avoid address reuse, and compound transactions where multiple UTXOs are combined for a payment.
Because of this, a single user might interact with the system using many different addresses. To solve this challenge, we designed the messenger to identify users by their public key instead of by a specific address. This means that no matter which address you use to send a transaction or message, it will always appear in the same chat. In other words, your wallet itself represents your identity, not the individual address that was used to send the message.
For receiving messages, users can still use multiple addresses from their wallet. Within the messenger interface, the legacy (first) address of the wallet will be displayed as the main identifier. However, all addresses belonging to the wallet will work for receiving messages, ensuring full compatibility with the UTXO model while keeping the messaging experience simple and consistent.
Regarding the Go Node and the upcoming hard fork:
The Go Node will be updated to continue functioning with its existing features. This includes syncing, mining, and regular transactions. It will simply be updated and will not offer any expanded functionality. A Rust Node will be required for using HFA, payloads, the messenger, or other features. However, it will still be usable for pools, the Stratum Bridge, and the wallet daemon (for regular transactions).
In short: The Go Node will continue to function, but will not offer any new features itself, even though it can handle the new features.
Strong Nodes v2.1: A Overlay System for Early Detection of Potential 51% Attacks
We have seen how quickly malicious nodes or mining pools can come to dominate a small coin. For that reason, we have recently been working on a concept designed to identify such nodes and to detect potential 51% attacks at an early stage. As part of this effort, we developed a system intended to detect these kinds of nodes even when they are not publicly visible nodes.
We call this mechanism Strong Nodes. It is designed as a benchmarking and early-warning system for detecting potential 51% attacks and mining-dominance attacks.
It is important to note that the system does not yet provide complete security. In its current form, it can still be bypassed, and it can also be disabled optionally through a startup argument. However, it represents an important first step toward a broader security architecture.
Although this is still an early concept and many parts will need further improvement, it is planned to be introduced and fully integrated with the upcoming hardfork. In addition, a number of further security features are planned as part of this broader effort.
Important: This system is a monitoring/early warning system, not an evidence or defense mechanism.
Read the Whitepaper
We have introduced new tools:
In the Web Wallet: https://wallet.cryptix-network.org/
Vault (Web Wallet)
The Web Wallet now includes an encrypted vault for important data.
You can store any important information there, no matter what it is — phone numbers, addresses, love letters, or other sensitive information.
This data is stored locally on your device only, not on any server.
Therefore, the data exists only on the device where it was created.
All data is fully encrypted within the Web Wallet, and access requires your fingerprint or password.
xPub Key Function (Web Wallet)
You can create an xPub key in the Web Wallet.
This key allows the following actions for people who receive it:
With an XPUB you can:
Derive addresses
View wallet balance
Track incoming and outgoing transactions
With an XPUB you cannot:
Sign transactions
Send coins
Take control of the wallet
What is the benefit?
Anyone who has your XPUB can largely monitor the activity of your wallet, more than other observers can.
This is useful for situations such as:
Trustees, Notaries, Business environments, Multi-user wallets, Similar applications
On the website:
Watchlist Function (Website) https://cryptix-network.org/cryptix-watchlist
You can add wallet addresses to a watchlist and receive instant alerts whenever there is:
an incoming transaction, an outgoing transaction, a new UTXO
The alerts are fully configurable.
This helps with monitoring suspicious users or wallets and provides greater transparency for the community.
The feature supports browser notifications.
This means:
Open your browser, add the wallet address, and simply keep the browser open.
The tab can even run in the background.
You will immediately receive a notification whenever activity occurs, depending on your configured filters.
XPUB Connector Page (Website) https://cryptix-network.org/cryptix-watch-only-portfolio
This page allows you to use XPUB keys and read the corresponding wallet data.
The Cryptix Messenger will use end-to-end encryption; here is the exact information on how it works:
https://cryptix-network.org/messenger-encryption
Here is the extended information about the upcoming messenger:
https://cryptix-network.org/cryptix-messenger
A hard fork is coming soon, where we plan to introduce payloads and the messenger. The code for the update is already in final testing.
We will also be implementing significant security enhancements, including an autoban system with automatic attack detection for on-chain DDoS, invalid blocks, reconnect spam, dust, and similar issues. Additionally, there will be a feature that optionally (and can be disabled to ensure decentralization) retrieves and uses a banlist from the seed server. This list is provided by the anti-fraud system, meaning the community decides which IP addresses are included. The system is modular, meaning that all nodes react within 60 minutes to new entries. We can add new nodes at any time in case of attacks. However, as mentioned, only nodes (IP addresses) that have been voted on by the community are included. We use this transparently and in a community-driven manner via the anti-fraud system.
Currently, the IP addresses of all Rplant servers will be included, as the exclusion of the pool was decided by the community.
The new update will require a hard fork. After deployment, you will have one week to replace your nodes. Those who do not replace their nodes will no longer be able to connect. This is a hard fork.
The web wallet now supports biometric authentication, such as logging in with a fingerprint. This works across all devices — including laptops, tablets, smartphones, and desktop computers — as long as they have fingerprint hardware. Please note that a modern browser like Google Chrome is required for this feature to be supported.
Regarding security: in my opinion, using this feature slightly reduces security, since the data — including the password — is stored on the device to enable biometric login. However, this is only relevant if an attacker gains access to the device; otherwise, it is not a significant concern. Still, it is worth mentioning.
Ultimately, it comes down to a trade-off between maximum security and convenience.
https://wallet.cryptix-network.org/
The browser miner now has full smartphone compatibility. It can be used for mining on most smartphones (all those we tested), regardless of whether it uses CPU or GPU mining. However, keep an eye on battery life and temperature, as depending on the settings, it can put a heavy strain on the hardware.
The browser Miner has a PWA, meaning you can also install it as an app on your smartphone.
Download: https://browserminer.cryptix-network.org/
This is a larger update, but not a mandatory one. Older versions will continue to run.
However, I highly recommend installing this update.
Changes:
User Interface (UI/GUI): The entire software is now fully responsive, meaning it adapts to different screen resolutions.
The complete interface has been rewritten and now features a full dark design.
Some tabs have been removed or cleaned up to create a more streamlined and modern look.
The software can now also be dragged sideways for a customized window size.
The settings window can be adjusted as well.
New Tools Tab: The Liquity Bot has been moved here and removed from the Dashboard tab.
Miner Tab: Updated Cryptix Miner with the latest version and AMD support.
Up to 3x higher mining speed, also for NVIDIA GPUs, thanks to OpenCL integration.
New configuration options are available in the Settings tab.
The previous 1% developer fee has been removed — now completely fee-free.
Stratum Tab: Now uses the new Stratum Bridge with Stratum v2 support, additional configuration options, and numerous bug fixes.
The Stratum Bridge configuration can now be edited directly within the software via Settings.
Node Tab: Updated to the latest Rust Node version with HFA Fastchain support.
Wallet Tab: The local wallet has been updated to the latest version, also with HFA Fastchain support.
Additionally, there is now dynamic detection of when the wallet process is ready, including for Local Wallet 2 (legacy).
Various smaller improvements and changes.
Please note:
Currently, two features are not working: console auto-scroll and console highlighting (coloring).
These need to be reimplemented due to the new UI and will be included in the next version, which will also feature the Cryptix Miner.
Download: https://github.com/cryptix-network/cryptix-all-in-one/releases

Simple GUI Wallet Standalone (Linux & Windows) Update v.1.0.8
HFA Fastchain Support
Startarguments possible
New Design
Supported launch arguments
--use-local-node
--use-public-node
--node-mode=local
--node-mode=public
--app-port=38477 (you can host it for other Computers)
Download: https://github.com/cryptix-network/cryptix-gui-wallet/releases/tag/v1.0.8
We’ve just crossed the 60% mark. Time flies. This year, the 75% milestone will be reached.
Do you already have enough coins? There will be no additional supply for the next 20 years. What has been mined and distributed is all there will be.
The next reward reduction is scheduled for April 20, 2026, with a decrease of approximately 5.6%.
Thank you to everyone who supports us — as developers, we give our best every day to ensure the long-term success of the project.
A browser extension for Chrome is now available (Firefox, etc., needs to be tested, but it's generally compatible with all browsers).
The browser extension can also communicate with the login/member area, enabling faster login/registration.
It has the same full functionality as the web wallet, can connect your own nodes, and has been tested with HFA/Fastchain transactions. Everything works.
The extension can be downloaded here and manually installed by enabling developer mode. Simply download, extract the ZIP file and click the "load unpack" button for the entire folder under extensions. I will package it later and upload it to the Chrome Extensions section, then it can be installed with a single click.
Download: https://cryptix-network.org/assets/downloads/cpay-browser-extension.zip
Rust Node Update v.0.16.0 / FastChain HFA activation
This update introduces the HFA feature as the first step toward Cryptix Fastchain technology. HFA provides a high-speed system for transaction visibility, making Cryptix CPAY one of the fastest transaction visibility systems worldwide.
The explorer and web wallet are already prepared, and the system is fully active and ready for use.
Read more:
https://cryptix-network.org/hfa-fastchain-technology
The update is not mandatory — existing nodes will continue to function as before, including the Go node.
The system is currently adaptive and optional, and everything remains fully backward compatible.
However, I strongly recommend enabling and using HFA.
HFA
To activate the feature, simply download the new node version (Rust) and start it with the following arguments:
--hfa
Enables the HFA fast rail for this process (this alone is sufficient)
Optional:
--hfa-cpu=
Sets the CPU low-water ratio for HFA (0.0 < value <= 1.0)
Example: --hfa-cpu=0.9
--hfa-microblock-interval-ms-normal=
Defines the HFA microblock interval in milliseconds while operating in normal mode
Default: 50
You can also explicitly disable it if needed:
--no-hfa
Forces HFA to be disabled (overrides config)
Datacenter Mode
There is also a new startup argument to prevent false-positive alerts in datacenter or hosting environments (e.g. due to port scanning):
--datacenter
Download the new Node:
https://github.com/cryptix-network/rusty-cryptix/releases/tag/v0.16.0
An update will be released soon that will activate the on-chain messenger and payloads, but this will require a hard fork. However, we are already nearing the end of development.
The website now displays live data of GitHub activity, allowing users to clearly see whether development is currently taking place. This is intended to ensure transparency. The section is located at the bottom of the roadmap page.
https://cryptix-network.org/roadmap
We took a closer look at the often-cited Nano latency figures (~200 ms), since Nano is frequently described as one of the fastest networks in terms of transaction visibility.
What we found is that these numbers generally represent average or median values under optimal conditions.
The official documentation itself is more conservative and states that confirmations are “typically less than 1 second.”
This is also technically consistent with how Nano works.
Confirmation requires global votes from Representatives, meaning the process is inherently bound to network propagation and round-trip latency, in addition to processing time.
Under favorable conditions—such as well-connected nodes, geographically close representatives, and no conflicts—latencies in the range of ~200–1000 ms are realistic.
In that sense, the lower numbers are not incorrect, but they are context-dependent and somewhat optimistic.
The key difference with our approach is not just about raw speed, but about how that speed is achieved.
Nano achieves fast confirmation through an efficient global consensus process, where nodes gather enough voting weight from the network to reach a decision.
HF-A takes a different approach: the decision in the fast path is made locally within the node, without waiting for a global vote.
At the same time, the system remains globally connected.
Once a transaction is locally accepted, it is immediately propagated to other nodes, making it globally visible very quickly.
The important distinction is that global visibility is not a prerequisite for the local confirmation—it is a consequence of it.
In simple terms: with Nano, confirmation emerges from the network and then becomes visible.
With HF-A, the decision is made locally and then shared with the network.
This shifts latency from a network-bound process to a primarily local one, followed by propagation.
Under good conditions, this allows reaction times in the range of ~10–150 ms.
It is important to emphasize that fast_confirmed is not finality, but a local signal.
Finality remains entirely within the Basechain or future mechanisms built on top of it.
HF-A does not attempt to replace or modify consensus—it strictly improves responsiveness and early transaction visibility.
A common concern is whether such an approach increases resource requirements or leads to centralization.
In this case, it does not.
HF-A is designed as an optional and adaptive system.
Each node continuously evaluates its own conditions—such as CPU load, queue pressure, and network state—and decides whether to participate in the fast path.
Under stress, limited resources, or potential attack scenarios, the system can degrade or fully disable itself automatically, without affecting the Basechain.
This ensures that weaker nodes remain fully functional even if they do not use HF-A.
HF-A also does not increase blockchain data size.
All fast-path state is ephemeral and not persisted, so no additional on-chain storage is introduced.
Likewise, no protocol changes are required—neither a hard fork nor a soft fork.
The feature can be enabled optionally, for example via a flag such as --hfa, and each node operator can choose whether to use it.
Security and abuse resistance were key design considerations.
The system enforces strict bounds on queues, CPU usage, and in-flight work, combined with early and inexpensive pre-checks.
It also includes adaptive mode transitions (normal → degraded → paused), ensuring that under heavy load or attack, the fast path is reduced or disabled before the Basechain is impacted.
In summary, Nano optimizes the speed of global agreement, whereas HF-A optimizes local decision time and then propagates that decision globally.
That shift is what enables significantly lower latency, without introducing new assumptions at the consensus level.
After that, it will be interesting to see how we can make this even faster, speed up the finality process.
One goal would be to deliver finality in 600 ms – yes, that's a very ambitious target.
But when it comes to transaction visibility, HF-A is probably the fastest system in the world, provided it works that well in practice.
Its adaptive and optional nature makes it even more flexible.
In our local subtests, transactions were measurably visible in the web wallet in under 50 ms, with the browser's visual rendering being the bottleneck.
But local is not global (important to understand).
And can someone tell me what Kaspa’s transaction visibility is at 100 ms blocks / 10 BPS?
Is it also 100 ms then?
Test it — I already know the answer because I tested it.
What HF-A is
We are currently researching the first step of the Fastchain, and in doing so we have come across something new, we call it HF-A.
HF-A is a decentralized fast transfer rail built on top of Basechain (base-layer system).
Its purpose is simple: to spread new transactions across the network as fast as physically possible, so nodes, wallets, and applications can see and react to them immediately.
HF-A does not change Basechain consensus, block production, or finality. Basechain remains the only settlement layer.
What HF-A changes is when a transaction becomes useful — it becomes visible and usable almost instantly, instead of only after confirmation.
Why it matters
In many systems today, transaction visibility is still too slow in practice.
Even if confirmation is relatively fast, users and applications often have to wait before anything meaningful can happen.
HF-A introduces a decentralized fast path for normal transactions, enabling:
- immediate network propagation
- instant wallet visibility
- real-time application response
- a significantly smoother user experience
Instead of waiting for confirmation before anything happens, transactions can already be seen and acted upon.
The core idea
Make transactions visible and usable as early as possible, while keeping final settlement on Basechain.
This shifts the focus from “when is it confirmed?” to
“when can it already be used?”
How HF-A differs from Lightning-style systems
Lightning and similar systems rely on payment channels, liquidity, and off-chain state.
HF-A does not.
- no payment channels
- no liquidity requirements
- no off-chain transaction model
The base-layer transaction remains unchanged.
HF-A simply accelerates how it propagates, gets validated, and becomes visible across the network.
What we are building
HF-A is the first step toward a broader Fastchain approach. Further steps in Fastchain will then involve finalization/execution.
The goal is to make transactions faster in practice without modifying the core blockchain or introducing unnecessary complexity.
In theory, HF-A can be integrated without requiring a hard fork, depending on implementation.
It is designed to:
- avoid block spam and artificial throughput inflation
- remain fully optional
- work alongside existing nodes without disruption
- stay accessible even for weaker nodes
HF-A is a real performance improvement, not a marketing-driven “high BPS” system.
HF-A vs. Kaspa and Nano
Kaspa and Nano emphasize different metrics:
- Kaspa: ~1 second transaction visibility (despite ~100 ms block time / 10 BPS, based on available public figures)
- Nano: ~200 ms transaction visibility (among the fastest publicly documented systems)
HF-A targets a different layer entirely:
pure propagation speed and earliest possible visibility
Because HF-A does not depend on confirmation, its latency is primarily bounded by network conditions:
- same node / local environment: ~1–5 ms
- national node-to-node: ~30–50 ms
- international propagation: ~100–150 ms (theoretical range)
This means transactions can be seen and reacted to as soon as they propagate, rather than after a confirmation step.
The result is not just faster confirmation metrics—but a fundamentally faster user-perceived experience.
One-line summary
HF-A is a decentralized fast transfer rail that makes Basechain transactions visible and usable almost instantly—without changing consensus, requiring a hard fork, or compromising the network’s design.
And the system is intelligently designed; in theory, it's as fast as possible. There’s no faster way because it would then be limited by global latency / internet connection.
This means that if global latency improves, HF-A will automatically become faster as well. It operates at its maximum capacity.
HF-A principles
HF-A:
- There will be no finality falsification.
- There will be no smuggling in a second consensus under a new name.
- There will be no attempt to market with artificial BPS / blocktime figures.
Instead:
- Settlement remains on the basechain.
- Fast is local / optional / bounded.
- Under load, the chain always wins.
- Fast can die, but not the basechain.
For Developers: HF-A Technology: Instant Transaction visibility
The Explorer and database system have been redesigned. The Explorer can now deliver data even faster, even for very large wallets with very large transactions/UXTOs. Previously, this could take a considerable amount of time, for example, with pooled addresses. This should now be fixed.
The entire REST API is now significantly faster for all accesses.
The old faucet has been revamped. It's a shame it was offline for so long.
The design has been updated, the interface simplified, and new protection features against DDoS attacks, payload attacks, etc., have been added.
It's limited to 3 coins (not much, but it's free) per address, user, browser, and IP address. There's also a cooldown period: one faucet transaction every 15 minutes. This makes it less susceptible to exploitation.
We're leaving it online for new users, etc. Please use it responsibly.
Ftw: The Discord Faucet was reduced yesterday from 1-20 coins to 1-10 coins to create an average of 1 block per day, per user.
https://faucet.cryptix-network.org/
There is now a public Javascript integration for the OX8 hash.
https://github.com/cryptix-network/cryptixhash-v2/blob/main/Cryptix-OX8_JS.js
The browser miner now also supports GPU (WebGPU) and not just CPU.
Is it fast? Not as fast as a proper native mining software. But still faster than the old Cryptix Miner version ( +20 - 40%) .
If you want to test it, experiment with the scan iteration values for optimal performance. For a browser miner that doesn't require installation, it actually works quite well.
But it's more of an experimental experience.
https://browserminer.cryptix-network.org/
The web wallet now supports browser/device notifications. If this feature is enabled, you will receive notifications when you receive coins.
This can now be enabled in the options. Important: You must first grant the necessary permissions on your computer.
Press this Button "Request Notification Permission" to give the Webwallet the Permission.
You will only receive a notification if the web wallet is not visually open, i.e., if you are in another tab.
The new website is live. This was a lot of work. A lot of unnecessary stuff was removed or restructured. In addition, the entire design has been replaced and rebuilt from scratch. Quite a lot has changed.
However, it’s not completely finished yet—there’s still quite a bit to do. There are simply too many pages and too much data—but it’s already much better now. What do you think of it?
The colors and design of all modules were also adjusted again, including Explorer, Webwallet, Cryptix Card, Memberarea, Dashboard, etc.
Also:
I’m now back working on the Cryptis Miner. There are still some bugs in the HiveOS scripts, which I’ll fix and test soon. The miner already works in the Linux console and on Windows, so if anyone wants to test it, go ahead.
The All-in-One will also get an update, as the Cryptix Miner will be replaced, along with the Stratum Bridge. I’ll probably take the opportunity to redesign everything and make some structural changes to modernize it and align it with the website, etc. I might also integrate the Cryptis Miner directly as an optional miner.
The pool still has a few bugs in the data display and needs further optimization for database access
The Near Future - We are currently at an important turning point in the project
Let’s take a look at the coming weeks and months.
The Cryptis Miner is now ready for prerelease. The necessary files have already been uploaded to GitHub for Linux, Windows, Hive, and MMPOS. At the moment, there is still a bug related to flightsheets in HiveOS that I am actively fixing. Once that is resolved, I will officially announce the prerelease. Anyone who wants to test it already can do so via the Hive console, Linux, or Windows.
It’s important to note that full CUDA and OpenCL installations are required, as the miner is built with portable programming in mind to achieve maximum hardware compatibility. While both CUDA and OpenCL are available for all hashing algorithms, CUDA is not yet fully optimized. Therefore, it must be enabled manually using the `--cuda-experimental` flag. In general, most hashes are only partially optimized at this stage. For the full release, performance improvements and additional algorithms will follow. That said, OpenCL with OX8 and CUDA/OpenCL for Hoohash are already in a solid, well-optimized state.
Regarding security, there have been several DDoS and hacking attempts recently. On Webwallet 2, someone attempted what could be described as a console log attack, specifically log injection or log flooding. This attempt was unsuccessful, mainly because I had already anticipated such scenarios in advance. However, I still tightened the protections further afterward.
More interesting were the attacks targeting the REST API. In this case, someone abused search engine crawlers to generate unnecessary requests on the address endpoints, which are computationally expensive. These requests appeared to originate from various search engine server IPs, which initially made the situation confusing. It took some time to understand why these IPs were involved and why the robots.txt rules were being ignored. In the end, the issue was identified and resolved. I have to admit, though, it was quite a creative approach.
The mining pool was also targeted by typical DDoS attacks. These have since been mitigated as well. While the attackers were not able to overload or crash the server due to existing protections, they did manage to occasionally cause small database lags of about one to two seconds. This, in turn, sometimes resulted in invalid nonces. This issue has now been fixed, even though the attacks themselves are still ongoing. I will continue strengthening the blocking mechanisms, but it was expected that the pool would be targeted immediately after going live.
The website also requires a significant overhaul. The design needs to become cleaner and more structured, similar to the explorer and web wallet, moving towards a consistent corporate design rather than a playful one. Additionally, a lot of the content needs to be reorganized, cleaned up, and updated. This process has already started. It is a considerable amount of work, but it will be completed and published soon.
Fusion, the member area, and the DEX will also require updates later on. The database system needs to be reworked, and the interface should be optimized. However, this is currently at the very end of my priority list. I have not yet decided whether I will address it directly after finishing the website or push it further back, since everything is still functioning as it is.
There are also some bugs in the explorer and the web wallet. The web wallet occasionally deletes the transaction list after pruning, even though it should not. The explorer, on the other hand, needs a more accurate display of incoming and outgoing transactions. When using a daemon, the current display can sometimes be incorrect or buggy. These issues also need to be addressed soon.
Once these points are completed, the off-chain side of the project will be in a state where it is fully usable and user-friendly. After that, only smaller updates, upgrades, and bug fixes will be necessary from time to time.
This brings us to the next major step: on-chain and node development.
With the experience I’ve gained through working with RIFT and developing the mining software, I’ve been able to significantly refresh my Rust knowledge and deepen my understanding of consensus mechanisms. Originally, my plan was to introduce a large hard fork that would include smart contracts and many other features all at once. However, I’ve realized that this approach is not ideal. It is too large, too risky, and increases the likelihood of security vulnerabilities and critical bugs, even with extensive testing.
Instead, we will split this into multiple hard forks that will follow each other relatively closely. The current codebase will serve as a foundation and reference, but the individual features will be rewritten cleanly and tested thoroughly, step by step. This process should not take excessively long, since we already have a working base to build upon.
The first step will be the introduction of payloads and an on-chain messaging system. This will also require updates to the web wallet and related components, so it is already a substantial amount of work on its own. From there, we will continue adding further features incrementally until everything is in place.
Another proposal from a developer was to completely rewrite the entire codebase and eventually phase out the Go node. This approach would also allow us to fix fundamental issues in the current implementation, such as incorrect mass calculations and other structural problems. It raises the question of whether the Go node should be maintained alongside or removed entirely in the long term.
At this point, it is becoming increasingly clear that the chain implementation in Rust should likely be rewritten from scratch. The current code contains too many issues, unfinished components, and in some cases, serious misimplementations. The wallet daemon, in particular, is highly unstable and frequently freezes during normal usage because it was not built robustly. Fixing it incrementally is not an efficient solution — it needs a proper rewrite in Rust.
The goal is to rebuild everything properly and professionally, not just something that “somehow works,” but a system developed with attention to detail and long-term stability in mind. This situation is similar to what we’ve seen with the explorer, web wallet, database filler, and other components — they function, but from a development and robustness perspective, they are far from ideal. Unfortunately, this also applies to parts of the Rust chain code, even if not to the same extent as the off-chain components. Here I would describe the transition as: "works somehow" → "is being seriously built"
To avoid going too far into detail: we will begin with the first hard forks while keeping in mind that a complete node rewrite is likely necessary. It is possible that work on this rewrite will begin in parallel, but it is important to understand that this is not a small task. It would require going through the code file by file, function by function, all while the chain remains live. This is complex, but achievable. However, it should come after the initial hard forks and new features like the messaging system are in place.
There are also many additional ideas planned, such as privacy features, although their implementation is not yet guaranteed. These would likely need to be separated from the core chain design.
The key takeaway is that the off-chain side is now close to being fully complete and properly structured, with only a few remaining adjustments and improvements. After that, the focus will shift entirely to on-chain development — potentially even to the point of fully replacing the existing node code with a clean, professional, and efficient implementation.
But to put it simply: Let's move from off-chain to on-chain, with full focus. Off-chain will be finished soon.
NOTE: THIS IS NOT THE CRYPTIS MINER (comes later)
Features
CPU and GPU mining
Local mining via 127.0.0.1
HTTP mining via node web address
Stratum pool mining
Stratum bridge support
CUDA support (NVIDIA)
OpenCL support (AMD / NVIDIA / Intel / iGPU)
No dev fee (0%)
-CPU optimizations
Startup
The miner initializes OpenCL by default on all available devices (NVIDIA, AMD, Intel, iGPU).
If OpenCL fails, it automatically falls back to CUDA (NVIDIA only).
OpenCL is currently the preferred backend, as it has received the latest optimizations and provides strong performance across all supported hardware, including NVIDIA GPUs.
CPU performance has also been significantly improved.
Notes
OpenCL performance is highly optimized and works across all major vendors
CUDA is still supported but has not received recent performance updates (only +100% Speed, but half of opencl)
AMD support has been added and is a major improvement in this release
Development Status
There are no developer fees.
Active development of the miner has been discontinued.
This release was created to provide a stable, all-in-one solution with competitive performance.
Binaries
Linux / HiveOS / Windows build is already available
The All in One software will receive this version in the next update. Anyone who wants to test it immediately only needs to download the Windows ZIP folder from GitHub and insert the contents (all individual files, not the entire folder) into the \include subfolder of the All in One software. Then it will work right away.
Download:
https://github.com/cryptix-network/cryptix-miner/releases/tag/v0.2.10
I've now added a clean version of CUDA, GO, and C#. If anyone needs it, it's accelerated and ready to wire up.
https://github.com/cryptix-network/cryptixhash-v2
I'm currently finalizing the update for the old Cryptix Miner:
OPENCL upgrade for AMD / NVIDIA / Intel / Onboard GPUs (accelerated version, not a slow one)
Stratum v1 support for Stratum Bridge
New accelerated Rust integration for CPU mining
The developer fee will be removed, so it will be free to use permanently.
This will be the last update for this software. It will then offer everything, such as Stratum Bridge support, direct node mining, AMD + NVIDIA, etc., at sufficient speed.
After this update, the software will be discontinued, but it will remain free to use.
If anyone needs the accelerated OPENCL integration, I have uploaded it publicly here and it can be used freely, so MIT.
https://github.com/cryptix-network/cryptixhash-v2/blob/main/Cryptix-OX8_OPENCL.cl
Nushypool has released mining software. This includes Cryptix/OX8. As far as I understand, it's also compatible with AMD.
https://github.com/nushypool/npminer
Triple mining with 1 CPU hash and 2 GPU hashes (core + memory GPU hash) works as well.
To clarify:
Hybrid mining (1 CPU hash + 1 GPU hash):
On the CPU side, I do not see any reduction in hashrate. It stays the same.
It makes no difference whether it is single CPU mining or hybrid mining, meaning CPU + 1 GPU hash.
The same applies to the GPU.
Single GPU mining produces the same hashrate as hybrid mining, meaning 1 CPU + 1 GPU hash.
Triple mining is different:
The CPU hash does not get slower. However, both GPU hashes — core and memory — are noticeably reduced. That also makes sense, since the kernel is being shared.
It took a huge amount of tinkering to get this running without crashes.
But the current result is:
The core hash drops by around 50%.
The memory hash drops by only 30–40%.
That means 50% + 60/70% results in a profit increase of around 10–20%, even in its current unoptimized state.
And this is on a very old GPU (1080 Ti), using OpenCL on an Nvidia card — basically the most suboptimal conditions possible.
I am currently working on CUDA, which in theory should perform better on Nvidia.
Modern GPUs can handle more batches, so it should improve further there as well.
But yes, it works — and it already delivers a meaningful profit increase.
I should add that this is not optimized yet, and there is still a lot of room for improvement.
What matters most to me is that it works on as many GPUs as possible, including old and low-end ones, and that it runs as stably as possible.
That is already the case now.
So there is still plenty of upside.
https://cryptis-miner.cryptix-network.org/
The dashboard has been updated to version 3:
Upgrades:
- Nushypool and Baikalmine can now be linked as pools
- API for Cryptix Community Pool updated
- A RAM overflow bug, causing the dashboard to consume too much RAM over time, has been fixed
- The dashboard now requires fewer connections for data; everything has been consolidated
- The new WebSocket server has been connected; it is more secure and better
- Lazy loading has been implemented; connections are now closed and the dashboard goes into standby mode when the tab is switched
- The market view now also displays the latest Safetrade trades. Additionally, trades and open orders are directly tagged with Exbitron or Safetrade
- The style has been modernized
https://cryptix-network.org/cryptix-dashboard
Let’s talk about the future of PoW and mining.
Right from the start: it doesn’t look good. It feels like mining is slowly but steadily dying – at least in the form we know it today. Maybe a few large ASIC-based projects will continue to exist, like Bitcoin. But small and mid-sized projects, especially CPU and GPU mining, will most likely disappear.
Of course, I can’t see the future. But this is my long-term perspective.
Before I continue: I didn’t start Cryptix as a PoW fair mining project for no reason. I’m a passionate miner myself. I didn’t spend months working with other developers on a mining pool and building mining software for nothing. I am a miner. I support PoW.
But that doesn’t change the fact that the era of PoW is probably coming to an end. Even if I wish it wasn’t.
Over the past weeks, I’ve talked to many other developers in the PoW space. Blockchain developers, pool operators, OS developers, mining software developers. And almost all of them agree: PoW has no future. Continuing to build on it is a waste of time.
And yes – I share that opinion. Yet I still built the pool and continue working on mining software. Maybe because I still hope it somehow works out.
I’ve even been asked by developers of upcoming projects whether it still makes sense to launch with PoW. My answer was clear: no. Absolutely not. Not for a serious project with real development behind it. Maybe for those copy-paste projects that live for a week and disappear. But not for something long-term.
So why is that?
The main answer is simple: user and miner behavior.
The entire culture has become toxic. Miners often behave as if developers are working for them. Disrespect and lack of appreciation have become the norm. And it’s so normalized now that you can barely criticize it anymore.
Many miners act like developers belong to them. Like they are supposed to deliver everything for free. Like a project must provide exactly what they want. And even if it does, there’s no appreciation. Only complaints when something isn’t right.
Freshly mined coins are almost always dumped immediately.
It doesn’t matter if the profit is tiny.
It doesn’t matter if the project gets damaged.
It doesn’t matter if developers spent years building it.
It simply doesn’t matter. There will always be another project.
And that leads to the next problem.
There are now actual operators – yes, real ones – who just keep launching new projects every couple of weeks. Fork, new name, new logo, done. Sometimes even multiple at the same time, running on the same servers, same infrastructure.
Why?
Because it works.
They make maybe $1,000–$2,000 per project. Launch several per week. Minimal effort. And it’s more profitable than building a real project.
The crazy part is: these projects often get more miners and more attention than real development projects. Their coins are sometimes even held longer than those from projects that have been developed for years.
That’s the reality.
That’s what the market rewards. And that’s why it keeps happening.
Honest, long-term projects die. Short-term projects extract value and disappear. And a week later, the next one appears.
It sounds insane.
But it’s real.
And even when a project actually has real development and survives longer, the next issue comes in: exploiters, botnets, large data centers. They show up, extract every possible dollar, and move on.
PoW mining today feels like a swarm of locusts. They arrive, consume everything, and move to the next field.
The problem is: there are fewer and fewer fields left.
And the locusts are getting hungrier.
This leads to a situation where even small projects get attacked aggressively. A few years ago, it would’ve been unthinkable for large farms to target small-cap projects. Today, it’s normal. Because there’s not much left to extract.
Most of the ecosystem has already been drained. Now they are feeding on what remains.
So where does PoW go from here?
Honestly: probably nowhere.
It’s a model that is slowly dying. Not because of the technology – but because of behavior.
The only projects that might survive are large ASIC-based ones. Because they can protect themselves better. Because they can limit botnets and opportunistic miners.
But that’s not a solution for small or mid-sized projects.
The alternative? PoS or similar systems.
And that’s exactly where everything is moving.
I’ve talked to many developers, and this is a widely shared opinion.
There are many more examples I could mention, but they wouldn’t change the conclusion.
Look at real projects. This isn’t just about Cryptix.
Take Xelis. Active developer, constant work, active GitHub. Still, the value goes down. Or look at projects that have been building for years with dedication, yet never see real success.
And then you see comments like: “the developer is broke.”
That’s not a joke. That’s reality.
Developers earn nothing.
I can confirm this from my own experience: I haven’t made a single dollar in profit. In fact, I’m at a loss. Servers cost money. Infrastructure costs money. Time costs money.
I’m literally paying to work. And on top of that, sometimes dealing with disrespect.
That’s the reality for many developers.
Look at donation wallets. Maybe a few hundred dollars over a year. And a large part of that often comes from the team itself.
Meanwhile, miners and traders sometimes make significant profits. Thousands in a single day are possible. But support for the project? Almost none.
The system is completely unbalanced.
At the end, there are only three paths:
You work for free and slowly burn out.
You create short-term copy-paste projects and make quick money.
Or you move to PoS/ICO and secure funding.
That’s the reality.
And it exists because users and miners have shaped it this way.
If this behavior doesn’t change, the remaining projects will disappear. And then there will be nothing left to mine.
And then people will say: “There’s nothing good left to mine.”
Yes – but why?
Where is liquidity supposed to come from if everything gets dumped instantly? Where is value supposed to come from if no one thinks long-term?
And one more thing: when someone makes profit, someone else takes the loss. Crypto is not a magic system. If investors get burned, they don’t come back.
Another point: miners often say they “secure the network.”
No, not really.
Projects can secure themselves in other ways. ASICs. Alternative consensus mechanisms. Different structures.
PoW is not a necessity. It’s a choice.
And if projects offer CPU/GPU mining, that’s actually something they do for you – not something they owe you.
I’m not saying this as an outsider.
I mine myself. I love mining. I built mining software with passion.
But this is my honest view of the current PoW world.
And finally: no, there are currently no plans to move Cryptix to PoS. We are staying with PoW for now. This is not an announcement.
And to all developers out there:
Stay strong.
The new community pool is now online.
The pool system is completely custom-developed in state-of-the-art Rust and is unique. It's designed for high performance, stability, and security—even against pool exploits.
Happy mining!
https://pool.cryptix-network.org/
It will still take a few more days before I release the Cryptis Miner. I decided to make the software properly right away instead of pushing out some half-finished release. That said, I will still publish a pre-release, otherwise it would take forever.
What has changed since the last update:
OX8 mining has been optimized again on both CPU and GPU, and the hashrate is now even higher. For example, on a GTX 1080 Ti it went from around 41–42 MH/s to 43 MH/s.
Hybrid mining with CPU and GPU at the same time has been improved further. It is now possible to mine on the CPU simultaneously without reducing the GPU hashrate. We solved this through core reservation and different kernels / Rust functions.
Additional hashes have been added, for example RandomX for Monero and Zephyr.
Autolykos 2 for Ergo and related coins has also been added.
This means the following will be possible:
CPU only
OX8 (Cryptix)
RandomX (Zephyr, Monero, and others) — including HugePages and MSR functions
GPU only
OX8 (Cryptix)
Autolykos 2 (Ergo and others)
Hybrid mining (CPU + GPU, without reducing GPU hashrate)
OX8 on CPU + OX8 on GPU
RandomX on CPU + OX8 on GPU
OX8 on CPU + Autolykos 2 on GPU
RandomX on CPU + Autolykos 2 on GPU
What I am currently researching is triple hashing:
I chose Autolykos because it is a memory-hard hash that uses relatively little core / ALU performance. So it is basically the opposite of Cryptix OX8, because our hash uses little memory but a lot of core performance.
That means I want to combine them so the same GPU can mine Autolykos 2 and OX8 at the same time, without significantly reducing the OX8 hashrate.
If that works, triple hashing would also become possible through:
OX8 + OX8 + Autolykos 2
or:
RandomX + OX8 + Autolykos 2
This would be a major advantage for many users, because it gets the maximum profit out of the hardware. Especially for rented rigs on Clore or similar platforms, this could be a strong advantage. On Clore, you do not pay extra for electricity anyway, and you also do not really have to worry about cooling or hardware wear. That means renting becomes even more profitable.
But not only there — anyone with well-cooled rigs and cheap electricity could also run the hardware at maximum capacity.
Another advantage is that I currently do not know of any software that allows three hashes at the same time without them heavily slowing each other down. So this would also be a clear sign of strong technology and good implementation.
Whether I release the triple hashing right away depends on the tests. The integration has already started. The individual hashes are all finished as well (though not fully optimized yet), but they are already usable for a release.
All hashes are also already available in CUDA. CUDA itself is basically finished too, but OX8 is not yet optimized for speed there, so it is not really usable yet. However, my OpenCL integrations work on all hardware, meaning AMD, Intel, NVIDIA, and even onboard GPUs.
- Timestamps added for V2 Stratum
- V2 Protocol longtime tested
- Retarget time configuration option
- New Grafana Json by (Note: I haven't tested it, I only checked that the code is clean.)
@HashSlingingSlasherNW
For developers, there is information on how the Stratum v2 protocol for Cryptix is structured:
https://github.com/cryptix-network/cryptix-stratum-bridge-v3/blob/main/STRATUM_PROTOCOL_INFO.md
Stratum has now been modernized and is fully usable, including with stratum v2.
https://github.com/cryptix-network/cryptix-stratum-bridge-v3/releases/tag/v1.2.3
The optional visual interface for Stratum Bridge has been fixed and now works better. It has also been visually improved.
There is also a compiled binary/executable version that can be run directly, eliminating the need to have Python installed on your computer.
https://github.com/cryptix-network/cryptix-stratum-bridge-browser-monitor
Cryptis Miner, the new Stratum Bridge, and the upcoming community pool will support Stratum V2.
Here is a quick explanation of what that means.
Stratum V1 is the older mining protocol used by most pools today.
In V1, the pool builds the block template and selects the transactions, while miners only provide hash power.
Stratum V2 is the newer generation of the protocol.
It focuses on better efficiency, security, and giving miners more control.
Stratum V1:
Uses JSON text messages
Usually not encrypted
Pool controls the block template and transactions
Stratum V2:
Uses a binary protocol instead of JSON
~60–70% less bandwidth usage
Better performance on high latency or unstable connections
Lower CPU usage on mining devices
Can reduce stale shares
Encrypted communication by default
Protection against man-in-the-middle attacks
Hashrate integrity protection
With Job Negotiation, miners can build their own block templates, which can improve decentralization
Recommendation:
If you have the option to use Stratum V2, we recommend using it.
We specifically implemented full V2 support in:
the Stratum Bridge
the community pool
the new Cryptis Miner
However, Stratum V1 will still be supported so older mining software continues to work normally.
Important notice about Cryptis Miner:
Cryptis Miner does NOT allow mining on rplant.xyz
(including subdomains or server IPs).
Due to ethical concerns regarding the operators, the software will terminate immediately on startup if such a pool is detected.
Mining on Rplant is therefore not possible, but mining on all other pools is fully supported.
It is hardcoded in the software's code; when attempting to connect to an Rplant server or domain, the software will display an error and will not start.
This restriction applies to all algorithms and coins that Cryptis Miner will support in the future.
The Stratum Bridge has been updated
- Modernization of legacy code
- Fixed faulty code and functions
- Numerous bugs have been resolved, including an issue where no data was displayed for miners without a worker name, and several other fixes
- Added support for the Stratum v2 protocol while remaining fully compatible with Stratum v1. Cryptis Miner will support both v1 and v2
The Stratum Bridge is compatible with OZM Miner, Cryptis Miner, and Cryptix Miner. I have now updated Cryptix Miner to support the Stratum Bridge; I just need to compile the bins.
I recommend this update to everyone using the Stratum Bridge. The previous version will continue to function, including with Cryptis Miner, but updating is encouraged.
https://github.com/cryptix-network/cryptix-stratum-bridge-v3/releases/tag/v1.2.1
When I originally wanted to write the OX8 hash for the miner using OpenCL, I couldn’t find any publicly available optimized code implementations of Blake3 or SHA3 / Keccak.
Because of that, I had to implement them myself. So that other developers don’t have to go through the same struggle, I’m sharing my code for it publicly:
Sha3_256:
https://github.com/cryptix-network/sha3-256-opencl-32b
Blake3:
https://github.com/cryptix-network/blake3-opencl-32b
Keccak:
https://github.com/cryptix-network/keccak-f1600-opencl
I’ve optimized and stabilized the Cryptis Miner again.
On my GTX 1080 Ti (without any overclock settings), the ox8 hash now runs stably at a peak of 40.5–41.5 MH/s.
If you manually adjust the autotune settings slightly (this is not overclocking, it’s something different), you can push it up to a peak of about 41.5–42.5 MH/s.
The OZM Miner once showed 45 MH/s at startup, but that only happened once. When I wait for the second measurement, it consistently reports 40.2–40.5 MH/s and stays around those values.
This means that on Nvidia GPUs using OpenCL, Cryptis Miner is now faster than OZM Miner. Not by a huge margin, but still noticeably. Of course, everyone should test this on their own GPU.
OpenCL slows down my older Nvidia development GPU quite a bit. On more modern cards, the performance gain will likely be even higher. AMD GPUs benefit heavily from OpenCL, which means they will probably become the most efficient GPUs again — which is fair, considering they weren’t supported for about a year. However, the efficiency difference between Nvidia and AMD should not be very large; I estimate around 3%.
But all of this still needs to be properly tested.
Let’s talk about pool systems, and especially about Miningcore:
Miningcore used to be a good way to obtain free open-source software and quickly and easily host your own mining pool. At the time, many years ago, the software was modern and matched the standards of the cryptocurrency ecosystem — around 5–6 years ago.
Miningcore still exists today and is used by many pools because it is free and supports many different coins. But now we come to the problematic information. To my knowledge, the original developer stopped maintaining Miningcore about four years ago. Why? I heard (though I cannot confirm if it’s true) that it was because maintaining it required a huge amount of work and nobody supported the developer’s efforts. There were no donations, meaning the appreciation for the time and work invested was missing. As I said, I do not know if this is the real reason or what exactly led to the decision.
As a result, the system was no longer actively developed by its original creator. Because it is open source, other developers continued working on it and added new coins and features. However, this led to many problems, because the extensions were often not implemented professionally and were not properly reviewed. Too many cooks spoil the broth — that’s already a problem. But too many people cooking who aren’t chefs is an even bigger one. The result: Miningcore is broken. It can’t even be compiled on Windows anymore because the console gets flooded with errors. I looked at some of the issues myself, and some were so ridiculous that they were simply duplicate import errors — for example (I believe), after the integration of FishHash or something similar.
But that’s not the only issue. Even if it did compile, the system would still be broken. It has an incredible number of security vulnerabilities — and we are not talking about small ones, but fatal ones. There are duplicate payout bugs, missing proper nonce validation, mining with incorrect hashes, incorrect difficulty detection — the entire system is exploitable in multiple ways. We experienced this ourselves in the past when pool exploiters appeared and people were able to mine with scripts or submit duplicate shares or wrong-difficulty shares using certain SRBMiner features. Many pools — including those for Cryptix and many other coins — used Miningcore at that time. The problem, however, was within the pool system itself; the blockchain or consensus mechanism cannot fix such issues.
In addition, the system is poorly protected against DDoS, payload attacks, and similar threats. Even basic script kiddies can cause the server to lag, increasing latency and costing miners rewards. And speaking of latency, even when nobody is attacking:
Another major problem is that Miningcore is heavily overloaded. The latency is extremely high, which results in fewer blocks and rewards being found and creates many stale blocks. There are several reasons for this. Because Miningcore is overloaded, filled with errors and warnings, and uses inefficient functions, the compiler and runtime environment struggle to operate efficiently. Even beyond that, the architecture itself is bloated. Miningcore is written in C#, which is an excellent programming language — we also use it for our all-in-one software. However, it is not designed for ultra-fast latency and real-time responses because it uses a garbage collector. For coins with a 2-minute block time this may not be a major issue, but for coins with faster block times it becomes a serious problem. Blockchains and coins have become much faster in recent years. We are talking about potential reward losses of 10–20% due to these issues. These are catastrophic numbers that directly cost miners money.
There are many more things that could be mentioned, but these are the most important ones.
A professional pool operator should no longer rely on Miningcore. That’s why shortly after the release of the Cryptis Miner, we will also release a new pool system. This new system has been completely developed from scratch in Rust. Every line of code is our own work, without building on other systems or using external code. In addition, the pool is designed to be 100% aligned with the blockchain itself. The Cryptis Miner will also be fully optimized to work with this pool system.
And finally: despite everything, Miningcore was still a great contribution. Providing such a comprehensive piece of software as open source was a significant effort. Many pool operators earned a lot of money because of it. Why did none of them support the Miningcore developer with donations for the work and effort involved? Think about things like that as well — nothing should be taken for granted.
The new website for the mining software is:
https://cryptis-miner.cryptix-network.org/
The mining software includes a benchmark feature that transfers hashrates and hardware data, similar to other mining software. This feature can be disabled.
There is also an automatic comparison feature that shows miners in both the console and the browser how efficiently their GPU is optimized. Everything works fully automatically, so users can immediately see whether their overclocking settings are correct without having to search for the best values themselves.
In addition, there is a public data overview that automatically displays the best GPUs, CPUs, and their benchmark data. This allows everyone to compare hardware and also review overclock settings. Of course, it will take some time until enough data has been collected.
https://cryptis-miner.cryptix-network.org/bench
There is also a REST API so websites and services such as Hashrate.no can receive accurate and up-to-date data. At the moment, some websites are still using outdated data from the old hash. Now there is a proper data source available for such websites and services:
https://cryptis-miner.cryptix-network.org/api/v1/overview
Example of an external website still showing outdated data:
https://hashrate.no/coins/cpay
Cryptis Miner is a newly developed mining software optimized for the Cryptix network and designed for high efficiency and stability across CPU and GPU hardware.
CPU Performance
Test system: AMD Ryzen 5 5600X
Current performance: ~1400 KH/s using 10 cores.
For comparison, Cryptix Miner achieves around 800 KH/s on the same CPU and core count.
This results in roughly an 80% performance increase on CPU.
GPU Performance
Test GPU: NVIDIA GTX 1080 Ti.
Cryptix Miner (unfinished): ~40–41 MH/s using OpenCL.
Cryptix Miner (CUDA kernels not yet implemented) is expected to reach around ~50 MH/s once CUDA support is completed.
For comparison on the same GPU:
Cryptix Miner: 8–9 MH/s (CUDA)
OZM Miner: 43–44 MH/s (CUDA)
Because CUDA is specifically designed for NVIDIA hardware, it can often provide up to ~20% higher efficiency compared to OpenCL. However, newer GPUs may perform better with optimized OpenCL implementations, which could allow Cryptis Miner to outperform CUDA-based miners on certain hardware.
AMD GPUs
AMD GPUs are expected to benefit significantly from OpenCL support and may achieve very strong performance. More benchmarking across different AMD cards is still required.
Intel and Integrated GPUs
Intel GPUs and integrated GPUs (such as laptop GPUs) are supported. Performance data is still limited and will become clearer after wider testing.
Features
The miner already includes support for:
CPU-only mining
GPU-only mining
CPU + GPU hybrid mining
Multi-CPU support
Multi-GPU support
Mixed GPU rigs (AMD and NVIDIA in the same rig)
Operating Systems
Supported systems include:
Linux
Windows
HiveOS
Architectures supported:
x64
x86
ARM
macOS is technically compatible but will not receive official compiled builds or distribution.
Network and APIs
Stratum v1 and Stratum v2 support
TCP and TLS connectivity
Hive API support
Extended miner API
Monitoring
Cryptis Miner includes a built-in web-based HTML dashboard that can be accessed directly through a browser for monitoring and management.
Auto-Tuning
An automatic GPU tuning system is integrated, allowing the miner to detect and apply optimal settings automatically for each GPU.
Stability and Accuracy
A key focus of Cryptis Miner is stable hashrate performance. The miner shows extremely low fluctuation and maintains consistent output during operation.
Unlike some mining software, Cryptis Miner does not include rejected or invalid shares in the displayed hashrate. This ensures that the reported hashrate closely reflects the real pool-side performance rather than inflated short-term calculations.
In internal testing, no invalid hashes have been observed so far. Stale shares are expected to remain minimal depending on network connection quality.
Optimization for Cryptix
Cryptis Miner is specifically optimized for the Cryptix protocol, including correct handling of nonce validity periods and other network-specific details.
It is also designed to work seamlessly with the upcoming new Cryptix community mining pool, which uses newly developed pool software built specifically for Cryptix nodes, technology, and DAG structure.
Both the miner and the upcoming pool software are fully in-house developments built from scratch using modern technologies.
Release
The first version of Cryptis Miner is expected to be released soon.
Developer Fee
1%
The miner is a private project and will later support multiple coins and hashing algorithms. The software will not be open source.
We have developed a browser miner that uses WASM (WebAssembly) to enable CPU mining directly in the browser. This means mining can be performed without downloading or installing anything, and it works on any device with a web browser.
The browser miner supports Stratum, which allows mining either on a local node with a Stratum bridge or on any public mining pool.
Please note that the browser miner is primarily experimental. Compared to dedicated mining software, the performance is significantly lower.
https://browserminer.cryptix-network.org/
There is now also a ready-made WASM file for the Cryptix OX8 hash, which allows mining tasks to be made available in the browser.
https://github.com/cryptix-network/cryptixhash-v2/blob/main/Cryptix-OX8_wasm_bg.wasm
Over the past few days, several updates have been implemented across the frontend and backend services.
Web Wallet
• Translations are now fully completed for: English, German, Spanish, French, Chinese, Russian, Turkish, Japanese, Arabic, Spanish
• New languages added (translations started): Italian, Dutch, Korean, Vietnamese, Hindi, Indonesian
• The wallet now automatically detects the browser language and displays the correct language if available
• The language can still be manually changed and saved via the footer
• Fixed a bug when switching languages
• Added the new header and footer from our updated branding design
Anti-Fraud System
• Implemented a new database system
• Improved DDoS protection and caching
• Updated to the new branding design (header & footer)
• Image uploads are now deeply scanned for viruses, including file magic byte validation
• Added a Service Worker
Landing Page
• Added new DDoS protection and caching to reduce server load
• Design improvements
Security Blog
• Updated with the new branding design (header & footer)
• Increased DDoS protection and XSS/infection protection
• Image uploads are now deeply scanned for viruses, including magic byte validation
• Added a Service Worker
Dashboard Chat Server
• Fixed a bug where after a server restart the username appeared as already in use
• Input validation strengthened
• DDoS protection increased
Pool Cache System
• DDoS protection strengthened
• Spam inputs are now blocked
Price Server / Price API
• DDoS detection settings adjusted and moved to a token-based system
• This allows more services and browser tabs to run without errors
• New database system for faster loading times
REST API Cache
• The caching system was completely rewritten in Rust
• Rust was chosen due to the very high number of requests per second
• The new system provides ~10% better performance and speed
• Added advanced DDoS detection, including IP range detection
Network Status
• Implemented a new database system, caching system, and enhanced DDoS protection
Live Node View Endpoint
• Performance and security updates
Lucky Lottery Ticket (Dashboard)
• DDoS protection slightly relaxed (previous settings were too strict)
• Stronger input validation
• Caching added for faster loading
• New database system
Explorer
• Updated to the new branding design (header & footer)
• Improved protection against reload attacks
• Better caching and improved preload / async loading, resulting in faster page rendering
• WebSocket connections close when the tab is inactive, reducing browser resource usage
• REST API requests are paused when the tab is inactive
Additional Fixes
• Numerous smaller bugs across different systems have been fixed
Overall Improvements
• ~20% reduction in overall server load
• Significantly faster data loading times
• Achieved through better caching, improved database systems, and optimized thread handling
Security has also been significantly strengthened, especially against:
• DDoS attacks
• Payload-based attacks
• XSS attacks
• SQL injection and other POST-based attacks
While protection already existed, it has now been further reinforced.
Additionally, several visual improvements were implemented to provide stronger branding and a more professional appearance.
Please perform a hard refresh in your browser, for example in Explorer or Webwallet, using Ctrl + F5.
The connection to Rplant in the dashboard has been removed. All links and mentions on the website have also been removed.
And again: We recommend that users discontinue using Rplant and switch to a different pool.
The pool wallet addresses have been flagged as suspicious. More information can be found here:
https://antifraud.cryptix-network.org/case/f11fae53-39bf-45fa-86db-5a7cb98a54f3
We’ve published a small Rust script so that you can analyze wallet addresses in the future—even if they are anonymized behind pools. This way you don’t have to scroll through the browser and search for a long time.
It works very simply: you enter a wallet address or part of an address, for example “vpnz” as the ending of a censored address. Then you specify the hot wallet of a pool or an exchange. The script then scans all transactions and returns the full address or the related transactions.
This allows you to automatically find addresses, verify transactions, and maintain full transparency—even for anonymized addresses.
Example: Finding an anonymized address
There is a precompiled Windows .exe, so you only need to open the start .bat file. After starting it, enter the hot wallet / pool wallet. Then press 1.
Next, enter the letters of the wallet that you already know, for example “vpnz”. Then wait a moment and the script will return the full address.
Source code for Linux, or you can compile it yourself, is also available. It's a simple little Rust script.
It also works with other coins/blockchains if they use the same REST API. The URL can be changed in the configuration. Licensed under MIT - do what you want with it.
Github: https://github.com/cryptix-network/Cryptix-api-address-finder
We have activated a new technology/interface that temporarily blocks wallets flagged as suspicious by the community-driven anti-fraud system from accessing all off-chain services, including the web wallet.
Although we cannot intervene directly in the blockchain itself, we leverage all our server technologies and connections to enhance security and make it as difficult as possible for suspicious users to operate. The system is fully automated and connected to the anti-fraud system’s API, ensuring that newly confirmed cases are immediately reflected across all off-chain services.
To prevent misuse or false application, there is no manual option to add entries. The system relies exclusively on the community-managed anti-fraud system.
Our new miner friend has already felt the system's effects and is apparently gone for now because he couldn't send his coins and was using the web wallet. The system cannot be bypassed with different hardware, VPN, or changing IP addresses, as it is wallet-dependent. This also means that cases within the anti-fraud system must be taken very seriously in community decisions. Only vote "suspicious" if you are certain.
It's important to note that the system cannot interfere with the blockchain. It's off-chain, ensuring the blockchain remains decentralized.
Here is the tech paper for the new V3 Hash: Cryptix OX8i
Read More: Tech Paper Cryptix OX8i
We are proud to officially release the Cryptix Antifraud System v1.0.0 — a major step forward in protecting our ecosystem and increasing transparency.
What is the Cryptix Antifraud System?
The Cryptix Antifraud System enables users to report suspicious wallet addresses, miners, fraud cases, and other serious crimes or suspicious activities.
Users can submit reports anonymously, whether they were personally affected by fraud or observed suspicious behavior, such as miners operating with specialized hardware.
How it works:
• All submitted cases are publicly visible to ensure full transparency.
• The community reviews and evaluates each case.
• If a case is confirmed by the community, the reported wallet will be officially marked.
• The system also includes an automated address checking tool and a public list of flagged addresses.
• This data can be used by law enforcement, mining pools, exchanges, and other service providers to take off-chain action.
Important to understand:
The Cryptix Network / CPAY is a fully decentralized blockchain. This means:
• No one can interfere with the blockchain — not even the developers.
• Funds cannot be frozen or modified on-chain.
However, the Cryptix Antifraud System allows us to:
• Document cases securely
• Provide intelligence to relevant platforms and authorities
• Track coin movements using our TX AI
• Enable decentralized, community-driven decisions
This ensures action can be taken outside the blockchain while maintaining the integrity and decentralization of the network.
Please note:
This system is intended only for serious fraud cases and major incidents — not for minor disputes or small issues.
Together, we can make the ecosystem safer.
https://antifraud.cryptix-network.org/
The database filler has now been replaced. It’s about 10x faster than the old one when adding new transactions to the explorer, while also using less resources.
The new filler works in parallel instead of sequentially and comes with a cache, making it compatible with a large number of users/requests at the same time and very high block times.
It’s also much more robust: it has a self-repair mechanism and can detect problems. Even if a node goes down or crash, it should theoretically reconnect automatically and start a repair modus (if needed).
This means that long-running operations should now run smoothly without issues.
A new update for the REST API will be deployed today due to IP range attacks. This means that only one active REST API connection per IP range (not per individual IP) will be allowed.
If anyone experiences any issues after the update, please let us know. However, normal users should not notice any difference and everything should continue to work as usual.
This change introduces additional DDoS protection, as someone has been attempting to DDoS the server using IP range attacks. The attempts have not been successful because they are targeting a cache, which is ineffective, but it still causes unnecessary resource usage. Therefore, we are implementing this fix.
- There are no longer separate versions for developers or classic users. The full version now includes all modules and files.
- Modules/Tabs can be selected via the options—activated or deactivated. The software is now fully modular, allowing users to control which features they want to use.
- Preconfigured pools in the Miner tab have been updated: getToMine pool removed, nushyPool added.
- Wallet systems have been expanded:
Webwallet 1 – new system
Webwallet 2 – old system
Local Wallet 1 – new system running locally via a self-hosted node
Local Wallet 2 – old system running locally via a self-hosted node
The new wallet system is now also available as a local wallet.
No external connection is required for local wallets, as long as a node is synchronized and active.
- Resource usage has been optimized. The software should now require less standby power, especially when tabs are deactivated.
- Bugs related to process termination when the software shuts down have been fixed. Process identification is now more robust.
- A new Chain Visualizer tab has been added. It visually displays the blocks/chain from https://dag.cryptix-network.org/
and allows connection to a local development node. This tab is primarily intended for developers.
This update is recommended but not mandatory. If you choose to update, you can simply open your existing All-in-One folder and overwrite the old files—your old configs and wallet data will remain, and you won’t need to set everything up again.
Github:
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.5.1
- Simple GUI Wallet Standalone Software for Cryptix CPAY
- Linux 64 & Windows 64
- Use the new Wallet BIP system
- Its the same wallet as the Webwallet Server #1 compiled as GUI Software
Virusotal - Viruscheck:
https://www.virustotal.com/gui/file/5299b4fa4315dc72ceffba92af2e7d47ef0cca0bca261e49f7465a21ff9b7d41
Github:
https://github.com/cryptix-network/cryptix-gui-wallet/releases/tag/v1.0.7
The new Hash v3, an extension of the OX8 Hash, will be named OX8i.
The “i” stands for the codename Iridium.
Iridium is a chemical element with the symbol Ir and atomic number 77. It is extremely hard and resilient—one of the toughest metals known. OX8i – Iridium perfectly reflects the concept: a robust, hard-to-attack hash..
Currently mined: ~57%
We’ll soon break 60%.
Hold on to your coins — they won’t be this easy to get for much longer.
Blockspot io listed us:
https://blockspot.io/coin/cryptix-network/
The new Hash v3 is about 90% complete. Here are the updates:
FPGA / ASICs: We are implementing new approaches and functions designed to make life even harder for FPGA and ASIC miners.
FPGA: For FPGAs, we are primarily targeting the LUT limit. The final hash would require 20x more LUTs for full parallelization and unrolling than the strongest known FPGA in the world can provide. Serial integration would technically be possible, but even an extremely expensive high-end FPGA would achieve less hash rate than a single 4090 — making it effectively unusable. This assessment is based on benchmark tests with the Vivado Design Suite. We deliberately avoided using floats because being “IEEE-754 compliant” does not guarantee identical behavior on every piece of hardware. Using floats is a very messy approach for deterministic, distributed systems. There are other options available, even though they require more integration work and testing.
ASICs: To implement the new hash, ASICs would need to develop an additional chip, costing developers tens of millions of dollars. It simply isn’t economically viable. A hard fork from our side would have cost manufacturers millions, and they are aware of that. There is no threat from ASICs. Even if a manufacturer attempted to adapt, our new ASIC deterrents would certainly keep them in check.
Botnets: This is a tricky topic. We do not intend to interfere with the blockchain itself, so botnets will always have a way to participate. The only way to stop them completely would be centralized control of the blockchain, which we will not do. However, we can make it harder for botnets and theoretically slow their performance somewhat. This will be attempted with a new function in Hash v3. To be clear: the boundary between a “legitimate GPU” and a “botnet” cannot be determined purely algorithmically — we can only worsen scalability for botnets.
Examples of mitigation strategies:
Serial dependencies: Each iteration depends on the previous one → bots cannot accelerate multiple hashes per instance in parallel.
Randomized index and memory access patterns: Many bots running concurrently are not efficiently optimized; their CPUs and GPUs become overloaded.
Variable loops / dynamic rotations: GPU-optimized bot miners do not benefit because they cannot utilize a constant pipeline.
Botnets can still participate, but they won’t gain a significant linear advantage through sheer numbers or parallel hardware. True decentralized blocking is impossible, but we can increase the “cost per bot,” which is the goal of the new hash.
CryptixHash v3 is coming. Starting tomorrow, development of the already initiated v3 hash will continue.
The new hash will introduce several innovations, including even more division operations, non-linear and unpredictable behavior. It will also become larger and more complex. In addition, there are further features that will not be disclosed until they have successfully passed the testnet phase.
Resistance against FPGAs and ASICs will be significantly increased, particularly through higher latency factors and RAM size requirements (though it will not be memory-hard).
Why? To have a fast replacement hash ready if it is ever needed. This allows us to perform a hard fork within 3–7 days if necessary. Additionally, it will give us better flexibility to balance performance between GPUs and CPUs.
If we perform a hard fork, no swap or anything similar will be needed; only the hash will be exchanged. Furthermore, we can then immediately enable payloads for everyone.
CoinCarp added us to their coin list overview:
https://www.coincarp.com/currencies/cryptix-network/
I am currently developing a new mining software called Cryptis Miner. It is a completely new, modern mining application built from the ground up, featuring the latest functionality and a strong focus on user-friendliness.
It should hopefully be ready for production soon – CPU mining support is already fully completed. This new software will replace the old Cryptix Community Miner, although the old miner will remain usable for some time. The old Community Miner will likely receive one final update, reducing the developer fee to 0% and adding an OpenCL + AMD update. After that, development of the old miner will be discontinued.
The new mining software will operate under the name Cryptis. It will not be exclusive to Cryptix, but will of course include the OX8 algorithm and be fully usable for Cryptix mining. The software will support all GPU types: Intel, Nvidia, AMD, and onboard GPUs. It will also support CPU, GPU, MultiGPU, and hybrid mining. The miner will be OpenCL-based. The developer fee will be permanently set at 1% for all hashes and coins.
There will also be an extended version available, which will offer a graphical user interface (UI) for desktop systems in addition to the console window. This will allow the software to be operated with simple clicks, for example on Windows, making it much more user-friendly. However, this will remain optional. Supported operating systems will be Linux, Windows, mmpos, and HiveOS. Mac / macOS will not be supported – there is simply no real demand for it.
I also plan to use this miner to support other projects that have difficulty finding integration with a professional mining software solution. I will integrate and support selected projects, focusing primarily on newer and carefully chosen ones.

The Member Area / Fusion has been updated:
A visual bug affecting GPU CCPI displays has been fixed.
A cache bug has been fixed.
CCPI multipliers have been adjusted.
New Special Job feature:
This feature selects suitable workers for overpaid jobs. These jobs are always calculated in 5-minute increments and can utilize both CPU and GPU resources. This is the first test for the future rental of hashrate/Fusion jobs. This feature is still under development.

Since there seems to be some confusion about the endpoints for the REST API, I have created a subpage with the most important information/endpoints.
https://cryptix-network.org/api-endpoints
Please note that there is a rate limiter/DDoS protection in place. Queries should not be made more frequently than every 5 seconds.
CoinPaprika has added us, so you can always find information here:
https://coinpaprika.com/coin/cpay-cryptix-network/
The dashboard has been redesigned and now displays individual volume and values for Safetrade and Exbitron. The total coin value and total volume are determined by both.
Read More: Usability and User Experience in Cryptocurrency Projects
Let’s talk about crypto exchanges. I regularly get approached by so-called “developer hunters” from major exchanges – just now again, this time from BitMart. This “pay-to-play” system, where developers are forced to pay huge fees to get listed, is simply unethical.
But what does this really mean?
Many major exchanges demand astronomical fees for listings – no matter what the coin is. It doesn’t matter if it’s a community project, open-source, a legitimate cryptocurrency, or a short-lived rug-pull token – it doesn’t matter. As long as the listing fee is paid, you’re in. This is a fully capitalistic system: developers and projects are pressured and financially drained.
So what are these exchanges really after? Are they serving their users and traders, their “community” that they always advertise? Or are they just after immediate financial gain? Because what we see is this: they don’t list what could actually benefit their users—they list what is paid for. A risky smart contract, a rug-pull token—doesn’t matter, as long as the fee is paid.
Is this the right path? Is this the future of crypto? Is this why new projects struggle to survive? Why Proof-of-Work is disappearing? In the past, coins could achieve millions in market cap immediately – today, listing fees are completely out of reach for most new projects.
And what exactly are these listing fees for? Take BitMart, for example—they already listed Kaspa. We use the same technically wallet system, meaning integration poses no security risk. It could be copy-pasted in minutes. Yet they demand tens of thousands of euros. Nevertheless, exorbitant fees are charged. This shows that the BitMart exchange doesn't make decisions based on risk or benefit for its users, but simply on profit. Why? Because it’s a pay-to-win system.
However, the business acumen here is questionable, as stock exchanges also earn money through trading fees, withdrawals, and new users.
But Back:
Even large projects eventually face exchanges like Binance, where fees are astronomical – practically impossible, even for top 100 coins. Shouldn’t successful projects at least have a fair chance at being listed?
Right now, the opposite is true: whoever can pay – no matter how shady the project – gets listed. Fair, transparent, hardworking projects are left out.
The crypto world needs to recognize its responsibility. If we don’t act, the wrong people will decide the future of our technology.
Consider also the market dominance of large projects. Such exchanges create decentralization – the opposite of what the crypto world should be.
A call to all users, miners, and traders: Don’t blindly support these exchanges. Whenever possible, use smaller, fairer platforms—even if the price is slightly worse. Every choice you make shapes the direction of crypto. Boycott pay-to-play exchanges where you can. Your community, your projects, your future – that’s in your hands.
I, along with other developers from various projects, will create a comprehensive list that identifies these types of exchanges and transparently displays their listing fees. This will give users full visibility and allow them to make informed decisions about whether they want to hand over control of the crypto world to these platforms.
It’s worth questioning whether we should support exchanges that don’t care about their users, that don’t care about the crypto ecosystem, and whose only priority is their own financial gain. Of course, they need to operate as businesses, but profit should not be their sole concern.
Ultimately, the future of crypto depends not on exchanges, but on the decisions of traders, users, developers, and miners. Choose wisely.
And to all developers: Don't play along. You can make it without being exploited, I'm sure of it.
Wow, it’s hard to believe – the block reward is now exactly 5 CPAY, which is half of what it was a year ago. Time really flies! It feels like the release was just yesterday. One year has already passed, and in that time, we’ve overcome many challenges.
We’ve grown strong and organically – from our website to our features and, of course, our community. That’s something we can be truly proud of.
Looking at the numbers: more than 54% of the total coins have now been distributed without our value crashing. That’s remarkable, especially compared to other projects where even 10% of the supply often fails to withstand selling pressure. In today’s PoW world, that’s a strong statement. And we achieved this despite having to withstand the MecaCex exchange fraud, which wiped out our project liquidity and forced us to restart from a $0 market cap, as well as the FUD from an insignificant competing project.
We’re still here – a clear testament to our dedicated community. Our listings continue to grow (big thanks to Safetrade!), and everything is moving exactly in the right direction – completely organic. We have no intention of stepping away.
And the best part: there’s still so much more to come. Current plans and developments are very promising and will make a real impact. In particular, the partnership with RIFT is a huge opportunity for Cryptix – both in terms of reach and liquidity (swap system). Of course, we’ll see how RIFT performs on the mainnet, but I’m optimistic.
On a personal note, this is an incredible chance to gain new experience. A ground-up, newly developed project is very different from a fork, and it’s exciting to work on modern code and innovative features that are truly state-of-the-art.
The next six months will be especially interesting for Cryptix. Many opportunities are already on the table, and even potential major changes could happen – naturally, the community will vote on them.
Stay tuned: things get really exciting at 65–70% supply and after the RIFT release and the swap system go live. 2026 is shaping up to be a very exciting year for us.
Cryptix CPAY is listed on the Safetrade Exchange. All markets are active and open.
https://safetrade.com/exchange/CPAY-USDT?type=pro
Currently, I’ve been more passive in announcements because there’s an extreme amount of work going on. I’m working on the smart contracts, the Fastchain modules, and the cooperation with the RIFT Project simultaneously. Always check the GitHub activity section to see how active I am – I’ve made this view publicly available on purpose. Still, I want to give a quick update and share recent progress and news.
Smart contracts are progressing well, though there are still some hurdles to overcome. Nothing critical, but it’s a lot of work.
Fastchain technologies are performing better than expected, though it’s still uncertain how we will integrate them into the BlockDAG.
The cooperation with the RIFT Project is going well. Many modules, including Cryptix Atomic and Fastchain components, are integrated into their testnet. It’s a great opportunity to later see how robust the development is in a Mainnet, especially on a serial blockchain where every error can be fatal. If it proves itself in a serial chain, adapting to a parallel chain will be much easier.
The RIFT ↔ CPAY swap system is being developed with the RIFT developers. Why? This will significantly increase liquidity for Cryptix and reduce volatility. It will also allow users to obtain RIFT where Cryptix is available – and vice versa. If either chain is listed on larger exchanges in the future, both will benefit.
Safetrade Exchange Listing: Yesterday we ran tests for the Safetrade listing. Everything looks good, and the listing should be available soon. When exactly? I cannot say – it depends on the Safetrade developers. Regardless, we’re grateful for the listing as it will provide a better market for our project.
I currently have an incredible number of projects going on at once; it's a lot of work. Therefore, I'm using my time for development and am less active on Discord, but feel free to contact me if you need support.
And:
Live Mined: 53.85 % -> Soon 54%
The next reward reduction is in 4 days.
Happy New Year, Cryptix Community!
Almost exactly one year ago, we launched Cryptix – and what a year it has been.
We’ve reached 52% of total supply, marking an important milestone in our journey. We’ve experienced highs and lows, faced challenges, and solved problems together.
2026 is the year to build on this momentum. Let’s continue to push forward, achieve new milestones, and make Cryptix even stronger. Thank you for being an essential part of this journey.
We’ve just released the Cryptix Fastchain ForkResolver – a robust foundation for developing high-speed blockchains and FastChain technology.
It’s crucial because it automatically protects blockchains from crashes and forks, handling reorgs correctly. This makes it the backbone for super-fast blockchains with real low-latency blocks. Such a forresolver is the basis for fast networking.
Perfect for projects aiming for high BPS and stable performance!
The fork resolver was successfully stress-tested at 10 eBPS (actual real blocks, not hot air blocks (BPS)). In theory, it could achieve more directly, and even more with further cache optimizations. However, this is unnecessary, as global latency never allows for more than 3-5 eBPS anyway.
The code still needs some optimization and is in development status, although it is basically suitable for the mainnet. The code still needs some optimization and is in development status, although it is fundamentally suitable for the mainnet. We have tested it with an external crypto project.
For those who would like to contribute to the development, here is the current code:
https://github.com/cryptix-network/fastchain-fork-resolver
I have received a few questions about FastChain, so I’m writing this as general information for everyone:
Is FastChain L1 or L2?
It is L1. FastChain is designed either to function as a standalone system or to be integrated into existing systems (not layered on top of them).
L2 means “Layer 2”, which is a layer built on top of a base layer. FastChain is not intended for that. Instead, it is an on-chain add-on for existing systems that is integrated rather than stacked on top. Alternatively, it can run as a standalone system.
If FC is used as an add-on, it works technically in a similar way to BlockDAG’s blue blocks. There is a stabilization layer and an enforcement layer. This is difficult to explain in just a few words, especially because the final plan does not yet exist. The current status is, as described in the whitepaper, “Research Innovation”. There is no fixed roadmap or final development plan yet.
What we are trying to do is explore a technical way to reach the limits of real throughput / blocks per second despite global latency and network gossip — in a different way than BlockDAG does.
Are parallel BPS real BPS?
No, they are not. Blocks that are produced in parallel and only recognized afterward do not increase real throughput. They are, however, one possible perspective.
Let me explain it this way:
Someone says cars drive at 10,000 m/h. I say: no, cars drive at a maximum of 200 m/h. Then he replies: no, because there are many cars global, and if I add up all their speeds together, cars move at the speed of light.
But this does not change the fact that each individual car only drives at 300 m/h. The cars are not actually faster, even if the combined, parallel calculation produces a very high number.
This is exactly why we need a measurement indicator such as eBPS, so users can immediately see whether a value represents real speed or just parallel, aggregated throughput.
This comparison is obviously simplified and may not be technically perfect.
BlockDAG is a good technology— a sensible technology. It makes mining fairer. It makes a blockchain more stable. And it automatically moves closer to the potential limits of global throughput.
BUT: it is not the limit — not even close. To reach that, a completely different approach is required.
There is also the point that beyond a certain speed, there is simply no reason to further increase BPS. I would say it makes sense up to a maximum of around 3 BPS, maybe 5 BPS. Beyond that, it’s just hot air — useless, with no clear additional benefit. That’s my opinion, based on technical reasoning.
Increasing BPS without a real need is also a way of digging your own grave. Nodes require more resources, everything must be processed, and this inevitably leads to centralization, because not everyone can or wants to provide that level of performance.
It also increases global energy consumption. There is a real difference between needing 2 CPU cores versus 8 CPU cores (even if one wants to argue from a “green” or “sustainability” angle — although anyone who truly focuses on that is already in the wrong place in the crypto world).
Another issue is that the blockchain gets clogged. Everything is pushed to the limit for no reason, even though it wouldn’t be necessary. How are you supposed to integrate new features later, such as L1 smart contracts, L1 ZK functionality, tokens, payloads, etc. (and no, L2 is not a solution, we can just stick with normal banksystems)? At some point, it simply becomes impossible, because data transfer capacity / Computer power is already saturated by empty blocks. Developers call this an architectural dead end.
Setting BPS too high is a dead end. In the end, nothing meaningful can be developed or extended anymore. Developers understand what I mean when I say: try handling a 100 KB payload at 30 blocks per second — that’s 3 MB/s.
The global average upload speed of private internet connections is about ≈ 2.5 MB/s. That means the average user wouldn’t even have the required internet bandwidth, and even users above the average would have their entire connection fully saturated.
These are the kinds of things that must be considered. The same applies to storage requirements — think about how many gigabytes per day would need to be stored for an archive node.
That is my perspective on this topic. It's good that there are different opinions on this. This fosters new technologies, innovation, and progress. Constructive criticism is always beneficial; it allows for the optimization of opinions and plans.
Still need some evening reading material?
The "You cant" System
We've made some changes to the member area login and registration systems.
It's now a fully-fledged zero-knowledge login (ZK) system.
Technically, it works like this:
✔ The password remains with the client
✔ The server never learns anything about the password
✔ The server doesn't store any confidential data
✔ Login is a mathematical proof
✔ Even if the server is compromised, passwords remain secure
This is zero-knowledge proof of password possession.
When creating an account in the member area, you can now use stronger encryption:
PBKDF2 + SHA-512 + Salt.
Accounts created with this stronger encryption are more secure. I can also later provide a feature for changing the wallet address for these accounts.
If you are creating new accounts anyway because of the new wallet system, create them directly with the stronger encryption.
The old accounts, IDs, etc., will remain valid. This is optional.
The new Encryption works with (100,000 Iterations) :
salt → PBKDF2(password) → stored passwordHash (512bit)
cryptixId = SHA256(wallet + passwordHash)
Means:
- The server knows neither the password nor the ID formula. The server doesn't know the password either. And the frontend doesn't transmit the password directly in its raw form.
- The username itself depends on the password.
Because it only sends hashes:
→ Zero-knowledge login
→ Server doesn't know passwords
→ Even in case of a server leak: Passwords remain secure
That's bank-level security - it's a similar approach.
The new web wallet uses even higher encryption and 500,000 iterations. And all data is stored locally on the user's device. There are no password / Account / ID transfers or anything like that.

The new web wallet is now online. Please note:
In the new wallet system, we no longer use the old Go-Node 972 derivation path, but instead the new BIP path as implemented in the Rust Node. This means that you will need a new seed and must create a new wallet if your old seed was generated with the previous web wallet. I might integrate the old legacy system later, but I think that's unnecessary work.
We recommend generating a new seed—ideally a 24-word seed—directly in the new web wallet and transferring your coins from the old web wallet to the new one. Web Wallet Server #2 will still support the old wallet. After creating your new wallet, log in to Server #2 and transfer your coins. Or you can use the Android app, which also has legacy features.
Wallet Server #2 will continue to run the old wallet system in case there are issues with the new wallet or for users who need to transition to the new BIP system.
Webwallet #1 (new System): https://wallet.cryptix-network.org/
Webwallet #2 (old System): https://wallet.seed2.cryptix-network.org/
So, what still needs to be done in the web wallet:
Perhaps: Add legacy seeds
The transaction history could have smoother animations
Translations are available, but we decided against using an automated translation module to prevent external connections from interfering with the wallet system. We've already started translating parts of it, but there are still sections and languages missing.
The All in One software will receive an update to include the new wallet system for local hosting. However, All in One will also retain the old local wallet system, so both options will be available.
We have just activated and successfully tested the NFC function in the web wallet. The web wallet will support NFC features such as NFC tabs for sending coins.
Regarding devices:
Android: Fully functional in the browser (Edge and Chrome tested)
iOS: Browser-based NFC is not possible (this is not our fault; Apple is many years behind in browser development, especially with PWA functions, NFC, etc.). iOS does not support it, even if we offered it.
Desktop: NFC only works with additional hardware; the computer or laptop must have a NFC module. However, it does work in theory.
We can't yet say which devices it works on or not. But that can be expanded. In theory, it should work on any device with Edge/Chrome 89+ or newer.
There will be many new features, such as:
Address book function for storing addresses with names
Direct sending of coins to address book entries
Built-in alias function and sending to aliases
Sound notification on incoming transactions
Fully automatic auto-compounding
Dollar values for coins, including for individual transactions
Static addresses with the ability to switch between them
PNG address image generation of the current address
Download and print of a transaction overview
Live blockchain feed
Configurable auto-logout
Panic button to instantly destroy all data
Multi-seed / multi-wallet support
Wallet creation with enhanced encryption
Free node selection, even using a local node through the web wallet
Custom proxy layers for external connections such as market servers
Filtered data through security modules
Detection system with visual warnings if browser extensions or script injections could endanger coins; anything trying to interfere with the wallet system is detected
Uses the latest Rust WASM, not the outdated Go version
Everything can be configured in the settings: every connection, every function. Everything can be turned on or off. Completely modular.
And More
Pure JS and HTML. No TypeScript, no unnecessary bloat, no useless imports. Clean, self-developed. Fully up to date.
Live Mined: 49.91 % ▲
We are very close to reaching 50% supply. That means half of all coins that will ever be released.
I was asked by researchers where exactly F lies in the Fastchain plan, so there is a short extension paper for those who want to delve into this topic.
Additional Information:
The constraints cover important physical and operational limits. These can be expanded to include, for example, network latencies between nodes, varying bandwidths, and dynamic transaction rates.
Objective Function F: Quadratic penalties can be sensitive to outliers. Absolute values or Huber penalties might be more robust. Weighting is heuristic; an incorrect choice can lead to suboptimality. The stochastic nature of the metrics is only partially addressed—true system dynamics might require additional models or MPC.
FastChain Core Extension ”F” Paper
Every developer, researcher, and tech enthusiast is invited to contribute to a new, innovative technology. Developers from other projects are also welcome to participate; innovation and development should not be limited by competition. One thing is clear, however: it will generate a tremendous amount of work and many challenges that need to be solved. If successful, it could represent a major breakthrough in the crypto world.
Cryptix FastChain Research Paper
Proposal for ISO/IEEE TC307: eBPS – Efficient Blocks Per Second
We have submitted a proposal for a new blockchain metric to TC307, the official Technical Committee for Blockchain Standards at ISO/IEC.
The eBPS metric is designed to protect users from misleading marketing, such as “Hot-Air Blocks,” and to encourage developers to focus on real technological innovation rather than paper numbers.
By providing a transparent and practical measure of truly efficient block production, eBPS has the potential to gain broad acceptance within the blockchain community.
We need to measure how many blocks are actually finalized globally—not how many are "generated" locally.
This solves:
Marketing exaggerations
Misinterpretations
Incomparability between chains
User confusion
False optimization incentives for developers
That's precisely why eBPS makes sense.
Proposal for ISO/IEEE TC307: eBPS – Efficient Blocks Per Second
I keep receiving some submissions that are based on misunderstanding—people simply don’t fully get it.
Let’s start with the basics. I’ll try to make it as simple as possible so everyone can follow along:
Hardware limits:
The more blocks, transactions, and data you have, the more performance your hardware requires. At some point, normal hardware won’t be enough. Users get excluded → centralization occurs.
Country/region latency:
Countries are connected to each other with a certain latency (connection time/ping, etc.). Gamers know this—ping is higher when a server is in a different region. EU players on a US server or US players on an EU server → 150 ms+ ping. You can’t go faster than the networking technology and regional limitations allow. At least not in reality, though on paper, yes—but we’ll get to that later.
Some data:
Minimum round-trip latency globally: ~20,000 km at ~200,000 km/s = 0.1 s = 100 ms
Realistically, accounting for routing, switches, and internet infrastructure: more like 150–250 ms
Data volume vs. speed:
The more data you try to send, the more speed is impacted. Small data → higher speed possible. More data → slower speed. Why? Simple: data processing, bandwidth limits, feedback loops, network gossip, etc.
Network health is a critical factor:
You don’t know in advance how good the network will be. You don’t know which nodes will be online tomorrow and where they will be. This is an unknown variable. Good nodes improve network health (fast performance, good connectivity, servers, etc.). Bad nodes can reduce it.
It’s not possible. Even with perfect network health, you cannot beat physics. So how can some blockchains claim 10 blocks per second, completing transactions in a tenth of a second? They can’t.
The trick is that blocks are simply loaded afterward. The difference comes from the DAG system (DAG is great Technology): a blockchain can create many blocks in parallel and later order them → this makes it appear fast to users, but the real final consensus time for global transactions is always limited by latency.
Does it make sense to do this? Yes. You can push the network close to its limits. However, these limits depend on data rates and network health. The same technology can have different limits depending on these factors.
We need to distinguish between real blocks with utility and what I call “hot air blocks”—blocks that only show high numbers on paper. For a true global blockchain with final transaction confirmation, 5–7 BPS is realistic. Anything higher is mostly hot air—not real. Depending on your perspective, if you count blocks generated locally on your computer as “real,” they are real. But if we talk about blocks that truly have a global blockchain utility, 5–7 BPS is the limit.
The key difference is between apparent speed (local confirmation, DAG) and real global consensus speed. Beyond a certain point, high BPS numbers in blockchains are mostly marketing. This can also be easily proven. If a blockchain has 50 BPS but the transaction arrives in 200 ms, the effective BPS is 5. Everything else is on paper, unusable, and hot air—but it sells well. In crypto, marketing often matters more than reality.
No—only hot air. The maximum, with many hacks, tricks, and technologies, is in my opinion ~20 BPS. But even that comes with conditions: minimal data per network request, good network health, and it’s not sustainable. It might work one day and crash the next.
This is why I’m working with Fastchain technology, a system that adaptively and dynamically finds the maximum for real blocks (not hot air on paper). Crucially, it’s self-healing: it constantly adjusts every second (or every 10 seconds), preventing crashes. The system finds the limit, and BPS is reduced by 2% immediately when necessary to maintain stability. This keeps you constantly at the true limit.
Here, the optimal choice of transaction volume, compression tricks, general data, lazy loading for weak nodes, and creating the best possible network health all matter.
Are there currently any blockchains with a true 10 BPS (NOT hot air)? No, there aren't. You just need to read the code—and understand what’s really happening. Marketing BPS ≠ real global consensus BPS. My personal opinion is that developers should focus on genuine development. They should strive to make block speeds truly beneficial, rather than simply trying to increase the perceived value.
And as an aside, with hot air blocks, 50+ BPS is now possible, maybe even 100 BPS. If you want, I can try it out. What's possible with hot air. Although in my opinion, it's a waste of time. It brings no progress to the crypto world.
And this is by no means meant as an attack on anyone. It's simply about educating users a bit, perhaps nudging developers in the right direction. And I want to emphasize that such technology is useful up to a certain point; I would say up to 3 BPS. Anything beyond that is pointless and is just marketing/paper data. After 3 BPS, the focus must shift to innovation, new ideas, and technologies. Not further expansion.
My last Words:
We need adaptive Systems, not hot Air.
Many have already heard of him and might know the basics: he is the origin of the crypto world as we know it today and the creator of Bitcoin. Most people know that. But once you go deeper, an incredible amount of misinformation circulates. Often, Satoshi is quoted in ways that just suit someone’s agenda – and that is simply not correct.
So let’s take a closer look at a few central topics.
Time and again, you hear the argument: “Bitcoin has ASICs too.” To that, one can only say: “You are not Bitcoin, and you will never be. The story has already been written.” But that’s not really the point. Do you even know when Satoshi stepped back? He wrote public emails until the end of 2010, a few private messages until mid-2011, and his last known message was:
“I’ve moved on to other things.”
With that, he was gone – emotionless and matter-of-fact. The first ASICs and similar hardware didn’t appear until two years after his last private email. Satoshi never accepted them because he simply wasn’t there anymore. Decisions by his successor Gavin Andresen were heavily criticized, until the community eventually stripped him of power. That’s the story behind “Bitcoin and ASICs” – most people don’t even know this.
In the whitepaper, Satoshi clearly wrote:
“The proof-of-work voting system is one-CPU-one-vote.”
He also knew:
“The design supports specialization and economies of scale in mining.”
He was aware that specialized hardware could emerge, but he could only respond once it became commercial or led to unfair practices. He probably did not imagine at the time that such hardware would appear so quickly and on such a scale, creating problems and unfair power distribution. Do you really think Bitcoin would still have ASICs today if Satoshi were active? It would be a direct contradiction to everything he stood for.
What mattered to him most was decentralization: Every user should have access, every user should have a voice, fair and independent of how rich or powerful they are. ASICs, on the other hand, concentrate power in the hands of those with the most capital – precisely the old banking system that Bitcoin was originally directed against. Only that, at least with banks, there were elected authorities; in cryptocurrencies, anyone can participate, no matter how competent or powerful.
There are projects that strike deals with ASIC or FPGA manufacturers, enrich themselves personally, then pump their coin while later quoting Satoshi from the whitepaper. They pretend to have anything to do with the original crypto mentality. Many projects no longer do this – some never did.
Would Satoshi have acted that way? Absolutely not. He has not moved a single one of his early-mined coins to this day. He would be a multibillionaire today, yet he hasn’t taken a Dollar. For him, the project and the community came before personal enrichment. This is also why he always wrote coolly, factually, and emotionlessly – unlike me; I write a lot, with personal opinion and emotion.
Satoshi, however, was friendly, responded to every criticism, and was active in the community. He ignored nothing – neither questions nor false statements – and even responded to offensive or provocative comments in a factual manner.
The current reality of many projects looks different. Developers occasionally check Discord or forums, ignore the community, and are not active participants themselves. They neither respond to criticism nor change opinions. Sometimes it’s marketing: they want to appear unreachable, present themselves as a “mystery,” as if “higher” than others. That’s arrogant distancing and contradicts Satoshi’s principle: Every user has a voice. If you are ignored, your voice does not count.
Satoshi’s maxim was: The project and the technology are above the individual developer. Your personal role as a human being does not matter – only progress and development count. Develop, whether it succeeds or fails, but do not do it to boost your ego or increase your name recognition. Those seeking fame or titles have not understood the crypto mentality. Satoshi was anonymous, partly for protection, but also to show: It’s not about the person, it’s about the technology.
Have you read Satoshi’s whitepaper? It is concise, clear, 9 pages long, with graphics for easy visual understanding. No digressions, no unnecessary examples. Technical, but not academic – understandable to anyone – and with a few formulas for those who want to go deeper.
Today, whitepapers are often 15–30 pages long, full of formulas that have nothing to do with the core idea – just to show off competence. Anyone who truly understands the content can explain it clearly. Simplicity is a sign of mastery – like skateboarding: If it looks easy, you really can do it.
But when everyone acts like a “crypto professor,” puts ego above the project, and tries to make everything complicated, it again contradicts Satoshi’s philosophy. Personal ego must never stand above the technology.
There are probably ten more points worth discussing – points that create new ways of thinking and provoke questioning. Anyone active in the crypto world – miner, trader, developer, or supporter – is part of the whole. This applies across projects, because there is only one crypto world. Every coin, every development contributes to this ecosystem.
No matter how big or small you are, no matter if you fail or succeed – you are part of it. The time, energy, and attention you invest are valuable. And that is exactly what I want to stimulate with these thoughts: reflection, considering the role you yourself play in the bigger picture.
Of course, everyone can take their own path. There is no right or wrong, everything has its reason for being. But anyone who breaks the core principles of the crypto mentality, who selectively follows Satoshi’s philosophy, should not quote him at the same time – neither in the whitepaper nor on the website. Either you live the principles, or you don’t. Everything else is hypocritical.
I get asked very, very, very often why I am anonymous. Why I don’t show who I am. Whether it would really be such a big problem.
No, it wouldn’t. Why should it be?
Being anonymous has nothing to do with having bad intentions, hiding something, or being ashamed of where you come from — which in itself would make no sense. You come from where you come from. That’s all.
Anonymity has many advantages:
No personal attack surface
In the crypto world it is extremely common for people to try to attack you personally.
Threats, harassment — yes, I’ve received several. Often from fake accounts. Most of the time it's nothing; trolls using the right moment to pretend to be someone else. Block them, move on.
But sometimes it could be serious. You can’t know.
And no one can physically target you if they don’t know who you are or where you are.
No one can attack your private life, your reputation, or the things you have built if they don’t know what or where those things are. Anonymity protects your private life, and this life has nothing to do with the crypto world.
No one can pressure you, blackmail you, or try to manipulate your opinion. There is simply no door to knock on.
You are, in a way, decentralized.
Protection from governments
Another factor is governments.
A new law could appear tomorrow, and suddenly you are responsible for something. Some countries react aggressively toward crypto and encryption developers — even treating them as threats.
You could be seen as a criminal when in reality you’re just writing code and trying to advance technology.
That’s the world we live in.
No fame, no ego, no name — just technology
Another important reason: when you are anonymous, you don’t do anything for fame or recognition.
Outside the crypto space, you are nobody — just like everyone else. And that’s healthy.
Success is easier to handle when you are a shadow rather than a target.
And it shows one thing:
This is not about your personality or your name.
It is about the technology you love, about the world you are building.
That is not tied to an identity.
Anonymity is a double-edged sword
Yes, anonymity can be used for bad things — scams, malicious intentions.
But that is not always the case.
My advice to every developer: stay anonymous
Your name, religion, skin color, origin — none of it matters.
The crypto world is a decentralized world.
Here, a name is irrelevant.
Here, only technology and progress matter.
Protect yourselves.
Stay anonymous.
No matter what others think.
No matter what others say.
Never let anyone pressure you.
Let's talk about BPS/speed. Is 10 BPS the limit? No, it isn't, only with the wrong technology choice and the wrong focus.
It’s important to understand that forcing a fixed BPS (Blocks Per Second) is one of the biggest mistakes developers can make. The most crucial factor—the network’s health and stability—is uncontrollable and determined by the users. To maximize network speed, it must be adaptive, dynamically adjusted based on predefined factors. This approach eliminates the need to select a lower fixed value, even if temporarily a 2–3x increase in speed is possible but not sustainable. Testing and enforcing a fixed BPS therefore becomes unnecessary.
Another key point is that not every block requires the network’s full throughput. Even if, theoretically, each block could be 100 KB, this will never happen in practice—not even for an hour. This allows for the concept of a “Fastchain,” which increases effective throughput. Even if a single blockchain were used by 60% of all crypto users worldwide, the network would not need its maximum capacity. Developers often strive for extremely high TPS (transactions per second), but these high values are rarely needed now or in the foreseeable future. While high theoretical speeds may look impressive on paper, they are rarely practical. Prioritizing high real-world speeds, efficient data transfer, and energy-conscious operation is likely a better approach. It also allows broader accessibility, including for users with older hardware.
But what is possible? I say 25 BPS is definitely possible globally stable.
How?
Whitepaper:
Cryptix FastChain - how to 25BPS
Since user security is a top priority, we've created a blog where we've compiled older information on scams, warnings, and more. We'll continue to add more information so that users can learn how to protect themselves and avoid falling victim to fraud, exploits, viruses, or other threats.
Please note, we simply want to reduce the amount of content like this on our website/news. We will likely only publish such topics on this blog.
https://blog.cryptix-network.org/
we are receiving an increasing number of user reports about fake Cryptis accounts that are trying to scam users by pretending to be me. This time we are talking about a ".its_cryptis" account, which has a dot in front of the actual tag. My real tag is only "its_cryptis".
This fake account is pretending to be a trading expert and tries to get users to register somewhere. The website it redirects to is: https://www.vestasyield.com/
After doing some research on who “Vesta Yield Limited” (the alleged operators) are, I found nothing—no company registration or anything similar. However, I did find reports that the FCA is warning for the operators, as they have already created many such websites without licenses and with fraudulent intent.
Among others:
Choice Assets CFDs
SMART ASSETS PRO LIMITED
Algo Trade247
There are apparently more than 20 such websites, all using the same text and template.
Therefore:
https://www.vestasyield.com/ is proven fraud; do not use this website. Also avoid any site with similar design, as they often change names and domains.
I would never contact you regarding trading or anything like that.
Verify the profile of the alleged Cryptis carefully. If there is no connection to the official website, it is not me. Check the “connections” section in the profile.
FCA Warnining:
https://www.fastbull.com/brokersview/news/fca-warning-forex-brokers-offer-services-without-authorization-flagged-287349
And people, if exchanges, CFD providers, trading companies, or similar services contact you on Discord—whether directly or through other users—then it is not a legitimate company. A serious broker or trading/CFD firm would NEVER do that. It can only be a scam.
Always check who operates the website or who is behind it. If you can’t find any such information on the site, it’s a scam.
If a company name is listed, then search for it first. There must be reviews and an official company registration. Otherwise, it’s also a scam. In this sector, companies must be regulated and licensed, and you should be able to find this information online. Also look up the listed address to confirm if the company headquarters actually exists, or whether multiple similar websites are using the same address under different names.
This way you can immediately see whether it’s a scam or not.
We integrated a new security system last night, mainly responsible for WebSocket and wallet functionality. It now monitors the WebSocket/upgrade connections of users and sessions. Please note: it is very sensitive for now, because since the announcement of the smart contracts, we have received several attacks. If the module classifies cookies, IP addresses, or users as suspicious, they may be permanently banned from all servers (in the worst case) or temporarily blocked from certain connection types for various time intervals.
A full ban means: website, pool, explorer, wallets, seed server—everything. In my opinion, the chance of an unjustified ban is practically zero. However, if you believe you were banned without doing anything wrong, send me a PM so I can unban you.
After activation yesterday, the system immediately banned many IPs, which I checked—and they were indeed not normal users.
Since then, the system has been running stable again, with normal load and without issues. Unfortunately, things like this are a waste of time at the current stage, since we would rather focus on other tasks. But better now than later. This way we can secure the servers further and further until there are no attack vectors left and such script kiddies eventually give up. It was clear that something like this would happen after announcing possible smart contracts. The same thing happened with the DEX. These are desperate attempts to hinder development and progress as much as possible.
Many new crypto projects present themselves as decentralized, yet their underlying technology often includes mechanisms that give developers direct, centralized control. Users should be especially cautious when a project uses hard-coded blacklists in the node software or implements protocol-level wallet freezing, where specific addresses can be blocked directly by the node. If developers are able to decide which wallets are allowed to transact and which are not, users effectively lose true ownership of their coins, which directly contradicts the core principles of decentralized blockchain systems. There is also significant risk when developers can unilaterally influence the token supply through actions such as freezing, burning, or artificially restricting circulating coins. When large amounts of coins are blocked in this way, the effective supply of the asset can be artificially reduced. In financial markets, intentionally restricting available supply can influence the price, and in the crypto context this may be considered a form of market manipulation. Any project where a single party can freeze wallets, remove coins from circulation, or otherwise control liquidity poses serious concerns regarding fairness, transparency, and user safety.
These centralized control mechanisms are not only technical and economic risks — they may also trigger regulatory consequences. Under the European Union’s MiCA regulation, a crypto-asset is considered centralized if developers have the ability to block transactions from specific wallets or change the economic structure of the token. Projects with such capabilities can fall under the requirements for regulated financial instruments, including mandatory disclosures, governance standards, and strict market integrity rules. In the United States, tokens where developers retain control over transferability or supply may fall under the SEC’s Howey Test and be classified as securities. This is not about any specific project, but a general warning relevant to any cryptocurrency that includes mechanisms for unilateral control over user funds or token supply.
For users, the key takeaway is simple: if a blockchain allows developers to freeze wallets, enforce blacklists, or manipulate supply at the protocol level, it is not truly decentralized and carries significant risk. Always review a project’s node code, governance model, and transparency before investing, mining, or providing liquidity.
One thing is certain: If developers can directly interfere with users’ ownership or transactions — such as freezing entire wallets — and they ship these abilities in the compiled node software or hard-coded into the protocol, then the system is not decentralized, no matter how it is marketed.
That has nothing to do with a decentralized cryptocurrency — not even remotely.
Don't let anyone make excuses; that's how centralization always begins.
We also faced a situation in the past where MecaCex deceived users and held large amounts of coins, which they dumped daily on other exchanges, destroying the coin’s value.
Even then, we chose not to intervene at the blockchain level — for legal reasons, but above all out of respect for the crypto space and the principles of true decentralization.
New CPAY Explorer:
The new Explorer is ready! You can find it at the familiar address:
https://explorer.cryptix-network.org/
The old Explorer will remain available for now but will eventually be deactivated:
https://explorer-2.cryptix-network.org/
The new Explorer features reduced data usage, asynchronous loading, lazy loading, and many other technologies that all mean one thing → faster loading times and less data and CPU usage for users.
There are also several new features, such as a list of recently viewed addresses — similar to a toplist, but instead showing active addresses and those holding coins. I found a classic toplist inappropriate, so this hybrid approach allows you to explore active wallets easily. The list is limited in size but includes all wallets known to the Explorer and REST API.
The entire Explorer is simpler to understand and use, even for new users. You can now quickly see, without complex data, where coins are coming from and where they are going in the address view. There’s also a clear summary of recent transactions.
In the detailed views — for transactions and blocks — you’ll now find more information. The system for filling tables from the socket server has been redesigned: transaction and block tables now receive cached data directly from the socket server, so content is visible immediately when loading, without waiting. Data updates every 2 minutes.
All other data, such as open address views, updates automatically. New transactions are loaded in real time — no need to refresh the page anymore.
Many other logic and functionality improvements have also been made. The new Explorer is a complete redevelopment, built using modern, clean JavaScript and HTML, without unnecessary frameworks like Tailwind or similar.
The old Explorer was, frankly, a mess — buggy, slow, and more of a “got it running somehow” project than a proper development. This issue is now fully resolved: the new Explorer is modern, fast, and reliable.
In some cases, large wallets with many transactions may still take a little longer to load, or new transactions might appear with a slight delay. This is due to the database filler, which will also be completely rewritten soon — professionally and from scratch. Once done, it will be 10× faster and bug-free.
The web wallet will also be addressed soon. I’ve made some improvements, but like the old Explorer, it’s essentially a throwaway product — further patching doesn’t make sense. A new web wallet will be coming as well.
We introduce Cryptix GhostGate Net:
a technical foundation for developers who wish to build privacy-respecting systems, secure communication tools, and protected digital environments. GhostGate is a peer-to-peer network with authenticated entry, encrypted communication, and no unnecessary intermediaries.
https://cryptix-network.org/cryptix-ghostgate
Web Wallet Update:
We've reworked the web wallet. There was a bug where it sometimes didn't display incoming transactions. This should now work better, and I've also moved data into RAM, which should make everything load more smoothly. Security measures against payloads, DDoS attacks, etc., have been further strengthened. A gRPC semaphore function has also been added, which protects against node overload as a last resort if all other modules fail.
Note: You can now only have a maximum of 3 connections per IP address, meaning 3 web wallet connections at the same time. There's a short burst of up to 5 connections. The entire WebSocket logic has been changed to improve the web wallet's performance. Previously, it closed longer AFK connections as ghost connections. Now it should actually distinguish between ghost connections and AFK connections.
However, I still need to test how it behaves with longer connections, for example, when a wallet is running in the background for an hour. There is a heartbump function, though, which keeps AFK connections stable.
The changes affect Webwallet Servers #1 and #2.
The faucet was reworked using the same methods, although it's not as important there.
We have now mined 47.12% of the token supply. In approximately two weeks, the next 5% block-reward reduction will take place according to the established tokenomics schedule. This brings us closer to the phase where the emission rate will decrease significantly.
The initial higher-emission phase was intentionally designed to distribute the majority of tokens early and transition later into a lower-issuance model. Despite the accelerated distribution phase, supply expansion has proceeded as planned.
As the project progresses, and once the circulating supply reaches approximately 60–70%, only a relatively small number of new tokens will enter circulation, as originally defined in the emission model.
Disclaimer: This update is provided solely to inform about the technical progress and tokenomics/deflation of the project. It does not constitute financial or investment advice, nor does it imply any expectation of future Coin value or performance.
In the member area, it is now possible to upload and set your favorite NFT as your profile NFT. It will be displayed directly inside the member area and also on your public member card.
At the moment, you can simply upload the NFT JSON / HEX data and the server will store it. Later, this will move fully on-chain — meaning users will need to actually own the NFTs in their wallet in order to use them.
https://member.cryptix-network.org/cryptis


The Exbitron Liquity Bot stopped working after the latest Exbitron update. Here is a fixed version so it works again. Both the Python and EXE versions are fixed.
The All in One package will receive the updated EXE with the next update. If you want to use it immediately, you need to download the EXE from GitHub and overwrite the old EXE in the "include" subdirectory. Do not overwrite your configuration file; only the EXE is required.
(You might need to create a new API key in Exbitron.)
https://github.com/cryptix-network/exbitron-liquity-bot/releases/tag/v0.2.6
The NFT Editor has a few new features and some methods have been changed. At 128px resolution, it was a bit choppy on less powerful devices. This has been fixed. Additionally, metadata, such as your author name, can now be directly appended to the exported JSON file. It's also possible to write preview images directly into the JSON and hex files, so you can draw directly using code/numbers.
Here's an example of what's currently possible with the editor. I've attached the file below; you can load it in the editor.
And remember, NID-NFTs are encryptions/passwords/identities. They offer entrophy and are not just images. In this example, it's 53220.67 bits, which is roughly 270 times what a quantum computer (if they ever actually achieve the expected performance) could crack.
Memberarea:
https://cryptix-network.org/member-area


Cryptix NFT-ID Protocol (NID) - Beta Launch
NID is a new on-chain protocol that transforms hand-drawn pixel graphics into deterministic, cryptographically relevant identity objects.
NID assets are not traditional NFTs. They are simultaneously:
• a reproducible, human-created pixel artifact
• a measurable entropy object (information, not just an image)
• an optional component for secure identity and key-derivation pipelines
Goal: reconnect digital identity to real human action and explicit intent — instead of automatically generated imagery.
How it works
The user draws pixel art (8×8 up to 128×128)
The pixel matrix is deterministically serialized and encoded as hex
Entropy is computed (Shannon entropy × number of non-zero pixels)
The hash of the pixel matrix serves as a verifiable fingerprint
Optional: used as a seed component within KDF-based security setups
Every NID file is fully reproducible without off-chain storage.
The pixel matrix itself is the source of truth, not a linked image.
Use cases:
• visual digital identity tied to human authorship
• proof of intentional creative action (anti-AI art spam)
• entropy component in secure key pipelines
(always combined with password, salt, and KDF — never alone)
• on-chain assets for systems requiring authenticity over volume
• comparison and ranking based on measurable information structure
Core idea:
Artwork is not only stored — it is treated as an information unit.
NID merges human creativity with cryptographic structure.
In an environment flooded by infinite AI-generated imagery
NID restores value through human intent and quantifiable informational content.
To summarize briefly: It aims to bring NFT back to its roots. Human-created and valuable, it should be art, not spam. Furthermore, every NFT can become a password, keyphrase/seed – or a salt for it – an identity, a connection (like group chat access via an NFT), an encryption. It combines art, blockchain, and security, all the way to quantum security.
In the member area, you'll now find a tab that allows you to create such NFTs. Currently, there's no function to mint them or submit them to the blockchain. However, a save and load function allows you to work on your NFTs at any time and prepare them for future use.
Whitepaper:
Read the Whitepaper
Memberarea:
https://cryptix-network.org/member-area


Cryptix All in One 2.4 Release:
- Adds the DEX Daemon to the Member Area tab
-- Provides background and window modes for the DEX Daemon. In window mode, the daemon's processes can be monitored via the logs.
-- The daemon configuration can be modified via the Config button, for example, for using a local node.
- Adds the DEX price to the Node tab
- Changes to the automatic termination of background processes when the program is closed.
- The delete data button in the Wallet tab has been reworked and should now function correctly. However, the cookie API in the WebView version, which the software uses, is not yet fully developed. In my tests, it sometimes worked and sometimes didn't. There is a batch file named "delete_cookies" in the software's main folder. Simply open this file briefly to delete the cookie files. The software must be closed beforehand.
Github
You can get CPAY on several exchanges. Please note that CPAY cannot be purchased directly with fiat currencies —
you’ll need to exchange it for other cryptocurrencies such as USDT or USDC first.
CEX:
Exbitron: CPAY/USDT
Fyn-EX:
CPAY/USDT -
CPAY/USDC
DEX:
Cryptix DEX: CPAY/All
OTC:
Stianor: Discord
Elva from Fyn-EX wrote to me with the information that trading there is already possible:
The official release will be on November 14, 2025, as some improvements are still being implemented, but in principle, the market is open and usable.
For Cryptix CPAY, the following pairs are available:
CPAY / USDT
CPAY / USDC
lease note that Fyn-EX is still a new exchange, so some initial issues might occur. I can’t comment on the reliability of the exchange — but of course, I’m hoping for the best.
And remember: Not your keys = not your coins.
So folks, the time has come — we’re releasing the Cryptix DEX.
Let’s start right away with the most important questions for crypto bloggers:
Will it give crypto bloggers sleepless nights? Yes.
Is it GPLv3? No.
Is it patent-protected? No.
Was it a lot of work? Oh yes.
Alright, jokes aside — here’s the serious part:
First, it’s important to understand that a DEX (Decentralized Exchange) is not a CEX (Centralized Exchange).
A CEX has its advantages and serves a different purpose.
For example, it offers fast liquidity and quick trades.
A DEX, on the other hand, gives you full control over your coins — no one else holds them.
Some users prefer this for reasons of trust and security.
It’s also more anonymous, and trades happen directly on the blockchain.
The DEX isn’t meant to compete with or replace a CEX.
It’s an independent alternative — another way to trade.
This means we remain tradeable at all times, even if a CEX goes offline, shuts down, or anything similar happens.
That said, I don’t think this will ever be the case with Exbitron — they’ve always been there, no matter what.
I’m confident that’ll continue.
Still, no matter what new regulations arise or what issues CEXs might face, we’ll stay independently tradeable.
That’s the real benefit.
But not only that — the DEX also includes several modules, such as the Cryptix Payment Gateway, which has now been battle-tested through the DEX.
Thanks to this testing, the module was completed earlier than planned.
The DEX also opens up possibilities for more things:
- Token and NFT trading/swapping (if we decide to release these functions — not 100% confirmed yet)
- A potential marketplace
- Fully decentralized payments for all kinds of goods, including hardware
- Even a hashrate marketplace
Everything will build on the developed DEX technology — there are incredible new possibilities ahead.
Technical Overview: How It Works
1. Create an Offer: The seller specifies the amount, price, and payment method (for example, PayPal, bank transfer, or Bitcoin).
2. Secure the Offer: The chosen amount of CPAY is locked in a multisig wallet and verified on-chain before it becomes visible.
3. Choose a Buyer: Buyers browse verified offers, register, and reserve the one they want.
4. Payment and Confirmation: After the external payment is completed, both parties sign to release the CPAY to the buyer.
All actions are automated through the local DEX Daemon software, which securely manages the wallet and signatures.
No technical or blockchain knowledge is required.
I recommend using a local node so that no sensitive data is transmitted between your wallet daemon and the internet.
If you use the public node, it works similarly to a web wallet.
Both options are available — it’s a matter of security vs. convenience.
That’s why I’ve provided both possibilities.
The All in One software will have the Dex integrated directly with the next update, which should be tomorrow. Currently, however, you only need to launch the EXE manually, in addition to the All in One software; that works too.
The daemon for Linux will be available at a later date, once we've completed the initial testing phase with Windows.
Access the DEX
Read the Whitepaper
View Terms & Rules
Download: DEX Daemon Win64
Github
And please, back up your keys. In the Dex daemon's root directory, you'll find the "user_wallet" folder. This contains your keys. If you lose them, your coins are lost.
Here is the first whitepaper version of the Cryptix DEX. Please note that the DEX is technically only 80% advanced, which means changes can still happen.
Cryptix DEX Whitepaper
We present a new innovation that will make crypto bloggers nervous and their fingers sweat.
The WORLD'S FIRST (who cares) lattice-based keyphrase system for quantum security. Patent protected (no, it's not), GPLV3 (no, not either, but MIT). Joking aside.
What do you guys think, as a basis?
Lattice-based keyphrase system for quantum security
To make the Lucky Reward System a bit fairer and to prevent the excessive use of virtual workers on CPU—where the Fusion system is simply started with one thread—I have updated the Fusion Reward System.
Each user can now submit a maximum of 5 tickets for CPU and 5 tickets for GPU.
This means the maximum possible is 10 tickets in total (5 for CPU and 5 for GPU).
Users can still use an unlimited number of workers for CPU and GPU, but this only affects the Lucky Reward System. The tickets per user are now limited to make it fairer.
Since there still seems to be some confusion about the Lucky Rewards and I’ve been getting private messages about it, here’s a clear explanation:
The Lucky Rewards are not taken from the total CCPI. The calculations and rewards work exactly the same as before. The Lucky Rewards are basically a gift from me — participation doesn’t require any kind of payment or stake.
Each worker counts as one ticket. More workers mean more tickets and therefore more chances. It doesn’t matter how much CCPI or computing power a device has.
The rewards, especially the rare ones, don’t appear exactly every 2 days or 10 hours. They’re generated based on mathematical randomness. I can only calculate an approximate timeframe, like “about every 10 hours,” but it might take 20 hours or sometimes happen twice in one hour. It works similarly to mining in that sense.
Some people might think they can exploit the system by starting many instances to get more workers. Technically, that’s possible — at least for CPU devices — but it’s been accounted for. Devices that try this won’t gain high priority, and overall computing power (CCPI) will be reduced. Over time, this would actually be a disadvantage for the user.
So, the Lucky Rewards are completely free to join and purely additional. Every worker has a chance, no matter how small. This system is designed to support smaller miners who might only make $0.05 a day with a worker, giving them the chance to earn an extra $0.10 reward, which can significantly boost their profit. This makes smaller devices more profitable over time. But large miners can also receive rewards — it adds up noticeably over time.
The goal is to support older and weaker hardware. The principle is “use it instead of throwing it away or buying new.” Everyone has old CPUs, GPUs, laptops, or mini-computers lying around. In the Fusion system, these can still generate strong profits (no guarantee, of course). The Lucky Reward system is designed to break the usual “pay-to-win” pattern, and the reward values are mathematically balanced — they’re not random guesses.
Another common misunderstanding: in the Fusion system, users are not competing like in traditional mining. They work together. In normal mining, when more users or computing power join, your individual rewards drop. In Fusion, it’s the opposite — the more users and computing power there is, the higher the CCPI per device becomes. This works because larger and more complex jobs can be processed when the system grows stronger and more relevant. So more users and workers mean more profit for everyone. There’s even a built-in multiplier that supports this concept.
The whole idea is to break away from the typical competitive “mining PvP” model and replace it with a cooperative system that benefits all participants.
The Fusion System now features a new function called “Lucky Rewards.” Every participant has the chance to receive additional rewards, regardless of their CCPI performance.
Each active worker receives one ticket per draw. Draws now occur every 30 minutes and distribute random rewards ranging from $0.005 (≈ 17.30 CPAY) to $0.05 (≈ 173.01 CPAY), which are automatically converted into CPAY. In addition, there is a 1% chance to win $1.00, and a very rare 0.017% chance to win $25. There is also a 5% chance to win $0.25.
The system is designed primarily to support smaller miners. While the rewards aren’t huge individually, receiving them every half hour allows them to accumulate over time. For users who generate only around $0.05 per day with their devices, winning $1 or accumulating smaller rewards can significantly boost earnings. The system is also intended to encourage users to use old/weak hardware instead of buying new ones.
Larger miners with a single powerful device might not notice a big difference immediately, but even for them, the rewards can add up over time. Importantly, Lucky Rewards are completely additional — your regular rewards and CCPI remain unchanged. It’s a free bonus system with no investment required.
And yes, since the system had a provisional 1-minute reward test, you may already have some rewards in your account. The 24-hour stats were cleared for a new cache system, but this did not affect any rewards.
Summary of Chances for All Workers:
$25 Bonus → ~every 120 days
$1 Bonus → ~every 2.1 days
$0.25 Bonus → ~every 10 hours
$0.005–$0.05 Bonus → every 30 minutes

We just checked out these spammers, the so-called “trading experts.” I wanted to see what their scam actually looks like. I thought it would be some kind of platform or a pyramid scheme. But no—it's even worse.
They send you a so-called trading software that supposedly does everything for you. But through the API / a keylogger, it just steals all your coins from Binance and other exchanges. A simple Trojan scam.
I didn’t think of that at first, because they present themselves as trading experts—when in reality, they just want to push malware on you. They even have a fake video showing supposed profits. They’ve even hidden the virus inside an app.
Here are typically Profiles of such Scammers and a Screenshot of the Virus Software.
As you can see, they've been doing this for over two years. Because in the video, you can see 2023 in the tab.
I actually wanted to track them with an IP tracker and other things, but they didn't open any pictures or URLs of me. So they know exactly what they're doing. This is planned, intelligent gang crime / cybercrime; these are not amateurs.

Let’s talk about spam:
Even though many users are experienced and already know this, some don’t. On Discord, there are many spam bots whose main goal is simple: to get your money. They are trying to scam you.
Here are the most common methods:
Invitations to so-called “Support” Discord servers
Friend requests and private messages from fake “support staff”
Job offers in the crypto or programming space
Trading messages like “You’ll make insane profits!”
If supposed “support staff” invite you to external Discord or Telegram groups – it’s 100% a scam.
If you receive strange job offers – it’s a scam. You’ll likely be used for criminal activity and could even face legal consequences.
If so-called “trading experts” message you, ask yourself: if they really made so much money, why would they need to spam strangers? Exactly – because it’s a scam.
Protect yourself with these simple steps:
Do not join external Discord groups, even if they are called “Support” or something similar.
Do not chat privately with so-called support staff or “crypto experts,” especially not on Telegram or Discord.
Do not open links from strangers – they may contain malicious scripts that can even drain your wallets.
Never share your key phrases, passwords, or seed phrases. Don’t trust anyone who gives you a “free” seed phrase either – that’s another scam trick.
Send nobody Money or Coins !
Trust nobody on the internet. On the internet, anyone can pretend to be anything – even a unicorn.
If a stranger messages you on Discord, in 99% of cases they only want one thing: to scam you and steal your money – especially in the crypto space. Don’t accept random friend requests, don’t share private information, and don’t hand out sensitive data. Simply: trust no one. That’s the only way to stay safe.
Also, be very careful with crypto code, mining software, nodes, and similar tools. Just yesterday, I saw code on GitHub for a cryptocurrency node that had a keylogger built right into it – openly in the source code, even commented and easy to spot. There are targeted crypto projects designed to turn you into part of a botnet or to infect your wallet.
And one very important point: never open ports on your computer. That’s an easy way to get hacked. I also recommend that everyone use antivirus software. Even free versions of Avira or Avast provide good protection.
Displays the current market price and hashrate. Updated every 15 minutes.
1. Install the App
2. Activate the Widget in your Home Screen
( To activate the Cryptix widget, long-press on an empty space on your home screen, select 'Widgets' from the menu, then find 'Cryptix Widget' in the list. Drag it onto your home screen and it will start showing the latest coin price and hashrate automatically.)
Virus: Check:
https://www.virustotal.com/gui/file-analysis/MGZiOTliMjZjNDc1OWMxNWNmMjE2NjI4ZjczMGY4NWU6MTc1OTIzNzU4OA==
Download:
Download
Github:
https://github.com/cryptix-network/cryptix-widget-android/releases/tag/v1.0.0

Let's talk about locusts in mining.
Anti-Locust Tokenomics: Designing Sustainable Proof-of-Work Networks
Withdrawals are now processed automatically by the Fusion system. There's no longer any need to wait; the server performs these transactions every two minutes. However, during the test phase, only amounts up to 2,500 coins are accepted; anything above that will continue to be manually reviewed until the system has been properly tested.
However, you will receive withdrawals of up to 2500 coins immediately (after 2 minutes at the latest).
https://github.com/cryptix-network/cryptix-wallet-daemon-tcp-trigger
There's now a TCP script that connects the wallet daemon to any interface for generating addresses, sending coins, and other functions. It's usable for exchanges and other functions that want to connect automated processes.
Dashboard:
The new Dashboard v2 has many new features. Some of these functions required a lot of performance, especially the block visualizer, which caused the Chrome Tab Killer to kill the tab after a long period of inactivity. I've now reworked this so that I was able to reduce the performance to 30% of what it was before. And many functions are disabled when the tab is not active or the function is in view. Now the browser's tab killers no longer intervene. Reload the dashboard on your devices if you have it open.
Webwallet:
There was a bug in the web wallet that prevented transactions from being processed after a prolonged period of inactivity and no longer displayed the wallet balance after a transaction. This bug should now be fixed.
Web Faucet:
It's back online now. I've integrated a small payload/DDOS protection, which should be sufficient.
Memberarea:
There was a bug that sometimes recorded 0 CCPI for the statistics. While the payouts were correct, the statistics cache didn't record them. This bug should now be fixed, so the statistics will no longer record 0 values for the history.
The explorer will now display the alias if you have entered one for your wallet address.

We are often asked what’s better for earning CPAY.
Here’s how I would roughly sum it up:
NVIDIA GPU: → Direct mining on the blockchain using the OZM Miner software together with a pool or your own node. Later on (once more jobs are integrated), Fusion might temporarily become more efficient, so it’s worth testing from time to time, since efficiency could fluctuate. However, if you don’t want to keep switching back and forth, staying on direct blockchain mining is the safer option. As of now, direct blockchain mining with NVIDIA is the most efficient.
AMD GPU: → Use the Fusion system (OZM and Cryptix Miner don’t support AMD GPUs due to OpenCL, but Cryptix Fusion does).
Intel and onboard GPUs /vGpus: → Use the Fusion system (again, OZM and Cryptix Miner don’t support AMD/Intel GPUs because of OpenCL, but Cryptix Fusion does).
CPU: → Use the Fusion system. While the Cryptix Miner technically supports CPUs, Fusion provides significantly higher CPAY efficiency on CPU hardware.
Cryptix Blockchain Mining Supports: All CPUs, NVIDIA GPUs. Windows, Linux, HiveOS, MMPOS. Computers, Servers, Laptops.
Cryptix Fusion Supports: All CPUs, NVIDIA GPUs, Intel GPUs, AMD GPUs, Onboard & vGPUs. Windows, Linux, HiveOS, MMPOS, Android. Computers, Servers, Laptops, Smartphones, Tablets.
https://git.mmpos.eu/linux/cryptix-fusion
MMPOS has added the Fusion System. Anyone who wants to use it there simply needs to select it.
https://app.mmpos.eu/
– Release Notes

Dashboard: Fixed bug with the “Reload” button
Windows: Resolved text zoom issue
Miner Tab: Previously saved configuration now loads automatically on open
New Tabs Added:
Member Area
Fusion Worker with Software
Wallet: “Send Coins to Alias” feature integrated
CUDA: Updated version available for NVIDIA 5XXX GPUs
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.3.0
It's possible to run the blockchain miner and the Fusion worker simultaneously. For example, you can mine directly on the blockchain with the GPU and use the CPU with the Fusion system.
You can also simply download the new files and copy them into the old folder, thus overwriting the old ones. This way, you'll remain logged into the wallet and your dashboard settings will remain intact.
Alias can also be checked without member access.
https://cryptix-network.org/alias-lookup
Anyone ready can get started. The AUTH servers are up, and the files should work.
For Windows, there’s basically nothing to do. Installation instructions for Linux / Hive Shell can be found here:
https://cryptix-network.org/cryptix-fusion-software
Hive Shell also works. Just create a custom wallet and name it “Fusion,” then enter your CryptixID. Next, set up a custom flight sheet with that wallet and a custom miner. Enter the GitHub URL for the download (https://github.com/cryptix-network/cryptix-fusion/releases/download/v1.0.0/cryptix_fusion_v1_hive.tar.gz), and the miner name will be automatically selected correctly.
For the wallet template, enter %WAL%.%WORKER_NAME%. You can enter any pool, it won’t actually be used. In the extra arguments, simply enter --cpu or --use-gpu --use-nvidia, and then start.
Apparently, only a custom miner is possible via Hive's flightsheets. Therefore, if you want to use both CPU and GPU, for example, I would recommend using the GPU via the flightsheets and the CPU via the shell. This allows for two instances. Nothing extra needs to be installed for the CPU instance. For the GPU instance via the flightsheets, nothing needs to be installed. For Linux/Hive Shell with GPU, CUDA 12.4 must be installed.
CCPI will also be displayed in the dashboard. Instead of showing very small numbers like 0.0000454, it will display 454.
We're now testing for the CPU. GPU AUTH is also open, and it would also be usable on the GPU, but it's not yet as profitable due to a lack of jobs. However, anyone who wants to use/try their GPU can do so.
Also, be patient; I might have to restart the server to allocate more RAM or cores to the VM. Or similar "child's play" problems.
And now I need to integrate/activate more and more jobs. Everything is programmed very modularly. This means I can do a lot without stopping the service or requiring a software version. We're starting with the four different jobs, which means the profit will change and improve with more jobs. The CCPI also needs to be adjusted. But just give it a try and let me know your values.
https://github.com/cryptix-network/cryptix-fusion
It is important that the Fusion software is started with the correct tags.
CPU jobs are started with the --use-cpu argument.
GPU jobs are started with the --use-gpu argument.
GPU specifics:
The additional tags are crucial: --use-amd, --use-nvidia, and --use-mixed:
--use-amd will launch OpenCL on all AMD devices in the rig/computer.
--use-nvidia will launch CUDA on all NVIDIA devices in the rig/computer.
--use-mixed will launch OpenCL on all devices in the rig and also create a fallback job from the CPU Server.
Some jobs run better on AMD, while others run better on NVIDIA. That’s why it is important to provide the authentication server with the correct hardware information — so the most profitable jobs can be assigned. CUDA and OpenCL can technically run the same jobs, but the performance depends on the specific job.
The --use-mixed tag is mainly intended as a safe fallback for any hardware. It can also utilize Intel chips, onboard GPUs, and other devices. However, since it relies on a fallback CPU job, profitability will generally be low. On a laptop, though, if you’re already running Fusion, it can be a way to squeeze out a bit more from the onboard GPU.
Mixed rigs:
In theory, it should be possible to start separate instances for AMD and NVIDIA GPUs.
That means:
Run one instance with --use-nvidia to activate the NVIDIA GPUs.
Run another instance with --use-amd to activate the AMD GPUs.
It’s also possible to start an additional instance for CPUs, so in total three instances could run simultaneously. This setup still needs to be tested.
CPU and GPU mining use the same software. The startup arguments are already configured, so it works on both Windows and Linux. All you need is your CryptixID — the auth server handles all configurations, addresses, and connections automatically.
For Windows, ready-to-use BAT files are provided: just insert your CryptixID and run. Alternatively, you can start the software from the console using the appropriate arguments:
CPU only:
./cryptix-fusion -u <cryptixID> --use-cpu
Limit the threads with:
--threads=4
Totally:
./cryptix-fusion -u <cryptixID> --use-cpu --threads=4
GPU only:
For NVIDIA GPUs (CUDA):
./cryptix-fusion -u <cryptixID> --use-gpu --use-nvidia
For AMD GPUs (OPENCL):
./cryptix-fusion -u <cryptixID> --use-gpu --use-amd
For other GPUs or if you have issues (OPENCL experimental):
./cryptix-fusion -u <cryptixID> --use-gpu --use-mixed
You can append a worker name to your ID using a dot, e.g.:
-u <cryptixID>.workercpu
You can also start the software twice on the same device: once with CPU only and once with GPU only. This allows both CPU and GPU Jobs simultaneously.
The development of the Worker software is moving forward
We decided to use XMrig as a container, added our own logic, and removed everything unnecessary.
Why XMrig? Because it’s one of the best open-source projects out there: clean, well-structured code, and it already includes everything we need (thread detection, OpenCL/CUDA, HugePages, etc.). Plus, it runs on almost any rig or PC.
How to start the software:
For CPU: ./cryptix-fusion -u cryptix_id --cpu
For GPU: ./cryptix-fusion -u cryptix_id --gpu
For GPU with type: ./cryptix-fusion -u cryptix_id --gpu --amd (also works with nvidia or mixed)
That’s it. All other settings will be fetched automatically from the AUTH server, including the right Work server and binaries.
You can still use XMrig configs, but only partially. Some job types won’t be supported — so it’s better not to edit the config unless you really need to.
You can also run CPU and GPU at the same time by starting the software twice (once with --cpu, once with --gpu). Or just run one of them — it’s fully modular.
We can release the CPU in about 7 days, give or take a few days. I'm currently still working on the worker software and adding the final features. But the basic functions are all finished and working. The AUTH server is also fully functional, both for the CPU and GPU. I'll release the software directly for the CPU and GPU, although we'll lock the AUTH server for the GPU for now. It will be activated approximately one week after the CPU.
There's still a bit of work to be done, especially because I still have to integrate the Fusion system into the ALL-in-One software. It will also be available there upon release, along with the member area. And it can be started with a single click.

Here is the regulatory information for the Cryptix Fusion System:
Regulatory Information Fusion
Current Fusion System Progress:
Step 1:
✅ Login and Registration System
✅ Withdrawal System
✅ Transaction System
✅ Discord Integration
✅ Database System
✅ Blockchain Integration
✅ CPU CCPI Backend
✅ CPU ↔ Member Area Connection
✅ CPU Server 1
✅ CPU Server 2
✅ CPU API & Cache System
✅ Performance Tracking
✅ Alias System
✅ Security Audit
✅ Alias Membercard / Website
✅ Alias Toplist Connection
✅ Fusion Withdrawal Integration
✅ Work Auth System
In Progress:
🔄 CPU Worker Software (Test runs started)
Waiting:
⌛ V1 Release / Early Access (Public CPU Release)
After the V1 Release - Step 2:
✅ GPU CCPI Backend
✅ GPU ↔ Member Area Connection
✅ GPU API & Cache System
✅ Withdrawal Integration
✅ GPU Withdrawal Integration
✅ GPU Server 1
In Progress:
🔄 GPU Worker Software (Test runs started)
🔄 GPU Server 2
Waiting:
⌛ CPU & GPU adding more Jobs
⌛ CPU & GPU Server 3
⌛ CCPI adjustment
⌛ Cryptix Fusion Website
⌛ V2 Release / Main Release (Public CPU & GPU Release)
Questionable:
❓ HDD/ SSD / M2 - Hard drive integration
❓ RAM integration
❓ Smartphone Worker APP
The question has come up several times: “Can the Fusion System mine CPAY directly, on the blockchain?” The short answer is yes — it can, for CPUs and Nvidia GPUs.
However, in most cases it won’t. The reason is that direct CPAY miners on the blockchain contribute to security and stability, including mining pools and software providers, and we don’t want to disadvantage them. The Fusion AI will therefore only use the CPAY blockchain under rare conditions: when profitability is higher than all other jobs by at least 20% and remains so for at least 24 hours, or when done manually because the blockchain requires higher security or hash rate. Even then, it must still be the most profitable option.
This means that while the Fusion AI can switch to the CPAY blockchain, it will happen only very rarely. Our own blockchain is included in the system but comes with safeguards, ensuring that existing pools, mining software providers, and miners are not disadvantaged, keeping the system fair.
For CPUs, it is highly unlikely that the CPAY blockchain will ever be the most profitable — this would require a massive surge in the CPAY value. For Nvidia GPUs, it might happen occasionally. AMD GPUs are still not supported for direct CPAY blockchain mining, although a mining software developer could potentially implement it.
That said, the Fusion System does support AMD GPUs, so indirectly, they will also be able to earn CPAY through the Fusion System in the future.
This means that direct mining in the blockchain will still be relevant, and even more effective than using indirect methods if you want to specifically mine CPAY. For this, you have to compare the profitability of CPAY and Fusion yourself.
Alias can also be checked without member access.
https://cryptix-network.org/alias-lookup
On Cryptix Fusion there are different jobs for CPUs and GPUs, since both types of hardware have their own strengths. CPUs are very good at cryptographic tasks such as encryption and decryption (not just mining – cryptocurrencies are only one part of cryptography). They handle serial, dynamic tasks well. GPUs, on the other hand, are designed for parallel work and are well suited for things like AI training (deep learning), large model inference, 3D rendering and ray tracing, scientific simulations, or heavy data processing.
The system automatically checks which type of job is the most profitable at any given moment and assigns your hardware to it. If something changes, your CPU or GPU is immediately moved to another task. Mining is also integrated: if it becomes more profitable than regular compute jobs, the system switches to mining. The goal is simple: you always earn the maximum profit without doing anything manually. All you need to do is start the software. The system runs completely automatically and recalculates profitability in real time every 60 seconds.
It doesn’t just look at whether you are using a CPU or GPU, but also at your individual hardware. Some systems may perform better or worse depending on their configuration. For example, if certain technologies like Hugepages aren’t enabled, your system might not be suited for a specific task, even though your hardware type usually is. Because of this, the system checks every five minutes whether your machine is reaching its expected CCPI. If not, you are automatically redirected to a different job where your setup performs better. When you first start the software, you are given a fallback task so the system can measure how well your hardware performs, and then it adjusts your jobs from there. This way, every worker is optimized individually for maximum profit.
This technology and automation are already finished and working. We are currently in testing. At beta release, only a limited number of tasks will be available, but over time we will add more jobs and coins, which will steadily increase profitability. We already have partners for non-mining jobs, and these will expand and vary as time goes on. So give the system a little time to grow. From my own CPU tests, I haven’t found any way to earn more profit than with Cryptix Fusion, but I can’t promise this for everyone. That’s why it’s important for users to test and let me know if they find something more profitable – I can usually integrate new tasks into the system within 24 hours.
The advantage for you is clear: one piece of software, maximum possible profit, and a member account where you get paid every five minutes in CPAY.
Read the new Cryptix Fusion whitepaper to understand the system.
Fusion Whitepaper
There is a publicly visible leaderboard in the Member Area that shows the top 5 users for both GPU and CPU. Each entry displays the user’s alias, which automatically links to their Cryptix Member Card.
On the Member Card itself, a small badge is displayed—but only for users in the top 5 of each category.
The design of the Member Card is currently temporary and will be properly updated soon to improve its appearance and overall user experience.


Anyone who sets an alias in the Member Area (https://cryptix-network.org/member-area) will now automatically get a dedicated page on the Cryptix domain:
member.cryptix-network.org/{ALIAS}
On this page, there is a small user card showing your alias, wallet address, a QR code for your wallet, and a personal note. You can set your personal note (up to 100 characters) in the Member Area — for example, to verify that you own the alias or to add any other information.
Here’s my card as an example:
https://member.cryptix-network.org/cryptis


The web wallet already has a feature that allows you to send coins to an alias/username without requiring the wallet address.
This will be available in the All-in-One software with the next update. This update will also integrate the Member Area into the All-in-One software.


The Fusion System is now fully integrated with the Withdraw Account System and ready for use. We are currently conducting the final tests for the automated releases of the 5-minute work blocks into the account funds.
So far, everything seems to be working.
Which brings us to the final step:
The software for users’ computers (Windows, Linux, Hive, MMPOS).
This raises some questions where the community is welcome to share their opinions—collective input is likely better than just a few minds deciding.
Information on this:
One software for everything? CPU, GPU, and hard drives,
Yes, hard drives are also planned as the latest development and might even come before GPUs—or afterwards. This way, even more profit can be extracted from each device.
As mentioned, each user can freely choose whether to use only CPU, only GPU, only hard drives, or any combination.
Then the question arises: do we create a single software where everything can be configured? Or separate software for CPU, GPU, and hard drives?
A unified software has the advantage that it only needs to be installed once for all device types. However, it also has the disadvantage that it must be updated every time any of the three types is changed or expanded. For example, a CPU user would have to update the software even if only the HDD functionality is upgraded. Additionally, inactive functions/modules in a unified software still consume storage space and performance. A user who only wants GPU mining might still have to load and store CPU and HDD files.
From a development perspective, it is probably better to use separate software because it is modular.
Therefore, I currently lean toward separating the software so that there is one program each for CPU, GPU, and hard drives. This would make it modular and efficient, avoiding unnecessary files, storage use, and functions for each user.



There's now a way in the memberarea to find wallet addresses using an alias. This is the alias associated with your Cryptix ID.
This alias will soon also be usable for blockchain transactions, so you no longer have to enter the wallet address, but only the alias.
You can only get an alias if you create a Cryptix ID in the new member area.

https://cryptix-network.org/member-area
7 Days (2025-09-19 03:50:43) to next Block Reward Reduction:
From:
Block Reward: 6.6742 CPAY
To:
Block Reward: 6.2996 CPAY
-5.61%
In the main tab of the Member Area, there is an alias that can be freely set and changed. It works like a "username." Each alias/username is unique, and the first person to choose it secures it. The username can also be changed every 60 seconds if you decide to update it.
What the alias is used for:
Currently, the alias is used for the Fusion users leaderboard. Additionally, a system is in development that will allow coins to be sent to an alias. This means that a wallet address will no longer be required. Coins can then be sent using either the wallet address or alias, in the web wallet, All-in-One, and app, with CLI support coming later.
The alias will also be used for other upcoming features, but I’m not revealing those just yet.
And:
A Login via Wallet-Address in the Memberarea is now possible. You dont need to use the CryptixID alltime.
Quick Summary (for those who don’t want to read much):
Connection time: ~5 minutes before your device shows up in the member area (reward calculations start immediately)
Calculation time for correct CCPI display: 10–15 minutes (delays are compensated after disconnect)
Payouts to Locked Balance happen automatically every 5 minutes (reconnects are considered)
Transfer from Locked Balance to Account Balance happens automatically every 60 minutes
---
More Details:
Fusion reward calculations are done in 5-minute blocks.
In each 5-minute block, the CCPI value for a job is recalculated, and the CPAY payout amount is adjusted. This means you may receive slightly more or less CPAY for the same job, depending on CPAY’s market behavior. CCPI values also fluctuate, since a job switch can occur every 5 minutes.
The key thing to understand: each Fusion Reward Job Block represents 5 minutes of work, which is paid out immediately and marked as Locked Fusion Balance. This applies regardless of the device or hardware type – each device has its own tasks and 5-minute job blocks.
Every 60 minutes, the Locked CPAY Balance is released and a transaction is created, making the CPAY directly withdrawable. Why every 60 minutes? To avoid overloading the system when many users are online. Multiple servers report their 5-minute performance blocks to a master server, and there are locking mechanisms to prevent collisions.
We modeled this system after blockchain technology, but it is not a mining reward system – cause users are not competing with each other. In fact, they work together, and the more users there are, the higher the CCPI value will likely be for everyone.
There are several protection and delay mechanisms to prevent exploits. This is why it usually takes up to 5 minutes before you can see your devices and hashrate in the member area. It can take up to 10–15 minutes before the correct CCPI is calculated and displayed. However, these start-up delays are compensated: after disconnecting, you still receive rewards for the same amount of time. This prevents "connect-jumping" exploits. It also ensures the system has enough time to read the old databases and create new ones.
What is CCPI and how should it be understood? Well, the computing tasks for Cryptix Fusion are not limited to mining. They are dynamic, depending on the job and its value. While mining is one possible task, other tasks can include AI training, encryption and decryption, scientific calculations, and various other jobs that require computing power. And only in mining does it make sense to measure performance in hashes per second.
That’s why values like H/s, MH/s, etc., are not meaningful here, and we needed to create a new indicator. This led us to develop CCPI (Cryptix Computing Power Indicator).
Every job requires a certain amount of computing power and has a financial value over time. This allows us to calculate how much computing power is needed to generate a specific value. Such an indicator is universal and can even be used for mining—often better than traditional metrics. For mining, simply looking at KH/s is insufficient; you also need to consider block rewards, coin value, and network hashrate.
In short:
1 CCPI = $1 per 5 minutes, which is $12 per hour, $288 per day, etc.
0.1 CCPI would be 10% of that, or $28.80 per day.
We also had to decide on the calculation interval. To avoid overloading the databases while still providing accurate indications, we chose 5 minutes. From this, one could also derive sCCPI (CCPI per second) or similar metrics.
In summary, CCPI is a newly developed indicator that measures the value of computing power. It is expressed as a numeric value representing $1 per 5 minutes and is universal for all types of hardware and all types of tasks.

https://cryptix-network.org/cryptix-ccpi

We have decided to start the Beta Release with CPU only. Why? For direct mining in the blockchain, GPU support is already available. CPUs have always been underutilized until now. Therefore, during the initial Beta period, the Fusion section will be available CPU-only. Supporting both CPU and GPU simultaneously would be too much to monitor and optimize.
It’s important to note that the Fusion system in the Member Area is completely custom-built. Everything visible in the Member Area has been programmed by hand—no ready-made scripts or templates are used, except for the statistics charts, which use Charts.js. It is a fully independent frontend and backend system. Even our database system does not use SQL or PostgreSQL; it is self-developed as well. This allows us to provide higher performance and security.
Such systems are complex, which is why we will need to adjust and correct a lot during the Beta Release. This includes calculations of CCPI and CPAY payouts, which we have initially set a bit high for users.
For these reasons and more, we have decided to start with CPU. However, it likely won’t be long before GPU support is added, as the system is already compatible with GPU and could be enabled quickly. This also allows for AMD GPU support, so more hardware can participate efficiently.
It is also important to emphasize: unlike traditional blockchain mining (which remains available), users or hardware types do not compete in Fusion. The network CCPI does not reduce profits for users. On the contrary, a higher CCPI allows us to process more, generating more liquidity. This means that the more users participate, the higher the CCPI becomes.
Current Progress:
Step 1:
✅ Login and Registration System
✅ Withdrawal System
✅ Transaction System
✅ Discord Integration
✅ Database System
✅ Blockchain Integration
✅ CPU CCPI Backend
✅ CPU ↔ Member Area Connection
✅ CPU Server 1
✅ CPU API & Cache System
✅ Performance Tracking
✅ Alias System
✅ Fusion Withdrawal Integration
In Progress:
🔄 CPU Miner (Test runs started)
Waiting:
⌛ Beta Release (Public CPU Release)
After the Beta Release - Step 2:
Waiting:
✅ GPU CCPI Backend
✅ GPU ↔ Member Area Connection
✅ GPU API & Cache System
✅ GPU Withdrawal Integration
🔄 GPU Server 1
Waiting:
⌛ GPU Miner
⌛ Withdrawal Integration
⌛ CCPI adjustment
⌛ V1 Release (Public CPU & GPU Release)
Questionable:
Hard drive integration
https://cryptix-network.org/cryptix-fusion
Cryptix introduces Fusion, a new system that lets users contribute their CPU or GPU power to real tasks like AI training, scientific computing, and blockchain operations. In return, participants earn CPAY tokens. Unlike traditional mining, hardware types don’t compete – CPUs and GPUs each get the jobs they’re best at. Performance and rewards are measured with the Cryptix Computing Power Indicator (CCPI), making earnings transparent and fair.

https://cryptix-network.org/cryptix-fusion
You can now send your collected Discord Faucet Rewards to your Cryptix Account / Cryptix ID, and even have them sent directly to your blockchain wallet. Here’s how it works:
Create or view your Cryptix ID: https://cryptix-network.org/member-area
Link your Cryptix ID to your Discord Faucet account using the command:
/cryptix-withdraw-id
Send your coins to your Cryptix ID account using the command:
/cryptix-withdraw
(Each transaction allows between 250 and 5000 coins, with a maximum of 2 transactions per day)
Your Cryptix CPAY coins are now in your account.
To send coins directly to your blockchain wallet, request a withdrawal in the Withdraw tab.
Please note: actual blockchain transactions from your Cryptix account must be reviewed and confirmed by a team member. This may cause a delay in processing. Transfers from Discord to your Cryptix account are instant and take less than 1 second.
To create a Cryptix ID account, you only need a password and a wallet address. We do not store account data—if you lose access, it cannot be recovered.
If you don’t have a Cryptix wallet yet, you can create one here:
https://wallet.cryptix-network.org/
The Member Area is currently in development and already activated for users to register and test. This is the real account system.
Since I’ve received several private messages with questions, I’m now releasing the official information:
What is the Member Area?
The Member Area generates a CryptixID, which is automatically linked to your blockchain wallet. This connection cannot be removed, since the ID is calculated directly from the wallet. The CryptixID will serve as the foundation for new technologies such as Cryptix Messenger, Cryptix Fusion, and more.
All data is encrypted or stored as validation hashes, and no sensitive or direct information is ever saved. For example, your password is never stored directly – only its validation hashes. This means nobody can access or interfere with your account, not even me. The concept is similar to blockchain technology, which was the inspiration for this system. That’s also why no email, real name, or phone number is required – your Cryptix Wallet + password is enough.
What can you do in the Member Area?
For example, the Discord faucet bot will be connected here. Free coins can be sent to your CryptixID and then withdrawn directly to your blockchain wallet. The Messenger will also be integrated, along with further technologies like Cryptix Fusion – a technology we have never mentioned before. It doesn’t even appear in the whitepaper or roadmap.
The member area can be accessed directly from the browser, but will also be activated in the ALL in One software with the next update.
https://cryptix-network.org/member-area
If you mine larger cryptocurrencies with higher block times, you're likely being scammed by large miners. Read this:
Exploiting Negative Shares in Cryptocurrency Mining- A Solo-to-PPLNS Switching Strategy
https://cryptix-network.org/assets/downloads/exploiting-negative-shares.pdf
The dashboard has had a few updates and bug fixes. It now also displays 24h averages. Simply refresh the dashboard to receive the updates.
https://cryptix-network.org/cryptix-dashboard
We are developing our own hash function, intended to be used for our encryption system and to eventually replace the current use of SHA3.
The main goals are:
Maximum diffusion
Determinism
Compatibility with all hardware types
Speed
Security
The first draft version is available on GitHub. Anyone interested in contributing is welcome to do so.
The current placeholder implementation is functional, but it still needs to be made more complex, comprehensive, and thoroughly tested. It is therefore a placeholder and starting point.
Cryptix Frost Hash Github
Please note that swaps from CYTX to CPAY are still possible until August 28. After this date, we will no longer offer the old CYTX Explorer, the old CYTX Wallet, or the swap option via Exbitron. Therefore, anyone wishing to swap must do so by August 28. After that there will be no more possibility. We first announced the hard fork more than 3 months in advance and then enabled the swap for 3 months. We will not offer any further support for CYTX after that.
Quantum-Resistant Coordinate Derivation from Natural Language Passphrases
New Features:
X25519 Key Exchange
Shared Secret
Ephemeral Keys for Forward Secrecy
Explanation:
Adds end-to-end encryption so that only both parties can decrypt the messages.
The new features protect the encryption against later decryption attempts.
Increased protection against eavesdropping and replay attacks.
Read More

OneZeroMiner now offers support for CPAY mining. The new version of the software supports our Cryptix OX8 Hash.
Please note:
Currently only NVIDIA support (no Intel/AMD).
They have the Blake3 step directly on the GPU, meaning the hashrate is higher than with the community software. Much higher. I recommend using this software to ensure the highest possible chance of obtaining blocks. i tested on my 1080 ti, with 3 x faster Hashrate.
Please do not all connect to the community pool, this is entered in the standard start batch of the software, so change it to another pool.
It's also possible to mine without a pool, i.e., directly on the node. This requires the Stratum Bridge, which is then connected using this command:
:run
onezerominer.exe -a cryptix -w cryptix:your-wallet-address -o stratum+tcp://127.0.0.1:555 --worker rig_name
goto run
pause
HiveOS update script from v1.4.4:
cd /tmp && wget https://github.com/OneZeroMiner/onezerominer/releases/download/v1.4.5/onezerominer-1.4.5.tar.gz && tar -xvf onezerominer-1.4.5.tar.gz && miner stop && cp -rf /tmp/onezerominer/onezerominer /hive/miners/onezerominer/1.4.4/ && rm -rf /tmp/onezerominer/ && miner start
Downloads
Linux:
https://github.com/OneZeroMiner/onezerominer/releases/download/v1.4.5/onezerominer-linux-1.4.5.tar.gz
HiveOS:
https://github.com/OneZeroMiner/onezerominer/releases/download/v1.4.5/onezerominer-1.4.5.tar.gz
Windows:
https://github.com/OneZeroMiner/onezerominer/releases/download/v1.4.5/onezerominer-win64-1.4.5.zip
Stratum Bridge:
https://github.com/cryptix-network/cryptix-stratum-bridge-v3
Note:
The mining software provider is not part of the Cryptix team. They are external providers.
We want to introduce a new rule that blocks miners who abuse our network. This feature would:
- Automatically mark as invalid any blocks produced by miners proven to engage in harmful activities (e.g., 51% attacks, forbidden hardware use, or manipulation).
- Retroactively remove all block rewards from these miners to effectively punish abuse.
- Prevent a single miner from destroying or manipulating the network.
Importantly, this rule only affects the block rewards earned by abusive miners, not the coins held by regular users. It does not interfere with normal coins or wallets, only with the rewards tied directly to the mining activity of those identified as abusing the system. So, everyday users will not be impacted.
At first glance, such a rule might seem like a step away from decentralization. However, if we implement it so that the exclusion of a miner is decided through community voting, the process itself remains decentralized.
For example, we could use a Discord vote where every user can submit suspicious wallet addresses. This way, decentralization is preserved, and no central authority controls the decision.
This change requires a hard fork — a new version of the blockchain software that everyone must accept to continue participating in the network.
We want to discuss this idea with you and hear your opinions before developing a concrete plan. Please share your thoughts in the General Chat. We will then hold a vote tomorrow (Discord).
Superpositional Hash Functions (SHFs)
We have a new idea for changing the basic mining/hashing structure for blockchain.
Superpositional Hashing redefines mining:
By introducing controlled non-determinism into hash outputs, we unlock a new mining paradigm—fairer, more inclusive, and inherently resistant to specialized and quantum hardware.
The core hash algorithm, like SHA-256, remains unchanged. But instead of accepting only a single valid output, a defined "shell" of near-matches becomes valid. This superpositional output space:
• Increases success rates for smaller miners
• Reduces the dominance of ASICs and FPGAs
• Weakens Grover’s quantum speedup by diluting amplitude focus
• Achieves all this without adding computational burden or requiring new hash algorithms
The result is a more balanced, quantum-resilient mining system—paving the way toward a fairer, decentralized blockchain future.
Quantum-Inspired Probabilistic Hashing via Controlled Superpositional Output
Hey everyone,
Due to incidents like the one with Xeggex, I want to remind you that large amounts of coins should always be stored in your own wallet. Keeping coins in external wallets that you do not control can be risky.
Security Overview:
Third-party wallets (e.g., exchanges): Very low security – third parties have access to your coins.
Own wallet (e.g., web wallet): Higher security – only you have access to your coins.
Self-hosted wallet: Highest security – only you have access, and there are no external connections.
For maximum security, use the All-in-One software with the "local node" option or the CLI wallet.
Especially users holding larger amounts of coins should always err on the side of caution.
The Miner’s Paradox: A Psychological Investigation of Dumping Behavior in Cryptocurrency Mining
Read More
We currently plan to find a small bank as a partner for prepaid credit card payments that are backed by CPAY.
For example: A wallet with 10,000 CPAY could be used in any store, online shop, etc., for fiat payments because the CPAY would automatically be converted into dollars, euros, etc., and then used. So wherever payments are accepted by credit card (VISA/Mastercard), payments could then be made with CPAY using a single card.
Such a system and integration with a bank or a similar partner could be programmed and implemented quickly. However, the current status is that we still cannot offer enough volume and liquidity — at least that was the current feedback.
One bank offered us that we could aim for a partnership starting from a monthly volume of 100,000 and that they generally like the idea and would cooperate.
Currently, we have a volume of ~15,000 - 30,000, so we are not that far off, especially considering that we are still small and new.
It would also be possible to implement all of this without a bank or financial service provider, but this would require a financial license. We do not currently have such a license, but we are also currently exploring whether this would be affordable and feasible — probably not.
If anyone knows a potential partner, please feel free to contact me. Otherwise, let’s work on increasing volume and liquidity (Advertising, new users, etc.).
Note: Please note that this is a conceptual idea and there is no firm implementation or partnership in place yet. All plans and statements are subject to change.
We’ve integrated a new defense system designed to detect and mitigate attacks against our encryption infrastructure. This includes traditional hacking attempts like malicious payloads and DDoS attacks, as well as targeted cryptographic attacks such as brute-force and tampering. The system already includes initial detection patterns and provides an interface for a dedicated AI, which we are actively developing. The final version will feature autonomous defense capabilities powered by artificial intelligence.
Why is this important?
In today’s world, where surveillance is becoming increasingly widespread, privacy is more important than ever. We believe that every individual has the fundamental right to private communication—and that no government or authority should be allowed to monitor personal conversations. That’s why our encryption and messaging system is designed to protect against exactly that.
Unlike conventional messaging platforms that rely on centralized servers, Cryptix will operate entirely on a decentralized blockchain architecture. This means there is no single point of failure—no central authority to shut it down, intercept it, or manipulate it.
But what about the encryption itself?
The core of this system is our custom-developed encryption protocol. Unlike typical solutions that rely solely on standard algorithms like AES, we’re building our own system from the ground up—one that integrates hashing, cryptographic design, and unique key derivation mechanisms. A custom-built encryption system, if implemented correctly, is much harder to break—especially when reinforced by active defense systems and AI-powered monitoring.
This approach could make attacks extremely difficult—even for highly resourced adversaries.
Of course, we don’t want to overpromise. This is an ambitious project, and we’re committed to a realistic and rigorous approach.
We have successfully applied our idea of midstate technology in our upcoming encryption scheme. This enables a novel key generation method that not only provides tremendous entropy but also ensures robust resistance against future quantum attacks.
By combining a secret midstate with dynamically generated nonces and message IDs, we expand the effective search space to a scale that makes brute-force attacks—both classical and quantum-based—practically impossible.
With this technology, we set an important milestone towards future-proof, high-performance encryption systems—without having to forgo established, proven cryptographic algorithms.
The key length and entropy are comparable to modern symmetric algorithms considered secure today. Against classical brute-force attacks, the search space requires 2^256 attempts—practically impossible with current computing power.
Even in a quantum attack scenario using Grover’s algorithm, which provides a quadratic speedup, the effort is reduced to approximately 2^128 operations, still regarded as practically unbreakable and thus forming a future-secure foundation for our encryption.
Our Cryptix solution is better equipped for the post-quantum era than many existing military systems, at least from the perspective of symmetric key strength.
https://github.com/cryptix-network/cryptix-encryption-v1/blob/main/src/main.rs
Please note that this is still a template code, not a finished product. We're just starting to correctly fill the placeholders and create a practical encryption. This version is theoretically usable, but not yet secure enough.
A little reading material? Let's talk about government blockades of technology in the community.
https://cryptix-network.org/eu-technology-regulation
It can sometimes happen, for example, when Exbitron's API receives many requests at once, that not all orders are deleted. Therefore, there is an update for the bot that checks again after deletion to see if all orders have been deleted and deletes them again if necessary.
https://github.com/cryptix-network/exbitron-liquity-bot/releases/tag/v0.2.5
This update includes only the new version of the Liquity Bot. There are no other changes. So if you’re not using the Liquity Bot, you don’t need to update.
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.2.1
Additionally, the Liquity Bot can also be updated manually:
You can download the ready-made EXE from GitHub and simply replace the old EXE — then it will work as well. The file to be replaced is located in the main folder of the All-in-One software, inside the “\include” subfolder. Just replace the old file with the new one.
Please note that the old API KEY is no longer valid. A new one must be created in your Exbitron account.
We have updated the Liquity Bot for the new Exbitron API. The bot is now faster and more stable, and fully compatible with the new API.
As soon as Exbitron is back online, the bot will work immediately. It has already been tested.
I recommend using the Python file from the “executable” folder, or alternatively the compiled EXE file.
https://github.com/cryptix-network/exbitron-liquity-bot/releases/tag/v0.2.0
Please note that the old API KEY is no longer valid. A new one must be created in your Exbitron account.
We've now released a smartphone wallet app.
We've precompiled it for Android. For iOS, users must compile the app themselves (we don't support OS or iOS).
Download:
https://github.com/cryptix-network/cryptix-mobile/releases/tag/v1.3.3
Viruscheck: https://www.virustotal.com/gui/file/7dfecbe716fd89eaa239311d9b0845ad73571fa2954d2465b37fa9e03d8ec2d7?nocache=1
We still need to create API interfaces so that the current value in USD and transactions are displayed correctly. We'll do this soon. Otherwise, the app is fully functional.
5 Days left to the next Block Reward Reduction:
Current Block Reward: 7.937 CPAY
Next Halving: June 19, 2025 – 23:20 UTC
New Block Reward After Halving: 7.4915 CPAY (Minus 5.6 %)
Now’s the time to mine while rewards are still high!
The core issue lies in the use of a BLAKE3 chaining step at the end of our hashing process. With CUDA/NVIDIA, this is manageable, as external C files can be integrated and called directly.
However, with AMD GPUs and OpenCL, the situation is different. In OpenCL, BLAKE3 must be fully implemented inside the kernel code, as external libraries cannot be linked. Unfortunately, there is no stable or performant OpenCL implementation of BLAKE3 available today. Only a few experimental versions exist — all of which are unstable or exhibit extremely poor performance.
To our knowledge, no major cryptocurrency project or official BLAKE3 source has released a viable OpenCL version. That means we'd have to develop it entirely from scratch. And if this were an easy task, someone would have already done it.
We’ve tested a workaround by offloading the final BLAKE3 step to the CPU, but this approach bottlenecks the entire mining pipeline, reducing performance to CPU speed levels. In that case, using a GPU makes no sense — you may as well mine directly on the CPU.
So far, we haven’t found any working and efficient OpenCL implementation of BLAKE3. (If you know of one, please share it — we’d love to evaluate it.)
Why BLAKE3 is CPU-optimized:
It was specifically designed to be highly parallel on CPUs, using SIMD instructions like AVX2 and AVX-512.
It uses a tree-based architecture that processes many small data chunks independently — ideal for multi-core CPUs.
While this architecture can theoretically be mapped to GPU compute models, doing so in a performant and stable way is extremely complex.
Yes, in theory it’s possible to build a working OpenCL version of BLAKE3 — but it would require significant effort, deep understanding of GPU kernel design, and possibly months of development and testing.
We plan to attempt this, but realistically, it’s a large and uncertain project. Many developers have tried and failed — so we must assume that even a partial success would be an achievement.
And no, AMD Vulkan is not an option or alternative (it has already been reviewed): Vulkan was developed for graphics and compute, but:
The compute functionality in Vulkan is not designed for classic high-throughput hashing algorithms like SHA/BLAKE3.
It is more complex to use than OpenCL/CUDA for pure computational operations.
You have to build the entire pipeline and memory management yourself – which increases the effort considerably.
Additionally, it would not support Intel or onboard GPUs, which is another advantage of OpenCL
We have now enabled the overclocking features for Linux and HiveOS, Hive Sheet. After there were no problems with Windows.
To do this, simply use the new version with "oc" at the end of the name. These versions allow startup arguments for:
--cuda-lock-core-clocks
Lock core clocks (e.g., ,1200,) [default: 0]
--cuda-lock-mem-clocks
Lock memory clocks (e.g., ,810,) [default: 0]
--cuda-power-limits
Lock power limits (e.g., ,150,) [default: 0]
Since this works on Linux with CUDA 12.4, the Linux version now also uses CUDA 12.4 like the HiveOS Version.
It worked well in our tests, but there was one GPU where it ignored the settings. We need to investigate further to determine why this was the case. If you'd like to test it, you can download the versions.
Please note: Overclocking is always at your own risk; you should know what you're configuring. Also note that the settings apply to all GPUs, so keep this in mind if you have different GPUs in 1 Rig.
If you want to compile yourself, you have to activate the build feature.
cargo build --release --features "overclock"
https://github.com/cryptix-network/cryptix-miner/releases/tag/v0.2.9
The Exbitron crypto exchange is currently offline due to a bug. Therefore, you will have to wait for swaps or purchases of CPAY.
We have now activated name fields in the Explorer for addresses. The reason behind this is that a user showed me a pool address because they found the number of mined blocks suspicious. It turned out to be just a pool address.
This function is manual for now, meaning I will manually add names to wallet addresses of pools. If users want me to add a name for a specific address, just let us know.
The AI is connected to the system and will automatically add a “suspicious wallet” tag to wallet addresses if any wallet appears suspicious.
The naming function for all users will be available later, so that this can also be set automatically.
Updates:
+ Main
- Window Mode Resize to 1280 x 720 / 16:9 / 720P
- Some Full Screenmode Optimizations
+ Wallet Tab
- CPAY logo addet
- Auto Compound Function addet
+ Node Tab
- Liquidity bot replaced with a current version that no longer uses CYTX but CPAY
+ Miner Tab
- Miner Status added
- RAM usage indicator added
- Hard disk usage indicator added
- Formatting of the side-page display changed
- Added Info button in Config tab to display all startup arguments
- New overclocking options: Memory Clock, Core Clock, Power Limit
- Pre-saved Pools in Miner-Config:
+ Removed:
- iturkmining
- GogPool
- 2realminer
+ Added:
- CaveMiner
- Pools4Mining
- GetToMine
+ GPU Miner
- Replaced version with overclock version
- Enables power limit, individual memory, and core clock (BETA Test phase, needs to be extensively tested first. After testing, we will also release the features for Linux and Hive OS Versions.)
Bugfixes:
+ Node Tab
- FIX: Synchronization status was stuck when stopping the node.
- FIX: Synchronization status not updated after restarting the node.
+ Mining Tab
- FIX: When restarting the miner, the mining animation was no longer displayed
+ FIX: Some minor Bugs
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.2.0
The wallet now includes an Auto Compound feature.
Options:
Checkbox: Starts or stops automatic compounding
Number of Compounds: Defines how many times compounding should occur
Interval: Sets the delay between each compound (in seconds).
Tip: 3 seconds is usually fine. If you encounter errors (e.g., due to a slow internet connection), try increasing the interval.
Important Note:
Compounding actions are actual blockchain transactions, which means transaction fees apply. While these fees are typically small, they still exist.
To prevent users from unintentionally using up their entire balance (e.g., by letting the feature run for days or weeks), Auto Compound must always be started manually and is limited by the number of compounds you set.
This manual activation and limitation act as a safety mechanism to protect your funds.
This feature is already available in the web wallets. It will be available in the self-hosted wallet in the All in One software with the next update.

Use the Cryptix Miner in MMPOS.
Read more:
Cryptix Miner
Use the Cryptix Miner in HiveOS via the shell or the flight sheets.
Read more:
Cryptix Miner
The hard fork is complete, and everything should be working as usual — for both the old chain and the new chain.
Remember, the wallet and explorer system, and swapping, are only available for three months. After that, we'll completely abandon the old chain.
And also, mining on the old chain doesn't make sense because Exbitron is connected to an isolated node from the hard fork. This means that anyone who continues mining on the old chain can't exchange their coins.
CYTX / CPAY Swaps are possible now on:
https://app.exbitron.com/exchange/?market=CYTX-CPAY
CPAY / USDT here:
https://app.exbitron.com/exchange/?market=CPAY-USDT
If you see this message in the Web Wallet:
"Transaction size/mass limit reached. Please reduce this transaction amount. (Mass: 11334815)"
It means your transactions need to be compounded. This happens when you try to send coins that are spread across too many individual inputs (UTXOs). Here's how to fix it:
Open the "Wallet" tab in the wallet.
Click on "Compound Transactions".
Repeat this process (important: not just once — repeat it multiple times) until all your coins are combined into a single transaction.
Once completed, you can send the full amount in one single transaction.
In the Config section of the Node tab, there is now a new option that allows you to freely select between the Rust or Go node. The All-in-One software now includes both nodes, so there is no longer a need for a special version for either the Go or Rust node. All modules have been adapted to work with both the Go and the Rust nodes. Simply switching and saving the setting is enough, and everything will function as usual.
I recommend using the Rust node by default—unless there is a technical reason not to—since it is the preset option. Only switch to Go if the Rust node does not work. This situation is very rare.
Download:
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.1.0
Hardfork Swap Information
We have now planned the swap with Exbitron, and it will proceed as follows:
At the time of the hardfork:
The CYTX/USDT market will be closed, and instead a CPAY/USDT market will be opened immediately.,
Additionally, a CYTX/CPAY market will be launched. There, the old CYTX coin can be exchanged for CPAY — just like the current CYTX/USDT market. You will need to go into this market and perform the swap yourself.
The exchange rate is 1:1, meaning 1 CYTX = 1 CPAY.
Exbitron will connect its market to my isolated node, which will prevent double mining.
Important Notes:
The CPAY coins available for swap will be replenished and recalculated daily.
That means if you want to swap immediately, you should send your CYTX coins to Exbitron before the hardfork.
Otherwise, you may have to wait a day for the CPAY supply to be topped up.
The swap is not virtual, but a real blockchain-based swap backed by actual coins.
This adds a layer of security, as every swapped coin must be fully backed and verifiable on-chain.
Post-Hardfork Conditions:
After the hardfork, we will isolate our node.
Any coins mined after the fork will not be swappable, as they won’t be part of the isolated blockchain used for the swap.
The only way to send coins for swapping after the hardfork will be via our provided wallet at:
👉 https://old-wallet.cryptix-network.org/
CLI Keyphrases / Wallet-Daemon / Login Seeds are not working in the Web-Wallet (Only data created with a web wallet can be used for login)
CLI wallets or wallet daemons will not be able to connect to our isolated blockchain.
Recommendation:
We strongly recommend sending your CYTX coins to Exbitron now, so they can be swapped immediately at the time of the hardfork and are fully backed by CPAY.
This way, you avoid any waiting time.
The blockchain is secured with a backup; in the worst case scenario, we can always load the backup if something goes wrong during the swap.
Time: The Hardfork will be:
27.05. 18:00 CEST
This is:
BST (London) – 17:00
EEST (Athens, Kyiv) – 19:00
MSK (Moscow) – 19:00
IST (India) – 21:30
CST (Beijing) – 00:00 (28 May)
JST (Tokyo) – 01:00 (28 May)
AEST (Sydney) – 02:00 (28 May)
EDT (New York) – 12:00
CDT (Chicago) – 11:00
PDT (Los Angeles) – 09:00
During a hard fork, the node’s old database must be deleted or reset.
Therefore, we have added a button in the All-in-One software.
How it works:
- Confirm the Config button in the Node tab
-Confirm the Reset Database button
- A console window will open where you confirm the reset by typing “y” or “yes” , press enter
- Close the console window
- Start the node as usual with the Start button
If you are not using the All-in-One software, you can start the node with the following startup arguments to achieve the same effect:
Rust Node:
--reset-db
Go Node:
/reset-db
It is also possible to manually delete the database:
Windows:
Open the directory:
C:\Users\USERNAME\AppData\Local
Then delete the following folders:
- Go Node: delete the folder Cryptixd
- Rust Node: delete the folder rusty-cryptix
Linux:
The same folders are located directly in the root folder with a dot prefix, so:
.rusty-cryptix or .Cryptixd
Delete these folders.
Here is the Update for the All-in-One Software with a Reset Button:
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.0.1
Cryptix All-in-One V2 Update:
This update includes the provision of modules for the upcoming V2 Network Update.
All Versions:
Go Node replaced (Go version)
Rust Node replaced (Rust version)
Miner updated to the new Cryptix OX8 hash
Wallet Tab:
Automatic logout time changed:
For web wallet connection from 10 minutes to 1 hour
For local node wallet connection from 10 minutes to 10 hours
Change from CYTX to CPAY
Miner Tab:
Miner Output Console width reduced
New area to the right of the console for displaying data such as CPU usage, block discoveries, etc.
Displays wallet address balance
Displays current CPU usage
Dev Version:
CLI Wallet replaced
Wallet Daemon replaced
Stratum Bridge replaced
Starting with the hard fork to network v2, this version must be used. The old software will no longer work. This version will also only work starting with the hard fork, not before.
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v2.0.1
Since We've been asked about the startup arguments for the Cryptix miner:
Local Node Mining:
cryptix-miner -a cryptix:YOUR-WALLET -s 127.0.0.1 --port 19201 --threads 1
Example:
cryptix-miner -a cryptix:qrjefk2r8wp607rmyvxmgjansqcwugjazpu2kk2r7057gltxetdvk8gl9fs0w -s 127.0.0.1 --port 19201 --threads 1
Pool Mining:
cryptix-miner -a cryptix:YOUR-WALLET -s stratum+tcp://POOL.COM:PORT --threads 1
Example:
cryptix-miner -a cryptix:qrjefk2r8wp607rmyvxmgjansqcwugjazpu2kk2r7057gltxetdvk8gl9fs0w -s stratum+tcp://stratum.cryptix-network.org:13095 --threads 1
CPU Config:
Please note: the number after threads is the selected thread for the CPU (more Threads = Higher Hashrate):
-- threads 4
is 4 threads. The number can be adjusted depending on the CPU, for example:
---threads 12
Disable CPU or GPU:
Disable CPU:
simply remove
--threads 1
, so:
cryptix-miner -a cryptix:qrjefk2r8wp607rmyvxmgjansqcwugjazpu2kk2r7057gltxetdvk8gl9fs0w -s 127.0.0.1 --port 19201
Disable GPU:
simply add
--cuda-disable
, so:
cryptix-miner -a cryptix:qrjefk2r8wp607rmyvxmgjansqcwugjazpu2kk2r7057gltxetdvk8gl9fs0w -s 127.0.0.1 --port 19201 --threads 1 --cuda-disable
We recommend that anyone unfamiliar with mining startup arguments or BAT files use the All in One software.
Miningcore Update for the Hardfork
To prepare Miningcore for the upcoming hardfork, only a few steps are required:
Replace a single file:
Replace this file in your Miningcore installation:
🔗 https://github.com/cryptix-network/cryptix-pool-miningcore/blob/main/src/Miningcore/Blockchain/Kaspa/Custom/Cryptix/CryptixJob.cs
Update the ticker:
Change the ticker from CYTX to CPAY in the appropriate ticker configuration files.
Replace the node:
You must switch to the new node during the hardfork, as the old node will no longer be valid or functional.
✅ For convenience, here is the complete and updated Miningcore release with all necessary changes included:
🔗 https://github.com/cryptix-network/cryptix-pool-miningcore/releases/tag/v0.3.0
Due to issues with GPU detection for CUDA on HiveOS, we created a custom HiveOS version of the miner.
The issue was that HiveOS supports CUDA version 11.5 at most, whereas we use the latest version — CUDA 12.6.
The HiveOS version uses CUDA 11.5 and can be installed as follows:
Option 1: Compile manually using the HiveOS-specific GitHub branch:
You must use the special hive-os branch on GitHub:
https://github.com/cryptix-network/cryptix-miner/tree/hive-os
Run the following command to install:
git clone -b hive-os https://github.com/cryptix-network/cryptix-miner.git
cd cryptix-miner
cargo build --release
Option 2: Download precompiled HiveOS binary:
You can download the compiled version directly here:
https://github.com/cryptix-network/cryptix-miner/releases
This version hasn't been fully tested yet, but it should work.
Alternative Method (requires upgrading HiveOS to support CUDA 12.6):
If you want to use the regular miner version with CUDA 12.6, you need to manually upgrade CUDA on HiveOS.
Run the following commands in the terminal:
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-6
Then install the required drivers:
sudo apt-get install -y nvidia-open
sudo apt-get install -y cuda-drivers
Please note that the software only supports NVIDIA GPUs and all CPUs. We don't have enough time to write the OPENCL drivers for AMD and Intel GPUs. However, we plan to implement this soon after the hard fork.
tarting from the moment of the hardfork, new files will be required.
The old mining software, Stratum Bridge, Node, and All-in-One software will no longer work.
Since we will launch a new chain with a new Genesis, the old blockchain will become invalid.
Also, the old hash function in the legacy mining software and SRB Miner will no longer produce a valid hash.
Therefore, here are the update files:
Rust Node (with CLI Wallet):
https://github.com/cryptix-network/rusty-cryptix/releases
Go Node:
https://github.com/cryptix-network/cryptixd/releases
Wallet Daemon (also included in the Go Node):
https://github.com/cryptix-network/cryptix-wallet-daemon/releases
CPU-only Miner:
https://github.com/cryptix-network/cryptix-miner-cpu/releases
CPU & GPU Miner (also supports CPU-only or GPU-only mining, pool support, and direct node mining):
https://github.com/cryptix-network/cryptix-miner/releases
Stratum Bridge (currently not required, as there is no external mining software. Most likely only needed for development purposes):
https://github.com/cryptix-network/cryptix-stratum-bridge-v3/releases
The update for the All-in-One software should be ready within the next 2 days.
These should be the final files, unless we decide to change the Genesis again or a major issue occurs in the last testing phase.
The final blockchain has already been launched and is therefore also serving as the final test.
Please note: The new files cannot be used now.
They will only be usable at the moment of the hardfork, and will be required immediately from that point on.
The downloads have already been replaced with the new files on the website and are available for download there.
During the hardfork, the old domains will be used for the new blockchain.
For the swap or to access the old blockchain, the following services must be used:
Old Wallet System (CYTX):
https://old-wallet.cryptix-network.org/
Old Explorer (CYTX):
https://old-explorer.cryptix-network.org/
These systems are already accessible and will remain online for 3 months after the hardfork to support the swap.
This means that for swapping and for viewing transactions on the old chain (CYTX) after the hardfork, you will need to use this wallet and this explorer.
The new blockchain (CPAY) will continue to operate on the old URLs/websites after the hard fork. There are no changes to this.
We have already renamed the labels to CPAY in the current Explorer and Wallet. However, please note that this change is purely cosmetic/visual. It is still the CYTX system until the hard fork.
There have also been a few other changes — for example, the automatic wallet logout timeout has been increased from 10 to 60 minutes.
Quantum attacks on mining? Quantum nonce spam?
We’re all doomed!
Nope, not quite — just kidding.
Don’t fall for the hype and quantum panic fueled by buzzwords and mysterious “patents.” The quantum threat is mostly marketing smoke right now, nothing more. There’s no real quantum danger today, and if it ever does show up, protecting yourself is quick and easy.
Shielding a cryptocurrency’s mining process—or specifically its nonces—from quantum computers is simpler than you think. We’re talking less than 10 lines of code, and the fix is straightforward.
Enhancing PoW Security with Midstate Hashing: A Lightweight Defense Against Nonce-Spam and Quantum Attacks
We’ve actually released a solution anyone can use. Totally free and open — no patents here.
When we later update the network to V3, we will integrate this feature to be quantum resistant in the mining process. But this is not worth talking about anyway, there is currently no threat and there will not be one in the next few years.
Since we keep receiving the same questions via private message regarding the hardfork, We’d like to clarify everything once more:
When is the hardfork?
The hardfork is currently scheduled for May 27, 2025 at around 6 PM GMT. We're still finalizing the last tests, so we can't confirm this 100% yet – but this date is very likely to be final.
How can I swap old CYTX to CPAY?
The swap will be available starting May 27 (assuming the hardfork happens that day) via Exbitron. You’ll be able to swap 1:1 for three months.
How can I send CYTX if the old blockchain is deactivated?
It won’t be deactivated. The old blockchain will continue to run for 3 months on a dedicated server.
There will be a web wallet and a blockchain explorer available.
However, this node will be isolated from the public network.
Can I mine on both chains?,
No. To prevent dual-mining, the legacy node will be isolated and not publicly accessible.
Exbitron will connect to this isolated node to get the valid chain state for the swap.
Important:
Once we isolate the node and hardfork, any blocks mined after the fork will not be part of the swap.
Only coins mined up to the hardfork will be swappable.
We’ll use a private mining instance to keep the old chain alive solely for the swap process.
Do I need to send my CYTX to Exbitron now?
Ideally, yes. This ensures your coins are ready for an instant swap once the fork happens.
However, as mentioned, there will still be a functioning web wallet after the fork.
You can also send your CYTX later during the 3-month swap window.
Is the swap automatic?
No, it must be done manually. Some users may choose not to swap.
There will be a Swap button inside your Exbitron account or possibly a CYTX/CPAY market – the final implementation is still being discussed with Exbitron.
Where do the CPAY coins come from?,
They will be a short "pre-deflation phase" to match the current CYTX supply as closely as possible.
Keep in mind:
We can only start at a monthly reward reduction point due to technical limitations.
That means we can’t mine e.g. 5 days at 8.4 rewards and then immediately at 7.9.
Instead, we’ll jump into a reward bracket that lasts 30 days.
Our pre-deflation will be calculated as 1 day, with 5 days mined at the 7.9 reward level,
allowing us to test two pruning points directly on the final chain.
What happens if something goes wrong?
We’ll keep backups of both the old and new blockchains.
If any issue arises – during the swap or otherwise – we can always restore from backup.
So don’t worry about your coins. Worst case: we reload the data.
What exactly will change?
We’ll introduce a new Cryptix OX8 hashing algorithm – meaning the old mining software will no longer work. This makes mining fairer and helps protect us from hardware-based attacks.
We’ll start a fresh blockchain and rename the coin from CYTX to CPAY – a better, more appealing name.
We can finally leave behind the scam exchange MecaCex.,
Originally, we planned not to swap their stolen user funds, but MecaCex has already sold all the coins.
A new Genesis Block will be created. The old chain won’t be able to connect to it.
We will activate payloads, enabling possible token systems, encrypted messaging, and other ideas – including a possible AI-based concept. These are just ideas for now, not promises.
Decentralized P2P trading functions will be activated – potentially important for token features.
And other improvements.
No, we will not change the block time. 1 second is exactly right for our project.
Will the new node be available in time? Mining software? Will pools work?
The new downloads for mining software, Rust Node, Go Node, Wallet CLI, Daemon, etc., will be available before the hard fork. The pool will also be converted immediately upon hard fork and will be available immediately.
Mining: We will provide our CPU and GPU mining software for all CPUs and all Nvidia GPUs (CUDA). We will add AMD (OPENCL) later.
The last testnet test was successfully completed. The pruning point was successful.
We will now launch a mainnet and test all modules with the new nodes, explorer upgrades, wallet upgrades etc. , as there are many new features.
This will take about 4-5 days, after which we can start the timer for the hard fork. This will be a week, which should be enough time for pools, etc., to prepare.
Current progress to the hard fork:
✅ Hash: Cryptix OX8
✅ Rust Node
✅ CPU Miner
✅ GPU Miner (CUDA / NVIDIA)
✅ Mining Core
✅ Go Node
✅ Go Stratum Bridge
✅ Go Node Testnet (3 Days)
🔄 Final Test all Moduls ( 4 Days)
The white paper and roadmap have been expanded and updated to reflect the current status (although they're still not where they should be). We've also already updated the website to use CPAY instead of CYTX. Even though the hard fork hasn't been completed yet, we're already implementing the changes so that everything will be ready for network version 2.
We have finished the Go Node and Stratum Bridge — these were the last missing modules.
This means that all components required for the hard fork are now complete.
We will now specifically test the Go Node on the testnet for stability over 3 days. After that, we will add a few new features, launch a mainnet, and conduct final testing of all modules, including sync tests. This will take approximately 4 more days, as we will wait until the first pruning point is reached.
If everything runs smoothly during that phase as well, we’ll be ready to proceed with the hard fork. We will also need to rename "CPAY" to "CPAY" in all modules like the Explorer, Wallet, etc. This renaming will begin now, so don’t be surprised if you already see "CPAY" in some places before the hard fork.
Once our final testing is done (in 7 days), how much lead time will you need? We’re thinking about a 1-week notice. We need to calculate the exact supply at the launch of the final mainnet for the hard fork, so it's important for us to know this in advance. We believe 7 days should be enough for everyone. The minimum possible lead time would be 4 days and the maximum 14 days.
Current progress to the hard fork:
Hash: Cryptix OX8 ✅
Rust Node ✅
CPU Miner ✅
GPU Miner (CUDA / NVIDIA) ✅
Mining Core ✅
Go Node with Stratum Bridge ✅
Go Stratum Bridge ✅
Go Node Testnet (3 Days) 🔄
Final Test all Moduls ( 4 Days) 🚧

We have added a new Discord bot for a Daily Reward / Faucet function:
What can it do?
/cryptix-claim – Claims the daily CPAY reward (every 24 hours)
/cryptix-balance – Shows your current CPAY balance
/cryptix-reset [user_id] – Resets a user's CPAY balance (admins only)
/cryptix-list – Lists all users and their CPAY balances (admins only)
This bot is now in a testing phase and is intended to replace the faucet, as managing the faucet manually has become tedious and it’s more convenient over Discord.
Currently, we process withdrawals manually (from 300 CPAY). In the future, we plan to connect it to the faucet for automatic withdrawals.
Users can collect CPAY every 24 hours, with rewards ranging from 1 to 20 CPAY for free.
Join our Discord and meet the Cryptix Community:
https://discord.cryptix-network.org/
We’ve launched a new website for CryptixPay:

https://cryptixpay.org/
Why?
The main Cryptix Network website can be quite overwhelming for new users. There's a lot of technical information—mining software, hash details, various downloads. But an average user of the coin system doesn’t need any of that and is easily overloaded with irrelevant content.
That’s why we decided to create a separate website specifically for the payment modules and CryptixPay.
Please note: this is a first version. Simple and compact. The site still needs content and room to grow. For now, it's a landing page—but it already serves its purpose perfectly.
And yes, we deliberately chose a light, friendly, and welcoming design instead of a dark theme. It’s more suitable for CryptixPay. Still, the branding remains clearly recognizable.
A new web wallet system is planned for CryptixPay, which will be connected and integrated there, in addition to the current wallet system.
We plan to do the same for other modules like Cryptix AI, Cryptix Encryption, and so on.
The goal is to separate the modules a bit while still keeping them connected—so that each type of user sees exactly the module that’s relevant to them.
However, the other modules aren't far enough along yet to justify separate websites. That will come later.
Our Discord now has a real-time channel display of the hashrate and USDT value. Furthermore, the values can be accessed anywhere using the commands:
/cryptix-hashrate
/cryptix-price
The values can also be accessed anywhere.

The next block reward reduction is tomorrow (01-May 2025), decreasing from 8.91 CPAY to 8.41 CPAY — a 5.61% drop.
Changes:
-The Liquidity Tab has been removed and integrated into the Dashboard Tab instead.
Why? The additional log was unnecessary as it was already visible above the Dashboard Tab, which was causing unnecessary performance overhead. It also provides a cleaner interface and better user experience when there are fewer tabs.
-The Liquidity Bot can now also be launched in windowed mode as a separate window. This feature is available in all versions.
-In the Miner Tab, the correct port for Baikal Mining has been entered.
-In the Miner Tab, you can now disable the GPU with a click. Similarly, the CPU can be disabled, and the threads can be selected via a simple click.
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v1.1.8

Changes:
- The Dashboard is now the default start tab.
- The MecaCex price has been changed to the Exbitron price.
- The Liquidity Bot is now directly integrated as a tab and connected with the Dashboard (only in the DEV version). The config file can be edited directly via the AiO software.
- The AI tab has been removed from the regular version but remains in the developer version.
- Performance optimization: The RAM usage has been reduced from 60 MB to 27 MB. The required CPU usage (on the development machine) has been reduced from 0.8% to 0.2%, while the software is idle.
- The bug that required Node.js to be installed for the local Node has been fixed. Now it is portable, and Node.js no longer needs to be installed separately for the local Node.
- More log files have been added (relevant for developers).
- Addet more Pools to the Miner Config
- Greater thread safety has been implemented, along with more reliable process termination in case the software crashes.
- A few minor bugs have been fixed.
- A new options tab has been added, featuring a language selection option.
BUT: The languages are not active. Why?
We initially wanted to implement this with an AI function, and it worked. However, it used too much processing power for the user. As a result, we decided against it and will do the translations manually. So, the feature will be active in the future. The basic functionality is already in place, so most of the work is done. We just need to create the translation files.
https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v1.1.7

How does it work?
It's simple: Click the button and you'll see if you've won or lost.
If a winning number appears, just send it to us on Discord or via email, and you'll receive the corresponding prize:
Bronze - Chance: 1 in 1,000 | Reward: 1000 CPAY
Silver - Chance: 1 in 5,000 | Reward: 5000 CPAY
Gold - Chance: 1 in 10,000 | Reward: 10,000 CPAY
Platinum - Chance: 1 in 100,000 | Reward: 50,000 CPAY
No purchase is necessary to participate. You don't have to enter any data or anything. Its complete for free. Simply open the dashboard and click the button.
You get one chance per hour!
Please note: If you win, you must screenshot or copy the winning number. If you reload the website or use the button again, your winning number will be lost.
Try your Luck now

Everything at a glance with our new Cryptix dashboard.
Features:
- A chart/statistic for the hashrate and difficulty of the last 24 hours.
- A wallet address can be connected, which then displays the wallet balance and the last five transactions (for example, the last five blocks with the date when mining). You don't need to log into the wallet; just enter and save an address.
- A market area of Exbitron
- A section with various important data such as mCap, Block Reward, Circulating and more.
- All dashboard data is automatically refreshed at various intervals. The page never needs to be reloaded, except for feature updates.
Open the Dashboard

🚨 NEW EVENT:
1st place = 10.000 CPAY
2nd place = 5000 CPAY
3rd place = 2500 CPAY
Whether you draw, paint, design digitally, or use AI – everything is allowed! Create your piece in any size or style – as long as it’s Cryptix-related!
📅 Submission Deadline: April 17th, 2025 at 16:00 GMT
⏳ That’s about 3 days from now – so don’t wait too long!
Take a photo and submit it to the new "Art Contest" channel in Discord.
As always, team members are excluded. Trail team members may participate.
This time the community will vote on who the winners are.
We have now switched our API to Exbitron. It now displays the average (best ask and best bid) as the current coin value on our website.
The All in One software's value display is also connected to it and will now display the correct values. The rewards calculator will also do so.
The market in Exbitron is looking very good now. Lower spreads, plenty of buy and sell offers. We've successfully separated ourselves from the other market and restabilized. That was a critical phase with MecaCex, but we're past it.
Thanks to everyone who provided liquidity and offers, with or without the bot. We've truly built a great community in such a short time.
Update for an Executable File
Edit the config file using a text editor and add the Exbitron API. Then set the values for quantity, spread, and orders.
That's it, run the executable with a click
Download:
https://github.com/cryptix-network/exbitron-liquity-bot/releases
Kaspersky Viruscheck for the exe:
https://opentip.kaspersky.com/7FFEA4B44F8380F8969F3C6E1059D4A3C287CB63A71FC8CBCA46F2311BE54518/results
With this update, no installation or Python is required. Simply open a portable EXE with 1 click.
The Cryptix Liquidity Bot automatically places buy and sell orders on Exbitron to maintain market liquidity and to reduce the exchange spread for a fair market.
Here’s how it works:
Key Config Values: (can be customized to your needs, with more or less spread. More or less USDT/CPAY, etc. )
START_USDT_AMOUNT: Initial USDT balance (e.g., 100 USDT)
START_COIN_AMOUNT: Initial coin balance (e.g., 20,000 coins)
MAX_USDT_AMOUNT: Max USDT the bot can hold (e.g., 125 USDT)
MAX_COIN_AMOUNT: Max coins the bot can hold (e.g., 50,000 coins)
SPREAD_PERCENTAGE: Price spread between buy and sell orders (e.g., 5%)
NUM_OFFERS: Number of buy/sell orders (e.g., 20 orders)
OFFER_DIFFERENCE: Price difference between successive offers (e.g., 0.01)
Workflow:
Fetches the latest market price (mid price between the best bid and ask).
Creates buy and sell offers with a spread based on the market price.
Places buy orders at lower prices and sell orders at higher prices.
Ensures balance stays within the max limits for both USDT and coins.
Cancels old orders before placing new ones.
Repeats the cycle every 15 minutes, updating balances and adjusting orders.
What the liquidity/trading bot DOES NOT do:
It does not buy or sell coins itself -> wash trading / fake volume
It does not create fake offers / jump-away orders
It uses real buy/sell offers (or both, depending on the settings), which are updated every 15 minutes (or depending on the settings). It is designed to provide a stable market and reduce spreads. Useful for market makers and spread traders or for an effective purchase/sale of coins.
Free to use and no Dev Fees:
https://github.com/cryptix-network/exbitron-liquity-bot
Must be run with Python; installation instructions are available on Github. We will provide an executable version without Python soon.
All you need is an Exbitron API, which you can create for free in your account. And Account Balances.
The bot isn't yet field-tested. Therefore, it should be tested and observed with small values first, especially due to the maximum order values. This hasn't been tested yet. It's also important to note that the bot deletes and resets all orders every 15 minutes, according to the settings. This includes manual orders.
I therefore recommend creating a new account with a fixed USDT amount to Test. This way, even manual exchange won't cause any conflicts.
Before, Hash v1 (Cryptixhash):
1080 Ti GPU = 280 - 300 MH/s
5600X CPU 1 Thread = 0.9 MH/s
After , Hash v2 (Cryptix OX8):
1080 Ti GPU = 15 - 18 MH/s
5600X CPU 1 Thread = 0.35 MH/s
So:
Hash v1: GPU:CPU ratio ≈ 300:0.9 = ~333:1
Hash v2: GPU:CPU ratio ≈ 18:0.35 = ~51:1
The CPU is now (relatively speaking) about 6.5 times more powerful than before.
To put it simply: The CPU is now more useful for mining. However, the GPU is still the more efficient option. However, when energy-efficient and modern server CPUs come into play, the situation could become very balanced.
It's difficult to achieve a good balance with such a complex hash in such a short time. Something like this requires testing on a lot of hardware. A CPU is not just a CPU, and a good GPU is not just a GPU. There are so many different models.
With Cryptix OX8, we've improved the balance between the hardware types by 6.5 times. Now, at release, we'll look at the exact user data; your information will be helpful. After that, we can balance the v3 hash even better.
Ftw: The hash has more "headroom" thanks to its highly nonlinear behavior and timing methods. This means the hardware isn't constantly pushed to its limits. Better undervolting/overclocking is now also possible, reducing power consumption per vote. Miners can also "play around" with it to find the best settings.
We thoroughly tested our latest method in Cryptix OX8, and everything works flawlessly. This means that this feature will be included in the release:
What does this function do?
It is a hashing process within a hashing process. The hash is no longer just a regular hash, but there is a "backdoor" where another hashing process occurs at a deeper level. So, a hash within a hash. We stumbled upon this idea by chance.
Why is this beneficial?
The benefits are clear: fewer chances for specialized hardware, as the process has become even more complex and nonlinear. Additionally, this method introduces higher latency and more overhead. It also increases the dispersion (entropy), making reverse calculations (side-channel attacks) significantly more difficult, if not impossible.
Since we implemented this technique as a side channel—with an optimal wait time in the millisecond range—the hash rate has not slowed down. For both CPU and GPU, the hash rate remains unchanged, with no drop (0%).
We highly recommend that every cryptocurrency project takes measures to protect itself as much as possible from the use of specialized hardware solutions like ASICs and FPGAs.
Promoting Decentralization: Many claim that FPGAs and ASICs contribute to decentralization. However, this is a myth. In reality, these specialized hardware solutions promote market centralization, as only those with the capital to invest in expensive, specialized equipment can compete. This contradicts the original goal of many cryptocurrencies, which is to allow broad and fair participation.
Protecting Your Community and Miners: Protect your community and miners from "pay-to-play" systems, where only those who can afford specialized hardware are truly competitive. Fair mining should be open to anyone with a computer. Everyone should have the opportunity to participate in the network and have a chance to find a block, regardless of their financial situation.
Environmentally Friendly Mining: Although mining is often seen as harmful to the environment, it's crucial to keep its environmental impact as low as possible. Custom-built hardware designed specifically for mining tasks, running constantly at the maximum of its power consumption, contributes significantly to environmental damage. It's a misconception that specialized hardware is more efficient simply because it focuses on a single task. The opposite is often true, especially when the hardware is overpowered for the job.
Let's remind ourselves of Satoshi Nakamoto's core principle:
"One device = one vote"
It was NEVER Nakamoto's vision:
"More money for specialized hardware = more votes"
How to do it:
Exploiting FPGA Limitations
We offer our new Cryptix OX8 hash (highly resistant) free of charge to all crypto projects to protect their projects. We are also happy to help with the integration, completely free of charge and without obligation:
Cryptix OX8 Hash
The Miningcore update is complete, and the following changes have been implemented:
Added the new Cryptix 0X8 hashes for the upcoming hard fork.
Simple Anti-Nonce Spam functions, which detect different types of nonce spam through various methods.
For pool operators: The new version can be found here:
https://github.com/cryptix-network/cryptix-pool-miningcore/releases/tag/v0.3.0
Current progress to the hard fork:
Hash: Cryptix OX8 ✅
Rust Node ✅
CPU Miner ✅
GPU Miner (CUDA / NVIDIA) ✅
Mining Core ✅
Go Node with Stratum Bridge 🔄
We now need to implement the hash in the Go language and integrate it into the Go node, then export the Stratum Bridge. After that, we're ready for the hard fork.
I often hear the claim that specialized hardware like FPGAs and ASICs are more energy-efficient and thus better for the environment. Let’s take a closer look at this topic:
The assessment of energy efficiency based on hash rate is based on incorrect assumptions and faulty mathematics, as the network’s difficulty adjusts to the miners. Whether the network has 1 GH/s or 1 TH/s, a block is generated every second (depending on the blockchain). Your individual hash rate doesn’t matter; you simply get your mathematical share of the total hash rate, at least over the long term. The blockchain only cares about the result – i.e., who finds the valid block. How much energy you consume or what your hash rate is doesn’t matter to the blockchain.
The difficulty automatically adjusts to the total hash rate or the found blocks. It doesn’t matter whether you're mining with a toaster or a supercomputer – you get only the share you contribute compared to the rest of the miners.
Imagine all miners switch from GPUs (e.g., 1 J/GH) to ASICs/FPGAs (e.g., 0.1 J/GH):
Sounds great: 10x more efficient!
But what happens in reality?
Since it has become cheaper, people deploy 10x more ASICs. Mining becomes more economically attractive, so it scales massively.
Result: The energy consumption stays the same or even increases.
“More efficient mining = better for the environment” only holds true if:
- The total hash rate decreases
- Fewer devices are active in the network
- And the system doesn’t scale to the economic limit
But this never happens in practice, because:
- Mining is driven purely by economics
- Where there’s profit, more mining is done – regardless of how much energy it consumes
- Specialized hardware almost always runs at full power, without breaks or throttling
CPUs and GPUs:
- Are more flexible
- Have variable load (idle time possible)
- Can be used for other tasks as well
ASICs and FPGAs, on the other hand:
- Run constantly at full load
- Are built only for one task: Mining
- Cause more environmental impact through production and continuous operation
Long story short:
Mining with specialized hardware is more environmentally harmful than mining with CPUs or GPUs. The claim that FPGA or ASIC mining is "more energy-efficient" is a marketing argument – on closer inspection, the opposite is true.
Advertising mining as environmentally friendly and energy-efficient is highly questionable. Mining is not eco-friendly, on the contrary. It consumes an incredible amount of energy. However, if someone wants to mine while being mindful of nature, they should avoid environmentally harmful hardware and do it as sustainably as possible.
The new hash (Cryptixhash v2) will be named:
Cryptix OX8
or shortname: OX8
The name is based on the use of Octonion (O), with 8 dimensions (X8).
Cryptixhash v3 will later be named:
Cryptix SX16
Since we will be expanding to Sedenions (16 dimensions) there
The hash is 98% complete—we're just fine-tuning the distribution and considering integrating an additional function. Other than that, the hash is fully functional and has passed extensive testing. It could already be deployed on a mainnet at this moment, as there have been no deviations, overflows, or similar issues even after days of testing.
Current Balance Between CPU and GPU:
CPUs are now about 4.5 times more efficient than before. This means CPU mining is now a viable option in terms of hashrate and efficiency. However, GPUs remain the more efficient and preferred choice.
What's Next?
We'll now adapt Miningcore (C#) to support the new hash. After that, we’ll work on the Go Node. The Rust Node, CPU Miner, and GPU Miner (CUDA / C++) are already complete.
The final RAM usage of Cryptixhash v2 will be around 200 MB per graphics card, with a range of 200 to 300 MB depending on the model and the number of threads. The hash has been optimized to prevent excessive memory usage, allowing for efficient dual-coin mining. These adjustments also help achieve a better balance between CPU and GPU mining.
For CPU computations, depending on the number of threads, data can be loaded directly into the L1 to L3 cache, eliminating the need to access the main RAM. This leads to significantly improved memory usage and efficiency. For example, with a Ryzen 5600X, 8 out of the 12 threads can fit into the L3 cache, and beyond that, the RAM is used. Modern CPUs with 3D cache would benefit even further, achieving higher efficiency.
A key advantage of Cryptixhash v2 lies in its non-linear structure, which leads to irregular behavior and varying timing. This means that the hardware does not run constantly at maximum power consumption, allowing for efficiency gains through methods like undervolting and overclocking. As a result, performance can be significantly optimized through fine-tuning parameters, in contrast to conventional "out-of-box" methods.
While both CPU and GPU hash rates are somewhat lower compared to other algorithms, this is a deliberate design choice. The non-linear processes and the "airier" structure result in reduced hardware strain, leading to better overall energy efficiency.
The balance between CPU and GPU remains similar to previous values (i.e. the last mentioned information), but CPUs are now more efficient if there is enough L3 cache (modern CPUs). However, as more threads are used, efficiency will decrease. In other words, the hash rewards hardware that doesn't run at unhealthy full load but operates in a more balanced state.
A visualization of the dispersion of the Cryptixhash v2 values. We are still working on improving the dispersion, but it is already very good.

Cryptix Coin Introduces 8-Dimensional Octonion-Based Hashing
We’re thrilled to announce a groundbreaking development for Cryptix Coin—the introduction of Octonion-based hashing in Cryptix v2!
Octonions, an advanced 8-dimensional number system, bring a whole new level of complexity and security to our blockchain. By leveraging their non-commutative and non-associative properties, we’re pushing the boundaries of cryptographic algorithms.
Though still in its experimental phase, Octonion-based hashing could reshape the future of cryptography and quantum computing. We’re starting with a simplified version for Cryptixhash v2 and are excited to explore its full potential.
For more info, visit:
https://cryptix-network.org/cryptix-octonion-hashing
Current CPU to GPU balance in Cryptixhash v2:
Before (Cryptixhash v1):
Nvidia 1080ti: 280 MH/s hashrate, 250 W power consumption, 1120.00 KH/s/W efficiency (CUDA Test)
Ryzen 5 5600X: 995 KH/s hashrate, 5.5 W power consumption, 180.91 KH/s/W efficiency (RUST Test)
After (Cryptixhash v2):
- Nvidia 1080ti: 25 MH/s hashrate, 250 W power consumption, 100.00 KH/s/W efficiency (CUDA Test)
- Ryzen 5 5600X: 330 KH/s hashrate, 5.5 W power consumption, 60.00 KH/s/W efficiency (RUST Test)
This means the CPU now has 33.16% of its previous hashrate, and the GPU now has 8.93% of its previous hashrate.
Balance between CPU and GPU:
The balance between CPU and GPU has changed by 371.83%, meaning the CPU is now 3.72 times more weighted in comparison to the GPU than before. Of course, efficiency varies depending on the model, overclock, software, etc. But the tests used the same starting points, which clearly shows the difference.
However, the GPU is still more efficient, effective, and faster. On the other hand, CPUs are cheaper in terms of acquisition costs, which leads to a stronger long-term balance favoring the CPU. That's already a very, very good balance between CPU and GPU.
The hash isn't completely finished yet, but it's already very advanced and stable. We're currently improving resistance to hardware attacks like FPGAs. However, there won't be any major performance differences.
Many users have been asking how the coin swap will take place. The swap will be conducted via the "Exbitron" market. A market will be set up there allowing the old coins (CPAY) to be exchanged for the new coins (CPTX) on a 1-to-1 basis. This means that 1 CPAY can be exchanged for 1 CPTX in an automated market on Exbitron. Withdrawals will be fully automated, meaning no manual review is required. The swap will therefore be quick and easy. The market will be ready immediately after the hard fork. Accounts can already be created on Exbitron.
Additionally, it should be noted that the new coin will not be released on MecaCex.
It should be noted that many users have not received their withdrawals from MecaCex, and there are concerns regarding possible fraud or misappropriation of customer assets. Users are advised to proceed with caution.
For exchange or purchasing, Exbitron should be used.
https://app.exbitron.com/
To this day, the cryptocurrency exchange MecaCex has failed to process withdrawals for users with higher amounts—without any verifiable or understandable reason.
The Problem
Unclear "technical issues": MecaCex claims that on February 26th, their liquidity bots made incorrect sales, leading to funds being frozen. However, the market continues to operate, which raises serious questions.
Withdrawals blocked—even for small amounts: Initially, only larger sums were affected. Now, users report that even withdrawals under $100, or as low as $30, are not being processed.
Repeated delays: MecaCex provided a date when the issue was supposed to be resolved. This date has been postponed three times without a clear explanation.
Independent testing confirms the issue: We conducted a test transaction using a newly created, anonymous wallet. The result? A withdrawal of just $28 was frozen. Despite multiple emails to MecaCex support, no response has been received, and the withdrawal remains unprocessed.
Our Clear Recommendation
🚨 Stop using MecaCex for Cryptix transactions!
🚨 If you have funds on MecaCex, transfer them to your own wallets as soon as possible!
🚨 Cryptix v2 will NOT be listed on MecaCex!
We already have a plan to compensate affected users, but we can only share details after the hard fork.
If You Are Affected
If your CPAY tokens have been frozen on MecaCex, please provide us with the following:
✔️ Screenshots of your wallet showing the blocked amount (in CPAY, not USDT)
✔️ Proof of your withdrawal attempts
We want to support affected users, but the situation at MecaCex is deeply concerning. To this day, withdrawals remain unpaid, the number of affected users continues to rise, and the amounts involved are growing.
👉 Act now and protect your assets!
👉 We strongly advise against using MecaCex!
We would like to recommend Exbitron as a possible alternative platform (Cryptix v2 will list there too), where no issues are currently known:
https://app.exbitron.com/
The development of Cryptixhash v2 is progressing well and quickly. The current hash, which is 80% complete, has been running flawlessly on the testnet for several days. There hasn’t been a single Expect error, invalid block, or software crash. Things are looking very promising. Due to the complexity of the new hash, which is not even remotely comparable to Cryptixhash v1, we need to conduct longer testing. An unhealthy hash would be a big issue on the mainnet. Additionally, we are still fine-tuning the balance between GPU and CPU performance in the final step.
Currently, only the development of the cache and memory hardness function remains, but it is already usable in tests. However, security will be further enhanced.
The hash will be much more demanding than the previous version. To give you an idea:
Single-core CPU performance (Ryzen 5600X):
Before (Hash version 1) -> ~ 950 KH/s
Now (Hash version 2) -> ~ 150 KH/s
We cannot yet provide details on GPU performance, as it doesn’t make sense to write a CUDA driver yet since it’s a complex task, and the hash is still not finalized.
In theory (based on the methods and functions), CPUs will perform better than before. There will be a better balance between CPU and GPU. This means CPU miners will likely be able to compete better with GPU miners, although GPUs will still dominate. However, we still need to fine-tune the details of the calculations in the final step, so we can’t say much about that yet. One thing is certain, though: FPGAs will be severely limited and won’t be as efficient as CPUs and GPUs. This means that FPGAs will have no practical use, and instead, we would recommend using a toaster for mining, as it might generate a better hash rate.
We have chosen to use the final DLL with open-source code for the Proof of Hardware concept. This allows users to transparently inspect and even create the file themselves, without the need for code obfuscation or anti-debugging techniques.
Here’s how it works to make the file non-bypassable:
Dynamic DLL/SO File and Proof of Work:
In the dynamic DLL/SO file, which is loaded into memory for fast access, a part of the Proof-of-Work function resides. The hash cannot be calculated without this file, as it contains the necessary dynamic content. Without the file, the result would be invalid.
Verification of the Entire File Content:
The source code of the DLL is open, meaning attackers could theoretically extract the function and hardcode it to achieve the same result. However, we verify the entire content of the DLL by calculating a hash of the entire file content using SHA3 and Blake3. This hash value is required for the correct Proof-of-Work result. Attackers cannot simply extract the function and hardcode it, as they would need to reproduce the exact file and hash value, which is not possible without the original DLL.
Dynamic Values like Nonce:
Additionally, the DLL contains dynamic values such as the Nonce and Blockhash, which are generated dynamically for each mining attempt. These values are unpredictable, making it impossible for attackers to predict or hardcode a solution. The file does not have a fixed value and changes with each calculation, so a one-time debugging and hardcoding attempt is not sufficient to bypass the Proof of Work.
If the file / function is altered, even by a single character, the file will no longer produce the correct hash. Manipulating or changing the file is impossible. The entire file hash is dynamically calculated based on dynamic values (such as Blockhash and Nonce), ensuring that the hash cannot be hardcoded.
This could theoretically also be used against software piracy.
I've heard that other crypto projects say this is an 'organic' development of cryptocurrency/mining:
CPU -> GPU -> FPGA -> ASICs
Why? Because that's how it was with Bitcoin? You are not Bitcoin!
What kind of nonsense is this? It will lead to the following:
- The creation of a 'Pay-to-Play' system, where only those who can afford the expensive hardware can participate.
- Centralization of the network, with only a few users owning such devices.
- Destruction of fair mining.
- Could enable market manipulation (If individuals own many coins)
- Especially at the beginning a high risk of 51% attacks
- Shit on the people who made your project successful
You talk about your 'community,' but once you no longer need them, you'll throw them away. So, a new community with FPGA/ASIC miners is supposed to emerge instead? Is that how it works? Do you not realize that the community is the reason for your success, but then they can no longer 'play' because they can't afford to mine with FPGA/ASICs? Then you won't need them anymore.
Would you like to learn more about how we plan to combat hardware attacks in the future? Read about our "Proof of Hardware" idea / experiment:
https://cryptix-network.org/cryptix-proof-of-hardware
Recently, several users have reported issues with USDT withdrawals on MecaCex. Currently, we are aware of at least two confirmed cases where users have been waiting for several days or even weeks without receiving their payouts. One of these users has been waiting since February 22 for their withdrawal. The affected withdrawals involve larger amounts.
We have contacted MecaCex directly and were informed that there are technical issues. We were last told that the issue would be resolved by March 3. Despite this promise, the affected users still have not received their payouts, and our messages sent after March 3 have gone unanswered. Although the MecaCex team has been online, we have not received any further communication since then.
We are now being repeatedly asked about the status of the withdrawals and when users will receive their funds. We also do not have clear answers.
Our Recommendation:
If you have funds on MecaCex, we recommend immediately requesting a withdrawal and informing us if you experience any technical issues.
We advise against making new deposits to MecaCex until the situation is clarified and the Problem is fixed.
If your accounts or coins are currently blocked, please note that this is not related to us. So far, there has only been one case (was the FPGA Attacker) where we made this recommendation.
We will continue to monitor the situation and keep you updated. If the technical problems have been resolved and all users have received their withdrawals, we will announce this here.
We would like to recommend Exbitron as a possible alternative platform, where no issues are currently known:
https://app.exbitron.com/
Please note that we take no responsibility for the use of Exbitron. Writing this message is a difficult step for us as it is our main market and our liquidity/orders. But we are trying to fulfill our obligations and protect our users from problems.
To make this absolutely clear again, as there is a lot of misinformation about it:
Cryptix is a decentralized blockchain, meaning that no one—really no one, not even developers—can intervene in the blockchain, alter, freeze, or block wallets or the blockchain within the blockchain.
The AI can't do this either, and neither can anyone else. It is a decentralized system with no control functions.
What we can do with the AI is analyze suspicious patterns for transactions and mining. This means we try to detect and prevent fraud or criminal activities using AI and manual checks. Our goal is to prevent misuse of the project and the coin as much as possible. However, we cannot do this within the blockchain itself, only externally. Or, in the case of serious criminal activities, forward this to the authorities.
This means it's only possible through cooperation with exchanges and pool operators. However, we can only send them information about our findings and cannot interfere with their systems. The operators decide for themselves what they consider appropriate and what actions they think are necessary. The pools are all operated by external parties (except for the community pool), and exchanges are also external operators. We also cannot force operators to check or respond to such things, we can only hope that this is the case.
CEX platforms are easier for cooperation because they are centrally managed, and withdrawals are manually verified anyway. Intervening in criminal activities such as money laundering, serious fraud and so on is also required by law for a CEX in many countries. DEX platforms are more difficult. It’s also not just us informing the operators when something suspicious is noticed, but vice versa as well. An exchange or pool can notify us of suspicious activity, and we will check it with our AI or manually.
Through such two-way communication and collaboration, we can detect as much misuse as possible. However, we can't prevent everything because it ultimately depends on the exchange or pool operator how they handle it. We can only analyze and report—there’s nothing more we can do, but that seems to be completely sufficient at the moment.
Within the blockchain, no one can intervene with your wallets unless the coins are on external wallets, like with mining where the coins are temporarily on the pool’s wallet. Or when the coins are sent to an exchange, the coins are on the exchange.
This should be clarified to avoid any further misinformation on this topic. We try to make the network as secure as possible, especially for new users. But resources are limited, especially since we will remain a decentralized blockchain in the long term. All we can do is analyze, report and check. Then we can pass on the information, that's all we can do. It should also be noted that the wallets are anonymous, there is no data collection of sensitive data. We can only analyze wallet addresses and the coin movements and transactions of anonymous users. Only when connected to the FIAT world can identity be determined.
These details can be verified through our GitHub, as the blockchain/node code is publicly available:
https://github.com/cryptix-network/rusty-cryptix
We have the first ideas to make things difficult for ASICS / FPGAs. Anyone who wants to work on this is welcome.
For understanding: The biggest weakness of FPGAs and ASICs is memory bandwidth and memory access time. This is especially true when low-quality or old boards are used, but even with high-quality and new boards, these limitations still exist.
While ASICs and FPGAs are extremely efficient at performing calculations that can be parallelized (e.g., simple mathematical operations or streaming data through an algorithm), they are more limited when it comes to complex memory operations.
When an algorithm requires reading and writing large amounts of data from memory (for example, by repeatedly accessing and updating large arrays or matrices), the hardware faces memory bandwidth bottlenecks. FPGAs, in particular, have less internal memory bandwidth compared to CPUs, making them slower for memory-intensive tasks, even though they might theoretically be faster than CPUs for simple computations.
To significantly limit or potentially block ASICs/FPGA performance, the following steps should be considered:
Implement unpredictable or dynamic calculations.
Branches and conditional logic.
Push hardware to its limits with memory-intensive or non-parallel tasks.
Overload or flood memory channels (large-volume memory access).
Prevent parallelization.
High latency memory accesses
Irregular memory access
Data that is not well cached.
Utilize dynamic memory access patterns.
Unpredictable algorithms
https://github.com/cryptix-network/cryptixhash-v2
We are currently working on a solution that could significantly throttle the efficiency of FPGAs and ASICs, potentially to the point where it would no longer make sense to purchase them or use them for mining.
We are also offering our services to other cryptocurrencies to help them protect their networks from FPGA/ASIC abuse, should they prefer not to have such devices on their network. Our services are completely free of charge and non-binding. The goal is simply to ensure fair mining and protect decentralization.
We offer these services primarily to the following coins (but not limited to them):
ASTRIX
Pyrin
Ironfish
Wala
Hoohash
We already have initial approaches and programming in place, which should make it extremely difficult for FPGAs and ASICs to mine these coins or even for such devices to be developed. However, it's important to note that FPGAs are reprogrammable, and this process must be thoroughly tested and observed over the long term. It will not be a quick and easy solution, but it is a possible approach. Will we succeed? We don’t know. Will we try our best? Absolutely.
Since users keep asking about the future: ASICs were never allowed and never will be.
FPGAs—small devices up to 2 GH/s per user, wallet, or household—were initially planned to be allowed. We even intended to provide the necessary software for them. However, after the first 700 GH/s attack, it became clear that the best course of action was to ban these devices entirely.
To make it absolutely clear: The use of ASICs and FPGAs (including small devices) is not permitted and constitutes a violation of the Cryptix Network's terms of use.
Anyone who uses these devices is attempting a targeted manipulation of the network, which could have legal consequences. After the recent events, where a user attempted to exploit our network, the topic of FPGAs will no longer be reconsidered.
And personally speaking, it is sad that there are always people trying to exploit a system. They enrich themselves at the expense of others, not because they necessarily need the money, but because 1 sports car is not enough.
We have people in the community who have been mining fairly since day one, using a small graphics card because they aren’t rich or don’t have great wealth. We have miners in the group who come from poor countries. These people have their block rewards taken away out of greed. I cannot understand what a person must experience to become so morally and ethically flawed.
Everyone should realize that the crypto world is not a PvP game, but the real world. There are real people here, a real community. This is a real project with a lot of work, a future, and goals. Maybe some will take a moment to reflect on that.
And it's not always just about money. Of course, most miners are here for that reason. But personally, I've always loved testing new hardware, experimenting with new overclocking settings. Having the mining hardware in front of you, tweaking it. Reading about technologies and hardware. Crypto and mining can be a lot of fun, and it's enjoyable.
The Twitter event has ended! We have determined the winners using a random generator:
🏆 1st Place - 5000 CPAY: @badsir_93p
🥈 2nd Place - 2500 CPAY: @vladSpasov50484
🥉 3rd Place - 1000 CPAY: @OPrinceOfWarO
Congratulations to the winners! 🎉🎉🎉

We are working on a Strike Back system for the AI.
Strike Back Attacks are highly controversial and questionable, as they involve attacking the attacker, rendering them unable to continue their assault. Essentially, you use the same methods as the attacker (or better ) to defend yourself. Legally, this is not allowed; however, it is also used as a social engineering tactic, with the aim of potentially making the attacker stupid enough to file a report and reveal their identity. Most courts issue acquittals for Strike Back Attacks – but not always – and punish the attacker, though many attackers won't take any action because they don't want to incriminate themselves. It is also the case that servers are often attacked and the hosts of the servers do not care about abuse. In the case of a strike back attack, the hosts take care of it very quickly and stop the attacks on their servers.
We were asked whether it would be possible to integrate this, and yes, the idea is good. The user must decide for themselves whether they want to use it. We do not give any recommendation on this matter; it's up to each individual to decide.
But to emphasize, if we were to publicly provide this feature: It is not allowed, and one would most likely be violating the law.
The targets are not freely selectable but only applicable to attackers, as we want to prevent misuse. It is intended to provide a last resort for companies to protect themselves from attackers if no other option is available.

After experiencing firsthand how frustrating DDoS and payload attacks can be, we decided to develop a security AI that functions as an intelligent firewall. The AI utilizes TensorFlow, neural networks, and deep learning to provide the most modern AI patterns. Cryptix Defender AI is not just designed for crypto projects; it can be used on any server that has a hosting task. All connections to a server are protected, and the AI currently offers the following security defense mechanisms. It is, therefore, also useful outside of crypto-related applications and protects against attackers.
Anti-DDoS attacks
Anti-0 Byte attacks
Anti-payload attacks
Anti-UDP flood attacks
Anti-SYN flood attacks
Additional protection mechanisms will be added as development continues, but these are already the most common and widely used by attackers.
The AI features a training mode, where it learns what normal user behavior and server load look like. In the running mode, the learned data is applied, and the AI uses the acquired knowledge to protect the server. You can freely choose whether potential attackers should be blocked temporarily or permanently banned from the server. The AI analyzes IP-based user behavior from the past 30 seconds, 2 minutes, and 10 minutes. This helps to detect both fast, aggressive attacks and longer-term passive attacks.
It is important to note that the AI needs to be trained for at least 1 hour during high-peak (high load) conditions to acquire the correct training data and become usable. Ideally, it should be trained multiple times. Also, please note that this is version 1 of the AI, and more features and analysis patterns will be added. There may still be some bugs present. Therefore, we recommend using the block mode for now, as it provides full protection.
This AI will always be free, and we hope that it can help stop annoying tyrants on the internet and assist overwhelmed server administrators in dealing with such attacks more effectively.

Our AI now receives neural networks (deep learning), we have replaced the IsolationForest learning function with tensorflow.


Other crypto projects have contacted us, claiming that they are suffering from DB filler attacks, so annoying Hacking-Attacks. This is incorrect. It is not the DB fillers that are being attacked, but the socket servers. The DB filler crashes when the RPC channels are overfilled, including by payloads.
Therefore, I have provided a starter file for all coins that protects against this issue.
Simply replace the current Main.py on the socket server with this file. After that, payloads that have no effect and users who attempt to use them will be blocked immediately.
(Of course, the cryptixd tags, etc., still need to be replaced with your own cryptocurrency).
https://github.com/cryptix-network/cryptix-anti-script-kids/blob/main/secure-the-socket-server-main.py
There is now a Linux version for the firewall:
https://github.com/cryptix-network/cryptix-anti-script-kids
Download the last Release:
https://github.com/cryptix-network/cryptix-anti-script-kids/releases/tag/v1.3
Can be freely used and modified for any project.
🚀 NEW EVENT 🚀
A brand-new community event is here, and here’s how it works:
✅ Follow our Twitter account:
🔗 https://x.com/Cryptix_Network
✅ Comment, like, and share this image on Twitter:
📷 https://x.com/Cryptix_Network/status/1892611057530618295
🏆 Prizes:
🥇 1st Place = 5000 CPAY (500 Blocks)
🥈 2nd Place = 2500 CPAY (250 Blocks)
🥉 3rd Place = 1000 CPAY (100 Blocks)
The winners will be selected randomly using a public random selection tool. We will input the participants’ usernames into the system and let the generator decide!
⏳ Deadline:
You have 72 hours (3 days)! The event ends on 02/23/2025 (MM/DD/YYYY) at 16:00 GMT+0.
Good luck! 🍀🚀
(As always, team members are excluded.)
- A bug has been fixed that blocked training for certain wallets.
- The start file, i.e., the training file, has been better trained for this version.
- The training works more smoothly now, as values adjust more gradually rather than changing abruptly.
- A sensitive mode has been added.
- The AI sklearn.cluster was customized.
- During training, data is now evaluated more precisely.
- When marking a suspicious wallet/miner, a re-spin of the training is triggered in sensitive mode.
This version is already much more refined and can be effectively used by community members for analysis. However, it is important to note that this is a different version from the one we use, with limited features. We use a developer version, which includes many more variables, analysis patterns, and functions. Additionally, this version is not as well-trained, as our training files contain several GB of data.
Download:
https://github.com/cryptix-network/cryptix-tx-ai/releases/tag/v1.1.0
Only 9 days left until the halving.
Block Reward now: 10 CPAY
Next Halving: 2025-02-26 05:16:19 UTC
New Rewards : 9.4387 CPAY
Minus: 5.61 % Rewards
AI TAB (All Versions):
New AI Tab: Connects to our live AI, and there is now an "Analyze" button for accessing the public version of the TX AI for wallet analysis.
Important: Start with Training Mode instead of Analyze Mode, as the AI is untrained, and Training Mode provides more accurate results.
Miner TAB (All Versions):
Overlay: Displays when the last block was found or when the last share was submitted.
Total Counter: Shows a total counter for blocks and shares.
Highlighting: Shares can now be highlighted if the feature is enabled.
NFC TAB (Go Dev):
The NFC Tab has now been added to the Go Dev Version. It was already included in the Rust DEV Version in Pre-release 1.1.5.
Node TAB (All Versions):
Error Message Removed: The annoying connection error message that appeared after restarting the server has been removed.
Wallet TAB:
Efficiency Improvement: The Wallet Tab is now more efficient.
Additional Updates:
Bug Fixes: Several smaller bugs, especially regarding responsiveness, have been fixed.
This update includes useful new features and several optimizations, making the overall experience smoother.




Download
A picture is worth a thousand words. Or?

We are currently working experimentally on a Crypto/Blockchain Messenger & Chat function. It is still very experimental, and we are unsure if it will be released as a final system. However, everything looks very promising so far.
What can it do? It enables a real Blockchain-based encrypted messaging and chat service. Messages can be sent and received over the blockchain in a decentralized and anonymous way. There are no servers, it works entirely through the blockchain and transactions.
An encrypted hash with the message is attached to transactions, which sends the message via a transaction and stores it encrypted on the blockchain. Through endpoints like the all-in-one software, app, or even a website, users can join live chats and receive private messages.
Currently, in our tests, messages are limited to 64 characters. This is similar to half of an SMS (which was 150 characters). However, up to 100 messages can be sent consecutively. Longer messages can also be split into multiple transactions, which would increase the reception time and possibly the cost of the message. The system supports numbers, letters, and special characters. We still need to test and experiment with other formats. Messages are sent and received in real-time with a block time of one second.
We will set a fixed message fee. The transaction fees will go to the miners. The message fee is designed so that the coins are burned. No coins go to the team or developers. This will reduce the maximum circulation of CPAY over time. The burned coins will be displayed in the explorer.
The fee will likely be around (per message) ≈ 0.0001 CPAY, which currently equals about $0.00000005 per message. This means that for 1 cent, you can send 200,000 messages.
It is important to emphasize that we are currently experimenting with this feature. Whether we will release it and whether it is technically feasible will be determined in the near future.


* These images are from the developer editor. For users, there will be a normal frontend/messenger UI.
The winners of the Mining Art Event have been determined:
1. Place: @amd99 (5000 CPAY) | with his recycled wooden rig

2. Place: @nostalgia (2500 CPAY) | with his Playmobil rig

3. Place @Tsboi (1000 CPAY) | with his rainbow rig

Thanks Hashrate.no for adding Cryptix-Network.

hashrate.no/coins/CPAY
Cryptix Live TX AI - this is still a BETA DEMO, not a finished system.
Visit the AI
We were released nearly two weeks ago, and it has been a bumpy and challenging time since then. Whether it was attacks from other crypto projects, system overloads, or fraudulent miners trying to exploit the network—it has been stressful and required a lot of work. However, it has also been an exciting time filled with rapid progress. Most importantly, it has strengthened the community and fostered a sense of unity. Even temporary setbacks can lead to positive outcomes.
What’s next?
Honestly, we don’t know exactly, but one thing is certain—it will continue to be a demanding journey. We have a lot planned and aim to stand out through rapid progress and competence. There are already too many crypto projects making false promises without delivering real progress, and we don’t want to be one of them.
Currently, we are developing many new features, some of which are still in the testing phase and weren’t even mentioned in the roadmap. We like to use the element of surprise and avoid making false promises. Some features may be scrapped if they prove to have little value, while others may be released without prior announcement.
Our focus remains on making blockchain and cryptocurrency technology more accessible to everyone. We are working to bridge the gap between the FIAT financial system and the crypto world while showing users the benefits of cryptocurrencies. We already have a highly skilled development team, but we are still open to new members. If you believe in the project, you are welcome to join us—whether as a supporter or a developer.
A Big Thank You to the Community
Whether you are a miner securing our network with your computing power, an early adopter holding your coins, a user helping newcomers with their questions, or simply someone who believes in this project—we appreciate each and every one of you! ❤️ We are doing our best to make this project grow and achieve its goals. At the same time, we are realistic and understand that even with rapid progress, it will take time.
🚀 The journey has just begun!
Cryptix and Crypto World are officially Partners now.

We are releasing: Cryptix TX AI v1.0.0
A trainable AI that detects suspicious wallets for transactions and mining.
This version is a beta and needs to be trained with data. As such, it may provide false results due to insufficient training. However, anyone can already test the AI and train it with their own wallets and data.
Why haven't we provided information on AI development? The reason is that many crypto projects advertise with AI, but after a year, they often don't actually have an AI, and it becomes clear that the developers are not capable of creating one. Because of this, crypto projects are often recognized as scams as soon as "AI" is mentioned in the roadmap. Therefore, we decided to release an AI first and only then talk about it.
This AI will continue to be developed. The developer version we are working on is already more advanced. This version is meant as a test version for community members, and also to help identify and discover suspicious wallets. The developer version already has the following features:
Track new blocks in real-time
Follow coins from block rewards to exchange transfers (even with 10,000,000 sweeps/compounds)
Automatically search wallets on the explorer
Automatically find suspicious transactions
Automatically find suspicious wallets
Automatically find suspicious Miners
The developer version is still a bit buggy, as it is in the early alpha stages. It can store data in a database and provide access to the explorer, showing suspicious wallets and miners.
Am I no longer anonymous? No, your wallet remains anonymous. No user data is collected. Only suspicious wallets are identified and reported based on transactions or mining activity. The detection works very well with a very low error rate. With further training, the error rate should be almost non-existent. Normal miners/users are completely ignored by the AI.
What's the benefit? It can track fraudulent/illegal transactions, miners, and wallets. It's impossible to escape detection by the AI, or to spin the coins into an anonymous state.
By the way, the use of ASICs and larger FPGAs (with more than 2 GH/s performance) is officially prohibited. This is known to both users and manufacturers, as it is stated in the source code, whitepaper, website, and even in Discord. Using such devices would constitute fraud against other users, and attempting to exchange coins via an exchange would be market manipulation and economic fraud.
The All in One Software will get a AI Update in the Dev Edition soon.
Rumor has it that more AI software and features maybee will be coming soon, including some for mining... but shh, keep it between us 🤫🚀.

https://github.com/cryptix-network/cryptix-tx-ai/releases/tag/v1.0.0
Join our fast-growing Discord community. Be Cryptix! #Crypto #Cryptix #Discord

https://discord.cryptix-network.org
Cryptix (CPAY) is now officially listed on Exbitron
Live & Ready – Start exchanging today!

https://app.exbitron.com/exchange/?market=CPAY-USDT
We have activated the API and NFC system in Cryptix Network All-in-One Version 1.5 (currently only available as the Rust developer version). However, this is still in beta status.
----- What does it do?
It activates a REST server for NFC payments (e.g., POS systems) and REST payments (e.g., online stores) when the Start button is pressed.
There are dedicated endpoints for REST and NFC:
NFC / POS:
/nfc-input/ (POST) | Input for payment requests, separated by devices
/nfc-output/{deviceId} (GET) | Displays payment requests for devices
REST / Online Stores:
/rest-input/ (POST) | Input for payment requests, separated by devices
/rest-output/{deviceId} (GET) | Displays payment requests for devices
The DeviceId allows for an unlimited number of devices, such as POS systems and online stores, but can also be used with just one device by simply using ID 1.
A manual input option is available for both REST and NFC, simplifying usage for small applications (for example, when the system is run with only one device in a store). It is also intended for administrative manual interventions.
Payment request data is stored and available even after a device restart or failure.
There is a manual NFC writing function, which allows direct connection of NFC devices with the software. It is also now possible to write NFC cards, making them fully usable.
To use this, simply enter the wallet address and press the "Write to NFC" button. Everything is fully automated. The interfaces and data from the storage system can also be used and connected.
Supported NFC systems:
ACR122U NFC Reader (the most widely used system worldwide)
Omnikey 5321 / 5325
Identiv SCR3310v2.0 USB Smart Card Reader
Sony RC-S380 (NFC Reader)
uFR NFC Reader
ACS ACR38 Smart Card Reader
Gemplus GemPC USB Reader
Additional devices need to be tested; the system uses ISO 7816
NFC-enabled smartphones
(Other devices need to be tested)
Please note, this is still the beta version, which needs to be tested in real-world scenarios. So far, everything has worked perfectly, with no bugs or errors reported.
This feature/update is primarily relevant for commercial users or individuals who want to test the function. Otherwise, there are no other updates in this version.
Powershell command to activate NFC Services:
net start SCardSvr

https://github.com/cryptix-network/cryptix-all-in-one/releases/tag/v1.1.5
Node Tab:
A new display now shows the current network hashrate.
A new display now shows the value at MecaMex.
(Data updates every 2 minutes.)
Wallet Tab:
A new option allows you to use the local node, meaning the Web Wallet servers are no longer contacted. This ensures the highest level of security and anonymity, as there is no external connection between the node and the wallet. We strongly recommend using this feature and running the wallet via the local node. However, the Wallet servers can still be used if desired.
Important:
When selecting "Local Node" in the Wallet section, it may take a few seconds for the computer to start the service (around 5 seconds). If the computer takes longer and a white window appears in the Wallet section, simply click the "Start Wallet" button to reload the page.
+ Fixed Minor Bugs like the Delete Data Button


Cryptix CPAY dual mining is now possible with SRB Miner.
+ Added support for dual mining FISHHASH/CRYPTIXHASH on AMD RDNA/RDNA2/RDNA3, NVIDIA (except Pascal)
+ Added support for dual mining AUTOLYKOS2/BLOCX + CRYPTIXHASH on AMD RDNA/RDNA2/RDNA3, NVIDIA GPUs
https://github.com/doktor83/SRBMiner-Multi/releases/tag/2.7.7
MecaCex is carrying out an update for Cryptix. The update will start in 6 hours. After that, it will be possible to mine directly on the MecaCex wallet and receive the block rewards there.
https://x.com/MecaCex_Com/status/1887427892604510393
Be ready to open your Bag:
At 3 TH/s, we’ll add 10,000 CPAY to the Faucet website and change the limit per person to 100 coins. That means the first 100 people can claim 100 coins for free!
Join our Discord to not miss the opportunity.
Discord
Join our Telegram:

Telegram
Starting today, our marketing processes begin. We will first focus on SEO, backlinks, guest articles, and maps, as these generate the fastest and most effective growth while ensuring long-term sustainability.
For competitive reasons, we will not disclose specific strategies. A 10-member marketing team has already taken on this task.
The All-in-One software has received an update with new useful features:
Cryptix All-in-One 1.1.3 Update
+ A synchronization status information has been added.
+ You can now select between 2 different wallet servers in the Wallet section.
+ In the Miner configuration area, pools can now be selected and connected without the need for manual configuration.
+ Newest Version of Stratum Bridge with 0% Fee
+ Minor bugs fixed, such as the taskbar not adjusting in fullscreen mode, and more.



Download
We have added a Reward Calculator.

Rewards Calculator
We've reached a new hashrate record today! The peak was 2.4 TH/s on 02/02/2025. 🚀

The winners of the Blockchain Art Event have been determined:
1. Place: @【𝐒𝐭𝐢𝐚𝐧𝐍𝐎𝐑】|𝔻𝕋| | 250 blocks (2500 CPAY)

2. Place: @Maxzbs | 125 blocks (1250 CPAY)

3. Place @demon193d | 50 blocks (500 CPAY)

We have implemented a pLimit per server, meaning there are now maximum connection limits in place. This prevents the application from crashing due to overload and ensures it remains online. Essentially, this acts as a bottleneck, where connections exceeding the limit are placed in a queue, and idle connections may be deactivated.
As a result, if you leave the wallet open for a long time, you might need to reconnect—this happens if another user takes your connection slot. However, this only occurs during high traffic periods. Otherwise, your connection remains stable.
We are still fine-tuning these settings, so we may need to restart the Web Wallet service more frequently for adjustments. If you encounter loading errors, this is normal—simply wait a moment and try again.
Next Steps:
To ensure pLimit doesn’t have to be used constantly, we are currently working on load balancing across multiple servers. We are developing a custom system that will distribute all requests evenly across servers. The exact number of servers needed will be determined over time.
Right now, we have three Web Wallet servers, with the third one currently being added.
The web wallet servers are completely overloaded, and we did not anticipate such a rapid surge. Currently, we are registering more than 1000 requests per second in our systems, which the servers cannot handle. We have temporarily shut down the web wallet for server upgrades, and it will be available again soon. The node and console wallets are still functioning.
https://cryptix-network.org/cryptix-network-status
Unfortunately, our recent progress was slightly hindered because a few pubescent script kids thought it would be fun to flood our website with DDoS and gRPC attacks. However, we managed to stop these public menaces with a handful of lollipops and a Python script.
Since we believe that other coins might be affected as well, and we know how annoying this can be, we're offering the script for free for anyone to use:
https://github.com/cryptix-network/cryptix-anti-script-kids
How to win:
Take a screenshot or download your image (right-click on the website and select "Save As"):
The best images of the visualized BlockDAG will win a prize:
1st place = 250 blocks (2500 CPAY)
2nd place = 125 blocks (1250 CPAY)
3rd place = 50 blocks (500 CPAY)
How it works: Go to: https://dag.cryptix-network.org/
Wait until a cool image is generated, then take a screenshot or right-click on the image and choose "Save As" to download it.
The Cryptix team will choose the winners from all submitted images. Images will only be accepted if they are uploaded in the "Blockdag" channel. The Cryptix team itself is excluded from participating in the event.
The submission deadline is in 24 hours, so it will be on 02/01/2024 (MM/DD/YYYY) at 10:30 GMT +0.
Join our Discord: https://discord.cryptix-network.org/
Two main tasks are currently in progress:
OpenCL Driver Update for the GPU Miner – This is not the most enjoyable task, but it's necessary for AMD cards and as an alternative to CUDA.
Upgrade of the All-in-One Software – The focus is primarily on improving mining to make it even more accessible and user-friendly. Pool support is also a key aspect of this update. Additionally, a few minor visual bugs will be fixed.
- SRB Miner Release for Cryptix / Cryptixhash
https://github.com/doktor83/SRBMiner-Multi/releases/tag/2.7.6
- New Mining Pools:
1. pool.cryptix-network.org
2. iturkmining.com
3. 2Realminers.com
4. gogpool.eu
We actually wanted to wait until the first pruning point and then release, but it doesn’t make sense because miners are constantly in the network. No matter how often we ban them, they keep coming back with a different IP address or VPN, sometimes within seconds. This was already the case from the third day after we uploaded the code to GitHub (so the entire last months). At that point, it was possible to manage the miners because there weren’t many, and we were constantly changing the hash. Now, however, the hash is final, and the miners have extracted the correct miners from the node. To ensure these miners don’t mine alone, we’ve decided to offer everyone the opportunity to mine, but at their own risk, since we don’t know if there will be a technical problem with the pruning point. If it works with the pruning point and the evaluations are fine, we’ll stay on this chain. If not, we’ll reset, fix the problem and try again. Why is this the case? Because we’ve had multiple issues with the first pruning point, where the nodes couldn’t download the blockchain anymore. It worked during the last testnet after the most recent changes. However, we want to be sure before officially releasing. So, to cut a long story short, there’s no point in simply waiting for the pruning point to come, because miners are always in the network. And then they mine alone, so we’re offering the opportunity for everyone. However, if we have to reset, there can be no complaints about wasting electricity. One solution would be to change the genesis and make the source code private. However, this would lead to legal issues later regarding the classification of securities, so it’s not an option.
Anyone can test the pruning point themselves by:
Downloading and starting the Go (important, the GO Node - not Rust) node.
- If a message appears stating that the current IDB does not -change the pruning point, then the first point has not been reached.
- If a message appears stating that the block level is incorrect, the pruning point did not work.
- If the node synchronizes, the pruning point has worked.
CRYPTIX IS NOT RELEASED NOW!
Progress Status:
✅ New Nibbles
✅ New Matrix
✅ New Iteration
✅ New XOR
✅ Stratum Bridge
✅ SRB Miner
✅ Cryptix CPU Miner
✅ We test the CryptixHash
--- Mining Test Stratum ✅
--- Rust Node Test ✅
--- Mining Test Rust Node ✅
--- Multi GPU Test ✅
--- Go Node Test ✅
--- Mining Test Go Node ✅
--- Pruning Point Test ✅
✅ Mining Core Upgrade ( Community Pool)
✅ Release / Launch