Is Portal Safe? Smart Contract Security Analysis

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2377

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: To mitigate the identified risks, it is strongly recommended to implement a multi-signature wallet or a time-locked contract for the `owner` role to decentralize control over critical functions like pausing, disabling permit, and setting the proxy address. This will reduce the single point of failure risk and introduce a necessary delay for sensitive operations. Furthermore, a comprehensive security audit of the external `proxy` contract is crucial, along with clear documentation of its operational procedures and security model. For future flexibility, consider adopting an upgradeable proxy pattern for core contracts to allow for seamless bug fixes and feature enhancements without requiring disruptive token migrations.

Category Ratings

TechnicalMedium

6/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

GovernanceHigh

1/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

UpgradesMedium

6/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

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

9 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Top-10 concentration > 50% (73.9% total → 65.5% effective; 59.8% in EOAs, 14.1% in contracts — heavy)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $10k ($6,610 across 1 pairs — easily drained)
LP top1 unlocked holder = 100.0% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (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

Security Findings

5 total

2 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

Centralized Control by Owner

The `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.

Recommendation: Implement 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.

H-02HighUnresolved

Critical Dependency on External Proxy for Circulating Supply

The `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.

Recommendation: Thoroughly 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.

M-01MediumUnresolved

Lack of Upgradeability

The `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.

Recommendation: For 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.

L-01LowUnresolved

Owner Can Disable Permit Functionality

The `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.

Recommendation: Clearly 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.

I-01InformationalUnresolved

Reliance on Off-Chain Mitigation for Vesting Deposits

The 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.

Recommendation: Implement 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.

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.

Is Portal Safe? PORTAL