

Jackson 🔶️ Pitboy
79 posts

@JacksonPitBoy
Who am i ?= Only Dev Pitboy Building on BnbChain since 2019






Response to @VeilLabsApp LLC's Security Update An EvidenceBased CounterAnalysis Veil Labs has issued a Security Update in response to our independent security audit. While we appreciate their engagement, several critical points remain unaddressed and certain claims require factual correction. Let’s examine the evidence. ON THE CORPORATE ADDRESS Veil Labs LLC was registered on April 7, 2026, just 11 days ago, at 30 N Gould St Ste R, Sheridan, WY 82801. This is not a physical office. This address is one of the most documented shell company hubs in the United States. According to Wyoming News, approximately 266,000 companies were registered at this single address between 2019 and 2024, representing more than 40% of all new business formations in Wyoming during that period. The ICIJ Pandora Papers investigation revealed that companies registered at this storefront address were involved in six federal criminal cases regarding COVID relief fraud and hundreds of them received tens of millions of dollars in PPP loans. ICIJ Pandora Papers: icij.org/investigations… Reuters: ksl.com/article/508163… Wyoming News: wyomingnews.com/news/local_new… This is an address most frequently used by all Indian scam companies. A Reuters investigation revealed that this address was used by a Russian entrepreneur to set up shell companies to make web traffic appear American. The FBI dissolved three LLCs registered at this address, 30 N Gould St Ste R, as tools of North Korea: Culture Box LLC, Next Nets LLC, and Blackish Tech LLC. The Sheridan County Chamber of Commerce reports receiving about five calls a week from victims trying to recover money from companies registered at 30 N Gould St. Local police confirm there are no regulations requiring registered agents to verify business legitimacy and victims have no recourse. We are not claiming that Veil Labs is committing fraud. We are pointing out that choosing this address, America's most notorious shell company hub, and marketing an enterprise grade privacy protocol raises serious questions regarding transparency and intent. REGARDING SIMPLESWAP ||| THE UNANSWERED QUESTION In all their responses, Veil Labs uses phrases like external liquidity partners, multi source routing systems, and cross domain execution layers. They never mention SimpleSwap by name. This is the fundamental issue they are avoiding. The evidence is in their own codebase. A commit message in the Privsol repositories reads: feat Next.js, SimpleSwap integration and Supabase refcode tracking. Their technical documentation, written in Indonesian, explicitly states: Integrasi partner library utilitas mis simpleswap.ts untuk memanggil API pihak ketiga. The source code contains a file named simpleswap.ts covering every SimpleSwap API endpoint: get_all_currencies, get_min_amount, get_estimated, create_exchange, and get_exchange. Every swap processed through Veil Labs is an API call to SimpleSwap. The TEYNO-xxxxx reference codes stored in Supabase are affiliate tracking identifiers. When Veil Labs claims multi hop routing at the execution layer, they are describing SimpleSwap's internal routing. When they claim dynamically generated execution paths, they are describing SimpleSwap's pathfinding algorithm. Veil Labs adds no additional routing, no additional privacy layer, or additional security. It is an affiliate front end with custom branding. The fundamental question is: Why is a SimpleSwap affiliate wrapper being marketed as a hybrid routing protocol designed to bypass cluster analysis? ON THE EXPERIMENTAL MODULE DEFENSE Veil Labs admits that the private key handling code was inadvertently included in the SDK but claims it was experimental and never used in production. There are problems with this defense. The SDK is the production interface used by developers and integrators to interact with Veil Labs services. Code in the SDK is, by definition, production code. Whether the proxy_transfer function was actively called is secondary to the fact that it existed in distributed code and accepted private keys as parameters with insufficient validation. Their statements claiming we do not solicit, store, or require user private keys contradict the SDK code itself, which contains functions designed to receive and process private keys. The intent may have been experimental, but the exposure was real. There is nothing inherently wrong with an Indonesian developer setting up a company in Wyoming. However, the combination of an 11 day old shell company, a notorious virtual address, anonymous branding, and marketing claims that contradict technical implementation creates a pattern that users deserve to understand. Veil Labs' response confirms some findings, such as the disclosure of SDK code and the lack of a formal audit, while ignoring the core issue of SimpleSwap dependency. Their use of vague terminology like external liquidity partners and the failure to name SimpleSwap directly suggests an intentional effort to create confusion. Users considering Veil Labs should understand that their funds are processed through SimpleSwap's infrastructure, their transactions are logged by SimpleSwap's systems, and the privacy protocol consists of a front end wrapper around an existing centralized exchange service. This is not inherently dangerous as SimpleSwap is a legitimate service, but it is fundamentally different from what the marketing suggests. The Fact: SimpleSwap already does its own routing. Veil Labs simply makes an API call. Furthermore, they market this as privacy. The Actual Code Flow👇 User requests a swap. Veil Labs → SimpleSwap API call. SimpleSwap executes the transaction. Veil Labs receives an affiliate commission. Summary Veil Labs' response is half admission, half silence. ✅ They admitted the SDK issue. ❌ They hid that they are a SimpleSwap wrapper. ❌ They did not explain the shell company structure. ❌ They did not address the ZK proof claim at all. Corporate structure, technical implementation, and marketing claims must align. Currently, they do not. We are always ready for technical discussions. Furthermore, we are not the ones saying these things. These reviews are conducted on public resources and public code. In other words, it is already there. It is in your code and what you have written.























