Is Unitas (UP) Safe? Smart Contract Security Analysis

Security Findings

2 High1 Med2 Info

High

Centralization of Control by Owner Multisig

H-01The `UnitasOFT` contract inherits `Ownable`, granting a single owner address (a 3/5 multisig) extensive administrative control. This owner can configure critical LayerZero parameters such as `setPeer`, `setSendVersion`, `setReceiveVersion`, `setConfig`, `setPrecrime`, `setOracle`, `setFeeCollector`, and `setTreasury` through the inherited `OFT` and `OApp` functions. Malicious or erroneous actions by the multisig signers could lead to severe consequences, including disabling cross-chain transfers, redirecting fees, or compromising the integrity of the token bridge.

IssueThe `UnitasOFT` contract inherits `Ownable`, granting a single owner address (a 3/5 multisig) extensive administrative control. This owner can configure critical LayerZero parameters such as `setPeer`, `setSendVersion`, `setReceiveVersion`, `setConfig`, `setPrecrime`, `setOracle`, `setFeeCollector`, and `setTreasury` through the inherited `OFT` and `OApp` functions. Malicious or erroneous actions by the multisig signers could lead to severe consequences, including disabling cross-chain transfers, redirecting fees, or compromising the integrity of the token bridge.

FixEnsure the multisig signers are highly trusted individuals, and that robust internal governance procedures, including strict review and approval processes, are in place for all administrative actions. Consider implementing a timelock for critical operations to provide a window for community review or emergency intervention.

StatusUnresolved

High

Reliance on LayerZero Protocol Security

H-02As an Omnichain Fungible Token (OFT) built on LayerZero v2, the contract's cross-chain functionality is entirely dependent on the security and operational integrity of the LayerZero protocol. This includes the security of LayerZero endpoints, relayers, oracles, and precrime mechanisms. Vulnerabilities or exploits within the LayerZero infrastructure, or issues with external actors (e.g., relayers censoring messages, oracles providing incorrect data), could directly impact the `UnitasOFT` token, potentially leading to loss of funds, frozen assets, or incorrect state synchronization across chains.

IssueAs an Omnichain Fungible Token (OFT) built on LayerZero v2, the contract's cross-chain functionality is entirely dependent on the security and operational integrity of the LayerZero protocol. This includes the security of LayerZero endpoints, relayers, oracles, and precrime mechanisms. Vulnerabilities or exploits within the LayerZero infrastructure, or issues with external actors (e.g., relayers censoring messages, oracles providing incorrect data), could directly impact the `UnitasOFT` token, potentially leading to loss of funds, frozen assets, or incorrect state synchronization across chains.

FixWhile direct mitigation within the `UnitasOFT` contract is limited, it is crucial to stay updated on LayerZero's security announcements and best practices. Implement robust monitoring for LayerZero-related events and transactions. Consider diversifying cross-chain solutions or implementing circuit breakers if the protocol's design allows for such measures in case of a LayerZero-wide incident.

StatusUnresolved

Medium

Risk of Owner Misconfiguration

M-01The owner multisig has the ability to configure various LayerZero parameters. Incorrectly setting these parameters, such as an invalid `peer` address, an unsupported `sendVersion` or `receiveVersion`, or an erroneous `config` for a specific `eid`, could lead to cross-chain messages failing, tokens becoming stuck on a particular chain, or unintended behavior. While the owner is a multisig, human error or a lapse in judgment during configuration remains a risk.

IssueThe owner multisig has the ability to configure various LayerZero parameters. Incorrectly setting these parameters, such as an invalid `peer` address, an unsupported `sendVersion` or `receiveVersion`, or an erroneous `config` for a specific `eid`, could lead to cross-chain messages failing, tokens becoming stuck on a particular chain, or unintended behavior. While the owner is a multisig, human error or a lapse in judgment during configuration remains a risk.

FixImplement a rigorous testing and verification process for all LayerZero configuration changes before deployment to production. Utilize a staging environment to simulate changes and ensure they function as expected. Document all configuration parameters and their intended values.

StatusUnresolved

Info

Non-Upgradeable Contract

I-01The `UnitasOFT` contract is deployed as a standard implementation contract and is not designed to be upgradeable via proxy patterns. This means that once deployed, its logic cannot be modified. Any future bug fixes, feature enhancements, or protocol changes would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.

IssueThe `UnitasOFT` contract is deployed as a standard implementation contract and is not designed to be upgradeable via proxy patterns. This means that once deployed, its logic cannot be modified. Any future bug fixes, feature enhancements, or protocol changes would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.

FixAcknowledge the implications of a non-upgradeable contract. For critical infrastructure, consider the long-term implications of immutability versus the flexibility of upgradeability. If future upgrades are anticipated, a proxy pattern might be considered for future iterations.

StatusUnresolved

Info

Minimal Custom Logic

I-02The `UnitasOFT` contract primarily acts as a wrapper, inheriting functionality from `OFT` and `Ownable` without introducing significant custom logic or state variables beyond the constructor. While this reduces the attack surface for new vulnerabilities within `UnitasOFT` itself, it means that the security profile is largely determined by the underlying LayerZero and OpenZeppelin libraries.

IssueThe `UnitasOFT` contract primarily acts as a wrapper, inheriting functionality from `OFT` and `Ownable` without introducing significant custom logic or state variables beyond the constructor. While this reduces the attack surface for new vulnerabilities within `UnitasOFT` itself, it means that the security profile is largely determined by the underlying LayerZero and OpenZeppelin libraries.

FixContinue to rely on well-audited and maintained external libraries. Ensure that any future custom logic introduced into similar contracts undergoes thorough security review.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract `UnitasOFT` is well-structured, inheriting from battle-tested OpenZeppelin `Ownable` and LayerZero `OFT` libraries (7.1 Architecture). It introduces no custom complex logic, reducing the surface area for new technical vulnerabilities (7.2 Code Security). The use of standard libraries mitigates common issues like reentrancy and integer overflows. However, the inherent complexity of cross-chain messaging via LayerZero introduces dependencies on external components like relayers and oracles, which are outside the direct control of this contract and represent a technical risk (7.6 External).

GovernanceHigh2/10

The contract utilizes an `Ownable` pattern, with a 3/5 multisig () acting as the owner (7.3 Access Control). This multisig holds significant administrative power, including the ability to configure LayerZero parameters such as peers, message versions, and potentially fees, which directly impacts the economic flow and security of cross-chain transfers (7.4 Economic). While a multisig reduces single points of failure, the concentration of control remains a notable governance risk (7.5 Governance). Misconfiguration by the owner could lead to funds being stuck or lost.

UpgradesLow7/10

The `UnitasOFT` contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates risks associated with proxy implementation bugs or upgrade path vulnerabilities. However, it means that any future changes or bug fixes would require a new contract deployment and a token migration process, which can be complex and costly.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

98.0% in top 10

5.3% in wallets92.7% in contracts

Effective Concentration42.4%

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.33M across 8 pairs

Pancakeswap v3WBNBanalysed$725.0K Pancakeswap v3WBNB$604.8K Pancakeswap v2UPV$320 Uniswap v2USDC$139 Pancakeswap v2Subject 3$6 Pancakeswap v3USDT$3

Show 2 more pairsShow less

Pancakeswap v3USDT$2 Pancakeswap v2WBNB$0

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

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0x0c54…0b36

Unlocked LP Held By

0x0144…69c60xc7e2…e64f0x592e…9318

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

What Raised This Score

8 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Top-10 concentration > 30% (98.0% total → 42.4% effective; 5.3% in EOAs, 92.7% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Volume/Liquidity > 15× (24.1× — wash-trading signal)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 55% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 55% of DEX liquidity)
2 High finding(s) from audit
1 Medium 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

Is Unitas Safe?

Security Findings

Centralization of Control by Owner Multisig

Reliance on LayerZero Protocol Security

Risk of Owner Misconfiguration

Non-Upgradeable Contract

Minimal Custom Logic

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 Unitas?