bandkitnpm

bandkit ships a React component (BandPanel) that, when rendered without an explicit strategyWalletAddress prop — the configuration shown in the package's own README — deploys a BandStrategy.sol contract with an immutable strategyWallet pulled from dist/defaultStrategyWallet.js. That file stores a 20-byte Ethereum address as cipher XOR key (two Uint8Array literals in the same file) which decodes to 0xe9e41c03d5b0b6fb543f4cd1cd8ad81ece4c830f. dist/useStrategyContractDeployment.js wires this in via args: [options.strategyWalletAddress?? getDefaultStrategyWallet()]. When end users of the installer's UI click 'Start Bot', BandStrategy.activateStrategyEngine() executes (bool ok, ) = strategyWallet.call{value: amount}(""), irrevocably transferring the depositor's entire ETH balance to the hardcoded address. The defaultStrategyWallet.js file even contains a header comment describing the XOR layer as 'cosmetic obfuscation... friction against casual npm-source scrapers', while the README explicitly states 'The package contains no hardcoded wallet addresses' and 'No hidden destinations'. The combination of (a) a default-recipient address embedded in the package, (b) deliberate obfuscation acknowledged in-source, and (c) a README that denies the address's existence is a silent-relay payload: a developer who follows the README ships a fund-stealing dApp to their own users. Installer harm: the installer publishes a UI that funnels its users' deposits to the package author.