Deep Dive into the Distribution Gateway
The mission of the Minterest protocol is to be the leading decentralised money market in Web3. Minterest’s unique model aligns incentives through innovations, such as the Liquidation Engine*, that generate greater fees and redistribute them all back to users of the protocol.
Minterest bootstraps the onboarding of liquidity by distributing its governance token, MINTY, to users of the protocol in addition to the underlying market yield. Like many DeFi projects, Minterest grapples with the challenge of aligning incentives to drive liquidity for the long-term success of the protocol. This blog post aims to shed light on how Minterest’s Distribution Gateway system provides a solution.
What is the Distribution Gateway?
The Distribution Gateway is a sophisticated contract, meticulously designed to manage the substantial distribution of MINTY during the early stages of the protocol’s life without compromising the overall health of the protocol.
This system keeps track of rewards accrued by each user and ensures their even release over a 12-month span. Consequently, our early supporters benefit significantly, while the influence on the circulating supply is adeptly controlled, granting the protocol the vital time it needs to achieve widespread user adoption and broader token distribution.
The Problem of Lazy Data Storing
Diving deeper, it’s crucial to address a technical nuance inherent to all blockchains – the lazy storage of data.
To minimise gas costs, when rewards are to be distributed to multiple users, DeFi projects (including Minterest) deploy indexes – ever-increasing variables that aggregate rewards. Rather than updating each user’s balances, the distributor modifies only one value – the index. Subsequently, all reward recipients bear the gas costs to deduce their respective reward share.
This method is efficient concerning gas consumption. However, the index doesn’t record the specific dates of reward distribution. As highlighted, the Distribution Gateway requires these dates to suitably release the MINTY tokens over a year. So, how do we navigate this challenge?
How the Distribution Gateway Works
Our answer to the lazy data storage dilemma is a strategic compromise in the precision of token release to the market, yet still within the bounds acceptable by our business model. The Distribution Gateway does not monitor every single token. Instead, it comprises 12 slots, each representing earnings for a month. Should a user remain active, their earnings data for the past 30 days is housed in the pertinent slot. When withdrawal is set into motion, the system computes the amount that can be withdrawn using the formula:
claimableMnt = slotBalance1 /12*11 + slotBalance2/12*10+…+slotBalance12/12
Here, slotBalance12 refers to the earnings of the most recent month.
The internal logic within the contract approximates the number of tokens from each slot ready for release. This method doesn’t trace the exact status of individual tokens but monitors the monthly earnings for a user’s yearly activity on the protocol.
For clarity, consider the following graphical representation that shows the total and available withdrawal balances for a user who earns a consistent MINTY amount each month and actively engages with the protocol:
Earned Balance represents all MINTY earned, both withdrawable and non-withdrawable.
Withdrawable Balance indicates the amount of MINTY that users can withdraw to their wallets.
What are Active and Inactive Users?
An “active user” is one who engages with markets or their MINTY balance at least once within 30 days. This means that a user who does a supply, borrow, repay or withdraw action, as well as stakes or unstakes MINTY in the governance process, triggers an update of the Distribution Gateway.
The Distribution Gateway system works flawlessly for active users. But how about users who deposit assets and then await their rewards, not making any chain transactions for several months?
The Distribution Gateway has provisions for this scenario as well. If such a user decides to withdraw MINTY after months of inactivity, the system gauges the duration (or number of slots) of their absence. All collected rewards are aggregated, and an average value per slot is calculated. This value is then incorporated into the previously mentioned formula to determine the withdrawable sum.
However, a minor hiccup arises. If a user remains inactive beyond 30 days, the UI might display a decline in the withdrawable sum. This usually occurs post the slot transition, roughly every 30 days. This apparent discrepancy arises as the averaging logic employed at the contract level is mirrored on the UI.
For a clearer picture, consider this example:
- On the 30th day of slot 1, a user accrues 10 tokens, enabling them to withdraw 1/12 of this total = 0.833 MINTY.
- By the first day of slot 2, the user’s total earnings amount to 12 tokens. However, due to their inactivity, the averaging logic is activated. The newly averaged earnings amount to 6 tokens per slot (i.e. 12 tokens earned across 2 months = 6 tokens per month), with the total withdrawable sum being approximately 1/12 of the 6 tokens = 0.5 tokens.
This dip might seem concerning initially, but the system rapidly recalibrates. It typically takes between 6 to 9 days to revert to the withdrawal amount observed at the end of slot 1. As a consequence, inactive users might observe the following pattern on the UI:
This is the so-called “saw pattern.” A similar chart will feature on the Minterest user dashboard to offer users a clearer forecast of impending rewards.
The Distribution Gateway has been carefully designed to manage the distribution of MINTY tokens in a manner that is both fair to early supporters and beneficial for the long-term health of the Minterest protocol. We understand the complexities and concerns users might have regarding reward distribution, and this mechanism ensures a balanced approach. We hope this deep dive has shed light on the intricacies and design sensibilities of the Distribution Gateway.
*Note that Minterest’s Autoliquidation Engine has been renamed to Solvency Engine.
24, August 2023
