AIP 37: Fee discounts for sAST holders using web app


The upcoming web app (AIP 30) will provide a new place to swap tokens using AirSwap without being routed through an aggregator. This will give us more space for fees whilst maintaining makers’ abilities to offer competitive rates. This proposal suggests a variable fee structure that is dependent on the sender’s staked AST balance to boost the utility and desirability of staked AST.

The proposal also suggests the creation of a new staking contract to optimise gas for its balanceOf function as a prerequisite.


  • The AirSwap fee charged when using the new Web App should be discounted depending on the sender’s sAST balance
  • Discounts will be exclusive to users of the Web App to incentivise its usage
  • Discount rates should be configurable - as a starting point this proposal suggests a smooth curve up to a maximum fee discount of 50% when 100k AST is staked
  • A new staking contract may be required for gas efficiency



The fees we are already planning to set for the web app must enable makers to quote competitively. A discount therefore makes trading on AirSwap favourable for sAST holders compared with other DEXes. This should help to:

  • Give additional utility to sAST, increasing number of stakers and growing the valuable governance community
  • Increase trading volume on the web app
  • Encourage community use of the AirSwap web app, making us more aware of its benefits and issues

Timing - why now?

  • The web app is currently under development, and to properly implement a different fee when using the web app than when using an integration we will need to update the swap contract
  • Because the contract will ideally need to be changed anyway, we should consider this fee related update at the same time.

Arguments against:

  1. Gas used for all trades will probably increase.
    • The increase will needs to be evaluated, and the implementation should minimise the increase for MetaMask Swaps and other integrations that do not benefit from a discount.
    • It has been noted in particular that currently sAST's balanceOf method adds up all stakes and is quite gas intensive, so balanceOf may also need to be optimised as a part of this AIP - existing stakes could optionally re-stake on a new contract in order to benefit from the discount.
    • note that mid/long term, layer 2 impacts on gas prices should be considered.
  2. Added complexity:
    • for makers
    • in contracts
    • in front end code
    • for users (could be mitigated with careful design)
  3. Discounting fees reduces pooled rewards for sAST holders who may not benefit from the discount if they don’t trade on the web app.

Discussion / notes

  • Various options for discount approach to be evaluated for gas use:
    • smooth curve similar to pool contract with slope and max parameters (currently proposed)
    • stepped discount thresholds
    • single “no fee above this amount” threshold

Some quick thoughts -

Would it be a simpler set up to implement this in the form of a fee rebate? e.g. set aside a portion of the fees (equivalent to the discount) generated into a different Pool contract. At the end of each month, run a tally of sAST held by each participant throughout the month and activate claims based on (sAST x volume traded) / SUM(sAST x volume) as rebate to all traders

Also thinking about consolidating AIP34 with this, where maker fee rebates would then fall under the same category and included into the sum of (sAST x volume traded)

Pretty much means we want people to hold asts in order to get discount of fee right? I think this is a good idea.

1 Like

Would it be a simpler set up to implement this in the form of a fee rebate?

Possibly, although I’m not sure how you would prevent the (admittedly unlikely) chance that points claimants could claim enough so that rebates couldn’t be paid, and I’m also not sure how this would work when fee pool consolidation to stables (AIP 26) kicks in.

I personally think the benefit would be more tangible if it could be applied immediately, i.e. “If you stake AST, you’ll get better value trades”.

1 Like

Yeah, I think it is better to get discount immediately.

I’m thinking of a slightly different setup which works in tandem with pool consolidation. Each time a consolidation event occurs, a % of the pool gets sent to a different contract (thus cannot be claimed from). That % is reserved as the rebates.

Agree that an instant discount would feel much more tangible though.

Was further thinking that we could base it on the total sAST held by all parties in the trade (in true p2p fashion). This way, if I’m trying to sell a token and list it on the OTC board, having more sAST favours people who want to trade with me because the fees are lower. We would correspondingly increase the amount of sAST required to be held in order to be eligible for the discount of course.

Another idea I had was to make the fees tied to transaction volumes. That way, when volumes are low, fees are immediately lowered to attract more people. We could even do a negative fee structure where people could even be paid to trade (this would of course mean using AST treasury to pay).

e.g. (arbitrary numbers - could also do it on a curve rather than in tiers)
0 - 100,000 USD: -0.1%
100,000 - 1,000,000 USD: 0.1%
1,000,000 - 10,000,000 USD: 0.2%
10,000,000 - 100,000,000 USD: 0.3%
> 100,000,000 USD: 0.4%

This would be the base fees on which the discount would then apply.

I think the drawback would be really high gas costs though… not sure how practical such a setup would be

I’ve recently been thinking about the differences between offering subsidies to makers vs. takers, and this seems to address a similar issue: a “discount” is effectively a subsidy on a transaction. Although exchanges have traditionally directed discounts towards makers and our discussions so far have focused on this, I think it might make more sense in our situation to be targeting takers so I’m glad to see this topic brought up.

Another possible way of implementing the discount/subsidy might be to fold it into the existing rewards systems, i.e. awarding points based on amount traded and sAST. E.g. (arbitrary numbers): 1000 points per $1000 traded per 1000 sAST – so, someone with 10,000 sAST trading $1000 would get 10,000 points; alternately, someone with 1000 sAST trading $10,000 would also get 10,000 points. This would probably be more like cashback on a credit card than a discount proper. There is less certainty to the benefit for the trader, but what I like about this alternative is the possibility that someone might even make a profit from points accrued net of fees incurred.

yeah might be another way to distribute the rebate similar to my suggestion above - just distribute it as points (I guess would have to be done on a snapshot basis rather than in real time)

drawback as mentioned is that the discounts might not feel as tangible as applying a straight discount,

If using trade volumes to reward points, will also want to watch out for wash trading, unless we can somehow ensure that the claims from point generation from trades will be less than the protocol fees they pay

1 Like

Frankly, i like the agrimony ideas but i also like this AIP proposal as it is now, proposed by graypixel. Now it looks simple and clear.

  1. Add the fees rebates for takers that are using AirSwap web app
  2. Fees rebate depends on taker’s sAST balance
  3. Gas spend increasing issue for the MM takers (because of additional sAST 's balanceOf method call) could be partially resolved by optimization of sAST 's balanceOf method.

My proposal about the option 3:
If we know the MM router address could we just avoid the sAST 's balanceOf method call in case if the swap is done through MM router and don’t make any rebate? We should call the sAST ‘s balanceOf method and make the rebate only in case when the swap done through AirSwap WebApp, because we want to give discounts only for sAST holders that are using our WebApp but not to everyone. We could make this “rebate excluded addresses list” easy to upgrade and add new routers’ addresses in future. This logic could be used for all future integrations (like upcoming 1inch integration).
P.S. We can also modify that with setting “rebate excluded” (boolean value) and AirSwap fee amount (integer value) for each router address separately.

1 Like

Yes, good points.

This is what I meant when writing “we should also be able to skip the balance check for MetaMask swaps so the impact should be less there.” but the extra detail is useful