Vulnerability Severity Summary

Vulnerability Severity Level	Total
Critical	0
High	1
Medium	1
Low	0
Very Low	0
Informational (Non severity level)	4

 

 

 

Vulnerability Findings

ID	Title	Severity	Status
SEC-01	Owner can change user balance by using burn function	High	Acknowledge
SEC-02	Imprecise arithmetic operations order (divide-before-multiply)	Medium	Acknowledge
SEC-03	Unused state variables (unused-state)	Informational	Acknowledge
SEC-04	Comparison to boolean constant (boolean-equal)	Informational	Acknowledge
SEC-05	If different pragma directives are used (pragma)	Informational	Acknowledge
SEC-06	Conformity to Solidity naming conventions (naming-convention)	Informational	Acknowledge

 

 

 

 

SEC-01:  Owner can change user balance by using burn function

Type	Severity	Location	Status
Owner can change user balance by using burn function	High	Check on finding	Acknowledge

 

Finding:

❌ (AjiraPayFinanceToken.sol#373-382)

 

Exploit Scenario:

The contract owner has the authority to modify the balance of tokens at other addresses, which may result in a loss of assets.

 

Alleviation:

Ajira Pay team has Acknowledge this issue.

 

 

SEC-02:  Imprecise arithmetic operations order (divide-before-multiply)

Type	Severity	Location	Status
Imprecise arithmetic operations order (divide-before-multiply)	Medium	Check on finding	Acknowledge

 

Finding:

❌ AjiraPayFinanceToken._swapAndLiquify(uint256) (AjiraPayFinanceToken.sol:432-459) performs a multiplication on the result of a division:

• buyBackTreasuryAmount = leftOverBnb / totalTreasury * buyBackTreasuryPercent (AjiraPayFinanceToken.sol#447)

❌ AjiraPayFinanceToken._swapAndLiquify(uint256) (AjiraPayFinanceToken.sol:432-459) performs a multiplication on the result of a division:

• liquidityTreasuryAmount = leftOverBnb / totalTreasury * liquidityTreasuryPercent (AjiraPayFinanceToken.sol#448)

 

Recommendation:

Consider ordering multiplication before division.

 

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#divide-before-multiply

 

 

 

Exploit Scenario:

Solidity’s integer division truncates. Thus, performing division before multiplication can lead to precision loss.

 

contract A {

function f(uint n) public {

coins = (oldSupply / n) * interest;

}

}

 

If n is greater than oldSupply, coins will be zero. For example, with oldSupply = 5; n = 10, interest = 2, coins will be zero.
If (oldSupply * interest / n) was used, coins would have been 1.
In general, it’s usually a good idea to re-arrange arithmetic to perform multiplication before division, unless the limit of a smaller type makes this dangerous.

 

Alleviation:

Ajira Pay team has Acknowledge this issue.

 

 

SEC-03:  Unused state variables (unused-state)

Type	Severity	Location	Status
Unused state variables (unused-state)	Informational	Check on finding	Acknowledge

 

Finding:

❌ AjiraPayFinanceToken._allowances (AjiraPayFinanceToken.sol:219) is never used in AjiraPayFinanceToken (AjiraPayFinanceToken.sol#199-538)

❌ AjiraPayFinanceToken.devTreasuryPercent (AjiraPayFinanceToken.sol:229) is never used in AjiraPayFinanceToken (AjiraPayFinanceToken.sol#199-538)

 

Recommendation:

Remove unused state variables.

 

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unused-state-variable

 

 

Exploit Scenario:

–

 

Alleviation:

Ajira Pay team has Acknowledge this issue.

 

 

SEC-04:  Comparison to boolean constant (boolean-equal)

Type	Severity	Location	Status
Comparison to boolean constant (boolean-equal)	Informational	Check on finding	Acknowledge

 

Finding:

❌ AjiraPayFinanceToken._transfer(address,address,uint256) (AjiraPayFinanceToken.sol:387-419) compares to a boolean constant:

• _isExcludedFromFee[_sender] == true (AjiraPayFinanceToken.sol#415)

❌ AjiraPayFinanceToken._transfer(address,address,uint256) (AjiraPayFinanceToken.sol:387-419) compares to a boolean constant:

• isInTaxHoliday == true (AjiraPayFinanceToken.sol#416)

 

Recommendation:

Remove the equality to the boolean constant.

 

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#boolean-equality

 

 

 

Exploit Scenario:

Detects the comparison to boolean constants.

 

contract A {

function f(bool x) public {

// …

if (x == true) { // bad!

// …

}

// …
}

}

 

 

Boolean constants can be used directly and do not need to be compare to true or false.

 

Alleviation:

Ajira Pay team has Acknowledge this issue.

 

 

 

SEC-05:  If different pragma directives are used (pragma)

Type	Severity	Location	Status
If different pragma directives are used (pragma)	Informational	Check on finding	Acknowledge

 

Finding:

❌ Different versions of Solidity are used:

• Version used: [‘=0.8.4’, ‘^0.8.0’, ‘^0.8.1’]
• =0.8.4 (AjiraPayFinanceToken.sol:2)
• ^0.8.0 (@openzeppelin/contracts/access/AccessControl.sol#4)
• ^0.8.0 (@openzeppelin/contracts/access/IAccessControl.sol#4)
• ^0.8.0 (@openzeppelin/contracts/access/Ownable.sol#4)
• ^0.8.0 (@openzeppelin/contracts/security/ReentrancyGuard.sol#4)
• ^0.8.0 (@openzeppelin/contracts/token/ERC20/ERC20.sol#4)
• ^0.8.0 (@openzeppelin/contracts/token/ERC20/IERC20.sol#4)
• ^0.8.0 (@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol#4)
• ^0.8.0 (@openzeppelin/contracts/token/ERC20/extensions/draft-IERC20Permit.sol#4)
• ^0.8.0 (@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol#4)
• ^0.8.0 (@openzeppelin/contracts/utils/Context.sol#4)
• ^0.8.0 (@openzeppelin/contracts/utils/Strings.sol#4)
• ^0.8.0 (@openzeppelin/contracts/utils/introspection/ERC165.sol#4)
• ^0.8.0 (@openzeppelin/contracts/utils/introspection/IERC165.sol#4)
• ^0.8.0 (@openzeppelin/contracts/utils/math/Math.sol#4)
• ^0.8.0 (@openzeppelin/contracts/utils/math/SignedMath.sol#4)
• ^0.8.0 (erc-payable-token/contracts/token/ERC1363/ERC1363.sol#3)
• ^0.8.0 (erc-payable-token/contracts/token/ERC1363/IERC1363.sol#3)
• ^0.8.0 (erc-payable-token/contracts/token/ERC1363/IERC1363Receiver.sol#3)
• ^0.8.0 (erc-payable-token/contracts/token/ERC1363/IERC1363Spender.sol#3)
• ^0.8.1 (@openzeppelin/contracts/utils/Address.sol#4)

 

Recommendation:

Use one Solidity version.

 

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#different-pragma-directives-are-used

 

Exploit Scenario:

–

 

Alleviation:

Ajira Pay team has Acknowledge this issue.

 

 

SEC-06:  Conformity to Solidity naming conventions (naming-convention)

Type	Severity	Location	Status
Conformity to Solidity naming conventions (naming-convention)	Informational	Check on finding	Acknowledge

 

Finding:

❌ Parameter AjiraPayFinanceToken.burn(address,uint256)._account (AjiraPayFinanceToken.sol:373) is not in mixedCase

Finding:

❌ Parameter AjiraPayFinanceToken.burn(address,uint256)._amount (AjiraPayFinanceToken.sol:373) is not in mixedCase

❌ Parameter AjiraPayFinanceToken.setBuyBackEnabled(bool)._enabled (AjiraPayFinanceToken.sol:364) is not in mixedCase

❌ Variable AjiraPayFinanceToken.DEAD (AjiraPayFinanceToken.sol:209) is not in mixedCase

❌ Variable AjiraPayFinanceToken._isExcludedFromFee (AjiraPayFinanceToken.sol:217) is not in mixedCase

 

Recommendation:

Follow the Solidity [naming convention](https://solidity.readthedocs.io/en/v0.4.25/style-guide.html#naming-conventions).

 

Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#conformance-to-solidity-naming-conventions

 

 

Exploit Scenario:

Solidity defines a naming convention that should be followed.

Rule exceptions

• Allow constant variable name/symbol/decimals to be lowercase (ERC20).
• Allow _ at the beginning of the mixed_case match for private variables and unused parameters.

Follow the Solidity naming convention.

 

Alleviation:

Ajira Pay team has Acknowledge this issue.