search

MinaProtocol / mina

Mina is a cryptocurrency protocol with a constant size blockchain, improving scaling while maintaining decentralization and security.
https://minaprotocol.com
Apache License 2.0
1.99k stars 529 forks source link

GraphQL: Indicate ledger creation fee #8669

Open garethtdavies opened 3 years ago

garethtdavies commented 3 years ago

Currently, it is a major source of confusion that 1 mina is burnt when a new address is created in the ledger.

Ideally, explorers/wallets would display this clearly to the user but currently, it is not possible from a raw transaction to easily infer this information.

Is there a way to clearly present this information so it could be presented to the user?

pyreton commented 3 years ago

In the meantime, I suggest adding a note about this to https://docs.minaprotocol.com/en/troubleshooting#accounts-and-transactions

nerdvibe commented 3 years ago

This is how we solved it on Clorio: image

And that's how it "works": https://github.com/nerdvibe/clorio-client/pull/26/files#diff-9594904de99692c822550d8605fb5f7760c7c99cda55461b36fb44853a5010c4R88

garethtdavies commented 3 years ago

Thanks @nerdvibe, will likely implement a similar solution. Correct me if I am wrong (or if I missed this) but this is just based on having an incoming transaction. This doesn't handle those cases where the account is in the genesis ledger?

I took a similar approach to the new accounts chart here by looking for the first incoming transaction to an address that wasn't in the genesis ledger https://minaexplorer.com/stats#accounts-by-day. It works, but still feels a bit hacky and seems having a nice way to incorporate this burnt fee would be better.

robinbb commented 2 years ago

I agree that this is a UX issue, but I do not necessarily see it as a GraphQL issue per se. Though, I understand that whatever UX fix is constructed may involve a GraphQL change. That said, this is not an issue with GraphQL, so I am removing the label.

garethtdavies commented 2 years ago

This is an old issue :) I'll close this as it's possible to handle in other (albeit hacky) ways as any change that was made would only be to GraphQL (it's already handled correctly in the daemon and the archive node), so it makes little sense for it not to be related to that GraphQL label. Feel free to reopen.

robinbb commented 2 years ago

Understood. Thanks, Gareth.

garethtdavies commented 2 years ago

Thanks, I will reopen as actually, now I think of Berkeley, this is probably even more useful as also have the case of account creation via zkApp - the equivalent in archive node is receiver_account_creation_fee_paid. It's possible to infer this in GraphQL but making this explicit would probably help!