Could the RewardManager precompile be used to report burned fee amounts using Teleporter?

[michaelkaplan13]

This Teleporter issue is going to create an example of how Teleporter and the NativeMinter precompile could be used to create a subnet that uses AVAX or any ERC20 on the C-chain as its native token used for paying transaction fees. This will enable moving that token from the C-chain into the subnet as its native token, and back to the C-chain its original form.

At the bottom of that issue, there is an open question:

(Longer Term) Can subnets track how much of their native token has been burned, and report that 
amount back to the origin chain to burn the collateral? This would likely require changes to the VM 
to track the amount burned in blocks, but would help prevent the locked native token collateral from 
strictly growing overtime, making the subnet validators more and more of a security target.

Reporting back how many tokens have been burned to the C-chain is not strictly necessary. The collateral locked there should never be released unless explicitly bridged back from the subnet via a Warp message signed by sufficient amount of the subnet validators. However, in the case of an extremely popular subnet that burns lots of tokens over time as usage increases, those subnet validators become an increasingly large security target because if they were compromised, an attacker to take all of the tokens that had been moved in to the subnet at any point in time and subsequently burned in transaction fees.

I was thinking that in order to try to report back how many tokens have been burned from the subnet to C-chain, the block format would need to be altered to explicitly track the total amount of transaction fees that have been burned. However, reading through the RewardManager, it seems like it could be possible (if not messy) to use it to achieve the same type of functionality.

There would be a solidity contract that has a public method that checks it current native token balance, sends it a to the black hole address, increments the total amount burned, and then submits a Teleporter message to the C-chain reporting that latest amount. The address this contract will be deployed to needs to be pre-determined (either using Nick's method or a specific deployer account/nonce), and in the subnet config, it is specified as the reward address for the precompile (with no admins). Then, anyone is able to call that contract to officially burn all of the fees and report the latest amount burned to the C-chain such that the native token collateral can be burned on the C-chain as well.

Definitely doesn't feel like the cleanest option necessarily, but I think it could be done with the existing precompiles without any further subnet-evm changes.

[aaronbuchwald]

If you want to report total fees burned back to the C-Chain (which could be very useful), you could also just deploy an observer contract (doesn't need to be deployed to the reward address specified by the RewardManager precompile) that checks the balance of the default burn address (or checks the burn address from the reward manager precompile address) and sends a message to report it back to the C-Chain.

You could also do this directly with Warp since there's no need for replay protection (just reports the current balance, which should be monotonically increasing) and you could handle incentives in a similar way to how YieldYak rewards whoever hits "reinvest".

For example, if you send funds to the Subnet via a contract on the C-Chain and also report back the total fees burned on the Subnet to the same contract in order to unlock them on the C-Chain then you could pay a small percentage or fixed fee to the address that delivers the updated fees burned.

[michaelkaplan13]

Oh yeah...I forgot that "burned" fees by are credited to the default burn address as is with a standard set up. That makes it even easier.

Paying out a percentage to whoever reports the burned amount back is also a cool idea. That could be easily configurable in the contract on the C-chain as well.