Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • hesty
  • [SCA] Hesty / Hesty-Contract / Oct2024
Hesty logo

Hesty

Audit name:

[SCA] Hesty / Hesty-Contract / Oct2024

Date:

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

Hesty is a transparent and secure marketplace for real estate projects that aims to democratize real estate investment.

Document

NameSmart Contract Code Review and Security Analysis Report for Hesty
Audited ByPrzemyslaw Swiatowiec, Grzegorz Trawinski
Approved ByAtaberk Yavuzer
WebsiteN/A
Changelog07/11/2024 - Preliminary Report, 28.11.2024 - Final Report
PlatformBase
LanguageSolidity
TagsERC20, KYC, Rewards, Dividend, Compliance
Methodologyhttps://hackenio.cc/sc_methodology
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Hesty
    Audited By
    Przemyslaw Swiatowiec, Grzegorz Trawinski
    Approved By
    Ataberk Yavuzer
    Website
    N/A
    Changelog
    07/11/2024 - Preliminary Report, 28.11.2024 - Final Report
    Platform
    Base
    Language
    Solidity
    Tags
    ERC20, KYC, Rewards, Dividend, Compliance

Review Scope

Repositoryhttps://github.com/la-bomba-studio/hesty-contract
Commit1cc5bf5f04f374d337c84f4f6dd47499f96df168

Audit Summary

26Total Findings
22Resolved
4Accepted
0Mitigated

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

Documentation quality

  • Functional requirements are provided.

  • Technical description is provided.

Code quality

  • The development environment is configured.

Test coverage

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

System Overview

Hesty is a decentralized platform providing a transparent marketplace for real estate investment. Using a series of smart contracts on the BASE blockchain, Hesty facilitates property fundraising, token issuance, referral rewards, and dividend distributions. The system consists of multiple specialized contracts, each with distinct roles, to manage and secure the investment process.

Hesty Router:

  • Purpose: Manages the interface between on-chain and off-chain transactions. Since Hesty operates under regulatory constraints, fiat-to-crypto transactions must be handled through a custodian. The router ensures funds from the custodian are received securely, while Hesty admins manually synchronize on-chain token allocations for off-chain fiat investments.

  • Core Functions:

    • adminDistribution: Distributes rewards paid in fiat (converted to EURC) to property token holders.

    • offChainBuyTokens: Allows Hesty admins to assign property tokens for off-chain fiat purchases, ensuring parity between on-chain and off-chain investments.

Token Factory:

  • Purpose: Manages the creation and distribution of property tokens that represent shares in real estate projects. Token Factory is also responsible for tracking fund amounts, handling fees, and supporting the claim-back process if a fundraise fails.

  • Core Functions:

    • createProperty: Allows property owners to issue a new property token with a fixed supply, representing shares in the property.

    • buyTokens: Enables users to buy property tokens using EURC. Investment fees and referral fees are calculated here.

    • completeRaise: Finalizes the property raise if the target is met, distributing funds to the property owner and the platform treasury.

    • recoverFundsInvested: Allows users to reclaim investments if the fundraising threshold is not met by the deadline.

Property Token:

  • Purpose: The token contract that represents ownership shares in a property. These tokens are non-mintable and track dividends and revenue distributions for investors.

  • Core Functions:

    • claimDividends: Distributes accrued dividends to token holders based on their balance.

    • transfer and transferFrom Overrides: These functions are customized to enforce KYC and blacklist compliance and to distribute accrued dividends to holders upon transfer.

Referral System:

  • Purpose: Tracks referral rewards, the number of referrals, and total referral earnings. The Referral System contract is designed to incentivize user referrals and manage referral-based reward distribution.

  • Core Functions:

    • addRewards: Allocates referral rewards to referrers based on user investments.

    • claimPropertyRewards: Allows referrers to claim earned rewards specific to each property.

    • claimGlobalRewards: Lets referrers claim rewards that are not tied to a specific property.

Hesty Access Control:

  • Purpose: Manages user roles and permissions across the Hesty platform, enforcing KYC and blacklist compliance for users.

  • Roles Managed:

    • Admin: Has comprehensive control over key contract functions, including completing and canceling property raises.

    • Funds Manager: Oversees fund transfers, particularly in the Hesty Router.

    • Blacklist Manager: Can add or remove users from a blacklist, preventing them from engaging in transactions.

    • KYC Manager: Approves KYC for users, allowing them to participate in investments.

    • Pauser: Has permission to pause all Hesty contracts in case of emergency.

Constants:

  • Purpose: A contract containing fixed values and role definitions shared across all Hesty contracts. Constants improve maintainability by centralizing configuration values, such as BASIS_POINTS, MULTIPLIER, and role definitions (e.g., BLACKLIST_MANAGER, FUNDS_MANAGER).

Privileged roles

Admin:

  • Description: The Admin role has the highest level of authority in the Hesty system, allowing comprehensive control over critical functions, such as finalizing raises, cancelling projects, and updating configuration parameters.

  • Permissions:

    • Execute completeRaise to finalize a fundraise and distribute funds if the target is met.

    • Execute cancelRaise to halt a fundraise and initiate the refund process if the raise is unsuccessful.

    • Set or modify key parameters, such as platform fees and referral fees.

    • Add or remove other privileged roles in the Hesty Access Control contract.

Funds Manager:

  • Description: The Funds Manager oversees fund transfers and distribution functions, particularly for off-chain and custodial transactions handled by the Hesty Router.

  • Permissions:

    • Call adminDistribution to distribute rewards for off-chain investments that have been converted into EURC.

    • Call adminBuyTokens in the Token Factory to issue tokens for users who invested with fiat currency, ensuring on-chain and off-chain investment parity.

Blacklist Manager:

  • Description: The Blacklist Manager role enforces compliance by restricting access for users identified as blacklisted, preventing them from participating in transactions on the Hesty platform.

  • Permissions:

    • Add addresses to the blacklist, effectively blocking them from future investments or token transactions.

    • Remove addresses from the blacklist when appropriate, allowing them to reengage with the platform.

KYC Manager:

  • Description: The KYC (Know Your Customer) Manager role is responsible for ensuring that users meet KYC requirements before they can invest or interact with Hesty’s financial operations. This role is essential for regulatory compliance.

  • Permissions:

    • Approve a user’s KYC status with approveUserKYC, granting them permission to participate in investments.

    • Revoke KYC approval if the user no longer meets compliance requirements or upon identifying suspicious activity.

    • Execute approveKYCOnly to confirm a user’s KYC status without triggering any associated actions (e.g., token transfers).

Pauser:

  • Description: The Pauser role has the authority to halt and resume contract functionality, primarily as a security measure in response to potential vulnerabilities, attacks, or other emergencies.

  • Permissions:

    • Call pause on the Hesty Access Control contract to temporarily disable all operations within the Hesty ecosystem.

    • Call unpause to resume standard operations once the security concern is resolved.

Property Owner:

  • Description: Although not a general platform privilege, the Property Owner role has special permissions in the Token Factory contract, primarily associated with issuing property tokens and managing property-specific parameters.

  • Permissions:

    • Call createProperty to initiate a new property raise and issue property tokens.

    • Set specific parameters for their property’s token issuance and token pricing.

Potential Risks

Admin-Controlled Actions: Several critical actions, such as token purchases on behalf of investors, are managed on-chain by the admin, centralizing control in a decentralized process. This dependency increases trust requirements, as users must rely on the admin to act in their best interest without oversight.

Unrestricted Token Usage: The contract is intended to operate solely with the EURC token; however, it currently permits any ERC-20 token, including those that may not comply with regulatory standards. Allowing unrestricted token types could introduce risks associated with non-compliant or fee-on-transfer tokens, potentially disrupting the contract’s intended behavior.

Admin Flexibility to Change Fees: The admin can adjust fees, including investment, referral, and listing fees, up to a high threshold, which could lead to increased costs for investors. This flexibility could allow for abrupt fee changes, impacting users' expected returns and potentially deterring participation.

Admin-Controlled Raise Finalization: The timing of when a raise is finalized is controlled entirely by the admin, meaning investors must trust the admin to complete the raise promptly and fairly. This authority introduces a risk of delayed raise completion, potentially affecting fund accessibility and investor expectations.

Absence of On-Chain Dividend Collection: There is no on-chain mechanism within the contract to accumulate or distribute dividends directly; dividend collection and distribution are managed off-chain under separate agreements. Investors may buy tokens expecting dividends but risk never seeing these payouts if off-chain arrangements are not honored or executed transparently.

Compliance Verification Risk: This audit does not include verification of regulatory or compliance requirements, which means that certain features or functions may not align with applicable legal standards. As a result, there is a risk that the system could operate in a non-compliant manner, potentially exposing the protocol to legal or financial liabilities.

Findings

Code
Title
Status
Severity
F-2024-7053Double Counting of Referral Fees Leading to Fund Shortages on Raise Completion
fixed

Critical
F-2024-7031Unintended Increase of maxAmountOfRefRev on Each Referral Reward Calculation
fixed

Critical
F-2024-6989All Fees Are Locked Within The Protocol
fixed

Critical
F-2024-6976Claiming More Tokens Than Purchased Due to Missing Reset on Token Balance
fixed

Critical
F-2024-6992The recoverFundsInvested Function Does Not Reset rightForTokens Collection
fixed

High
F-2024-6969Over-Selling of Property Tokens Leading to Unclaimable Tokens
fixed

High
F-2024-6967Inconsistent Fund Recovery Validation Leading to Fund Theft and Double Claims
fixed

High
F-2024-7024The completeRaise Makes Use of Push pattern
accepted

Medium
F-2024-7023Protocol's Owner Can Update Property Owner Fee Address
accepted

Medium
F-2024-7027Direct Token Transfer in adminBuyTokens Prevents Refunds and Allows Premature Trading
fixed

Medium
1-10 of 26 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/la-bomba-studio/hesty-contract
Commit1cc5bf5f04f374d337c84f4f6dd47499f96df168
WhitepaperREADME.md
RequirementsREADME.md
Technical RequirementsREADME.md

Assets in Scope

contracts
Constants.sol - contracts/Constants.sol
HestyAccessControl.sol - contracts/HestyAccessControl.sol
HestyRouter.sol - contracts/HestyRouter.sol
interfaces
IHestyAccessControl.sol - contracts/interfaces/IHestyAccessControl.sol
IReferral.sol - contracts/interfaces/IReferral.sol
ITokenFactory.sol - contracts/interfaces/ITokenFactory.sol
PropertyToken.sol - contracts/PropertyToken.sol
Referral
ReferralSystem.sol - contracts/Referral/ReferralSystem.sol
TokenFactory.sol - contracts/TokenFactory.sol

Appendix 3. Additional Valuables

Verification of System Invariants

During the audit of Hesty platform, 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 Foundry fuzzing suite was prepared for this task, and throughout the assessment, 4 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

Property should be created if parameters do not exceed expected limits.Passed100000
Users without KYC should not be able to receive tokens.Passed100000
Dividends should not be claimable if user does not have property tokens.Passed100000
Users should be able to claim dividends once per distribution.Passed100000
  • Invariant

    Property should be created if parameters do not exceed expected limits.

    Test Result

    Passed

    Run Count

    100000

    Invariant

    Users without KYC should not be able to receive tokens.

    Test Result

    Passed

    Run Count

    100000

    Invariant

    Dividends should not be claimable if user does not have property tokens.

    Test Result

    Passed

    Run Count

    100000

    Invariant

    Users should be able to claim dividends once per distribution.

    Test Result

    Passed

    Run Count

    100000

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