Skip to content

Potential Risks

DISCLAIMER // NFA // DYOR

This analysis is based on decompiled bytecode — the contract source code is not verified on Etherscan. Function names, parameter types, and internal logic are inferred from selector matching, transaction input decoding, and event log analysis. We are not smart contract security experts. This document should not be considered a comprehensive security audit or financial advice. Always verify critical information independently.

⊙ generated by robots | curated by humans

METADATA
Contract Address 0x99c96efF...Ab2dCC (etherscan)
Network Ethereum Mainnet
Analysis Date 2026-03-29

Risk Summary Matrix

SEVERITY COUNT CATEGORIES
☒ Critical 4 Custodial Fund Risk, Unverified Source, Keeper Authority, No Audit
△ High 4 Centralized Control, No Timelock, Self-Reported Profit, Withdrawal Uncertainty
△ Medium 3 No Multisig, Young Contract, Fee Opacity
☑ Low 2 Uniswap Dependency, Event Coverage
◇ Informational 2 Unknown Functions, SENT Token Relationship

Critical Risks

☒ CRITICAL: Custodial Fund Risk

Description: The contract holds user ETH directly. Users deposit funds and trust the keeper to trade and manage them. There is no escrow, no insurance fund, and no mechanism for users to control how their funds are traded.

Impact:

  • Keeper can execute any trade, including unprofitable ones
  • No on-chain constraint prevents trading all user funds at a loss
  • Keeper controls slippage tolerance (minTokenOut parameter)
  • If keeper private key is compromised, all pooled funds are at risk
  • No mechanism to prevent keeper from setting unfavorable trade parameters

Current Exposure: ~4.84 ETH across 85 user vaults

Affected Functions:

  • executeTrade (0xea0ccfae) — trades user funds
  • closeTrade (0xd86938ba) — closes positions
  • withdraw / withdrawPartial — fund retrieval (subject to restrictions)

Comparison to Industry:

  • Legitimate DeFi vaults (Yearn, Aave) use audited on-chain strategies with no single-party discretion
  • Managed funds in traditional finance require regulatory licensing, segregated accounts, and insurance
  • This contract has none of these protections

☒ CRITICAL: Unverified Source Code

Description: The contract source code is not verified on Etherscan. All analysis is based on bytecode decompilation, function selector matching, and transaction pattern observation.

Impact:

  • Cannot independently audit the implementation logic
  • Hidden functions or backdoors may exist in the 16 unidentified function selectors
  • Compiler optimizations may obscure actual behavior
  • No guarantee that observed behavior matches intended design

Affected Functions: All — especially the 16 unmatched selectors:

  • 0x06e20080, 0x1a519533, 0x553a9a93, 0x5b451dff, 0x6f747452, 0x8b4c6df1, 0x8c07635a, 0xa0aca335, 0xae1e9118, 0xb3051d6e, 0xbda962d5, 0xc84d5389, 0xc9b6e079, 0xda91a291, 0xe7ba4fe5, 0xe87ce5ee, 0xf1cb0216

Mitigation:

  • Request contract owner verify source code on Etherscan
  • Use transaction simulation before interacting
  • Limit exposure until verification is available

☒ CRITICAL: Unrestricted Keeper Authority

Description: The keeper has complete discretion over all trade parameters with no on-chain constraints beyond MAX_TRADE_ETH (0.5 ETH per trade).

Impact:

  • Keeper chooses which token to buy (could select illiquid or worthless tokens)
  • Keeper sets slippage tolerance (minTokenOut) — could set to 0 allowing maximum slippage
  • Keeper controls trade timing — could front-run market movements
  • Keeper decides when to close positions — could close at a loss
  • No user approval mechanism for individual trades
  • No stop-loss or take-profit automation on-chain

Affected Functions:

  • executeTrade — 7 parameters all controlled by keeper
  • closeTrade — 5 parameters all controlled by keeper

Attack Scenarios:

  1. Keeper executes trades to illiquid tokens with 0 minOutput, extracting value via Sandwich Attacks
  2. Keeper trades into tokens they or associates hold, creating artificial volume
  3. Keeper delays trade execution to capture adverse price movements
  4. Keeper executes many small trades to generate fees while net-zero for users

☒ CRITICAL: No Independent Audit

Description: No audit report is available for this contract. Combined with unverified source code, the contract represents an entirely trust-based system.

Impact:

  • No third-party verification of fund safety
  • No review of access control implementation
  • No validation of trade execution logic
  • No assessment of potential exploits

High Risks

△ HIGH: Centralized Owner/Keeper Control

Description: Owner and keeper are the same single Externally Owned Account (EOA) (0x9fBcc72A...63eA03). This address has:

  • Full administrative control (setKeeper, setFeeRecipient, transferOwnership)
  • Full trade execution authority (executeTrade, closeTrade)
  • Deployed the contract

Impact:

  • Single point of failure — private key compromise = total fund loss
  • No checks and balances between roles
  • No governance or community oversight
  • Owner can change fee recipient, keeper, and ownership at will

Industry Standards:

  • Legitimate DeFi protocols separate admin from operational roles
  • Critical operations require Multisig (3-of-5, 4-of-7)
  • timelock delays allow community review before changes
  • This contract has none of these

△ HIGH: No timelock Protection

Description: All administrative and trade execution functions execute immediately. No delay period exists for any operation.

Impact:

  • Owner can change keeper, fee recipient, and ownership instantly
  • No advance warning for parameter changes
  • Community cannot react to adverse changes
  • No opportunity to withdraw before harmful trades

△ HIGH: Self-Reported Profit

Description: The totalProfitGenerated value (~0.018 ETH) is maintained by the contract's own logic during trade execution. There is no independent verification mechanism.

Impact:

  • Profit calculations may not reflect actual realized gains
  • Closed positions may show "profit" even if the round-trip trade lost value
  • Users relying on getStats() for performance evaluation may be misled
  • No way to verify profit calculations without source code

Verification Difficulty:

  • Would require tracing every trade, calculating actual swap rates, and comparing to reported profit
  • Token amounts received vs sold back must be compared at market rates
  • Fee deductions may not be reflected in profit numbers

△ HIGH: Withdrawal Uncertainty

Description: Only 2 withdrawal transactions were observed in the contract's short history. The withdrawal mechanism's constraints are not fully understood from bytecode alone.

Impact:

  • Unclear whether users can withdraw at any time or only when no active trade exists
  • Unclear whether withdrawal requires keeper approval
  • Unclear whether partial withdrawals return proportional profit
  • Cannot verify fund availability guarantees

Observed:

  • 0x2e1a7d4d (withdraw) — 2 calls
  • 0x66c91379 (withdrawPartial) — 0 calls observed

Medium Risks

△ MEDIUM: No Multisig Protection

Description: Single EOA owner controls all administrative functions with no multi-signature requirement.

Current Owner: 0x9fBcc72A...63eA03

Impact:

  • No distributed trust model
  • Single point of compromise for all admin functions
  • No way for users to prevent unilateral owner actions

△ MEDIUM: Extremely Young Contract

Description: The contract was deployed on 2026-03-28 — approximately 1 day before this analysis. It has not undergone the test of time and usage that older protocols have.

Impact:

  • No Lindy Effect — unproven durability
  • Potential for undiscovered bugs in complex trade logic
  • Limited transaction history to analyze behavioral patterns
  • 85 users depositing into a day-old unverified contract represents elevated risk

△ MEDIUM: Fee Structure Opacity

Description: A flat 0.005 ETH fee is sent to the fee recipient on each deposit, but the stored fee value in slot 7 shows 0.01 ETH. The discrepancy is unclear.

Impact:

  • Fee calculations may not be transparent
  • Fee amount could be changed by owner (if settable via unidentified function)
  • Users may not fully understand fee structure before depositing
  • Additional hidden fees may exist in trade execution

Low Risks

☑ LOW: Uniswap V3 Dependency

Description: All trades execute through Uniswap V3 SwapRouter at 0xe592427A...861564. This is a well-audited, battle-tested protocol.

Assessment: Low risk — Uniswap V3 is one of the most used and audited DeFi protocols. The dependency itself is not a concern; the risk is in how the keeper uses it.

☑ LOW: Event Coverage

Description: The contract emits events for deposits, trades, and administrative changes. This enables off-chain monitoring.

Events Observed:

  • VaultDeposit (28 occurrences)
  • TradeExecuted (13 occurrences)
  • TopUpOrWithdraw (8 occurrences)
  • OwnershipTransferred (1 occurrence)

Assessment: Good practice for transparency. Users can monitor keeper actions via event logs.

Informational

◇ INFO: 16 Unknown Function Selectors

Description: Of 44 function selectors in the dispatch table, 16 could not be matched to known signatures via 4byte.directory or cast 4byte. These represent custom functions whose purpose is unknown.

Questions:

  • Do any of these functions allow fund extraction?
  • Are any of these admin functions with additional powers?
  • Could they represent emergency/backdoor functionality?
  • Are they view functions or state-changing?

Recommendation: Source code verification would resolve these unknowns.

◇ INFO: SENT Token Relationship

Description: The contract references the Sentinel SENT token (0xe88BaAB9...aDc304) for eligibility/tier purposes. Users declare a SENT amount during deposit, but the contract does not appear to transfer or lock SENT tokens.

Observations:

  • Users can deposit with sentAmount = 0 (no SENT required)
  • getEligibility checks the user's SENT balance via the token contract
  • Tier system appears to reward higher SENT holders with potential benefits
  • The actual benefit of holding SENT for this vault is unclear from bytecode alone

Risk Mitigation Checklist

For users considering interaction with this contract:

  • Understand this is a custodial system — you are trusting the keeper with your ETH
  • Accept that the keeper has full discretion over trade execution
  • Accept risk of unverified source code with 16 unknown functions
  • Verify withdrawal functionality works before depositing significant amounts
  • Monitor TradeExecuted events to track what trades the keeper makes
  • Keep exposure small — the contract is 1 day old with no audit
  • Monitor for ownership or keeper changes via events
  • Understand the 0.005 ETH flat fee on each deposit
  • Accept that reported profits are self-calculated by the contract

For the contract owner:

  • Verify source code on Etherscan
  • Separate owner and keeper roles to different addresses
  • Transfer ownership to a Multisig
  • Implement timelock for administrative functions
  • Commission an independent security audit
  • Publish documentation explaining the trading strategy
  • Implement on-chain safeguards (max loss per trade, daily trade limits)
  • Add user consent mechanism for trade execution
  • Document fee structure transparently

Disclaimer

This risk analysis is based on bytecode decompilation and transaction pattern observation of an unverified contract. It should not be considered a comprehensive security audit. Professional blockchain security auditors should review the contract before any critical decisions or significant value interactions. The observations in this document may not capture all risks, and the actual contract behavior could differ from the analysis.