ABSTRACT
Dedaub was commissioned to perform a security audit of the eOracle Token Staking protocol. The auditors found 1 low severity security issue with the protocol, and have included 1 advisory issue for the team’s consideration.
BACKGROUND
The eOracle protocol consists of a token contract EOToken with an initial supply of 10,000,000 tokens.
Part of these tokens will be airdropped using an AirDrop contract. Users which have been chosen for the airdrop will be able to claim these tokens during a number of claim windows, where missing one of these windows means forfeiting the rest of the airdrop. The owner of the airdrop contract is able to claim any forfeited tokens. During the first window, a claimant is also able to participate in a StakeDrop, where the tokens slowly vest over a period of time according to a sigmoid function.
Once a user has claimed EOTokens, the user is able to stake these tokens through the protocol. Staking involves locking these tokens for a certain period, and results in these tokens being delegated to an Eigenlayer operator. The lockup period for a stake can be extended, and the stake can also be increased. Withdrawals can be made subject to a queuing period.
The protocol is structured in a number of layers, with the staking and withdrawal flows passing through a number of contracts before resulting in the delegation or the release of the tokens. These flows are access controlled, while the entry points available to the user only make transfers of control to trusted contracts.
The protocol makes use of upgradable contracts and in particular uses the Beacon pattern to deploy an EOStakerPod contract for every staker. As with all upgradable contracts this means that the logic of the protocol can change during the operation of the protocol.
SETTING & CAVEATS
This audit report mainly covers the contracts of the private repository Eoracle/token at commit 0ab70c3617a3432118cabbfab083fa5cd3d90234.
2 auditors worked on the codebase for 4 days on the following contracts:
src/
├── EOAirdrop.sol
└── staking/
├── EOStakeDropSigmoidController.sol
├── EOStakeLockController.sol
├── EOStakeManager.sol
├── EOStakerPod.sol
├── abstract/
│ └── EOStakeControllerBase.sol
└── beacon/
└── EOFactoryBeacon.sol
In addition to the above, the protocol depends on the EOToken contract, which is the ERC20 token upon which the protocol is based. This token contract was regarded as being out of scope for the purpose of the audit and no tokenomic analysis was carried out with respect to it.
The audit’s main target is security threats, i.e., what the community understanding would likely call “hacking”, rather than the regular use of the protocol. Functional correctness (i.e. issues in “regular use”) is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.
VULNERABILITIES & FUNCTIONAL ISSUES
This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:
Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.
CRITICAL SEVERITY
[No critical severity issues]
HIGH SEVERITY
[No critical severity issues]
MEDIUM SEVERITY
[No medium severity issues]
LOW SEVERITY
Lack of upgradeability for abstract contracts
Low | Status: RESOLVED
The abstract contracts EOStateControllerBase and EOFactoryBeacon do not have storage gaps to allow future upgradability. This will create problems with the storage layout of the protocol if new contract variables need to be added to these abstract contracts in the future.
OTHER / ADVISORY ISSUES
This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.
There are no bound checks on any of the setters in the EOStakeLockController
Advisory | Status: RESOLVED
In the functions setMinLockPeriod, setMaxLockPeriod and setMinStakeAmount of the EOStakeLockController contract, there are no validations specifying bounds on the values being set. This means that there is no protection against mistaken or inconsistent inputs.
Compiler bugs
Advisory | Status: INFO
The code is compiled with Solidity 0.8.25. Version 0.8.25, in particular, has no known bugs.
DISCLAIMER
The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.
ABOUT DEDAUB
Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub’s auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.