Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

ShopinX Info

shopinx.io

The global retail industry is undergoing a significant transformation as customer acquisition and retention costs reach historic highs. Brands continue allocating billions of dollars to loyalty initiatives in an effort to retain customers within their ecosystems. However, a substantial portion of consumers ultimately abandon these programs due to the limited flexibility and utility of closed-loop reward structures. At the core of this challenge lies the traditional database architecture underpinning most loyalty systems, which prevents true user ownership and restricts the free movement of rewards and value across independent networks.

ShopinX Logo
Onboarded date 23/04/2026

Team and KYC Verification

The team has securely submitted their personal information to SolidProof.io for verification.

In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

88.71
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2026/04/23
Revision date 2026/06/15

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner can blacklist addresses

It is possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Token transfer can be locked

Owner can lock user funds with owner functions.

Token can be burned

There is a function to burn tokens in the contract without any allowances.

Ownership is not renounced

The owner retains significant control, which could potentially be used to modify key contract parameters.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Smart Contract Analysis Statement

Contract Analysis

The ShopinX Token contract implements an ERC20 token with a fixed, non-mintable supply minted once at deployment, burnable balances, EIP-2612 permit approvals for signature-based allowances, owner-controlled time locks, and a built-in cliff-plus-step vesting mechanism. The token is built on top of well-established OpenZeppelin components, and the project-specific logic is concentrated in the transfer gate that enforces the locks and the vesting schedules.

Ownership Privileges

The ownership of the contract has been retained under a two-step ownership-transfer process, with the ability to renounce ownership deliberately disabled so the contract cannot be left without an administrator. We recommend that ownership be assigned to a multi-signature wallet, ideally fronted by a timelock, given the operational powers described below. The owner retains full privileges including:

  • Freezing the entire balance of any address for a bounded period through the full-address lock.
  • Distributing tokens together with an amount-based lock that applies only to the transferred tranche.
  • Creating a cliff-plus-step vesting schedule for any address.
  • Removing a previously applied full-address freeze to correct mistakes.
  • The owner cannot create new tokens after deployment, as the total supply is fixed at the initial mint and there is no minting function.
  • The owner cannot move or seize tokens already held by other addresses, since administrative transfers are funded only from the owner's own balance.
  • The owner cannot lock an address indefinitely, as the maximum lock duration is capped at four years.
  • The owner cannot alter or cancel a vesting schedule once it has been created.

Security Features

The contract implements several positive security features:

  • It builds on widely used, community-reviewed OpenZeppelin token, ownership, and signature components rather than reimplementing this functionality from scratch.
  • The compiler version is pinned to an exact release, and the Solidity 0.8 series provides built-in protection against arithmetic overflow and underflow.
  • Ownership uses a two-step handover and the renounce path is disabled, which reduces the risk of accidental or irreversible loss of administrative control.
  • Administrative locks are bounded in time and reversible, every privileged function validates its inputs, and the public availability view is kept consistent with the rules enforced on actual transfers.

Review Summary

This contract was reviewed across successive iterations, and the current version represents a substantial improvement over the earlier ones. The higher-severity issues raised previously - the ability to freeze an address permanently, and a transfer lock that applied to a recipient's entire balance rather than only the tokens being distributed - have been resolved: locks are now time-bounded and reversible, and a transfer lock now affects only the amount actually sent. The medium-severity items have also been addressed, partly through code changes and partly through explicit design decisions that are now documented in the source. The items that remain open are low-severity or informational, and are largely product and operational decisions, such as confirming the intended vesting release pattern, deciding whether vesting should be revocable, and publishing the administrative addresses, together with one minor correctness note regarding repeated use of the amount-based lock on the same address. None of the remaining items prevent a safe deployment, provided the operational recommendations are followed.

Note - This Audit report consists of a security analysis of the ShopinX Token smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the ShopinX Token team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Findings and Audit result

Critical
High
Medium
1
Low
Optimization
8
Informational
high Issues | 2 findings

Resolved

#1 high Issue
Owner can irreversibly freeze any holder via setLock
src/v3/ShopinXToken.sol
L64-76
Description

setLock accepts any unlockTime strictly greater than block.timestamp, with no upper bound. Combined with the invariant that a lock can only ever be extended, never reduced, this allows the owner to call setLock(victim, type(uint256).max) and freeze every token the victim currently holds as well as every token they ever receive afterwards, because _update uses lockUntil[from] as the authoritative gate on every outgoing transfer. The freeze cannot be reduced or removed by any party afterwards, not even the owner, because of the monotonic-only rule.

Comments

Introduce an upper bound on unlockTime (for example block.timestamp + MAX_LOCK_DURATION where MAX_LOCK_DURATION is capped at a few years) and add an owner-controlled reduceLock / removeLock function that is itself guarded by a multisig and a timelock. Publicly disclose that setLock is a trusted administrative primitive, and make sure that the project's marketing does not claim that the token cannot be blacklisted, because setLock is in practice an irreversible blacklist.

Alleviation

Resolved. setLock now caps the freeze at MAX_LOCK_DURATION of four years and rejects the zero address (lines 64-70), and a new removeLock lets the owner clear a freeze (lines 73-76). The freeze is therefore bounded and reversible rather than permanent. setLock remains a trusted administrative primitive and should still be disclosed as such.

Resolved

#2 high Issue
transferWithLock freezes the recipient's entire pre-existing and future balance
src/v3/ShopinXToken.sol
L79-92
Description

transferWithLock stores the lock as a timestamp on the recipient's address (lockUntil[to] = unlockTime). Because _update checks that timestamp for every outgoing transfer, the lock extends to the recipient's whole balance at that moment and to any tokens they later receive from third parties, not just to the amount transferred in the call. A single wei of SPX sent to a market-maker, exchange hot wallet or retail holder with a far-future unlockTime freezes that address entirely for the duration of the lock.

Comments

Track locks as amounts rather than as a single per-address timestamp. A practical pattern is a mapping lockedAmount[account] that is incremented by amount inside transferWithLock (and decremented or cleared once the lock expires), with _update enforcing balanceOf(from) - lockedAmount[from] >= value. Alternatively, apply the lock only to the tranche transferred in the same call (one record per tranche) so that pre-existing balances cannot be retroactively affected. Without a fix, the owner is trusted not to send even a wei to any address they do not intend to freeze in full.

Alleviation

Resolved. transferWithLock now records an amount-based lock (lockedAmount and lockedUntil) and the gate only reserves that tranche, not the recipient's whole balance or later incoming tokens (lines 79-92, 194-212). See the separate low-severity note about the lock being overwritten rather than accumulated on repeated calls to the same address.

medium Issues | 4 findings

Resolved

#1 medium Issue
availableToTransfer view is inconsistent with the transfer rules enforced in _update
src/v3/ShopinXToken.sol
L153-173
L177-215
Description

When an address carries both a time-lock (lockUntil in the future) and a vesting schedule, availableToTransfer evaluates only the vesting branch and can return a non-zero value, while _update still reverts the actual transfer because it checks block.timestamp >= lockUntil[from] first. User interfaces, routers, bots and accounting tools relying on this view will mislead users about what they can actually move. This also means transferWithVesting never inspects lockUntil[to] when writing a new schedule, which is a silent way to land an address in the inconsistent state above.

Comments

Short-circuit availableToTransfer when the account is time-locked, regardless of whether a vesting schedule exists, so that the view always reflects what _update will actually permit. Optionally also surface whether the zero comes from a lock or a vesting lien, to make UI feedback clearer.

Alleviation

Resolved. The view and the transfer gate now apply the same rules: both check the full-address freeze first and then subtract amountLocked + vestingLocked (availableToTransfer lines 153-173, _update lines 177-215), so the view matches what a transfer will actually permit.

Resolved

#2 medium Issue
Single-step Ownable with broad, irreversible operational powers
src/v3/ShopinXToken.sol
L7
L9
Description

The contract uses a single-key, one-step Ownable for all administrative functions (lock creation, lock extension, vesting creation). A mistyped transferOwnership sends ownership to an unusable address in a single transaction, and there is no on-chain delay or co-signer requirement between a privileged call being initiated and it taking effect. Given the impact of setLock, transferWithLock and transferWithVesting, this access-control model is thinner than best practice for a production token.

Comments

Replace Ownable with Ownable2Step so ownership transfer requires an explicit accept step. Assign ownership to a multisig (for example Safe) fronted by a TimelockController with a delay of at least 24 hours on setLock, transferWithLock and transferWithVesting. This reduces the blast radius of a compromised or lost key and gives the community a window to react to unexpected administrative changes.

Alleviation

Resolved at the code level. The contract now inherits Ownable2Step (lines 7, 9), so ownership transfer needs an explicit accept step. Placing the owner behind a multisig and a timelock remains an operational recommendation.

Resolved

#3 medium Issue
Vesting lien is enforced as a fungible reserve against the entire balance rather than a segregated escrow
src/v3/ShopinXToken.sol
L21
L199-212
Description

The _update hook enforces balanceOf(from) >= value + (v.totalAmount - vestedAmount(from)). The result is a fungible reserve: any tokens in the account can satisfy the locked amount, and granted tokens are not distinguished from pre-existing or later-received tokens. This does not freeze unrelated balance, but it does couple the accounting of the grant to the beneficiary's wider balance, which can confuse off-chain tooling that expects vesting grants to be held in a separate escrow. It also means burning, slashing or clawing back granted tokens in isolation is impossible.

Comments

Consider tracking the vesting lien on a dedicated counter (for example lockedVestingBalance[account]) that is initialised to amount and decremented as vesting unlocks, enforcing balanceOf(from) - lockedVestingBalance[from] >= value in _update. An even cleaner approach for large grants is to deploy a dedicated vesting escrow per beneficiary (such as OpenZeppelin's VestingWallet), so that the granted tokens are physically segregated from any unrelated balance the beneficiary may hold. The current behaviour is not broken, but it is unusual enough that it should be documented explicitly so that investors and integrators understand it.

Alleviation

Addressed by documentation. The lien is still a fungible reserve against the whole balance, but this is now stated explicitly in the code (lines 21 and 199). A segregated per-beneficiary escrow was not adopted, which is acceptable given the explicit disclosure; mirror the same note in the external documentation so integrators are aware.

Resolved

#4 medium Issue
Locked and undervested holders cannot burn their tokens
src/v3/ShopinXToken.sol
L183-212
Description

_update applies the lock and vesting checks to every non-mint transition, including _burn (which routes through _update with to == address(0)). A holder under an active lock or with an undervested grant therefore cannot exercise the burn / burnFrom interface inherited from ERC20Burnable. This contradicts the common user expectation that holders can always destroy tokens they own, and makes the advertised 'burnable' behaviour conditional in a way that is not documented.

Comments

Decide explicitly whether burning should remain possible while a holder is locked or undervested. If yes, special-case to == address(0) inside _update and skip the lock / vesting checks for burns. If the product intentionally prohibits burns during a lock, drop ERC20Burnable from the inheritance list so the burn / burnFrom interface is not advertised to users, or document the restriction prominently.

Alleviation

Addressed as a deliberate design. Burns now skip the full-address freeze, so a frozen holder can still destroy tokens (lines 183-191). Amount-locked and still-unvested tokens remain non-burnable because the reserve check also applies to burns (lines 206-212); this is the intended behaviour that only unlocked tokens can be burned, and it is documented in the code. Confirm this matches the product intent and restate it in the user-facing documentation.

low Issues | 4 findings

Resolved

#1 low Issue
Floating Solidity pragma and default PUSH0 target
src/v3/ShopinXToken.sol
L2
Description

The contract uses a floating pragma ^0.8.27, allowing compilation with any compatible 0.8.27+ compiler. Combined with the default Shanghai target of modern solc, the emitted bytecode uses PUSH0, which is not universally supported across EVM-compatible chains. Two rebuilds of the same source can therefore produce different artifacts, and deployment can silently fail on chains that do not implement PUSH0.

Comments

Pin the compiler to an exact version (for example pragma solidity 0.8.27;) so that every deployment uses the exact compiler that was tested. If deployment on an L2 or chain that does not support PUSH0 is planned, also set the EVM version to paris (or earlier) in foundry.toml; otherwise the deployed bytecode will not execute on those chains.

Alleviation

Resolved. The pragma is now pinned to an exact 0.8.27, and Aderyn no longer reports the unspecific pragma or the PUSH0 opcode. One optional hardening remains: foundry.toml still sets no evm_version, and 0.8.27 defaults to the Cancun target, so set evm_version explicitly if a chain that is not on Cancun is a deployment target.

Resolved

#2 low Issue
Missing input validation on privileged functions
src/v3/ShopinXToken.sol
L64
L79
L101
Description

The privileged entrypoints do not validate inputs that have operational impact. setLock accepts address(0) because it never calls _transfer. transferWithLock and transferWithVesting do not require amount > 0, so a zero-amount call silently consumes a vesting slot forever (combined with the write-once rule on vesting). transferWithVesting also lacks upper bounds on cliffDays and stepDays, allowing pathological schedule parameters.

Comments

Add require(to != address(0)) to setLock, transferWithLock and transferWithVesting, require(amount > 0) to transferWithLock and transferWithVesting, and sensible upper bounds on cliffDays and stepDays (for example <= 36500). These checks cost almost nothing and prevent administrative mistakes that would otherwise silently pollute storage or create unusable schedules.

Alleviation

Resolved. setLock now rejects the zero address and caps the lock at MAX_LOCK_DURATION (lines 65-67). transferWithLock now requires a non-zero recipient, a positive amount and a bounded unlock time (lines 84-87). transferWithVesting now requires a non-zero recipient, a positive amount, and upper bounds on stepDays and cliffDays (lines 108-112). The bounded cliff and step values also remove the earlier overflow-revert path inside vestedAmount.

Resolved

#3 low Issue
renounceOwnership is exposed and would be destructive
src/v3/ShopinXToken.sol
L57-59
Description

OpenZeppelin's Ownable exposes renounceOwnership, which sets the owner to the zero address. Given the design of this contract, a renounced ownership makes every existing lock permanent and every existing vesting schedule frozen in place, with no path to correct a mistake. There is no operational reason to keep this function active in a production deployment of this token.

Comments

Override renounceOwnership() to always revert. Because the owner holds broad operational powers (lock extension, vesting creation) and because there is no fallback administrator, an accidental renouncement would permanently disable every administrative path while leaving existing locks and vesting schedules immutable forever.

Alleviation

Resolved. renounceOwnership is overridden to revert (lines 57-59), so ownership can no longer be dropped by accident.

Pending

#4 low Issue
transferWithLock overwrites an existing amount-lock and there is no way to clear it
src/v3/ShopinXToken.sol
L73-76
L88-89
Description

transferWithLock assigns lockedAmount[to] = amount and lockedUntil[to] = unlockTime rather than accumulating, so calling it twice on the same address replaces the earlier lock; because the first tranche is already in the recipient balance, the previously locked tokens stop being reserved. removeLock only clears the full-address freeze, not the amount-based lock, so there is no direct way to undo an amount-lock except overwriting it with another transfer or waiting for expiry.

Comments

Accumulate the locked amount (lockedAmount[to] += amount) or store one record per tranche so a second call cannot silently drop a previous lock, or revert when an active lock already exists. Add a clear or reduce function for the amount-based lock that mirrors removeLock, and emit an event when a lock is cleared.

Alleviation

Raised against this version. This is an owner-operated correctness and least-surprise issue rather than a third-party exploit, since the owner is trusted and can already manage freezes. The practical impact is that an accidental second lock can release a previously locked tranche earlier than intended.

optimization Issues | 4 findings

Resolved

#1 optimization Issue
Mark public administrative and view functions as external
src/v3/ShopinXToken.sol
L64
L73
L79
L94
L101
L153
Description

Several administrative and view functions are declared public but are never called from within the contract. public adds a small gas overhead because the arguments are copied from calldata into memory. external is the appropriate visibility whenever internal consumption is not needed, and it also communicates more clearly that these functions are part of the contract's external surface only.

Comments

Change the visibility of the administrative and view functions that are never called internally from public to external. The compiler can then pass arguments directly from calldata instead of copying them to memory, saving gas on every call with no functional impact.

Alleviation

Resolved. The administrative and view entrypoints are now external (setLock, removeLock, transferWithLock, isLocked, transferWithVesting, availableToTransfer); vestedAmount stays public because it is called internally. Aderyn no longer reports the public-not-internal pattern.

Resolved

#2 optimization Issue
Replace repeated numeric literals with named constants
src/v3/ShopinXToken.sol
L11-16
Description

The literal 100 is repeated in percent validation and in the vesting maths, and the initial supply is written as an inline expression in the constructor. Promoting these to named constants improves readability and reduces bytecode duplication, while also making the cap part of the contract's public API.

Comments

Declare uint256 constant PERCENT_BASE = 100; and uint256 public constant INITIAL_SUPPLY = 1_000_000_000e18; and reuse them throughout. Named constants are slightly cheaper to reference, easier to audit, remove the possibility of a silent typo creating inconsistent values, and document the token economics directly in the contract's ABI.

Alleviation

Resolved. PERCENT_BASE and INITIAL_SUPPLY, along with the lock and schedule bounds, are now named constants (lines 11-16) and used throughout, and the supply uses scientific notation. Aderyn no longer reports the repeated literal or the large numeric literal.

Resolved

#3 optimization Issue
Prefer multiplication before division to reduce precision loss
src/v3/ShopinXToken.sol
L140-147
Description

vestedAmount performs a division (afterCliff / stepSeconds) before multiplying by stepPercent, and computes currentStepAmount by dividing totalAmount by 100 before multiplying by currentStepElapsed. Reordering to divide last keeps precision maximal and prevents rounding errors from accumulating across steps.

Comments

Reorder the vesting maths so that all multiplications happen before any division for the interpolated component, and add the step-completion term on top. The invariant 100 % stepPercent == 0 already bounds the precision loss today, but the reordered version stays correct even if that invariant is later relaxed.

Alleviation

Resolved for the precision-sensitive path. The within-step interpolation now multiplies before dividing (line 147). Slither still reports a divide-before-multiply on completedSteps (lines 140 and 144), but that division is the intended floor count of completed steps and is correct by design.

Resolved

#4 optimization Issue
Pack VestingInfo fields to reduce storage writes
src/v3/ShopinXToken.sol
L26-32
Description

VestingInfo declares five independent uint256 fields. The values stored there (token amounts bounded by the total supply, day counts and a percentage) all fit in smaller integer types, so the struct can be packed into fewer storage slots without loss of precision.

Comments

Use uint128 for totalAmount (the full supply * 1e18 fits comfortably inside uint128) and uint32 for startTime, cliffDays, stepDays and stepPercent. This lets the whole struct fit in two storage slots instead of five, cutting the storage cost of transferWithVesting approximately in half.

Alleviation

Resolved. VestingInfo now uses uint128 for the amount and uint32 for the time and schedule fields (lines 26-32), packing into two slots. See the separate informational note on the unchecked downcasts used when writing the struct.

informational Issues | 10 findings

Pending

#1 informational Issue
Vesting schedules are write-once and cannot be cancelled or amended
src/v3/ShopinXToken.sol
L114
Description

The check require(vesting[to].totalAmount == 0) prevents any subsequent update to a vesting schedule once it has been created, and the contract exposes no function to cancel or amend one. Whether this is acceptable depends on the product requirements around vesting and is therefore flagged as a product and operations decision rather than a bug.

Comments

If the project's tokenomics or legal commitments require that vesting schedules be revocable or amendable (for example to handle beneficiaries leaving the team, or to correct parameter mistakes), add administrative revokeVesting / amendVesting functions guarded by a multisig and a timelock, and emit explicit events. If the schedules are intended to be immutable by design, simply document that clearly so that investors and beneficiaries understand the commitment.

Alleviation

Unchanged. Schedules are still write-once (line 114) with no cancel or amend path. This remains a product decision - add guarded revoke and amend functions if revocability is required, otherwise document the immutability.

Pending

#2 informational Issue
Vesting releases tokens continuously within each step
src/v3/ShopinXToken.sol
L144-149
Description

After the cliff ends, vestedAmount releases tokens continuously each second inside the current step. Classic cliff-plus-step schedules typically unlock tokens discretely at step boundaries. Whether the continuous behaviour is correct depends on what the project has advertised; it is not itself a security bug, but it is a meaningful product decision worth explicitly documenting.

Comments

Confirm which release pattern the project has advertised to investors. If discrete step releases are promised (the more common cliff-plus-step semantics), drop the within-step term and only credit completed steps. If continuous linear release is intended, a single duration parameter is simpler. Whichever pattern is chosen, document it clearly in the README and on vestedAmount.

Alleviation

Unchanged. The within-step term still releases tokens continuously each second (lines 144-149) rather than at discrete step boundaries. Confirm which pattern was advertised and document it.

Pending

#3 informational Issue
permit allowances can still be signed while an account is locked
src/v3/ShopinXToken.sol
L177-215
Description

A locked holder can still produce valid EIP-2612 permit signatures because permit only updates allowance. A subsequent transferFrom will revert in _update because of the lock. This matches the standard semantics of permit, which never promises that a downstream transfer will succeed, and is therefore documented here as informational rather than as a vulnerability.

Comments

This is expected ERC-2612 behaviour: permit only sets an allowance, it never guarantees that a later transferFrom will succeed. No change is strictly required. If user experience is a concern for permit-based flows (DEX routers, permit-plus-swap bundles), consider overriding permit to revert when the signer is currently locked, so that signatures cannot be produced during the frozen window.

Alleviation

Unchanged and expected. A frozen or locked holder can still sign a permit; the later transferFrom still reverts in the gate (lines 177-215). This matches ERC-2612 semantics, so no change is required unless the project wants to block signing during the frozen window for user-experience reasons.

Pending

#4 informational Issue
Reliance on block.timestamp for time comparisons
src/v3/ShopinXToken.sol
L66
L86
L95
L132
L155
L188
Description

All lock checks, vesting progress checks and availability checks use block.timestamp. Validators have a limited ability to influence this value, which is irrelevant at the day-level resolution used by the vesting and lock logic. Listed for completeness because it is an industry-standard disclosure.

Comments

No change required. block.timestamp manipulation is bounded to a handful of seconds on modern consensus, and this contract operates on day-level granularity. Flag it in the project's security notes so that investors and integrators are aware, but no code change is needed.

Alleviation

Unchanged. The lock, freeze and vesting checks still rely on block.timestamp (for example lines 66, 86, 132, 155 and 188), which Slither continues to report. At day-level granularity the validator influence is negligible, so this stays a disclosure item.

Resolved

#5 informational Issue
Modulo used for interpolation flagged as weak randomness
src/v3/ShopinXToken.sol
L146
Description

Static analysis reports afterCliff % stepSeconds as a weak pseudo-random number generator. The modulo here is purely a deterministic interpolation inside a vesting step and not a random value. Listed for documentation only.

Comments

No action required. The modulo is used only to compute how far into the current vesting step the current block is, for deterministic linear interpolation. It is not a source of randomness. A short comment near the line documenting the intent will prevent the finding from being reopened by future reviewers or tools.

Alleviation

Resolved by documentation. A comment now states that the modulo is a deterministic interpolation and not randomness (lines 145-146). Slither still reports it, but it is a confirmed false positive.

Resolved

#6 informational Issue
Strict equality on totalAmount == 0 flagged as dangerous
src/v3/ShopinXToken.sol
L114
L130
Description

Static analysis flags v.totalAmount == 0 as a dangerous strict equality. Here zero is the default value for an uninitialised VestingInfo, so the comparison is the standard way to check whether a schedule has been set. Listed for documentation only.

Comments

No action required. Using 0 as a sentinel for an uninitialised struct in a mapping is idiomatic Solidity. A short comment on the vesting mapping documenting this sentinel will help future reviewers.

Alleviation

Resolved by documentation. A comment now documents that a zero totalAmount is the sentinel for an unset schedule (line 25). The strict-equality checks (lines 114 and 130) are the idiomatic sentinel test, so the Slither report is a confirmed false positive.

Pending

#7 informational Issue
Verify EIP-712 domain separator after deployment
src/v3/ShopinXToken.sol
L49
L51
Description

ERC20Permit is initialised with the name 'ShopinX Token', which matches the ERC20 name. A routine post-deployment check should confirm that the domain separator computed off-chain matches the one returned by the deployed contract, to rule out metadata or constructor-argument drift.

Comments

After deployment, compare the on-chain DOMAIN_SEPARATOR against the one produced by the reviewed source with the same constructor arguments. A mismatch indicates recompilation with different metadata or unexpected constructor arguments, and should be investigated before permit is enabled for end users.

Alleviation

Unchanged. The ERC20 name and the permit name still match (lines 49 and 51), so the post-deployment domain separator check still applies once the contract is live.

Pending

#8 informational Issue
Recipient and initial owner addresses should be publicly documented
src/v3/ShopinXToken.sol
L46-47
Description

The constructor receives the initial recipient of the full supply and the administrative owner as two arguments, with no on-chain labelling of what each address represents. Clear documentation of these addresses is essential for downstream trust evaluation given the broad administrative powers described elsewhere in this report.

Comments

In the project documentation, publish the exact addresses used for recipient (the initial holder of the full supply) and initialOwner (the administrative key), along with the nature of each address (EOA, multisig, custodian, treasury). This is essential context for investors evaluating the centralisation surface described in the high-severity findings.

Alleviation

Partially addressed. The constructor parameters now carry comments describing the recipient and the administrative owner (lines 46-47). Publishing the actual deployed addresses and their nature in the external documentation is still recommended.

Pending

#9 informational Issue
Initial supply changed from the originally audited figure
src/v3/ShopinXToken.sol
L12
L53
Description

The constructor mints the full supply once at deployment. The figure increased from the originally audited 300,000,000 to 1,000,000,000 SPX, which is a tokenomics decision rather than a remediation. It is recorded here so that the supply change is explicitly reviewed and tracked.

Comments

Confirm that the larger supply is the intended tokenomics, and update every document, test, deployment script and external reference that still states the old figure. Exposing the supply as a named constant so the value is part of the contract's public API was recommended and has been done.

Alleviation

Carried over and formalised. The supply is now the named constant INITIAL_SUPPLY of 1,000,000,000e18 (lines 12 and 53). It still does not introduce a vulnerability, but confirm the figure is the intended tokenomics and update every external document and test that still states the older 300,000,000 value.

Pending

#10 informational Issue
Unchecked downcasts when writing the vesting struct
src/v3/ShopinXToken.sol
L116-121
Description

transferWithVesting narrows amount to uint128 and block.timestamp, cliffDays, stepPercent and stepDays to uint32 with unchecked casts. With the current fixed supply and the enforced bounds these casts cannot overflow today (the amount stays below the uint128 range and the day and percent values are bounded well below the uint32 range), but the casts are unchecked and the forge linter flags them as unsafe; startTime stored as uint32 also truncates after the year 2106.

Comments

Use a checked conversion (for example OpenZeppelin SafeCast) or add explicit require bounds when narrowing amount to uint128 and the time and schedule values to uint32. Document that startTime stored as uint32 is valid until the year 2106.

Alleviation

Raised against this version. There is no impact under the current fixed supply and the enforced bounds, so this is a defensive-coding and long-horizon correctness note rather than a live bug.