
AuditHaze
Porcemic
Audit Score
Always perform your own due diligence before interacting with any smart contract.
Owner can mint?
No mint function
This refers to the ability of the contract owner to produce additional tokens within the contract's framework.
Owner can blacklist?
No blacklist found
This indicates whether the owner has the authority to block certain addresses from interacting with the contract's ecosystem.
Can be a honeypot?
No honeypot option
This describes a situation where the contract might prevent token holders from selling their assets, potentially trapping their funds.
Owner can set fees?
No high sell fees
This refers to the owner's ability to adjust the maximum sell fee applied to transactions within the contract.
Trading enabled?
Trading enabled
This indicates whether trading is already enabled or if the owner must perform an action to allow trading to begin.
Detailed Analysis
Tokenomics
Token Supply
Fixed supply, no minting
Transaction Fee
Buy Fee
Sell Fee
Max Wallet
No maximum restriction
Max Transaction
No maximum restriction
Liquidity Lock
After launch (DYOR)
Team Vesting
Read whitepaper
Total Holders
Updated live from contract
Token Distribution
Contract Functions
Standard ERC-20 Functions
Custom Contract Functions
Security Checks
Vulnerability | Status | Details |
---|---|---|
Re-entrancy | SAFE | No external calls before state changes |
Integer Overflow/Underflow | SAFE | Uses SafeMath or Solidity ≥0.8 |
Ownership Renouncement | WARNING | Owner has not renounced control |
Blacklist Capability | SAFE | No blacklist |
Arbitrary Minting | SAFE | No mint |
Trading Lock | SAFE | No trading lock function |
Max Transaction Limit | SAFE | No limit |
Upgradable Contract | SAFE | No proxy contract |
Honeypot Behavior | SAFE | No logic found to block selling |
Access Control | SAFE | OnlyOwner pattern properly implemented |
External Call Risks | SAFE | External contract calls are protected by checks |
Centralization Risks
Owner Address Privileges
Owner has access to critical functions such as minting and fee setting.
SAFEUpgradable Proxy
Contract logic can be changed through a proxy pattern controlled by the team.
SAFEMinting Function
Owner or privileged role can mint additional tokens post-deployment.
SAFETrading Enable/Disable
Owner has control over enabling or pausing trading.
SAFEFee Configuration Rights
Fee rates can be adjusted by a privileged address.
SAFEBlacklist Mechanism
Owner can blacklist user wallets arbitrarily.
SAFEOwnership Renounced
Ownership has been renounced, reducing central control.
WARNINGWhitelist Address Control
Certain addresses have privileges others do not.
SAFERestricted Functions
Only specific roles can call important contract functions.
SAFEEmergency Withdraw
Owner can withdraw contract funds instantly.
SAFEContract Overview Checklist
The code was tested with compatible compilers and simulated manually reviewed for all commonly known and specific vulnerabilities.
Vulnerability Checklist
Vulnerability Description | Status |
---|---|
Visibility of functions and variables | Passed |
Compiler error | Passed |
ROI Investment Plan | Passed |
Transfer Block | Passed |
Floating pragma | Passed |
Timestamp dependence | Passed |
Deprecated solidity functions | Passed |
Gas limit and loops | Passed |
Front running | Passed |
User balance manipulation | Passed |
Dos with revert | Passed |
Dos with block gas limit | Passed |
Reentrancy security | Passed |
Malicious libraries | Passed |
Integer overflow/underflow | Passed |
Using inline assembly | Passed |
Missing event emission | Passed |
Missing zero address validation | Passed |
Use of tx.origin | Passed |
Oracle security | Passed |
Outdated compiler version | Passed |
Block values as a proxy for time | Passed |
Presence of unused code | Passed |
Data consistency | Passed |
Money giving bug | Passed |
Unnecessary use of SafeMath | Passed |
Self-destruct interaction | Passed |
Signature unique id | Passed |
Weak sources of randomness | Passed |
Optimize code and efficient gas fee | Passed |
Owner Privileges
The list of functions in the contract that only the owner can call:
- activateProject()
- setMaxSearchAddress()
SWC Checklist
ID | Severity | Name | File Location |
---|---|---|---|
SWC-100 | Pass | Function Default Visibility | L: 0 C: 0 |
SWC-101 | Pass | Integer Overflow and Underflow | L: 0 C: 0 |
SWC-102 | Pass | Outdated Compiler Version | L: 0 C: 0 |
SWC-103 | Pass | A floating pragma is set | L: 0 C: 0 |
SWC-104 | Pass | Unchecked Call Return Value | L: 0 C: 0 |
SWC-105 | Pass | Unprotected Ether Withdrawal | L: 0 C: 0 |
SWC-106 | Pass | Unprotected SELFDESTRUCT Instruction | L: 0 C: 0 |
SWC-107 | Pass | Read of persistent state following external call | L: 0 C: 0 |
SWC-108 | Pass | State variable visibility is not set | L: 0 C: 0 |
SWC-109 | Pass | Uninitialized Storage Pointer | L: 0 C: 0 |
SWC-110 | Pass | Assert Violation | L: 0 C: 0 |
SWC-111 | Pass | Use of Deprecated Solidity Functions | L: 0 C: 0 |
SWC-112 | Pass | Delegate Call to Untrusted Callee | L: 0 C: 0 |
SWC-113 | Pass | Multiple calls are executed in the same transaction | L: 0 C: 0 |
SWC-114 | Pass | Transaction Order Dependence | L: 0 C: 0 |
SWC-115 | Pass | Authorization through tx.origin | L: 0 C: 0 |
SWC-116 | Pass | A control flow decision is made based on The block.timestamp environment variable | L: 0 C: 0 |
SWC-117 | Pass | Signature Malleability | L: 0 C: 0 |
SWC-118 | Pass | Incorrect Constructor Name | L: 0 C: 0 |
SWC-119 | Pass | Shadowing State Variables | L: 0 C: 0 |
SWC-120 | Pass | Potential use of block.number as source of randomness | L: 0 C: 0 |
SWC-121 | Pass | Missing Protection against Signature Replay Attacks | L: 0 C: 0 |
SWC-122 | Pass | Lack of Proper Signature Verification | L: 0 C: 0 |
SWC-123 | Pass | Requirement Violation | L: 0 C: 0 |
SWC-124 | Pass | Write to Arbitrary Storage Location | L: 0 C: 0 |
SWC-125 | Pass | Incorrect Inheritance Order | L: 0 C: 0 |
SWC-126 | Pass | Insufficient Gas Griefing | L: 0 C: 0 |
SWC-127 | Pass | Arbitrary Jump with Function Type Variable | L: 0 C: 0 |
SWC-128 | Pass | DoS With Block Gas Limit | L: 0 C: 0 |
SWC-129 | Pass | Typographical Error | L: 0 C: 0 |
SWC-130 | Pass | Right-To-Left-Override control character (U+202E) | L: 0 C: 0 |
SWC-131 | Pass | Presence of unused variables | L: 0 C: 0 |
SWC-132 | Pass | Unexpected Ether balance | L: 0 C: 0 |
SWC-133 | Pass | Hash Collisions with Multiple Variable Length Arguments | L: 0 C: 0 |
SWC-134 | Pass | Message call with hardcoded gas amount | L: 0 C: 0 |
SWC-135 | Pass | Code With No Effects (Irrelevant/Dead Code) | L: 0 C: 0 |
SWC-136 | Pass | Unencrypted Private Data On-Chain | L: 0 C: 0 |
PORCEM Checklist
ID | Severity | Name | Result | Status |
---|---|---|---|---|
$PORCEM-01 | Minor | Potential Sandwich Attacks | Pass | Not-Found |
$PORCEM-02 | Minor | Function Visibility Optimization | Pass | Not-Found |
$PORCEM-03 | Minor | Lack of Input Validation | Pass | Not-Found |
$PORCEM-04 | Major | Centralized Risk In addLiquidity | Pass | Not-Found |
$PORCEM-05 | Minor | Missing Event Emission | Pass | Not-Found |
$PORCEM-06 | Minor | Conformance with Solidity Naming Conventions | Pass | Not-Found |
$PORCEM-07 | Minor | State Variables could be Declared Constant | Pass | Not-Found |
$PORCEM-08 | Minor | Dead Code Elimination | Pass | Not-Found |
$PORCEM-09 | Major | Third Party Dependencies | Pass | Not-Found |
$PORCEM-10 | Major | Initial Token Distribution | Pass | Not-Found |
$PORCEM-11 | Major | Complexity on the tax calculations | Pass | Not-Found |
$PORCEM-12 | Major | Centralization Risks In The X Role | Pass | Not-Found |
$PORCEM-13 | Informational | Extra Gas Cost For User | Pass | Not-Found |
$PORCEM-14 | Medium | Unnecessary Use Of SafeMath | Pass | Not-Found |
$PORCEM-15 | Medium | Symbol Length Limitation due to Solidity Naming Standards | Pass | Not-Found |
$PORCEM-16 | Medium | Invalid collection of Taxes during Transfer | Pass | Not-Found |
$PORCEM-17 | Informational | Conformance to numeric notation best practice | Pass | Not-Found |
$PORCEM-18 | Informational | Enable Trade and Exclude Exist to create a whitelist | Pass | Not-Found |
This report has been prepared for PORCEM Token. AuditHaze provides both client-centered and user-centered examination of the smart contracts and their current status when applicable. This report represents the security assessment made to find issues and vulnerabilities on the source code along with the current liquidity and token holder statistics of the protocol.
A comprehensive examination has been performed, utilizing Cross Referencing, Static Analysis, In-House Security Tools, and line-by-line Manual Review.
The auditing process pays special attention to the following considerations:
- Testing the smart contracts against both common and uncommon attack vectors.
- Inspecting liquidity and holders statistics to inform the current status to both users and client when applicable.
- Assessing the codebase to ensure compliance with current best practices and industry standards.
- Verifying contract functions that allow trusted and/or untrusted actors to mint, lock, pause, and transfer assets.
- Cross referencing contract structure and implementation against similar smart contracts produced by industry leaders.
- Thorough line-by-line manual review of the entire codebase by industry experts.
Audit Timeline
Initial Contract Submission
Contract submitted for security audit
Automated Analysis
Static analysis and automated vulnerability scanning completed
Manual Code Review
Line-by-line code review by security experts
Final Report
Audit completed and final report published