The devDependency decimal.js was updated from 10.1.1 to 10.2.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

decimal.js is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency cross-env was updated from 6.0.0 to 6.0.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

cross-env is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency babel-eslint was updated from 10.0.1 to 10.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

babel-eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Using event.sol you need to know all the possible events before you deploy the contract is a little too limiting.

Imagine if you wanted to play chess with a futarchy. You will need to have a separate token for each move that only pays out if that move happens and there is a win. You would have to have 1 round to allow people to propose moves and then you would have to take that list and reduces it so that you do not go over the gasBlockLimit in the for loop. Which would be quite a small list as OutcomeTokenCreation costs alot of gas.

Is it possible to use the current token model to start trading and still be able to propose other moves, and distribute the associated token to the everyone that calls buyAllOutcomes after the fact without being prohibitively expensive?

@gnosis.pm/gnosis-core-contracts is a thing which should be talked about

EDIT: Is now @gnosis.pm/pm-contracts

https://github.com/gnosis/gnosis-contracts/blob/9285b3e12708b921eecba827161b9295894b406f/contracts/Tokens/StandardToken.sol#L61

Some solidity coders propose to use an approvalIncrease function

• • @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
  • Beware that changing an allowance with this method brings the risk that someone may use both the old
  • and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
  • race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
  • ethereum/EIPs#20 (comment)
  • @param _spender The address which will spend the funds.
  • @param _value The amount of tokens to be spent.
    */
    function approve(address _spender, uint256 _value) public returns (bool) {
    allowed[msg.sender][_spender] = _value;
    Approval(msg.sender, _spender, _value);
    return true;
    }

Currently, all our smart contracts are save. But at some point, this might change, hence it would make sense to use an increaseApproval from the start.

An exemplary contract can be found here:
https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/token/StandardToken.sol

I think it should be done, but it is NOT important currently

@tjade273 wrote an implementation

The devDependency babel-eslint was updated from 10.0.3 to 10.1.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

babel-eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hi Guys,

We develop code linter - Solhint, that provide:

1. Strict source code validation according Solidity Style Guide
2. Security code check using ConsenSys Guide for Smart Contracts
3. Best practices code validation

We think that it would be awesome to add some kind of code validation to your project.

You may contact us - we will be glad to help!
- Ilya

The dependency @gnosis.pm/util-contracts was updated from 2.0.0-alpha.3 to 2.0.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@gnosis.pm/util-contracts is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Your Greenkeeper Bot 🌴

Currently, StandardMarket is optimized via an automated market maker which employs the following formula:

cost = cost level after trade - cost level before trade

where

b = market funding / ln(number of outcomes)

cost level = b * ln( sum ( exp( net quantity of outcome sold / b ) over all outcomes ) )

See:

LMSR Primer
Hanson's original paper on LMSR
This other tutorial on LMSR

There are some computational tricks necessary to get this to compute on the EVM. For example, since the calculations internally use a fixed-point representation, it is very easy for the inner exponential sum to overflow. See comments in LMSRMarketMaker.sol for more details.

A couple of ways more optimal calculations of the price may be achieved:

• Replace all ln with log2 and exp with pow2. You may verify that this does not change the result of the LMSR functions, but may be more computationally expedient. See #26
• There is a floorLog2 meant to cut down on the computation required for logarithms in general. Right now it is used to adjust the natural logarithm, but of course, it may also be used for the base 2 logarithm. There may be a more efficient way to compute that than a binary search: #25

Acceptance criteria:

• PR is made against the development branch
• The existing test suite passes
• There are significant gas cost savings for buying and selling (try npm run measuregasstats)
• There are additional fuzz tests for pow2 and log2 like the existing tests for exp and ln with at most an error of 1e-9 (or for any other non-primitive math functions which are implemented as part of an optimization). See the math tests for existing examples.

The devDependency lodash was updated from 4.17.11 to 4.17.12.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

lodash is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Thought it might be helpful to add a security policy as this is a new feature in GitHub

https://github.com/gnosis/pm-contracts/security

Happy to help with a pull request if given some reference text

The devDependency truffle was updated from 5.0.30 to 5.0.31.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

truffle is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency truffle was updated from 5.1.4 to 5.1.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

truffle is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

The devDependency solhint was updated from 1.2.1 to 1.3.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

solhint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

https://github.com/gnosis/gnosis-contracts/blob/9285b3e12708b921eecba827161b9295894b406f/contracts/Markets/StandardMarketWithPriceLogger.sol#L54

Hey, I am currently testing these smartcontracts, and it would be great if we could call the function LogPriceBefore(); in L54, in order to finish the integral calculation just before the market closure. Currently, the integral calculation is to my knowledge not guaranteed to be complete.

According to the ERC20 standard are transfers of amounts == 0 not allowed and should return false:

https://theethereum.wiki/w/index.php/ERC20_Token_Standard

The code allows to do transfers of amounts == 0
https://github.com/gnosis/gnosis-contracts/blob/master/contracts/Tokens/StandardToken.sol#L46
https://github.com/gnosis/gnosis-contracts/blob/master/contracts/Tokens/StandardToken.sol#L28

Not a terribly big deal but could shave off gas.

The gas stats have this going on:

Contract: Event
  buyAllOutcomes:
    min: 90982
    max: 135662
    avg: 126726
    med: 135662

...

Contract: CategoricalEvent
  buyAllOutcomes:
    min: 91046
    max: 91046
    avg: 91046
    med: 91046

This repo still relies on Truffle 3.4.11. As you probably know for a while Solidity started issuing deprecation warnings for a lot of old syntax/features which will turn into errors with the 0.5.0 release.

Truffle in the 4.x releases has updated Assert.sol to deal with all those requirements. It would be great if Gnosis could upgrade to 4.x and get the benefit of these updates.

Since the Solidity CI also compiles Gnosis contracts, that would make our life much more easier 😉

https://github.com/greenkeeperio/greenkeeper-lockfile

It would be easy for plasma like a contract to use WETH, if EtherToken.sol can add withdraw(uint value, address user) method.

This change will reduce transfer ETH easy by doing -

WETH(wethAddress).withdraw(amount, msg.sender)

// instead of this (will not work when you have payable default function)
// WETH(wethAddress).withdraw(amount)
// msg.sender.transfer(amount)

Following is the example -

    /// @dev Sells tokens in exchange for Ether, exchanging them 1:1
    /// @param value Number of tokens to sell
    /// @param user Address of user
    function withdraw(uint value, address user)
        public
    {
        // Balance covers value
        balances[msg.sender] = balances[msg.sender].sub(value);
        totalTokens = totalTokens.sub(value);
        user.transfer(value);
        Withdrawal(msg.sender, value); // can have different event or can change current event
    }

Let me know what do you think. I can send pull request if everyone agrees.

Hello, I am looking to make use of the Gnosis EtherToken. I happened across this deployed Wrapped Ether contract that seems like it is pretty heavily used. Unfortunately it has no link to its source code. I'm wondering if you are able to verify that this is an instance of the Gnosis EtherToken implementation, or maybe point me in the direction of what other implementation it might be if you happen to have an idea?

https://github.com/gnosis/gnosis-contracts/blob/9ae83fd6a2b231801dd39c91d4b554e1db91b7d8/contracts/Markets/StandardMarket.sol#L163

For better readability, I would add the stage modifier
atStage(Stages.MarketFunded)

But actually, it is not needed since this.sell would throw anyway, if the contract is in another stage.

How do you guys perceive this kind of issue reports? Pedantic of helpful? Still need to find a workflow.

https://github.com/gnosis/gnosis-contracts/blob/8c72d7ec6aff48478ab1eba78596a572c77a9cba/contracts/MarketMakers/LMSRMarketMaker.sol#L73

In most cases, the calcProfit function is called followed by an enforced eventContract.sellAllOutcomes(outcomeTokenProfit);

In these situations, it would be nice to offer traders something like this ipo line 73

for(uint outcomeTokenIndex=0;outcomeTokenIndex< OutcomeTokens.length;outcomeTokenIndex++) {      
netOutcomeTokensSold[outcomeTokenIndex] = netOutcomeTokensSold[outcomeTokenIndex].sub(int(outcomeTokenCount));
}

to enable the most efficient markets, which allow a buy order followed by an immediate sell without loosing money.
With the current version, the LSMR is charging indirect fees by calculating the costLevelAfter on wrong outcomeTokensSold assumptions. Just try to first buy 10 tokens and then sell them again, but you will end up with less. If we have the for loop, we won't end up with less.

If the function calcProfit is called somewhere without an enforced sellAllOutcomes, then it does not make sense to have this for loop in.
@cag What do you think about it?

Steps to reproduce:

1. Enter https://trading.staging.gnosisdev.com
2. Click on Risk Disclaimer, Privacy Policy, Terms of Service or Imprint button.
3. Observe

Expected result:
The usser is redirected correctly to the each page.

Actual result:
The buttons re-charge the page.

Tested on: Chrome, Firefox, Status, Coinbase Wallet.
Mobile: LG nexus 5x
Android version: 8.1.0

The devDependency eslint was updated from 5.15.3 to 5.16.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

The default oracle functions (isOutcomeSet() and getOutcome()) should contain a bytes32 as input. The reason being that right now an oracle contract can only report on a single event as there is no way to request specific information.

To keep things general it would be nice to pass bytes32 always so that a single oracle can report upon multiple events.

For example: If i have a tic tac toe contract that plays multiple games in it. And i want to allow prediction markets to link into it. Each game is identified with keccak256(msg.sender,block.number) and each time i want to resolve a game i need to specify the game i want to resolve like below.

        function isOutcomeSet(bytes32 hash) public constant returns (bool) {
                return(games[hash].isFinished);
        }

        function getOutcome(bytes32 hash) public constant returns (int) {
                return(games[hash].winner);
        }

I understand the need to keep this general. But passing nothing will force ppl to deploy alot of contracts to act as intermediaries. Using the bytes32 is the best IMO as its the size of the keccak256 hash output which is used most often.