Governance Call Recap
- Date: Dec 5th, 2024
- Time: 17:00 UTC
- Moderator: @alex. from @Boardroom
- Recording Link: YouTube
Agenda
- Introduction from Boardroom, Luke Youngblood, and 0xMims
- The Great OEV Debate from API3, RedStone Finance, and Solidity Labs
Meeting Notes:
- @alex. from Boardroom started the call with the Moonwell Minute, a quick look at quantitative governance data. The first metric was proposal participation; like last month, Alex noted that we are still seeing elevated turnout on proposals. This month, proposals ranged from 173 to 313 votes. The second metric was the participation of the top 1000 delegates. This month, there was a slight change in the voting participation makeup of the delegate base. Both active and inactive delegates decreased (-0.58% and -1.68%, respectively) and there was an equivalent increase in “ghost” delegates (a change of +2.26%). Delegates are classified as “ghosts” if they have never voted on any proposal and “inactive” if they’ve voted once (but not on the last 3 proposals). This could be explained by continuing userbase growth on Base and Optimism; as new users come in, it may take some time for them to familiarize themselves with how governance works and cast their first vote.
- Moonwell contributor Luke then joined the call to discuss multiple things. First, he talked about the proposal to add a voting requirement to enable users to claim rewards and he mentioned the impact that’s had on the consistency of reaching quorum on proposals. He urged community members to vote “abstain” should they not want to express an opinion on a proposal. He also gave an intro to the concept of OEV (Oracle Extractable Value). When a loan is underwater on Moonwell, liquidator bots try to position and in return for paying up to half of that loan, they get some of that borrower’s collateral plus a bonus of 7%. It’s a normal market function that keeps markets healthy. He mentioned a large liquidation event earlier this year on August 4th, and he noted that liquidators earned 7% of that $3.6M liquidation. On mainnet Ethereum, there are offchain relays like Flashbots that enable a user to get their liquidation transaction to the top of the block. OEV gives liquidators the right to post a price early, making the markets more efficient when it’s done properly. On the call, we had two providers of offchain solutions debate with a developer of an onchain solution.
- 0xMims on a WELL asset listing
- During the intro, Super Delegate 0xMims discussed a proposal that he recently created to add WELL Core Markets to the protocol. A few of the factors that preceded this effort included the token’s liquidity on Aerodrome, its circulating market cap, and the Chainlink price feed for WELL on Base going live. 0xMims followed the Asset Listing Framework, including information on asset decentralization, risk, oracle assessment, etc.
- Switch Moonwell Optimism’s Markets to using API3’s OEV Enabled Data Feeds
- Dave Connor from API3 posted a proposal for Moonwell to switch to API3’s data feeds on the Moonbeam deployment. The proposal outlined the benefits such as increased revenues for the protocol and the technical simplification of switching due to no code changes being required. On the call, Dave gave the case for why API3 and Moonwell would be a good fit. He first described how API3’s OEV works, which gives people who would trigger liquidations on Moonwell the ability to trigger extra data feed updates; this is a key differentiator from some of the other solutions. Oracles trigger data updates based on the percentage deviation generally between the real world and what’s already onchain. Rather than waiting for the price of Ethereum to either fall further to hit a deviation-based update or wait for a time-based update to trigger, searchers are able to see that position and they bid for the right to trigger an extra data feed update. Moonwell would get 80% of the winning bid; API3 would get 20%. He mentioned that the first iteration would go live on Moonbeam markets. He finished by mentioning that their OEV feeds have been live for six months, one of the longest periods for any solution, and that API3 supports every chain in the Superchain.
- Additional revenue stream for Moonwell ecosystem via OEV implementation
- A few weeks ago, RedStone proposed implementing their OEV technology on Moonwell’s AERO market to capture liquidation profits usually taken by third-party bots, redirecting 50% back to Moonwell’s reserves. Successful testing may lead to expansion to other markets, further enhancing protocol revenue. On the call, Kuba first mentioned that RedStone was the fastest-growing oracle in 2024. He also brought up their current partners, including Ethena, EtherFi, Fraxlend, and others, and that RedStone has just gone through the due diligence process on Compound. He discussed the risks involved, including creating bad debt. He stated that RedStone limits the delay to 500ms, as they use the offchain auction mechanism built by Fastlane. The second threat he discussed was hacks and he gave a recent example from Compound when a small code base change was made that distributed rewards. RedStone’s solution requires no code changes; it’s fully Chainlink-compatible. He mentioned that the worst thing that could happen with RedStone is losing the OEV, but never delaying price updates. Kudo commended the idea of an MEV tax (explained by Elliot from Solidity Labs in the next section), but he expressed concern over the idea that it uses gas prices for ordering the MEV transactions - citing the issues with the Chi gastoken from 1inch. He also mentioned the congestion on Base network and how the change could make it worse. He further explained that for all the potential OEV solutions, the market adoption is important; any new type of solution requires the searchers to adapt to that interface and to update their trading bots. He finished by talking about the RedStone product - as a side effect of connecting to RedStone OEV, there’s the possibility of bringing more price updates onchain than what’s enabled by the current situation.
- Capturing OEV in the Moonwell Protocol
- Last week, Elliot from Solidity Labs created a forum discussion around Solidity Lab’s solution to improve how liquidations occur on Moonwell. He noted the current state of MEV capture for the protocol - professional liquidators compete using bots to earn fees by liquidating risky underwater loans - before proposing the idea that Moonwell could introduce a “MEV tax,” charging liquidators for priority access to update price feeds and execute liquidations. Similar to the other solutions proposed, he recommended a phased approach, beginning with a single market before expanding. On the call, Elliot first gave an intro to Solidity Labs and the work they’ve done with Moonwell, including the launch of the protocol on Base and upgrading governance to the multi-chain system that’s currently in place. He explained the proposal for an OEV system that can help the Moonwell protocol internalize revenue that’s normally given to searchers. He mentioned that competitors on Mainnet leave hundreds of millions of dollars on the table every year in terms of liquidations because whenever an Oracle posts a price update, it leads to extractable value that the MEV bots can capitalize on. Solidity Labs is able to create a system that allows the Moonwell protocol to internalize a majority of this revenue. Elliot agreed with Kuba that any new solution requires the searchers to adapt to that interface, and mentioned that they would discuss this change with Flashbots and other relays. He discussed the non-upgradeable, immutable smart contract which has many fallback and safety mechanisms. The initial 30-second time period in which OEV bot operators provide the new price and pay the OEV tax is a parameter that can be adjusted with risk analysis from Gauntlet. It would use the existing Chainlink feeds and it would be fully audited. He welcomed feedback from Gauntlet, Chainlink, or other risk managers.
- Dave chimed in to discuss the parameterizable delay discussed by Elliot and Kuba. The searchers that are waiting for big liquidations actually want the volatility; we tend to see more updates when the market’s volatile. With API3’s solution, instead of seeing bad debt when the market moves rapidly, you’ll actually see more data feed updates.
- Luke replied once more with some data points, not wanting to express an opinion. Regarding Chainlink on Ethereum mainnet, which has been around for six years, it has seen a lot of volatility through Black Thursday and other market events. It has the advantage of being very Lindy. On mainnet, Chainlink will post a price feed if ETH deviates by 1% or more. Whenever ETH is very volatile, all of the MEV searchers start to bid really heavily right before that 1% price feed lands. That means that they’re actually looking at centralized exchanges for prices and when the 1% deviation will trigger a price feed update. On Base, the deviation is 0.15%. In general, Base tends to be a safer network to lend borrowable assets on (against ETH). The main point: despite all of the market volatility, like Black Thursday or stETH depegging or USDC depegging, the biggest lending protocols on mainnet have not incurred significant bad debt. He lastly mentioned that API3’s solution was really interesting because it can post the price before it hits that 1% or 0.15% deviation if there’s a price that people want to post.
- Kuba replied directly to Luke. He questioned whether the length of time really ensures the safety of a solution. He gave an example in the form of Venus acquiring bad debt when the TERRA/LUNA crashed. He believed they were connected to Chainlink, but the price still was dropping so fast that and the market was under too extreme conditions. He thinks that Moonwell should be prepared for that kind of a Black Swan event, even if it’s a 0.001% probability. He also replied to Luke’s question about their data sources; RedStone currently is connected to almost 100 different sources. They query the price from a mix of sources including CEXs, enterprise level data providers like Kaiko, and they also query based on onchain slippage.
- Dave also responded to both Luke and Kuba. He first addressed the depeg caused by Luna, stating that it was actually not caused by the rapidity of the movement. It was caused by Chainink oracles having hard-coded a 10 cent minimum price for Luna. A faster pricing update wouldn’t necessarily have done anything. Addressing Luke’s question about data sources, Dave highlighted API3’s verifyability. It works directly with providers that provide big Web2 enterprise grade clients with pricing data. They post the address of the oracle that they operate so that users can verify that the address is indeed operated by a data provider. Aggregation happens onchain. Users can see an aggregated onchain price, and go see exactly what it’s made up of. Verifyability is one advantage that API3 offers versus Chainlink or other providers.
Other Links:
Be sure to attend the next call on the first Thursday of January!
We host calls on the first Thursday of every month, 17:00 UTC.
Next Call: January 3rd, 2024.