Pallet XRPL

[zees-dev]

Context

This PR introduces the XRPL transaction pallet (pallet-xrpl-transaction) - which allows for the submission of signed XRPL transactions of the SignIn type by the XUMM mobile wallet to be submitted to the chain.

The signed transaction must contain specific memo data of the extrinsic - which encodes the chain_id, nonce, max_block_number and a hash (blake256) of the scale_encoded_extrinsic to be dispatched by the mapped ethereum address (from the provided pub key in the signed transaction).

The pallet only contains a single extrinsic submit_encoded_xrpl_transaction that is a self contained call - which means that the signed transaction is validated based on the data provided in the signed transaction itself.

A signature must be provided in the submit_encoded_xrpl_transaction call (2nd param) in addition to the actual call itself (to be which is hashed and signed in the memo data); these parameters are validated against the provided encoded/signed XRPL transaction.

Original RFC

Dependent PRs

• apply_self_contained function signature update trn-frontier#6
• apply self contained updates #753
• once_cell support previous rust versions xrpl-sdk-rust#4

[ken-futureverse]

can we shorten the pallet to be just xrpl @zees-dev ?

[zees-dev]

can we shorten the pallet to be just xrpl @zees-dev ?

so, pallet-xrpl?
I do think it can create confusion with xrpl-bridge and maybe xls-20 since it's not really like a top-level xrp crate.
What do you think?

[p-dealwis]

@zees-dev I'm guessing because we are using the ethereum address scheme they can't hold assets on their address in TRN? And if so does that mean they will only be able to access TRN via their FPass account?

[zees-dev]

@zees-dev I'm guessing because we are using the ethereum address scheme they can't hold assets on their address in TRN? And if so does that mean they will only be able to access TRN via their FPass account?

Since the public key can be mapped to both XRP address scheme and TRN address scheme, we can use it to derive the ethereum address.
In fact this derived ethereum address is used to perform their futurepass address lookup.
Hence it is possible for both the mapped ethereum address and the respective futurepass address to hold assets.

[surangap]

nice work👏. added couple of comments for further improvements/discussion

[surangap]

lgtm👍

[ken-futureverse]

I wonder if we should use genesisHash as a way to identify the chain rather the chainId in the signing payload, the problem with chainId is it relies entirely on the admin to make sure it's unique, there is nothing on-chain could validate that, meanwhile, genesisHash is a guarantee uniqueness. It also creates a weird coupling dependency between the XRPL and Frontier pallet, I assume.

[JasonTulp]

Nice work 🚀