Lumia

Relying on off-chain admin calculations: The off-chain migrating user data from VeOrnPausable to VeLumiaMigrated introduces significant risks. Inaccurate or manipulated off-chain data may lead to incorrect user balances, loss of unclaimed rewards, distorted governance power, and potential financial loss for users, undermining trust and raising legal concerns.

Reliance on Governance External Contracts: The functioning of the system significantly relies on the governance of external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.

Single Points of Failure and Control: The project is fully or partially 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.

Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.

Reward Pool Depletion: If the reward pool balance runs out, users won't be able to withdraw their earned rewards or stakes, as there won't be enough funds to cover the claims. To prevent this, protocol administrators should regularly monitor the reward pool and top it up as needed to ensure it always has enough balance for payouts.

Admin's Unrestricted State Modification: The absence of restrictions on state variable modifications via functions setPointsRewards() and setRewards() by the admin can lead to sudden changes in rewards. This affects contract integrity and user trust, especially during critical operations like reward distribution. Moreover, the incorrect reward value and abnormal duration period for the rewards distribution can potentially result in no rewards being allocated to participants.

Reliance on Owner's Actions: Users who stake their tokens using the dropLock option will encounter withdrawal restrictions and will only be able to retrieve their staked tokens once the isAirdropPassed parameter is activated. Since this activation is performed exclusively by the contract owner through the updateAirdropState() function, it creates a risk of delayed unlocked stakes.

The VeLumiaMigrated::_migrate() function considers the option when the locktime of users' stakes on Ethereum or BSC is different from the same value of users' previous stakes on the Lumia chain resulting in the function choosing the minimum from both values. As a consequence, the user's bigger locktime value can be suddenly changed and replaced with a smaller one after the migration is over.

During the migration process, the ratio between 1 ORN and 1 Lumia token is maintained at 1:1, reflecting the rebranding of ORN to Lumia. While this ensures consistency in the migration, it's important to assess the rebranding process thoroughly to identify and address any potential issues that may have arisen.

This audit report focuses exclusively on the security assessment of the contracts within the specified review scope. Interactions with out-of-scope contracts are presumed to be correct and are not examined in this audit. We want to highlight that Interactions with contracts outside the specified scope, such as the implementation of the IOrionVoting interface, legacy/governance/base/StakingPoints.sol, and other out-of-scope contracts have not been verified or assessed as part of this report. While we have diligently identified and mitigated potential security risks within the defined scope, it is important to note that our assessment is confined to the isolated contracts within this scope. The overall security of the entire system, including external contracts and integrations beyond our audit scope, cannot be guaranteed. Users and stakeholders are urged to exercise caution when assessing the security of the broader ecosystem and interactions with external contracts. For a comprehensive evaluation of the entire system, additional audits and assessments outside the scope of this report are necessary. This report serves as a snapshot of the security status of the audited contracts within the specified scope at the time of the audit. We strongly recommend ongoing security evaluations and continuous monitoring to maintain and enhance the overall system's security.

The previously deployed versions of VeORN and VeLumiaMigrated lack storage gaps in their parent contracts, including StakingPoints, TWBalance, Staking, Pausable and VeOrnMigrator. This omission introduces a significant risk of storage collisions if these parent contracts are modified in the future. Specifically, updates to the storage layouts—such as adding new state variables or restructuring existing ones—could overwrite or corrupt critical data in the child contracts, potentially leading to unpredictable behavior, security vulnerabilities, or complete contract failure.

Front-running During The Initialization Of The Implementation Contract: If the deployment and the initialization of the implementation contract, which is VeLumiaMigrated, will not be handled within one transaction, it can cause the front-running of the VeLumiaMigrated::initialize() function by the attacker which will lead to unexpected system behavior. In addition to that, the VeORNPausable contract does not adhere to the best practices and does not implement the Initialization pattern, which creates a risk of the improper usage of the system.