Fee Handler Management Issues

Proposal Discussion WIP: BIP
#1

Hi All

I was speaking to some community smart contract devs and they raised an issue with how fees for the Balanced DEX are currently handled. Right now, it requires a ton of manual maintenance. Here are the two key maintenance issues:

1.) Creating routes: When a new token is added to the Balanced DEX, fees in the form of that new token are sent to the Fee Handler. But currently, they will just sit there until a specific route for that token is defined. For example, VOID tokens just sit on the Fee Handler. I believe FRMD also. A trusted account needs to set a route of VOID → bnUSD → BALN in order for the fees to be swapped to BALN and distributed to stakers/DAO Fund. So, if a route is not created, BALN stakers and DAO Fund get nothing.

2.) Triggering routes: This is less of a problem as the first issue. Right now, IF a token has a route, somebody must call the “route_balances” method. Anybody can do it, but of course it costs some gas. It must be called once per token type on Balanced (i.e. 5 times if the contract has VOID, FRMD, OMM, FIN, and CFT). As more routes and more tokens are added, this will continue to increase time and gas cost for whoever writes a bot to handle this.

I’d say the first point is the biggest issue, and we came up with a proposed solution, open to suggestions though:

1.) Only charge fee in quote token: Available quote tokens are sICX, bnUSD, IUSDC and USDS. The quote token is the right-side token in a pair, and Balanced limits this to the aforementioned 4 tokens. If the fee is always charged in the right-side token only, we’ll never need any new routes. For example, VOID/bnUSD (bnUSD is quote token), we don’t need a new VOID route to get VOID → BALN, we just charge a fee in bnUSD and keep it there.

Downside of this strategy is that the only time fees are used to buy BALN is for pairs that are token/USDS and token/IUSDC.

2.) Option 1 + route sICX into BALN: This removes the downside of option 1, but adds the potential downside (depending on your opinion) that fee distributions won’t include sICX anymore, only BALN and bnUSD. DAO Fund will also stop accumulating sICX and only accumulate BALN & bnUSD. So for example, FIN/sICX pool, fees would be charged always in sICX

Neither of these really solve the “trigger routes” issue, but that transaction can be piggy-backed on claiming network fees as a solution. So when somebody claims their network fees, it can also trigger the routing + distribution of any tokens on the Fee Handler contract. The primary issue is route-management, outlined in the first issue.

3 Likes
#2

I will vote for option 2, which seems to support BALN price more. Anything to support our token price is better.

3 Likes
#3

Option 2 100% in my eyes. Adding sicx as another additional token for constant baln buy pressure soubds great. Im sure come bull makret with added trading volumes it can be a real positive for baln! I trade my sicx fees for baln regardless this will save me a step :grinning:

3 Likes
#4

Thats quite a puzzle but I think some good solutions were mentioned for the route creation problem. I see that the current method is not something we want to keep as it is not scalable and depends to much on trusted users.
I think both option 1 and 2 are good but personally I like option 1 a tiny bit more. The buying of BALN with fees is a nice cherry on top but not a core feature. I have not done any calculations on this yet but I don’t think the baln price is boosted much due to this feature during this bear market. Once trades go up the value of BALN will go up either way. The DAO can aquire BALN multiple ways but the influx of sICX is more restricted and I don’t know if we should stop this. While accumulating the sICX the community can always decide to use this to buy BALN at a strategic time to have a similar effect.

But all in all I dont have a real preference and therefore I would say option 1 as it is the ‘cleanest’.

I do also like some of the suggestions mentioned on the Discord server. As AlgoChain mentioned the creation of a path during the pair creation could be an entire diffrrent approach.

2 Likes