Adding BTCB/ETH as a votable pool

Adding BTCB/ETH as a votable pool.

I feel this pool is attractive liquidity providers.

  • Attractive to Liquidity Providers
  • Potential for low rent liquidity
  • Increased competition for bBALN pool votes

Your thoughts and comments are appreciated.


I’d be in favor of this, but open to other opinions. It completes the on-chain triangular arbitrage between ETH/BTC, ETH/bnUSD, and BTC/bnUSD, and like you said, attracts lower-rent liquidity.

Something I wanted to be discussed changed/added to this proposal is to think about ETH/sICX and BTC/sICX instead or additionally.

Now the King and Queen are indeed different, but my arguments for these pools are such:

  • There is a lot more sICX or ICX than ETH or BTC on ICX chain at almost any time
  • Anyone using Balanced is at least somewhat long ICX or notionally long ICX even if not right at the moment
  • A big BTC/sICX or ETH/sICX pool can also double up as BTC - bnUSD and ETH - bnUSD liquidity in conjuction with the sICX/bnUSD pool, our largest pool. The stable coin pairs are the bigger fee earners, precisely because they don’t tend to move in sync, so having long/long pairs like BTC/sICX and ETH/sICX that can capitalise on our sICX/bnUSD pool more without having tons of token/stable pairs that people are reluctant to supply for.
  • A quick look at alot of other inflation incentivised DEXs (almost everything thats not UNI) they highly support X/chain token pools in general.

Just wanted to know peoples thoughts on this, would that be something you would supply to or would think people would supply to?
Not to derail the current proposal, since we can easily have both as seperate proposals but wanted us to discuss it overall.


As a bBALN holder and LPer I would love this. However, I have to question if it is in the best interests of the platform. Is it a pool we really need to provide BALN inflation to support.

If made votable, I believe this pool will end up attracting a very large portion of the bBALN vote, as it is a natural choice for LPers, but we will be wasting a lot of BALN inflation for a pool that will be of marginal benefit to the platform and Icon ecosystem.

Personally, I think POL is a better choice when it comes to ETH and BTC related pools. When it comes to voting for BALN inflation, I would like to see more choices for pools based on tokens in the Icon ecosystem such as CFT or FRMD.

1 Like

Some good points all around. Combining both @arch and @CryptoKnight’s general thoughts, we need to ideally strike a balance in terms of what’s best for three primary parties that interact with liquidity pools:

  • LPs
  • Speculative Traders
  • Arbitrage Traders


  • Good for arbitrage traders
  • Not that special for speculative traders because most don’t have BTC or ETH on ICON
  • Good for LPs because low IL and both assets are nice

With this type of breakdown, we can expect almost all of the volume of an ETH/BTC pool to be the result of arbitrage. This is good, but we can possibly do better.


  • Ok for arbitrage traders, but not as good as ETH/BTC
  • Good for ICON speculative traders
  • Ok for LPs because low IL and both assets are nice

@CryptoKnight I see why you would want Balanced to support ICON Ecosystem projects, but imho we first need to focus on growing out DAO Fund, and arbitrage traders are very necessary for that. This is how I see ecosystem tokens for now:

Ecosystem Token / bnUSD (i.e. FRMD/bnUSD)

  • Bad for arbitrage traders, not traded elsewhere, so no arb volume for balanced
  • Good for speculative traders
  • Bad for LPs, high impermanent loss risk (this could be somewhat mitigated with token/sICX instead of token/bnUSD)

Since we don’t get arbitrage volume, we don’t really earn back the money spent on incentives. You can think of BALN minted to pay LPs as a literal cost to the DAO and to bBALN holders through dilution. We should focus on pools that will help us earn that back, and arbitrage is a key supporter of that.


I think you are right about FRMD and most other ecosystem token pools right now. However, I do think the CFT/sICX pool would be a good candidate to add to the voting list, but that is probably a discussion for a separate post.

As for ETH/BTC I am not totally opposed to it, and would probably vote yes and participate in the pool if it came to a vote. However, I think that maybe its something that would be better to add later once the ETH/bnUSD and BTC/bnUSD pools are a little deeper (maybe after a few more rounds with Karma acquiring POL).

I think @arch’s idea of ETH/sICX or BTC/sICX is better and he did a pretty good job of laying out the benefits of that approach.


Quick question: how does their support of X/chain token pools compare to X/Protocol Token pools?

@benny_options & @arch as well:

I’ve been thinking a lot about this. What Arb traders want, what bBALN stakers want, and what LPers want. And feeling a lack of those different voices in discussions around POL or Voting pairs.

Maybe they are here in a gentle way, but I haven’t seen anyone post whole heartedly about increasing POL in a specific pair to boost their arbitrage gains. I didn’t hear anyone complain about sICX/bnUSD or BALN/bnUSD POL ruining their LP rewards.

Maybe it is a result of having the protocol’s position as a higher priority than personal positions? Just some thoughts.

Regardless, back to the topic:

What we want:

  • More liquidity in the DEX
  • Preferably low cost liquidity

What we know:

  • Being a votable pair does not guarantee LPers to our protocol — look at IUSDT/bnUSD pool
  • Having a relatively high BALN reward does not guarantee LPers supply to our protocol in substantial amounts — look at IUSDT/bnUSD pool and the existing ETH/BTC pools

Options this thread has brought up:

  • Do not add new votable pools
  • Add either ETH/BTC OR ETH/sICX and BTC/sICX pools as votable
  • Add all 3: ETH/BTC, ETH/sICX, and BTC/sICX pools as votable

I feel I am in the camp of going for the third options, adding all 3 pools, as I am most interested in seeing how all these new options will effect the voting.

Edit 1: Specifically, I hope that it will create competition for voting pairs and holding bBALN. As well as letting the market decide which LP is the biggest draw.

Edit 2: Alternatively, we could route everything through BALN, and lean on BALN:ETH/BTC/sICX/NEWLayer1s

1 Like

This is 100% of the incentivised LPs on Pancake that involve CAKE.
As you can see other than the heavily supported CAKE/BNB, theres almost nothing.

These are the top 6 pools involving BNB, sorted by multiplier of incentives, everything below that is less than a 2x.

All incentivised ETH related pools

All incentivised BTC pools

ETH/Chain token is hugely larger than any other ETH pair (presumably because Chaintoken/stable is large)
BTC/Chain token is equal to BTC/stable
Both are ETH & BTC/Chain token significantly larger than BTC/ETH

1 Like

Thank you for doing the digging.

So there’s like $335m in bnb:stable liquidity, sheesh! And at 13%…

I haven’t dug deep into pancake, how can they offer such high apy all over the place?

… but that is sidetracking. I feel this proves the point of chain token/pair dominance


They bundle the rewards + the real trading fees (what they call LP Rewards in the image)

But I do believe CAKE is quite inflationary indeed


Osmosis in the Cosmos Ecosystem kinda does this. It’s an interesting idea, because if we pair everything to BALN, we can use DAO Fund BALN to pair against assets purchased with bnUSD. Allows faster scaling I’d say, and in theory we could issue more BALN to pair against purchased assets if it were advantagous.

This is a fair point, but these pools do accrue a non-zero amount of votes, almost like “vote leak”. Therefore the more of these lesser-supported pools we have, the more leakage there will be. The “vote leak” currently amounts to ~2.8%, not too bad, but wouldn’t want it much higher.

Considering we’re leaning toward BTC/bnUSD as the next POL, my thought on this proposal would actually be to add BTC/sICX as a votable pool to see how much traction it gets. It’s at least worth trying and does provide an on-chain triangular arbitrage.

1 Like