It does have generally accepted logography, colors, and fonts, you can find them on the media kit on the kaspa.org.
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 a aged metal coin.
You can find it on: github.com/kaspanet
The list of transactions of a certain address in Katnip only includes the incoming ones, that fill the balance of the address. But outgoing transactions that spend coins from that address are not shown in the list, so if some of coins have already been spent then the address balance will apparently be less that the sum of balances of incoming transactions.
To know if this or that of the transaction outputs have been spent you should click the ID of that transaction in the list and look for the
Spents (N) line in the transaction description header on the appropriate explorer page, where
N is the number of subsequent transactions that were spending UTXOs of the transaction in question. If there is that line then at least one of the UTXOs of that transaction has been spent, and that's the reason of the difference between the address's balance and the sum of transactions.
Generally the old explorer still knows the best 'cause it's keeping its own transactions database that's not pruned, while the beta explorer does not yet. And the KDX node is pruned every day so to keep only the last 3 days of transactions, so if you strop the KDX for more that a day you're risking of losing some transactions info (not your balance though, it's taken directly from the node by per-address basis).
There may be two reasons for this, but both are of the similar nature.
It may be that you are mining solo and see, say, 3 entries about the reward for the found blocks in the explorer. But at the same time, the balance on the address is equal to the sum of rewards for just 2 blocks. The question is, what to believe?
This happens because the Katnip does not fully take into account the Kaspa block reward logic. The payout for the block you found is not given to you by the block you found, but by the blocks following it — those that made your block their parent. Each of them gives you a reward for the found block, but in the end, after the network reaches a consensus regarding the position of your block and its descendants, only one of these reward transactions remains valid — the one that executed by the block which turned out to be the element of the so-called selected chain, the "barebone" of the DAG. The remaining reward transactions are discarded, and the rewards accrued by them are not taken into account by the network (for more details, see Merging and rewards).
However, the explorer does not monitor the consensus state, because
And the node in its current version does not provide the explorer with such information in a convenient form.
Therefore, you can see records for all transactions in the explorer, both those that were recognized as valid, and those that were eventually discarded. They're reflected in the list of transactions, and you can't tell from there which one is the valid in the end and which is not.
But the address balance in the explorer is taken from the node, where all these nuances are taken into account, so in the end it's the balance that is the true indicator of the number of coins you have at your disposal.
No. At least not yet.
When it becomes the ultimate L1, someone, or many someones, will implement L2 smart contracts over it. The Kaspa community will eventually provide any L1 support needed for a well thought design of L2.
L2 and smart contracts implementation discussions are led in the #smart-contract-brainstorming channel of the Kaspa Discord server.
Because a wallet contains many addresses. This is by far not unique to Kaspa. Practically all Bitcoin wallets are HD wallets that automatically derive a fresh public address for each transaction. While it is true that there is some address reuse, it is considered best practice to only accept funds to an address once. The number of non-empty addresses typically increases quite fast, as in the common case the amount of money you transfer is smaller than the amount of money in the output you spend, so the difference is spent to a new change address, thus one address spent makes two new addresses.
There's a separate article about it.
No and won't become in the near future. See Shai's explanation.
As of August 21, 2022 there are around public 70 nodes active. There is an unknown number of node not accessible from outside (personal-use nodes).
As of August 8, 2022 the top miners are as follows:
1) kaspa:qr36zdxs0dn3n0h799jhdl02qks5742lxjgmfsfj9xmlca7n4l6mw0s0n48nx: 21.5%
2) kaspa:qrk9decfnl4rayeegp6gd3tc6605zavclkpud5jp78axat5namppwt050d57j: 18.9%
3) kaspa:qp0l70zd5x85ttwd6jv7g3s3a8llzj96d8dncn4zmhv4tlzx5k2jyqh70xmfj: 17.2%
4) kaspa:qqg0m2cq9nls4s2mlj9estz6v947l8j6vmcvv4057clh688088ftg7ce6p895: 15.2%
5) kaspa:qpay7sfnmw89n5sh6ltruc0v2kushh765nadgtn62562aslrt5632l78dclyw: 13.5%
6) kaspa:qzspny3tg0hda6nm7xl669knxxrtmr5mdtdf02z867875y8v8uy8yuq4xhd0j: 1.7%
7) kaspa:qpgq93dckz9ljp47qmlzuz67ltzsh6ad0qc5723qn23r666d52cr6jzznu332: 1.3%
8) kaspa:qpgjypq0jeuc5rc594y6vn7k7qkz3d7zttgty98h79khrt7ppnhfxjzh0p86a: 1.0%
9) kaspa:qrgl5h07jxwgcsm6tk80f9dpl4hllmwht5klnctanuhslcmcjv0evda89hg4t: 1.0%
10) kaspa:qzp4pmk70mk29a0mw0phuyj0qq74haemdu4v58yjl03fellmveyzu40f89w5e: 1.0%
11) kaspa:qq9lfv6r3pjfqgj7gfz2uveymgmh93t8wu8v3ua7p2u022kx825cwr9zpcaqf: 1.0%
12) kaspa:qz4rrvhdjqr0ku0kg76mwka8vy0mupuz9h8dkhmvle4le37wqmk22u0ny9nfn: 1.0%
13) kaspa:qp4layahzqfwwlcx5vssr7dujzutsylhu4uag5qkzzhh0sqvkpq7g7ak9g73q: 1.0%
14) kaspa:qqxzjspnt2hcesglpennw0x946dg7fejgfukyur26hz3gzkus6rgvp7hhveje: 1.0%
15) kaspa:qphfhh2ukva9n5kd0n0ps0femfwjqug6m65mx5ax49jemrjqvm757vds26k6x: 0.7%
16) kaspa:qrj4n2rcmuwv00cz07rdkdkxrtvwsqruc0s6z5q4rh9t8nunsx632qra7jue0: 0.7%
17) kaspa:qqqxuxsr3hu73durn84tyt8ykdkzty0l4x2y4shdtfk923wr2dcrjau9vh7hz: 0.7%
18) kaspa:qzqd8agc7sfm3je5l7agsj8klalxenjn287rha5xyxnlcv3h3nde2vtdleyyr: 0.3%
19) kaspa:qztf0v29fl3y27njgu5kt2veq9zp6u33qugskaue4qjzyv07ptzqqrq2snxyt: 0.3%
20) kaspa:qpl66y2dg2lxv7vgeuq2tfqfvevxp984sxnqnwgd472cwzyxekw6j3wjxh0mt: 0.3%
Run a command line (in Windows: press
Win+R, then type
Enter ) and run one of the following commands there in its console window:
Each one should return a list of IP addresses. Each address corresponds to one of Kaspa nodes running all over the internet.
Note that not any such node is suitable for mining on it: mining requires node to have the RPC port open, and this may not be the case for a given node, because DNS seeders are only designed to provide to the newly syncing node the addresses to sync from. And for that the syncing source node must only have another specific p2p synchronization port opened (16111), not the RPC one (16110) that is required to operate with both miner and wallet. The only way to know if node allows mining is to try to connect a miner or a wallet to it.
As of kaspad v0.12.1 it is also possible to run the
GetInfo -a -s <address of node>, if you get a response it shows the rpc port is open to the public, the command also displays if the node is synced and utxo indexed, if the queried node is of v0.12.1 or later.
Also please try to choose a node of these lists as randomly as possible: if everyone would start mining at the very first node that the very first DNS seeder gives out, that node would most probably be slowed down significantly, and may even crash. At the very least you'll have a strange errors appearing in the miner, mining (your and the others') will become unstable, and so this would be to everyone's disadvantage in general.
You'll see multiple "
Accepted block ... via relay" messages in the console output. See also a "Setting up a CLI node" article to know the synchronization stages.
No. All nodes are absolutely equal. Running a node increases the connectivity of the Kaspa network and allows you to have a minimal delays when mining.
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.
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.
What's the history with mining hardware bought by DAGLabs, according to @Hashdag's Meduim article?
Question: Hashdag wrote in Medium article that they bought 'mining equipment' for the PoW to have an early advantage. What it was, why there's no any additional info?
Answered by Ori Newman:
Where was no specific answer given because the mining algorithm has no name. We just tried to cooperate with a mining company and develop an algorithm that will be very easy for them to develop ASICs for. I can guarantee to you that it had no slight relation to the current used mining algorithm (k-heavyhash).
Less than 3% of the total supply (840,000,000 KAS). See here
Shai Wyborski and Michael Sutton have put together an elaborate step-by-step guide to locally cryptographically verify the chain integrity. Anyone who has concerns about the integrity of the chain (or is just looking for a fun way to spend an afternoon) is welcome to follow. That tutorial is available either in the form of a Jupyter notebook or a PDF. The steps therein allows anyone to cryptographically verify that:
When Kaspa was designed (before the mainnet launched) the team thought that oPoW would be valuable in reducing waste and saw the potential in it and how it could potentially be more decentralized than the current ASIC mining. oPoW is also as secure as SHA256. The value proposition of energy-efficiency will materialize only when specific optical hardware became a thing, until then community members can still mine with CPUs/GPUs. To develop the hardware for this a external group (not connected to Kaspa) needed funding and funding required a live network to sustain it. Kaspa volunteered to be that network (made the first move). Later on the group developing hardware for oPoW dissolved and DAGlabs as a for profit entity also dissolved. As a result there was ultimately no premine or hardware specific to the developers or any insider group. Anyone could mine equally when the network launched (see above answers). Additionally the developers alone didn't just choose to use oPoW ,the community voted on it before the mainnet launched.
Answered by Yonatan Sompolinsky:
DAGLabs raised overall roughly 8M$.
The project's initial business plan was to develop OPoW-like ASICs and sell and distribute their hashrate, as I described in some medium post. I thought of it as a good middle ground between decentralization and sustainability.
The fact that this plan failed is indeed a failure of DAGLabs as a for profit entity. The reason it failed was a combination of the immaturity of OPoW ASIC tech, and (my, together with Polychain's) assessment that pure fair launch is the only path to give Kaspa (and, in fact, any PoW coin) true chance at growing to meet its goals/dreams.
If you think Polychain's support of this is weird or even suspicious then you probably hadn't had the chance to engage with crypto VCs. As I said in Kaspa's Telegram group, crypto space has seen way more bizarre instances than a VC supporting fair launching over no launching.
See also screenshots.
Additionally, when the Kaspa mainnet went live in November 2021 there was already a decent size community. Anyone could have mined at that time.
No, all nodes are equal. Kaspa totally isn't a PoS coin.
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.
No, purely PoW philosophy, Kaspa is Nakamoto's spiritual heir.
No and it will not.
Nope. Maybe on L2.
Kaspa is a L1 PoW coin, not a token, so no contract whatsoever.
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.
Yep, here's the PDF. Notice the actual dates might swing a bit due to the network conditions: the start moment of every next phase is based on a predefined DAA score value, and the moment of achieving of one or another value of DAA score may deviate from its estimated date and time because of the total network hashrate fluctuations and thus the block generation pace fluctuations.
Currently the TX fee is calculated as 0.0001 Kas per UTXO.
No. Only a publicly declared fair launch.
Nah. Fair launch model, a Nakamoto's philosophy.
The monetary policy has two phases:
Note that the policy dictates how many coins are minted per second regardless of the block rate. Should the block rate change in the future, the reward will be adjusted accordingly to maintain the same emission rate.
Here are some numbers:
The last estimation is correct while the blockrate is kept as is, namely 1 BPS. Otherwise the time of zero reward will be shorter for log2(new BPS) years, say if 32 BPS is established, the new zero-reward date becomes 36 – log2(32) = 36 – 5 = 31 years from the mainnet start .
Approximately 28.7 billion KAS which is a fixed supply with no plans to increase.
tl;dr: In a nut shell, the hard cap in the code is 29 billion but overall supply is an estimate, due to the halving schedule being on daa scores, rounding, original gamenet random rewards, and possibility for emission to reduce with faster block rates.
So to conclude, the total emission may change within some small limits, but it is guaranteed to never reach 29 billion, and the most accurate value that is available for evaluation is given by the bot in the discord:
28,704,026,601 KAS in the period of 36 years from the mainnet start (November 07, 2022).
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.
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.
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.
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.
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.
You should have a proper GPU driver installed. Having only CUDA toolkit installed is not enough; moreover, CUDA toolkit is not required unless you're planning to recompile a miner's .cu files.
Make sure your drivers are newer than the minimal supported drivers
Lower you overclock settings, check GPU temperature, update your GPU driver to the latest version. This may seem totally unrelated but surprisingly really helps.
Make sure you don't have two computers with the same name (like
HOME-PC) on your network: sometimes the router's DHCP system settings require that addresses be updated every, say, 2 hours, and the presence of PCs with the identical name causes problems in the IP address re-assignment process. If possible, set a (different) static IP address to each of your rigs.
GPU thread ... crashed: "an illegal memory access was encountered"message
This is usually due to a too high overclock setting, try lowering you GPU OC values.
This seems to be something to do with GPU power saving settings. It is suggested to run "Paint 3D" or some OpenGL enabling application in this case, that should address the issue.
It is possible (use
-t <number of CPU cores to mine at> syntax, i.e.
-t 4) but it doesn't really make sense: CPU mining gives you about +1Mh/s per core, while with even as low-grade a GPU as 1050Ti you're getting around 100 Mh/s on it alone. It can also significantly reduce your GPU mining speed if you have few cores (e.g. 2) and several GPUs: it takes a certain amount of CPU power to manage and load GPU threads, and CPU mining aggressively consumes this resource.
You can try running one miner instance per GPU to have as many miner instances as there are GPUs in the rig. Use the
--opencl-device) option to specify which miner instance controls which GPU in the rig.
The default value (16) is good enough albeit a bit conservative. You may choose to set a higher value, which increases a hashrate (people use values up to 4096), but there comes a question: increasing the workload for a little more hashrate has a tradeoff on submission latency, because work chunks are less granular. Latency of say 0.5 sec usually will not effect the blueness of the mined block, but does reduce the chance of being a chain block, thus reducing the chance of merging red blocks and earning their reward. So the system in essence incentives maximal responsiveness (minimum latency). Thus the optimal value lies in the range of 256...1024.
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).
Consider every time the DAG changes to be a job. This job is updated on average every second. When the user specifies for instance 1% to dev fund, then every 100 jobs the miner mines one job over the dev fund address. If it finds a block during that time, that block's reward goes to dev fund.
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.
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.
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.
Click here to download the guide from Kaspa official site.
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.
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.
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?".
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
[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.
For the web wallet:
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.
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
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.
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 <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.
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
-b %USERPROFILE%/.kdx/data/kaspad-kd0) while being run without the
--utxoindexparameter, to reset the utxo indexing data in that folder;
But that requires a bit of a hand work.
Slower but easier way is to:
%USERPROFILE%/.kdx/data/kaspad-kd0line in its address bar, press Enter;
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.
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:
Basically a combination of the first two eventually helps.
Since there are many questions of what are the differences and similarities of Kaspa's and Kadena's approaches concerning DAG, one of Kaspa theoreticians, Shai Wyborski (@deshe), conducted a comparative analysis of the solutions offered by Kaspa and Kadena, and issued the result in the form of a thread of tweets here. For convenience, here's the full text of 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.