¶ Kaspa
¶ Brand
¶ Does Kaspa have an Official Brand Guide?
It does have generally accepted logography, colors, and fonts, you can find them on the media kit on the kaspa.org.
¶ why is the kaspa logo not a perfect circle?
Per @Rhubarbarian (Discord): The logo was designed with much thought. The "K" is slightly bent to form movement (an arrow) as well as to emulate a more classical Aramaic character in a modern form. The shape of the outer ring is to symbolize a well used silver coin (not perfect, common coin). The colors were inspired by the patina of an aged metal coin.
¶ Development
¶ How do I view the official open-source code?
You can find it on: github.com/kaspanet. More specifically — the code for the actively developed and most widely used version of the node, written in Rust, is located here, while the code for the version written in Go, that is currently still being used by some people on the mainnet but has been declared deprecated and is no longer supported (although it remains consensus-compatible with the Rust node code, and will stay in this state until the activation of the 10 blocks per second mode) is here.
¶ Is Kaspa hiring developers?
Kaspa does not have paid positions. Kaspa is a community project, all related activity is carried out on a voluntary basis and, if paid at all, is paid through donations. In particular, a fund of 100M Kaspa was raised for the ongoing rewrite of the source code from the Go language to the Rust language, and another fund of 70M Kaspa was raised for the implementation of the DAGKnight protocol. The funds from these pools are distributed among participants involved in the respective tasks according to internal agreements, and this distribution does not necessarily have to be public — it is at the discretion of the participants.
Any previously funded projects, as well as new proposals suggesting compensation for development, go through the following stages:
- Publishing the initial proposal in the #votes-and-funding-discussions channel on Kaspa's Discord;
- Discussing the proposal and holding a preliminary vote on it;
- In case of a positive preliminary vote there goes a general vote;
- In the event of a positive outcome in the general vote, a fundraiser is announced for the implementation of the proposal;
- In case of successful fundraising, the execution of the proposal commences, and in case of failure, negotiations are held with the proposer regarding the fate of the raised funds.
Sometimes volunteer activity is rewarded retroactively, in case a person has brought significant benefit to Kaspa, according to the active community members opinion. Proposals for rewarding a particular person go through the same approval stages as described above.
In general, Kaspa needs developers, but preferably enthusiast developers willing to contribute to the development of Kaspa out of interest or to help advance the project in which they themselves hold a part of their investment portfolio (as well as to be part of the history of cryptocurrency development as a participant in one of the revolutionary projects).
¶ L2s and Smart Contracts
¶ Does Kaspa support L2 features?
A limited set is supported, namely a KRC-20 standard. See kasplex.org.
¶ Will Kaspa implement smart contracts in the future?
Yes, the corresponding work is being led by a couple of groups of people, outside the Kaspa core development team, with general oversight provided by Yonatan Sompolinsky.
Additionally, discussions regarding L2 and smart contracts implementations are being held in the #smart-contract-brainstorming channel of the Kaspa Discord server.
¶ Rust rewrite
¶ What is Rust rewrite?
See KIP-1 (Kaspa Improvement Proposal).
¶ Why switch to Rust instead of refactoring the Go code?
There's a discussion on this topic here. In short, too much technical debt in the Go code, and better native security and parallelism support by the Rust language. The latter is not of great importance at 1 block per second, but is absolutely crucial for the multi block per second network sustainability on affordable hardware.
¶ Hard forks, downtimes and global issues so far
¶ Did kapsa have downtimes?
Yes, several times in its history.
First Kaspa was down during 2-3 days at around November 23th-25th 2021, 2 weeks after the mainnet launch, thanks to a net split due to some bug in its code. That bug was discovered and fixed with the Kaspa's first hard fork, which also introduced a stable 500 Kas per block reward, instead of the previously active pseudorandom 1..1000 reward with the avg of 750 Kas per block. A proof of network integrity between pre- and post-hardfork states (balances, commitments etc.) for independent check can be found here.
Due to downtime, there was a period that involved the @someone235 solo mining in an unfair advantage to secure the network. This resulted in about ~11 million coins being mined. To provide transparency about this event Yonatan (hashdag) proposed to allow the community to decide on what should happen to the coins here. The community decided that the amount should be burned and the announcement about these coins being burned is found here. Today you can view the burn wallet here and currently as of writing holding 11,221,012.15428043 KAS worth very close to 1.9M dollars.
At December 16th, 2023 Kaspa had experienced another short-time (~20 minutes) pause in blocks acceptance (but not their generation) due to another bug manifestation. There's quite an interesting post mortem of that event by Ori Newman.
¶ What's that dust attack story?
See this post mortem by Shai Wyborski.
¶ When Kaspa goes from 1 bps to 10 bps, is this a fork of the network that leaves us with two Kaspas, or an upgrade to mainnet?
Yes, a hard fork will be required, but don't anticipate the existence of 2 Kaspas, as there is no group of individuals (especially miners) interested in maintaining the "original" Kaspa network.
A network split resulting in two coexisting coins - a "classic" one and a "new" one - typically occurs when developers and/or miners diverge in their visions for the project's future. Some choose to remain with the "original" or "classic" version for their own reasons, while others transition to a newly forked version.
However, this scenario does not apply to Kaspa. The community is unified, so there is no motivation for anyone to uphold the pre-forked version. While it is technically possible for some miners to unintentionally miss the upgrade, it is unlikely to last or succeed in the long term based on the aforementioned reasons.
It is important to note that the fork will not impact balances nor necessitate any form of "upgrade," "switch," or "exchange of old coins." All balances will remain unaffected, and any offer requesting users to "send coins to a designated address for a new version" should be considered a 100% scam attempt.
¶ Global hashrate
There are several trackers of the history of Kaspa global hashrate, for instance here and here (scroll down to charts, click the "hashrate history" tab).
There's also the most genuine source of such data in every Kaspa node: each node stores the historical list of pruning points, where the next point is created every 24 hours, since the Kaspa mainnet inseption. These pruning points can be used to obtain a difficulty sample from each day in history. Here's the difficulty chart by 2025 Jan 06 (notice the chart reads the difficulty, not the hashrate; but the hashrate estimation could be derived from the difficulty: for 1 BPS network it's done by multiplying the difficulty to 2, for 10 BPS network that will be multiplying it 20):
Here's the csv file for the chart above.
¶ Tokenomics
There's a separate article on the topic.
¶ Miscellaneous
¶ Where is the rich list?
¶ Where can I Trade Kaspa?
There's a separate article about it.
¶ Is Kaspa quantum resistant?
No and won't become in the near future. See Shai's explanation.
¶ Explorer
¶ What are Kaspa explorers?
Here: explorer.kaspa.org and kas.fyi.
¶ There are so many differences In transaction History between explorer and KDX/Web wallets, how to find out who tells the truth?
Generally, the explorer knows best because it maintains its own transaction database that is not pruned. The KDX node undergoes pruning daily, along with the web wallet node, in order to retain only the most recent 2 (and up to 3, by the end of the period) days of blocks and their transactions.
Therefore, if you stop using KDX for more than a day (or do not access the web wallet during the same period — or have cleared your browser cache where the web wallet stores its transaction history), you run the risk of losing some transaction information for those sent to or from that wallet. However, this limitation does not affect your balance, as the balance is retrieved directly from the node on a per-address basis, and the node's balance data is never pruned.
¶ Nodes
¶ How many nodes / miners are there?
As of January 03, 2024 there are around 340 public nodes active. There is an unknown number of node not accessible from outside (personal-use nodes).
Public nodes known to kas.fyi by January 03, 2024
As of September 21, 2024, the top miners are as follows:
- kaspa:qpamkvhgh0kzx50gwvvp5xs8ktmqutcy3dfs9dc3w7lm9rq0zs76vf959mmrp: 33.9%
- kaspa:qrk9decfnl4rayeegp6gd3tc6605zavclkpud5jp78axat5namppwt050d57j: 21.9%
- kaspa:qqc3a2j95vhn9jlq9d87mexyg7dwc0lvnyvzwypgwk9hx00h44krvlhf85g4q: 9.6%
- kaspa:qquu5ypnp3n0za4uu3dh89rftgnjzmlc3p4czx4la4nqd4lnw2n65fsq8y8le: 6.9%
- kaspa:qp9rv9jvx2kyf6wu4lupuruunq5zsuszyxs0dr3l89ej7wsgs48jqkewy6xtl: 5.1%
- kaspa:qrxw3rn59vdj3lfd7wne96dxv5fvge25n0rdx4psaz06qpep6g33z77mw2343: 4.5%
- kaspa:qrrw4vmfgkd4jd3hvajn4cfmtycw2vu2gg303cclfsxj45h4w3v0xt3nqrl6e: 3.9%
- kaspa:qq9rfyltvv40kfhe8hux3gktee982ln55xgc9cyljl54q8n9ds84qgq9hq5p7: 3.0%
- kaspa:qrvqn64vxkcevdev6k2y49slxw4ls57cjzdqmqkcgh9wu7xmghk57v4ehla0t: 2.7%
- kaspa:qzd6sfx3a8gx3q0qjvsts0pc4gj62z8a4kdf6qcndq5fg42wwxpv6sv9ngmg9: 2.1%
- kaspa:qq9pp4328qqajddq0wdndf8ljarg5ed6dddtp2lf3sthf366kkdxkx6yszqmv: 1.8%
- kaspa:qrxkessyzxkv5ve7rj7u36nxxvtt08lsknnd8e8zw3p7xsf8ck0cqeuyrhkp0: 1.5%
- kaspa:qqzffjn32q670kat0huq5j0pcvk95r8j0am62c8fyzd6yr24tefaq758ug3tw: 1.2%
- kaspa:qz8lxq8cw4qq5xkv39egdhxjyspahexuj99xzcctnqr9wkjz2jfz72y6vvjkg: 0.6%
- kaspa:qrtfl46ue56yk8n45ugn9xsdvprfhs0n4a0nnltq7gve2hcm2l2ezzevkmxwm: 0.6%
- kaspa:qpy827u4r43hp36nu2w78dphwgzjr3e9xdwwvm7k7dalyhpfkr84qucn4ecud: 0.3%
- kaspa:qpg2xz8ust2sgwj2nnmp8gjpyqcncu0j4lxjr4h2szrvtrgp74kec2462g6j9: 0.3%
¶ How to find a public node?
The Kaspa Community hosts multiple DNS seeders, a node resolver, and multiple Kaspa nodes, the whole constitute the Public Node Network (PNN).
Start by finding one DNS from here (example: sean.kaspa.stream), then run a command line (in Windows: press Win+R, then type cmd and press Enter ) and run one of the following commands there in its console window:
nslookup sean.kaspa.stream
Each one should return a list of IP addresses. Each address corresponds to one of Kaspa nodes running all over the internet.
It is important to note that not every node is suitable for mining or operating a wallet. A node must have the RPC port open for these functions, which may not be the case for some or even all of the reported nodes. DNS seeders are primarily designed to provide a set of addresses for node syncing, and may not guarantee that the nodes are suitable for mining or wallet operations. For syncing purposes, a node only requires a specific p2p synchronization port (16111) to be open, not the RPC port (16110) necessary for mining and wallets. There are several ways to determine if a node allows for mining and wallet operations:
-
attempt to connect a corresponding utility to the node;
-
execute the
kaspactlcore utility with the following command line parameter:GetInfo -a -s <address of node>A successful response indicates that the node's RPC port is publicly accessible. This command also indicates if the node is synced (necessary for wallets and miners to function) and if its UTXO set is indexed (necessary for wallets to function).
Furthermore, it is advised to select nodes from these lists randomly. If everyone were to connect to the very first node provided by the first DNS seeder, that node might experience performance issues, dependent on its hardware, and could potentially crash due to the lack of hardware resources.
¶ How to know if node is synced?
- If the node is your own (a locally ran one): wait for multiple "
Accepted block ... via relay" messages in the console output. See also "Setting up a CLI node" article to know the synchronization stages. - If the node is a remote one: invoke a
kaspactl GetInfo -a -s <IP address of the node>command. You'll see a “isSynced” field among this command's output lines containing the value of either “true” or “false", which means the node is synced or not, respectively.
¶ Is there a way to have a profit from running a node? Can I run a master node?
No, all nodes are completely equal. Running a node enhances the connectivity of the Kaspa network and helps minimize delays during mining. It also provides autonomy and independence from third-party service providers when working with wallets.
¶ My node can't start, says error "...not in the selected parent chain", what to do?
Delete the node DB manually, or restart a node with a one-time --reset-db command line parameter, and let it resync from scratch. Don't forget to remove the --reset-db parameter before a next node start.
Note: As of Kaspad v0.12.2 this bug has been fixed. updating to the newest node version should stop the error from happening.
¶ Patents & Copyrights
¶ Is Kaspa tech patented?
Nope and it won't be.
Regrading the code: obtaining patents for anything goes against the ideology of open source, and Kaspa's code is open sourced, as well as of many of its ecosystem parts.
Research papers results aren't going to be patented as well, for scientifically-philosophical reasons of their creators.
Anyone going to try improving Kaspa ideas and techniques on their products are welcome to do so. It's just that this will require a very high level of expertise in many areas simultaneously, as well as consulting Kaspa theoreticians on many topics to be implemented correctly. So this will take much time and effort from the challengers, and, as a side effect of the result, will do a nice PR to Kaspa itself.
¶ Pre-History
For questions regarding Kaspa prehistory, DAGLabs details and stuff, see here.
¶ Tokens & PoS
¶ Are there going to be master nodes?
No, all nodes are equal. Kaspa totally isn't a PoS coin.
¶ Can I have a profit by running a node?
Nope, no direct profit. But it gives you the fastest ping for your mining, and a full control of the node and wallet functionalities: you won't have to seek for a public node with the RPC port open, and won't need to hope it's healthy, well-versioned and non-malicious. This way you are also strengthening the decentralization and stability of the Kaspa network in general.
¶ Delegators, anything else from a PoS universe?
No, purely PoW philosophy, Kaspa is Nakamoto's spiritual heir.
¶ Is staking possible?
No and it will not.
¶ Maybe NFT?
Nope. Maybe on L2.
¶ What is the Kaspa's contract address?
Kaspa is a L1 PoW coin, not a token, so no contract whatsoever.
¶ Why is Kaspa better than PoS coins that don't use much energy, are also "very fast", and have smart contracts?
Proof of stake (PoS) systems end up being much more centralized than many Proof of Work systems for the following reasons:
- PoS creates a "rich get richer" system -- the more coins you hold and stake the more voting power you have to create new blocks. These tokens also earn more coins through staking. Since these individuals don’t need to expend resources to stake (unlike in mining), they can simply increase their overall staking amount as they earn more coins from staking rewards, and exponentially grow their influence on the network over time, forever. With PoW systems you can't infinitely expand. There is a limited amount of energy / equipment / land leading it to be more decentralized also.
- PoS systems often have very few validators -- Many big name cryptocurrencies have as few as 21 block producers. A far cry from Bitcoin's thousands of nodes. This means it's much easier to get compromised. The main point of a cryptocurrency is to be immutable and decentralized otherwise it makes more sense to just use a database shared with 21 people.
Kaspa uses less energy than many other PoW coins because of the hashing algorithm used -- Optical Proof of Work
L2s are only becoming bigger and Kaspa will be able to support L2s and smart contracts in the future. It's important first to get a decentralized and secure base layer with less features. It's easier to build on top of secure bases than to make the base more secure after things are already built on it.
¶ Trading
¶ How to swap between ERC20 (Polygon), TRC20 (Tron), BSC20 (BNB) and other USDTs?
Use any large exchange: Binance, Kucoin or other, they allow USDT deposits and withdrawals in any networks independently.
¶ Why is Kaspa not on more Centralized Exchanges?
Kaspa is a community project. CEX (Centralized Exchanges) are open to list projects, but for a (usually) substantial listing fee. The community has previously funded some listings. But for now, it has decided to halt new fundings for new CEX listings. This does not mean we will not do it anymore in the future. Also, if an exchange should be adding Kaspa free of charge we are always happy to help.
¶ Wallet CLI
¶ How to import a wallet from a seed phrase?
Run kaspawallet create --import, then it will ask you for this phrase, and you will need to enter it, all 24 words at once, separated by spaces. It must be 24-words phrase that you've previously got from running kaspawallet dump-unencrypted-data, not a 12-words phrase from KDX or web wallet: these phrases are incompatible.
¶ My wallet balance is wrong, what's the matter?
Since it is the node that provides per-public-address balances for a wallet, it's 99.(9)% chance that some of that balances are calculated incorrectly. You should restart a node without --utxoindex flag, wait until it is fully synced, and then restart it with the --utxoindex flag. If it doesn't help then resync the node from scratch: remove datadir2 folder completely, start a node without --utxoindex flag, wait for a full synchronization, and then restart it, this time with the --utxoindex flag. Then check your balance.
Double check that you're using the same wallet as before, that you're not accidentally checking the balance for not the same wallet that was kaspawallet create-ed or --import-ed from a seed phrase. Make sure kaspawallet show-addresses shows you the same address(-es) you've been mining or receiving transactions to.
If it's still not ok, ask for help on a #help-wallet channel of Discord server.
¶ Why can't I send the desired amount of Kaspa?
The wallet says **"transaction mass of NNNNN is larger than max allowed size of 100000"**
The requested amount of Kaspa is collected into a transaction from the UTXOs (unspent transaction outputs) that you have at your disposal. If you got Kaspa by mining, then you have a lot of UTXOs of,say, 500 Kaspa each. But adding UTXO to a transaction requires a certain amount of memory to describe it, it is several hundreds of bytes. Yet the size of the transaction is limited, and the limit is 100000 bytes. This means that currently a transaction can fit not more that 84 UTXOs descriptions, so the guaranteed lower limit of Kaspa that could be transferred in one transaction is 84*500=42,000 Kaspa. But if you have larger UTXOs in your UTXO set (say, if you purchased some Kaspa from someone else), this limit might be much higher: it depends of whether the wallet will choose to use that UTXOs in your requested transaction (currently the CLI wallet chooses the largest UTXOs first).
If you want to send more in one transaction, you should manually "compound" your UTXOs beforehand: this is done by sending 42,000 Kaspa to yourself several times. You may send Kaspa to the same public address of yours that you've been mining too, it does not matter if the source and destination addresses are the same. This way you'll get several UTXOs of 42,000 Kaspa each instead of multitude of UTXOs of 500 Kaspa each. If you want to send even larger amount in one transaction, you can compound your funds even further, into, say, 1,000,000 Kaspa blocks before requesting the final transaction to the desired external address.
¶ Wiki
¶ How do I set the dark theme?
You can enable Dark/Light Mode by signing into your kaspa wiki account (wiki.kaspa.org) and under Preferences edit your Appearance setting to your choice.
¶ Mining
¶ Miscellaneous
¶ Isn't mining Kaspa bad for the environment?
Kaspa uses less energy than many other PoW coins because of the hashing algorithm used -- Optical Proof of Work -- to eliminate energy as the primary cost of mining and instead make it concentrated in hardware (capital expense-CAPEX) rather than electricity (operating expenses-OPEX). Ideally in the future mining would be done with lasers (not invented yet).
¶ What are some Algorithm Options?
See: Mining Algorithm Opinions
¶ Who are the top miners? How decentralized is the mining?
See here.
¶ Why some blocks have multiple coinbase outputs?
Q contd: Like this block.
Short answer (courtesy of @coderofstuff on Discord) : this block's coinbase transaction has 3 outputs. If you look at the parents of this block you'll see there are 3 of them. Dig deeper and look at the payload of those parent blocks and you'll see that the current block is paying out to the miner that's in those payloads.
A block's coinbase transaction pays to the miners if it's parents, not to it's own miner EXCEPT for cases where a block merges red blocks. When a miner merges red blocks, they take the payment that would've gone to the miner of that red blocks. The network does not pay out to miners of red blocks.
Detailed answer: see here for in-depth explanation of Kaspa mining reward system.
¶ Pools
¶ Why do I have many shares a minute the first minute after joining a pool, and then the shares acceptance speed drops significantly?
This is the way for the pool to know your real hashrate. The pool starts at low difficulty, then adjusts up the difficulty over time for each miner to find a few shares a minute. The pool difficulty does not affect profitability.
- Solo mining always uses the difficulty set by the network, which is adjusted to 1 block a second on average over all miners participating;
- A pool needs to always know your real hashrate and so it gives you less difficult tasks to process. Then it only chooses to further broadcast those of your solutions that fit the total network difficulty criteria — and you'll eventually have one, 'cause it is just a matter of luck for your solution to have a hash that's not simply less than the pool's difficulty, but, by accident, a network's difficulty too;
- But there is a tradeoff for a pool: lower difficulty per share means more shares and more accurate estimation, but on the other hand — more CPU wasted on network instead of validating miners' solutions;
- The heuristics most pool use is 10 seconds per share (or the minimum diff between diff for 10 seconds per share and network diff);
- To know what difficulty gets you 10 seconds per share requires an initial estimation of the hashrate (starting from some fixed starting diff) — that's why your initial accepted share rate is visibly higher.
¶ Open Community
¶ DIscord & Telegram
¶ I'm interested in becoming a moderator, how do I do that?
Becoming a moderator is not achieved through a proposal. It is a volunteer position and you are chosen by being a trustworthy member of the Kaspa community. Moderators are selected from community members who demonstrate commitment, time and effort to continually helping the server to be a respectful and wonderful experience for all. The best way to become a mod is to be here, help others, learn the ins and out of the community.
Being a moderator is a volunteer gig. Moderators are paid by the joy of having an awesome community and being able to help those new and old in the community.
¶ Projects (Wallets, Explorers, Apps, etc.)
¶ Flux
¶ What is the benefit from running Kaspa node on Flux?
Depends on the point of view.
If you're the Flux node owner (i.e. you have staked some Flux coins, 1000+, and have registered your PC/sever with 8GB RAM, 4 cores, 100 Gb SSD, 10 Mbps internet connection etc., what is it required there to be the Flux node), and someone's running a Kaspa node (kaspad executable) on your Flux node, then you're getting paid for that in Flux coins. That's your benefit.
If you, on the contrary, want to run a Kaspa node on the Flux network, using its cloud-like structure, then you're taking a benefit of having your Kaspa node run on a hot-reserved reliable distributed infrastructure, that guarantees you the stable and load-ready instance of running Kaspa node. You can mine to it then, or have it as a background service for your own mining pool (if you have one somehow), or your Kaspa node-based site or whatever. But you'll have to pay for it in the Flux coins, to the Flux system. As long as you pay (it will be about ~5$ worth of Flux per month for a Flux node configuration that's acceptable for a Kaspa node to run), you will have your Kaspa node on and running.
But there's no way you can gain any direct profit from running specifically a Kaspa node on someone's (or your own) Flux node.
¶ How to run Kaspa node on Flux?
Click here to download the guide from Kaspa official site.
¶ KDX
¶ How do I backup my KDX wallet?
In KDX and webwallet you should've written down the 12-words seed phrase that was presented to you at the wallet creation. If you did not do that you'd better create a new wallet, backup its seed phrase and transfer you funds to that wallet from the previous one.
¶ Is there a reason that transactions show in my wallet completely out of order?
They are not out of order. They are "sequential" from the standpoint of what the wallet sees. However, if the wallet is not online at the receipt of transaction, it might not see it when comes back online, furthermore, there is a 3-day pruning period following which it will definitely not see it. If that occurs the balance will just increase.
Perhaps we should record increasing balance as a "phantom" transaction 
, but we haven't done so (yet). The only way to access this data is via an archiving block explorer. Wallet or node can not track this data (it's too much data to keep as given high-speed of Kaspa, it produces gigabytes of data per week). Whatever transactions the wallet sees are stored in local cache, which also means that if the wallet is restored someplace else, the transaction data won't be there).
Technically speaking the wallet could be integrated with an archiving block explorer to fetch this data, but the community-ran explorer wasn't quite there when the wallet was made and at times is not very stable with accounts that receive a lot of transactions (I.e. mining) and we can't really make a server-side caching solution because it would require kaspad node to be always online, which can be done with some redundancy but is very complicated.
¶ Is there an option that the KDX wallet will not use dozens of GBs of the disc space?
Click the "Reset data directory and resync" button (see the screenshot) each time you feel the KDX has become too fat. Say, every couple of weeks. It will resync its database from scratch. This operation won't affect your balance, but maybe you'll have to give KDX some time to find your balance back, see "Why my KDX balance is wrong?".
"Delete data directory and resync" button
¶ My KDX refuses to start, how to fix it?
- Uninstall it;
- Remove the following folders completely:
%localappdata%\kdx,%userprofile%\.kdxand%programfiles%\Kaspa\KDX; - Reinstall it.
If there is any recommended patch to Kaspa core files exist (see Discord server's #announcements channel), download it and replace the appropriate files in the %programfiles%\Kaspa\KDX\bin\windows-x64 folder.
¶ Specific Errors
[ERR] KASD: Unable to start kaspad: not found
Probably KDX started two kaspad processes. They are fighting for the resources or something. Try to forcibly close one of them.
¶ Other ways to deal with KDX/web wallet troubles
For the web wallet:
- Try Ctrl+Shift+I to bring up dev tools and then right click on reload button and select last option "Empty cache and hard reload"...
For KDX:
- The only really available options to see the correct KDX balance are: restarting the application, clicking Scan more addresses in the Debug sub-tab of the Wallet tab, and resyncing from scratch by the "Delete database" button in the Settings tab, when its Advanced mode checkbox is checked. Usually a combination of the first two eventually helps.
¶ My KDX wallet balance is wrong, what's the matter?
Try importing your mnemonic into the online wallet or running KDX 2.8.7 and manually purging the data folder in ~/.kdx. Previous versions of both node and web wallet software libraries had various issues that so far have all been identified and resolved.
If this is a wallet used with an older version of the wallet libraries, try (in KDX or web wallet) going to the DEBUG tab and clicking Scan More Addresses. For example, the earlier version of kaspad had a glitch that could cause some transaction outputs to become not visible to the application layer. Web wallet also had some issues, one of which was new address generation during fee preview calculation in the "Send" dialog, which are really hard to replicate and thus hard to debug.
Generally, because of how wallets work, i.e. they derive a chain of addresses from your private key, the loss of funds is very unlikely. You have to either lose your private key or have your system compromised security-wise.
notice from 2021.01.11: with the latest version of NodeJS and the JavaScript CLI wallet is failing to start with nodejs giving the following error: Error: error:0308010C:digital envelope routines::unsupported This doesn't happen on previous versions of NodeJs. If you end up in this situation, until this is resolved, to mitigate, please run export NODE_OPTIONS=--openssl-legacy-provider (on macOS/linux) or set NODE_OPTIONS=--openssl-legacy-provider (on windows) before running kaspa-wallet. This applies only to the JavaScript CLI wallet, not the native Golang CLI wallet shipped with kaspad.
¶ What does "Compound transactions" do when clicked in the KDX/kaspanet.io wallet?
If you pressed it, did you lose your coins? Absolutely NOT. It might however take a few seconds or even minutes for them to be visible again. Click "scan more addresses" to speed up the process. See also "Other ways to deal with KDX/web wallet troubles" topic down here on this page.
Long answer:
It combines your many small UTXOs (unspent transaction outputs) acquired by mining or buying of whatever was the way of receiving Kas, into less number of larger UTXOs. Actually it tries to combine as many UTXOs of whatever size as possible into larger UTXOs.
This is useful because when you try to send some Kaspa via a transaction, the amount you want to send must be gathered of these UTXOs — say, 1500 Kas will be described as "take coins from this, this, and this UTXO of 500 Kas each and send them to following address: []". Yet describing each UTXO requires about 1 kb of data to be inserted into the transaction body, and the maximum size of the transaction body is 100 kb. Thus you can only put about 85 UTXO descriptions into 1 transaction. And this limits the amount of Kaspa that you can send via 1 TX by the number of coins in UTXOs you have in possession.
Sometimes your compounded coins could have seem lost, as they're not reflected on your KDX balance immediately. But there's nothing to worry about, it's simply that KDX/web isn't aware (yet) of the balance of the address the coins were sent to, but it will over time. You may though need to click "Scan more addresses" button in the Wallet tab for KDX/web to know about the appropriate address's balance. The reason is, KDX/web wallet is the HD-type wallet that can have a vast amount of private/public key pairs (addresses) chain-generated from a single seed phrase, and when the coins are compounded, they are sent to one of the next addresses in the address derivation chain. Sometimes this address lies beyond the set of addresses that KDX/web is currently aware of, so "Scan more addresses" is needed to generate more addresses, beyond the limit that's currently known to KDX/web, and check if any of them have any non-zero balance, to reach to the address that the compounded coins were sent to.
¶ Why am I getting error 'Rejected transaction ...: Transaction ... is orphan, where allowOrphan = false' when trying to compound. What should I do?
Up to at least version 0.11.17 inclusively there's still a bug in the kaspad that eventually prevents both KDX/web and CLI wallets from sending and compounding coins after a certain number of such operations.
In the newer versions of the KDX there's a "Reindex UTXO" button that fixed this problem for a certain while. Use it again whenever necessary.
Historical ways to fix it are the following: faster but more complicated way is to
- stop KDX completely (not letting it continue running in the background);
- start a CLI node and make it chew up KDX's node data folder (i.e. start it with a parameter
-b %USERPROFILE%/.kdx/data/kaspad-kd0) while being run without the--utxoindexparameter, to reset the utxo indexing data in that folder; - wait for the CLI node to start "Accepting blocks...", stop it;
- and start KDX again.
But that requires a bit of a hand work.
Slower but easier way is to:
- stop KDX completely (not letting it continue running in the background);;
- open the Windows Explorer window, put a
%USERPROFILE%/.kdx/data/kaspad-kd0line in its address bar, press Enter; - you'll get into the KDX node data folder, delete it;
- start KDX again.
Voila!
¶ Why does my address in KDX change every time?
It's for increased security of your privacy, so no one could link your different payments (sent or received) to a single entity, i.e. you. It is also changed because once you have used an address to send or receive funds, it is considered to be weakened cryptographically by 2/3rds, so this is a standard practice for UTXO-based chains like Bitcoin, to which Kaspa belongs as well. The KDX changes the address every time it detects it is used, but it doesn't invalidate these addresses, they keep being absolutely functional, specifically you can continue mining to the same address as before, regardless of what KDX currently shows you.
This is also true for the web wallet: KDX and web wallets share the same codebase in many aspects.
Basically, a new change address is generated whenever coins are going off that address, and the amount being sent (+its fees) isn't strictly equal to the sum of UTXOs used in tx
The remnants of that sum - the change - is sent back to the wallet but not to the address of the origin; instead it's sent to the newly generated change one, that is related to the origin one in the sense of keys derivation sequence.
¶ Why is my KDX balance wrong?
Tracking the balance of the HD wallet is somehow complicated task in Kaspa, so sometimes KDX reaches certain limits in the search process and needs some user help.
The only really available options to see the correct KDX balance — after waiting for the DAG to have been 100% synced — are:
- restarting the application;
- clicking "Scan more addresses" in the "Debug" sub-tab of the "Wallet" tab (give it time to process, it scans 10,000 new addresses), and
- resyncing from scratch by clicking the "Reset data directory and resync" button in the Settings tab, when its Advanced mode checkbox is checked (normally syncing takes not more than 2 hours, usually much less).
Basically a combination of the first two eventually helps.
¶ Other
¶ Kadena
Given the numerous questions regarding the variances and similarities in the approaches to DAG of Kaspa and Kadena, one of Kaspa's theoreticians, Shai Wyborski (@deshe), conducted a comparative analysis of the solutions provided by Kaspa and Kadena, and shared the findings in a series of tweets. For ease of access, here is the complete text from that thread:
Recently I see a lot of buzz around the comparison of $kas and $kda.
While I do not think small cap projects should compete, I feel urged to clarify why I believe that, ultimately, $kas is the superior tech. Keep in mind that I am naturally very biased in favor of Kaspa having spent a decent part of the last four years helping develop it. I will do my best to keep my bias in check and be as impartial as possible, but I'm only human.
I also want to stress that I mean no disrespect for the $kda team and tech. They are esteemed researchers and colleagues whose work I appreciate greatly. In cryptocurrencies there are no solutions, only trade-offs, and I want to explain why my personal opinion is that Kaspa's trade-offs are better.
I think the main disadvantage of $kda is in its sharding. Sharding essentially means that each chain on chainweb is an autonomous economy. The way Kadena interconnects the chains means that in order to double spend in any of the chains, an attacker must be computationally comparable to all chains combined. That is a very neat feature, as it allows to make many parallel chains without compromising security. The huge disadvantage is that, since any chain is an autonomous economy, the latencies of the network are the latencies of each chain. It might be the case that the Kadena network creates 100 bps on 10000 chains, but in order to spend a transaction, you have to wait for a block on a particular chain. Each chain individually still has to be secure and is thus subject to the usual limitations of Nakamoto consensus, especially that the block delay must be orders of magnitude longer than the block propagation delay. This means that, no matter how Kadena is scaled, the long confirmation times remain fixed. This also means that every application developed on the Kadena network must run independently on any chain (or, run it on one chain, but then users must spend their money to that chain before they can use the service). This means that while kadena manages to scale bps, it cannot scale services or response times.
Kaspa, on the other hand, has none of that. The network is not sharded and the consensus protocol doesn't require any form of block delay to remain secure. This is why we already see Kaspa provide much shorter confirmation times while creating more blocks.
The main (perhaps only) advantage of kda over kas is its L2. They have a smart contract infrastructure called Pact which seems interesting enough (though I am not a smart-contract developer so I can't really tell). This makes it more readily adoptable. The crux is that it is possible to develop smart-contracts and other L2 applications on $kas, and I believe this will happen in due time. On the other hand, $kda could never achieve the responsiveness of Kaspa without completely redesigning their consensus layer (whereby actually becoming a different tech), which is why I think Kaspa is the superior tech.
Furthermore, later, on July 3, 2023, Shai published this document where he mathematically proves that Kadena does not scale.
¶ Archival FAQ topics
Visit this page to see what questions were asked frequently enough one day to be even added to this Wiki.