Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Lydia Info

lydiaexchange.com

Lydia proposes a decentralized infrastructure for the issuance, trading, and settlement of features derivatives using smart contracts and oracle networks. Existing derivatives markets suffer from centralization, restricted access, high fees, and opaque operational logic. Lydia eliminates the need for trusted intermediaries by deploying collateral-backed features assets on permissionless blockchains. These assets mirror the price behavior of real-world instruments without requiring custody or delivery. All settlement and risk management are enforced on-chain via transparent smart contracts. Real-time pricing is achieved through decentralized oracles. Lydia aims to redefine the architecture of global derivatives by offering programmable, auditable, and universally accessible financial instruments.

Lydia Logo
Onboarded date 11/11/2025

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

80.00
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
N/A
Network N/A
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/11/11
Revision date 2025/11/11

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is not renounced

The owner retains significant control, which could potentially be used to modify key contract parameters.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Ownership Privileges
  • The owner can set the admin wallet address.
  • The owner can set the price feed hash.
  • The owner can request withdrawal of USDC and ETH from the contract.
  • The owner can confirm the withdrawal request only after the delay, which is set to 24hours.
  • The owner can cancel the withdrawal request.

Note - This Audit report consists of a security analysis of the Lydia smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the Lydia team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Findings and Audit result

Critical
High
Medium
Low
Optimization
2
Informational
high Issues | 1 findings

Resolved

#1 high Issue
Unrestricted Withdrawal Functions Create Critical Centralization and Rug Pull Risk
Program.sol
L251-260
L262-266
Description

The contract contains withdrawUSDC and withdrawETH functions that grant the contract owner the unilateral and unrestricted ability to drain the entire balance of these assets from the protocol at any time. This creates a severe centralization risk, as the contract’s fundamental promise—to allow users to sell their tokens back for USDC—is entirely dependent on the owner's choice to maintain liquidity. This design forces users to place absolute trust in a single, centralized entity rather than in the decentralized code. It exposes all token holders to a total loss of their investment through various scenarios, including a malicious rug pull by the owner, theft of funds by an attacker who compromises the owner's private key, or even a simple human error in fund management.

Comments

To mitigate this critical risk and build user trust, the withdrawal mechanism must be decentralized and transparent. Instead of allowing immediate, unilateral withdrawals by a single owner, the contract should implement a trust-minimizing system. The recommended approaches are either a Timelock or Multisignature Control. A timelock would enforce a mandatory delay (e.g., 24-48 hours) between the initiation of a withdrawal and its execution, giving users a public window to see the withdrawal and exit their positions if they disagree with it. Alternatively, requiring signatures from multiple parties (a multisig wallet) to approve any withdrawal would prevent a single point of failure from compromising the protocol's funds. Both mechanisms replace the need for absolute trust with a verifiable and more secure process.

Alleviation

The contract introduces a timelock mechanism for withdrawals (requestWithdrawal, executeWithdrawal) which is a great improvement. However, the original, unrestricted withdrawUSDC and withdrawETH functions still exist. These functions allow the owner to bypass the timelock and withdraw funds instantly, which means the centralization and rug pull risk is still present. To fix this, the withdrawUSDC and withdrawETH functions should be removed entirely, forcing all owner withdrawals to go through the new timelock process. Hence the issue is considered as partially resolved.

medium Issues | 4 findings

Resolved

#1 medium Issue
Flawed Price Verification Allows Admin-Approved Exploitation
Program.sol
L83-153
Description

The buyTokens function contains a critical design flaw where the final token calculation uses a tokenPrice provided by an off-chain admin signature, while a potentially stale on-chain oracle price is used only for a slippage check. This creates an exploit scenario where an admin could be tricked into signing a transaction based on a stale oracle price. Because the signed price would match the stale on-chain price, the flawed slippage check would pass, allowing a user to purchase tokens at a price significantly below fair market value. The core issue is that the price used for execution is dictated by an off-chain, user-provided parameter rather than a reliable, fresh on-chain price source.

Comments

A robust mitigation requires ensuring that the transaction executes at the fair market price, as determined by the oracle. This should be implemented in three steps. First, the function must be modified to guarantee a fresh oracle price by uncommenting the pythContract.updatePriceFeeds call and using getPrice instead of getPriceUnsafe. Second, the slippage check should be maintained to ensure the admin-signed tokenPrice is closely aligned with the fresh oracle price. Finally, the token minting calculation must be altered to use the fresh oraclePrice8Decimals directly, rather than the tokenPrice from the signature. This ensures the admin's signature serves as an authorization for the sale, but the actual price is always the current, secure on-chain market price.

Resolved

#2 medium Issue
Signature Malleability Allows Fund Theft via Replay Attack
Program.sol
L61-81
Description

The core security of the contract is compromised by a flaw in the validSignature modifier, which fails to implement domain separation. The signature hash is generated from a generic set of parameters (amount, price, nonce) without including any context about the intended function call (e.g., "buy" or "sell"). This vulnerability allows an attacker to capture a valid signature from one function, such as buyTokens, and successfully replay it on another, sellTokens. The contract will incorrectly validate the signature for the wrong context, misinterpreting the signed usdcAmount from a buy operation as a tokenAmount for a sell operation, leading to an unauthorized withdrawal of USDC and a complete drain of the contract's funds.

Comments

To mitigate this, the signature verification process must be updated to include domain separation, ensuring that a signature is only valid for the specific function it was created for. This can be achieved by modifying the validSignature modifier to accept an additional parameter, such as a string or bytes32 selector, that uniquely identifies the action (e.g., "buyTokens", "sellTokens"). This unique identifier must then be included in the data that is hashed and signed. By tying each signature to its intended function, this change makes it impossible to replay a signature across different functions, preventing the described theft of funds.

Resolved

#3 medium Issue
Execution Price Dictated by User Input, Not Oracle
Program.sol
L143
L211
Description

The contract's core financial logic is critically flawed because it uses an admin-signed, user-provided tokenPrice for its final calculations instead of the secure on-chain oracle price. While the contract does fetch a price from the Pyth oracle, it is only used for a superficial slippage check. This creates a security theater where the check can pass if the admin is tricked into signing a price that matches a stale or manipulated oracle price. The actual execution—the amount of tokens minted or USDC transferred—relies entirely on the potentially malicious price from the signature, allowing an attacker to dictate the terms of the trade and systematically drain value from the protocol by buying below or selling above fair market value.

Comments

The fundamental design must be inverted so that the on-chain oracle is the single source of truth for pricing. The admin's signature should serve only as an authorization to transact, not as a price quote. The mitigation involves three steps: first, ensure a fresh oracle price is fetched within every transaction by using updatePriceFeeds and getPrice. Second, perform the slippage check by comparing the user's desired price against this fresh oracle price. Third, and most importantly, the final calculation for minting or transferring assets must use the fresh, validated oraclePrice as its basis, completely ignoring the user-provided tokenPrice for anything other than the slippage validation.

Resolved

#4 medium Issue
Calculation Flaw in Price Normalization Leads to Unreliable Slippage Checks
Program.sol
L83-153
L155-231
Description

The contract's price normalization logic contains a critical calculation flaw that leads to a significant loss of precision, rendering the slippage check unreliable. Specifically, when handling prices of low-value assets that have a large negative exponent from the oracle, the code performs integer division prematurely (price / 10**...). This "division before multiplication" error truncates valuable digits, causing the calculated oraclePrice8Decimals to become highly inaccurate or even zero. This flawed, low-precision value is then used in the vital slippage comparison against the admin-signed price. Consequently, the check becomes meaningless; it can cause valid transactions to fail with a false price deviation error or, in other edge cases, fail to catch a real deviation, undermining one of the contract's core safety mechanisms.

Comments

To resolve this, the financial logic must be refactored to avoid lossy pre-normalization. Instead of converting the oracle price to a fixed 8-decimal format, all price comparisons should be performed by scaling both the oracle price and the admin-signed price to a common, higher-precision denominator before any division occurs. This can be achieved through cross-multiplication, a standard technique in fixed-point arithmetic that preserves precision and ensures that the comparison is mathematically sound and reliable.

low Issues | 1 findings

Resolved

#1 low Issue
Missing validation for constructor parameters
Program.sol
L47-59
Description

The constructor of the Program contract initializes several critical addresses (_pythContract, _usdcToken, _adminWallet) and a _tokenPriceFeedId without validating them. If any of the address parameters are initialized with the zero address (address(0)), it can lead to contract malfunction. For example, interactions with the Pyth oracle or the USDC token contract would fail, and administrative controls could be lost if _adminWallet is the zero address. Similarly, a zero value for _tokenPriceFeedId could cause price feed lookups to fail.

Comments

To mitigate this vulnerability, I have added require statements in the constructor to ensure that none of the address parameters are the zero address and that _tokenPriceFeedId is not zero. This ensures that the contract is initialized with valid parameters, preventing locked funds or failed contract interactions due to invalid setup.

informational Issues | 2 findings

Acknowledged

#1 informational Issue
Floating pragma solidity version
Program.sol
L2
Description

Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.

Pending

#2 informational Issue
Manual Price Normalization Increases Code Complexity
Program.sol
L83-153
L155-231
Description

The contract contains large, complex blocks of code in both the buyTokens and sellTokens functions (lines 103-119 and 176-192, respectively) dedicated to manually normalizing the Pyth oracle price into a fixed 8-decimal format. While the logic may function correctly under expected conditions, its multi-branched, verbose nature makes it difficult to audit and introduces a latent risk of subtle bugs, such as precision loss or rounding errors with unexpected exponent values. This custom implementation is a source of technical debt and is less gas-efficient than more direct calculation methods, increasing the contract's complexity without a clear benefit.

Comments

It is recommended to refactor the contract's financial calculations to avoid this manual normalization step. The arithmetic for token amounts and slippage checks should be performed by directly using the pythPrice.price and pythPrice.expo values provided by the oracle. This approach would eliminate the complex and fragile normalization blocks, resulting in code that is significantly cleaner, more gas-efficient, easier to audit, and more robust against potential edge cases in the oracle's data structure.