Allow for more fee margin for multisig accounts
- Lenguaje dominante
- Rust
- Estrellas
- 132
- Forks
- 167
- Merge medio
- 1 d 23 h
- PR fusionados (30 d)
- 110
Descripción
With #3303, multisig fees are paid in a similar way to singlesig accounts: the tx summary commits to the fee note. We might want to change this in the future as described below:
Note: this is not an issue with flat fees, since the fee committed to in the tx summary will always cover the execution costs.
---
I think here the sequence would need to be different from how it works for single-sig. Specifically, we don't want to pay fees before `exec.multisig::auth_tx` is run. This is because multi-sig coordination may take significant amount of time (i.e., potentially days) and in this timeframe the fees could change.
I think the desired sequence would be:
1. Run a fee estimation procedure. This would give us the fee amount. For this, we'd probably need to split the `pay_fee` procedure into `estimate_fee` (to compute the fee w/o creating the fee note) and `pay_fee` that would internally use `estimate_fee` and then create the note.
2. Make some adjustments to this fee amount (e.g., multiply by 2). The adjustments could be passed in via the auth args.
3. Include the adjusted fee in the `TX_SUMMARY_COMMITMENT` - we can probably just override one of the `salt` values.
4. Collect signatures on this commitment (may take time).
Once the signatures are there, we'd execute the procedure again but this time:
1. We'd need to skip the fee estimation logic - but would still need to make sure we include the previous fee estimate in the `salt` (we should be able to communicate this via auth args)..
2. After `exec.multisig::auth_tx` run `pay_fee`. Would be good if `pay_fee` returned the asset that went into fee payment.
3. Verify that the asset that went into fee payment is not greater than the one we committed to in tx summary.
_Originally posted by @bobbinth in https://github.com/0xMiden/protocol/pull/3303#discussion_r3583173659_
Guía de contribución
Evaluación
Este issue todavía no se ha evaluado.