Be wary of any issues related to this comment

Is the plan to do that unraveling of CurrencyPair slices in a separate PR?

Is the plan to do that unraveling of CurrencyPair slices in a separate PR?

@toteki wdym? if you mean the piece that sets the price for voting, those changes are in oracle.go

@toteki wdym? if you mean the piece that sets the price for voting, those changes are in oracle.go

The stuff in the binance provider that still relies on a strict Ticker,Candle,Ticker,Candle... ordering of the input slice - assuming it gets separated back into two functions will it be a different PR? possibly by @RafilxTenfen

// SubscribeTickers subscribe all currency pairs into ticker and candle channels.
func (p *BinanceProvider) SubscribeTickers(cps ...types.CurrencyPair) error {
	pairs := make([]string, len(cps)*2)
	iterator := 0
	for _, cp := range cps {
		pairs[iterator] = currencyPairToBinanceTickerPair(cp)
		iterator++
		pairs[iterator] = currencyPairToBinanceCandlePair(cp)
		iterator++
	}
	if err := p.subscribePairs(pairs...); err != nil {
		return err
	}
	p.setSubscribedPairs(cps...)
	return nil
}

@toteki wdym? if you mean the piece that sets the price for voting, those changes are in oracle.go

The stuff in the binance provider that still relies on a strict Ticker,Candle,Ticker,Candle... ordering of the input slice - assuming it gets separated back into two functions will it be a different PR? possibly by @RafilxTenfen

// SubscribeTickers subscribe all currency pairs into ticker and candle channels.
func (p *BinanceProvider) SubscribeTickers(cps ...types.CurrencyPair) error {
	pairs := make([]string, len(cps)*2)
	iterator := 0
	for _, cp := range cps {
		pairs[iterator] = currencyPairToBinanceTickerPair(cp)
		iterator++
		pairs[iterator] = currencyPairToBinanceCandlePair(cp)
		iterator++
	}
	if err := p.subscribePairs(pairs...); err != nil {
		return err
	}
	p.setSubscribedPairs(cps...)
	return nil
}

Right! The comment you referred to - Yeah, I'd rather do that in a separate PR since this one is already pretty lengthy and needs to be well-reviewed

Right! #592 (comment) you referred to - Yeah, I'd rather do that in a separate PR since this one is already pretty lengthy and needs to be well-reviewed

Let's do that + "refactoring our anomaly detection logic for these candles" in a separate PR and then we can finally close #542 @adamewozniak @RafilxTenfen ?

LGTM. Would like to see an approval from @toteki too prior to merging, but otherwise, this looks good.

My approval's already in (since my original notes were just naming/comments I submitted it as an "approve" and not a "request changes")

e: The error -> 0 change on vwap looks good too