projectwyvern / wyvern-ethereum Goto Github PK

The guardedArrayReplace function (https://github.com/ProjectWyvern/wyvern-ethereum/blob/master/contracts/common/ArrayUtils.sol#L25), used by the Exchange contract to test whether the possible transaction bytecodes specified by two orders can be matched, is presently written in plain Solidity. I have not inspected the output EVM code yet, but I'm guessing it's not very efficient. At minimum, there are probably unnecessary array bounds checks, and given the particularities of the EVM, this may not be the optimal way to implement this algorithm in general (some kind of batched masking might be more efficient).

Breaking changes to the bytecode mask format will be considered if they would lead to substantial gas savings, but they must preserve the property that individual bytes can be masked/unmasked independently.

After upgrading various dependencies (mostly solc 0.23), solcover is broken:

Compilation warnings encountered:
zeppelin-solidity/contracts/ownership/Ownable.sol:20:3: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.
  function Ownable() public {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/MerkleProof.sol:17:3: Warning: Function state mutability can be restricted to pure
  function verifyProof(bytes32[] _proof, bytes32 _root, bytes32 _leaf) internal  returns (bool) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:13:3: Warning: Function state mutability can be restricted to pure
  function mul(uint256 a, uint256 b) internal  returns (uint256 c) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:25:3: Warning: Function state mutability can be restricted to pure
  function div(uint256 a, uint256 b) internal  returns (uint256) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:35:3: Warning: Function state mutability can be restricted to pure
  function sub(uint256 a, uint256 b) internal  returns (uint256) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:43:3: Warning: Function state mutability can be restricted to pure
  function add(uint256 a, uint256 b) internal  returns (uint256 c) {
  ^ (Relevant source part starts here and spans across multiple lines).
zeppelin-solidity/contracts/ownership/Ownable.sol:20:3: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.
  function Ownable() public {
  ^ (Relevant source part starts here and spans across multiple lines).
,/home/travis/build/ProjectWyvern/wyvern-ethereum/coverageEnv/contracts/common/ArrayUtils.sol:35:22: TypeError: Function declared as pure, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
        uint words = SafeMath.div(array.length, 0x20);
                     ^------------------------------^
,/home/travis/build/ProjectWyvern/wyvern-ethereum/coverageEnv/contracts/common/ArrayUtils.sol:36:22: TypeError: Function declared as pure, but this expression (potentially) modifies the state and thus requires non-payable (the default) or payable.
        uint index = SafeMath.mul(words, 0x20);
                     ^-----------------------^
,zeppelin-solidity/contracts/MerkleProof.sol:17:3: Warning: Function state mutability can be restricted to pure
  function verifyProof(bytes32[] _proof, bytes32 _root, bytes32 _leaf) internal  returns (bool) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:13:3: Warning: Function state mutability can be restricted to pure
  function mul(uint256 a, uint256 b) internal  returns (uint256 c) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:25:3: Warning: Function state mutability can be restricted to pure
  function div(uint256 a, uint256 b) internal  returns (uint256) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:35:3: Warning: Function state mutability can be restricted to pure
  function sub(uint256 a, uint256 b) internal  returns (uint256) {
  ^ (Relevant source part starts here and spans across multiple lines).
,zeppelin-solidity/contracts/math/SafeMath.sol:43:3: Warning: Function state mutability can be restricted to pure
  function add(uint256 a, uint256 b) internal  returns (uint256 c) {
  ^ (Relevant source part starts here and spans across multiple lines).
Compilation failed. See above.
Cleaning up...
Event trace could not be read.
Error: ENOENT: no such file or directory, open './allFiredEvents'
Exiting without generating coverage...
cat: coverage/lcov.info: No such file or directory
[error] "2018-05-12T19:17:51.156Z"  'error from lcovParse: ' 'Failed to parse string'
[error] "2018-05-12T19:17:51.158Z"  'input: ' ''
[error] "2018-05-12T19:17:51.158Z"  'error from convertLcovToCoveralls'
/home/travis/build/ProjectWyvern/wyvern-ethereum/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Failed to parse string
error Command failed with exit code 1.

I don't understand this error, verifyProof is marked as pure. Haven't spent much time debugging, should be an easy fix somewhere, probably just a toolchain issue. The usual yarn compile, yarn testrpc, and yarn test works fine.

A successful bounty submission will fix solcover - which should then work with Travis CI as previously written.

Does wyvern support EIP712 from which version? And which version of wyvern protocol is supported by OpenSea?

I get an error when deploying the WyvernExchangeV2 contract

On line 341 of DelegatedShareholderAssociation.sol there's this check:

            /* Prevent the DAO from sending the locked shares tokens (and thus potentially being unable to release locked tokens to delegating shareholders). */
            require(ERC20(sharesTokenAddress).balanceOf(address(this)) >= totalLockedTokens);

this won't catch a call of approve ERC20 function, because that call doesn't immediately decrease balance. So transferral of tokens in ownership of the DAO contract is still possible, despite the intention to prevent it.

Spent all evening scouring for reentrancy bugs, and came up empty. The contract honestly looks really good.

Only note I have is concerning overflows/underflows. If OpenZeppelin is already a dependency, you might want to join the growing number of contracts taking advantage of SafeMath to sanity check all arithmetic operations.

There are other basic sanity checks in the code to check for situations that shouldn't exist, but they don't cover overflows. E.g:

UTXORedeemableToken.sol (lines 192-199)

/* Calculate the redeemed tokens. */
tokensRedeemed = satoshis * multiplier;

/* Track total redeemed tokens. */
totalRedeemed += tokensRedeemed;

/* Sanity check. */
require(totalRedeemed <= maximumRedeemable);

The sanity check would cover the case where satoshis is very large, but would fail to cover the case where satoshis becomes close to the uint256 max.

The absence of sanity checks is felt even more strongly in places like lines 163/164 in DelegatedShareholderAssociation.sol, where uint values are subtracted down to 0.

I'll stress that none of this represents a security vulnerability on its own, but it's seriously worth considering switching to SafeMath as part of a defense in depth approach to contract security.

That's the only recommendation I have. Good luck with the port! Exciting to see new life breathed into Wyvern.

access_token$production$8vwk8chkv364zkw7$47c0806e1da176fc9ccbde59ae42bcfbmy tokem

Due to Solidity stack size limitations, the current order hashing implementation (here) must hash orders in two parts. This is a waste of gas. Instead, manually "tightly pack" the Order struct into bytes following the Solidity tight-packing convention (see here), which should result in one fewer calls to the keccak256 builtin. Other ways of getting around Solidity's stack size limitation may be candidate solutions as long as they still decrease gas costs.

May be rendered easier by this Solidity PR, but I do not know what the timetable for that is.

when a proposal is created the beneficiary is stored without checking on line 214 of DelegatedShareholderAssociation.sol.

function newProposal(
        address beneficiary,
        uint weiAmount,
        bytes jobMetadataHash,
        bytes transactionBytecode
    )
        public
        onlyBoardMembers
        returns (uint proposalID)
    {
        proposalID = proposals.length++;
        Proposal storage p = proposals[proposalID];
        p.recipient = beneficiary;
...

when a proposal is executed the following is called on line 337 of DelegatedShareholderAssociation.sol.

/* Execute the function. */
 require(p.recipient.call.value(p.amount)(transactionBytecode));

However this will return true whether p.recipient is valid or not.

https://solidity.readthedocs.io/en/develop/control-structures.html#error-handling-assert-require-revert-and-exceptions

The low-level call, delegatecall and callcode will return success if the calling account is non-existent, as part of the design of EVM. Existence must be checked prior to calling if desired.

As part of the Wyvern bounty program I submit:

In Line 20 of the WyvernDAO solidity contract, it states that the required shares to be a board member are 0.1% of the total supply. At the currently specified 200 * {decimals}, this is only .01% of the total supply to be a board member, which is a factor of ten less than the intended result.

Duplicate of #8 - additional issue so an increased bounty can be placed through Gitcoin. Will be tracked through that issue.

Duplicate of #9 so that an additional bounty can be created through Gitcoin, will be tracked along with that issue.

Currently, because DAO can call approve function on the token and can call itself, it can delegate locked tokens to some address, effectively creating new votes from thin air, I think that should be prevented.
Furthermore, if user withdrawal of tokens lowers the amount of locked tokens under the amount that the DAO delegated, the delegation can't be reversed.