Receipts

[adamdossa]

@maxsam4 I took another review of the test cases - really useful to see those!

On the claim receipt logic I think we're still thinking about it in different ways based on: https://github.com/PolymathNetwork/polymesh-settlement-module/blob/bd2f2a3248d4530509b8223df69644c1467107be/src/tests.rs#L428

My thinking is that sometimes a leg will be settled off-chain, rather than on-chain. In that case, rather than locking the asset (and then moving it when the instruction settles), instead when authorising an instruction, a counterparty can provide a receipt showing that they have made the appropriate transfer off-chain instead.

So the API would be something like the below (but with better data structures):

        assert_ok!(Settlement::authorize_instruction(
            alice_signed.clone(),
            instruction_counter,
            legs_being_authorised_with_receipts: Vec<u32>
            receipts: Vec<Receipt>
        ));

This should then check:

• Alice is the payer for any legs in legs_being_authorised_with_receipts
• The receipt details in receipts match the assets that Alice would otherwise have had locked as part of authorising this instruction

Provided those pass, then Alice's authorisation is valid, but no assets are locked for legs_being_authorised_with_receipts and on instruction execution, the receipt is just marked as "Used" and no actual assets are transferred.

To make this work properly I suspect we may need to reserve tickers for fiat currencies, so that they can be referenced in a leg, even though they don't really exist as assets in Polymesh. If we do this, we could add the following checks:

• any tickers referenced in legs in legs_being_authorised_with_receipts are "fiat tickers"
• all legs with "fiat tickers" are authorised via a receipt (rather than locking an asset which shouldn't be possible on "fiat tickers" as they are placeholders and not real assets"

IIUC the current functionality with receipts is a bit different - it allows a user to first authorise an instruction (with all assets being locked) and then submit a claim receipt which unlocks the assets, but still allows the instruction to be executed.

[maxsam4]

@adamdossa I recently added authorize_with_receipt function that covers the single-step authorize and claim receipt functionality. There's no test case for it right now and it only accepts a single receipt. I'll fix both those things soon.

Re. the additional "fiat tickers" checks you mentioned, I guess we can add them but I don't really see the need. As long as those tickers are reserved and nobody has their balance onchain, all instructions referencing them without receipts will fail execution anyway.