Scope & method. I’m basing this breakdown entirely on materials I captured directly: front-end code bundles, on-page text, and Network/XHR logs. I’m not leaning on outside marketing blurbs or hearsay. Instead, I’ll walk you through Orbion using its own words and behavior—UI states, API calls, and just as importantly, what’s missing (wallet-connect, signature prompts, on-chain transactions, DEX integrations). The aim is straightforward evidence and clear reasoning—no hype, no dramatics.

What Orbion Says It Is

Orbion (domain name: orbion.vip) presents itself as an “Advanced DEX Sniping Bot” for the Solana ecosystem. Across the interface copy and feature panels, the product introduces a familiar story:

• Automated trading via a “bot” you can create and manage inside a web dashboard with tabs like Create Bot and My Bots.
• Prominent features listed: “24/7 Automated Trading,” “Real-Time Synchronization,” “Telegram Bot Access,” “Risk Management.”
• A Telegram bot is positioned as an auxiliary control/notification surface.
• A simple amount input (peso-denominated) and a “Wallet Balance” readout exist right on the page, implying that once you “fund” your account, the bot will operate on your behalf.

If you stop here, Orbion looks like a slick, consumer-friendly gateway to “hands-free” Solana trading.

What a Real Solana Sniping/Trading Bot Must Do (Baseline)

Before we audit Orbion, here’s the minimum a genuine Solana-native trading/sniping tool must demonstrate:

• Web3 Wallet Connection. A Connect Wallet flow (Phantom, Solflare, Backpack, Slope/Sollet, etc.). In code, you’ll typically see window.solana and wallet-adapter patterns.
• On-Chain Transaction Prompts. On every buy/sell/snipe, your wallet opens a signature request that includes instructions and fees (lamports). In code, look for primitives like sendTransaction, TransactionInstruction, or VersionedTransaction.
• Publicly Verifiable Transactions. After signing, the product shows a transaction signature (hash) so you can click through to Solscan or Solana Explorer.
• Program/DEX Interactions. Trades on Solana route through protocols like Jupiter (aggregator), Raydium, Orca, Serum. Real bots leave a paper trail of program IDs and DEX activity.
• Token Accounts & Balances (ATA). When you acquire a token, your wallet’s associated token account reflects the new balance; the UI should be a mirror of wallet reality, not a separate ledger.

Keep those five pillars in mind. They’re the difference between blockchain trading and a website that simulates balances.

Forensic Product Audit

Wallet Connection: Absent

• There is no “Connect Wallet” button and no adapter UX (Phantom/Solflare/Backpack).
• At the code level, there are no references to the Solana wallet surface (window.solana) or wallet/tx primitives (sendTransaction, TransactionInstruction, VersionedTransaction).
• You log in and fund an internal account; the page shows “Wallet Balance: ₱0.00” by default—this is an in-platform ledger, not your Solana wallet.

Why this matters: Without wallet connect, the app cannot request signatures or touch your on-chain assets. Whatever “trading” it claims to do, it is not being done by you, under your custody, on your wallet.

On-Chain Prompts & Explorer Proof: Absent

• The UI provides an amount input (with a minimum like “min ₱100”) and a “Create Trading Bot” button that can be disabled purely based on your numeric input.
• There is no wallet pop-up for signing a transaction, no instruction preview, no fee breakdown—nothing you’d see on any real Solana interaction.
• There are no transaction hashes or explorer links surfaced to the user after any action.

Why this matters: Without a signature request and a public tx hash, there is no on-chain audit trail. The app can claim “trades,” but users have no verifiable record.

Program/DEX Activity: Absent

• A product calling itself a DEX sniping bot should reveal protocol touchpoints: Jupiter routes, Raydium/Orca/Serum program IDs, pool addresses, or at minimum DEX brand mentions in the UI or code.
• The materials you provided do not contain such markers. There’s no sign of aggregator routing, liquidity pool discovery, or program instruction assembly.

Why this matters: Without DEX interactions, sniping is a branding claim, not a function.

Where the Money Actually Flows: Centralized Server APIs

All monetary operations—deposit, withdraw, wallet, dashboard, transactions, investment, subscription, referral commissions—are implemented as HTTP calls to /api/... endpoints. Representative examples include:

/api/wallet/deposit
/api/wallet/withdraw
/api/wallet
/api/transactions
/api/investment
/api/subscription
/api/subscription/active
/api/referrals/commissions
/api/dashboard

And the user profile payload clearly models an internal wallet with database-backed balance and transaction list:

"wallet": { "balance": "0.00" },
"transactions": []

Why this matters: This is custodial and off-chain. You are crediting a balance on a database, not moving funds on Solana. The operator controls the ledger and can mint or revoke balances at will.

Deposits: Off-Chain, With Screenshot “Proof”

The deposit flow is telling:

• The front-end features a code path that captures a screenshot of your payment proof (e.g., via a toDataURL("image/jpeg", 0.8) pattern) and uploads it to the server through an endpoint such as:

POST /api/deposit-request

• Payment settings parse raw addresses (e.g., TRC20:..., Solana:...) to display send-to instructions, consistent with manual transfers, not wallet-connected on-chain flows.
• There are no regulated fiat gateways (e.g., Stripe/PayPal), and more importantly, no on-chain tx hash is used as “proof.” The “proof” is literally an image.

Why this matters: In Web3, your signature + the resulting hash is the proof. Screenshots are not proof; they’re support attachments in centralized systems. A genuine Solana app would never ask you to upload a payment receipt image to get credited.

UI Shell Behavior: The “Bot” as a Container

• The Create Bot card is a marketing shell with a disabled button until a minimum amount is entered.
• The “My Bots” area is a tabpanel container that toggles visibility and shows placeholders such as “Loading your bots…” and “Active Bots (…)” only after the server returns data.
• There is no on-chain session state—no positions, no signed instructions, no live route/price/AMM logs—just UI states bound to server responses.

Why this matters: The “bot” is a page section that reflects database state, not a live, on-chain trading process.

Earnings Model

Fixed Daily ROI in the Interface

The interface explicitly promotes fixed daily returns (e.g., “Fixed daily returns on your investment,” “Daily Profit” displayed as 2% in the captured DOM). Elsewhere in the UI text, you’ll find lines like “Up to 2%/3% daily profit potential.”

Why this matters: Fixed daily ROI does not exist in real, market-risk trading. Markets are variable. Any “bot” promising fixed daily yields is not describing normal trading—this is the hallmark of a HYIP (high-yield investment program) structure.

Referral Earnings: “Earn 1% Daily From Referrals”

The interface promotes a 1% daily referral commission and exposes a dedicated API to fetch referral commissions:

GET /api/referrals/commissions

Why this matters: A daily, percent-based referral payout tied to “investment balances” is a strong indicator of a pyramid/Ponzi dynamic, especially in the absence of real on-chain PnL to fund it. Legit affiliate programs pay from real product/service revenue or fees, not from new deposits.

Transparency & Branding

• Author metadata and presentation are generic. There are no linked audits, no protocol IDs, no public code, and no demonstration of on-chain trades.
• The base page even includes a development-preview banner script from a well-known cloud IDE—its message, in plain language, says this is a temporary development preview “not for public use.”

Why this matters: Money-handling software should not present itself to the public on a dev-preview rail. For a tool that expects deposits, this is a red flag about release maturity and operational discipline.

Consistency Check: Claims vs. Behavior

Let’s compare Orbion’s claims with its observable behavior:

The discrepancy is not subtle. The entire money model is centralized and API-driven, while the entire Web3 layer (connect, sign, verify) is missing.

Security & Custody Implications

• Custody Risk. Funds reside in a platform-controlled wallet (a database number) until the operator chooses to honor a withdrawal API call. You do not hold the keys; you do not sign transfers.
• No On-Chain Rights. Because there are no signatures, you have no transaction-level rights. If balances are modified or withdrawals stall, there is no explorer trail to support your claim.
• Manual Proof Flow. The deposit “proof” is a screenshot posted to an API endpoint. This invites disputes and arbitrary crediting logic—again, a custodial pattern where the operator is the judge.
• Release Discipline. A dev-preview banner embedded in the main page indicates that the build pipeline is not production-grade.

What This Really Is

Taking all of the above together:

• The “DEX sniping bot for Solana” branding is not supported by a wallet connect, on-chain signatures, explorer hashes, or DEX/program interactions.
• The UI is a front-end shell: amount input, disabled button logic, a “My Bots” container that shows placeholder text and fills from server data.
• The funds model is custodial, with a database “wallet”, API-driven deposit/withdraw, and a screenshot-based deposit proof mechanism.
• The earnings model revolves around fixed daily returns and daily referral payouts—classic HYIP composition.
• The operational posture (development preview script on the main page) does not align with a product that should be handling public deposits.

Classification:
This fits a centralized HYIP/Ponzi-style investment scheme with a sniping/trading bot veneer. It is not a Solana-native trading/sniping product. It operates off-chain, under operator custody, and simulates yield via server-side balances and referral overlays.

How to Self-Verify in Minutes (Optional, For Readers)

If you’re technically inclined, you can replicate the core findings without any special tools:

1. Open the site and look for a “Connect Wallet” button (Phantom/Solflare/etc.). You won’t find one.
2. Click any action that claims to trade/snipe/buy/sell. Your wallet should ask for a signature. It won’t.
3. Open DevTools → Network, perform a “deposit,” and note the requests. You’ll see /api/wallet/deposit and a /api/deposit-request upload with an image/screenshot.
4. Ask for a tx hash. There isn’t one presented—because no transaction was signed.
5. Look for DEX routes. You won’t find Jupiter/Raydium/Orca/Serum program traces.
6. Try withdrawing. It’s an API request, not a signed transaction from your wallet.

Final Analysis & Recommendation

My analysis, constrained to the artifacts you provided, is unequivocal:

• Orbion is not a Solana DEX sniping bot in any meaningful, on-chain sense.
• Its core mechanics—funding, “profit,” referral payouts—are off-chain, driven by a centralized database via HTTP APIs.
• The product’s promises (fixed daily ROI, 1% daily referral) and deposit proof flow (screenshot upload) are canonical HYIP signals.
• The absence of wallet connect, signature prompts, transaction hashes, and DEX interaction removes any remaining doubt.

Classification: High-risk HYIP / Ponzi-style scheme masked as a “Solana trading/sniping bot.”

Recommendation: Do not treat this as a Web3 product; do not deposit funds you cannot afford to lose; do not promote it as an on-chain trading tool.

If you are assessing platforms in this space, use the five-pillar baseline (wallet connect, signatures, hashes, DEX interactions, wallet balances) to screen for authenticity.

Closing Thought

Healthy skepticism isn’t cynicism—it’s due diligence. If a “bot” can’t connect to your wallet, can’t ask for a signature, can’t show a tx hash, and can’t name the DEX routes it uses, it’s not a blockchain trading tool. It’s a website that moves numbers in a database.