Digital Oro International

The project is fully centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.

The system Staking and Raffle distribute funds from Treasury. Initially, the Treasury is filled with funds received from “DOI Token” sale. Treasury is supposed to be funded externally to cover the payouts.

The DOI_Treasury contract is the sole source of funds for raffle, real estate, and referral rewards, but it has no on-chain mechanism to autonomously generate or secure these funds. Its balance depends entirely on manual deposits by system administrators, introducing centralization and trust assumptions. If mismanaged or underfunded, users may be unable to claim their expected rewards.

The system’s access control relies on the onlyAuthorizedContract and onlyInternalContract modifiers, which depend on approvedContracts and internalContracts mappings managed by the admin or owner roles. Since these roles are centrally controlled, key functions—such as processing referral commissions, withdrawing locked funds or altering user balances in treasury—ultimately depend on trusted administrative management. This introduces a centralization risk, as misuse or misconfiguration of these roles could compromise the fairness or integrity of the system’s operations.

DOI_Gold ERC721 tokens serve as eligibility assets for participating in real estate staking and acting as verified stakeholders within the system. However, the verification process is performed off-chain by the system administrator, who must manually trigger the on-chain verifyFunction() afterward. This introduces a trust dependency on the admin’s off-chain actions, as users cannot independently verify or trigger their own verification, making the process centralized and dependent on proper administrative execution.

In the replaceToken() function, the admin has the ability to burn a user’s existing Gold token and mint a new one to a different address. This effectively allows the admin to revoke ownership of tokens without the holder’s consent. Such unrestricted administrative control introduces a centralization risk and undermines token ownership guarantees, as users must fully trust the admin not to misuse this capability.

The system accepts token amounts as human-readable values (without decimals) in several functions, relying on internal scaling logic to maintain consistency across the execution flow. As a result, fractional token amounts cannot be used. Moreover, if a system manually triggers functions outside the intended internal call sequence—bypassing the approved execution paths—accounting inconsistencies may occur, potentially leading to inaccurate balances or other unintended behaviors.

The PayoutManager contract calculates payouts by dividing the total payout amount by the number of unlock periods (payoutPerPeriod = totalPayout / totalPeriods). Due to integer truncation in Solidity, the cumulative sum of all periodic payouts (payoutPerPeriod * totalPeriods) may be slightly lower than the intended total payout. Consequently, users may receive marginally fewer tokens than expected. While the impact on users is minor given the small rounding discrepancy, administrators should monitor the Treasury’s balance to ensure accounting consistency. Any surplus tokens allocated to the Treasury to offset such discrepancies can be withdrawn by authorized roles, mitigating potential operational concerns.

Each RealEstate contract defines a maximum total amount of USDC that can be staked; however, no per-user staking limit is enforced. As a result, a single user could potentially stake the entire available capacity of a given RealEstate contract, preventing other participants from taking part in the staking opportunity and undermining fairness in access to the system’s rewards.

The protocol’s revenue, which funds RealEstate staking rewards, raffle prizes, and referral rewards, appears to be generated off-chain—presumably from activities such as selling or renting properties. There is no on-chain mechanism to verify or enforce these revenue inflows, meaning the system relies entirely on administrators or owners to accurately and fairly update the Treasury. This introduces a centralization and trust risk, as users cannot independently verify the source or correctness of funds backing the rewards, and mismanagement could result in insufficient payouts.

The Treasury contract holds users’ locked USDC tokens from RealEstate staking, as well as reward tokens, with the locked funds being the most critical. The contract exposes withdraw() and withdrawTo() functions, which grant the owner the ability to transfer out these funds. This introduces a centralization and trust risk, as the contract owner could potentially drain user deposits, compromising the safety of staked assets and overall system integrity.

Normally, users are required to hold at least one Gold token to maintain their active locks, and the _update() function in the Gold contract enforces this by reverting transfers that would leave a user without any Gold tokens. However, the replaceToken() function bypasses this safeguard, allowing a user to hold active locks without possessing any Gold tokens.

When the Gold token reaches its supply limit of 5,000 tokens, the DOI_Raffle contract allows an active raffle to be closed even if users have already participated. In this situation, a winner is still selected; however, the expected on-chain payout mechanisms (doiTreasury.processPayment() or payoutManager.initializePayout()) are not executed. Instead the winner will receives a reduced prize, managed off-chain. This discrepancy between expected and actual payout behavior may lead to user confusion or disputes. The conditions under which a raffle may close with modified prize distribution should be clearly disclosed within the raffle rules.

The system relies on multiple cross-contract interactions between DOI_Raffle, the DOI_LockManager contract, or the DOI_Treasury contract, among others. Certain functions involve external calls before all internal state changes are finalized, which deviate from the Checks-Effects-Interactions (CEI) pattern. While no direct exploit or reentrancy pathway was identified, inconsistent adherence to CEI can increase the risk of unexpected state dependencies, partial execution, or unforeseen side effects during cross-contract calls. Ensuring strict CEI compliance across all interacting components is recommended to maintain predictable and secure execution flows.