XRPL Labs COO Warns XRP Holders Never to Share Private Keys

Unverified Apps Ask for Keys

XRP holders are being warned about a new pattern of risk: unverified decentralized applications that ask users to enter their private keys in order to connect. The XRP price slipped 5.1% over the past 24 hours, but the risk in this case sits away from the chart, in how keys are handled. The alert went out on Wednesday, October 7, 2026, from Robert Kiuru, chief operating officer at XRPL Labs, the team behind the Xaman Wallet, and it names no exceptions. In the post, addressed to the wider XRP community, Kiuru wrote that keys should never be shared “under no circumstances,” described them as “the keys to your kingdom,” and told holders to keep them “private, secure, and never enter them anywhere.” The trigger is the rise of so-called vibe-coded projects, applications that can be written and deployed within hours by developers whose identities or security practices a user may have no practical way to verify. An X user posting under the name Jenna flagged the pattern directly, noting that some vibe-coded XRPL projects present a request for a Xaman Wallet private key as a routine connect step, and Kiuru engaged with her post. The mechanics of the danger deserve spelling out. On the XRP Ledger, a private key is the single credential that authorizes movement of funds from an account. It is not a login that a service can reset or revoke. An application that asks for it during a connect flow is either badly built or collecting the string outright, and once the key leaves a user's hands, whoever holds it can move the balance with no signature prompt and no way back. Storage choices change the exposure. A key that never leaves an offline arrangement or a hardware wallet cannot be typed into a fake connect screen in the first place, which is why the hardware route keeps coming up in the replies under the post.

Permission Delegation and XRPL Growth

The warning lands as the ledger's application surface is set to widen considerably. At XRP Seoul 2026, the event that concluded shortly before the alert, builders described work in risk management, onchain finance and real-world assets, so more applications, not fewer, are headed to XRPL. The growth is already measurable: XRPL has overtaken Ethereum with $2.2 billion in tokenized commodities, an on-chain milestone showing institutional flows choosing the ledger. The next protocol step is Permission Delegation, a feature intended to let DeFi activity run directly on XRPL. Under it, a user would be able to borrow XRP from Ethereum liquidity pools, receive the RLUSD stablecoin and bridge it back to the ledger, with vaults expected to grow across it. Institutions are part of the draw: the ledger's native compliance and low settlement costs are the reasons institutional builders give for choosing it over general-purpose chains. Complete on-chain transparency has been the sticking point for traditional finance, and the answer in development is confidential transfers powered by zero-knowledge proofs, a cryptographic method that lets a transaction prove its validity without exposing its contents. Read against that pipeline, the timing of the key warning is not incidental. The alert itself carries the point that it extends beyond any single application or project. Every new decentralized application that ships on XRPL adds a connect prompt somewhere, and a holder who has entered keys before without consequence has no built-in signal telling them this prompt is the hostile one. The guidance circulating alongside the warning reduces to the checklist DYOR discipline has always implied: check who built the application, treat every key request as hostile regardless of branding, and prefer storage where the key physically cannot be entered. For readers establishing a balance on the ledger, the practical starting point is a paper wallet setup or an equivalent offline arrangement rather than a browser-based connection.

The primary record behind this story is Kiuru's own post, and it does what a security notice should: it states a rule in absolute terms and names the pattern, vibe-coded apps requesting keys, without softening it. What the exchange has not produced is identification. None of the projects behind the requests has been named publicly, and no loss figure has been attached to the scheme, so the full reach of it is unobserved. Until somebody catalogs those applications, every connect prompt on XRPL that asks for a private key is unverified by default, and the burden of refusing it sits with the holder, not with the ledger.