We realized that we were not configuring the oracle when it was forced. This left us in a weird state, because if it was forced and it hadn't been configured before, it couldn't be reconfigured through addOrModifySupportForPair (on the aggregator).

The only thing to do, would be to go to the underlying oracle, and configure it there. This was not a big issue, but it was a UX problem

We are now implementing forceOracle. This will allow admins to force a specific oracle, for a specific pair of tokens. When an oracle is forced, only other admins will be able to set a new oracle for the pair.

We are doing this so that if an oracle with lower precedence is better for a specific pair, we can adjust

We are now adding the possibility to set pair-specific mappings config. The idea is that we will check if a pair has some specific mapping set. If it doesn't, then we will check the global config

We are now increasing the size of the storage variables, basically because we can. Since we have a storage slot (256 bits) to spend, we can increase the size of each var

We increased period from 16b to 32b and gasPerCardinality from 32b to 104b

Note: we are leaving 112b for a next PR

We are now just simplifying quote for the Transformer Oracle. Instead of having multiple if/else statements, we simply transform the input if needed, and then transform the output if needed

If a token were to have decimals between type(int8).max < decimals <= type(uint8).max, then we would overflow. By using int16, we can avoid this problem

Before this change, we were able to configure the max delay allowed for Chainlink feeds. The thing is that for all networks, the max delay was 24hs 😅

I went over most Chainlink feeds and in fact, the max delay is 24hs. But, at the same time, maxDelay was mutable, so we were reading storage once for each read feed. And we could potentially read 4 feeds per pair

So the idea is to simplify everything by just hardcoding the max 24hs delay. In an ideal world (alpha drop), we would use the actual feed heartbeat instead of a max delay that covers all feeds

Before this change, we couldn't quote two tokens that mapped to the same address. It would work only if they had their own individual feeds

So the idea here is that if two tokens maps to the same address, then we consider them the same, and we will quote 1:1. We should now be very careful in what we map to other addresses

We are now making a change so that plans are stored for the mapped version of a pair. This has a few benefits:

1. If a register the pair WETH/DAI, then it will associated to ETH/USD
2. This means that WETH/USDT already has a plan calculated
3. If we remove the mapping USDT => USDT, then all pairs X/USDT will stop working, until they are reconfigured

Note: if two tokens are mapped to the same address, then we will use their original version. This is so that stablecoin to stablecoin pairs used their feeds, and we don't assume that they are 1:1

We are now doing a few things:

• Removed the dependency to mean-finance/dca-v2-core (will allow us to avoid circular dependencies)
• Updating the package version
• Updating the docs to our new format

Thanks to @0xged , we realized that we had a corner case where the oracle wouldn't work as expected. This scenario could happen if we removed a mapping (to USD or another token) and suddenly a pair lost support.

In that case, the pricing plan was already set, and we couldn't remove it by reconfiguring the pair (because it reverted). With this change, we can now lose support