Some ideas for the network explorer page are available at: XRPLBounties/Proposals#16

• An amendment gaining or losing majority.
• An amendment becoming activated.
• Fees being increased or decreased by consensus.
• Transactions that are in a validated ledger with tecINVARIANT_FAILED
• External events ("The validator list at vl.xrplf.org was updated: new serial number 31891")
• In the future, reports about detection of Byzantine validators.

@xrpscanner

xrpscan showcases the time on which a transaction was validated, 02/21/2016 | 08:29 & Dec 14, 2019, 07:21:01 AM UTC.

This is great but it would be best if xrpscan showcases the time since it was validated, 1 hour and 30 minutes ago, in this design:

Normal video on Youtube:

When the user hovers over the channel's button, it showcases this:

So if the user wants to know when the transaction was last validated, the user must hover over to the time section of the page, which will showcase something like this 13 hours and 08 minutes ago, 38 minutes ago, 24 seconds ago, 4 days, 09 hours and 38 minutes ago.

Summary

It appears that the sorting of Amendments is wrong. I think this has something to do with the fact that we went into double digits on the minor number. I think the latest Version and Amendments should move up to the top so that the sorting is the same as before.

Steps to reproduce

1. Navigate to https://xrpscan.com/amendments
2. Scroll down until you find version 1.10.0 of accepted Amendments

Example Image

Revision 1.1

Show NFTokenBrokerFee on NFTokenAcceptOffer transaction pages. For example:

https://xrpscan.com/tx/BE43B2D19F9487D92F32CB0C139EB98F9D19C9A411FE012D0E36C517E8D5390B

It would be useful to show Transaction metadata, such as balance changes in a more user friendly format. To do this, we may switch to https://www.npmjs.com/package/ripple-lib-transactionparser for parsing tx.meta property.

https://xrpscan.com/amendment/0285B7E5E08E1A8E4C15636F0591D87F73CB6A7B6452A932AD72BBC8E5D1CBE3

Validators may be listed under Nays section because they:

1. Explicitly voted No by rejecting an amendment
2. Are running an older version of rippled that doesn't support this amendment
3. Are running latest version of rippled, took no action, and the amendment defaults to No

It would be great to distinguish between the first two cases and highlight vetoing validators that are running an unsupported version.

It would be really nice to have a transaction explanation bot that can be tagged in a @github
comment or a chat channel and provided with an XRPL TX hash.

The bot could generate and post a detailed analysis of said tx, complete with fancy tables and maybe even graphics!

Context: https://twitter.com/nbougalis/status/1328512054622253070?s=20

I didn't receive the transaction to my address, the txid says no transaction found.

For example, SBI VC (1.8) are related, and can be clubbed in a single view.

I believe adding Xrplorer's forensic services would greatly reduce the amount of scammed victims, it would increase the XRP Ledger's transparency.

When someone searches for an address (activated or not), refer to Xrplorer's forensic DB which contains a list of reported accounts that are conducting illegal activities such as scamming and hacking, to name a few.

Currently, the XRP Ledger Foundation is sponsoring the basic package which you can use to access their advisory lists which contains these said reported accounts, I believe scams should be diminished from the XRP Ledger ecosystem, we can start by implementing Xrplorer's forensic services to everyday used applications like yours 😄.

When an account is deleted/not activated, it normally showcases this:

If you implement this feature, I recommend doing something similar to this:

When an account is searched by a user, go through Xrplorer's lists, if the address is contained in the said list, showcase a bright red warning, like:

or something simpler:

This will increase xrpscan's reputation in the XRP Ledger ecosystem, it will also keep the XRP Ledger ecosystem safer and transparent.

@xrpscanner

Links:

• https://xrplorer.com/
• https://xrplorer.com/products/advisorylist

Currently, the amendment registry is updated manually by the admin. There's some room for improvements to be made.

We're able to show new amendments automatically by using a non-dUNL rippled instance. If a new rippled version is available, update automatically and go through the amendment list under src/ripple/protocol/impl/Feature.cpp (here) and if a new amendment is found:

List it on the amendment registry, dUNL voting stats will be provided later on when the admin updates their dUNL validator.

As mentioned internally, xrpscan's dUNL validator should not be updated automatically for security reasons. This is a slight improvement.

On Partial Payment transaction info page, add a badge that clearly indicates that the transaction delivered less than requested amount.

Example: https://xrpscan.com/tx/957AF5856DF4265AB8A44537B62081D78CA4ECA6FA38F89358883510380A0EA7

Please consider adding a plot showing the total supply of an issuer's assets over time. For black holed accounts this feature would be useless, but I believe it would be insightful for assets issued by gateways such as Bitstamp USD and GateHub USD.

We can look at the order books for pairs including Bitstamp USD (for example) to assess the current state of that asset's liquidity, but it says nothing about that asset's potential liquidity and market depth taking into account the amount sitting idle in wallets. We can also currently view the total issued supply on XRPScan as printed text, but it doesn't tell us how that amount compares to prior amounts. By viewing a plot of the issued amount over time we can better understand whether or not an asset's popularity is increasing or decreasing, and can help users decide if they should consider a trading strategy involving that asset based on its relative availability.

I also think this would be nice to have simply as a record of historical XRPL metrics, and as a way to identify potential trends.

Thank you for taking the time to consider my suggestion.

currently not optimized for mobile

Switch to Advanced table. Example: https://xrpscan.com/account/rMsZProT3MjyCHP6FD9tk4A2WrwDMc6cbE

@xrpscanner

Could xrpscan add a new metric to the metrics page, named XRP burned that tracks the amount of XRP burned?

How to achieve this

For every ledger, add all transactions' fees together and use that as the amount of XRP burned.

We can use this method to even compute past ledger's data but it would be a hassle to retrieve all past ledgers and their respective transaction, and then computing them all.

https://xrpscan.com/ledger/4444444

Fields under ledger summary such as ledger_index, hash, parent hash and tx hash are missing.

As described by @hallwaymonitor2:

1. Collect the info of the relevant DTs to a table (pic 1).

2. Calculate aggregates of txs & XRP payments (daily, weekly or monthly).

3. Draw and publish the following chart (pic 2).

FYI:

• I made up the numbers (of pic 1 & 2) just for demo purposes.
• I think even monthly aggregates alone would be cool because smaller time frames could bring too much noise (?)
• In future there will be lots of xRapid related DTs and hence the aggregates would be sufficient.
• Criteria is needed for xRapid relevant DTs due to transparency which DTs are qualified and which aren't within the published aggregates.

Further clarification by @behindtheledger

I think that's a great concept. And agree the aggregates are important for detecting trends. At least for the first pass, I'd frame it more as an analysis of xRapid exchange flows, than an xRapid volume tool. Leave it open-ended.

That avoids misleading people, because we can't know with certainty what's xRapid and what just looks like xRapid. For a later refinement you could try to match the ledger xfers with exchange trades, but that is probably trickier than it sounds.

Another option is to do a separate analysis as we've been doing, and then input the DTs which are most likely to be doing xRapid flows...but that wouldn't be fully automated

On an individual amendment page, how about adding a column for each validator with a link to the first flag ledger validation (not sure if you track these, actually; could just link to the ledger itself) in which that validator started voting for the amendment? And for the nays, maybe a link to the last flag ledger when they voted in favor of the amendment (implying the flag ledger after is when they stopped voting for it), if they ever voted for it.

I noticed today that when I bring up my account through Trezor > XRP Beta Wallet > See full transaction history that it no longer shows my account associated with a Flare address, is this something that you changed recently? I was kinda freaked out and thought it got disconnected for some reason.

Most AMM accounts listed on https://xrpscan.com/amms (Page 5) are inactive. Its possible these AMMs were deleted, and recreated under a new AMM account. Add condition to exclude inactive AMM accounts.

(Fat fingered submitting this issue early.)

On an individual amendment page, how about labeling the groups "yeas" and "nays" in the style of a vote, instead of "voters" and "vetoers"? I think it's much better terminology. All validators are voters, but they might vote differently. None of these votes is a veto, which typically implies unilateral nullification of a passed resolution. Yeas and nays matches the terminology used in human elections and resolutions.

Many transactions have date set to epoch. For example: https://xrpscan.com/tx/5DA6701294BC5C25590CA1BAED1F1AAD9D02C37CBB214D1088C0A65A7808E5F7

i found the date in the tx data is error ,the tx hash is https://xrpscan.com/tx/D48679E493842959383B3E8113AC0380EDF399FEFA8BE9FD774AD9D1ADA35B53
https://xrpscan.com/tx/7C5376ADC92E931551BB240E4B1AD00D647E8E538491F8FB1FE3C68E4BF39BED
https://xrpscan.com/tx/D7949BA083380B68123C832BED5871935959EDCED4DD72F742A4B44015055D52
they all show that date is Jan 07, 1970, 02:08:50 PM UTC

Show the total account balance at the end of each transaction for the transaction asset. In other words, an XRP transaction would show the XRP balance at the end of that transaction not just the transaction amount.

Amendment voting progress bar uses websocket to connect to ws.xrpscan.com and render the progress bar. It takes upto 2 seconds to establish websocket connection and shows skeleton until that time.

Instead of progress bar skeleton, it would be better to show cached voting data.

You can't really scroll through the graphs very easily.

Some transactions don't have transaction metadata like affected nodes. This must be fixed.

Example tx: https://xrpscan.com/tx/1722224453E72048B40797310D6EA707F5D2C72BC081732C01074D68849D6877

Currency codes are not converted from the HEX throwing the display off.

Show validators' up-time rate (e.g: 97% up-time rate), replace it with the validators' consensus agreement rate (1h), I think the 24h rate is good enough. A validator's up-time rate is important to consider its overall reliability.

I have no idea how we could backtrack this data, hopefully there's a log somewhere in rippled (unlikely)

Create a page that shows how much XRP one would need in a wallet to be in various percentiles. Something ledger.exposed used to show and rich-list.info shows now.

Really small amounts of Gatehub.BTC are shown as 0 BTC in transaction info page. The actual amount delivered is 9.593812375249502e-9 BTC. Actual amount delivered must be displayed, regardless of its value.

Link: https://xrpscan.com/tx/AA6299FCAFF5958BCD78721C473AEC6E69663B3B87B1B8DBCE38E40B8618EBAD

As of the time of writing, the account explorer and the api seems to be returning a 404 status code. Please see the screenshot below.

xrpscan should have at least a automated status page where users can check for any outages, maintenance and/or any down time. Cheers!