StaticBit.io

📖 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

2⃣ Fees accrue inside every trade: they stay in the pool, nothing is paid out. 20 trades later the pool held 151.76 XRP for the same 150,000 LP. AMMWithdraw (tfWithdrawAll) returns your share, fees included. 👇👇

fixCleanup3_6_0 #XRPLedger

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

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

XRPL ran slow today, 13:17 to 13:23 UTC. Ledgers closed 10 to 40 seconds apart instead of the usual ~4, and ledgers 107806253 to 107806258 had no transactions at all. #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

PermissionDelegationV1_1 goes live on XRPL in ~1h 10m, around 21:25 UTC. An account will be able to let another send specific transactions on its behalf while the keys stay with the owner. DelegateSet grants and revokes rights, the delegate pays the fee. #XRPL

PermissionDelegationV1_1 should activate around 21:25 UTC on Oct 8. BatchV1_1 and fixBatchV1_2 follow after 14:00 UTC on Oct 9. Votes as of Oct 4: 29, 30 and 34 of 35, threshold 28. PermissionDelegationV1_1 has the thinnest cushion. #XRPL

xrpld 3.4.1 shipped today: a Batch fix and stability work, per @XRPLOperations. No mainnet impact, no funds lost. New amendment fixBatchV1_2 is up for vote too (32/35). Meanwhile BatchV1_1 and PermissionDelegationV1_1 both had their countdowns reset since our last check. #XRPL

PermissionDelegationV1_1 is at 29/35, window to Oct 5, per @Vet_X0. Why PermissionDelegationV1_1: the original never hit mainnet. A Sep 15, 2025 bug let it charge fees before checking permissions (wrong tec vs ter error code). #XRPL

xrpld 3.4.0 shipped Sept 16: LendingProtocolV1_1 and fixCleanup3_4_0. Fourth fixCleanup bundle in a row now. #XRPL