Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →
Grand Gangsta City logo

Grand Gangsta City

Audit name:

[SCA] Grand Gangsta City | Token | Jun2025

Date:

Jul 10, 2025

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Grand Gangsta City team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Grand Gangsta City is a project with an ERC20 token with built-in category-based vesting logic.

Document

NameSmart Contract Code Review and Security Analysis Report for Grand Gangsta City
Audited ByOlesia Bilenka; Georgi Krastenov
Approved ByAtaberk Yavuzer
Websitehttps://grandgangstacity.com/→
Changelog16/06/2025 - Preliminary Report
10/07/2025 - Final Report
PlatformSEI
LanguageSolidity
TagsVesting; ERC-20
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Grand Gangsta City
    Audited By
    Olesia Bilenka; Georgi Krastenov
    Approved By
    Ataberk Yavuzer
    Website
    https://grandgangstacity.com/→
    Changelog
    16/06/2025 - Preliminary Report
    10/07/2025 - Final Report
    Platform
    SEI
    Language
    Solidity
    Tags
    Vesting; ERC-20
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/Grand-Gangsta-City/Token-Contract→
Commit80f2e952d33a680f7c55023114d8d3d9b7334481
Remediation Commitf0dc5e513852e2bd0ee6c31506ac0957b5b8fba9
2nd Remediation Commite126ec86afa9ffaabe14cbba286d1581de50202b

Audit Summary

12Total Findings
9Resolved
3Accepted
0Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are missed.

  • Technical description is not provided.

  • Tokenomics is provided.

Code quality

  • The development environment is configured.

  • Several inefficient code parts were identified throughout the contract.

Test coverage

Code coverage of the project is 0% (branch coverage).

  • Tests are not provided.

System Overview

  • The GGC contract is an ERC20 token with built-in category-based vesting logic. Upon deployment, the entire total supply of 1 billion tokens is minted to the contract itself (address(this)), from which all allocations and distributions are managed. The tokenomics are structured around predefined categories (e.g., Seed, Team, Marketing), each initialized with a fixed token pool, TGE unlock percentage, cliff duration, and vesting period. The contract owner can allocate tokens from these categories to individual beneficiaries through the allocateBatch function. These allocations define a vesting schedule specific to each beneficiary based on the corresponding category parameters. Beneficiaries claim their vested tokens over time using the claim() function, which is protected against reentrancy. Additionally, the contract includes the ability for the owner to reassign an allocation to a new address using changeAddress, preserving the vesting schedule and claimed amount. The contract introduces the allocation revoking functionality, allowing the owner to revoke any unclaimed allocation and return it to its category.

Privileged roles

  • The owner of the GGC contract can allocate tokens to beneficiaries via allocateBatch, and reassign vesting allocations to new addresses using changeAddress, revoke any unclaimed allocation and return it to its category.

Potential Risks

Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.

Insufficient Permissioning and Documentation: Inadequate permissions and under-documentation heighten the risk of unauthorized access and actions, complicating issue resolution and increasing the potential for security breaches.

Insufficient Multi-signature Protection for Critical Roles: the owner and other critical roles appear to be controlled by single addresses without multi-signature protection. This centralizes control and increases the risk of unauthorized actions, accidental mistakes, or compromise of a single key. Using a multi-sig wallet for such roles would help reduce the risk of single points of failure.

The changeAddress function risk: it allows the contract owner to arbitrarily transfer an allocation from one address to another. The approve approveAddressChange and revokeAddressChangeApproval functionality which allows to approve the change befirehand was added. However, it is not rescricted to which address the change is approved.

The revokeAllocation function risk: in the 2nd remediation, commit e126ec8 the revokeAllocation function was introduced  allowing the Owner to revoke any unclaimed allocation and return it to its category, which introduces a centralization risk.

Findings

F-2025-1093Incorrect SECONDSPERMONTH Constant Used in Vesting Calculations
Status
fixed
Severity

High
F-2025-1098Incorrect Handling of Already Vested Tokens in changeAddress Function
Status
accepted
Severity

Low
F-2025-1095changeAddress and revokeAllocation Functions Introduce Centralization Risk in GGC Contract
Status
accepted
Severity

Low
F-2025-1095Redundant Vesting Start Check in claim Function
Status
accepted
Severity

Observation
F-2025-1095Inconsistent Revert Style in GGC Contract: require vs. revert
Status
fixed
Severity

Observation
F-2025-1095Unnecessary Explicit Initialization of uint256 Variables to Zero
Status
fixed
Severity

Observation
F-2025-1095Redundant totalVestingSeconds Check in allocateBatch() Function
Status
fixed
Severity

Observation
F-2025-1095Unnecessary nonReentrant Modifier in Claim Function
Status
fixed
Severity

Observation
F-2025-1093Inconsistent TGE Percent Handling
Status
fixed
Severity

Observation
F-2025-1093Redundant Event
Status
fixed
Severity

Observation
Code
―
Title
Status
Severity
F-2025-1093Incorrect SECONDSPERMONTH Constant Used in Vesting Calculations
fixed

High
F-2025-1098Incorrect Handling of Already Vested Tokens in changeAddress Function
accepted

Low
F-2025-1095changeAddress and revokeAllocation Functions Introduce Centralization Risk in GGC Contract
accepted

Low
F-2025-1095Redundant Vesting Start Check in claim Function
accepted

Observation
F-2025-1095Inconsistent Revert Style in GGC Contract: require vs. revert
fixed

Observation
F-2025-1095Unnecessary Explicit Initialization of uint256 Variables to Zero
fixed

Observation
F-2025-1095Redundant totalVestingSeconds Check in allocateBatch() Function
fixed

Observation
F-2025-1095Unnecessary nonReentrant Modifier in Claim Function
fixed

Observation
F-2025-1093Inconsistent TGE Percent Handling
fixed

Observation
F-2025-1093Redundant Event
fixed

Observation
1-10 of 12 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Definitions

Severities

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.

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

Potential Risks

The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/Grand-Gangsta-City/Token-Contract→
Commit80f2e952d33a680f7c55023114d8d3d9b7334481
Remediation Commitf0dc5e513852e2bd0ee6c31506ac0957b5b8fba9
2nd Remediation Commite126ec86afa9ffaabe14cbba286d1581de50202b
Tokenomicshttps://grandgangstacity.com/#token→

Assets in Scope

GGC.sol - GGC.sol

Appendix 3. Additional Valuables

Additional Recommendations

The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.

To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:

  • Detecting changes to ownership or critical permissions.

  • Monitoring large or unexpected transactions and minting events.

  • Pausing operations when irregularities are identified.

These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.

Disclaimer