Smart Contract Analysis Statement

Contract Analysis

The DEOS-X Yield Tranche contract implements a non-transferable receipt token that keeps the ERC20 interface but not its transfer and approval behaviour. The DEOS-X vault creates one such token for each of its three tranches when it is deployed, mints it one to one against the USDT capital an investor places in that tranche and burns it when that capital is paid back, so an investor's balance always equals the capital the vault holds for them in the tranche. The token is a short contract built on a widely used and well established token library. It uses the decimals of the vault's stablecoin, which are eighteen on BNB Smart Chain and six on Ethereum. Only the vault that created it can create or destroy tokens, approvals always revert and no token can ever move from one wallet to another, so the token records ownership of a fund position rather than being a tradable asset. There is no owner, no administrator, no pause switch, no blacklist, no transfer fee, no proxy and no external call anywhere in the code. The three tokens of the live pilot vault on BNB Smart Chain were confirmed to run exactly the reviewed code, although their source has not yet been published on the block explorer. The review found no critical, high, medium or low severity issues. It was proven with symbolic analysis that any call from any address other than the vault leaves an investor's balance, the total supply and the allowance granted to that caller unchanged, and the token's behaviour was exercised in every randomised test of the vault without a single deviation.

Ownership Privileges

The token has no owner and no administrator. The only privileged address is the vault that created it, which is fixed at creation and can never change, and the picture is as follows:

• The vault mints tokens to an investor only as part of a deposit, in exactly the amount of USDT capital placed in the tranche.
• The vault burns an investor's tokens only when the vault owner pays that investor's withdrawal request, in exactly the amount of capital paid back.
• Nobody, including the vault, the vault owner and the holders themselves, can transfer tokens between wallets, approve a spender, freeze a balance or change the token name, symbol or decimals.
• No party can upgrade, replace or shut down the token, because it is not a proxy, contains no code replacement mechanism and cannot be destroyed.
• Because the tokens cannot be sold or transferred, a holder can only exit through a withdrawal request in the vault, and the timing of that exit is decided by the vault owner.

Security Features

The contract implements several positive security features:

• The transfer restriction is enforced in the single internal hook through which every balance change passes, so it covers direct transfers and transfers on behalf of others alike, and only minting and burning can change a balance.
• Approvals are refused outright, so no allowance can ever be created and no spender can ever act on a holder's tokens.
• The minting and burning functions check the caller against an address fixed at creation, and there is no setup call that an outsider could race to claim the minting right.
• The contract makes no external call and contains no inline machine code and no loops, and the few additions and subtractions without overflow checks in the underlying library are each guarded by a preceding balance or supply check, which removes reentrancy, overflow and gas exhaustion problems by construction.
• The token uses the established library's standard balance accounting and events, so wallets and explorers display holdings and the minting and burning history correctly.

Points Requiring Attention

The following matters fall outside the code itself and deserve attention:

• The token keeps the ERC20 function names but refuses approvals and transfers, including transfers of zero. Wallets, portfolio tools and token screening services may show a send function that always fails or flag the token as faulty, so the project should state clearly that the token cannot be transferred and ask explorers to label it accordingly.
• The tokens of the live pilot carry the same names and symbols as the production tranches and are not yet verified on the block explorer. Holders should confirm a token by checking that its vault address is the published vault, and the team should verify the pilot tokens and give future pilot tokens distinct names.
• The token has no market and no value of its own. What a holder receives depends entirely on the vault and on its owner paying withdrawal requests, as described in the separate statement for the vault.

Note - This Audit report consists of a security analysis of the DEOS-X Yield Tranche (TrancheToken) smart contract. This analysis did not include economic analysis of the fund's investment strategy or terms. Moreover, we only audited the LP token contract for the DEOS-X team, and the vault that creates and controls it is covered by a separate statement. Other contracts and systems associated with the project were not audited by our team, including the owner Safe, the investor portal and its backend, the deployment scripts and the testnet helper contracts. We recommend investors do their own research before investing.