Quantum Audit Logo

Is Portal Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Portal PORTAL
0x1bbe…1fed
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The PortalToken contract is an ERC20 token leveraging OpenZeppelin extensions for permit, pausable, and burnable functionalities. It introduces a custom mechanism to calculate circulating supply by subtracting tokens held by a designated proxy address. The audit identified significant centralization risks due to the owner's extensive control over critical functions, and a high dependency on an external proxy contract for accurate circulating supply reporting, which could impact the token's economic stability and market perception.

2 High1 Medium1 Low1 Informational
Volume 24h
$281.1600
Liquidity
$5.8K
Price
$0.01629
Token Age
2y
Top 10 Holders
74.1%

Security Findings

2 High1 Med1 Low1 Info
High

Centralized Control by Owner

H-01The `owner` role has extensive control over critical token functions, including pausing transfers (`pause`), enabling/disabling permit functionality (`disablePermit`), and setting the `proxy` address (`setProxyAddress`) which directly impacts the reported `totalSupply`. A compromise of the owner's private key could lead to a complete halt of token operations, manipulation of circulating supply, or disruption of user interactions.
IssueThe `owner` role has extensive control over critical token functions, including pausing transfers (`pause`), enabling/disabling permit functionality (`disablePermit`), and setting the `proxy` address (`setProxyAddress`) which directly impacts the reported `totalSupply`. A compromise of the owner's private key could lead to a complete halt of token operations, manipulation of circulating supply, or disruption of user interactions.
FixImplement a multi-signature wallet or a time-locked contract for the `owner` role to introduce a delay and require multiple approvals for critical operations. This decentralizes control and reduces the risk associated with a single point of failure.
StatusUnresolved
High

Critical Dependency on External Proxy for Circulating Supply

H-02The `totalSupply()` function is overridden to subtract the balance held by a `proxy` address, intended for cross-chain functionality. The security and integrity of the `PortalToken`'s reported circulating supply are critically dependent on the correct functioning and security of this external `proxy` contract. A malicious or compromised `proxy` could manipulate the perceived circulating supply, leading to economic instability or misrepresentation.
IssueThe `totalSupply()` function is overridden to subtract the balance held by a `proxy` address, intended for cross-chain functionality. The security and integrity of the `PortalToken`'s reported circulating supply are critically dependent on the correct functioning and security of this external `proxy` contract. A malicious or compromised `proxy` could manipulate the perceived circulating supply, leading to economic instability or misrepresentation.
FixThoroughly audit the external `proxy` contract to ensure its robustness and security. Implement strong access controls and monitoring for the `proxy` address. Clearly document the operational procedures and security model of the `proxy` and consider mechanisms to revoke or update the `proxy` address in a secure, multi-party controlled manner.
StatusUnresolved
Medium

Lack of Upgradeability

M-01The `PortalToken` contract is deployed as a standard implementation without any built-in upgradeability mechanism (e.g., UUPS, Transparent proxies). This means that any future bug fixes, security patches, or feature enhancements would necessitate deploying an entirely new token contract and migrating all existing token holders, which is a complex, costly, and disruptive process.
IssueThe `PortalToken` contract is deployed as a standard implementation without any built-in upgradeability mechanism (e.g., UUPS, Transparent proxies). This means that any future bug fixes, security patches, or feature enhancements would necessitate deploying an entirely new token contract and migrating all existing token holders, which is a complex, costly, and disruptive process.
FixFor long-term projects, consider implementing an upgradeable proxy pattern (e.g., UUPS) to allow for future contract modifications without requiring a full token migration. If upgradeability is not desired, ensure the current implementation is extremely robust and thoroughly tested.
StatusUnresolved
Low

Owner Can Disable Permit Functionality

L-01The `disablePermit` function allows the owner to enable or disable the ERC20 Permit functionality. While this is an intended feature, disabling `permit` could disrupt user experience or integrations that rely on gasless approvals. This power is centralized with the owner.
IssueThe `disablePermit` function allows the owner to enable or disable the ERC20 Permit functionality. While this is an intended feature, disabling `permit` could disrupt user experience or integrations that rely on gasless approvals. This power is centralized with the owner.
FixClearly communicate the operational policy regarding the `permitEnabled` state. Consider if this control needs to be managed by a multi-sig or a more decentralized mechanism if the project aims for progressive decentralization.
StatusUnresolved
Info

Reliance on Off-Chain Mitigation for Vesting Deposits

I-01The constructor's comment states that "potential address duplication is mitigated by the deployment scripts" for `vestingDeposits`. This indicates a reliance on off-chain processes to ensure correct initial token distribution. While not a direct contract vulnerability, a failure in the deployment script could lead to unintended initial token allocations.
IssueThe constructor's comment states that "potential address duplication is mitigated by the deployment scripts" for `vestingDeposits`. This indicates a reliance on off-chain processes to ensure correct initial token distribution. While not a direct contract vulnerability, a failure in the deployment script could lead to unintended initial token allocations.
FixImplement on-chain validation or a more robust deployment process to prevent potential issues with `vestingDeposits` duplication or errors, if possible. Ensure deployment scripts are thoroughly tested and reviewed.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin libraries for its core ERC20, Ownable, Permit, Pausable, and Burnable functionalities, ensuring a solid foundation (7.2 Code Security). The custom `totalSupply()` implementation, which subtracts tokens held by a `proxy` address, introduces a critical external dependency (7.1 Architecture, 7.6 External). The `permit` function includes an owner-controlled enable/disable switch, adding flexibility but also a point of control (7.3 Access Control).

GovernanceHigh1/10

The token's economic model is a straightforward ERC20 with a fixed total supply and initial distribution to vesting addresses and a treasury. However, the `owner` role holds highly centralized control over critical functions such as pausing transfers, disabling permit functionality, and setting the proxy address (7.5 Governance, 7.8 Operations). The circulating supply calculation's reliance on an external `proxy` contract introduces a significant economic risk if the proxy is compromised or mismanaged (7.4 Economic).

UpgradesMedium6/10

The `PortalToken` contract is deployed as a standard, non-upgradeable implementation (7.7 Upgrades). This design choice means that any future bug fixes, security patches, or feature enhancements would necessitate a complete redeployment of the token and a complex migration process for existing token holders. This lack of flexibility could pose challenges for long-term project evolution.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

74.1% in top 10
61.6% in wallets12.5% in contracts
Effective Concentration66.6%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$5.8K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder87.0%
Top-3 Unlocked95.7%

Key Addresses

11 addresses
Deployer
0x96e3…43b8
Unlocked LP Held By
0xb9a1…5d270xf667…dd150x4f8a…0bb20xf1e5…a56e0x80fb…6cf60x61c9…619e0xcd2a…6f840x6647…8f4e0x090a…da6e0x7542…116c

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

9 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 50% (74.1% total → 66.6% effective; 61.6% in EOAs, 12.5% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $10k ($5,753 across 1 pairs — easily drained)
  • LP top1 unlocked holder = 87.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 95.7% (independent LP — depth risk)
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Frequently Asked Questions

Is Portal a scam?

Based on the provided data, we cannot definitively label Portal a scam. However, it exhibits significant red flags often associated with high-risk projects. The high-risk score of 67/100, combined with unrenounced ownership, unlocked liquidity, and extreme token concentration, indicates a strong potential for investor losses due to developer action or market manipulation rather than a secure investment. Investors should proceed with extreme caution.

Is Portal safe to buy?

Portal is not considered safe to buy based on its current security profile and high-risk score of 67/100. Key risk factors include unrenounced contract ownership, allowing potential malicious changes, and unlocked liquidity, which enables a 'rug pull' by liquidity providers. The highly concentrated token supply, with 66.0% held by the top 10, also poses a significant risk of price manipulation. These factors indicate substantial investment risks.

Has Portal been audited?

The Portal token contract is verified, meaning its code is publicly available for anyone to review on the blockchain explorer. This transparency is beneficial. However, contract verification is not the same as a professional security audit. An independent security audit involves a thorough review by experts to identify vulnerabilities, logical flaws, and potential attack vectors beyond just code visibility. The provided data does not indicate that Portal has undergone such an audit.

Related Audits

6 more on the record
Nillion (NIL)Critical RiskSynapse (SYN)Critical RiskTurtleCritical RiskAutonolas (OLAS)Critical RiskSyrup Token (SYRUP)Critical RiskChipCritical Risk

Would You Like a More Detailed Audit of Portal?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit