Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report

Audit name:

[SCA] PinLink | Smart-Contract | Aug2024

Date:

Sep 23, 2025

Table of Content

Introduction
Audit Summary
System Overview
Risks
Findings
Appendix 1. Severity Definitions
Appendix 2. Scope
Disclaimer

Want a comprehensive audit report like this?

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

NameSmart Contract Code Review and Security Analysis Report for PinLink
Audited ByPanagiotis Konstantinidis, Seher Saylik, Andy Cho
Approved ByAtaberk Yavuzer
Websitehttp://pinlink.io
Changelog07/08/2024 - Preliminary Report
13/08/2024 - Final Report
23/09/2025 - Updated Final Report
PlatformEthereum
LanguageSolidity
TagsStaking, Marketplace, Token
Methodologyhttps://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
    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

Audit Summary

15Total Findings
4Resolved
10Accepted
1Mitigated

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-1280Overpayment on Repeat Rentals Due to Using New tokenAmount for Accrued Rewards
accepted

Critical
F-2025-1282Future Pauses Immediately Block New Rentals
accepted

High
F-2025-1282Incorrect Reward Accrual Due to Premature resume() Calls with Future Timestamps
accepted

High
F-2025-1281Mint Reverts When marketplace Is Set due to underflow in _preUpdate function during mint operations
accepted

High
F-2025-1281Delist Fails for Never Rented Items Leaving Tokens Stuck in Contract
accepted

High
F-2025-1281Partial Returns Reset startTime Causing Underpaid Rewards on Remaining Balance
accepted

High
F-2025-1282Incompatibility With Pin Fee-On-Transfer Token
mitigated

Medium
F-2025-1281Misconfigured Minimum Token Amount Check Causes Inconsistent Logic
accepted

Medium
F-2025-1274Only One Listing Allowed Per ERC-1155 Token ID
accepted

Medium
F-2025-1281Unsafe Downcasting From uint256 To uint128 In Reward Calculations
accepted

Low
1-10 of 15 findings

Identify vulnerabilities in your smart contracts.

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-1https://github.com/PinLinkNetwork/PinLink_SmartContract_PinStaking
Commite95984e98ccfa163a16b64245e2fb2baeded4fe4
Repository-2https://github.com/PinLinkNetwork/PinLink_SmartContract_Token
Commit85a40f1b07a8c30ad0559dfb65ca8c9b54faab0d
README.mdN/A
Technical RequirementsREADME.md

Contracts in Scope

PinLink_SmartContract_PinStaking
src
PinStaking.sol - PinLink_SmartContract_PinStaking › src › PinStaking.sol
rewardsPeriod.sol - PinLink_SmartContract_PinStaking › src › rewardsPeriod.sol
PinLink_SmartContract_Token
src
fractional
FractionalToken.sol - PinLink_SmartContract_Token › src › fractional › FractionalToken.sol
marketplace
Marketplace.sol - PinLink_SmartContract_Token › src › marketplace › Marketplace.sol
IMarketplace.sol - PinLink_SmartContract_Token › src › marketplace › IMarketplace.sol
token
PinToken.sol - PinLink_SmartContract_Token › src › token › PinToken.sol

Disclaimer