Create dNDX, a dividends token for Indexed fee revenue

Create dNDX, a dividends token for Indexed fee revenue

The repository for dNDX and the timelock contract can be found here. The README has a more in-depth explanation of the mechanics than this thread.


This is a proposal for creating dNDX - a dividends token to distribute fee revenue from Indexed Finance to users who stake NDX tokens. It contains a description of the mechanics of dNDX as well as some open questions about how to configure it, as there are several configuration options which we must decide upon prior to deployment.

This proposal involves only dNDX and the configuration we will use to mint it. I will wait a couple of days for people to discuss different configuration parameters for this contract before submitting a Snapshot with some of the more popular options. This does not require an on-chain governance proposal, as there is nothing the Indexed timelock needs to do for this to be created.

There will be one or more on-chain governance proposals for two related subjects: adding exit fees to the core indices, and setting a buyback contract as the exit fee recipient, but the latter hinges on the results of this proposal.

Timelock Contract

A timelock contract will be used to lock up NDX in exchange for dNDX. We will set a minimum and maximum duration that NDX can be locked for. Users will select their own lock duration - as they increase the duration of the timelock, they will receive more dNDX for each NDX they lock. In order to withdraw the NDX that was deposited, the user will need to burn the dNDX they received.


It is important that by distributing revenue from the protocol we are not simultaneously making governance more difficult. To address this, the timelock contract has a mechanism to allow users to maintain voting power after a deposit.

While NDX tokens are locked, they will be held in a specific contract for the user who made the deposit, which allows that user to delegate their voting shares. This is unlike most other contracts users could put their NDX into, in that it does not remove their ability to participate in governance or delegate representatives to do so on their behalf.

This will not significantly affect the cost of interacting with the timelock contract, as it uses a create2 call that selfdestructs every time it is used. The overall gas increase is something like 15,000 per call.

Early Withdrawals

Deposits can be withdrawn prior to the unlock date if a fee is paid. The contract will be configured with a maximum fee, which is paid if the deposit is withdrawn at the exact time that it was made. The fee is reduced proportionally to the fraction of the lock period that has passed; if you withdraw halfway through the lock period you set, you will pay a fee that is 50% of the maximum.


This lock-up system has some benefits beyond the obvious ones for dividends in general:

  • Users who most believe in the future potential of Indexed will receive the greatest share of revenue.
  • Holders who want some kind of earnings for their NDX will be incentivized to lock it up in a form that maintains their voting power rather than put it on the market where the voting supply would be reduced.
  • Because the default behavior on a deposit is to immediately delegate the tokens to the depositor, every NDX staker will also be an eligible voter.
  • Because dNDX is a productive asset that the user receives upon deposit, it could be considered a kind of loan. If a user believes that the value of dNDX will decrease, or they need access to capital, they could sell the dNDX on an exchange and then repurchase it when they wish to withdraw their NDX.


dNDX is a simple dividend-bearing ERC20 token. It is configured with an underlying token, which can be any other ERC20, that is used as the actual dividends payment token. There is a public function disbursePayment which transfers the underlying token from the caller to the contract and disburses it as dividends.

Dividends are not immediately transferred to the dNDX holders, as that is prohibitively expensive. Instead, internal records are kept regarding how much each user is owed, and there is a public collect() function which anyone can call to claim their pending dividends. Dividends may be withdrawn at any time regardless of the timelock for the deposited NDX.

Example: If Bob has 50 dNDX and Alice has 100 dNDX, and 30 DAI are distributed, Bob will be able to claim 10 DAI and Alice will be able to claim 20.

This is not vulnerable to timing exploits: if you receive dNDX, you will not receive dividends from previous disbursals; if you send dNDX, you will not lose dividends you’d accumulated before the transfer.

There is one drawback to this type of contract, which is dust. Every time a disbursal is made, some dust will accumulate in the contract. To be precise, the amount of dust that accumulates is:

((amount_distributed * (2^128 - 1)) % dndx_supply) / (2^128 - 1)

Generally speaking, this amount should be negligible; however, there is another source of dust, which is amounts of dNDX that are too small to ever be worth claiming the dividends for. If a large number of accounts hold miniscule balances of dNDX, they may never actually claim their dividends because they are simply not worth the gas, meaning some amount of the payment token is permanently locked.

It may be a good idea to add a minimum deposit to the timelock contract to reduce this dust buildup, as hiring a full time maid would be a poor use of the treasury’s funds.


Assuming that the community is on board with this style of revenue distribution, we must select several parameters.

Minimum Lock Duration
The minimum period of time that tokens can be locked for. When tokens are locked for this duration, the depositor will receive 1 dNDX for every NDX they deposit.

Maximum Lock Duration
The maximum period of time that tokens can be locked for. When tokens are locked for this duration, the depositor will receive 1 + max_bonus_multiplier for every NDX they deposit.

Maximum Bonus Multiplier
The multiplier for a deposit with the maximum duration. When deposits are made, the depositor will receive a bonus multiplier calculated with the formula:

max_bonus_multiplier * (lock_duration - min_lock_duration)
/ (max_lock_duration - min_lock_duration)

So for example if we have min_lock_duration = 1, max_lock_duration = 3, max_bonus_multiplier = 2, then a deposit with duration 2 would get a bonus multiplier of 1, so 2 dNDX would be minted for every 1 NDX deposited.

Maximum Early Withdrawal Fee
The maximum fee for an early withdrawal, paid when tokens are withdrawn at the exact same time as the deposit was made. The actual early withdrawal fee paid is calculated with the formula:

deposit_amount * lock_time_remaining * max_early_withdrawal_fee
/ (lock_duration)

For example, if the lock duration is 60 days and 30 days have passed, a maximum early withdrawal fee of 50% would mean the user loses 25% of their deposit.

It is important that the maximum bonus multiplier and the early withdrawal fee be calibrated relative to eachother to prevent a situation where we incentivize users to set a long duration for their deposit in order to get a higher share of dividends with no intention to wait for the full timelock. As such, I think we should set a very high early withdrawal fee, perhaps 50% or more.

Dividends Payment Token
The token that dividends are paid out in. It seems that the community has generally determined that this should be either DAI or NDX, but it can technically be any ERC20. This is a permanent decision, as the contracts are not upgradable.

The argument in favor of DAI is that dividends paid out in a currency asset rather than a speculative one would make for more stable distribution and generally be “cleaner”, as the value of the dividends would not change depending on how long users wait to collect them. If dividends were paid in DAI, it would be trivial to measure the value of dividends being paid out, and it may attract a broader set of users.

The argument in favor of NDX is that token buybacks would increase the price of NDX by some amount, and that even if stakers simply sold it on the market, it had to be bought from the market to obtain it in the first place, so the net effect would still be positive on the price unless all dividends were sold like this. It would also allow stakers who believe in the long term success of the protocol to accumulate NDX and thereby voting power.

Personally, I am in favor of DAI, but based on the community discussion I’ve seen and the last unofficial poll we did, it seems NDX will win out, and I don’t see much of an issue with that. If NDX does win here, I will edit the timelock contract so that whenever early withdrawal fees are paid, they are directly redistributed through dNDX. If we select DAI, I will edit the contract so that governance can set an address to transfer withdrawal fees to, and we can set that to the buyback contract once it is deployed.

Minimum Deposit
The minimum amount of NDX that can be deposited. This feature does not currently exist in the contracts, but would be trivial to add. It would reduce the buildup of dust, but may leave smaller holders feeling excluded. We must decide whether to add a minimum deposit, and what it should be if we do add one.


As a fan of Dividend Reinvestment, I would prefer ETH or NDX over a stablecoin.

Generally, I like this strategy w/ a timelock - it incentives the right action. As a (possibly impossible) thought, I do like what OlympusDAO is doing with rebasing & staking. If that type of mechanism is possible here - allowing you to increase your NDX holdings over time and then paying out dividends in a stablecoin, I would be very interested.


I like the idea, my personal preference would be for DAI as well. Where would the early withdrawal fees go? I didnt see that mentioned.

1 Like

If we choose something other than NDX as the payment token, fees would be transferred to the buyback contract (meaning we’d sell the NDX charged as early withdrawal fees at the going market rate for the payment token, then redistribute it as dividends). If we choose NDX as the payment token, we’d just directly distribute it as dividends when the fees are collected.

I’m not familiar with OlympusDAO but I will take a look.

1 Like

I also prefer NDX or ETH over DAI.

With NDX, I think it would be relatively easy to implement autocompounding and also provides a price support for NDX itself.

1 Like

Thank you for the proposal.

Regarding lock duration. It might be a good idea to consider setting a minimum duration where rewards > gas costs. Might be hard to estimate, but would protect new participants from making bad decisions. Maximum duration, 1 year?

I prefer dividends to be paid out in NDX. That way the protocol wont be a seller of NDX. Besides (quite unsure of this) paying out dividends in DAI might make it look more of a security.

If we choose something other than NDX as the payment token, fees would be transferred to the buyback contract (meaning we’d sell the NDX charged as early withdrawal fees at the going market rate for the payment token, then redistribute it as dividends). If we choose NDX as the payment token, we’d just directly distribute it as dividends when the fees are collected.

I wonder if it would be possible to have an option where if NDX is the payment token, 50% of the withdrawal fees get burned. I’ve seen a lot of people suggest some sort of burning mechanic for NDX, and this seems like a perfect way to implement that.

I think we should avoid any kind of token burn, as we have a limited supply and a static quorum (though we could change the governance contract I suppose).

I’m not sure that using NDX would change that, but it is an interesting point.

1 Like


great proposals.

I think, it is very important that the design of dNDX token will not prevent the compatibility of the token.

Good examples are auto-compounding token like xSushi or bBADGER, where the “native” token is staked and the staked token ist used for compatibility in other protocols like bancor or aave.

Also those staked token are eligible for vorting.

The deposited NDX will still be usable for voting, but dNDX would not. The main drawback to this design is the lack of compounding interest, but IMO it creates better incentives by requiring a lockup to receive revenue, and you could still compound the interest yourself by using the dividends to buy and lock more NDX.

1 Like

I prefer dividends to be paid in ETH.

Just like vbnt burning, we can create a contract for anyone who can execute it to sell the tokens in our revenue treasury to ETH for dividend payment, and at the same time give the executor some bonus in NDX.


Hi, very good idea !
I personnaly prefer dividends to be paid in DAI, I think that it will be more “clean” to not use a speculative token for dividends.

for the other criterias :

  • minimum lock duration : 1 week
  • maximum lock duration : 1 year
  • minimum deposit : 10 NDX (1k$ when NDX will be at 100$ next year :wink: )

I like this proposal! I was leaning towards NDX buyback and distribute, but I am not sure how impactful that will be with the upcoming wintermute loan. I guess we’ll have the option to decide via Snapshot?

Yeah this will be an option in the Snapshot proposal. I’m waiting to submit it until we have a few different config options people seem on board with, then I’ll create the proposal with a few permutations of them (e.g. NDX/30-360d/5x Max Bonus/50% Max Fee)

This is a well thought out proposal that looks to bring long term value to NDX.

Our recommendation is for rewards to be paid out in NDX.

A 50% early withdraw penalty fee seems hefty, but it will definitely ensure long term alignment which is the goal here.

Im also in favor for the rewards to be paid out in NDX.


dNDX should be paid out in NDX-ETH uniLP tokens.

  1. Protocol uses fees to buy 50% eth, 50% NDX and adds it to uniswap LP.
  2. NDX stakers accrue uniLP tokens (instead of dai or ndx).

This way ndx stakers are paid out in both ndx and eth (compromise) and you incentivize ndx liquidity.


I like this one, but the average user will find it a bit complex.

Zapper could simplify it or Indexed could automate the ‘add/remove liquidity’ portion too, right.

I actually like this one a lot - I’d be open to UNIv2LP or SLP tokens for simplicity.