AIP7: Creation of Contraction Fee & Incentives for buyers

This proposal ideates upon the concept of a contraction fee which is a special kind of fee done for sellers who try to front-run bond purchasers. The proposal here suggests three different solutions, each of them innovative with various consequences.

The problem being addressed here is that there are market manipulators who are aware that during every bond redemption cycle, there will be people who will buy bonds and in effect push the price of ARTH up. Since the time of purchase is known and the volume is known as well, the frontrunners can easily time their buy and sell orders. They’ll basically buy the dip and after bond purchasers have pushed the price up, they will immediately sell which totally reverses the efforts done by bond purchasers.

Note that this fee/incentive is only applicable when we are below 1$

What is a contraction fee?

The contraction fee is a fee that’ll only be enabled to sellers depending on any negative price that sellers make when we are below the peg. The fee is determined by three factors;

  • How far we are from the peg (the further below the peg, the more the fee)
  • How much of a negative impact is the seller making. (The bigger the sell order below the peg, the more the fee)
  • Is the 12hr TWAP below the 1$ mark. The fee will only be applicable to orders if the 12hr TWAP is below 1$

This is just a basic post that explains the idea to penalize sellers and is open for further discussion. Further, this idea can also be extended to reward buyers below the peg as well.

Implementation #1: Forking Uniswap and creating a custom pool that applies the fee

This is the least intrusive option. It requires no hard forks and it means that we can create a custom Uniswap pool where the incentives are based more towards the peg. Sellers who sell below the peg can get charged in ARTH and buyers who buy can get rewarded in MAHA.

The fork can further borrow the liquidity from Uniswap.

Some very rough but similar ideas:

Implementation #2: Frontrun sell orders and burn the ARTH before the sell order is executed

The team has created a working implementation of a smart contract that can fee a sender if it finds a pending transaction that is basically a sell order on Uniswap.

This code is innovative however it requires a hard fork of the ARTH coin, which can be very hard to execute.

Cons: Will require a hardfork and may not 100% work

Implementation #3: Embed the fee directly into the code

This implementation will again a hard fork of ARTH, wherein the ‘transfer’ function is modified to implement the sales fee whenever a transaction is made to Uniswap. However, modifying the “transfer function” is a bit dirtier and it can have possible unintended long-term consequences. Moreover, this requires a hard-fork of the token.

Cons: Requires a hardfork of the token

These are the three implementations that allow the protocol to basically create better rules for the price action when we are below the peg.


Im not a fan of implementation 2 or 3 in aip7, but I think implementation 1 is a step in the right direction, as long as we can figure out how to reward ARTH buyers below the peg. I Think having a slight dump when the 12hr twap goes above 1$ is inevitable if we make that the point where you can sell with no penalty. So there needs to be a counter measure in place that will attract buyers below a certain price.


  1. People buy ARTH at .92 with intentions to make a quick flip
  2. 12hr twap hits 1$
  3. people that have been waiting to sell with no penalty automatically dump bringing the price back down to .94
  4. counter measure comes into play to offset this (within the same epoch), which will allow the protocol to go further into expansion instead of see-sawing back and forth, from contraction to 1 epoch of expansion then back to contraction.

i cant think of a good recommendation for a counter measure right now. :frowning:

But that first epoch after a contraction is important because not only will we have “quick filppers” looking to cash out, but there will be bond buyers that need to be compensated, and potential expansion rewards that might go out before the demand needs it… all of which could present tremendous downward pressure that would send us right back into contraction, most likely before the debt is cleared.


I don’t think this is the right path to pursue. Forking and changing the code for better results on Uniswap is a bit myopic. We need a system that can handle the supply and demand of ARTH when it expands past Uniswap to Sushiswap, 1inch, Binance, and other centralized exchanges. The more we tweak the code and increase the complexities, the more unintended consequences the team will encounter.

I would like to use the US tax code as an example. It’s a monstrosity that’s thousands of pages long and keeps growing. It’s far from elegant in its approach and no one outside of the professionals have read through it. Part of me thinks that the complexities are intentionally don’t to keep people dependent on tax accountants and attorneys.

Anyways, I believe we just need to change the incentive to adjust people’s behaviors. What I learned from reading/watching “Freakanomics” is that the world is run on incentives. If done well, we can predict/dictate how people will behave. I will put up another proposal on how we can further tweak the incentives.

I’m a fan of Freakonomics as well :slight_smile: I think the uniswap fork won’t really make things complicated in that aspect; To the end-user it’s just a simple swap transaction. However, what it does is that creates better incentives for staying to the price peg.

ESD for example is currently facing issues with the new kinds of demand that exists outside of just Uniswap. For that matter it is valid to ascertain the importance of a pool that scales beyond Uniswap, Sushi etc…

However the Uni fork is addressing an issue with sellers who dump on bond purchasers which I find very hard to resolve unless we create incentives that directly impact the buying/selling of ARTH.

This is a screenshot from the whitepaper to sort of have a glimpse on how this could work.

This is possible yes. However as a first draft we can use the 12hr TWAP and see if later on whether we should use the spot price or use the 1hr TWAP instead.

With the custom pool option, would all trading cease on uniswap and only take place in the custom pool during contraction?

Uniswap trading will always continue to happen. Only that the liquidity will be incentivized to be on the Custom pool more.

We’d want to spread out liquidity so that more is on the Custom pool. It could look something like 5% on Uniswap, 5% liquidity on Sushiswap, and then 90% to the custom pool.

Incentivizing more liquidity in one pool (the custom one) will attract more volume as well and it can further affect the price on other pools (Uniswap, Sushiswap) through arbitrage.

Yes, the world runs on incentive structures, including human society and the rest of nature! This is a big part of my passion for DAOs - the ability to architect incentive structures that motivate participants to fulfill a project’s value proposition. Blockchain and DAO are helping us to participate in the progression of life’s evolution in the way that humans cooperate, by emulating the distributed nature of DNA and the deterministic cellular execution of that code, adaptable through the consensus mechanism of procreation and incentivized through the ecosystem by the various stages of the carbon cycle relevant to each player’s needs.
We are just in the stage of fine-tuning this carefully designed incentive structure until the best interest of each player aligns with the value proposition of MahaDao. I agree if anyone can benefit from gaming the protocol then they will. Must create an incentive structure where the favorable behavior is the most profitable. But must also maintain a balanced, reciprocal nature and be thermodynamically sound. Very tricky. Kudos to all of your excellent work!

:joy: StrongHands { onlyHigher() } :rofl: :rofl:
can’t believe we didn’t think of that already!

Agree with your assessment that when the price gets to the $1 mark there will be a dump, however, that may not be as heavy in volume moving forward (when $ARTH stablizes as it proves it can hold to $1) as it will be for this next pass of the $1 mark, as it is reasonable to expect some portion of $ARTH holders expected it to reach $1 (sooner) and are holding for that moment to dump.

While we need to think about short-term and long-term incentives, thinking long-term will likely result in the best outcomes for the project.

What does the project need to do to establish the $1 GMU peg?

risk if $ARTH cannot establish a peg to $1 as a value coin all the other goals are a distant secondary IMHO.

The extensive time spent below $1 is causing pause from the market to move into $ARTH, if $ARTH is unable to establish the $1 peg there could be fear and a mass exodus at some time in the future.