Quantum Audit Logo

Is PinLink Safe?

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

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

PinLink PIN
0x2e44…07c4
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The PinLink token contract implements a standard ERC-20 interface with custom tax mechanisms, anti-bot features, and Uniswap V2 integration. A critical limitation of this audit is the provided source code being truncated, particularly for the core `_transfer` function and other administrative functions. This prevents a comprehensive security analysis of the contract's full functionality and potential vulnerabilities. Based on the available code, significant centralization of control and complexity in the partially visible tax/anti-bot logic are noted.

1 Critical1 High2 Medium1 Low
Volume 24h
$120.8K
Liquidity
$542.9K
Price
$0.05789
Token Age
1y
Top 10 Holders
45.8%

Security Findings

1 Crit1 High2 Med1 Low
Critical

Incomplete Source Code for Critical Functions

C-01The provided source code for the `PinLink` contract is truncated. Specifically, the core `_transfer` function, which contains the token's custom tax, anti-bot, and transfer logic, is incomplete. Additionally, the `multisend` function (inherited from `IMultisend`) and other potential administrative functions are missing. This prevents a comprehensive security analysis of the contract's full functionality, making it impossible to identify potential vulnerabilities such as reentrancy, logic errors, or economic exploits within these critical components.
IssueThe provided source code for the `PinLink` contract is truncated. Specifically, the core `_transfer` function, which contains the token's custom tax, anti-bot, and transfer logic, is incomplete. Additionally, the `multisend` function (inherited from `IMultisend`) and other potential administrative functions are missing. This prevents a comprehensive security analysis of the contract's full functionality, making it impossible to identify potential vulnerabilities such as reentrancy, logic errors, or economic exploits within these critical components.
FixProvide the complete and verifiable source code for all contracts, including all inherited interfaces and libraries. Ensure that the provided code accurately reflects the deployed contract's logic. A full audit cannot be conducted without complete source code.
StatusUnresolved
High

High Centralization of Control

H-01The contract grants significant power to privileged addresses, specifically the `owner`, `_controller`, and `devWallet`. The `owner` has exclusive control over critical functions such as `openTrading`, which initializes Uniswap liquidity and enables token swaps. While the full extent of control is unclear due to truncated code, such centralization often allows privileged users to modify key parameters (e.g., tax rates, max transaction/wallet limits, fee exclusions) or even disable anti-bot mechanisms, posing a risk of rug-pulls or arbitrary changes to tokenomics.
IssueThe contract grants significant power to privileged addresses, specifically the `owner`, `_controller`, and `devWallet`. The `owner` has exclusive control over critical functions such as `openTrading`, which initializes Uniswap liquidity and enables token swaps. While the full extent of control is unclear due to truncated code, such centralization often allows privileged users to modify key parameters (e.g., tax rates, max transaction/wallet limits, fee exclusions) or even disable anti-bot mechanisms, posing a risk of rug-pulls or arbitrary changes to tokenomics.
FixEvaluate the necessity of each privileged role and its associated powers. Consider implementing a multi-signature wallet for critical administrative actions to distribute control and reduce single points of failure. If parameters are mutable, clearly document and implement robust access control for their modification. For critical actions like `openTrading`, consider a time-locked execution or a community-governed mechanism if applicable.
StatusUnresolved
Medium

Unclear Tax Distribution and Anti-Bot Mechanism Logic

M-01The `_transfer` function, which is central to the token's tax and anti-bot logic, is incomplete. Variables such as `ethSendThresholdDivisor`, `totalRatio`, and `disableAddToBlocklist` are declared but their full impact and interaction within the tax distribution and anti-bot system are not visible. This lack of clarity makes it difficult to assess the correctness and security of these mechanisms, potentially hiding vulnerabilities, leading to unexpected behavior, or allowing for manipulation of tax collection and distribution.
IssueThe `_transfer` function, which is central to the token's tax and anti-bot logic, is incomplete. Variables such as `ethSendThresholdDivisor`, `totalRatio`, and `disableAddToBlocklist` are declared but their full impact and interaction within the tax distribution and anti-bot system are not visible. This lack of clarity makes it difficult to assess the correctness and security of these mechanisms, potentially hiding vulnerabilities, leading to unexpected behavior, or allowing for manipulation of tax collection and distribution.
FixProvide the complete `_transfer` function and any related administrative functions. Clearly document the purpose and interaction of all variables involved in the tax and anti-bot mechanisms. Ensure that tax calculations are precise, prevent division by zero, and that tax distribution to `taxWallets` is robust and cannot be manipulated. Verify that anti-bot measures are effective and cannot be bypassed or abused.
StatusUnresolved
Medium

Potential for Max Wallet/Tx Limit Manipulation

M-02The contract implements `maxTxRatio` and `maxWalletRatio` to limit transaction sizes and wallet holdings, respectively. These are set in the constructor. While intended to prevent large transactions and whale accumulation, the truncated `_transfer` logic makes it impossible to fully verify their effectiveness. Without the complete code, it's unclear if these limits can be bypassed (e.g., through flash loans, multiple small transactions, or specific excluded addresses) or if their values can be changed post-deployment by a privileged user, potentially leading to unfair advantages or market manipulation.
IssueThe contract implements `maxTxRatio` and `maxWalletRatio` to limit transaction sizes and wallet holdings, respectively. These are set in the constructor. While intended to prevent large transactions and whale accumulation, the truncated `_transfer` logic makes it impossible to fully verify their effectiveness. Without the complete code, it's unclear if these limits can be bypassed (e.g., through flash loans, multiple small transactions, or specific excluded addresses) or if their values can be changed post-deployment by a privileged user, potentially leading to unfair advantages or market manipulation.
FixProvide the complete `_transfer` function and any related administrative functions. Thoroughly review the implementation of `maxTxRatio` and `maxWalletRatio` to ensure they are robust against bypasses. If these limits are mutable, implement strict access control and potentially a time-lock for changes. Consider edge cases where these limits might inadvertently block legitimate users or create denial-of-service vectors.
StatusUnresolved
Low

Redundant Use of SafeMath

L-01The contract uses OpenZeppelin's `SafeMath` library for arithmetic operations. However, for Solidity versions 0.8.0 and higher (the contract uses `^0.8.15`), arithmetic operations automatically revert on overflow and underflow. This makes the explicit use of `SafeMath` redundant, as the compiler provides native overflow/underflow protection. While not a vulnerability, it adds unnecessary code complexity and slightly increases gas costs due to additional function calls.
IssueThe contract uses OpenZeppelin's `SafeMath` library for arithmetic operations. However, for Solidity versions 0.8.0 and higher (the contract uses `^0.8.15`), arithmetic operations automatically revert on overflow and underflow. This makes the explicit use of `SafeMath` redundant, as the compiler provides native overflow/underflow protection. While not a vulnerability, it adds unnecessary code complexity and slightly increases gas costs due to additional function calls.
FixConsider removing the `SafeMath` library and relying on Solidity's native overflow/underflow checks for contracts compiled with `^0.8.0` or higher. This will simplify the code and potentially reduce gas consumption without compromising security.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture (7.1) is a standard ERC-20 token with custom transfer logic, integrating OpenZeppelin libraries and Uniswap V2. Code security (7.2) is severely hampered by truncated source code, making a full assessment impossible. The partial `_transfer` function reveals complex conditional logic for taxes and anti-bot measures, increasing the attack surface. The use of `SafeMath` is redundant in Solidity 0.8+, but not a vulnerability. Without the full code, potential reentrancy, integer issues, or other logic flaws within the core transfer mechanism cannot be fully evaluated. The `permit` function is inherited but its implementation is not provided.

GovernanceMedium4/10

The contract exhibits high centralization (7.3 Access Control, 7.5 Governance) with `onlyOwner`, `onlyERC20Controller`, and `onlyDev` modifiers granting significant power to privileged addresses. The owner can `openTrading`, which initializes liquidity and enables swaps, a critical function. Economic parameters (7.4) like `buyTax`, `sellTax`, `maxTxRatio`, and `maxWalletRatio` are set in the constructor. The mutability of these parameters and the full scope of control over tax wallets and exclusion lists are unclear due to truncated code. The `disableAddToBlocklist` variable implies a powerful anti-bot mechanism, but its associated functions are missing, raising concerns about potential abuse or single points of failure. The `ethSendThresholdDivisor` and `totalRatio` variables are declared but their economic impact is not fully visible.

UpgradesMedium6/10

The PinLink contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard implementation contract, meaning its logic cannot be modified after deployment. This eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade paths. However, it also means that any discovered vulnerabilities or desired feature changes would require a new contract deployment and token migration.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

45.8% in top 10
10.0% in wallets35.8% in contracts
Effective Concentration24.3%

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

$543.1K across 2 pairs
Uniswap v3WETHanalysed$542.9K100.0%Uniswap v2WETH$2470.0%

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

LP Locked100.0% · UNCX Locker
Top-1 Unlocked Holder0.0%

Key Addresses

4 addresses
Deployer
0x8c74…9d62
Unlocked LP Held By
0xccfb…3efe0x20ab…35fa0x5eb5…3af0

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

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 20% (45.8% total → 24.3% effective; 10.0% in EOAs, 35.8% in contracts — mild)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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

Related Audits

6 more on the record
SEIHigh RiskDolomite (DOLO)High RiskRedstone (RED)High RiskSPACE ID (ID)High RiskHarryPotterObamaSonic10Inu (BITCOIN)High RiskUSDS Stablecoin (USDS)High Risk

Would You Like a More Detailed Audit of PinLink?

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

Get Detailed Audit