EIP-2400 - Transaction Receipt URI

EIPs
1

Latest version: https://github.com/status-im/EIPs/blob/tx-hash-uri/EIPS/eip-2400.md

3 Likes
2

Users need a common, self-describing and universal way of sharing a transaction receipt with others.
As there was already a standard for transaction request, I followed the same idea around it.

Possible improvements:

  • remove the 0x part of transaction hash, as it’s redeundant
  • define a better way of informing the events risen
  • better way of informing method called

I don’t think is important to include things that a client can figure out by itself, as transaction status, for example, as the information would have to be validated anyway.

1 Like
3

thanks for the initiative - left comments on the EIP

4

I added in the specification a recommendation (should) on how to deal with pending and failed transactions.

I wonder if we should add recommendations for inner failed transactions, something that sometimes happens in some contracts as MultiSigWallet, where the confirmation sucessfully executes in the outermost transaction, but the inner transaction fails, leading users to errors in trying to confirm again. The same thing could maybe be used to trick users into thinking a transaction wasnt executed when part of it (as the most important) was executed.

1 Like
5

Also, I mentioned that a transaction can become invalid, but I mentioned a case I am not really sure how realistic is.

What happens when a transaction is included but ends up in a uncle block?
I guess naturally it would get included again in a next block, but it gives a very small window to overrun the transaction, just like is done with pending transactions.

So perhaps this already falls into the case of a waiting for 12 confirmations, and an overrun would cause it to become an invalid transaction just like for overran pending transactions.

6

This EIP now is being moved to Review. If you would like to join conversation: