Pool IDs can just be incrementing integers
Pool IDs are currently `bytes32` values that increment by `2**128`. After discussion with the development team, it seems that this was in preparation for a feature that was ultimately not used. Pool IDs should instead just be incrementing integers.\\n```\\n// The upper 16 bytes represent the pool id, so this would be pool id 1. See MixinStakinPool for more information.\\nbytes32 constant internal INITIAL\\_POOL\\_ID = 0x0000000000000000000000000000000100000000000000000000000000000000;\\n\\n// The upper 16 bytes represent the pool id, so this would be an increment of 1. See MixinStakinPool for more information.\\nuint256 constant internal POOL\\_ID\\_INCREMENT\\_AMOUNT = 0x0000000000000000000000000000000100000000000000000000000000000000;\\n```\\n\\n```\\n/// @dev Computes the unique id that comes after the input pool id.\\n/// @param poolId Unique id of pool.\\n/// @return Next pool id after input pool.\\nfunction \\_computeNextStakingPoolId(bytes32 poolId)\\n    internal\\n    pure\\n    returns (bytes32)\\n{\\n    return bytes32(uint256(poolId).safeAdd(POOL\\_ID\\_INCREMENT\\_AMOUNT));\\n}\\n```\\n
Resolution\\nThis is fixed in 0xProject/0x-monorepo#2250. Pool IDs now start at 1 and increment by 1 each time.\\nMake pool IDs `uint256` values and simply add 1 to generate the next ID.
```\\n// The upper 16 bytes represent the pool id, so this would be pool id 1. See MixinStakinPool for more information.\\nbytes32 constant internal INITIAL\\_POOL\\_ID = 0x0000000000000000000000000000000100000000000000000000000000000000;\\n\\n// The upper 16 bytes represent the pool id, so this would be an increment of 1. See MixinStakinPool for more information.\\nuint256 constant internal POOL\\_ID\\_INCREMENT\\_AMOUNT = 0x0000000000000000000000000000000100000000000000000000000000000000;\\n```\\n