Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is SEI Safe?

Ethereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance2/10Upgrades6/10Checks passed3 of 5Findings1 Critical · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

This audit was conducted on a partial codebase consisting solely of interfaces and two utility libraries (AddressCast, OFTComposeMsgCodec).

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Top-10 concentration > 50%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 50% (95.7% total → 59.1% effective; 34.8% in EOAs, 60.9% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 1 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
60.9%Contracts34.8%Wallets4.3%Everyone else
60.9%Contracts34.8%Wallets4.3%
ContractsWalletsEveryone elseBubble area = share of supply
95.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking60.9%
  • Walletsanonymous holders, free to sell34.8%
  • Everyone elsethe rest of the supply4.3%
Effective concentrationwhat the score reads59.1%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$2.30M

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$2.30MShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xb6cf…c5740x6708…93e40x5ca2…d75f

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

Security Findings

1 Critical1 Medium1 Low2 Info
Critical

Incomplete Codebase for Audit (Missing OFTImplementation)

The primary contract, OFTImplementation, which is expected to contain the core business logic, state variables, and access control mechanisms for the Omnichain Fungible Token, was not provided for review. This prevents a comprehensive security assessment of the protocol's functionality, potential vulnerabilities (e.g., reentrancy, integer overflows, access control flaws), and overall system integrity. Without the implementation, the actual security posture of the protocol cannot be determined.C-01

Issue

The primary contract, OFTImplementation, which is expected to contain the core business logic, state variables, and access control mechanisms for the Omnichain Fungible Token, was not provided for review. This prevents a comprehensive security assessment of the protocol's functionality, potential vulnerabilities (e.g., reentrancy, integer overflows, access control flaws), and overall system integrity. Without the implementation, the actual security posture of the protocol cannot be determined.

Fix

Provide the complete and verified source code for the OFTImplementation contract to enable a full and accurate security audit. This is essential for identifying and mitigating potential vulnerabilities before deployment or further integration.

Status

Unresolved

Medium

Potential for Misinterpretation with abi.encodePacked in OFTComposeMsgCodec

The OFTComposeMsgCodec library utilizes abi.encodePacked for message encoding. While this is a common practice for cross-chain messaging, abi.encodePacked does not add padding and can lead to ambiguity or misinterpretation if the decoding logic on the receiving chain or within other parts of the protocol does not precisely match the encoding structure, especially when dealing with variable-length data (bytes _composeMsg). A mismatch could lead to incorrect parsing of message components like nonce, srcEid, or amountLD.M-01

Issue

The OFTComposeMsgCodec library utilizes abi.encodePacked for message encoding. While this is a common practice for cross-chain messaging, abi.encodePacked does not add padding and can lead to ambiguity or misinterpretation if the decoding logic on the receiving chain or within other parts of the protocol does not precisely match the encoding structure, especially when dealing with variable-length data (bytes _composeMsg). A mismatch could lead to incorrect parsing of message components like nonce, srcEid, or amountLD.

Fix

Ensure that all decoding logic strictly adheres to the exact encoding structure defined in OFTComposeMsgCodec. Consider adding explicit length prefixes for variable-length data within the _composeMsg if not already handled by the underlying LayerZero messaging system, or use abi.encode for fixed-size encoding where possible to reduce ambiguity. Thorough cross-chain testing of message encoding and decoding is crucial.

Status

Unresolved

Low

Low-Level Assembly in AddressCast.toBytes

The AddressCast.toBytes function employs inline assembly for byte manipulation. While the function includes size checks and appears to correctly handle the conversion, assembly code is inherently more complex and less readable than high-level Solidity. This increases the risk of subtle bugs, off-by-one errors, or unexpected behavior if not rigorously tested across all edge cases, potentially leading to incorrect address or byte array representations.L-01

Issue

The AddressCast.toBytes function employs inline assembly for byte manipulation. While the function includes size checks and appears to correctly handle the conversion, assembly code is inherently more complex and less readable than high-level Solidity. This increases the risk of subtle bugs, off-by-one errors, or unexpected behavior if not rigorously tested across all edge cases, potentially leading to incorrect address or byte array representations.

Fix

Thoroughly review and test the AddressCast.toBytes function with a wide range of inputs, including edge cases for _size (e.g., 1, 32) and _addressBytes32 values. Consider adding comprehensive unit tests to ensure its correctness and resilience. If possible, explore alternative high-level Solidity constructs that achieve the same functionality to improve readability and reduce potential error surface.

Status

Unresolved

Info

Extensive Interface Definitions Indicate High System Complexity

The provided codebase includes a significant number of interfaces (IMessageLibManager, IMessagingChannel, IMessagingComposer, IPreCrime, etc.). While this modular design promotes separation of concerns and reusability, a large number of interconnected interfaces suggests a highly complex system architecture. Increased complexity can lead to a larger attack surface, make it more challenging to reason about the overall system's security, and increase the potential for integration errors between different components.I-01

Issue

The provided codebase includes a significant number of interfaces (IMessageLibManager, IMessagingChannel, IMessagingComposer, IPreCrime, etc.). While this modular design promotes separation of concerns and reusability, a large number of interconnected interfaces suggests a highly complex system architecture. Increased complexity can lead to a larger attack surface, make it more challenging to reason about the overall system's security, and increase the potential for integration errors between different components.

Fix

Maintain clear and comprehensive documentation for the entire system, detailing the responsibilities of each interface and how they interact. Implement robust integration testing to ensure seamless and secure communication between all components. Consider architectural reviews to identify and simplify any overly complex interdependencies.

Status

Unresolved

Info

Lack of Access Control Context in Interfaces

Several functions defined within the interfaces (e.g., registerLibrary, setDefaultSendLibrary, setEnforcedOptions in IMessageLibManager, setEnforcedOptions in IOAppOptionsType3) imply privileged administrative actions. Without the concrete implementation of these interfaces, it is impossible to verify if robust access control mechanisms (e.g., onlyOwner, role-based access control, multi-signature wallets) are properly applied to prevent unauthorized users from invoking these critical functions and altering protocol parameters.I-02

Issue

Several functions defined within the interfaces (e.g., registerLibrary, setDefaultSendLibrary, setEnforcedOptions in IMessageLibManager, setEnforcedOptions in IOAppOptionsType3) imply privileged administrative actions. Without the concrete implementation of these interfaces, it is impossible to verify if robust access control mechanisms (e.g., onlyOwner, role-based access control, multi-signature wallets) are properly applied to prevent unauthorized users from invoking these critical functions and altering protocol parameters.

Fix

Ensure that all functions within the OFTImplementation that correspond to these privileged interface methods are protected by strong access control. Implement a multi-signature wallet for critical administrative roles to enhance security and decentralization. Clearly document the access control policies for each sensitive function.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

This audit was conducted on a partial codebase consisting solely of interfaces and two utility libraries (AddressCast, OFTComposeMsgCodec). The core contract, OFTImplementation, which would contain the primary business logic, state management, and access control mechanisms, was not provided. Consequently, a comprehensive security assessment of the protocol's functionality, economic model, and governance structure is not possible. The identified risks primarily relate to the inherent limitations of reviewing an incomplete system and potential complexities within the provided libraries.

Technical8/10Low risk

The provided codebase consists of well-defined interfaces and two utility libraries, AddressCast and OFTComposeMsgCodec. The AddressCast library includes robust input validation for address conversions, such as checking _addressBytes.length before casting (7.2 Code Security). However, the core OFTImplementation contract is missing, preventing any assessment of the actual implementation's security, reentrancy, or integer overflow vulnerabilities (7.1 Architecture, 7.2 Code Security). The OFTComposeMsgCodec library utilizes abi.encodePacked, which, while common, requires strict adherence to decoding logic to avoid misinterpretation in cross-chain messages (7.2 Code Security).

Governance2/10High risk

Due to the absence of the OFTImplementation contract, it is impossible to assess the protocol's governance model, economic stability, or potential for oracle manipulation (7.4 Economic, 7.5 Governance). Interfaces like IMessageLibManager define functions such as setDefaultSendLibrary and setEnforcedOptions, which imply significant administrative control. Without the implementation, the robustness of access control mechanisms for these critical functions cannot be verified, posing a high risk of unauthorized actions (7.3 Access Control).

Upgrades6/10Medium risk

The provided information states is_proxy: false, suggesting the OFTImplementation might not be directly upgradeable via a proxy pattern. However, without the actual contract code, it's impossible to confirm this or assess any other upgrade mechanisms (7.7 Upgrades). The lack of the core contract also prevents an evaluation of potential upgrade safety issues, such as storage collisions or initialization logic, if an upgrade pattern were to be introduced later. Therefore, the upgrade safety and operational risks (7.8 Operations) remain unassessable.

Final RecommendationWhat to do about this score

A comprehensive security audit requires access to the complete and deployed source code of the OFTImplementation contract.

Without this crucial component, any security assessment is inherently incomplete and cannot guarantee the safety of the protocol. It is strongly recommended to provide the full codebase for a thorough review covering all aspects of smart contract security, including reentrancy, access control, economic models, and upgradeability. Additionally, ensure that all critical administrative functions within the OFTImplementation are protected by robust, multi-signature based access control.

Contract & Record

1 audit on record
TypeSolidity 0.8.28
NetworkEthereum
Token age1y
Contract0xbdf4…788b
Deployer0x3554…5332
Badge for your website
SEI security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 13, 202662Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the SEI contract address?

The SEI contract on Ethereum is 0xbdf43ecadc5cef51b7d1772f722e40596bc1788b. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is SEI a scam?

Quantum Audit's risk score for SEI is 62/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is SEI liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $2.30M.

Who holds SEI?

As of Sep 4, 2026, the 10 largest holders own 95.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
DolomiteDOLO · Ethereum62MediumRedstoneRED · Ethereum62MediumPinLinkPIN · Ethereum62MediumFuse CatFUSECAT · Ethereum62MediumEtherStreetSTREET · Ethereum62MediumCONDOEthereum62Medium

Would You Like a More Detailed Audit of SEI?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page