Vlad Frolov

@telezhnaya Basically, those are receipts and execution outcomes. We have not put too much effort into making that page clear to the end-users since it seems it is rarely viewed....

I am amazed by the grounding work that has been done! :rocket: Here are my answers to the questions: > Can we consolidate Wallet & Explorer? I have never thought...

> Staking? Onboarding for Staking? Personalization for Staking? *(I assume you refer to delegation. It is unfortunate clash of NEAR Protocol staking with the process that Wallet calls "staking", which...

> "download vm context" Can we reconstruct it from a receipt and a block header? Do we need to extend nearcore to provide something else? > We contract runtime team...

@Pangstar Thanks for submitting the issue! Would you consider creating a PR with the issues fixed? I am happy to review and merge it

For the context, `status` RPC returns `protocol_version` and `latest_protocol_version`, but to collect the information, we would need to call `status` RPC on every producing (a.k.a. validating) node, yet we don't...

@bowenwang1996 exposed through `validators` API or how exactly?

@ilblackdragon Do we only want this client-side, meaning that we won't be able to index the data, but it will be easier to implement in pure JS on the client...

@reefoh Hey, here is a quite a useful idea! (we should integrate it into our revamped transaction details experience somewhere in the receipt details block)

@roshaans It is clearly a bug on Explorer side. Transaction status in the indexer database will only be reported as failed if there was not enough tokens to cover the...