Dear Terra Classic Community,
Representing Genuine Labs, I submitted this proposal seeking for validators and community's agreement on implementing Tax2Gas in Genuine Labs's approach.
## Overview
As the PPJ work that has been approved by government in [#12115]([hidden link]), we - Genuine Labs will take the responsibility for implementing the Tax2Gas features.
We had shown up our works on 2 biweekly reports over the last 5 weeks that have been described on the proposal:
-
- [hidden link]
Our PR for the works is still openning on [terra classic core repository]()
We also having the test scenarios for testing Tax2Gas logic in e2e, which can be found at: [Test Scenario]([hidden link])
However, we faced strong opposition from some members of the community. That led us to seek the community's agreement to decide if we should implement tax2gas in this way or not.
## Tax2Gas Implementation
Our implementation includes:
- Moving original logic, which located in custom/auth module to tax2gas module
- Giving the method to calculate exact amount that required to pay for the tax and the gas
- Convert all taxes into gas in a pre-defined gas-prices and Allow user to pay by multiple denom to cover gas
- Making the sender to pay for all the taxes that contract might forward
- Changing the way to prioritize tx in mempool
- Adding logic to bypass some special ibc transaction
#### 1. Moving custom/auth module's fee logic to tax2gas
The old fee logic, which is located in custom/auth module will be moved to tax2gas module, which includes some logic: BurntaxSplit, CalculateTax, deductFee,...
Suppose a user A makes a 200000uluna bank send tx that require 20000uluna to pay for gas and 1000uluna to pay for taxes. The new tax2gas logic will be:
- Calculate the gas fee that is required for ante handler (for example 5000uluna), this gas will be deducted immediately in antehandler
- TaxGasMeter will calculate the taxes - which is 1000uluna, convert it into gas and consume it.
- On posthandler, the tax - which is converted to gas (called taxgas) will be converted back to fee (taxfee) based on the token that user chooses to pay for gas. If use choose to pay by uluna, then taxfee will still be 1000uluna.
- The posthandler will also calculate the gas fee that is required for the overall process (which is 20000uluna), minus the gas used to ante handler (5000uluna). 15000uluna + 1000uluna tax will be deducted from user.
- The 1000uluna tax will be handled as BurntaxSplit (80% burn, 3% to bonus rewards, 10% to Community Pool and 7% to rewards)
- The 20000uluna gas will be sent direct to FeeCollector module, which works as validator rewards.
Tax2gas will require new separated params for burn tax rate and gas prices.
#### 2. Giving the method to calculate exact amount that required to pay for the tax and the gas
When tax is converted to gas, the tax will also be multiplied by gas-adjustment. This might make the gas fees become enormous and not correct to deduct all the fees as usual.
As process is very complicated, there is no way to calculate exactly the gas fees (without tax) that need to multiply with gas-adjustment. That's why we - Genuine Labs suggest the chain to deduct user's fee in this way:
- We only calculate the **exact amount of gas** that is needed for overall process and deduct user's fee based on that. That's mean even when user pay 1b LUNC to cover gas, we will only calculate and deduct the actual gas cost and the actual tax for this tx (for example: 20000uluna gas and 1000uluna tax)
**Props**:
- User will not have to overpay for the gas (which might be simulated wrong and need to multiply with gas-adjustment)
- The simulation process will be more precise, less **`out of gas error`** show up. With tax2gas, the gas-adjustment only needs to set to 1.5 (not 2.5 as current tx)
**Cons**:
- Validator might take a little bit less rewards than usual
#### 3. Convert all taxes into gas in a pre-defined gas-prices and Allow user to pay by multiple denom to cover gas
In tax2gas context, as tax is converted to gas, the tax can also be paid in other denom, **as long as it is in gas prices params**. This could help user to pay by multiple denoms to cover gas.
Eg: If a user makes a 200000uluna bank send tx and has to pay 1000uluna but their bank balances only have (200000 + 500 ) uluna, they tx will be rejected as it's not enough to cover tax. But when user has 1000uusd more and the gas prices are set as 2 uusd = 1 uluna, we will allow them to pay tx with uusd. The user just needs to add the fees flag as `--fees 500uluna,1000uusd`.
For now, we will **only accept to pay in uluna and ustc(uusd)** because only those are the valuable tokens in Terra Classic. However, as the gas prices is a parameter, the community can be free to change it and pay with different denoms using **UpdateParams** proposal.
**Props**:
- Allow user to pay by multiple denom to cover gas
**Cons**:
- User might choose less valuable tokens to pay as gas. (However, that can be adjusted with **UpdateParams** proposal when the ratio is not precise.)
#### 4. Making the sender to pay for all the taxes that contract might forward
In our [last report]([hidden link]), we had mentioned that the sender will be the one to pay for all the taxes that contract might forward.
Imagine you need to deposit 100000uluna to a contract B to have a ticket for buying a new release token. However, the contract B can only be deposit by contract A (which have some more logic and may be swap ...). So you deposit 100000uluna to contract A, pay 2000uluna as fee, then contract A will forward that amount to contract B. However, when you open the balance in contract B, it's only show up that the balance is only 998000uluna (2000uluna in amount is required for contract to pay for tax). That's will be very frustrated and you will need to deposit that steps again.
Furthermore, some contracts might process wrong and return error if the amount it receives is less than the exact original amount. Also, it's not fair for a receiver to pay for fees which sender should already paid that.
**Props**:
- More precise way for contracts to execute
- Less inconvenient process
#### 5. Changing the way to prioritize tx in mempool
When we are changing the tax2gas to new logic, gas prices will be the same for every node. As the gas prices that user put in will not be considered as a way to be prioritized in mempool, a new method of calculating mempool's priority is mentioned:
- Transactions that have higher tax gas will be set a larger priority
- Oracle tx will always be the first tx
#### 6. Adding logic to bypass some special ibc transaction
Inspired by Global Fee module, we add a few msg types of IBC that are allowed to not pay fees.
The max bypass gas parameter is 200.000 gas, which means above tx types will not be charged fees if gas limit is smaller than 200.000 gas.
**Props**:
- With this addition, IBC relayers can relay without fees if all txs are small and enhance the IBC relaying for the chain.
## Vote Options
As this proposal pass, we will merge our PR on terra classic core repository as it's our final version in tax2gas. Otherwise, the implementation will be **dropped** and we - Genuine Labs will move on with other PPJ proposals.
Note: This tax2gas implementation will **only be available** for **Lunc** and **Ustc**, the community can vote on future **UpdateParams** proposals if there's a demand for other token denoms.
Vote **Yes** - I agree with the outlined proposal and want to see it implemented
Vote **No** - I disagree and do not want this
Vote **Abstain** - I will go with the majority
Vote **No with Veto** - I strongly disagree and want the deposit to be burnt.