The Hacken 2025 Yearly Security ReportCovers major Web3 breaches, their root causes, prevention insights, and key regulatory trends for 2026.
Learn more

Sensi

Audit name:

[SCA] Sensi Token | Token | Dec2024

Date:

Dec 18, 2024

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 Sensi team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Sensi Token is fee-on-transfer ERC-20 token.

Document

NameSmart Contract Code Review and Security Analysis Report for Sensi
Audited ByOlesia Bilenka
Approved ByAtaberk Yavuzer
Websitehttps://sensi.fi/→
Changelog17/12/2024 - Preliminary Report
PlatformBNB Chain
LanguageSolidity
TagsFungible Token; ERC-20; Fee-On-Transfer
Methodologyhttps://hackenio.cc/sc_methodology→

  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Sensi
    Audited By
    Olesia Bilenka
    Approved By
    Ataberk Yavuzer
    Website
    https://sensi.fi/→
    Changelog
    17/12/2024 - Preliminary Report
    Platform
    BNB Chain
    Language
    Solidity
    Tags
    Fungible Token; ERC-20; Fee-On-Transfer
    Methodology
    https://hackenio.cc/sc_methodology→

Review Scope

RepositoryN/A
CommitN/A
Deployed Contracthttps://bscscan.com/token/0x63e77cf206801782239d4f126cfa22b517fb4edb→

Audit Summary

5Total Findings
0Resolved
0Accepted
0Mitigated

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

Documentation quality

  • Functional requirements are not provided.

  • Technical description is not provided.

Code quality

  • The code mostly follows best coding practices.

  • The development environment is not configured.

Test coverage

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

  • Tests are not provided.

System Overview

Sensi Token is fee-on-transfer ERC-20 token project with the following contract:

A_SENSIv3 - is an ERC-20 token with fee-on-transfer functionality, supporting standard ERC-20 operations like transfer, approve, and transferFrom, alongside additional features for configurable fees, burning, and administrative control.

It has the following attributes:

  • Name: Sensi

  • Symbol: SENSI

The  token applies fees during transfers based on the trade direction (buy, sell, or other transfers). For buy transactions, a percentage of the transferred amount is sent to a designated taxAddress, and a portion of the remaining amount may be burned. Similarly, sell transactions deduct a percentage for the taxAddress and apply a burn to the post-tax amount. Other transfers between non-whitelisted addresses are also taxed but not burned. Both tax rates and burn percentages are configurable by the contract owner, and exemptions are supported through a whitelist and NFT-based tax waivers.

Privileged roles

  • The contract integrates administrative functions that allow the owner to manage tax rates, burn percentages, tax recipient addresses, and whitelisted accounts. It supports liquidity pool integration by allowing the specification of an LP token address and includes mechanisms for secure withdrawal of both ETH and ERC-20 tokens. Transfers are validated for compliance with the ERC-20 standard, and the _transfer function handles the integrated fee and burn logic. The contract ensures flexibility in tokenomics while maintaining compatibility with decentralized exchange ecosystems.

Potential Risks

Fixed Total Supply Post-Deployment: The token’s total supply is determined at deployment and cannot be verified beforehand, potentially limiting the project’s adaptability and economic model flexibility.

Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.

Fee-on-Transfer Mechanism and Configurable Fees: The fee-on-transfer mechanism may affect token usability in certain DeFi protocols that do not fully support fee-on-transfer tokens. Additionally, the ability of the contract owner to modify tax rates and burn percentages introduces potential centralization risks.

Findings

Code
―
Title
Status
Severity
F-2024-7713Inconsistent Use of msg.sender and msgSender() in ASENSIv3 Contract
unfixed

Observation
F-2024-7712Magic Numbers Usage Reduces Code Readability
unfixed

Observation
F-2024-7711Redundant Comparisons to Boolean Values
unfixed

Observation
F-2024-7710Lack of Configuration Events
unfixed

Observation
F-2024-7709Floating Pragma
unfixed

Observation
1-5 of 5 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

RepositoryN/A
CommitN/A
WhitepaperN/A
Deployed Contracthttps://bscscan.com/token/0x63e77cf206801782239d4f126cfa22b517fb4edb→

Assets in Scope

https:
bscscan.com
token
0x63e77cf206801782239d4f126cfa22b517fb4edb - https: › › bscscan.com › token › 0x63e77cf206801782239d4f126cfa22b517fb4edb

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Sensi Token, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.

Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 15 invariants were tested over 65,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

Sender balance must decrease by the transferred amount in the transfer function.Passed65K+
Recipient balance must increase by the post-tax amount in the transfer function.Passed65K+
Tax address balance must increase by the calculated tax amount in the transfer function.Passed65K+
Allowance for the spender must decrease by the transferred amount in the transferFrom function.Passed65K+
Sender balance must decrease by the full transfer amount in the transferFrom function.Passed65K+
Recipient balance must increase by the transferred amount in the transferFrom function.Passed65K+
Allowance for the spender must match the approved amount in the approve function.Passed65K+
Tax percent, divisor, and address must be correctly set and retrievable in the setTax function.Passed65K+
Whitelist status for each address must match the provided status in the setTaxWhitelist function.Passed65K+
Total supply must decrease by the burn amount in the burnTokens function.Passed65K+
Owner balance must decrease by the burn amount in the burnTokens function.Passed65K+
ETH balance of the recipient must increase by the withdrawn amount in the withdrawToken function for ETH.Passed65K+
ETH balance of the contract must decrease by the withdrawn amount in the withdrawToken function for ETH.Passed65K+
ERC-20 balance of the recipient must increase by the withdrawn amount in the withdrawToken function for ERC-20.Passed65K+
ERC-20 balance of the contract must decrease by the withdrawn amount in the withdrawToken function for ERC-20.Passed65K+

  • Invariant

    Sender balance must decrease by the transferred amount in the transfer function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Recipient balance must increase by the post-tax amount in the transfer function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Tax address balance must increase by the calculated tax amount in the transfer function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Allowance for the spender must decrease by the transferred amount in the transferFrom function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Sender balance must decrease by the full transfer amount in the transferFrom function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Recipient balance must increase by the transferred amount in the transferFrom function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Allowance for the spender must match the approved amount in the approve function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Tax percent, divisor, and address must be correctly set and retrievable in the setTax function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Whitelist status for each address must match the provided status in the setTaxWhitelist function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Total supply must decrease by the burn amount in the burnTokens function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    Owner balance must decrease by the burn amount in the burnTokens function.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    ETH balance of the recipient must increase by the withdrawn amount in the withdrawToken function for ETH.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    ETH balance of the contract must decrease by the withdrawn amount in the withdrawToken function for ETH.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    ERC-20 balance of the recipient must increase by the withdrawn amount in the withdrawToken function for ERC-20.

    Test Result

    Passed

    Run Count

    65K+

    Invariant

    ERC-20 balance of the contract must decrease by the withdrawn amount in the withdrawToken function for ERC-20.

    Test Result

    Passed

    Run Count

    65K+

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