XRPL Multisig Prover

[abresas]

Support for payments (native or with token) using tickets, and updating multisig signers.

• We do not yet support GMP
• Payment amounts are passed as cosmwasm coin amount, yet precision loss needs to be discussed
• We have (temporarily) added an xrpl_voting_verifier contract that allows us to differentiate between different message statuses. The generic voting_verifier has functionality for supporting this, but doesn't expose the actual status of a message yet.
• We haven't yet implemented rewards which is a new feature that wasn't part of the generic multisig prover when we started the project, and we are not sure if and how they should be implemented.
• This PR requires custom signature verification support from multisig contract, which isn't yet supported.
• We have a first implementation of integration tests. However, the integration tests fail, unless signature verification on multisig is disabled (commented out), until custom signature verification is implemented.
• No support for trustlines yet

[cjcobb23]

Why do we need a separate voting verifier for XRPL? We added support for succeeded vs failed on chain to the voting verifier, I think that's the only thing you needed for the XRPL case, is that right?

axelar-amplifier/packages/axelar-wasm-std/src/voting.rs

Line 140 in c0904e1

pub enum Vote {

[k4m4]

Why do we need a separate voting verifier for XRPL? We added support for succeeded vs failed on chain to the voting verifier, I think that's the only thing you needed for the XRPL case, is that right?

axelar-amplifier/packages/axelar-wasm-std/src/voting.rs

Line 140 in c0904e1

pub enum Vote {

@cjcobb23 We had added status confirmation logic to the voting verifier before the feature you mentioned was implemented, so we had forked it out as a separate project. We recently discussed switching back to the voting verifier, but it looked like the feature we need is still WIP, since we couldn't find a way to query for the message status (Vote) that reached consensus (just boolean):

axelar-amplifier/contracts/voting-verifier/src/query.rs

Line 78 in c0904e1

== Some(Vote::SucceededOnChain) // TODO: consider Vote::FailedOnChain?

[cjcobb23]

Why do we need a separate voting verifier for XRPL? We added support for succeeded vs failed on chain to the voting verifier, I think that's the only thing you needed for the XRPL case, is that right?

axelar-amplifier/packages/axelar-wasm-std/src/voting.rs

Line 140 in c0904e1

pub enum Vote {

@cjcobb23 We had added status confirmation logic to the voting verifier before the feature you mentioned was implemented, so we had forked it out as a separate project. We recently discussed switching back to the voting verifier, but it looked like the feature we need is still WIP, since we couldn't find a way to query for the message status (Vote) that reached consensus (just boolean):

axelar-amplifier/contracts/voting-verifier/src/query.rs

Line 78 in c0904e1

== Some(Vote::SucceededOnChain) // TODO: consider Vote::FailedOnChain?

I see, yes the status is not yet exposed through query. I think it would be preferable to just expose the status through a query in the voting verifier, rather than write an entirely new contract. We would welcome a PR for the voting verifier to expose the status via query.

[eguajardo]

Why do we need a separate voting verifier for XRPL? We added support for succeeded vs failed on chain to the voting verifier, I think that's the only thing you needed for the XRPL case, is that right?

axelar-amplifier/packages/axelar-wasm-std/src/voting.rs

Line 140 in c0904e1

pub enum Vote {

@cjcobb23 We had added status confirmation logic to the voting verifier before the feature you mentioned was implemented, so we had forked it out as a separate project. We recently discussed switching back to the voting verifier, but it looked like the feature we need is still WIP, since we couldn't find a way to query for the message status (Vote) that reached consensus (just boolean):

axelar-amplifier/contracts/voting-verifier/src/query.rs

Line 78 in c0904e1

== Some(Vote::SucceededOnChain) // TODO: consider Vote::FailedOnChain?

I see, yes the status is not yet exposed through query. I think it would be preferable to just expose the status through a query in the voting verifier, rather than write an entirely new contract. We would welcome a PR for the voting verifier to expose the status via query.

I just started taking a look at this, I'll be working on the query to expose the status

[cjcobb23]

This is not a standard format for message ids. This is used by evm chains, but other chains could use different formats. What types of messages is this called on specifically?

[k4m4]

Let's close this, since the XRPL-specific smart contracts will live in a Common Prefix fork. We will submit a separate PR with just the XRPL ampd components shortly.