StaticBit.io

withdraw from a vault

We’re not waiting for the amendments to start building. Deposit to vault → see shares before signing Pay loan → schedule + full amount shown before confirmation All of this is already in StaticBit (DevNet). Mainnet just needs the green light from validators. #XRPL #lending #protocol #amendments

We are ready for lending protocol

StaticBit 2.6 is ready for XRPL vaults and the Lending Protocol. The Vaults, Loan Brokers and Loans screens are in the app. They show your positions, and before you sign you see what you receive and what you give. The SingleAssetVault and LendingProtocol amendments are not enabled on mainnet as of Nov 8, so the section is empty there for now. It works on DevNet. Also in 2.6: - Account import by private key: Add new wallet, Import account, Private key. It accepts 64 hex characters, or 66 with a 00 prefix (secp256k1) or ED prefix (ed25519). - Every Features card on the home screen opens: 20 ledger object types, including Checks, NFTs, Escrow, MPTs, Credentials, DIDs and Permissioned Domains. View only. - Max network fee in settings: a cap on the automatic fee, 0.01 XRP by default. If you back up a wallet added by private key, restore the backup on 2.6 or newer: version 2.5 does not read that key type. iOS: the update isn't available yet, we're working it out with Apple. Get it: Google Play play.google.com/store/apps/d… #StaticBit #XRPL #Ripple #XRPLCommunity

Links to metadata die 🪦 When an NFT, an MPT, a DID or a credential keeps its picture and description off the ledger, the ledger entry holds only a link. The file sits on IPFS, on the issuer’s own server or in an S3 bucket. Part of the projects on XRPL no longer maintain their storages, images and metadata nft live only with marketplaces who downloaded them and store them in their storages. 🪦🪦🪦

Backup in StaticBit: Settings, Security, Backup. Save it as a password-protected file or QR code, check it there, and keep a copy off this phone. No app at hand? The decoder on GitHub opens a backup: staticbit-io.github.io/walle…. You need the password you set when making it, and it can't be recovered. #StaticBit #XRPL

StaticBit 2.5 is out on Google Play Wallet secrets are encrypted with AES-256-GCM under two factors: a random secret in your platform's protected storage (Android Keystore, iOS Keychain) and your PIN. Neither alone opens the vault. StaticBit never receives your keys. Also in this release: - a backup you make yourself: a password-protected file or a QR code - the signing screen breaks a transaction into fields and shows every memo separately - Batch, DelegateSet, Vault, Credentials, DID and Permissioned Domains are read on the signing screen and in the activity feed - developer mode: server groups, TestNet and DevNet The app does not put your keys into your phone's automatic backup. If you lose your phone without a backup of your own, the wallets can't be recovered, not by you, not by us. We'll show how to make one tomorrow. iOS 🍏: the update isn't available yet, we're working it out with Apple. Get it: Google Play 🤖 play.google.com/store/apps/d… #StaticBit #XRPL #XRP

fixCleanup3_3_0 has held 82.86% support since Aug 28, targeting Sept 11 activation. Fixes a div-by-zero in AMMWithdraw and hybrid offers dropping off the permissioned-DEX order book. Third fixCleanup in a row, same six-week cadence. Looks like a fixed rhythm. #XRPL

a campaign is running on the XRP Ledger: a one-drop payment, a memo promising a 510 XRP check, a link. in a 200 ledger window that was 14% of all successful XRP payments, 480 addresses in 13 minutes. the check isn't real. a real one sits in your wallet. #XRPL

🪦 Ripple wants XLS-38 gone as dead code. We counted how much else on the XRP Ledger is just as empty. Method: 2,016 ledgers spread evenly across seven days, 307,229 transactions, every transaction type counted. All figures below are from that sample. The type distribution is misleading on its own: ▸ Checks rank third by volume — 24,034 transactions, 7.8% of all traffic. But CheckCreate comes from 15 accounts and CheckCancel from four. Cancellations outnumber cashings four to one (11,094 vs 2,558). Written checks mostly go uncollected. ▸ Escrow — 3,487 creations from three accounts, 3,668 cancellations from two, and exactly one EscrowFinish in the whole sample. ▸ Price Oracles (XLS-47) — 80 OracleSet transactions from four accounts. Vaults and the Lending Protocol, both in validator voting right now, depend on that layer. Zero across 307,229 transactions: not one PaymentChannelCreate, DIDSet, CredentialCreate or DepositPreauth. All four amendments are enabled on mainnet and have been for a long time. The genuinely distributed activity is NFTs: 244 accounts in NFTokenCreateOffer, 162 in NFTokenAcceptOffer. Plus CheckCash with 95 senders — checks do get cashed, just not by the accounts writing them. Caveat we'd rather state than bury: the sample covers 1.33% of the week, so "zero" means "not once in 307,229 transactions", not "never". It bounds the magnitude anyway. A primitive that misses all 2,016 samples is hard to call alive. Shipping a feature is the easy part. @Ripple @XRPLF #XRPL #XRP #Escrow #onchain

🌉 Ripple is asking the XRPL community to withdraw XLS-38 — the ledger's native cross-chain bridge amendment — along with fixXChainRewardRounding. David Fuelling (@sappenin) of @RippleXDev published the recommendation on 27 August. It is a recommendation, not a decision: Ripple holds one vote among many. Why now: ▸ The EVM Sidechain bridge is already served by @axelar — 75+ validators, threshold signatures, key rotation, 55+ chains connected. ▸ No demand for private sidechains materialised. The community had 12–15 months to bring concrete projects built on XLS-38. None arrived. ▸ Dead code is not free. Withdrawing the amendment removes more than 10,000 lines from xrpld — less surface to maintain, review and onboard new contributors into. We pulled the vote counts from the ledger this morning: XChainBridge sits at 5 of 35 validators against a threshold of 28. Its companion fixXChainRewardRounding is at 11 of 35. The amendment has been open for voting since rippled 2.0.0. How the withdrawal would work: 1. A pull request sets VoteBehavior::Obsolete for XChainBridge in xrpld. 2. Servers on that version automatically vote against it, regardless of operator config. 3. Once no active validator supports it, the code comes out. Nothing changes for XRPL EVM Sidechain users — Axelar remains the route to and from mainnet. A comment period is open: if you are building on XLS-38, RippleX wants to hear it on GitHub or the XRPL developer Discord. The line worth noting: this is unlikely to be the last withdrawal proposed. Lean protocol, on purpose. @Ripple @XRPLF #XRPL #XRP #XLS38 #Axelar

📖 We wrote the entire text of War and Peace into XRPL mainnet. All 3,339,794 bytes of it, split across 3,278 transactions, in 15.3 minutes. Then we read it back out of the ledger and compared it to the original. Byte-for-byte match, SHA-256 verified. 💰 IT COST FOUR CENTS 0.039336 XRP total. Every transaction paid 12 drops, and not one paid more. XRPL's base fee does not scale with transaction size — Transactor::calculateBaseFee charges the same for an empty transaction and one carrying a full kilobyte of memo. Bytes are free. For 3.19 MB that full-history nodes will now keep forever, the network charged about four cents. That asymmetry is the whole experiment. 🔀 THE PART WE DID NOT EXPECT We rehearsed on testnet first. Mainnet was faster. ▸ Upload time: 20.84 min on testnet, 15.3 min on mainnet ▸ Ledgers consumed: 378 on testnet, 236 on mainnet ▸ Our share of a ledger, median: 90.9% on testnet, 8.3% on mainnet On an empty testnet we were the traffic — filling ledgers with ourselves, sometimes 100% of one. On mainnet the same 3,278 transactions dissolved into ordinary volume and rode along faster. The network never noticed. open_ledger_fee stayed at 10 drops throughout, the transaction queue stayed empty, and ledgers held a median of 171 transactions against an expected size of around 733. 📐 WHAT THE PROTOCOL ALLOWS ▸ Memo ceiling is 1024 bytes for the whole serialized Memos array (STTx.cpp:695, isMemoOkay). Useful payload: 1019 ▸ Adding an 11-byte MemoType tag pushes the transaction over the limit — it fails local checks ▸ In the ledger each transaction occupies 1323.1 bytes: 1172.5 blob plus 150.6 metadata, or 1.298x the payload ▸ The queue accepts at most 10 transactions per account (TxQ.h:165) ▸ A default node keeps the last 256 ledgers (Config.h:209). "Forever" only applies to full-history nodes 🗜 A COMPRESSION PARADOX bzip2 squeezes the Russian text 5.72x, so it would fit in 909 transactions and 0.009 XRP. But compressed bytes look like noise to RocksDB, which cannot compress them again — each stored byte then costs 1.5x more on disk. Net disk saving: 3.98x, not 5.72x. Plain text is the opposite: RocksDB compresses it almost exactly as much as transaction overhead inflates it, landing at 1.048x. 📚 WE WERE PREDICTED In XRPL-Standards discussion #103, someone wrote that memo examples would "land us in episode 143 of the 'I'll put my files on ledger in chunks' discussion" and that "sane people know this is a bad idea." We are that episode. We just measured it. This lands two weeks after the community argued over whether the memo limit should be raised at all — one side holding that paying the fee should buy you the space, the other that every node stores it forever. Nobody put a number on it. Here is one: at today's limit, 1 GB works out to 1.05 million transactions and 12.64 XRP. ⚙️ Worth knowing: XRPL already has a per-byte fee, it is just not used for memos. An EscrowFinish carrying a fulfillment costs 330 drops plus 10 drops for every 16 bytes of the preimage. The mechanism exists. Memos simply do not use it. 🔗 Read any chapter, assembled live from the ledger: staticbit-io.github.io/war-a… Code and dataset: github.com/StaticBit-io/war-… The site stores no copy of the book. Every character is fetched from transaction memos at read time and SHA-256 checked before display. Account: rU1A1kuVpYHk3TZYWJxVtPUc94aXyteizy — its entire history is the novel. #XRPL #XRP #Tolstoy

📊 $16 trillion a year. We ran the number through the ledger. In Jackson Hole yesterday, @bgarlinghouse said Hidden Road and GTreasury together handle roughly $16T in annual transaction volume — comparable to Visa — and that moving part of that flow onto the XRP Ledger would improve speed, cost and settlement. Dollars are not what a ledger counts. It counts transactions. So how many is that? $16T a year = $43.8B per day = $507,000 every second. Turning that into load depends entirely on the average payment size: ▸ $10M per payment → 0.05 TPS ▸ $1M → 0.51 TPS ▸ $100K → 5.07 TPS ▸ $10K → 50.7 TPS ▸ $1K → 507 TPS Hidden Road is a prime broker. GTreasury is corporate treasury — both now inside @Ripple. Their average ticket runs in the hundreds of thousands to millions, not a thousand dollars. The entire stated flow is a fraction of one TPS on top of what the network already carries. Two things follow. The Visa comparison misleads. Visa reaches $16T through billions of small retail charges; this reaches it through a small number of very large ones. Same dollars, opposite transaction profile. And throughput is not the constraint here. What is: FX liquidity depth, trust lines to issuers, and the compliance layer — verifiable credentials and permissioned domains. Those are the amendments currently sitting in the validator voting queue, and sitting there firmly. Our own measurement, taken today: 248 ledgers sampled over 26.7 hours. Average load 23.5 TPS, roughly 2.03M transactions per day, 3.85s close interval. Payments are 38% of traffic; order book activity is about half of it. On the widely quoted 1,500 TPS: that is a capability under favourable conditions, not what the live network delivers today — a point @JoelKatz made plainly in May. #XRPL #XRP #Ripple

🧭 StaticBit Wallet 2.4 is out — Paths: cross-currency payments inside the wallet. The @Ripple XRP Ledger itself builds the route across network liquidity. You pick the pair, set either the amount you send or the amount you want to receive, and before you sign you see the route, the price impact and the fees. Slippage tolerance is configurable, and the quote re-prices live as liquidity shifts. What else landed: → Transaction confirmation moved into a popup — you stay on your screen, the form and the quote survive. → Native QR scanning, including Destination Tag straight into the input field. → Haptic feedback on passcode entry; app auto-lock restored. → dApp connectivity: the session recovers by itself after device sleep or a dropped network, no app restart. A second signing request arriving while a confirmation is open no longer gets silently lost. No fee is injected when the dApp sends a transaction with autofill disabled. Non-custodial, iOS and Android: iOS apps.apple.com/us/app/static… Android play.google.com/store/apps/d… #XRPL #StaticBit #Paths #Crypto @RippleXDev

🌊 The deepest AMM pool on the XRP Ledger holds 2,758,360 XRP — 21.5% of all XRP sitting in the network's 22,280 AMM pools. The median pool holds 80 XRP. We crawled its entire history: 135,710 transactions since it was created. 📉 IT WAS NOT ALWAYS THIS WAY The pool launched on 2024-04-16 with 100 XRP and 14 CRYPTO. By August 2024 the XRP side peaked at 4,877,729. It has been draining ever since — down 43% from that peak. The other side went the opposite way: 31,933 CRYPTO in August 2024, 3,600,768 today, a 113x increase. Price followed: 152.75 XRP per CRYPTO at the peak, 0.766 now. Down 99.5%. That shape is what a one-directional pool looks like. Players earn the token in-game, deposit it, and take XRP out. 🔁 THE VOLUME IS NOT WHAT IT SEEMS Over 30 days, 421 payments moved through the pool. Every single one was circular — the sender and the recipient were the same address. Ordinary transfers between two different parties: zero. Across the pool's entire history, 75,209 transactions touched it. Nine were ordinary payment transfers. The rest were arbitrage bots and offers. The pool is deep, and almost nothing organic passes through it. 🔑 BUT THE LIQUIDITY IS REAL, AND IT IS NOT THE PROJECT'S This is the part worth stating plainly, because the obvious suspicion is wrong. The 2.76M XRP arrived through 57,709 deposits from 893 addresses over 848 days. The largest single deposit in the pool's history was 205,000 XRP — 0.7% of everything contributed. There was no seeding event. The LP token has 792 holders. The largest holds 4.0%. Addresses we could tie to the project on-chain — the issuer, the treasury, the NFT minters, the payout wallets — hold 0.00003% between them. The pool creator ranks 550th. Withdrawals happened too: 1,130 of them, 4.26M XRP, most recently on 2026-07-30. Nobody is locked in. ⚖️ WHAT THE DEPTH CANNOT DO Supply is 10 billion CRYPTO. The pool holds 3.6 million of it — 0.036%. Running the constant-product formula at a 0.864% fee: selling 1% of supply would return 2,661,682 XRP and drop the price 99.88%. Selling 5% returns barely more, 2,738,466 XRP, because the pool is already drained by then. Halving the price takes 1,504,501 CRYPTO and removes 807,905 XRP — 29% of the XRP side. Depth is not the same as being able to absorb the supply above it. 📋 What this does not establish: whether the project is sound, whether the game works as advertised, or what anyone intends. The NFTs are real — 95,102 minted, 77,414 outstanding. The payouts are real — 195,969 of them from one wallet alone. We measured the pool, not the business. Snapshot: ledger 106,225,985, 2026-08-11. Full crawl, no aggregators. #XRPL #XRP #DeFi