The protocol's functioning heavily relies on the assumption that auction configuration cannot be set for the next auction as long as the current auction is underway.

1. Call `setAuctionConfig` with valid `_config` and `_config.startCooldown` (say 2 weeks)

2. Successfully call `startAuction`.

1. Note this maybe called by anyone as long as `config[auctionId].starter` is `0x0`

2. This will increment the `_currentEpochId`.

3. Call `setAuctionConfig` within the cooldown period.

1. In `EpochLib::isActive`, `info.startTime <= block.timestamp` will evaluate to `false`.

2. A valid configuration maybe set for the next auction in current auction's cooldown period.

This will have impact have an inadvertently affect **multiple** functions throughout the contract.

​

Just as **one such example**, consider the function `SpiceAuction::removeAuctionConfig`. *After following the steps as described above*, you call `removeAuctionConfig`, then:

​

1. `configSetButAuctionStartNotCalled` should be set to `false` as per the steps we took thus far (we set the config and called `startAuction`).

2. The line `auctionConfigs[id+1].duration > 0` will incorrectly set it to `true`

3. This will then incorrectly delete the `auctionConfig`but, let the `epoch` untouched! This is intented state.

​

Here, the assumption that an auctionConfig cannot exist for `id+1` is rendered false. Note this was one such example.

Manual Review

1. Rethink the conditions in `SpiceAuction::setAuctionConfig`.

2. Change the condition for `configSetButAuctionStartNotCalled` in `SpiceAuction::removeAuctionConfig` to not rely on `auctionConfigs[id+1].duration > 0` but, `epochs[_currentEpochId].startTime > 0` perhaps.