Introduction
We express our gratitude to the PinLink team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
PinLink is the first RWA-tokenized DePIN platform, dedicated to driving down costs for AI developers and creating new revenue streams for DePIN asset owners.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for PinLink |
| Audited By | Panagiotis Konstantinidis, Seher Saylik, Andy Cho |
| Approved By | Ataberk Yavuzer |
| Website | http://pinlink.io→ |
| Changelog | 07/08/2024 - Preliminary Report |
| 13/08/2024 - Final Report | |
| 23/09/2025 - Updated Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Staking, Marketplace, Token |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for PinLink
- Audited By
- Panagiotis Konstantinidis, Seher Saylik, Andy Cho
- Approved By
- Ataberk Yavuzer
- Website
- http://pinlink.io→
- Changelog
- 07/08/2024 - Preliminary Report
- 13/08/2024 - Final Report
- 23/09/2025 - Updated Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Staking, Marketplace, Token
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository-1 | https://github.com/PinLinkNetwork/PinLink_SmartContract_PinStaking→ |
| Commit | e95984e |
| Repository-2 | https://github.com/PinLinkNetwork/PinLink_SmartContract_Token→ |
| Commit | 85a40f1 |
Review Scope
- Commit
- e95984e
- Commit
- 85a40f1
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 81.05% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
System Overview
Pinlink is a both staking and a marketplace protocol with the following contracts:
FractionalToken — an ERC-1155–based fractional ownership token contract that lets authorized minters create and extend supply of tokens, enforces rental restrictions via a linked marketplace, and manages per-token metadata.
PinToken — an ERC-20 token with an owner-controlled tax system that mints a fixed supply at deployment and applies different transfer fees—regular, buy/sell via whitelisted DEXs, or tax-exempt—distributing collected taxes between a staking contract and a treasury.
It has the following attributes:
Name: PinLink
Symbol: PIN
Decimals: 18
Total supply: 100000000 tokens.
Marketplace — a rental marketplace for ERC-1155 fractions where a designated renter lists token fractions; users (rentees) rent them by posting ERC-20 collateral and earn hourly rewards in a separate ERC-20 as reward token.
A renter deposits token fractions into the marketplace and specifies the collateral currency, how much collateral must be locked per fraction, and the hourly reward rate that rentees will earn.
While tokens are rented, the rentee accumulates reward tokens based on the number of fractions rented and the defined hourly rate. If the marketplace is paused during the rental, that period is excluded from reward calculations.
The renter can temporarily stop rentals and later resume them. Any paused periods are excluded from rentees’ reward accruals.
PinStaking — a simple, owner-managed staking pool where users lock a single ERC-20 token to earn that same token as rewards, released linearly over configurable reward periods.
Rewards are distributed continuously over time using a global “rewards-per-staked-token” meter to keep earnings fair regardless of when users joined.
An authorized owner funds new reward periods by sending tokens to the contract and specifying a duration (in days).
Any undistributed remainder from a previous period is rolled into the next, ensuring nothing is lost—only the schedule changes.
Privileged roles
FractionalToken
Admin (initial owner): Grants/revokes roles and sets the marketplace address, which holders cannot later revoke.
Minter(s): Can create new token IDs, expand supply, and set metadata.
Marketplace
Admin (initial owner): Assigns or revokes renters.
Renter(s): Control listings, set collateral/reward rates, pause/resume rentals, delist items, and enforce returns.
PinToken
Owner: Can set staking/treasury addresses, adjust taxes (within limits), whitelist DEXs, and mark accounts tax-exempt.
PinStaking
Owner: Starts new reward periods and determines size/duration of emissions (cannot withdraw once funded).
Risks
Centralized Control: The FractionalToken is designed to be minted only by the MINTER_ROLE. However, this allows for centralized control over the minting process and poses a risk of unauthorized token issuance.
In Marketplace contract, renters set all economic parameters (collateral, reward rates) and can pause/resume rentals or delist assets, potentially disrupting rentees.
In FractionalToken contract, the admin can set a new marketplace address at any time. Because holders cannot revoke marketplace approvals, this exposes users to forced reliance on whichever external contract the admin chooses.
The FractionalToken contract allows addresses with the MINTER_ROLE to arbitrarily mint new tokens without any enforced cap. Since the admin can assign this role at will, the token supply is fully centralized and subject to uncontrolled inflation,
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1280 | Overpayment on Repeat Rentals Due to Using New tokenAmount for Accrued Rewards | accepted | Critical | |
| F-2025-1282 | Future Pauses Immediately Block New Rentals | accepted | High | |
| F-2025-1282 | Incorrect Reward Accrual Due to Premature resume() Calls with Future Timestamps | accepted | High | |
| F-2025-1281 | Mint Reverts When marketplace Is Set due to underflow in _preUpdate function during mint operations | accepted | High | |
| F-2025-1281 | Delist Fails for Never Rented Items Leaving Tokens Stuck in Contract | accepted | High | |
| F-2025-1281 | Partial Returns Reset startTime Causing Underpaid Rewards on Remaining Balance | accepted | High | |
| F-2025-1282 | Incompatibility With Pin Fee-On-Transfer Token | mitigated | Medium | |
| F-2025-1281 | Misconfigured Minimum Token Amount Check Causes Inconsistent Logic | accepted | Medium | |
| F-2025-1274 | Only One Listing Allowed Per ERC-1155 Token ID | accepted | Medium | |
| F-2025-1281 | Unsafe Downcasting From uint256 To uint128 In Reward Calculations | accepted | Low |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository-1 | https://github.com/PinLinkNetwork/PinLink_SmartContract_PinStaking→ |
| Commit | e95984e98ccfa163a16b64245e2fb2baeded4fe4 |
| Repository-2 | https://github.com/PinLinkNetwork/PinLink_SmartContract_Token→ |
| Commit | 85a40f1b07a8c30ad0559dfb65ca8c9b54faab0d |
| README.md | N/A |
| Technical Requirements | README.md |
Scope Details
- Commit
- e95984e98ccfa163a16b64245e2fb2baeded4fe4
- Commit
- 85a40f1b07a8c30ad0559dfb65ca8c9b54faab0d
- README.md
- N/A
- Technical Requirements
- README.md