HashEx Security Blog - Medium

How to Become a Smart Contract Auditor

Polly Traore — Thu, 17 Nov 2022 17:43:11 GMT

Smart contracts auditor is a popular job that’s always in demand. But not everyone is cut out for it. If you are sure that you can handle reviewing and fixing somebody else’s code, then our article on how to become an auditor may be just what you need.

Let’s take a look at the path that lies ahead of anyone who decides to make sure contracts work as intended and are safe to use.

Study development

To become an auditor, you have to first learn the specific language that is used for writing smart contracts. For someone with an IT background, it is relatively easy, since most smart contract languages resemble each other. But for a new potential auditor, the landscape will be unfamiliar, so the process becomes more demanding.

The main thing that you need to remember is that to become an auditor, you have to first become a developer, and learn how the language works. That’s why it’s also important to focus on one language and then study others if the need arises. The most common choice is to go with Solidity since it’s the most used one. It resembles Java Script in structure, which, once again, gives the advantage to those who already have experience in coding. For them, it’s entirely possible to achieve a high level of knowledge without taking third-party classes. For newbies, it is preferred.

Studying Languages

Like any subject, coding languages can be studied with or without a teacher. There are many online classes that promise to give you a result in a short time. Not all of them are equally effective. Selecting a class is a personal process. You have to set up your goal and choose the most appropriate method of learning, curriculum, and instructors. Consider prices as well, since different schools may require different budgets.

Online studying gives you an advantage right away: you can adjust your schedule so that your work and personal life aren’t affected.
However, if you need a more hands-on environment, networking opportunities, and potential job opportunities, you might choose offline classes.
The last option is the most attractive one — studying on your own. Books, online study materials, and determination are basically all you need.

But to confirm that you really possess the knowledge, you would still require a certain document. Schools offer you a diploma, but if you study on your own, you might need another way. HashEx Solidity Certification will come in handy in this case. You receive the document after passing a test created by Solidity experts, that combines a set of questions and tasks ideal to determine your level of knowledge.

From Developer to Auditor

Becoming a developer, even a good one, isn’t enough to qualify for an auditor position. This job requires an additional set of skills as well as specific qualities.

For one, an auditor has to be detail-oriented and attentive. The best auditors have to be meticulous while reviewing a code. Correcting and avoiding errors is a no.1 priority.

To save time, auditors often work in teams, which means that a successful auditor would be able to easily adapt to teamwork.

Some auditors minimize the possibility of human error by allowing two or more separate teams to review the same code.

Social and soft skills aren’t the only ones needed for auditing. There are various tools that auditors use daily. Some of them provide automatic audits and some allow testing of the code. Knowing how to work with them is an imperative skill.

These are the things that aren’t necessarily covered in courses, so the best way to obtain them is to start working.

It’s not easy and no one is going to offer a job to a newby auditor right off the bat. But there are projects like HashEx Aсademy BootCamp that give auditors and developers an opportunity to gain actual experience in the field. Working on a real project will give you the necessary credentials and recommendations as well as valuable experience and skills.

When you’ve learned everything there is to learn and experienced the environment, you can start looking for a job in auditing. Just keep in mind a few more tips.

Surrounding yourself with a community of more experienced auditors is a quick way to get better.
Following the most actual security news will help you track the trends and new types of attacks.
Regularly testing your knowledge helps keep your mind and attention sharp.

Build a blockchain career with HashEx:
HashEx Solidity Certification
HashEx Career Services

How to Become a Smart Contract Auditor was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lachain Consensus Protocol Smart Contract Audit Report

Polly Traore — Tue, 15 Nov 2022 19:28:25 GMT

Audit by: HashEx
Prepared for: Lachain
Platform: Lachain
Language: C#

HashEx was commissioned by the Lachain team to perform an audit of Honey Badger Byzantine Fault Tolerant (HBBFT) consensus realisation. The audit was conducted between March 14 and April 18, 2022.

HBBFT consensus is a part of Lachain Cross Chain DeFi protocol. The protocol allows seamless access to finance products on major blockchains without gas tokens management. All fees and gas are paid with the LA token [1].
HBBFT was introduced in October of 2016 by Andrew Miller et al. It was built to eliminate synchronous protocols’ problem of critical dependence on network timing assumptions which makes them inappropriate for real deployments scenarios [2].
Using the example of PBFT, the authors have proved [3] that weakly synchronous protocols are not long living in malicious networks and would grind to a halt if the time assumption is violated. HBBFT came out from an improved asynchronous atomic broadcast protocol [4]. Andrew Miller et al. proposed enhancements that resulted in bit transmission complexity reduction from O(N²) to O(N).
The code is available at the @LATOKEN/lachain GitHub repository and was audited after the v0.0.71-main tag.
Update: the Lachain team has responded to this report. The updated code is located in the same repository after the v0.0.88 tag.

Contract

Lachain.Consensus

Consensus by itself is not responsible for final block processing and block addition to the blockchain. It serves for achieving an agreement in the list of transactions that will be worked on and will form the final block further. Roughly speaking, consensus ensures that the majority of nodes approves a proposed data for block creation.

A detailed description of functional layers interaction during consensus agreement achievement in HBBFT and their inner processes explanation can be found in the original Andrew Miller’s work [2], article series by POA Network [5, 6], and Appendix B.

The audited folder has a neat and lean structure. Each subfolder name is conventional with whitepaper functional components and modules. The project and the consensus in particular are written in C# language. Observation of public HBBFT realisations revealed that it might be the first protocol implementation in this language. Various implementations are collected in the @initc3 Github [7], some of them have been audited [8].

It’s worth to mention that several modifications were introduced into more of the HBBFT implementations compared to the original whitepaper protocol [2]. One can check the Issues section in the @amiller/HoneyBadgerBFT Github repo.

Issues

#01. Decrypted share validation problem

Severity: Medium
Status: Resolved
Location: Module: Lachain.Consensus/HoneyBadger/HoneyBadger.cs:L169

Once CommonSubset returns the list of shares to HoneyBadger, the latter requests the decryption from other nodes. When the number of decrypted shares from different parties reaches f + 1 (where f is the number of byzantine nodes), the plain text of the initial message can be obtained with TPKE.Dec. The protocol authors assert in the whitepaper [2] that “if C contains invalid shares, then the invalid shares are identified”. However, they wriggle out of specifying the exact encryption scheme in the standard that satisfies this requirement, but it’s marked out they used threshold encryption proposed by Baek and Zheng [9] in their demo Python realization [10]. It turned out POA Network had stepped aside from using it in their implementation [11], favoring BLS12–381 [12], which was invented after the HBBFT presentation. Since the Lachain team adopted their approach, we imperatively advise to examine this elliptic curve on the ability to validate decrypted blocks that the node receives on the substitution. A similar issue is discussed at @amiller/HoneyBadgerBFT Github repo.

When the decryption phase in HoneyBadger is started, every valid node sends their decryption shares for every encrypted share.

private void HandleCommonSubset(ProtocolResult> result)
{
 (…)
 foreach (var share in result.Result)
 {
 var dec = _privateKey.Decrypt(share);
 _taken[share.Id] = true;
 _receivedShares[share.Id] = share;
 CheckDecryptedShares(share.Id);
 Broadcaster.Broadcast(CreateDecryptedMessage(dec));
 }
 (…)
}

At this moment the byzantine node could send a non-valid decryption message (message.Decrypted field in CreateDecryptedMessage(dec) in the snippet above). It is important to send this message fast and to be at the first f+1 values on other nodes. Otherwise, this vulnerability won’t work.

When there are enough decrypted shares for some share (not less than f+1) then decryption of this share starts.

This function is called when some decrypted message come:

private void HandleDecryptedMessage(TPKEPartiallyDecryptedShareMessage msg)
{
 var share = Wallet.TpkePublicKey.Decode(msg);
 _decryptedShares[share.ShareId].Add(share);
 (…)
}

This function is called to start decryption for some share:

{
 (…)
 _shares[id] = Wallet.TpkePublicKey.FullDecrypt(_receivedShares[id]!, _decryptedShares[id].ToList());
 (…)
}

This function is called in HoneyBadger.CheckDecryptedShares function:

public RawShare FullDecrypt(EncryptedShare share, List us)
{
 (…)
 var ys = new List();
 var xs = new List();
 foreach (var part in us)
 {
 xs.Add(Fr.FromInt(part.DecryptorId + 1));
 ys.Add(part.Ui);
 }
 var u = MclBls12381.LagrangeInterpolate(xs.ToArray(), ys.ToArray());
 return new RawShare(Utils.XorWithHash(u, share.V), share.Id);
}

This Lagrange interpolation outputs a wrong value because variable ys contains a wrong value for some xs. Because of this, all decryption output will be wrong because this process is tied to this interpolation. Therefore one node can break the whole decryption process.

Update: The fixed realisation contains an extra decrypted share verification stage presented after L143 if-clause in HoneyBadger.cs. The verification has been achieved with the use of threshold and pair-based cryptography principles on the BLS12–381 elliptic curve. Since the approach requires a separate verification public key for each participant, additional modifications to key generation module and node storage scheme were needed. The task was also fraught with difficulties in maintaining compatibility with existing chain history. Intended consensus behaviour for invalid decrypted shares was evidenced in integration tests.

#02. Possible DoS by byzantine validator

Severity: Medium
Status: Resolved
Location: Module: Lachain.Core/Consensus/EraBroadcaster.cs:L143

When the node processes external messages from other nodes, it checks whether a module that corresponds to this message exists. In case there is no corresponding module, the node creates one and starts a new thread for it. Therefore one node can create an unlimited amount of threads on other nodes and this may lead to a Denial of Service (DoS) problem.

There are an unlimited amount of ids for BinaryBroadcast, CommonCoin, ReliableBroadcast, and BinaryAgreement modules. The mechanism of changing the group of validators (i.e. DoS prevention) was out of the scope of the current study.

public void Dispatch(ConsensusMessage message, int from)
{
 (…)
 switch (message.PayloadCase)
 {
 case ConsensusMessage.PayloadOneofCase.Bval:
 var idBval = new BinaryBroadcastId(message.Validator.Era, message.Bval.Agreement, message.Bval.Epoch);
 EnsureProtocol(idBval)?.ReceiveMessage(new MessageEnvelope(message, from));
 break;
 case (…)
 case (…)
 case ConsensusMessage.PayloadOneofCase.SignedHeaderMessage:
 var rootId = new RootProtocolId(message.Validator.Era);
 EnsureProtocol(rootId)?.ReceiveMessage(new MessageEnvelope(message, from));
 break;
 default:
 throw new InvalidOperationException($”Unknown message type {message}”);
 }
}

Update: The Lachain team agreed with the described concern and modernized the Dispatch function inside the EraBroadcaster class. The updated version includes a message validation for each external request type, whereas inner requests pass without checks as they are produced inside a node and believed not to have malicious objectives. Also, now all messages addressed to unexisting protocol id are postponed and put in a queue for further usage if/when an appropriate protocol is created, in contrast to instant new module initialization.

private void HandleExternalMessage(IProtocolIdentifier protocolId, MessageEnvelope message)
{
 if (ValidateProtocolId(protocolId))
 {
 if (message.External)
 {
 var protocol = GetProtocolById(protocolId);
 if (protocol is null)
 {
 lock (_postponedMessages)
 {
 _postponedMessages
 .PutIfAbsent(protocolId, new List())
 .Add(message);
 }
 }
 else protocol.ReceiveMessage(message);
 }
 else Logger.LogWarning(“Internal message should not be here”);
 }
 else
 {
 var from = message.ValidatorIndex;
 Logger.LogWarning($”Invalid protocol id {protocolId} from validator {GetPublicKeyById(from)!.ToHex()} ({from})”);
 }
}

private bool ValidateProtocolId(IProtocolIdentifier id)
{
 switch (id)
 {
 case BinaryBroadcastId bbId:
 return ValidateBinaryBroadcastId(bbId);
 case CoinId coinId:
 return ValidateCoinId(coinId);
 case ReliableBroadcastId rbcId:
 // need to validate the sender id only
 return ValidateSenderId((long) rbcId.SenderId);
 case BinaryAgreementId baId:
 // created only by internal request, external messages never reach BinaryAgreementId
 // so no need to validate
 return true;
 case CommonSubsetId acsId:
 // created only by internal request, external messages never reach BinaryAgreementId
 // so no need to validate
 return true;
 case HoneyBadgerId hbId:
 // only has era in the fields
 ValidateId(hbId);
 return true;
 case RootProtocolId rootId:
 // only has era in the fields
 ValidateId(rootId);
 return true;
 default:
 return false;
 }
}

#03. Modified common coin algorithm

Severity: Informational
Status: Open
Location: Module: Lachain.Consensus/BinaryAgreement/BinaryAgreement.cs:L131–137

Coin toss sequence is defined as ‘false, true, and the returned value of CommonCoin’. HBBFT whitepaper describes an algorithm without “forced” common coin values, later implementations mostly use a ‘true, false, and returned value of CommonCoin’ pattern. See more at @amiller/HoneyBadgerBFT Github repo.

We expect no significant consequences of this modification.

if ((_currentEpoch / 2) % 3 == 2)
 {
 Broadcaster.InternalRequest(new ProtocolRequest(Id, coinId, null));
 }
 else
 {
 _coins[_currentEpoch] = ((_currentEpoch / 2) % 3) != 0;
 }

Conclusion

In this report, we present the results of the audit of the Lachain protocol consensus made upon their request. The Lachain team chose for their network Honey Badger Byzantine Fault Tolerance consensus. BFT consensuses are green (sustainable) consensuses: energy consumption of BFT consensuses is significantly lower than Proof of Work ones because they do not entail a computation puzzle. HoneyBadger consensus is one of the modern implementations of BFT consensuses with their definitive feature, compared to the rest of the BFT consensuses, being asynchronous, i.e. independent from the network timing assumptions. Synchronous and weakly synchronous of consensuses mean that a consensus can be reached only if the network performs as expected. The HB BFT consensus can work independently from the network timing parameters and therefore may work on a larger range of networks (e.g. TOR network with big latencies). The development of the network and consensus by the Lachain team took 2 years. At this time, the 2 most popular realizations of the HB BFT consensus are Andrew Miller’s version written in python and POA network’s version in Rust. As far as we know, the current version is the first one written in one of the most popular coding languages C#.

We’ve investigated the consensus algorithm and focused mainly on the consensus sabotage possibilities. Since the Lachain team advertises their consensus as an HBBFT realization, we’ve referenced A. Miller’s paper [2], considering also the already discovered issues in HBBFT repo and other model and production implementations [7].

As a result of our inspection, we’ve introduced several concerns that may threaten consensus result convergence and a separate node service availability. By substituting a share with an invalid one during the decryption phase a perpetrator could freeze new blocks on adding to the blockchain, halting all transitions for an indefinite period of time until a byzantine node is detected and removed. Also, the lack of external message validation made nodes potentially vulnerable to DoS attack by malicious nodes since addressing to existing module led to its instant initialization.

In the provided update, the Lachain team acknowledged the issues and added fixes for ‘Decrypted share validation’ and Possible DoS by a byzantine validator’ problems. Although the implementation of the coin algorithm preserves a slight discrepancy to the original paper, we have doubts regarding the adverse effects of the modification, as the consensus performance and properties are not compromised. All things considered, we ensure compliance of the audited consensus implementation with the specifications of the HBBFT whitepaper.

HashEx website: https://hashex.org
Request an audit

Lachain Consensus Protocol Smart Contract Audit Report was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

HashEx Anniversary Raffle

Polly Traore — Fri, 11 Nov 2022 14:18:52 GMT

Happy 5th Birthday, HashEx!

That’s right, it’s been 5 years already, and to celebrate this occasion, we are running a HashEx Anniversary Raffle! Anyone can win fantastic prizes that will help them level up DeFi skills and knowledge!

All prizes are available in the form of a transferable NFT Voucher.

How to participate:
Any user can take part in our raffle. To do this, go to our Anniversary Raffle page, and leave your request under the prize you wish to receive. The requests will be accepted from November 10 to December 10.

On December 12, we will randomly select winners from all the participants.

Check out the amazing prizes!

Free Blockchain career consultation from HashEx HR Experts
This is a unique opportunity to get an online consultation and ask anything regarding your career growth, skills, job search, and anything related to working in Blockchain.
Free Solidity testing from HashEx developers
You can take a test designed for Solidity developers and auditors to determine your skill in the matter. The test is based on many years of Solidity experience.
Find out more https://academy.hashex.org/
40% off HashEx developer BootCamp.
You can join our developer Bootcamp and intern for 1 month with a 40% discount. You will get actual skills under the guidance of an experienced mentor and will work side by side with experienced Solidity developers.

Celebrate our birthday with us!

HashEx Anniversary Raffle was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Analytex: new features and interface improvements

Max Nekoz — Fri, 28 Oct 2022 14:55:35 GMT

AnalytEx is gaining new functionality and becoming more convenient every day. AnalytEx Smart Alerts are available.

Alerts

With AnalytEx Alerts, users can set up notifications of various changes with customization options. Now the functionality allows you to configure notifications about changes in the price of tokens in various chains, changes in the liquidity of the selected token, changes in the utilization rate of specific pools in different protocols, as well as set up notifications for changes in custom smart contracts.

AnalytEx Alerts

The service supports 6 chains: Ethereum, Avalanche, Fantom, Cronos, BSC, and Polygon. At the moment, users can receive notifications in Telegram, and email notifications will be available soon.

AnalytEx Alerts

Lending Aggregator

Lending Aggregator becomes more flexible, users can now sort lending opportunities by assets and by pools.

AnalytEx Lending Aggregator

Sorting by assets provides easy navigation through a particular asset in different chains, so you can quickly find the most profitable pool and chain to lend a particular asset.

View by Assets

Live Crypto Ticker Widgets

The best way to present our real-time data to your audience becomes even better. In the new update, sorting of tokens by chains is available. Choose a network, choose a token, customize the widget design and enjoy amazing widgets for free!

AnalytEx Widgets

Soon we will describe in detail the capabilities of AnalytEx Alerts, stay tuned and do not forget you can make us better with your ideas: https://analytex.today/contacts.html

Follow our Twitter and get access to Data-Driven news: https://twitter.com/AnalytexToday

Analytex: new features and interface improvements was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

CleverMinu Smart Contracts Audit Report

Polly Traore — Thu, 27 Oct 2022 17:30:30 GMT

Audit by: HashEx
Prepared for: CleverMinu
Platform: Binance Smart Chain, Ethereum, Polygon Network
Language: Solidity

HashEx was commissioned by the CleverMinu team to perform an audit of their smart contract. The audit was conducted between 29/09/2022 and 03/10/2022.

The purpose of this audit was to achieve the following:

Identify potential security issues with smart contracts
Formally check the logic behind given smart contracts.

The code was provided in .sol file with MD5 hash sum of c86fe39c705f6dfee9457c2e3349c1e9.

Update. The CleverMinu team has responded to this report. The updated code is located in the GitHub repository after the commit 4bf5066. The same code was deployed to Ethereum, Binance Smart Chain, and Polygon networks at address 0x155AB9Cd3655Aa6174E1e743a6DA1E208762b03d.

Contract

SafeMath

Safe arithmetical operations library.

Issues

#01. Gas optimizations

Severity: Low
Status: Acknowledged
1. In versions of Solidity >=0.8, over- and underflow checks are built-in when using math operations. To save gas remove, one can remove the SafeMath contract or rewrite the implementation of functions more simply, for example:

function safeAdd(uint256 a, uint256 b) internal pure returns (uint256) { return a + b; }

#02. Lack of error messages

Severity: Info
Status: Resolved
require() conditions return no error messages, which may confuse users and complicate the debugging.

Contract

ERC20Interface, ApproveAndCallFallBack, IHoldingContract

Interfaces for standard compliance. No issues were found.

Contract

Owned

A version of the Ownable authorization model without a simple possibility of renouncing.

Issues

#01. Lack of error messages

Severity: Info
Status: Resolved
require() conditions return no error messages, which may confuse users and complicate the debugging.

Contract

HoldingContract

A simple contract to be deployed inside CleverMinu’s constructor section. The only function of HoldingContract is to transfer part of its balance upon request from the CleverMinu token contract.

Issues

#01. Tokens are transferred without confirmation

Severity: Info
Status: Resolved
The initiate() function doesn’t return any values, i.e., it doesn’t signal if tokens have been transferred successfully or not.

function initiate(address receiver,uint256 tokens) public { require(msg.sender == MAINCONTRACT, “Forbidden”);
 uint balance = ERC20Interface(MAINCONTRACT).balanceOf(this);
 if(balance ERC20Interface(MAINCONTRACT).transferinternal(this,receiver, tokens);
 }

Contract

CleverMinu

An implementation of the ERC-20 token standard. Transfers are susceptible to a fixed fee of USER_BURNRATIO value (10% default), which is moved to the HoldingContract and paid later to the token holders after the 1-hour delay (default bonus value is 0.01% per day).

Issues

#01. Exaggerated owner’s rights

Severity: High
Status: Resolved
The contract owner is capable of halting the transfers by setting USER_BURNRATIO to over 100% and causing the underflow error or updating IMOENDTIME any time after the sale.

function setIMOendTime( uint256 time) public onlyOwner {
 IMOENDTIME=time;
 }

function setUSERBurnRatio( uint256 _ratio) public onlyOwner {
 USER_BURNRATIO=_ratio;
 }

Another problem is open minting for the owner: setting IMOENDTIME = 0 allows the owner to re-init the contract, effectively minting another _totalSupply (1e21 tokens) to the CleverMinu contract's balance. After that, the owner can transfer these minted tokens to any address by calling IMOreferral().

function init(uint256 _imoenddate) public onlyOwner 
 {
 require(IMOENDTIME==0,”Already Initiated”);
 //IMOENDTIME = block.timestamp;
 IMOENDTIME=_imoenddate;
 balances[this] = _totalSupply;
 emit Transfer(address(0), this, _totalSupply);
 ContractAddress=this;
 addtoWhiteList(this);
 }

Recommendation: Add safety checks into setIMOendTime() and setUSERBurnRatio(). Consider adding input data validation to other set functions, i.e., setHoldBonusRatio() and setIMOBurnRatio().

It is also acceptable to renounce ownership completely, although, it’s not simple in the case of a used Owned contract.

#02. Holding bonus is not guaranteed

Severity: Medium
Status: Acknowledged
The bonus for holders is paid in the creditholdingbonus() function, which is called in every transfer. This function checks the time period after the last user's balance update. It calls the HoldingContract to transfer the bonus amount from its balance to the user, but if HoldingContract doesn't hold enough tokens, nothing is transferred, and the bonus is cleared, meaning a loss for the user.
Moreover, anyone can trigger this kind of loss of the bonus tokens by sending any amount to the whale holders, whose bonus exceeds the HoldingContract’s balance at the moment.

Recommendation: Consider not updating lastbalances[_address] unless bonus tokens are successfully delivered. It's also possible to store unpaid bonuses in the mapping address => uint256.

#03. Possible overflow

Severity: Low
Status: Resolved
SafeMath is not used in the getburntokencount() function, since there are no limits in the setUSERBurnRatio(), see the 'Exaggerated owner's rights' issue.

function getburntokencount(uint amount) public constant returns (uint balance) {
 return ((amount*IMO_BURNRATIO)/100);
 }

#04. Division before multiplication

Severity: Low
Status: Resolved
Division before multiplication can, in some rare cases, cause calculation errors in integer math. In this contract, division before multiplication is performed in the creditholdingbonus() function on L235.

#05. Approve before IMO ends

Severity: Low
Status: Acknowledged
Using the increaseAllowance() and decreaseAllowance() functions, you can change the allowance before the end of the sale. This is most likely a logical error, since the approve() function, on the contrary, checks the time.

#06. Gas optimizations

Severity: Low
Status: Partially fixed
1. Multiple reads from storage are performed in init(): _totalSupply; transfer(): IMOENDTIME, USER_BURNRATIO, Holding_CONTRACT; creditholdingbonus(): Holding_CONTRACT; transferFrom(): IMOENDTIME, USER_BURNRATIO, Holding_CONTRACT; transferAnyERC20Token(): owner;
2. Reverted fallback is not needed as of Solidity 0.4.0.
3. External calls to itself in IMOsale() and IMOreferral() could be avoided by splitting transfer functions into internal and external separate functions.
4. Upgrading to recent pragma versions might save gas both for deployment and interaction with the contract. For example, in 0.6.5 the immutable keyword was introduced, post-0.8.0 versions include internal safe math checks, post-0.8.4 have custom errors to replace require() revert reasons.

#07. No visibility is set

Severity: Info
Status: Resolved
Mappings balances[] and allowed[] have no default visibility set; internal is used by default.

#08. Lack of Events

Severity: Info
Status: Resolved
There are no custom events besides standard ERC-20 ones. We recommend adding such events, especially for governance functions, e.g., updating whitelist and ratios.

Conclusion

We recommend adding documentation as well as unit and functional tests for all contracts. We also recommend upgrading the Solidity compiler version and importing the OpenZeppelin library.

This audit includes recommendations on improving the code and preventing potential attacks.

HashEx website: https://hashex.org
Request an audit

CleverMinu Smart Contracts Audit Report was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

European Union dreams of regulating the Blockchain and HashEx is ready to help

Max Nekoz — Wed, 26 Oct 2022 14:59:46 GMT

HashEx applies for a tender placed by the European Commission, which aims to develop a solution for automated data gathering directly from the Ethereum blockchain and testing the technological capabilities for supervisory monitoring of real-time DeFi activity. The goal of the project is to control and reduce financial fraud, as well as to protect ordinary users.

Why is it important?

Most DeFi applications like decentralized exchanges or lending protocols are built upon Ethereum’s blockchain, they allow anyone to exchange or loan crypto tokens without providing any personally identifiable information to an intermediary. Regulators and lawmakers around the world are concerned that such tools are being used to avoid laws and tax liabilities. Furthemore, acute anxiety is caused by hacker attacks and stealing funds. Over the current year, hackers have stolen more than $ 3 billion of funds from ordinary users, while 90% of the hacking falls on decentralized finance. The number of unique DeFi addresses is approaching a million, which means that each user has lost about $3,000 on average, the statistics are simply appalling! The European Commission considers it its duty to secure ordinary users of DeFi. HashEx, in turn, supports such an initiative.

The HashEx team has been at the forefront of the DeFi industry for more than 5 years and possesses deep expertise in data analysis, development, and security of smart contracts and decentralized protocols.
AnalytEx platform, developed by the HashEx company, combines data and context with innovative real-time data processing, and is able to meet the demands of the European Commission for a number of reasons:

- AnalytEx engine provides real-time data collection and aggregation across EVM-compatible blockchains, allowing signature analysis of smart contracts and responding to any changes without delay.
- The proprietary pattern analysis technology instantly captures even subtle patterns in the activity of the decentralized finance industry, both for the purpose of detecting misbehavior and for the purpose of smart investing based on real-time data.
- A prefabricated infrastructure, the use of only in-house services, without the use of third-party ones, and the availability of APIs, ensure quick setup of interface and smart notifications for absolutely any requests. The adaptability and flexibility of the product take its possibilities far beyond simple investments, allowing it to be used for in-depth data analysis.

These advantages make HashEx an ideal candidate for the implementation of the European Commission request.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

European Union dreams of regulating the Blockchain and HashEx is ready to help was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

InVaria2222 Smart Contracts Audit Report

Polly Traore — Wed, 26 Oct 2022 13:17:56 GMT

Audit by: HashEx
Prepared for: InVaria2222
Platform: Ethereum
Language: Solidity

HashEx was commissioned by the InVarFinance team to perform an audit of their smart contract. The audit was conducted between 19/08/2022 and 23/08/2022.

The purpose of this audit was to achieve the following:

Identify potential security issues with smart contracts
Formally check the logic behind given smart contracts.

Information in this report should be used for understanding the risk exposure of smart contracts, and as a guide to improving the security posture of smart contracts by remediating the issues that were identified.
The code is available at the @InVarFinance/invaria2222 GitHub repository and was audited after the commit 81b14fe1 (audited file InVaria-staking.sol).

Update: the InVarFinance team has responded to this report. The updated code is located in the GitHub repository after the commit 6b5c42d.
Update 2: The audited InVariaStaking contract with additional events was deployed to Ethereum chain at address 0x10a92B12Da3DEE9a3916Dbaa8F0e141a75F07126.

Contract

InVariaStaking

Contract address: 0x10a92B12Da3DEE9a3916Dbaa8F0e141a75F07126
The contract allows staking ERC1155 tokens with id1. Users can get rewards in USDC tokens during the staking period. Also, users are able to burn their tokens a year later after staking. As a reward for burning, users will get compensation in USDC tokens.

Issues

#01. Exaggerated owner’s rights

Severity: High
Status: Resolved
a. The contract owner has the ability to change the reward token (USDC) at any time using the setAddress() function. If the owner accidentally or maliciously changes the USDC address, users will receive rewards in completely different tokens that are worth nothing;
b. The contract owner has the ability to change staking token at any time using the setAddress() function. If the owner accidentally or maliciously change InVariaNFT and InVariaNFTBurn addresses, users' NFTS will be locked in the contract and won't be available for burning.

Recommendation:
a. Make USDC variable constant;
b. Make InVariaNFT and InVariaNFTBurn variables constant.

#02. Lack of events

Severity: Low
Status: Partially fixed
The functions setAddress(), stakeNFT(), unStake(), withDraw(), BurnNFT() don’t emit events, which complicates the tracking of important off-chain changes.

#03. Lack of validation of input parameters

Severity: Low
Status: Partially fixed
The contract constructor and the setAddress() function don’t check the addresses for a non-zero value.
We recommend adding validation to prevent incorrect initialization and behavior of the contract.

#04. Division before multiplication

Severity: Low
Status: Acknowledged
Division before multiplication can, in some narrow cases, cause calculation errors in integer math. In this contract, division before multiplication is performed on L182 (StakingReward_Balance() function).
Make sure the calculations work as expected.

#05. Floating pragma

Severity: Low
Status: Acknowledged
A general recommendation is that pragma should be fixed to the version that you are intending to deploy your contracts with. This helps to avoid deploying using an outdated compiler version and shields from possible bugs in future solidity releases.

#06. Gas optimization

Severity: Low
Status: Partially fixed
a. The state variables AprByMin, BurnReturn, YearInSeconds, WithDrawAddress can be declared as constant to save gas;
b. The state variable WithDrawAddress is never used in the contract and can be removed, to save gas on deployment;
c. The USDC_Balance(), BurnNftInfo() functions can be declared as external to save gas;
d. The variables staketime, unstaketime and isUnstake of the StakingInfo structure can be packed into one slot (by casting time variables to uint64);
e. The variables locktime and isBurn of the BurningInfo structure can be packed into one slot (by casting time variable to uint64);
f. The values stakingInfo[stakingAddress].length (L109, L143, L176) and burningInfo[msg.sender].length (L148) can be stored in a local variable to save gas on every loop step;
g. InVariaNFT and InVariaNFTBurn can be presented by one variable if BurnFunction interface is derived from IERC1155.

#07. Left to burn amount possible miscalculation

Severity: Low
Status: Open
NFTs in a burningInfo instance can be burned with BurnNFT() when the records' lockTime parameter is strictly less than block.timestamp. However, while calculating the NFTs amount available for burning in BurnNftInfo(), NFTs of records with lockTime equal to block.timestamp are also summed. This may affect the contracts with burned amount dependent logic. The issue was introduced in the update.

#08. Lack of documentation

Severity: Info
Status: Acknowledged
We recommend writing documentation using NatSpec Format. This would help in development, as well as simplify user interaction with the contract (including using the block explorer).

#09. No guaranteed rewards

Severity: Info
Status: Acknowledged
It is assumed that users will receive rewards for staking and burning tokens. But there is no guarantee that there are enough rewards on the balance of the contract at any time, since the source of the rewards is not explicitly known. Thus, before starting to use the contract, users must make sure that the contract has enough rewards for both staking and burning. Also, they should be informed that the contract owner can withdraw USDC tokens before the rewards distribution ends.

Conclusion

1 high, 2 medium, 5 low, and 1 informational severity issues were found.
1 high severity issue has been resolved in the update. 3 low severity issues have been partially resolved.

The reviewed contract is highly dependent on the owner’s account. As stated in the project description, users can earn rewards by staking, and can also burn NFT after the lock-up period and return the initial mint cost. But taking into account the implementation of the smart contract, the payment of any reward (including for burning NFT) is not guaranteed. And also, the owner can withdraw rewards from the contract at any time. Users using the project have to trust the owner and that the owner’s account is properly secured.

We strongly suggest adding functional tests for the contract to cover all edge cases.
This audit includes recommendations on improving the code and preventing potential attacks.

HashEx website: https://hashex.org
Request an audit

InVaria2222 Smart Contracts Audit Report was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Keeping Your NFTs Safe

Polly Traore — Fri, 21 Oct 2022 16:22:50 GMT

NFTs represent one of the most vulnerable areas of DeFi. The rarer they are, the more they cost, the more likely they are to be targeted by hackers. So for an NFT collector, it’s vital to take security measures. Lucky for all of us, NFT aficionados, there’s plenty that we can do to secure our collectibles.

Hardware Wallet

Hot wallets may be the most convenient to use and easily acquired, but that doesn’t mean it’s entirely safe to use. Metamask, Trust Wallet, Rainbow, or any other hot wallet is prone to external attacks simply because they maintain a connection with the Internet. It’s enough to accidentally visit a scam website run by malicious actors to lose all your NFTs.

A hardware wallet stores your private keys offline so to access them, a third party would have to sign a message from your hardware device. Only then they can get a hold of your seed phrase.

You, however, will always have access to your wallet as long as you have the phrase. Even if you lose the wallet you still can access your assets with the help of your secret recovery phrase.

Some of the most popular hardware wallets are Trezor and Ledger. They allow having sub-wallets and do provide extra firewalls.

When you need access to the wallet, simply transfer the assets you might need to a hot wallet and trade from there. Your hardware wallet will remain secure and won’t give access to any third party.

Keep Your Seed Phrase a Secret

There are some guidelines about the best ways to store your passwords, and they very much apply to your seed phrase.

The best idea is to memorize it. To successfully do it, check out different practices that allow memorizing long phrases. Some recommend writing down the phrase several times, although make sure to dispose of the paper with the password.

Of course, simply memorizing it isn’t enough unless you have an eidetic memory. You should keep one piece of paper with the password written down, preferably in a way that only you would be able to read, for instance, encoded. Another option is splitting the phrase into several parts and hiding it in different places.

Some crypto users recommend cryptosteel capsules — metal devices that can withstand heat and floods.

The most common option is involving a centralized company in backing up your private keys.

Stop Accepting Direct Messages on Discord

Discord is the most popular platform on which many projects host their own servers. And scammers would happily target you through DMs. They would attempt to inform you of airdrops, releases, and such. It’s better to close the messages altogether and avoid being bombarded with links that may or may not turn out to be malicious.

If you want to receive important news, focus on video announcements. That’s much safer and the risks of encountering scammers are lower.

The same goes for Telegram and other platforms — avoid direct messages and try to limit the number of links you open. Always check and verify the link.

Approach Your NFT Trading Wisely

The most popular errors that traders and NFT collectors make are usually connected to their online behavior. The desire to earn a lot without effort or investments makes users an easy target. This is why we suggest that you trade wisely. Study some practices and online experts, and don’t jump into any flashy ventures that promise you millions in days. Be smart with your money and make smaller stops.

For NFT and token traders, we recommend the advantages of AnalytEx. Make informed trading decisions.

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

Keeping Your NFTs Safe was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Anito Legends Smart Contracts Audit Report

Polly Traore — Tue, 18 Oct 2022 15:25:12 GMT

Audit by: HashEx
Prepared for: AnitoLegends
Platform: Binance Smart Chain
Language: Solidity

HashEx was commissioned by the Anito team to perform an audit of their smart contract. The audit was conducted between 8/06/2022 and 14/06/2022.

The purpose of this audit was to achieve the following:

Identify potential security issues with smart contracts
Formally check the logic behind given smart contracts.

The code is available in the Binance testnet:

Laro 0xC2B980821010dC7DCB6E00D02cAD6933e41bb2AC,
Ginto 0xebCd9C071792ab6fd2B349246DBc3ed6F335b818,
Anito 0x786FF6AA212B10E3B1f24D27623dB8d95F893b6d,
Stones 0x3F494a389251a07559c02329e69011748a2296dD,
Marketplace 0x1B89457d8cf48125632c3Bd112D8092E0B294590,
Summoner 0xceb4Aa3e864F844EEFa2C681A3262Cc443357eb5,
MasterChef 0x50E0208E60482CddEbC30F00d94c7DDdD4DFFd24,
Reward Manager 0xFd09FcdaCf75a144B13053b6eDdAfFE1fF03Bf7a.

Update: the Anito team has responded to this report. The updated code can be found at:

Laro 0x7bCfE5752B2CC8fe035806F21f61bF7880eE9374,
Ginto 0x4Dd0FFcbF2F542894e5DacAE7e18A78D2dC1c62e,
Anito 0xd6e8F7aEDA13d2dA86d3a9245801E2daE7c7dcF3,
Stones 0x49Ac17e3e1C2076d28BbceEB646CD71562198DaC,
Marketplace 0x8699661653B8360014E9688f9aB14b862fA793Fb,
Summoner 0xbE19009582AD1799B6fde595ad10Be86E3A43577,
MasterChef 0x3640Eae2551600D63B2049669d6dbF55cef8B81b,
Reward Manager 0xAF535e7e0232cb53179dBCb052daEFF4815D0E29.

Contract

BEP20Detailed

Part of the Laro inheritance scheme.

Issues

Gas optimization

Severity: Low
Status: Acknowledged
_name, _symbol, _decimals shoud be marked immutable.

Contract

BEP20

ERC20 interface implementation. Part of the Laro inheritance scheme.

Issues

Excessive owner’s rights

Severity: High
Status: Resolved
Critical token transfer methods have a whenNotPaused modifier. If the owner pauses the contract, token transfers will become unavailable.

Recommendation: Remove pause logic or renounce ownership.

Contract

Laro

An ERC20 interface implementation. Like BUSD, it is used as a payment method for market items in the Marketplace contract. Reward medium for the MasterChef contract. One of two payment mediums for stones in the Stones contract. Token transfers can be paused by the owner. No issues were found.

Contract

BEPPausable

The base contract which allows descendants to implement an emergency stop mechanism. Part of the Laro inheritance scheme. No issues were found.

Contract

Anito

An ERC721 interface implementation

The NFTs are minted by operators either directly by mint methods or via summoning the apprentice: passing 2 “masters” NFTs owned by a user, another Anito NFT (apprentice) is minted for the user.

Issues

Excessive owner’s rights

Severity: High
Status: Resolved
The owner can pause all NFT transfers. Hasty contract pause will arouse inevitable tokens’ price collapse and a loss of users’ assets.

Recommendation: Remove pause logic or renounce ownership.

Excessive operator’s rights

Severity: High
Status: Partially Fixed
Operators’ list should include only verified and reliable addresses, as they have access to uncontrolled mint and summoning. Also, one operator can revoke another operator’s role including himself.

Recommendation: Grant the operator role only to the Summoner contract passing its address as an argument in the constructor or manually delete all other operators except Summoner.
Update: Now only the owner can include/exclude operators, but they still have access to uncontrolled mint and summoning.

Max summon count is hardcoded

Severity: Medium
Status: Resolved
Max summon count is a hardcoded value in executeSummoning():

require(anitoInfo[master1].summonCount < 7 && anitoInfo[master2].summonCount < 7,”Maximum apprentice reached”);

Therefore the maxSummonCount variable change will not have an effect and the max possible summon count is always constant;

Recommendation: Replace the problematic line with the snippet below:

require(anitoInfo[master1].summonCount < maxSummonCount && anitoInfo[master2].summonCount < maxSummonCount,”Maximum apprentice reached”);

Gas optimization

Severity: Low
Status: Acknowledged
a. baseExtension, LAUNCH_MAX_SUPPLY, should be const.

b. LAUNCHPAD should be marked as immutable.

c. L:50 requirement should be checked in the constructor during token creation.

d. getMaxLaunchpadSupply(), getLaunchpadSupply() are redundant as LAUNCH_MAX_SUPPLY and LAUNCH_SUPPLY have public visibility.

e. Direct boolean comparison in L109.

f. notRevealedUri is redundant. In L110 a return “” could be used instead.

g. The ReentrancyGuard inheritance is not used.

h. Instead of LAUNCH_SUPPLY incrementation in the mintTo() function just add size after the for loop.

i. getMaxLaunchpadSupply(), getLaunchpadSupply(), pause(), unpause(), addOperationsAddress(), removeOperationsAddress(), setMaxSummonCount(), getAnitoOfAddress() should have external visibility.

No events

Severity: Low
Status: Acknowledged
No events are emitted in reveal(), addOperationsAddress(), removeOperationsAddress(), setMaxSummonCount().

Code style

Severity: Info
Status: Acknowledged
a. The ERC721 import is unnecessary since it’s already included in ERC721Enumerable.

b. maxSummonCount, operationsAddresses have default visibility.
c. Better to use multi-line comment notation /**/ in L200–203.
d. No space after requirement in the first argument in L170–171.
e. Missed spaces in for loop L:161.
f. The Zero address is more preferable than the empty address in the L205 error message.
g. A redundant dev comment in L62.
h. No error messages in requiremnts L133, 138.

baseURI public visibility

Severity: Info
Status: Acknowledged
baseURI can be seen even if the reveal flag is false since baseURI has public visibility. However, if baseURI stores confidential information which premature disclosure can lead to certain losses, it should not be stored in the blockchain at all if its sudden publicity causes any undesirable consequences.

Contract

Stones

ERC1155Supply interface implementation.

Initially, the owner of the contract sets prices for the “stones” tokens in Laro and Ginto.

Then tokens are bought by users, sending the Laro to treasuryAddress and Ginto to 0xdead (arbitrary non-existent address, implicit burn).

There are 4 stone types used to pay for summoning: ST_SUMMONING_STONE is obligatory, and ST_RARITY_STONE, ST_CLASS_STONE, ST_STAT_STONE are optional.

Issues

Excessive operator’s rights

Severity: High
Status: Partially Fixed
Operators have uncontrolled access to mint. Also, one operator can revoke another operator’s role including his own.

Recommendation: Operators must be Timelock contracts with a minimum delay of at least 24 hours. This won't stop the operators from possible rights abuse but it will help users to be informed about upcoming changes.
Update: Now only the owner can include/exclude operators, but they still have access to uncontrolled mint.

Gas optimization

Severity: Low
Status: Acknowledged
a. Pausable inheritance is not used.
b. Constant variables are not used in L17-L20.
c. Direct boolean comparison in L34.
d. setTreasuryAddress(), setPrices(), setTokenName(), addOperationsAddress(), removeOperationsAddress(), setURI(), mint(), mintBatch(), buyStone() should have external visibility.

No events

Severity: Low
Status: Acknowledged
No events are emitted in setTreasuryAddress(), setPrices(), setTokenName(), addOperationsAddress(), removeOperationsAddress(), setURI().

Code style

Severity: Info
Status: Acknowledged
a. Ginto token can be burnt instead of being sent to the 0xdead address in the buyStone() function. This will help keeping totalSupply() more precise;
b. operationsAddresses mapping has default visibility.

Contract

MasterChef

Staking contract with Laro reward token.

Issues

No guarantees the reward contract has enough tokens

Severity: Medium
Status: Acknowledged
Reward tokens are stored in the RewardManager address and are transferred to the user during withdraw(), deposit(), and harvestAll() functions calls. Since it's not checked that RewardManager has sufficient balance and allowance during pool updates, reward payments are not ensured to a user. Furthermore, the owner can set an arbitrary rewardManager address with setRewardManager().

Recommendation: Redesign the architecture that MasterChef mints tokens by itself or keeps distributed amount of tokens.

massUpdate flag is optional

Severity: Low
Status: Acknowledged
add() and set() functions have an optional _withUpdate flag which calls massUpdatePools() if set false and may cause unfair rewards in case of rarely updated pools, see more info here.

No support of tokens with commissions

Severity: Low
Status: Acknowledged
The deposit function doesn’t have a check on the actual transferred amount of deposited tokens. The owner must not add pools with tokens with fees on transfers. In general, any rebasing token is not supported.

Gas optimization

Severity: Low
Status: Acknowledged
a. devAddress is not used anywhere except setDevAddress() function.
b. laro can be sent directly to the ultimate receiver in safeLaroTransfer().
c. add(), set(), pendingReward(), deposit(), withdraw(), harvestAll(), emergencyWithdraw(), setDevAddress(), setTreasuryAddress(), updatestartTime() should have external visibility.
d. DEPOSIT_FEE_CAP, ALLOC_POINT_CAP should be const, also no visibility specified for DEPOSIT_FEE_CAP.
e. laro should be marked immutable.
f. poolInfo.length in massUpdatePools() should be stored in the local variable.

harvestAll() can fail if there are too many pools

Severity: Info
Status: Acknowledged
The MasterChef interface has only the harvestAll() function to collect rewards without amount withdrawal. Under the hood, it iterates over the pools and sums up all pending rewards. If the number of pools is great enough, iteration may exceed the block gas limit and all harvestAll() calls will be reverted. Users will have to collect their rewards with withdraw() and deposit() functions.

Contract

RewardManager

Masterchef’s reward tokens’ holder.
It approves (non-automatically) the MAX_INT allowance of the specified ERC20 token for the specified Masterchef contract.
A multisig account set by the owner or operator is able to withdraw ERC20 tokens from the RewardManager contract.

Issues

Excessive owner’s rights

Severity: Medium
Status: Acknowledged
Multisig wallet can withdraw all MasterChef reward tokens with withdrawERC20().
Recommendation: Add a requirement _token is not equal to the Laro address.

No events

Severity: Low
Status: Acknowledged
No events are emitted in setOperator(), setMasterchef(), setMultisig().

Gas optimization

Severity: Low
Status: Acknowledged
a. The SafeERC20 library is not used.
b. setOperator(), setMasterchef(), setApproval(), setMultisig(), withdrawERC20() should have external visibility.
c. onlyOperator() modifier is never used.

Contract

Summoner

An operator contract for the Anito token, calling executeSummoning method on it.
It decreases the user’s Stones balance of type ST_SUMMONING_STONE by 2, and arbitrary (depending on user’s input) decreasing by 1 Stat, Class, or Rarity stones.

Issues

Stones constants point to similar integer

Severity: Medium
Status: Resolved
ST_RARITY_STONE, ST_CLASS_STONE, ST_STAT_STONE point to the same integer value 1, providing transfers of the same type in summon().

Recommendation: Assign different values to stone types.

Optional booleans in summon()

Severity: Medium
Status: Resolved
a. A user can set all optional booleans to false and execute summon() only for 2 ST_SUMMONING_STONE tokens.
b. A user can accidentally set multiple booleans to true and pay multiple times for summoning.

Recommendation: a. Require one of the booleans to be set to true.
b. Use else if statement instead of if on L57, 62.

Gas optimization

Severity: Low
Status: Partially Fixed
a. anitoNFT, stones should be marked as immutable.
b. Direct boolean comparison in L27.
c. The maintenanceMode variable is not used.
d. ERC20, ERC721 imports are not used.
e. L45–46 requirements are double-checked in anito executeSummoning() function.
f. The operationsAddresses mapping and onlyOperators modifier are not used.
g. Consider using just IERC1155 interface instead of whole contract import.
h. Inherited functionality of the Ownable contract is unused.
i. pause(), unpause(), summon() should have external visibility.

Contract

Marketplace

ERC721Holder and ERC1155Holder implementation contract.
Marketplace where ERC721 and ERC1155 can be changed to Laro or BUSD.

Issues

createMarketSale() doesn’t require market item isn’t sold

Severity: Critical
Status: Resolved
The createMarketSale() function doesn't make a vital check that the passed itemId argument hadn't been already sold. This oversight leads to serious security breaches in the NFT marketplace and endangers the safety of users' NFTs. A malefactor can utilize this vulnerability in one of the following ways. ERC721 can be bought with the lowest historical sale price on market place, i.e. if an NFT was sold with one price and after some period of time it was placed on market place again with price gains it can be bought with itemId of the previous sale and consequently, it's price. Moreover, even this partial payment will go to the seller of the previous itemId. ERC1155 can be exploited quite similarly, but in this case, a hacker may take into account multi-token standard and buy small amounts of some type, place them for peanuts on the marketplace and then exhaust all tokens of this type by multiple purchases of his own itemId.

Recommendation: Add constraint on itemId that it isn’t sold:

require(!idToMarketItem[itemId].sold, “ItemId is already sold”);

setAllowAsset() may lead to unsupplied MarketItems

Severity: Medium
Status: Partially Fixed
As the setAllowAsset() method doesn't provide value for assetTypes, adding new contracts may lead to MarketItem unsupplied with ERC721 or ERC1155. If the user mistakenly buys the MarketItem, he transfers Laro or BUSD to a seller and gets nothing in exchange. Consider providing value for assetTypes in setAllowAsset() or make users check whether they buy proper MarketItem.

Recommendation: Require that the_assetAddress value in assetTypes mapping isn't null.
Update: Although assetTypes[_assetAddress] can be modified in the new version, the parameter provided by user may contain unsuppoted by market asset type.
Consider adding the requirement below in setAllowAsset():

require(_assetType == ASSET_ERC721 || _assetType == ASSET_ERC1155, “Unexpected asset type”);

Gas optimization

Severity: Low
Status: Partially Fixed
a. All public functions in the contract should have external visibility.
b. Castings of msg.sender to payable type are unnecessary L150,151,202, 247.

Contract

Ginto

An ERC20 token implementation.
Minted either by the owner or by another user with previously signed messages by the signer once in 2 weeks.
Blacklisting both for sender and receiver is implemented.
Used as one of the payment mediums for stones in the Stones contract.

Issues

Gas optimization

Severity: Low
Status: Acknowledged
a. Ineriantace of Pausable and ReentrancyGuard is unnecessary;
b. BURNER_ROLE is not used.

Conclusion

1 critical, 4 high, and 6 medium severity issues were found. 1 critical, 2 high, and 2 medium severity issues have been resolved with the update, while 2 high and 1 medium severity ones have bee resolved partially. The reviewed contracts are highly dependent on the owner’s account. Users using the project have to trust the owner and that the owner’s account is properly secured.

This audit includes recommendations on code improvement and the prevention of potential attacks. We recommend adding tests with coverage of at least 90% with any updates in the future.

HashEx website: https://hashex.org
Request an audit

Anito Legends Smart Contracts Audit Report was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

5 Reasons to Learn Solidity

Polly Traore — Fri, 07 Oct 2022 11:17:46 GMT

Solidity is the language at the core of most decentralized projects. It was developed specifically for smart contracts, responding to the needs of developers. As one of the first and most widespread, it attracts the attention of most developers wishing to break into the world of dApps. Today, we look at 5 reasons developers should consider learning Solidity.

A Relatively Easy Language

While many developers choose certified courses and schools, some prefer to study them independently. This happens to be a popular choice since compared to many other programming languages, Solidity is relatively easy. Those who have experience coding on JavaScript, find it especially accessible. Solidity is based on the same if/then principle. It’s adapted to better reflect the features required for smart contract functionality.

When you select this language, make sure to get the best possible sources. Easy access makes it difficult to track the true professionals. You can have the knowledge with no proof or vice versa.

More Career Possibilities

Like in any other area, IT offers a wide variety of specific fields. Their popularity and demand for specialists change depending on trends. Versatility allows developers to switch fields at any point and avoid burnout. Even those who remain excited after years of work can benefit from new knowledge and adopt decentralized practices for a standard IT project.

Solidity developers are in high demand right now and it’s become obvious that crypto projects are here to stay. So why not add an extra tool to your belt?

Change the DeFi Landscape

Smart contracts have many use cases in different areas. From business to entertainment, there have been thousands of new applications and new ones appear every day. Working with smart contracts can help you get a job in finance, gaming, art, etc. Imagination is the only limit as you can work on an existing project or create your own startup.
Pretty much every existing service can benefit from using smart contracts.

Stepping Stone

We have already covered that Solidity is one of the easiest languages, but it’s not the only one. By mastering this language and getting enough experience in smart contract development, you automatically open up possibilities to add more knowledge. After discovering Solidity, many developers move on to new languages, such as Rust, Vyper, Yule, etc. Depending on their needs, some developers build their own languages.

General Knowledge

Solidity can give developers an understanding of DeFi space. Even if they are uninterested in the decentralized market, they can still benefit from knowing how it functions and borrow some tools from it if necessary. This enriches expertise and options. With minimum effort, it’s possible to follow the latest trends and even participate in trading activities making educated predictions as opposed to guesses.

Become a Certified Expert

HashEx has an exciting opportunity for Solidity developers. If you think that you have already mastered Solidity, you can put your knowledge to the test. Literally. HashEx offers a test that, thanks to its structure, allows to determine the developer’s level and grade it accordingly.

With a HashEx Solidity Certificate, developers have factual proof of their knowledge and skill, making it easier to get their first job in blockchain.

Get your Certificate today!

Follow HashEx DeFi Intelligence Ecosystem:
Announcement Channel
Twitter

5 Reasons to Learn Solidity was originally published in HashEx Security Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

HashEx Blog

Sharing useful information about the blockchain

Let's Work Together! Write now.