Quantum Audit Logo
Launch App

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

Is PinLink Safe?

PINEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance4/10Upgrades6/10Checks passed6 of 7Findings1 Critical · 1 High · 2 Medium · 1 Low5
SummaryAI Copilot

The PinLink token contract implements a standard ERC-20 interface with custom tax mechanisms, anti-bot features, and Uniswap V2 integration.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 20%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
35.8%Contracts10.0%Wallets54.2%Everyone else
35.8%Contracts10.0%54.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
45.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.8%
  • Walletsanonymous holders, free to sell10.0%
  • Everyone elsethe rest of the supply54.2%
Effective concentrationwhat the score reads24.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$543.1K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$542.9KShare of depth100.0%
LP Locked100.0% · UNCX Locker
Top-1 Unlocked Holder0.0%
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.

Security Findings

1 Critical1 High2 Medium1 Low
Critical

Incomplete Source Code for Critical Functions

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

Issue

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

Fix

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

Status

Unresolved

High

High Centralization of Control

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

Issue

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

Fix

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

Status

Unresolved

Medium

Unclear Tax Distribution and Anti-Bot Mechanism Logic

The _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.M-01

Issue

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

Fix

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

Status

Unresolved

Medium

Potential for Max Wallet/Tx Limit Manipulation

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

Issue

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

Fix

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

Status

Unresolved

Low

Redundant Use of SafeMath

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

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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.

Governance4/10Medium risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

A complete and verified source code is essential for a thorough security audit.

Without the full implementation of critical functions like _transfer, multisend, and administrative controls, a comprehensive assessment of the contract's security posture is impossible. It is strongly recommended to provide the complete, deployable source code for all contracts. Furthermore, review the centralized control mechanisms, ensuring that privileged roles are absolutely necessary and that their powers are clearly defined and limited to prevent potential abuse. Implement robust testing, including unit, integration, and fuzz testing, to cover all possible execution paths and edge cases, especially for complex tax and anti-bot logic.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age1y
Contract0x2e44…07c4
Deployer0x8c74…9d62
Badge for your website
PinLink security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202662Medium
  2. Aug 30, 202664Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the PIN contract address?

The PinLink (PIN) contract on Ethereum is 0x2e44f3f609ff5aa4819b323fd74690f07c3607c4. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is PinLink a scam?

Quantum Audit's risk score for PinLink is 62/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is PIN liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $543.1K.

Who holds PIN?

As of Sep 4, 2026, the 10 largest holders own 45.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
SEIEthereum62MediumDolomiteDOLO · Ethereum62MediumRedstoneRED · Ethereum62MediumFuse CatFUSECAT · Ethereum62MediumEtherStreetSTREET · Ethereum62MediumCONDOEthereum62Medium

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 Is this your token? Publish your own audit on this page