diff --git a/XIPs/xip-21-transaction-reference-content-type.md b/XIPs/xip-21-transaction-reference-content-type.md index 57e24b1..86821ce 100644 --- a/XIPs/xip-21-transaction-reference-content-type.md +++ b/XIPs/xip-21-transaction-reference-content-type.md @@ -2,9 +2,8 @@ title: On-chain transaction reference content type description: Provides an on-chain transaction hash or ID sent as a message. author: @rygine (Ry Racherbaumer), @lourou (Louis Rouffineau), @nmalzieu (Noé Malzieu), @galligan (Matt Galligan), @nakajima (Pat Nakajima), @yash-luna (Yash Lunagaria) -discussions-to: https://community.xmtp.org/t/xip-21-on-chain-transaction-reference-content-type/532 status: Review -type: Standards Track +type: Standards category: XRC created: 2024-01-26 --- @@ -35,20 +34,24 @@ The goal of the transaction reference content type is to provide transaction det ```ts type TransactionReference = { /** - * The CAIP-2 chain ID where the transaction happened in the format `:` + * The chain ID for the transaction as outlined in EIP-155 */ - chainId?: string; + chainId: number; + /** + * The networkId for the transaction + */ + networkId?: number; /** * The transaction hash */ - transactionHash: string; + reference: string; /** * Optional metadata object */ metadata?: { transactionType: string; currency: string; - amount: number; + amount: bigint; decimals: number; fromAddress: string; toAddress: string; @@ -58,23 +61,23 @@ type TransactionReference = { ## Rationale -The `chainId` provides details of the network used for the transaction in [CAIP-2 format](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md), while the `transactionHash` field contains the hash of the transaction on the network. These two fields should be enough to display a basic reference to the transaction. An optional `namespace` field can be used for a more human-readable description of the network. +The `chainId` provides details of the network used for the transaction as defined in [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md), while the `reference` field contains the hash of the transaction on the network. These two fields should be enough to display a basic reference to the transaction. An optional `networkId` field can be used when it differs from the `chainId`. In addition, optional `metadata` can be added to provide more details and a richer display of the transaction. -## Backward Compatibility +## Backward compatibility To maintain backward compatibility, a content fallback is stored in the codec as text — ensuring that the intent of the transaction reference content type is conveyed even in non-supporting clients. -## Test Cases +## Test cases Test cases will validate the interpretation of schema type and effective use of a content fallback. These are essential for ensuring interoperability across XMTP platforms. -## Reference Implementation +## Reference implementation -You can find a reference implementation of this transaction reference content type in the [xmtp-js-content-types](https://github.com/xmtp/xmtp-js-content-types) repo under the [packages/content-type-transaction-reference](https://github.com/xmtp/xmtp-js-content-types/tree/main/packages/content-type-transaction-reference) directory. +You can find a WIP reference implementation of this transaction reference content type in the [xmtp-js-content-types](https://github.com/xmtp/xmtp-js-content-types) repo under the [packages/content-type-transaction-reference](https://github.com/xmtp/xmtp-js-content-types/tree/main/packages/content-type-transaction-reference) directory. -## Security Considerations +## Security considerations While there are no known negative security implications in the data of the on-chain transaction reference content type, clients could pass inaccurate or misleading values for these fields. In addition, clients could display inaccurate or misleading values for these fields and/or link to unrelated transactions.