What is Navcoin (NAV)?
Navcoin, launched in 2014, is an open-sourced digital currency offering fast and reliable payments with innovative technological and privacy features. Storing coins on a Navcoin wallet allows for making public or private transactions, earning rewards through staking (for network validation) or mixing coins (for privacy enhancement), and having a vote in project proposals.
Unique to Navcoin’s cryptosystem is that public NAV coins can be converted 1:1 to xNAV, the revolutionary privacy coin that guarantees untraceable transactions. Additionally, Navcoin has launched wNAV, a wrapped representation of NAV, that can be used in ecosystems such as Ethereum and Binance Smart Chain (BSC).
Navcoin was launched without pre-mining or an ICO to achieve a fair and transparent initial distribution of the supply. The project operates as a fully Decentralized Autonomous Organization (DAO), without a central decision making authority (unlike most other projects). Anyone can participate by simply staking NAV in their wallet, thereby obtaining a say in protocol governance and a vote on proposals that arise from within the community.
How are Navcoin’s privacy-enhanced features achieved?
Navcoin’s philosophy is to provide people with privacy preserving solutions that allow them to express themselves financially and transact as they desire. This has resulted in the development of xNAV, a privacy coin based on the decentralized, trustless, and permissionless technologies of the future.
First of all, xNAV is built on top of the self-developed privacy protocol blsCT that merges Boneh-Lynn-Shacham (BLS) Signatures and Confidential Transactions (CT). BLS compresses a group of signatures into a single compact signature that authenticates the entire group, thereby shielding the origin of individual transactions. CT is a well-established privacy protocol that obfuscates the amount of coins in a transaction.
On top of that, xNAV ensures personal privacy by using Stealth Addresses, public-key cryptography and the innovative Dandelion++ protocol. Stealth Addresses are private addresses which ensure complete privacy for the receiver of a transaction. Dandelion++ is a communication mixing protocol which breaks the link between a message and its source.
When using blsCT, two xNAV transactions can be merged into one, and transactions can be aggregated an infinite number of times. This allows Navcoin to scale effectively and support a high quantity of transactions across the network and users’ transactions are completely shielded and untraceable. Anyone trying to monitor transactions being made through Navcoin’s network is unable to tell if a transaction has been aggregated or not, and users are able to merge their coins with other individuals making transactions. When doing so, a user’s wallet uses Dandelion++ to send an anonymous request for coins from other nodes. These nodes can then connect and communicate between them using public-key cryptography to broadcast the session and their coins to mix. From those, the sender can randomly select several coins from the responses received. These coins are in turn mixed together with the original user’s coins, and then sent to the network, and this system ensures true privacy while also enabling anyone who helps to facilitate the mixing-process by providing liquidity to receive a fee for their service, and generate a passive income.
Combining these technologies, xNAV stands out in scalability and privacy, effectively supporting high quantities of transactions across the network with shielded and untraceable transactions.
How is Navcoin’s network secured?
Navcoin’s network is secured by a Proof of Stake (PoS) consensus mechanism, which means that anyone can use their NAV to help validate transaction blocks. By comparison, Bitcoin’s Proof of Work (PoW) consensus mechanism requires miners to calculate huge mathematical problems to process transactions and earn rewards. This requires expensive hardware and is extremely energy intensive. Navcoin’s PoS consensus mechanism does away with these resource intensive requirements; even a 5 Volt Raspberry Pi can take part in securing the network.
Navcoin’s users can earn passive income in two distinct ways. First of all, users can help secure the network by staking NAV to validate transactions. With block times of 30 seconds, the block reward is 2.5 NAV. Of each reward, 2 NAV are for the staker, and 0.5 NAV are held in a decentralized treasury, the Community Fund, used for self-funded community initiatives.
Users can also mutually merge their xNAV coins over various nodes to facilitate the mixing process that ensures xNAV’s privacy and anonymity. Users are rewarded a fair compensation fee in return for this service.
How is Navcoin’s network governed?
In addition to helping to secure the network, Navcoin’s PoS consensus mechanism enables all public NAV holders to get involved with governing their platform. There is no central authority controlling Navcoin, and community members play a crucial role in maintaining a fair and decentralized system of decision making. As a result, Navcoin operates as a Decentralized Autonomous Organization (DAO) with all protocol administration and consensus changes being subject to an open voting system. All community members holding their NAV on the public side can participate in the DAO by staking their coins, and each stake is the equivalent of one vote. This gives each wallet holder a say in protocol governance, and allows them to vote on any proposals that arise. To ensure widespread participation, there is also no minimum staking amount required for anyone to take part in voting.
Navcoin’s governance system also incorporates a Community Fund to ensure that contributors and projects can be compensated and funded by the network.
AdminUpgradeabilityProxy.constructor(address,address,bytes)._admin (#348) shadows:
- AdminUpgradeabilityProxy._admin() (#433-438) (function)
Rename the local variables that shadow another component.
Additional information: link
UpgradeabilityProxy.constructor(address,bytes)._logic (#268) lacks a zero-check on :
- (success) = _logic.delegatecall(_data) (#272)
AdminUpgradeabilityProxy.upgradeToAndCall(address,bytes).newImplementation (#424) lacks a zero-check on :
- (success) = newImplementation.delegatecall(data) (#426)
Check that the address is not zero.
Additional information: link
Modifier AdminUpgradeabilityProxy.ifAdmin() (#373-379) does not always execute _; or revert
All the paths in a modifier must execute _ or revert.
Additional information: link
Address._verifyCallResult(bool,bytes,string) (#227-244) is never used and should be removed
Address.functionCall(address,bytes) (#159-161) is never used and should be removed
Address.functionCall(address,bytes,string) (#169-171) is never used and should be removed
Address.functionCallWithValue(address,bytes,uint256) (#184-186) is never used and should be removed
Address.functionCallWithValue(address,bytes,uint256,string) (#194-201) is never used and should be removed
Address.functionStaticCall(address,bytes) (#209-211) is never used and should be removed
Address.functionStaticCall(address,bytes,string) (#219-225) is never used and should be removed
Address.sendValue(address,uint256) (#133-139) is never used and should be removed
Proxy._implementation() (#34) is never used and should be removed
Remove unused functions.
Additional information: link
Pragma version^0.6.0 (#5) allows old versions
Pragma version>=0.6.2<0.8.0 (#83) is too complex
Pragma version^0.6.0 (#249) allows old versions
Pragma version^0.6.0 (#327) allows old versions
solc-0.6.8 is not recommended for deployment
Deploy with any of the following Solidity versions: 0.5.16 - 0.5.17, 0.6.11 - 0.6.12, 0.7.5 - 0.7.6 Use a simple pragma version that allows any of these versions. Consider using the latest version of Solidity for testing.
Additional information: link
Low level call in Address.sendValue(address,uint256) (#133-139):
- (success) = recipient.call{value: amount}() (#137)
Low level call in Address.functionCallWithValue(address,bytes,uint256,string) (#194-201):
- (success,returndata) = target.call{value: value}(data) (#199)
Low level call in Address.functionStaticCall(address,bytes,string) (#219-225):
- (success,returndata) = target.staticcall(data) (#223)
Low level call in UpgradeabilityProxy.constructor(address,bytes) (#268-275):
- (success) = _logic.delegatecall(_data) (#272)
Low level call in AdminUpgradeabilityProxy.upgradeToAndCall(address,bytes) (#424-428):
- (success) = newImplementation.delegatecall(data) (#426)
Avoid low-level calls. Check the call success. If the call is meant for a contract, check for code existence
Additional information: link
Proxy._delegate(address) (#42-61) uses assembly
- INLINE ASM (#43-60)
Address.isContract(address) (#106-115) uses assembly
- INLINE ASM (#113)
Address._verifyCallResult(bool,bytes,string) (#227-244) uses assembly
- INLINE ASM (#236-239)
UpgradeabilityProxy._implementation() (#294-299) uses assembly
- INLINE ASM (#296-298)
UpgradeabilityProxy._setImplementation(address) (#314-322) uses assembly
- INLINE ASM (#319-321)
AdminUpgradeabilityProxy._admin() (#433-438) uses assembly
- INLINE ASM (#435-437)
AdminUpgradeabilityProxy._setAdmin(address) (#444-450) uses assembly
- INLINE ASM (#447-449)
Do not use evm assembly.
Additional information: link
Different versions of Solidity is used:
- Version used: ['>=0.6.2<0.8.0', '^0.6.0']
- ^0.6.0 (#5)
- >=0.6.2<0.8.0 (#83)
- ^0.6.0 (#249)
- ^0.6.0 (#327)
Use one Solidity version.
Additional information: link