[BUG] Volume

[joeykrug]

Volume has been broken for a few weeks, way too high, dunno why

[nuevoalex]

In the update-volumetrics function in AN the resulting value is not converted from attoETH to ETH. The volume stored in the DB is in terms of ETH. Since there was no original migration for this value either we can't just trivially modify any getters to convert the value (since it is currently a sum of attoETH values and ETH values).

We need to write a migration script to regenerate this value from the trades table and either:

• store it as attoETH then convert to ETH in any getter
  or
• store it as ETH

In the interest of ease for v1 I'd recommend the second approach. For v2 anything we store should be in on-chain / atto units.

[joeykrug]

Sure let’s store it as ETH

[ryanberckmans]

I haven't looked into this, but it seems you guys are reporting that my recent volume fix PR AugurProject/augur-node#777 is handling units improperly.

Note that the fix for this will require a DB reset. [Edit: Alex suggested a fix migration which works]

My PR expects that markets.volume and outcomes.volume are denominated in ETH. Suggest we keep this, so the fix would be converting into ETH when calculating incremental volume.

The fix can probably be entirely isolated to the pure function volumeForTrade.

@nuevoalex if you explain the correct conversion, I'm happy to open a fix PR.

[nuevoalex]

It should be doable without a reset. We can just rebuild the volumes from the trades table in a migration

[nuevoalex]

Took a look at the code again and its actually a bit different than attoETH vs ETH. The values being passed to volumeForTrade are actually in terms of ETH at that point, however this means the formula needs alterations since the formula assumes attoETH values when accounting for complete sets.

In particular this portion:

BigNumber.min(p.numCreatorShares, p.numFillerShares).multipliedBy(numTicks));

Will produce a value far too high since numTicks is the value in attoETH of a complete set but this function is returning an ETH value. The equivalent value for this case where the shares are actualy display shares and the desired result is in terms of ETH would be:

BigNumber.min(p.numCreatorShares, p.numFillerShares).multipliedBy(displayRange));

Where the displayRange value comes from the market table by taking its maxPrice - minPrice. In Yes/No and categorical this will always be 1 but for scalars it will vary.