Optimizing incentives in the burning fee
Closed this issue · 4 comments
Incentives only work when users have a choice - in the case of the burning fee, the choice to shift out or hold renBTC (or any other minted token). The current fee model equally distributes burning incentives across the entire RenVM ecosystem, despite many dApps naturally burning more than others. This may result in a misalignment of incentives where they are needed most.
Problem
An equal distribution of the fee may (1) overincentivize dApps unaffected by changes in the fee and (2) underincentivize dApps that give users a choice to shift out or hold. For example, the fee would be negligible for Compound borrowers because prospective borrowers are unlikely to borrow BTC (and shift out) just because of a lower burning fee imposed by RenVM. Compound’s borrow volume should be unaffected by the fee, so RenVM would lose potential income by offering a fee any less than max. Because Compound reaps part of the incentive, dApps that do offer users a choice to shift out or hold (where the incentive would work best) would be underincentivized.
Proposal
Ideally, the fee would be weighted for each dApp based on how much renBTC it has shifted in and out. This is a natural reflection of both choice and general shifting behavior, so this would optimize incentives for each dApp. At any given R/3, dApps that have shifted out a higher % of the renBTC that they have previously shifted in should pay a higher burning fee, as they need less incentive. More of the incentive would then be reaped by dApps that are under-shifted-out (these are the dApps RenVM needs to shift out most and may be likelier to offer users a choice).
Examples
Let’s assume a max burn fee of 0.15%.
• dappA has historically shifted 50 renBTC in and 0 out. It needs maximum incentive to shift those 50 renBTC out, so the burn fee should be 0.
• dappB has shifted 50 renBTC in and 49.9 renBTC out. It needs minimal incentive to shift out the remaining 0.1 renBTC (0.2% of 50 renBTC), so the burn fee should be discounted from max by only 0.2% (or 0.1497%).
• dappC has shifted 50 renBTC in and 25 renBTC out. It needs the median incentive to shift out the remaining 25 renBTC (50% of 50 renBTC), so the burn fee should be discounted from max by 50% (0.075%).
Considerations
• A contract could request to shift out more renBTC than it has shifted in. If shifted_in < shifted_out, the maximum fee of 0.15% would be imposed. This disincentivizes users to shift out of proxy addresses. The more that users shift in from one address, the more incentive they're given to shift out from the same address.
• renBTC holders can find ways to shift out of the lowest-fee dApps, but this would create an equilibrium across the ecosystem over time.
• The implication is that the more burning an address does relative to minting, the more expensive burning becomes. If an address has already shifted out most of the renBTC is has shifted in, it should need minimal incentive to continue shifting out. Why offer incentives where they're not needed?
Model
The model would be represented by burn(x) = min(0.0015, -0.0015x+0.0015) where x = % of unshifted-out renBTC, or (shifted_in - shifted_out) / shifted_in.
One thing that isn’t taken into account here, from a conceptual point-of-view, is that many dapps are likely to offer users a choice: do you want to receive your BTC from this dapp as renBTC (faster and cheaper) or BTC (more tangible)? A lot of the composability in DeFi depends on this choice being available to users/contracts.
This proposal is based on the idea that choosing renBTC over BTC (or vice versa) is inherent to the dapp, rather than the user of the dapp. The risk of adopting this proposal is largely around whether or not this assumption is actually true. At this stage, I recommend that we keep this issue open, continue to flesh it out, and observe people’s/dapps’ behaviours after the SubZero rollout.
One question that comes immediately to mind is around how to implement this fee. It is certainly possible that you could track the minting/burning ratio per address, but we will need to investigate whether there are exploitations to that minimise fees “out of bounds” of the incentives being created by this proposal. For example:
People deploy proxy smart contracts whenever they need to mint. People “use up” these minting smart contracts whenever they need to burn. If there is renBTC in circulation, then this guarantees there is proxy somewhere that has minted renBTC but has not burned up to that same ratio yet. If people deploy lots of small value proxies, then it's reasonably likely that many of the proxies would not have been consumed at all.
One defense against this is that you integrate the fee over the entire curve. However, it illustrates that there are potential ways that people (or eventually the ecosystem) may subvert the intended incentives.
There’d need to be a mechanism to impose the "optimized" burning fee on each unit of renBTC being burned based on the most-used contract they went through. This would disincentivize using a dApp and then "using up" a proxy to burn for a lower fee.
In the case of renBTC passing through multiple contracts, we could compare the amounts of historical renBTC minted between those contracts and impose a fee unique to the contract with the highest amount.
For example, let's say Alice mints 0.5 renBTC through proxyA, sends it to Idex, and then gets it all back as renBTC. Let's also say Idex has historically minted 10k renBTC, while proxyA has minted 0.5. While calculating a burning fee for proxyA's 0.5 renBTC, RenVM would:
(1) see that her 0.5 renBTC also passed through the Idex contract,
(2) compare Idex's 10k historical renBTC minted to proxyA's 0.5,
(3) then apply a burn fee on the 0.5 renBTC from the "optimized" model that is unique to the Idex contract.
Even if Alice were to "use up" proxyA, she'd pay the same fee as if she burned directly through Idex, thus disincentivizing proxyA altogether and letting the above proposal function as intended.
Q: The community could deploy a "universal minting proxy" with no burn method that could become the most-used minting contract. If Alice's renBTC were minted through it, and it had historically minted more renBTC than the dApps she used, wouldn't this mechanism give her renBTC a 100% burn discount?
A: When evaluating contracts' historic mint volumes to calculate a fee, this mechanism would need to disregard all contracts that have burned 0 renBTC. With or without a burn method, this contract could certainly mint more than any other contract. However, in that case, as long as it has burned > 0 renBTC, the community at large would not have incentive to mint through it because it would be "used up" before it could subvert the incentives in any meaningful way.
Questions:
(1) Too cost/time prohibitive for RenVM to trace units of renBTC between contracts?
(2) On-chain privacy solutions?
- Without spending a decent amount of time scoping this solution, it's hard to say how complex it would be. My guess is that it will be very hard to prove the correctness/soundness of any formal description, which we would need before we could be confident that there weren't loopholes.
- On-chain privacy would indeed make this very difficult, perhaps even impossible (depending on the privacy implementation).