¶ 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.
¶ 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.
¶ 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.
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.
¶ 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).
As of September 21, 2024, the top miners are as follows:
1) kaspa:qpamkvhgh0kzx50gwvvp5xs8ktmqutcy3dfs9dc3w7lm9rq0zs76vf959mmrp: 33.9%
2) kaspa:qrk9decfnl4rayeegp6gd3tc6605zavclkpud5jp78axat5namppwt050d57j: 21.9%
3) kaspa:qqc3a2j95vhn9jlq9d87mexyg7dwc0lvnyvzwypgwk9hx00h44krvlhf85g4q: 9.6%
4) kaspa:qquu5ypnp3n0za4uu3dh89rftgnjzmlc3p4czx4la4nqd4lnw2n65fsq8y8le: 6.9%
5) kaspa:qp9rv9jvx2kyf6wu4lupuruunq5zsuszyxs0dr3l89ej7wsgs48jqkewy6xtl: 5.1%
6) kaspa:qrxw3rn59vdj3lfd7wne96dxv5fvge25n0rdx4psaz06qpep6g33z77mw2343: 4.5%
7) kaspa:qrrw4vmfgkd4jd3hvajn4cfmtycw2vu2gg303cclfsxj45h4w3v0xt3nqrl6e: 3.9%
8) kaspa:qq9rfyltvv40kfhe8hux3gktee982ln55xgc9cyljl54q8n9ds84qgq9hq5p7: 3.0%
9) kaspa:qrvqn64vxkcevdev6k2y49slxw4ls57cjzdqmqkcgh9wu7xmghk57v4ehla0t: 2.7%
10) kaspa:qzd6sfx3a8gx3q0qjvsts0pc4gj62z8a4kdf6qcndq5fg42wwxpv6sv9ngmg9: 2.1%
11) kaspa:qq9pp4328qqajddq0wdndf8ljarg5ed6dddtp2lf3sthf366kkdxkx6yszqmv: 1.8%
12) kaspa:qrxkessyzxkv5ve7rj7u36nxxvtt08lsknnd8e8zw3p7xsf8ck0cqeuyrhkp0: 1.5%
13) kaspa:qqzffjn32q670kat0huq5j0pcvk95r8j0am62c8fyzd6yr24tefaq758ug3tw: 1.2%
14) kaspa:qz8lxq8cw4qq5xkv39egdhxjyspahexuj99xzcctnqr9wkjz2jfz72y6vvjkg: 0.6%
15) kaspa:qrtfl46ue56yk8n45ugn9xsdvprfhs0n4a0nnltq7gve2hcm2l2ezzevkmxwm: 0.6%
16) kaspa:qpy827u4r43hp36nu2w78dphwgzjr3e9xdwwvm7k7dalyhpfkr84qucn4ecud: 0.3%
17) kaspa:qpg2xz8ust2sgwj2nnmp8gjpyqcncu0j4lxjr4h2szrvtrgp74kec2462g6j9: 0.3%
¶ How to find a public node?
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 n-mainnet.kaspa.ws
nslookup kaspadns.kaspacalc.net
nslookup mainnet-dnsseed.kas.pa
nslookup seeder1.kaspad.net
nslookup seeder2.kaspad.net
nslookup seeder3.kaspad.net
nslookup seeder4.kaspad.net
(see the most up-to-date list of available DNS seeders at https://github.com/kaspanet/kaspad/blob/master/domain/dagconfig/params.go#L218)
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
¶ DAGLabs existence, actions and earnings history
- DAGLabs founded in 2018 by Yonatan Sompolinsky and backed by (mainly) Polychain and (lesser) Accomplice and Genesis Mining investments in the amount of 8M$ to implement GhostDAG protocol in the opensource code of the coin, and to develop (and later sell and lease) an optical ASIC mining devices for that coin;
- by the mid-2021 it was decided there's no sense to continue funding the development since optical ICs are not ready for a factory-grade implementation and in general the interest to PoW coins is ceased in the cryptosphere, so by the agreed decision of Polychain and DAGLabs the project is henceforth stated as "owned by the community" while DAGLabs and Polychain waive any intellectual property rights;
- by the start of the mainnet (2021 Nov 07) DAGLabs still exists but in the half-sleeping mode, supporting several developer on a part-time basis and waiting for the mainnet launch;
- after a launch DAGLabs starts mining on the common grounds, slowly spending the remnants of the initial funding (in the amount of several hundred thousand USD) to mine Kaspa on a rented Amazon HW;
- by late-December the GPU miner is written by the community member @hauntedcook (and then later also in cooperation with @demisrael), so DAGLabs switches to another type of rental HW;
- mining on rented facilities lasts for about 5 months, after which the finances are finally exhausted;
- these mined coins, in the amount of not more than 3% (probably close to 2.5%) of the max supply (i.e. obviously <850M Kas) are shared between investors (Polychain at al) and the former employees, advisers etc of the DAGLabs in some proportion;
- DAGLabs is officially closed after that (took some time to dissolve a legal entity; wasn't operational at all during that time).
Source links:
https://discord.com/channels/599153230659846165/916662870379491328/1046886450601398393
https://discord.com/channels/599153230659846165/916662870379491328/996761363894509568
https://discord.com/channels/599153230659846165/909907923084382218/996054649410953226
https://discord.com/channels/599153230659846165/909907923084382218/996047610651627551
https://discord.com/channels/599153230659846165/909907923084382218/995774105712337026
https://discord.com/channels/599153230659846165/916662870379491328/991123684385361951
https://discord.com/channels/599153230659846165/916662870379491328/990897783475163136
https://discord.com/channels/599153230659846165/916662870379491328/990893756591001640
https://discord.com/channels/599153230659846165/916662870379491328/990739452622163989
https://discord.com/channels/599153230659846165/916662870379491328/990736859791523850
https://discord.com/channels/599153230659846165/916662870379491328/955793396268687380
https://discord.com/channels/599153230659846165/610815395527393301/954060451145203813
https://discord.com/channels/599153230659846165/610815395527393301/953621816205799445
https://discord.com/channels/599153230659846165/916662870379491328/939960107771518996
https://discord.com/channels/599153230659846165/916662870379491328/939913692722659358
https://discord.com/channels/599153230659846165/909907923084382218/924705390309019720
https://discord.com/channels/599153230659846165/916662870379491328/920271238088253450
https://discord.com/channels/599153230659846165/909907923084382218/911015989792108574
https://discord.com/channels/599153230659846165/599153231305637890/907943846699204621
https://discord.com/channels/599153230659846165/599153231305637890/906770708586197002
https://discord.com/channels/599153230659846165/599153231305637890/895617582856548372
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).
¶ How much Kaspa does DagLabs or Polychain capital have?
Less than 3% of the total supply (840,000,000 KAS). See here
¶ Where is the transaction history prior to March 2022?
- There are attempts to piece together people's data directories and add it to the explorer. It exists in bits and pieces; it's just not linked with the block explorers right now.
- Even in the unlikely chance that all the data is never found, it doesn't mean it's insecure. All UTXO data is guaranteed to be updated properly at any moment so all transactions that ever happened are still valid (as there are rules to check at any moment). Proof of Work accumulated work proofs are kept forever.
- There is a genesis and a proof-of-genesis that allows you to verify that the current UTXO set is legit. If you wanted to, you can use the UTXO set to view all the balances in all accounts.
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:
- The current state of the Kaspa chain evolved from an empty UTXO set;
- The original genesis (from Nov' 7, 21) and the post-restart genesis (from Nov' 23, 21) were not created earlier than claimed (proved via including a commitment to the most recent Bitcoin block in both of them, which is a cryptographic version of posting a picture with today's newspaper).
¶ Why was the HeavyHash (oPoW) mining algorithm chosen? Was it so the devs could premine and control any hardware?
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.
¶ Why Kaspa is a fair launch coin when its theoretical research was funded by Polychain? Why did they leave? Is Kaspa a scam?
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.
¶ 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.
¶ Tokenomics
¶ Is there a halving phase schedule table?
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.
¶ Is there any kind of fees?
Currently the TX fee is calculated as 0.0001 Kas per UTXO.
¶ Was there any type of ICO, vesting phase or something like this?
No. Only a publicly declared fair launch.
¶ Was there any kind of premine?
Nah. Fair launch model, a Nakamoto's philosophy.
¶ What is the monetary policy?
The monetary policy has two phases:
- The pre-deflationary phase, that started at the mainnet start, Nov 07 2021, has already ended (at May 08, 2022). Reward rate was firstly random, in a range of 1 to 1000 Kas per block, for the first 2+ weeks, and then was replaced with the constant one at the 1st hardfork: 500 Kas per second. Since a blockrate was also 1 per second, that essentially meant the reward was 500 Kas per block. This stage lasted for 6 months.
- The chromatic phase started after that. In this phase block rewards geometrically decrease. The initial block reward was 440 KAS. The block reward halves once per year, but smoothly: every month, block reward is decreased by a factor of (1/2)^(1/12) (this means that the ratio of block rewards in consecutive months is exactly the same as the ratio of frequencies of two consecutive semitones in a tempered chromatic scale. The initial block reward is the frequency of the note A4, and every averaged year is hence called an octave). Here, a year (or an octave) is 365.25 days, and a month (or semitone) is exactly one 12th of a year.
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:
- by January the 1st, 2023, about 15.3B Kas had been mined (53.3%);
- by January the 1st, 2024, about 21.9B Kas will have been mined (76.3%);
- by January the 1st, 2025, about 25.1B Kas will have been mined (87.4%);
- by July the 10th, 2026, about 95% of all Kas will have been mined;
- it will take about 36 years since the mainnet start for the block reward to fall below 1 Sompi (= 10-8 Kas = 0.00000001 Kas) that will on practice mean the reward is 0 from that moment on, since no value below 1 Sompi is expressible in Kaspa.
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 .
¶ What is the total supply?
Approximately 28.7 billion KAS which is a fixed supply with no plans to increase.
¶ Why am I seeing different max supply's in different places?
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 stage” random rewards, and possibility for emission to reduce with faster block rates.
Elaborated:
- There was a "random reward subphase" during the first 2 weeks of the mainnet, where the block reward was pseudorandom in the range of 1..1000, with the expected average value of 500. But it turned out the average was more like 750 instead (still distributed randomly between miners though), hence about +300M to the estimated supply of the "stable reward" phase;
- The halving schedule is bases on DAA score calculation, an since in realtime the DAA score looks slightly different for each node (not all nodes know of all blocks generated at any given moment thanks to the DAG structure where there could be more than 1 block mined simultaneously in the different ends of the Kaspa network), each node decided separately, whether it's already time for reward reduction or it is not yet. So miners on different nodes can have a different reward for their blocks during the phase change period (up to 18 seconds in total). This could give a slight noise to the total emission, but that noise would hardly exceed tens of thousands Kaspa;
- Moreover, due to a parallel nature of DAG we can have an anti-chain of parallel blocks all with score exactly below the transition score. However there is a limit to the number of such parallel blocks being rewarded — namely the DAA window size (2641 — very untight upper-bound indeed). So we can take 2641 blocks from every "month" and give them the reward of the "month" before, which is equal to simply adding 2641 extra blocks with current (this "month") reward. This could give another tens of thousands Kaspa;
- Sometimes DAA scores jumps up by a certain value thanks to blocks parallel creation, so the exact border of the reward switching could not be achieved, and this gives yet another swing in total emission, but it's too expressed in hundreds to thousands Kaspa at each new reward phase start.
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).
¶ How will Kaspa keep incentive miners to secure the network when the block reward is 0?
contd: “Looks like it can not rely on transaction fee to incentive miner because it is too small?”
By 2029 Kaspa will have an even lower inflation rate than Bitcoin and have arguably become the world's most "hard money." Also by that time, on account of its revolutionary implementation of POW, Kaspa may well be the "most secure money" humanity has ever known. These facts plus Kaspa's anticipated future speed increases (up to 100 bps by that time, leaving Visa in the dust) plus smart contracts (likely by that time) plus Kaspa's support for Eth settlements (presently in the planning stage), plus L2s and their fee steams (widely anticipated), should make Kaspa exponentially more valuable within 5 years. Therefore, the volume of fees and new fee streams are anticipated to be sufficient to support profitable mining. In fact, Kaspa's fee flow may well be sufficiently robust to generate far more wealth for miners than the emission schedule does today. Supposing that mining isn't sufficiently profitable in spite of all these anticipated developments, network fees could be increased. In the unlikely event fee increases aren't sufficient to sustain mining profitability, various other options are available to support mining. The important thing to realize is that the reduced emission schedule will vastly increase the scarcity of newly-mined Kaspa within this decade, thereby helping reduce amount for sale on the market, thereby minimizing the likelihood that special measures to support mining will ever be needed.
Technically, there are also other alternatives, such as increasing the standard fee amount, adding a tail emission or demurrage (a fee for stationary UTXOs), and each of them has its pros and cons, but essentially all of them require intervention in the emission schedule and are not discussed for actual implementation, but rather considered by some of the community members as an alternative possibilities from general considerations.
¶ 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?".
¶ 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 <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
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.
¶ Archival FAQ topics
Visit this page to see what questions were asked frequently enough one day to be even added to this Wiki.