XIP-21: On-chain transaction reference content type

Improvement Proposals Final XIPs
,
1
5 Likes
2

Hi,
It’s my first contribution and I have no intiention of disturbing anything :slightly_smiling_face:, but regarding the structure of the transaction reference, could we consider the Chain Agnostic initiative, aiming to standardise how we identify blockchain-related primitives?

For instance, this specification identifies the blockchain with namespace and networkId while the CAIP-2 specifies the chainId with namespace (eip155, etc.) and reference (1 for Ethereum mainnet, 137 for Polygon PoS mainnet, etc.). So, basically a reference property instead of networkId.

Obviously the reference would clash with this current specification using reference for the transaction hash.

Unfortunately, there is no CAIP specification (yet) for a transaction reference (it can be submitted to their proposal though).

We can think of something like this:

type TransactionReference = {
  /**
   * Identify the blockchain in a CAIP-compliant way
   */
  chainId: { // This structured object is what the caip js library uses
    namespace: string;
    reference: string;
  }; 
  // alternatively
  chainId: string; // The actual CAIP-2 syntax <namesapce>:<reference> (eip155:1) but needs to be parsed to be used. Note the caip js library provides utilities for that.

  /**
   * Lack of CAIP specification for the transaction hash, could be:
   */
  reference: string;
  // or
  transactionHash: string;
  // or something else such as txHash, transactionId, etc.

  // ...
};
3 Likes
3

@aurel This is a great suggestion. I’d be open to aligning on standard naming for the chain, and then renaming the existing reference field to something like transaction_hash to avoid confusion.

2 Likes
4

Awesome. Thanks

2 Likes
5

How wonderful to hear from you, @aurel - thank you for the suggestion and for following up!

@nick - I will revert this XIP to Draft status so we can go ahead and update the XIP to align on standard naming per Aurel’s suggestion.

2 Likes
6

Thank you for the update to the XIP, @nick! Moving the XIP to Review status now.

2 Likes
7

Hi there, I’m new to this space but definitely want to get involved more!
I am implementing this feature and noticed that the amount field is typed as number.
Should this instead be bigint?

Thanks!

1 Like
8

Welcome to the space, @sonicsmith! :wave:

Thank you for taking the time to review this XIP and for your question about the amount field. cc’ing @nick, a core dev on the project, to provide some guidance here. :smiley:

Please do keep an eye on this post as another change may be coming through next week.

If helpful, I thought I’d mention the XMTP Dev Community Call. Half the call is dedicated questions from the community and deep dives into XIPs. So if you ever have anything you’d like discuss, it would be great to see you there!

With aloha,

J-Ha

9

@sonicsmith Just checking back to let you know we’re going to await the return of the XIP author to make a holistic call on this. I will take the action item to loop us all back to your open question upon Ry’s return late Apr/early May. More soon - and thank you again for your partnership on this!

1 Like
10

Open item from @aurel about whether this sentence is still necessary.

11

Open item from @aurel:

Should we make the chainId required?
If not, the behaviour must be documented, for instance, if undefined it defaults to eip155:1 (Ethereum mainnet).
I’d personnally prefer it to be required so that there is (slightly) less cases to manage for builder implementing the specification and, in a chain-agnostic context, there is no preference to a give chain (the default one if undefined)

12

@aurel and @sonicsmith - just a note here to let you know that we are following up on your questions on this XIP. Thank you for your patience!

13

@sonicsmith thanks for you comment! yes, bigint makes more sense for the amount field. i’ve updated the spec to reflect this.

1 Like
14

@aurel thanks for your comment and patience!

for simplicity, i’ve updated the spec to include a mandatory chainId field that references a blockchain ID according to EIP-155. i’ve also added an optional networkId for the rare cases where it differs from the chainId.

i understand this limits transaction references to EVM chains, but that’s also a current limitation of XMTP. in the future, we can consider using CAIP-2 for referencing blockchains.

curious to hear your thoughts on this!

cc @nick

1 Like