API3 DAO Revenue Incinerator

OSS Technologies Limited has deployed API3DAORevenueIncinerator.sol at Ethereum mainnet address 0x41d437332798b32092E6371B667A96779Dc623F6. It is verified, and is a slightly changed and optimised version of this code: github[dot]com/ErichDylus/API3/blob/main/contracts/SwapUSDCAndBurnAPI3.sol, an automatic DAO revenue buy and LP and burner as explained in this medium article: medium[dot]com/@ugurmersin/monetizing-data-feeds-951cd5c912bd.

We want only to contribute to the API3 DAO as a community member for now, though we also consider this an initial reference for any future API3 DAO proposals we might make. OSS Technologies Limited provides review and support services for open source software developers with a focus on Solidity; while we do not provide audits, this code has been peer reviewed, passed MythX security scans, and is not meant to hold large values (small risk at any time). Because this contract is immutable, we as deployer have no way to influence this contract and API3 is free to use it, ignore it, or alter and re-deploy it, as it is open source.

This is gas-optimised and designed for high volume low value amounts to lower MEV risks. Liquidity will be lowest at the beginning, so smaller initial amounts of USDC are advisable. A substantial ETH-API3 token value balance mismatch is unlikely because neither asset is held by this contract longer than one transaction; only USDC and LP tokens may sit idle in balance.

This contract automatically buys-and-burns API3 tokens with any ETH sent directly to the contract, so excess ETH revenue could be directed to it. This also provides a swap and burn mechanism if the ETH-USDC pair on UniV2 were to become unfavourable, or if protocol contracts were to automatically direct excess revenue in the form of ETH to this contract (for example to avoid USDC blacklisting risk).

There are events in this contract for any trackers, along with the swap events in the Uniswap version 2 router for amount of API3 tokens purchased, and the burn events in the API3 token contract.

To sum, this contract is used as follows:

  • send excess USDC revenue to the contract address at which point it is functionally burned (as it is irretrievable)
  • any address calls either (A) swapUSDCToAPI3AndLpWithETHPair() or (B) swapFractionUSDCToAPI3AndLpWithETHPair(uint256 _divisor) to swap and LP either (A) the total USDC or (B) the total USDC / _divisor, respectively
  • LP tokens can be redeemed by any address’s call to this contract only after a year, at which point the redeemed API3 tokens are burned, and the redeemed ETH and fees are automatically used to buy API3 tokens which are burned
  • if ETH is sent directly to the contract address, it automatically buys and burns API3 tokens by the receive() function

Example transactions:

  • swapFractionUSDCToAPI3AndLpWithETHPair() (_divisor of 4) tx: 0xac94a5c30e8e1d3c244b04743cb0cec0b25232a8c84060b1a8a84775ca63257b
  • swapUSDCToAPI3AndLpWithETHPair()tx: 0xab99c7014593081f4e93341002fdf75f95f9f02664e1ba8568686561c45caf19
  • 0.0333 ETH transfer (receive()) tx: 0x05e2d2c5f2cb951d1a58cb3c09a755e0a347d8acacf0b9309c899ae892e94c89)

Changes from source file: add swapFractionUSDCToAPI3AndLpWithETHPair(), use Sol-DAO FixedPointMathLib.sol library in lieu of Sol-DAO FixedPointMath.sol, YEAR_IN_SECONDS as constant variable.



Edited to remove hyperlinks.

Fantastic to see the community building.

Thanks to all contributors. The whitepaper doesn’t detail how exactly this was supposed to be done, and this is a sensible way that addresses the practical issues.

is not meant to hold large values (small risk at any time)

This is arguably not correct, the amount being held will functionally accumulate through the lifetime of the LP. For example, consider the case where it accidentally allowed the redeeming of the LP tokens after 10 years instead of 1 year as a result of a typo.

Somewhat related to this, CTT will have this audited independently because it’s very likely that someone will use this one way or another and we want to avoid potential damages as a result of that.


Just wanted to add that I think the changes to the source are beneficial – specifically I think swapFractionUSDCToAPI3AndLpWithETHPair() is a smart addition, in case larger-than-anticipated chunks of USDC find their way into the address at any given time; this function allows partial treatment of the USDC to mitigate slippage and MEV risk on bulk conversions.

Also glad to hear CTT will submit this for independent audit for the benefit of some additional review :+1:

If a large batch of USDC gets sent to the contract, the party that wants to capture the MEV can call swapUSDCToAPI3AndLpWithETHPair() themselves so I don’t see how swapFractionUSDCToAPI3AndLpWithETHPair() helps.