When the block is being proposed for the first time, the contents of the block are pushed twice causing the number of blocks proposed to be 2 instead of 1

Some functions are not protected by permissions. Implement it.

all migrations happen in second step. separate migrations over several files.

Maybe this https://github.com/sc-forks/solidity-coverage

Consider a hypothetical example
Suppose Staker stakes in 4000 Epoch and for some reason becomes offline for 9 Epochs. Then comes online again in 4010 Epoch and then increases stake and then in the same Epoch commits and reveals. So in this way he can avoid penalty for not participating for the last 9 Epochs. This is a bug.

We need to check the 5 different stakers while sorting the iterations.

Issue 1) Suppose there are 4 stakers if a staker (who is not 4th staker) is staking again for second time his unstake after & withdrawAfter must be updated but here in line 15 & 16 the unstake after & withdrawAfter of 4th staker will be updated because numstakers=4.
Issue 2) And also in file "stakemanager.js" the test case "should be able to unstake after unstake lock period" is passing because in test case "Should be able to increase stake" we are making the 1st staker to stake again (2nd time) in the same epoch so the unstake after & withdrawAfter of the 1st staker won't get updated but still the unstake after & withdrawAfter for 1st staker will be (currentEpoch+1) so in next epoch he can unstake. But if we make 1st staker to stake in next epoch the test case "should be able to unstake after unstake lock period" fails.

            function stake (uint256 epoch, uint256 amount) external checkEpoch(epoch) checkState(Constants.commit()) {
            require(stateManager.getState() != Constants.reveal(), "Incorrect state");
            require(amount >= Constants.minStake(), "staked amount is less than minimum stake required");
            require(sch.transferFrom(msg.sender, address(this), amount), "sch transfer failed");
            uint256 stakerId = stakerIds[msg.sender];
            uint256 previousStake = stakers[stakerId].stake;
            if (stakerId == 0) {
             numStakers = numStakers.add(1);
            stakers[numStakers] = Structs.Staker(numStakers, msg.sender, amount, epoch, 0, 0,
            epoch.add(Constants.unstakeLockPeriod()), 0);
            stakerId = numStakers;
            stakerIds[msg.sender] = stakerId;
             }  else {
                      stakers[stakerId].stake = stakers[stakerId].stake.add(amount);

15) stakers[numStakers].unstakeAfter = epoch.add(Constants.unstakeLockPeriod());
16) stakers[numStakers].withdrawAfter = 0;
}
emit Staked(epoch, stakerId, previousStake, stakers[stakerId].stake, now);
}

1. nobody commits
2. nobody reveals
3. nobody proposes
   Block should be empty for the propose epoch
4. All blocks disputed successfully

build can be its own repo. All other razor network repos can refer to that folder.

this needs all dependent razor network repos to be modified.

We can create a switch inside the VoteManager contract which gets switched so that we dont need to call this function each time the staker commits.

We need a list of parameters that can be changed by the admin.

There are some benefits using Hardhat instead of Truffle.

• Speed up Solidity tests runs
• Utilize Ethers instead of web3
• Much better and versatile migration system
• Rich support for good plugins like etherscan verification etc.

The initial supply of schellingcoin has been changed to 1 billion. Please make the change.

while disputing if you input wrong value of the asset then you can call this function to reset the value.

Due to the introduction of the Delegator, there is no need for ResultProxy.sol as of now.
Neither ResultProxy.sol is deployed, neither its called by other contracts

The disputer should be able to input values of assets he disputes in batches.
Eg Say there are 10 assets and the disputer disputes all of them. Then he should be able to input 5 values in one batch and then again 5 values in another batch

1. Assert for penalty and reward calculation
2. Sorting potential block proposers

Check whether staker raising dispute if successful gets rewarded and the rogue staker gets penalised

We do not have any issue templates. We need them to make issue reporting more standardised.

Package name: ethlint (https://github.com/duaraghav8/Ethlint)

As of now
The block reward is constant
which should slowly decrease over time

function blockReward() public pure returns(uint256) { return(40*(10**uint256(18)));} 

This issue is about to dissolve Constants.sol library, declare constants into the contract if needed.

This has following benefits -:

• As constants are inlined in Solidity, we would be saving some execution cost too. When we fetch constants from Library it uses delegate call which adds up the cost of tx. (~2000 gas)
• Almost all of the constants declared in Constnats.sol are exclusive to a single contract, it will improve code readability too.

Dependabot cannot update elliptic to a non-vulnerable version

The latest possible version that can be installed is 6.5.3 because of the following conflicting dependencies:

@nomiclabs/[email protected] requires [email protected] via a transitive dependency on [email protected]
@nomiclabs/[email protected] requires [email protected] via a transitive dependency on [email protected]
[email protected] requires [email protected] via a transitive dependency on [email protected]
[email protected] requires [email protected] via [email protected]
[email protected] requires [email protected] via a transitive dependency on [email protected]

The earliest fixed version is 6.5.4.

ESLint

In some instances, normal math is used. Use openzeppelin safemath everywhere.

To add the functionality of changing default admin in access control to ensure flexibility.
Obviously, only the current admin can pass his role to the new one.

In Todays Scenario,
It's fixed to one who deploys the contract initially.

both files seem outdated. Delete if outdated

• Bridge

Test where staker unstakes and is made to wait for one epoch which is the unstake lock period

1. test that before unstake lock period staker is not able to unstake
2. test that after unstake lock period staker is able to unstake

Test where staker unstakes he is made to wait for withdraw lock period after which he able to withdraw staked amount

1. test that before withdraw lock period staker is not able to withdraw
2. test that after withdraw lock period staker is able to withdraw the stake amount

Write documentation of each function and variable used in the contract Schelling3

function setStakerStake(uint256 _id, uint256 _stake, string calldata _reason, uint256 _epoch) external onlyWriter {
_setStakerStake(_id, _stake, _reason, _epoch);
}
This Function is not called in any other contracts.
In comments of VoteManager, there is one call of it
So was it created for test purposes only?

We need to run tests + other things on pull requests.

Solidity 6+ has ABIEncoderV2 support and it is not experimental anymore. Upgrade to 6

The master branch is outdated. sch4 is the latest and most up to date branch. merge it with master.

Current we have unstake lock and withdraw lock
another lock period is required after unstake if complete, to prevent last minute hit and run attacks.