Salty.IO - yongskiws's results

Salty Audit Analysis

Salty.IO is a Decentralized Exchange built on the Ethereum blockchain, employing Automatic Atomic Arbitrage (AAA) to generate yield and offer Zero Fees on all swaps. Through AAA, market inefficiencies are during the swapping process, resulting in profits that are subsequently distributed to liquidity providers and stakers. These earnings are utilized to establish Protocol Owned Liquidity (POL) for the DAO.

Furthermore, Salty.IO introduces USDS, an overcollateralized ERC20 stablecoin native to the protocol, backed by the WBTC/WETH liquidity pool. The exchange is launched with 100% decentralization, where all parameters, regional exclusions, whitelisting, and contracts are under the control of the DAO itself.

Overview

Structuring the code is crucial for conducting a thorough analysis of the code base. This enables auditors to predict the level of contract difficulty, identify critical contracts, and determine security-critical features such as payment functions or assembly usage. Additionally, this approach accurately measures the time required to perform a detailed audit and helps determine the cost of a project audit. To achieve efficiency, clarity, and improvements, it is essential to have a comprehensive view of the entire architecture. This enables the identification of the basic structure, relationships between modules, and key design patterns. By understanding the big picture, we can analyze the complexity of the code and reveal its strengths and potential for improvement with confidence.

• Lines: total lines of the source unit

• nLines: normalized lines of the source unit (e.g. normalizes functions spanning multiple lines)

• nSLOC: normalized source lines of code (only source-code lines; no comments, no blank lines)

• Comment Lines: lines containing single or block comments

• Complexity Score: a custom complexity score derived from code statements that are known to introduce code complexity (branches, loops, calls, external interfaces, ...)

Consensys Review

Diagrams Risk

Diagrams Source Lines (sloc vs. nsloc)

Exposed Functions

StateVariables

Capabilities

Dependencies / External Imports

AST Node Statistics

Approach to Auditing

• We began by thoroughly reviewing and read docs Salty procotol the provided documentations, as well as reviewing the video provided. Here, we made note of important information, noted down unclear parts and overall tried to fully understand how the protocol should function. We also took notes of integrated and inherited protocols and mapped out possible risk areas.

• While we were studying the docs, we had ran static analyzers and linters through the contracts to detect basic vulnerabilities and other non critical errors. The result of our static analysis was then compared to the provided bot reports and those deemed known were removed.

• After the documentation review and static analysis, we started the process of manual code inspection. We noted how the contracts were divided into different modules and we inspected the contracts in each module carefully. We stuidied each of the contracts, tested how each function behaves and compared that to how they're expected to behave. We then tried out various attack ideas, including the ones provided by the sponsors. We noted the dependencies, inheritancies, and possible vulnerabilities that can arise from them. We made comparisons to issues found in protocols of the same kind (including older commits) to see if the same mistakes were repeated and how effective the provided fixes were.

• After this was done, we made notes on the issues we found and prepared the analysis report.

Codebase quality

Overall, I consider the quality of the Salty codebase to be excellent. The code appears to be very mature and well-developed. We have noticed the implementation of various standards adhere to appropriately. Details are explained below:

Strengths :

Exemplary unit test coverage: The codebase shines with its meticulous unit testing strategy. The comprehensive suite of unit tests ensures the reliability and resilience of the system's core functionality, providing confidence in its performance under various scenarios.

Artful integration of Natspec: A commendable strength is the thoughtful integration of Natspec. The use of this documentation format not only improves code readability, but also exemplifies a commitment to providing clear and human-friendly documentation that fosters a more collaborative and accessible development environment.

Weaknesses :

Opportunities to improve documentation: While the codebase stands out in many ways, there is an opportunity for refinement in the documentation. Addressing this area of improvement can increase the overall clarity of the codebase, make it more accessible, and facilitate seamless collaboration among developers. In essence, the codebase demonstrates proficiency in testing methodologies and documentation practices. Strengthening the documentation further would strengthen the codebase's comprehensibility and contribute to an even more polished and developer-friendly ecosystem.

Analysis of the code base and diagram architecture

ArbitrageSearch

DAO

DAOConfig

Proposals

Airdrop

BootstrapBallot

InitialDistribution

PoolUtils

PoolsConfig

PoolStats

Pools

PoolMath

RewardsConfig

PriceAggregator

RewardsEmitter

SaltRewards

StableConfig

CollateralAndLiquidity

Liquidizer

StakingConfig

Liquidity

StakingRewards

Staking

Upkeep

Approach we followed when reviewing the code

Upkeep a complex set of maintenance steps for various contracts and operations within them, including token swaps, arbitrage, reward distribution, and liquidity management.

StakingRewards StakingRewards abstract contract that provides staking functionality for SALT and issuance of rewards in the form of SALT tokens. These contracts allow for increases and decreases in user stakes, claim of rewards, as well as addition of SALT rewards into a specific pool.

Airdrop maintains a list of users eligible to claim Salty airdrops. Authorized users can claim a certain amount of SALT after a successful BootstrappingBallot contract. Claims can be made after authorization and when airdrop claims are permitted.

CollateralAndLiquidity functions as a liquidity and collateral manager on an exchange. Users can deposit collateral (WBTC and WETH), borrow USDS, withdraw collateral, and liquidate user positions that do not meet the minimum collateral ratio. The contract also monitors the amount of USDS borrowed by each user and provides various display functions for value information in USD.

DAO manages different aspects of the system and provides flexibility to change parameters and perform other management actions through a decentralized voice and decision-making system.

Proposals to manage voting and proposals in the SALT DAO ecosystem

Parameters Code Base Decentralization

The DAO has exclusive control over an extensive list of exchange parameters. For safety, parameters are adjusted incrementally or decrementally within a specified range.

DAO:

• bootstrappingRewards: The amount of SALT provided as a bootstrapping reward for a new pool when a new token is whitelisted. Default: 200k SALT

• percentPolRewardsBurned: For rewards distributed to the DAO, the percentage of SALT that is burned with the remaining staying in the DAO for later use. Default: 50%

• baseBallotQuorumPercent: The minimum amount of xSALT required for ballot quorum. Default: 10%

• ballotMinimumDuration: How many days minimum a ballot has to exist before it can be taken action on. Default: 10 days

• requiredProposalPercentStake: The percent of staked SALT that a user has to have to make a proposal. Default: 0.50%

• maxPendingTokensForWhitelisting: The maximum number of tokens that can be pending for whitelisting at any time. Default: 5

• arbitrageProfitsPercentPOL: The share of the arbitrage profits that are sent to the DAO to form SALT/USDS Protocol Owned Liquidity. Default: 20%

• upkeepRewardPercent: The share of the WETH arbitrage profits sent to the DAO that are sent to the caller of DAO.performUpkeep(). Default: 5%

POOLS:

• maximumWhitelistedPools: The maximum number of pools that can be whitelisted at any one time. Default: 50

• maximumInternalSwapPercent: For swaps internal to the protocol, the maximum swap size as a percent of the reserves. Default: 1%

REWARDS:

• rewardsEmitterDailyPercentTimes1000: The target daily percent of rewards distributed by the stakingRewardsEmitter and liquidityRewardsEmitter. Default: 1%

• emissionsWeeklyPercentTimes1000: The weekly percent of SALT emissions that will be distributed from the Emissions contract. Default: 0.5%

• stakingRewardsPercent: The percentage of rewards received by SALT stakers (compared to liquidity providers). Default: 50%

• percentRewardsSaltUSDS: The percent of SALT Rewards that will be sent directly to the SALT/USDS pool. Default: 10%

STAKING:

• minUnstakeWeeks: The minimum number of weeks for an unstake request at which point minUnstakePercent of the original staked SALT is reclaimable. Default: 2 weeks

• maxUnstakeWeeks: The maximum number of weeks for an unstake request at which point 100% of the original staked SALT is reclaimable. Default: 52 weeks

• minUnstakePercent: The percentage of the original staked SALT that is reclaimable when unstaking the minimum number of weeks. Default: 20%

• modificationCooldown: The minimum time between staking and unstaking or between depositing and withdrawing liquidity (to avoid rewards sniping). Default: 1 hour

STABLECOIN:

• rewardPercentForCallingLiquidation: The collateral percent that a user receives for instigating the liquidation process. Default: 5%

• maxRewardValueForCallingLiquidation: The maximum reward value (in USD) that a user receives for instigating the liquidation process. Default: $500 USD

• minimumCollateralValueForBorrowing: The minimum USD value of collateral - to borrow an initial amount of USDS. Default: $2500 USD

• initialCollateralRatioPercent: The initial maximum collateral / borrowed USDS ratio. Default: 200%

• minimumCollateralRatioPercent: The minimum ratio of collateral / borrowed USDS below which positions can be liquidated. Default: 110%

• percentArbitrageProfitsForStablePOL: The percent of arbitrage profits that are used to form USDS/DAI Protocol Owned Liquidity. Default: 5%

PRICE FEED:

• maximumPriceFeedPercentDifference: The maximum percent difference between two non-zero PriceFeed prices when aggregating price. Default: 3%

• setPriceFeedCooldown: The required cooldown between calls to setPriceFeed. Default: 35 days

Risk Assessment:

Gas Risks

which could introduce additional risks related to price volatility, liquidity, and slippage. Ensuring adequate liquidity and monitoring gas currency prices is essential to maintain the contract's functionality.

Review gas usage in each function and ensure there are no significant gas leaks.

Evaluate whether the Bisection Search and algebra implementations have been optimized efficiently.

Solidity Version

The contract interacts with various external contracts, which could contain bugs or vulnerabilities. Regularly updating the contract and its dependencies can help minimize this risk.

Dependency Risks

external libraries and interfaces, which could introduce additional risks related to version compatibility, security, and maintenance. Ensuring that the dependencies are up-to-date, well-maintained, and secure is crucial for the contract's long-term viability.

Governance Mechanism

Review governance mechanisms, especially the role of DAOs. Ensure decision-making and asset management policies are well defined.

Feed Price

Review and evaluate oracle security against various types of attacks, including price manipulation attacks or fake data intrusions. Consider using multiple oracles to reduce the risk of a single point of failure. Implement a continuous monitoring system to detect suspicious or unusual price changes. Set early warnings and emergency actions if there are indications of price manipulation or oracle failure.

Conclusion

In general, the Salty project exhibits an interesting and well-developed architecture we believe the team has done a good job regarding the code, but the identified risks need to be addressed, and measures should be implemented to protect the protocol from potential malicious use cases. Additionally, it is recommended to improve the documentation and comments in the code to enhance understanding and collaboration among developers. It is also highly recommended that the team continues to invest in security measures such as mitigation reviews, audits, and bug bounty programs to maintain the security and reliability of the project.

Time spent:

36 hours