StaticBit.io

While working on new features for our app, we discovered an issue in how rippled calculates delivered_amount for cross-currency Payment transactions. When a Payment crosses the sender's own offers on the DEX, those offers are cancelled with zero net balance effect. However, their amounts are still counted in delivered_amount, inflating the reported value. In our test case: ``` delivered_amount: 30 XRP Actual balance change: 10 XRP The same swap via OfferCreate produces correct results. ``` The official XRPL documentation states: "you should use the delivered_amount field of the metadata to see how much actually reached its destination" — with the only documented exception being partial payments before 2014-01-20. Self-crossing offers are not mentioned, meaning any app following the official recommendation may receive incorrect data. The Partial Payments documentation further reinforces this concern: "When processing any Payment, use the delivered_amount metadata field, not the Amount field. The delivered_amount is the amount a payment actually delivered." Takeaway: Always verify delivered_amount against actual balance changes in transaction metadata (AccountRoot, RippleState nodes) — especially for cross-currency swaps. Issue: github.com/XRPLF/rippled/… Docs: #delivered-amount" target="_blank" rel="nofollow noopener">xrpl.org/docs/reference… #XRPL #XRP #rippled #blockchain #dev @msvadari @vjkhannaripple @RippleXDev Check your apps @xpmarket

🚧 Looks like there might be a small issue with the XRPL WebSocket API Tool: xrpl.org/resources/dev-… Getting a frontend error on load: “Unrecognized extension value in extension set…” Possibly related to CodeMirror / duplicate state instances 🤔 Just sharing for visibility — would be great to see it fixed, since it’s a really useful tool for developers 🙌 #XRPL #DevTools #Web3 @RippleXDev

@ShortTheFOMO github.com/XRPLF/rippled/…

@StaticBit_io link issue when you have it open id like to look into this one, thanks :)

StaticBit continues working on new DEX features, and during debugging we ran into an old XRPL behavior that I reported quite a long time ago. Most XRPL methods support pagination via marker, which allows clients to reliably iterate through all objects. However, when requesting the order book using book_offers, pagination does not behave the same way as in other XRPL methods. Example: request book_offers with limit = 5 response returns 5 offers, but no marker is provided. This means the client is forced to use a large limit (50–100+), otherwise it cannot guarantee traversal of the full order book. There is another problem here: the order book may contain unfunded offers (owner_funds < TakerGets), and with a small limit, the client may receive only such offers and never reach the actual liquidity. Someone might suggest using a private node or increasing server limits, and yes — this is partly related to public node limits. But this does not solve the underlying behavior of the method itself. In theory, this behavior can be abused by creating a large number of unfunded offers, for example buy orders, to occupy the beginning of the book. In this case, a client using a small limit will only see those offers and may assume that liquidity is very low. For example, it is possible to create a visual gap in the RLUSD order book where the UI shows that buy liquidity is only ~100 XRP, while in reality it is much higher. As a result, it becomes impossible to reliably load the full order book through the API without special workarounds. Question to XRPL developers: Is this expected behavior of book_offers, or a known limitation of the method? And why does it not use a standard marker field in both request and response like other paginated methods? For DEXs and wallets this can lead to incorrect liquidity display. #XRPL #DEX #XRPLDev #StaticBit @midnightfdn @vjkhannaripple P.S. We first noticed this problem when @xpmarket issuing its token, do you remember this @Kirjakulov ?

We have just created a request to expand the function for the order book in xrpl, we look forward to the support of the community and the interest in this functionality from Ripple github.com/XRPLF/rippled/… @msvadari

it's not broken, it's just not there, you can only get 50-100 offers, if they stand up to those that have real funds - then in fact you will get an empty book, and the fact that you will receive orders by subscription via WSS will not let you see the real state of the book at the moment.

@StaticBit_io marker is broken I get it.

@ShortTheFOMO You don't understand the essence of the problem, read it carefully

@StaticBit_io there are two different ways to get books, one is a WS that auto updates the results. the other is manually calling book_offers I think most just work around this #L588" target="_blank" rel="nofollow noopener">github.com/shortthefomo/t… 😛 ur not the only one to notice that

@msvadari Yes, I think it's time to do it, I'll create a request

@StaticBit_io I wouldn't say anything is broken or incorrect, which would be a bug. It's a feature that probably should have been added a while ago yes, but still a feature request IMO.

@msvadari So, it’s feature?) not a bug?)

@StaticBit_io Seems like a good feature request. I'd recommend opening an issue here: github.com/XRPLF/rippled/…

@Kirjakulov @msvadari I wanted to tag you but I tagged someone else.

@StaticBit_io Not just remove, but based on what you showed me, it can cause an actual heart attack to someone when all order from the orderbook disappear, making it look like there is absolutely no liquidity. Even market makers can get a heart attack.

@Vet_X0 We are waiting it in Brazil, there are reports of expansion, but where are the live forums.

no shortage of XRP events in the next couple of weeks. XRP Tokyo XRP Las Vegas XRP Zone Paris Blockchain Week XRP Meetup Poland

@Kirjakulov Yes, for start-up projects and projects with little volatility to remove unsecured offers in the book, this can be a major problem and a blow to reputation.

@StaticBit_io That is a very interesting behaviour indeed. It was also bery interesting to observe it when you showed it me live. I can easily see how this can be abused to: 1. Temper with price 2. Cause users to panic 3. Cause projects to panic

@Kirjakulov @vjkhannaripple I'm open to new job offers 😅

@vjkhannaripple @StaticBit_io If only such devs received any form of financial "thank you"... Coz they could simply do nothing... And we need to encourage people like him, who have been around for years.

We may have found an unexpected behavior in XRPL transaction streams when using transactions_proposed with api_version=2. According to the docs, proposed transactions should only differ by: validated = false no meta ledger_current_index instead of ledger_index Doc: #transaction-streams" target="_blank" rel="nofollow noopener">xrpl.org/docs/reference… However, when subscribing with API v2, we receive mixed formats: some messages use tx_json some use transaction This makes parsing inconsistent. Interesting detail: This behavior seems to happen on public servers running Clio (s1 / s2), while the public xrplcluster node returns consistent format. Not sure if this is expected behavior, backward compatibility, or a Clio-specific issue. Has anyone seen the same? @msvadari @Kirjakulov @Vet_X0 @WietseWind #XRPL #RippleX #Clio #XRPLDev

@Vet_X0 @Kirjakulov @vjkhannaripple

@Vet_X0 @Kirjakulov @vjkhannaripple In our scenario, this is treated with a small crutch, it is more important that the behavior is expected.

Hey, one thing worth checking — the $ symbol inside the desc field in your TOML. In your metadata you have: desc = "$gei is a project dedicated to taking a 💩 on all the stinky gei bears 🌈🐻 within crypto!" TOML itself allows this, but some parsers in the XRPL metadata pipeline may not handle special characters well, especially if there is any preprocessing, templating, or environment substitution involved. In some languages $ can be treated as a variable marker, and this occasionally breaks parsing depending on the library being used. Also worth noting that the description contains emoji / multi-byte UTF-8 characters, which can sometimes cause issues in stricter parsers even if other explorers display the token correctly. Since Xaman pulls metadata through multiple layers, a failure at any step could result in the token not resolving. @WietseWind will answer this question better. Not saying this is definitely the cause, but I've seen similar issues before with TOML metadata parsing.

Hey guys. I need an XRPL dev to help with an issue with token metadata not pulling into Xaman Wallet if possible. We’re having a strange problem with one of our XRPL tokens $gei raadqNCqPHhqpb5HEMBjbfFa21YYu9GWfW > Logo + metadata show correctly on FirstLedger > Shows correctly on BitHomp > Shows correctly on XRPL Meta > Other tokens we run appear on Xaman fine But for some reason, gei does NOT pull any info into Xaman, no logo, no details, nothing, and it also doesn’t appear in the ecosystem list. We already spoke to @XamanWallet support. They tried manual refresh / manual pull, but it returns errors on their side as well. Things we already checked: ✔ Token info uploaded on FirstLedger ✔ Asset metadata set ✔ Trading volume exists ✔ Trustlines active ✔ Other smaller tokens appear in ecosystem but this one doesn’t So something is breaking in the data pipeline somewhere between: FirstLedger > metadata source > Xaman If anyone from the XRPL / Xaman / metadata / explorer side can help look into this, it would be hugely appreciated. Not sure where the failure point is, but something is clearly not syncing correctly. Would really appreciate any help from the XRPL dev community 🙏

@RippleXrpie Perhaps for a QR code you should use the X address instead of the classic r address, it already includes destTag and is most convenient for the XRPL network?

Spent some time analyzing FortisX. 👉 fortisx.fi/kol/jack What stands out is not the yield itself, but how the system is structured. Liquidity isn’t just pooled — it’s allocated across multiple strategies internally. Meaning: capital efficiency > simple staking For long-term #XRP holders, this model makes much more sense than passive holding. Worth paying attention.

@RyGuy75765 we found you, welcome)

@StaticBit_io Im lost 😆😆😆

@Vet_X0 @msvadari state of each developer after release)

@msvadari @StaticBit_io you know the dev is legend when you see such a pfp