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 | |
---|---|
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 |
Methodology | https://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
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
---|---|
Repository | https://github.com/la-bomba-studio/hesty-contract→ |
Commit | 1cc5bf5f04f374d337c84f4f6dd47499f96df168 |
Review Scope
- Commit
- 1cc5bf5f04f374d337c84f4f6dd47499f96df168
Audit Summary
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 theToken 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 theHesty 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-7053 | Double Counting of Referral Fees Leading to Fund Shortages on Raise Completion | fixed | Critical | |
F-2024-7031 | Unintended Increase of maxAmountOfRefRev on Each Referral Reward Calculation | fixed | Critical | |
F-2024-6989 | All Fees Are Locked Within The Protocol | fixed | Critical | |
F-2024-6976 | Claiming More Tokens Than Purchased Due to Missing Reset on Token Balance | fixed | Critical | |
F-2024-6992 | The recoverFundsInvested Function Does Not Reset rightForTokens Collection | fixed | High | |
F-2024-6969 | Over-Selling of Property Tokens Leading to Unclaimable Tokens | fixed | High | |
F-2024-6967 | Inconsistent Fund Recovery Validation Leading to Fund Theft and Double Claims | fixed | High | |
F-2024-7024 | The completeRaise Makes Use of Push pattern | accepted | Medium | |
F-2024-7023 | Protocol's Owner Can Update Property Owner Fee Address | accepted | Medium | |
F-2024-7027 | Direct Token Transfer in adminBuyTokens Prevents Refunds and Allows Premature Trading | fixed | Medium |
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 | |
---|---|
Repository | https://github.com/la-bomba-studio/hesty-contract→ |
Commit | 1cc5bf5f04f374d337c84f4f6dd47499f96df168 |
Whitepaper | README.md |
Requirements | README.md |
Technical Requirements | README.md |
Scope Details
- Commit
- 1cc5bf5f04f374d337c84f4f6dd47499f96df168
- Whitepaper
- README.md
- Requirements
- README.md
- Technical Requirements
- README.md
Assets in Scope
contracts/Constants.sol
contracts/HestyAccessControl.sol
contracts/HestyRouter.sol
contracts/interfaces/IHestyAccessControl.sol
contracts/interfaces/IReferral.sol
contracts/interfaces/ITokenFactory.sol
contracts/PropertyToken.sol
contracts/Referral/ReferralSystem.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. | Passed | 100000 |
Users without KYC should not be able to receive tokens. | Passed | 100000 |
Dividends should not be claimable if user does not have property tokens. | Passed | 100000 |
Users should be able to claim dividends once per distribution. | Passed | 100000 |
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.