Stable and predictable costs for Integritee users

[echevrier]

To ensure that costs are stable and predictable for Integritee users, the Integritee service is priced in USD. Payment, however, occurs in an equivalent amount of TEER tokens, based on the live exchange rate with USD.
See Requirements: #34

Stable Fee Pallet

• Calculates a reasonable USD/TEER exchange rate to convert the USD fees to TEER.
  • Use of Teeracle -> Run a teeracle service to get the USD/TEER exchange rate from different website at a certain frequency (to defined)
  • Get the average
• Conversion value limits to avoid extreme cases
  • Are set by governance decision. 2 possible solutions to check:
    1. Defined as runtime constants. Will be modified by a runtime update.
    2. Min and Max values in storage. SUDO right call for now, then governance vote.

Pay fees in TEER.
2 solutions to be discussed and checked:

1. Compact and perhaps generic solution: Stable fee pallets as a replacement for the transaction payment pallet.
   See: pallet-asset-tx-payment : https://github.com/paritytech/substrate/blob/f318350b6410ef47e438aae24c0b4779373d0a7b/frame/transaction-payment/asset-tx-payment/src/lib.rs
   And its use in statemint :
   https://github.com/paritytech/cumulus/blob/753f58caacfd810ea62fce9ee9d923a274122615/polkadot-parachains/statemint/src/lib.rs#L690
2. Simple solution but perhaps incomplete: Change only the payment. If the fees calculated by the Transaction Payment Pallet are independent of the TEER and can be assumed to be in USD, simply convert these fees into the TEER value to be paid.
   • Implement a new CurrencyAdapter for the OnChargeTransaction of the Transaction Payment Pallet, which takes the exchange rate from the Stable Fee pallet and converts the fee to a TEER fee.
   • Changed the runtime configuration of the Transaction Payment Pallet:
     • TransferFee, CreationFee, TransactionByteFee constants
       USD, MILLIUSD, MICROUSD, .... ?

[brenzi]

solution 1 is not exactly what we need IMO. the asset-tx-payment is meant for paying fees in assets other than the native token. That is not what we do! fees will always be paid in our native token, TEER.
solution 2 sounds interesting because we could really define fees in USD as a standard config, well understandable from source.
@clangenb what do you think?

[echevrier]

solution 1 is not exactly what we need IMO. the asset-tx-payment is meant for paying fees in assets other than the native token. That is not what we do! fees will always be paid in our native token, TEER.

This was just an example of a pallet, which replaces the transaction payment pallet. We would need to implement our own.

[echevrier]

solution 2 sounds interesting because we could really define fees in USD as a standard config, well understandable from source.

In this case the Stable Fee Pallet would be only a USDToNativeTokenConverter Pallet. As the solution is less compact, I'm not sure of the possible consequences : If someone change the configuration or remove the pallet, ....

[clangenb]

After discussing with @echevrier yesterday, I also think that option 2 is the way to go. Also, because we can basically use the standard pallet_transaction_payment. However, I have not investigated how our custom CurrencyAdapTEER 👍 (haha) can access other pallets. If this is not possible, we'd probably still need a custom payment pallet to access the teeracle's information.