Is Destra Network (DSYNC) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 High2 Med1 Low1 Info

Critical

Centralized Control and Owner Privileges

C-01The contract owner (an EOA) has extensive control over critical parameters, including setting all fees (buy, sell, liquidity), enabling/disabling trading, blacklisting wallets, changing fee receivers, and adjusting transaction/wallet size limits. A compromise of the owner's private key would allow an attacker to manipulate the token's economics, drain funds from fee receivers, or arbitrarily censor users, leading to catastrophic consequences for the protocol and its users (7.3 Access Control, 7.5 Governance, 7.8 Operations).

IssueThe contract owner (an EOA) has extensive control over critical parameters, including setting all fees (buy, sell, liquidity), enabling/disabling trading, blacklisting wallets, changing fee receivers, and adjusting transaction/wallet size limits. A compromise of the owner's private key would allow an attacker to manipulate the token's economics, drain funds from fee receivers, or arbitrarily censor users, leading to catastrophic consequences for the protocol and its users (7.3 Access Control, 7.5 Governance, 7.8 Operations).

FixImplement a multi-signature wallet for ownership to distribute control and require multiple approvals for critical operations. Consider implementing time-locks for highly sensitive parameter changes (e.g., fee adjustments, blacklisting) to provide a window for community reaction or intervention. Explore decentralizing some control mechanisms through a community governance model.

StatusUnresolved

High

Excessively High Transaction Fees

H-01The `marketingSellFee` is set to 6000, which translates to a 60% fee on sell transactions. Combined with other potential fees, the `totalSellFee` can be extremely high. Such high transaction taxes can severely deter trading activity, reduce liquidity, and make the token economically unviable or unattractive for most users, potentially leading to a 'dead' token (7.4 Economic).

IssueThe `marketingSellFee` is set to 6000, which translates to a 60% fee on sell transactions. Combined with other potential fees, the `totalSellFee` can be extremely high. Such high transaction taxes can severely deter trading activity, reduce liquidity, and make the token economically unviable or unattractive for most users, potentially leading to a 'dead' token (7.4 Economic).

FixRe-evaluate and significantly reduce the transaction fees, especially the sell tax, to a more reasonable and competitive level (e.g., 5-10%). High fees often lead to low trading volume and poor user experience. Clearly communicate the fee structure to users.

StatusUnresolved

High

Blacklisting Functionality

H-02The `blacklistWallet` function allows the owner to permanently prevent any address from transferring tokens. While intended to combat malicious actors, this power can be abused to arbitrarily censor or exclude legitimate users from participating in the token's ecosystem. This introduces a significant centralization risk and goes against the principles of decentralization (7.3 Access Control, 7.5 Governance).

IssueThe `blacklistWallet` function allows the owner to permanently prevent any address from transferring tokens. While intended to combat malicious actors, this power can be abused to arbitrarily censor or exclude legitimate users from participating in the token's ecosystem. This introduces a significant centralization risk and goes against the principles of decentralization (7.3 Access Control, 7.5 Governance).

FixConsider removing the blacklisting functionality entirely to promote a permissionless and censorship-resistant environment. If blacklisting is deemed absolutely necessary, implement it through a transparent, multi-signature, or community-governed process with clear criteria and an appeals mechanism.

StatusUnresolved

Medium

Multiple EOAs Control Launch Parameters

M-01The `updateLaunchBlock` and `updateLaunchTimestamp` functions, which control the token's launch timing, are protected by the `onlyTeam` modifier. This means that multiple external accounts (EOAs) designated as 'team members' can collectively or individually (if not carefully managed) manipulate the launch schedule. This expands the attack surface compared to a single owner, as compromise of any team member's key could affect the launch (7.3 Access Control, 7.8 Operations).

IssueThe `updateLaunchBlock` and `updateLaunchTimestamp` functions, which control the token's launch timing, are protected by the `onlyTeam` modifier. This means that multiple external accounts (EOAs) designated as 'team members' can collectively or individually (if not carefully managed) manipulate the launch schedule. This expands the attack surface compared to a single owner, as compromise of any team member's key could affect the launch (7.3 Access Control, 7.8 Operations).

FixIf multiple team members need control, consider using a multi-signature wallet for the 'team' role. Alternatively, restrict these critical launch control functions to only the contract owner, or implement a time-lock for any changes to provide transparency and prevent last-minute manipulation.

StatusUnresolved

Medium

Potential for Sandwich Attacks on Swap-Back Mechanism

M-02The `swapTokensForEth` function, triggered by the automated swap-back mechanism, performs a `swapExactTokensForETHSupportingFeeOnTransferTokens` operation. While `amountOutMin` is used, these transactions are publicly visible in the mempool. If the `swapThreshold` is significant, a large swap could be susceptible to sandwich attacks, where malicious actors front-run and back-run the swap to extract value, reducing the ETH received by the contract (7.6 External, 7.4 Economic).

IssueThe `swapTokensForEth` function, triggered by the automated swap-back mechanism, performs a `swapExactTokensForETHSupportingFeeOnTransferTokens` operation. While `amountOutMin` is used, these transactions are publicly visible in the mempool. If the `swapThreshold` is significant, a large swap could be susceptible to sandwich attacks, where malicious actors front-run and back-run the swap to extract value, reducing the ETH received by the contract (7.6 External, 7.4 Economic).

FixWhile difficult to fully prevent in public mempools, consider strategies to mitigate MEV, such as using a private transaction relay for swaps if available, or dynamically adjusting `amountOutMin` more aggressively based on current market conditions. Keep `swapThreshold` at a reasonable level to avoid excessively large swaps that are more attractive to MEV bots.

StatusUnresolved

Low

Hardcoded Router Address

L-01The `routerAddress` (0x7a25…488D, Uniswap V2 Router) is hardcoded in the contract's constructor. While this is a common practice for established DEX routers, it means the contract cannot adapt to a new router, a different DEX, or a future version of the current router without a complete redeployment. If the hardcoded router becomes deprecated, compromised, or less liquid, the contract's swap-back functionality would be impacted (7.1 Architecture, 7.8 Operations).

IssueThe `routerAddress` (, Uniswap V2 Router) is hardcoded in the contract's constructor. While this is a common practice for established DEX routers, it means the contract cannot adapt to a new router, a different DEX, or a future version of the current router without a complete redeployment. If the hardcoded router becomes deprecated, compromised, or less liquid, the contract's swap-back functionality would be impacted (7.1 Architecture, 7.8 Operations).

FixConsider making the router address configurable by the owner (e.g., via an `onlyOwner` function `setRouterAddress`). This would allow for flexibility in adapting to ecosystem changes without requiring a full contract redeployment.

StatusUnresolved

Info

Lack of Events for Critical Parameter Changes

I-01Several critical parameters, such as `_maxBuyTxAmount`, `_maxSellTxAmount`, `_maxWalletSize`, `swapThreshold`, and various fee percentages, can be changed by the owner without emitting corresponding events. This lack of event emission makes it difficult for off-chain monitoring tools, users, and auditors to track changes to the token's economic model and operational parameters, reducing transparency (7.8 Operations).

IssueSeveral critical parameters, such as `_maxBuyTxAmount`, `_maxSellTxAmount`, `_maxWalletSize`, `swapThreshold`, and various fee percentages, can be changed by the owner without emitting corresponding events. This lack of event emission makes it difficult for off-chain monitoring tools, users, and auditors to track changes to the token's economic model and operational parameters, reducing transparency (7.8 Operations).

FixEmit specific events whenever critical parameters are modified. This enhances transparency, allows for easier monitoring by external services, and provides a clear historical record of changes for users and auditors.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes Solidity 0.8.17, mitigating integer overflow/underflow risks (7.2 Code Security). It employs standard `Ownable` access control (7.3 Access Control) and an `Address` library for safe external calls. However, the `onlyTeam` modifier introduces multiple points of control for launch parameters, expanding the attack surface (7.3 Access Control). The `swapTokensForEth` function, while protected by an `inSwap` reentrancy guard, performs external swaps that could be subject to MEV (7.6 External).

GovernanceMedium4/10

The economic model features significant owner control over fees, transaction limits, and wallet sizes (7.4 Economic). Notably, the `marketingSellFee` is set to an extremely high 60%, which could severely impact token liquidity and trading viability (7.4 Economic). The owner also possesses the power to blacklist wallets, enabling arbitrary censorship (7.5 Governance). While the automated swap-back mechanism aims to maintain liquidity, its parameters are fully owner-controlled, posing a centralization risk (7.8 Operations).

UpgradesMedium6/10

The DestraNetwork contract is not designed with upgradeability in mind (7.7 Upgrades). This means its logic is immutable once deployed, providing certainty for users regarding its functionality. However, any future changes or bug fixes would necessitate a complete redeployment and migration of assets, which can be a complex and costly process.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

26.6% in top 10

14.3% in wallets12.3% in contracts

Effective Concentration19.2%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$1.01M across 3 pairs

Uniswap v2WETHanalysed$999.9K Uniswap v3WETH$5.5K Uniswap v4ETH$191

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned34.0%

LP Locked100.0% · Null Address, UNCX

Top-1 Unlocked Holder0.0%

Lock Expiry2074 (verified ≥ 1 year) · UNCX V2

Key Addresses

6 addresses

Deployer

0x9ce7…4589

Unlocked LP Held By

0x4218…32890xe7a6…87280xb3ac…68a00x0000…8a900x1f2f…f387

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

5 factors

Ownership NOT renounced — owner is an EOA (single private key)
1 Critical finding(s) from audit
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Not Signed In

Is Destra Network Safe?

Security Findings

Centralized Control and Owner Privileges

Excessively High Transaction Fees

Blacklisting Functionality

Multiple EOAs Control Launch Parameters

Potential for Sandwich Attacks on Swap-Back Mechanism

Hardcoded Router Address

Lack of Events for Critical Parameter Changes

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Destra Network?