Switch — Full-Operation Review (Aggregator + SwitchX CL Protocol)🔗

Status: REVIEW BRIEF — informational; one architectural risk surface flagged on the new SwitchX deployment, no confirmed critical findings team-wide Targets:

• switch.win · beta.switch.win — DEX aggregator / routing engine
• switchx.fi · app.switchx.fi — newly-launched concentrated-liquidity protocol with ve(3,3) governance (added 2026-05-14)

Notable: Switch's routing engine also powers 0xCurv. SwitchX is the same team's new on-protocol product. Together they make Switch one of the broadest-surfaced PulseChain DeFi operators.

Published: 2026-04-26 · Last updated: 2026-05-14 (SwitchX added)

Why this review exists🔗

Switch began as a complex multi-hop router (balancer pools, limit orders, OTC offers) and is the routing engine behind 0xCurv — so a Switch-side defect propagates to at least one downstream aggregator. With the 2026-05 launch of SwitchX, the same team has now also shipped a full Uniswap-V3-class concentrated-liquidity protocol with ve(3,3) governance, automated liquidity vaults, server-signed off-chain fee quotes, and a custom MEV recapture mechanism. The trust surface that previously routed user funds through Switch now also holds them (in CL positions, in vaults, in vote-locked SWITCH). We want both pieces explicitly documented.

Methodology🔗

Public-source review only. We surveyed the public switch.win site, the beta front-end, the switchx.fi marketing page, the app.switchx.fi SPA bundle, and cross-checked routing contract paths through PulseChain block explorers. We compared the addresses called by app.0xcurv.win/swap against those called by beta.switch.win to confirm the "powered by" disclosure. For SwitchX we inspected the static JS bundle (155KB) to enumerate runtime endpoints — contract addresses are not embedded statically, the app loads them at runtime. No code execution. No source-level review of SwitchX contracts (deployment registry not yet public at time of writing).

Part 1 — Switch.win Aggregator🔗

Hypothesis status (aggregator)🔗

What we did NOT find (aggregator)🔗

• No reports of exploit, drain, or pause
• No on-chain evidence of operator self-trade
• No mixed-content scripts on the public swap page

Outstanding work (aggregator)🔗

• Audit the limit-order / OTC settlement contracts: signature scheme, replay protection, expiry semantics.
• Document the canonical Switch routing-contract address publicly and pin it on the project site so users have a single source of truth.

Canonical routing-contract anchoring (rev 1, 2026-04-27)🔗

Switch on PulseChain currently routes through one or more contracts whose canonical address has been changing over time as the project ships new features. The advisory's rev-0 cited the address inline but didn't anchor a "canonical address" field in the case JSON, which means downstream advisories that reference Switch (notably aggregate and 0xCurv) had to maintain their own copy. We have since:

1. Resolved the current canonical Switch routing contract on PulseChain (persisted to source_refs for case-JSON canonical-anchoring purposes).
2. Ascertained the deployer's EOA — the same EOA that has been building Switch since launch — and persisted it in source_refs as type addr for stable lookup.
3. Wired a getCode + owner() snapshot into the daily cron so any router-rotation is detected within a day. Same model as Liberty Swap.
4. Documented the observed-rotation cadence so the user-facing advisory body can convert "they rotate frequently" (vague) to "address rotates roughly every N weeks" (specific).

Why this is high-leverage despite LOW severity: address rotation is the single most common drainer-impersonation vector for small-DEX users. Users find the canonical address from a cached Telegram message, paste it in, and route through what they believe is Switch but is actually a fake-Switch deployment. Anchoring the canonical address in our case JSON (and surfacing it on swap.wick.pics in the per-DEX info panel) is the cheapest defence.

Cross-references kept synchronous: aggregate and empseal both reference Switch. They pull the canonical address from this case JSON's source_refs rather than embedding inline, so a rotation event updates everywhere atomically.

Aggregator verdict🔗

Low risk at the front-end level. The structural caveat is that Switch is a routing-layer dependency for at least one downstream aggregator — a defect here propagates. Users routing trades through switch.win carry a normal aggregator risk profile; users routing through 0xCurv carry this risk plus their own wrapper risk.

Part 2 — SwitchX (concentrated-liquidity protocol, launched 2026-05)🔗

What SwitchX is, publicly🔗

From switchx.fi, the app at app.switchx.fi, and — added 2026-05-14 to this advisory — the publicly published SwitchX-Whitepaper repo (org: BuildTheTech, "Build The Technology"), the architecture is:

• Concentrated liquidity, Algebra-V4-class engine. The core layer is V4Pool / V4Factory / V4PoolDeployer / V4CommunityVault with a plugin hook system at beforeInitialize / afterInitialize / beforeModifyPosition / afterModifyPosition / beforeSwap / afterSwap / beforeFlash / afterFlash / handlePluginFee. This is the Algebra V4 plugin pattern (Camelot V3 family), not raw Uniswap V3.
• SwitchXBasePlugin is the default plugin on permissionless public pools — composes adaptive fees, MEV protection, cross-DEX toxicity pricing, optional signed fee quotes, oracle tracking, farming integration, ALM rebalancing, and MEV backrun execution.
• Adaptive fees — three plugins: DynamicFee (volatility), BackrunFee (same-block sandwich detection), ToxicityFeeV2 (cross-DEX LVR via oracle). Same-block MEV surcharge is active at launch.
• MEV recapture is on-chain, plugin-based. MevBackrunPlugin runs in the afterSwap hook; a permissioned mevExecutor address (off-chain keeper) submits the backrun via the plugin. Profits route to ve(3,3) voters + treasury via DripVotingReward. Self-funded mode (selfFundedEnabled) ships dark; until activated the executor flash-borrows.
• ALM vaults — ALMVault ERC20 + HybridRebalanceManager + ALMKeeper. TWAP-driven rebalancing with volatility-adaptive ranges. Donation-inflation is explicitly hardened (MIN_SHARES = 1e6, deposits that round to 0 shares revert, launch scripts pre-seed empty vaults).
• ve(3,3) governance with finite emissions. VotingEscrow, Voter, Minter, Gauges, Rewards, ProtocolFeeManager. Hard cap of 1 billion SWITCH tokens, 2.5-year emission schedule (then zero forever). 50% of trading fees are auto-converted to SWITCH on the open market as a perpetual buyback. Burn locks at 2x voting multiplier. Automatic farming-reward locking into veNFTs.
• Server-signed fee quote lane. /api/signed-fee-quote is a Vercel Node endpoint that produces an EIP-712 signed payload binding pool, router, recipient, callback payer, direction, amount, price limit, fee, nonce, AND deadline. This is a precision tool for first-party routed flow only — it requires an explicit feature flag, short deadlines, single-hop only, per-token raw-amount caps, and the on-chain verifier is in the plugin path. Until production-enabled, the unsigned Toxicity public lane handles corrective flow by swap shape, not user identity.

Audits (both publicly published — important caveats below):

• SpyWolf (1.3MB, audits/switchx-audit-report-spywolf.pdf) — Core + Periphery review. Findings: 3 Medium (oracle staleness in vault rebalances, fee-on-transfer multi-hop slippage bypass, multicall partial-commit risk), 2 Low (plugin misconfiguration, liquidity rounding). Final statement: all Medium and Low findings remediated before re-audit close. SpyWolf is primarily a KYC + small-audit firm — strong on contract code-quality checks, less specialised on novel AMM math.
• 33Audits (10MB, 26 pages, dated 2025-12-20; audits/switchx-audit-report-33audits.pdf) — deep technical review focused on plugin lifecycle + fee-accounting edge cases. Visible scope (from text-extraction; the PDF uses styled headers + tabular layouts so severity tags don't extract cleanly): plugin replacement during pending-fee states, community-vault unset / address(0) edge cases, V4VaultFactoryStub analysis, NonfungiblePositionManager.collect() recipient handling, _cleanPositions flow, fee-transfer timestamp accounting (lastFeeTransferTimestamp vs block.timestamp), uint104.max bit-packing overflow on pending fees, missing event emissions on community fee transfer, CUSTOM_POOL_DEPLOYER cross-deployer pool creation. Readers should pull and read the PDF themselves — our text extraction can't reliably surface 33Audits' specific severity tags or remediation status.

Honest read on the audit firms (this matters):

Neither SpyWolf nor 33Audits is a Tier-1 audit firm. Tier-1 in 2026 = Trail of Bits, OpenZeppelin, Spearbit, Cantina, ConsenSys Diligence, Sigma Prime, plus the top contest platforms (Code4rena, Sherlock, Cantina contests). 33Audits is a small-to-mid-tier firm founded ~2025-03 (about 14 months old at audit date); their public team signal connects to leeftk, a known Code4rena warden, which suggests real audit chops behind the brand. SpyWolf is a smaller firm with a heavier KYC-launchpad focus. Both produced substantive work — 33Audits in particular did deep technical analysis on the plugin/fee subsystem that's the most novel SwitchX-specific surface. But "two audits passed" should not be read as "Trail-of-Bits-and-Spearbit double-clean." For a protocol this architecturally ambitious — Algebra-V4 fork + ve(3,3) + custom MEV recapture + ALM vaults + signed-fee-quotes — a true Tier-1 review (or a Code4rena contest) would add real coverage on top of what's been done. That gap is part of the residual-risk surface.

Tech-stack & operational disclosure (recovered from the public Vite build):

• Frontend: Vite + React + reown (WalletConnect) project 020552830f7e141ce2e9e0e066893002
• Deployed on Vercel, project prj_LiuqgmwJgGdVWVDAGGin4w2FAX0w, branch pulsechain-ve33
• Repo BuildTheTech/SwitchX-Frontend is private; BuildTheTech/SwitchX-Contracts does not exist publicly — on-chain code is closed-source as of advisory date
• Public SDKs: Switch-SDK and Switch-Operators-SDK ship the aggregator ABIs (SwitchRouterABI.json, SwitchLimitOrderABI.json); the new SwitchX V4Pool / Plugin ABIs are NOT in the public SDK as of 2026-05-14
• Plugin developer SDK: @switchx/abstract-plugin is documented for third-party plugin authors (docs/plugin-developer-guide.md)
• Git author on the production commit: Datakunskap (GitHub user, 21 public repos)
• Vercel team scope: avantgarde-62446367

Residual risk surface — what remains material despite the audits🔗

The two completed audits + hardening described in the whitepaper close most of the obvious bug classes (donation-inflation, oracle TWAP, signed-quote field binding, reentrancy). The risks that do remain are mostly operational and role-key, not contract-bug-class — and that profile is normal for a freshly-launched protocol.

1. Phase-1 deployer-key risk (explicitly acknowledged by team)🔗

Whitepaper §12.7: "At launch, the deployer address holds admin keys for operational agility during the bootstrapping phase." Phase 2 transfers ownership of VotingEscrow, Voter, Minter, ProtocolFeeManager, ALM vaults, and the SWITCH token's setMinter to SwitchXTimelock. Phase 3 transitions timelock roles to a community multisig.

Until Phase 2 completes, deployer-key compromise = malicious upgrade of any upgradeable contract. The team has the timelock contract ready to deploy from day one. Time-window of acute risk is whatever Phase 1 lasts.

Watch: when SwitchX-Timelock is set as owner across the upgradeable contracts. Until then, treat large positions as exposed to upgrade risk.

2. mevExecutor key compromise🔗

The MEV backrun executor is a permissioned address that gets:

• Sentinel overrideFee=1 (zero swap fee) on the SwitchX side
• Bypass on the BackrunFee plugin and the cross-DEX oracle (Toxicity V2) plugin
• Direct route through _isMevInternalSwap to pay zero fees

A compromise of the mevExecutor private key allows the attacker to swap fee-free through SwitchX pools indefinitely. If self-funded mode is later enabled and the executor holds capital, that capital also becomes drainable. The role is trustedInternalExecutors plural — likely a small set with operator rotation.

Watch: which address holds mevExecutor (key custody), how often it rotates, whether self-funded mode activates, what dollar-size of token balances the executor holds when self-funded.

3. Signed-fee-quote signing-server compromise🔗

The whitepaper confirms the EIP-712 payload binds pool / router / recipient / callback payer / direction / amount / price limit / fee / nonce / deadline — this is more comprehensive than 0x v4 / Sushi RP2 precedent classes. Field-binding is not the residual risk; signing-key custody is.

Specifically: the /api/signed-fee-quote Vercel Node function holds the private signing key. The whitepaper notes "production posture is to enable this lane … once the signer SLA, key-rotation runbook, frontend configuration, WAF/BotID controls, on-chain allowlists, and fork proof are ready." Until production is live, the lane is dark. Once live, signing-key compromise allows minting valid quotes for any first-party-routed swap — economic damage bounded by the on-chain per-token raw amount caps mentioned in the whitepaper but not yet enumerated publicly.

Watch: activation of signedFeeEnabled (frontend) + the signer address on-chain in the allowlist; the per-token raw-amount caps once published.

4. Plugin system as a third-party attack surface🔗

@switchx/abstract-plugin is published as a developer-facing SDK with base contracts, an upgradeable variant, and example contracts (see docs/plugin-developer-guide.md in the whitepaper repo). The plugin model is permissionless: third parties can build and deploy plugins that attach to pools via setPlugin. Whitepaper §12.2 confirms launch posture removes the old SecurityPlugin kill-switch from the default factory path, so by default new public pools inherit SwitchXBasePluginFactory only.

The risk class: a third-party-built plugin that has a bug + is attached to a pool by mistake or by a curated-pool admin → users routed through that pool inherit the bug. This is Uniswap-V4-Hooks-class risk; the only completed-precedent for production hook exploitation is the Cetus disputed-issue (2024), but the attack surface is novel and not yet stress-tested in the wild.

Watch: what plugins get attached to which pools, who attaches them, whether any non-SwitchXBasePlugin plugin gets the defaultPluginFactory slot.

5. SpyWolf-flagged residual concerns🔗

Per the SpyWolf audit's §8.8 Systemic Risk Assessment, three Medium findings were called out and the audit's Final Statement says they were remediated. The categories worth tracking post-launch:

• Oracle staleness — vault rebalance using stale TWAP under quiet markets. Mitigation: minObservationWindow, maxStaleness checks.
• Fee-on-transfer multi-hop — slippage bypass through FoT tokens. Mitigation: balance-delta verification.
• Multicall partial-commit — non-atomic batches. Mitigation: full-revert on any sub-call failure.

A remediation is a checkpoint, not a guarantee. Post-launch behavior under real-world flow is what tells you whether the remediations held. Worth a periodic re-scan once a few months of mainnet history exist.

6. SwitchX-Frontend repo is private; supply chain unobservable🔗

The BuildTheTech/SwitchX-Contracts repo does not exist publicly (404), and the SwitchX-Frontend repo is private. We can't audit the GitHub Actions, the npm dependency tree, or the deploy pipeline that builds the production Vercel bundle. The whitepaper + SpyWolf cover the contract attack surface; the front-end build pipeline attack surface (Badger 2021 / Curve DNS 2022 class) is opaque to outside review. Once the on-chain code is open-sourced, this category drops in severity.

Watch: announced source-availability changes; any DNS or app-domain anomalies; the integrity of app.switchx.fi over time (page-hash monitoring).

7. PulseChain dependency🔗

Whitepaper §12.8 explicitly notes "validator concentration, network congestion, RPC availability, and bridge security for assets bridged from other chains" as systemic dependencies. These are not SwitchX's bugs — they're chain risks SwitchX inherits. Our prior PulseChain base-layer advisory at /greenteam#pulsechain covers them in detail. SwitchX takes one specific second-order hit: MEV recapture profitability assumes "sufficient liquidity depth on both SwitchX and PulseX" — if the PulseX side of the arb venue dries up, the recapture engine starves.

SwitchX — what users should watch for today🔗

For users considering SwitchX positions in the first 30–60 days:

1. Treat any "no slippage" or "guaranteed fee" prompt from the app with suspicion. Adaptive-fee + signed-quote protocols normalise a UX where the user trusts a server-signed number. Verify in the wallet's tx-simulation tool that the on-chain minAmountOut matches what the UI told you.
2. Watch for an unusually quiet first 7 days. Quiet means the contracts are still in a low-attention window. The riskiest period for a freshly-launched concentrated-liquidity protocol is after the first day's MEV-bot detection lag clears but before coverage from professional audit firms starts. That window is typically days 3–21.
3. Size automated-vault positions to "I could lose this and shrug." Auto-rebalancing vaults compound their own exposure: one bad rebalance during low liquidity can lock in losses that would have been small on a manual position.
4. If you see SWITCH-related token distributions (airdrops, retroactive grants) prompt your wallet to call a function you don't recognise — a function whose selector you can't decode on a block explorer — stop. The fresh-protocol airdrop UX is a recurring vector for malicious-approval phishing (Badger pattern).
5. If the protocol depends on its own front-end for anything load-bearing (e.g. you can only construct a swap via the signed-quote endpoint), then a front-end compromise is a fund-loss path. Self-custody users should check whether direct-contract calls are supported.

What's NOT in either audit's scope🔗

Both SpyWolf and 33Audits are contract-only reviews of the SwitchX Core, Periphery, ALM Vault, and Plugin subsystems. That's a meaningful scope — but it's not the whole protocol attack surface. The categories below are outside what either audit covered and therefore deserve independent attention.

1. Off-chain infrastructure (entirely out of scope)🔗

The /api/signed-fee-quote endpoint runs as a Vercel Node function. The off-chain MEV arbitrage keeper that drives the mevExecutor runs as an off-chain bot. Neither audit reviewed:

• Signing-key custody and rotation for the EIP-712 fee-quote signer
• The Vercel build pipeline + environment-variable management for the signer host
• GitHub Actions secrets in the (private) SwitchX-Frontend and BuildTheTech/SwitchX-Contracts repos
• WAF / BotID / rate-limiting on the signer endpoint
• The off-chain keeper's opportunity-selection logic (the audits looked at the on-chain MevBackrunPlugin; not the off-chain bot that decides when to trigger it)
• npm dependency tree for the front-end
• DNS integrity for app.switchx.fi and www.switchx.fi

Historic precedents for this entire class: Badger 2021 ($120M, frontend approval injection), Curve DNS hijack 2022, KyberSwap frontend incidents. These attacks don't need a contract bug; they need a single compromised CI secret or a single npm-supply-chain incident.

2. Economic / tokenomics-level attacks🔗

Audits review code; economic mechanism-design analysis is a separate discipline that neither firm advertised in their report scope.

• Late-epoch finite-emission concentration. Whitepaper §6 makes the case for hard supply cap + 2.5-year emission terminus. When emissions approach zero, the strategic value of marginal voting power concentrates into a small set of decisive epochs. A coalition strategy: accumulate veSWITCH cheaply in low-attention epochs, then dominate when remaining-emission decisions cluster.
• 2x burn-lock dynamics. Permanent-non-decaying-voting-power-at-2x is a one-way valve. Holders who burn early get permanent governance power on emissions that haven't yet been minted. Late-arriving capital is structurally disadvantaged. This is by design — but it means the governance equilibrium is determined by who burned in the first few months, not by who holds liquidity later.
• 50% auto-buyback feedback loop in low-liquidity periods. When PulseX SWITCH liquidity is thin (e.g. during quiet markets), the 50% fee-to-buyback creates structural buy pressure on shallow books — gameable by anyone who can predict the buyback timing. Whitepaper doesn't disclose buyback execution randomisation.
• Auto-locking farming rewards. A configurable percentage of farming rewards lock into veNFTs at maximum duration. Concentration risk: which addresses accumulate auto-locked positions at what rate? This concentrates governance into the most active farmers.
• DripVotingReward 52-period catch-up cap. Documented as DoS protection. The corollary: a reward stream that goes 52+ periods without a catchUp call loses the older periods' rewards entirely. Edge cases worth manual stress-testing.

3. Cross-protocol composability (single-protocol audits don't cover)🔗

• SwitchX ↔ PulseX coupling. Whitepaper §10 details MEV recapture against PulseX V1/V2 + StableSwap. Neither audit covered: behavior when PulseX is paused, when PulseX V2 has shallow liquidity for a long-tail pair, or when the StableSwap depegs.
• Oracle composition into downstream protocols. If Phiat, Liquid Loans, or any PulseChain lending market eventually uses SwitchX as a price source, sustained multi-block manipulation of a SwitchX pool propagates. SwitchX's own TWAP guards protect SwitchX; they don't protect downstream consumers.
• Bridge-token + LST oracle composition. Bridged WETH, bridged stables, and any liquid-staking tokens have their own pricing assumptions. A SwitchX pool whose quote token is a thin-liquidity bridged variant of a major asset can have its own oracle skewed without the bridge being broken.

4. MEV recapture as an attack surface🔗

Both audits looked at the MevBackrunPlugin code. Neither analysed the system it operates in:

• Race condition between mevExecutor and external searchers. The internal-swap detection runs _isMevInternalSwap on msg.sender. If an external searcher can call the backrun ladder before the mevExecutor in the same block, they extract the value SwitchX intended to recapture. Audits typically don't model this since it's a same-block adversarial timing question, not a code bug.
• Self-funded mode capital exposure. Once selfFundedEnabled = true, the executor holds token balances. The mevExecutor address becomes a hot wallet. The audits didn't review what happens when this key is compromised because the feature ships dark.
• Bounded-ladder gameability. The whitepaper notes the keeper "halves through a small bounded ladder if the larger attempt cannot clear repayment/profitability". An attacker who knows the ladder construction can craft swaps whose own MEV is just above the keeper's smallest-rung profitability, ensuring the keeper takes none of it.
• v4FlashBorrowEnabled kill-switch. Default-enabled at launch. If a contract bug elsewhere allows flash-loan-induced state manipulation, this is the lever.

5. Plugin replacement during in-flight operations🔗

33Audits looked carefully at plugin replacement during pending-fee state (good). Neither audit specifically modelled:

• Plugin replacement during an in-flight ALM rebalance (the rebalance reads plugin once, then makes follow-up calls — if the plugin is replaced between calls, behavior diverges)
• Plugin replacement during a multicall batch
• Plugin replacement when the new plugin has a different pluginConfig bitmap (some hooks now fire that weren't expected; or some hooks no longer fire that were)

6. Whitepaper-disclosed features NOT YET in audit scope🔗

Three production-darkable features explicitly mentioned in the whitepaper but flagged as not-yet-enabled at audit time:

• signedFeeEnabled — the production posture for /api/signed-fee-quote. The on-chain verifier is reviewed; the off-chain signer is not.
• selfFundedEnabled — MEV executor self-funding. Audits reviewed the contract path; the operational risk profile is separate.
• Fee Auction layer (pluginFee lane). Whitepaper §5.4 notes "Activation requires priority-fee telemetry … fresh fork proof, and rollback proof." Until activated, no audit coverage attaches to its production behavior.

When any of these three features flips to production, the audit coverage gap re-opens. A formal re-scoping with at least one of the original audit firms (or a Tier-1 firm) is the cheapest mitigation.

7. Sustained multi-block oracle manipulation🔗

Both audits address flash-loan-induced TWAP manipulation via minObservationWindow / maxStaleness enforcement. Neither addresses sustained multi-block manipulation — the attack class behind UwU Lend ($19.3M, 2024) and Mango Markets ($117M, 2022). On PulseChain, where some long-tail tokens have shallow liquidity on every venue, a patient attacker can drift an oracle over many blocks. The mitigation is venue diversification, not TWAP window tuning.

8. PulseChain-specific assumptions🔗

Most audit firms test on Ethereum-mainnet fork (12s blocks, mature MEV infrastructure, deep liquidity). PulseChain has different block times (~10s), different validator concentration, different MEV maturity, and a smaller searcher pool. Audits that don't explicitly recalibrate for these differences may miss:

• Timing attacks that don't work on Ethereum but work on PulseChain
• Same-block backrun economics that look profitable on paper but lose to network conditions
• Gas-price-priority sandwich windows that are narrower or wider than Ethereum

Neither audit publishes an "assumption recalibration" section confirming PulseChain-specific tests were done.

None of the above is a confirmed vulnerability. They are categories of risk that two contract-only audits cannot cover. The point of this section is to be honest about the limits of "audited" — even by competent firms.

Combined verdict🔗

Switch (aggregator side): low risk. Years of public operation, no exploit history, broad routing surface but standard non-custodial flow. Structural caveat that a Switch-side router defect propagates to 0xCurv.

SwitchX (CL protocol side): medium risk. What we found on the second pass is meaningfully better than the day-1 architectural picture suggested: two completed audits (SpyWolf cleared, 33Audits unread but published), comprehensive EIP-712 signed-quote field binding, on-chain plugin-based MEV recapture (not off-chain auction), explicit donation-inflation hardening on ALM vaults, three-phase decentralization roadmap. The residual surface is operational — Phase-1 deployer key, mevExecutor role custody, signing-server key custody once production-enabled, third-party-plugin attack surface, and supply-chain visibility into the (still-private) frontend repo. These are real risks but they're the normal risks of a fresh launch from a competent team, not architectural unknowns.

Operationally for the wick.pics stack: Switch.win remains a primary input to the PLS-AGG-ARB-V5 cross-aggregator scanner. SwitchX is not yet wired; once contract addresses are mapped (one observed swap on app.switchx.fi will yield them) we will add it as a fifth aggregator-input in arb scanning. SwitchX pools become eligible for LP-side participation once Phase-2 timelock transfer completes and is verified on-chain.

This page exists so people don't have to make architectural-risk judgements without context. It is not financial advice and it is not a claim of any confirmed vulnerability in either Switch.win or SwitchX as of today.

Document v0.3, last updated 2026-05-14 (deeper SwitchX research pass: whitepaper + SpyWolf audit summary + team / repo recon). Original aggregator advisory v0.1 published 2026-04-26. Reviewing analyst: Wick Red Team (33Audits PDF text-extraction + verified-source contract review still pending).