xrpscan

From the information available in public domain, exchanges will receive an allocation of Spark tokens directly from Flare Networks. Participating exchanges that have signed an agreement do not need to set their messageKey.

Hi, If you okay with it, can you privately share your wallet address so we can take a look?

I'm unsure about other flare tools, but we do simple verification via this regex: /^0x[A-F0-9]{40}$/ The red flame icon appears only if it matches this regex.

Hi, There's a small nuance when showing information about Spark claims. The claim is valid on last messageKey. This is not the same as the current messageKey. Because of this subtle difference, there's a back-filler that checks for the most recent messageKey and updates the db at the third party service we use. This may introduce some delay and show outdated messageKey info. That's my guess what happened here. I can see that your account now shows your messageKey correctly.

Spark (FLR) claim amounts can now be viewed on xrpscan. Look up your XRP wallet address and it will consider snapshot balance + escrow receivables and multiply with XRP:FLR claim ratio to show the expected amount of FLR you may receive: https://xrpscan.com/account/rTooLkitCksh5mQa67eaa2JaWHDBnHkpy

You may use AltCoinTrader's wallet for example purposes: https://xrpscan.com/account/r34mWrX3cZCZpJEsqe1F6PNotREXwj1f3r I see you've already added XRPScan, thank you! Hello there, @Flintstone!

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.

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.