Draft - Opening thoughts on Gas Reimbursements and Bounty Framework

Proposals Brainstorming
1

Authors

  • Finesseboi
  • Owen

Summary

  • Create a foundation for our framework to incentivize devs to build on NFTX. By reimbursing gas costs there is less risk associated with trying out the smart contracts. The purpose of this proposal is to define which situations gas reimbursements would be applicable for and how that can help grow the DAO.

Rationale

  • Incentivize Builders
    • Less Risk for builders
    • Upfront Communications
  • Framework limits fraud
    • Reduces our risk
  • Metrics can always be updated based on the market

Effect

Opportunity

  • Increased Transparency
    • Reduces Fraud
  • Incentivize Builders
  • Builders become teachers
  • Community growth

Risk

  • Cost to treasury
  • Useless reimbursements
  • If people are not allowed reimbursements they may get upset and stop trying to build
    • If NFTX is competitive this becomes irrelevant

Specifications

  • The process to request funds
    • How to prove
  • How much funds maximum can be request
  • How often per dev maximum before we recruit
  • Requirements
  • Bounties/Bonus (if the project gets implemented by the DAO do they get paid a bounty in nftx from the treasury)
  • Security Disclosure
  • Gas Reimbursements

Funding request (y/n) - Yes -

  • Based on previous specifications, case-by-case limited by the framework.

Proposed points of discussion

  • Do we believe this adds value?
  • Should we always ask if this can be done on testnet first?
  • Numbers

Communication

Quorum and Governance Notes

  • Minimum Quorum: As this is only a draft, no quorum is required.

  • Passing Threshold: As this is only a draft, no quorum is required.

1 Like
2

Thoughts:

  1. There are only gas costs associated with deploying smart contracts.
    I suspect the majority of value in the short-term will come from front-end devs who can add more features, or back-end devs who can make things faster.

  2. I think most gas costs associated with trading of the underlying D1/D2 fund tokens are comparable to other platforms like Uniswap, so I don’t think we need to do anything for normal users. Unless we want to have a gas rebate promotion kind of thing on trading like what Balancer is doing right now. But that’s a little hard to do rn b/c technical power is short. So gas rebates should just be for deployment for the D1/D2 pools.

  3. At current gas/ETH prices, it costs around $100 total to deploy a D1 fund. My changes would cut that in about half, so closer to $50-60. I think D1 fund deployment is what we should be clear about funding, and everything else (e.g. other projects/integrations) can be on a case to case basis. We can also reserve the right to not reimburse if e.g. people are just spamming deployment to drain our treasury. Also some obvious requirements on the gas cost for deployment (e.g. they can’t set something absurd like a 1000 gwei tx and expect to be reimbursed).

3

General suggestions for operationalizing the gas reimbursement process:

  1. We decide how much budge to allocate for this (e.g. 8 ETH).
  2. We make it clear that we will reimburse D1 fund creations, as long as there is at least X number of NFTs in the D1 fund. (or some other metric).
  3. We decide on a reasonable maximum gas refund. Suggestion is 0.08 ETH. We reserve discretion to only give partial or no refund if gas price is something absurd like 1000 gwei. (At 8 ETH, that would allow for 100 vaults which seems like more than enough in the short-term.)
  4. We set up a Google Form. Users submit the tx hash of XToken deployment and createVault function call, as well as address they wish to be refunded ETH and the vault number.
  5. Periodically, we go through and decide which submissions to refund, and then ratify with Snapshot (e.g. “Refund D1 deployment costs for vaults 25 to 45”.) Then the DAO will go and refund the smaller of either the total gas amount or the max amount we set.
1 Like
4

I definitely agree here and would push for the framework to reimburse fund deployment. I also think, via rabbithole, reimbursing the gas costs with minting and redeeming will allow users to learn how to use the platform without them being afraid of the cost. I also think case by case permissions should be minimized but they are necessary, having transparent requirements will avoid people deploying as an attack vector.

  1. Agreed, % of treasury max or flat per quarter/month?
  2. What metrics should we use? Minimum TVL, minimum tx amount (usage after deployment)?
  3. Agreed, this should also never exceed a max $ of the budget allocated to gas reimbursements.
  4. This works for me regarding implementation.
  5. We should agree on a set time period so users who deploy will be aware of how long they should expect to wait for possible reimbursements. I think having the time period be the same as the budget revisit would make the most sense.
5

I think flat amount is fine. Not sure if we should allocate some amount every month. Having a lump amount seems better because then people don’t have to do something silly like wait until next month to deploy because that’s when the budget refreshes to get refunded.

I think minimum TVL is fine, especially as even some of the more popular existing funds like PUNKs haven’t seen that much tx activity.

Yeah, having the times line up for reimbursement makes sense.