StaticBit.io (@StaticBit_io) header
StaticBit.io (@StaticBit_io) profile picture

#XRPL #dev #wallet 🇧🇷 XRPL APPs — decentralized, seamless 📈 🚧 https://teapawt.org/t.co/3JxoZM1ecc

XRPL
Joined June 2024
Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@StaticBit_io)Photo by StaticBit.io (@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
7
1
5
24
14,779
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
26
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
1
1
6
89
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. 🪦🪦🪦
1
2
56
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
1
1
42
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
1
43
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
50
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
42
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
40
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
1
64
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
51
xrpld 3.4.0 shipped Sept 16: LendingProtocolV1_1 and fixCleanup3_4_0. Fourth fixCleanup bundle in a row now. #XRPL
2
50
BatchV1_1 crossed the threshold: 29 of 35, 82.86%. The Majorities entry appeared Sept 15 at 14:06:41 UTC, opening the 14-day window. Activation expected ~Sept 29. Looks like it's starting... #XRPL
44
On Sept 9, rippled merged PR #8157: reserved the SmartEscrow amendment and seven fields. The WASM engine stays in a separate branch. This is merge prep, not a launch. Gas limits sit in validator fee-voting, not hardcoded, so the network can retune them anytime. #XRPL
43
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
59
the anchor is clean: a Payment of 10 drops, merkle root in Memos. but the registry the paper calls on-chain is a JSON file on the publisher's backend. hooks aren't on mainnet. Credentials and DID are, and they cover exactly this. @msvadari #XRPL
Trust in official statistics underpins evidence-based policy. But how can a user know a data set they downloaded is the one the publisher released? Our new paper proposes an answer. bit.ly/3UxqxcX #SDMX #OfficialStatistics
1
115
Thanks @angell_denis . Your dashboard made the github.com/StaticBit-io/Xrpl… test suite stronger, it pointed at holes we didn't know we had. Witness attestations and multisig LoanSet now have tests, neither was possible in the SDK a week ago Fixing them closed 49 red cells on devnet along the way: Sponsor 45→84, XChainBridge 14→23.
New from the XRPL Foundation: a live scorecard for every amendment before it reaches mainnet. amendments-staging.xrpl.foun… 🧵
73
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
59
🪦 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
1
3
271