Use input asset to determine option covenent type

[roconnor-blockstream]

Describe the feature

Notice that the current input asset type to the funding covenant must be either a Grantor Token Generator or a Option Token Generator. The current input asset type to the settlement covenant must be a Target Asset type. For the other Collateral Covenant operations (expire, cancel, and exercise) the current input asset must be a Collateral Asset type. (If the current input asset type is none of these, then the contract is being used in error, and may as well make it anyone can spend, i.e. nothing enforced.)

Therefore much of the witness path can be eliminated in favour of checking the input asset type. That leaves only a choice between expire, cancel, and exercise in case the current asset input type is of Collateral type.

If you wish to get a bit more fancy, you may notice that the expire and cancel operations are nearly identical. You could merge them into a single cancel operation that requires a Grantor Tokens to be burned, and also requires the same number of Option Tokens be burned or not, depending on if the timelock has been set to past the expiry time or not.

[roconnor-blockstream]

cc @apoelstra

[KyrylR]

Hi @roconnor-blockstream, thanks a lot. Since this issue, I’ve done quite a bit of refactoring of the Options contract and also added the batch feature
I hope I didn’t miss anything, but as far as I can see, this issue has already been resolved with the refactored contract (after the batch feature was added)

[KyrylR]

One more update to the comment above

Here is the PoC of what you described, as I understood it:

   match jet::eq_256(input_asset_bits, param::TARGET_ASSET_ID) {
        true => {
            let params: (bool, u32, u64, u64) = witness::SETTLEMENT_PARAMS;
            let (is_change_needed, index_to_spend, grantor_token_amount_to_burn, asset_amount): (bool, u32, u64, u64) = params;
            settlement_path(index_to_spend, grantor_token_amount_to_burn, asset_amount, is_change_needed)
        },
        false => match jet::eq_256(input_asset_bits, param::COLLATERAL_ASSET_ID) {
            true => {
                match witness::COLLATERAL_BRANCH {
                    Left(exercise_params: (bool, u32, u64, u64, u64)) => {
                        let (is_change_needed, index_to_spend, option_amount_to_burn, collateral_amount_to_get, asset_amount_to_pay): (bool, u32, u64, u64, u64) = exercise_params;
                        exercise_path(index_to_spend, option_amount_to_burn, collateral_amount_to_get, asset_amount_to_pay, is_change_needed)
                    },
                    Right(left_or_right: Either<(bool, u32, u64, u64), (bool, u32, u64, u64)>) => match left_or_right {
                        Left(cancel_params: (bool, u32, u64, u64)) => {
                            let (is_change_needed, index_to_spend, amount_to_burn, collateral_amount): (bool, u32, u64, u64) = cancel_params;
                            cancellation_path(index_to_spend, amount_to_burn, collateral_amount, is_change_needed)
                        },
                        Right(expiry_params: (bool, u32, u64, u64)) => {
                            let (is_change_needed, index_to_spend, grantor_token_amount_to_burn, collateral_amount): (bool, u32, u64, u64) = expiry_params;
                            expiry_path(index_to_spend, grantor_token_amount_to_burn, collateral_amount, is_change_needed)
                        },
                    },
                }
            },
            false => {
                match jet::le_32(cur_index, 1) {
                    true => {
                        let expected_asset_amount: u64 = witness::FUNDING_EXPECTED_ASSET_AMOUNT;
                        funding_path(expected_asset_amount)
                    },
                    false => (),
                }
            },
        },
    }

This approach looks interesting and makes life easier when working with branches, though for practical reasons I would leave the current approach as it is unless there is a really strong argument for refactoring

As soon as we have a need for optimization, I would take another look at refactoring the current approach

What do you think @roconnor-blockstream?

PS: The same applies to this:

If you wish to get a bit more fancy, you may notice that the expire and cancel operations are nearly identical

[KyrylR]

Addressed the issue here: #10