xrpscan

Its a fair point that every car driver need not know about IC engines - but at the same time enough independent car mechanics must know about engines so one can get it fixed anywhere.

@yxxyun has quite deep understanding of the XRPL. I wouldn't belittle their argument about downward sell pressure.

Deleted accounts are now correctly highlighted instead of showing Account not found error. Searching for deleted accounts will also work properly. Let us know if notice any bugs: https://xrpscan.com/account/r93Fr5Cmf6KAho1GfF9mvNKV97tZsCFKcB

Precisely what @yxxyun said. When the docs say the account is deleted from the ledger, it implies the current validated ledger. Every account's transactions are present in the full history server. There's a tiny difference though, all accounts activated after passing of the amendment will have their sequence number set to the ledger in which they were created (ex. https://xrpscan.com/account/rpgtBwm6FaSdj9YUCrGV81GgwANq7Hm3JV).

It is possible to show historical transactions for a deleted account too. We're rewiring the xrpscan api to do this, as the assumptions we made about the accounts are no longer true due the amendment.

@xrptipbot What kind of disks are these?

There are 35 dUNL validators. One of them is using a more modern domain verification technique, but the data api does not support this method yet and reports 34 validators.

The xrpl.org blog provides more background on why this amendment lost majority. Mainly due to the fact that this amendment introduces a backwards-incompatible change and about half the nodes in the network are still on 1.3.1, and therefore would get amendment blocked.

They've taken this a level up. For 1 XRP they're able to send (1 / 0.000088 + 0.000012) 10,000 scammy payments, and possibly generating as many deposit notifications from exchanges, wallet and tracker apps et al.

The validation message data is not on-ledger, is ephemeral and is transmitted as part of consensus metadata. Therefore, retrieving historical validation messages is a bit tricky. Additionally, validation messages contain only those amendments that a validator is voting for, guesstimating vetoed amendments in historical validation messages is even trickier. For these reasons we don't show voting/vetoing pattern for enabled amendments till we figure out how to backfill this data. Thank you very much! If you have any suggestions for improvement, we're all ears.

Hi SquaryBone, there's been some reports of 404 errors in this release. We've identified the cause, but meanwhile would it be possible for you to hard-refresh the browser window and see if its fixed?

I agree, the amendments could use a bit of context to make sense. We're exploring if its a good idea to write a short summary for each amendment or simply link to the specific amendment writeup. Thank you for your feedback!

XRPL Amendments dashboard is now available: https://xrpscan.com/amendments With this release we aim to provide greater transparency on Amendment voting numbers, super-majority status and Vote/Veto pattern by dUNL validators. Amendment voting status displayed here is based on the validations received during the latest voting round, as reported by our node. Feedback on what's broken, what can be improved is most welcome.

Berkeley validator had an outage last week. Its back online now, but this could be the cause of the dangling validator key.

Thanks for the mention @hallwaymonitor! Btw, we moved over from a flat file to an API over the last quarter: https://api.xrpscan.com/api/v1/names/well-known