k i b o c o n t ra ct a u d i t - kiboplatform.net

Kibo Contract Audit Prepared by Hosho

July 17th, 2018

Report Version: 2.0

Copyright © 2018 Hosho Group Inc.

Executive Summary

This document outlines the overall security of Kibo’s smart contract as evaluated by Hosho’s

Smart Contract auditing team. The scope of this audit was to analyze and document Kibo’s

contract codebase for quality, security, and correctness.

These contracts have passed the rigorous auditing process performed by the Hosho team and all

issues have been fixed. (See Complete Analysis)

Testable code is 95.91% which is on par with the industry standard of 95%. (See Coverage

Report)

It should be noted that this audit is not an endorsement of the reliability or effectiveness of the

contract, rather limited to an assessment of the logic and implementation. In order to ensure a

secure contract that’s able to withstand the Ethereum network’s fast-paced and rapidly changing

environment, we at Hosho recommend that the Kibo team put in place a bug bounty program to

encourage further and active analysis of the smart contract.

1

Table Of Contents

1. Auditing Strategy and Techniques Applied 3

2. Structure Analysis and Test Results 4

2.1. Summary

2.2 Coverage Report

2.3 Failing Tests

3. Complete Analysis 5

3.1 Resolved, Critical: Divide By Zero

3.2 Resolved, Critical: Funds Unpaid

3.3 Resolved, Critical: Funds Bonus

3.4 Resolved, High: Duplicate Ownership

3.5 Resolved, Medium: Hard Promo Limit

3.6 Resolved, Low: Non-Functional Modifier

3.7 Resolved, Low: Extra Import

3.8 Resolved, Low: Unused Variable

3.9 Resolved, Low: Fixed Value Usage

3.10 Resolved, Informational: ERC-20 Non-Compliance

4. Closing Statement 10

5. Appendix A 11

Test Suite Results

6. Appendix B 32

All Contract Files Tested

7. Appendix C 35

Individual File Coverage Report

2

1. Auditing Strategy and Techniques Applied

The Hosho Team has performed a thorough review of the smart contract code, the latest version

as written and updated on June 21st, 2018 . All main contract files were reviewed using the

following tools and processes. (See All Files Covered)

Throughout the review process, care was taken to ensure that the contract:

● Documentation and code comments match logic and behavior;

● Follows best practices in efficient use of gas, without unnecessary waste;

● Uses methods safe from reentrance attacks;

● Is not affected by the latest vulnerabilities;

● Implements and adheres to existing ERC-20 Token standards appropriately and

effectively; and

● Distributes tokens in a manner that matches calculations.

The Hosho Team has followed best practices and industry-standard techniques to verify the

implementation of Kibo’s contract. To do so, the code is reviewed line-by-line by our team of

expert pentesters and smart contract developers, documenting any issues as they are discovered.

Part of this work includes writing a unit test suite using the Truffle testing framework. In

summary, our strategies consist largely of manual collaboration between multiple team members

at each stage of the review:

1. Due diligence in assessing the overall code quality of the codebase.

2. Cross-comparison with other, similar smart contracts by industry leaders.

3. Testing contract logic against common and uncommon attack vectors.

4. Thorough, manual review of the codebase, line-by-line.

5. Deploying the smart contract to testnet and production networks using multiple client

implementations to run live tests.

3

2. Structure Analysis and Test Results

2.1. Summary

The Kibo contracts are a complex, multi-faceted gambling platform with strong isolation

between various parts of the system. This isolation allows for the contracts to be upgraded,

swapped, and exchanged, while primarily providing a single point of entry into the entire system.

A dual-level governance system is also implemented, allowing for administrative approval and

community consensus. With random numbers being provided from off-chain sources, this allows

for the usage of secure RNG's that do not involve predictive data from the blockchain itself. The

collection of games are well implemented as lottery systems, and allow for extreme levels of

flexibility when setting the configuration for the games themselves.

2.2 Coverage Report

As part of our work assisting Kibo in verifying the correctness of their contract code, our team

was responsible for writing a unit test suite using the Truffle testing framework.

For each file see Individual File Coverage Report

2.3 Failing Tests

No failing tests.

See Test Suite Results for all tests.

4

3. Complete Analysis

For ease of navigation, sections are arranged from most critical to least critical. Issues are tagged

“Resolved” or “Unresolved” depending on whether they have been fixed or still need addressing.

Furthermore, the severity of each issue is written as assessed by the risk of exploitation or other

unexpected or otherwise unsafe behavior:

● Critical - The issue affects the contract in such a way that funds may be lost, allocated

incorrectly, or otherwise result in a significant loss.

● High - The issue affects the ability of the contract to compile or operate in a significant

way.

● Medium - The issue affects the ability of the contract to operate in a way that doesn’t

significantly hinder its behavior.

● Low - The issue has minimal impact on the contract’s ability to operate.

● Informational - The issue has no impact on the contract’s ability to operate, and is meant

only as additional information.

3.1 Resolved, Critical: Divide By Zero

Contract: Jokerball

Explanation

During the distribution of the jackpot, the system checks and runs the getLuckies function. It

proceeds to utilize this in the shareFreeJackpot function for a division equation that splits

the prize per each lucky. However, if there are no free tickets utilized in the jackpot, then the

length is 0, causing a divide by zero. This error causes all attempts at paying out winning tickets

to fail, resulting in the game never becoming fully resolved and nothing being paid out to

winners.

Resolution

The Kibo team added a line that checks if(luckies.length == 0), which will return if

true and prevent the accidental division by zero.

5

3.2 Resolved, Critical: Funds Unpaid

Contract: SixFromFortyNine

Explanation

Prior to pay being called, in the releaseFunds function within the require statement, the

unpaid funds value is set to zero. The code attempts to add these unpaid funds to the overall

available reserve funds, however, as it was previously set to 0, it is unable to do so. It is possible

this is by design but without documentation, we are unable to verify this.

Resolution

The Kibo team was able to fix this issue by creating a variable, named unpayed, to store the

funds that are not being released before the amount is reset to 0.

3.3 Resolved, Critical: Funds Bonus

Contract: SixFromFortyNine

Explanation

Prior to pay being called, in the releaseFunds function within the require statement, the

bonuses value is set to zero. This means that when this function is executed, no funds will be

delivered to the safe wallet set within the users contract. It is possible this is by design but

without documentation, we are unable to verify this.

Resolution

The Kibo team was able to fix this issue by creating a variable, named bonuses, to store the

bonus amount prior to the the value being reset.

3.4 Resolved, High: Duplicate Ownership

Contract: Wallet

Explanation

The constructor allows for multiple owners to have the same address, creating the duplicate

owner problem. If this is allowed to occur then many functions will not work properly, such as

removeOwner, due to the interactions between owner addresses and the contract. This issue is

compounded by msg.sender being automatically added as an admin, making it easy to

accidentally add the contract creator twice. These protections can be added in either Wallet or

KiboWallet contracts.

6

Resolution

This issue was fixed by the Kibo team who built in a check to require that the owners indexes are

valid and verifying that the address is not a duplicate.

3.5 Resolved, Medium: Hard Promo Limit

Contract: Users-Promo

Explanation

The promo system utilizes the PROMO_TICKETS constant, which limits the number of tickets to

3. As each drawing sets up a new used_tickets variable by increasing the drawing ID, it is

set to 0. The following require will then pass its first check each time, allowing a user to utilize 3

free tickets for each drawing they are a part of.

Additionally, the system indicates that more free tickets should be able to be added to the active

drawing through the buyFreeTicketPack function in the Proxy contract. However, if this

is called during the same drawing, the hard limit prevents this addition from happening as the

buyFreeTicketPack function that is called fails due to 3 tickets already being used. This

causes unhittable loops within the system.

Resolution

After further investigation with the Kibo team, it has been determined that this is the intended

functionality of the promo tickets system, thus no changes are necessary.

3.6 Resolved, Low: Non-Functional Modifier

Contract: Ballot

Explanation

The timeBetweenProposals modifier can be removed since it will always evaluate to true.

TIME_BETWEEN_PROPOSALS is set to 0 and proposals[current].end is only set to

block.number in a single location. Thus, block.number will always be greater than or

equal to proposals[current].end making the modifier always true.

Resolution

This issue was remediated by changing the value of the TIME_BETWEEN_PROPOSALS

constant from 0 to 10.

7

3.7 Resolved, Low: Extra Import

Contract: FreeballInterface

Explanation

The users.sol file is imported twice at the beginning this contract file.

Resolution

This issue was fixed by removing the second import of user.sol.

3.8 Resolved, Low: Unused Variable

Contract: Freeball

Explanation

The variable mt can be removed as it isn't used or returned, as long as the variable y is set to

_num at the beginning of the rndXorShift function to which it belongs.

Resolution

The Kibo team has removed the mt variable to rectify this issue.

3.9 Resolved, Low: Fixed Value Usage

Contract: Freeball

Explanation

During the execution flow of the buyTickets function, the tickets per block is limited to a the

fixed value of 10, rather than being set dynamically elsewhere in a constant or variable, as is

done with all other fixed values in this contract. If the constant TICKETS_PER_BLOCK is

updated, expecting that number to be updated in the function, this could cause issues during

execution.

Resolution

The Kibo team has changed the require statement in the buyTickets function to compare

against the TICKETS_PER_BLOCK constant, instead of the previously hard-coded value of 10.

8

3.10 Resolved, Informational: ERC-20 Non-Compliance

Contract: KiboToken, Shareholder

Explanation

The ERC-20 standards state that the decimals variable should be explicitly implemented. The

Kibit Token does not implement the 'decimals' variable, which is required in order to be fully

ERC-20 compliant.

Resolution

The Kibo team has resolved this issue by declaring a decimals constant for the Kibit token

and a decimals variable for the Share token.

9

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

4. Closing Statement

The Hosho team is grateful to have been given the opportunity to work with the Kibo team.

The team of experts at Hosho, having backgrounds in all aspects of blockchain, cryptography,

and cybersecurity, can say with confidence that the Kibo contract is free of any critical issues,

and that the Kibo team has taken extensive steps to remediate their code to rectify all previously

found issues in their contracts.

The statements made in this document should not be interpreted as investment or legal

advice, nor should its authors be held accountable for decisions made based on them.

We at Hosho recommend that the Kibo team put in place a bug bounty program to encourage

further analysis of the smart contract by other third parties.

10

5. Appendix A

Test Suite Results

Contract: Freeball tests

Function tests

√ Should buy a freeball ticket (372ms)

√ Should fail to buy a freeball ticket without Proxy (52ms)

√ Should setPrizeToMatches (64ms)

√ Should setPrizeToMatches return false with invalid input (52ms)

√ Should fail to setPrizeToMatches from a nonballot account

√ Should transferSum (38ms)

√ Should fail to buy more than one freeball ticket per block per client (231ms)

√ Should fail to buy more than 10 freeball ticket per block (215ms)

Contract: Freeball winning tests

√ Should buy a winning freeball ticket and payout (343ms)

√ Should buy a winning freeball ticket and fail to payout from empty safe (285ms)

Contract: Freeball Losing tests

√ Should buy a losing freeball ticket (314ms)

Contract: Jokerball tests

√ Should not allow double initialization (64ms)

√ Should allow it's safe to be destroyed (96ms)

√ Should allow the win to finish, even if there are no FreeTicketPacks in the set (2986ms)

√ Should getWinGroups

√ Should getMatches of ticket 0

√ Should rnd by ID (99ms)


11


Buy ticket tests

√ Should buyTicketPack for jokerball (1475ms)

√ Should buyFreeTicketPack for jokerball (595ms)

√ Should buyFreeTicketPack and then buyTicketPack for jokerball (1990ms)

Configuration

√ Should return the RND address

√ Should not permit anyone but the RND to set the winNumbers (41ms)

√ Should require that proxy is the only system able to make proxy based calls (53ms)

√ Should not allow ticket purchases if the game is inactive (4324ms)

√ Should allow the users contract to change the game address, updating rnd along the way

(5394ms)

√ Should not allow the emitting of a new RND address unless called from the users contract

(48ms)

√ Should let the drawing release timeout be set (236ms)

√ Should let the max unverified sum be set (231ms)

√ Should let the tickets per step be set (175ms)

√ Should let the period be set (187ms)

√ Should let the free jackpot storage (157ms)

√ Should let the jackpot storage count be set (207ms)

√ Should let the free jackpot be set (174ms)

√ Should let the min jackpot be set (168ms)

√ Should allow payment of the subscription fee (1718ms)

√ Should allow a partner to buy partner ticket packs for their assigned client (1315ms)

√ Should only allow the safe address to increase the reserve (41ms)

√ Should return the drawing funds (67ms)

Drawing/Payout

√ Should not permit payout before the drawing has winning numbers (119ms)

√ Should not permit a non-registered user to try and claim payout (75ms)

√ Should not allow a bad game ID in to attempt payout (61ms)

12

√ Should not let you buy a ticket if you've not purchased a group ticket (972ms)

√ Should not allow a group ticket purchase higher than the number of parts in the game

(272ms)

√ Should pay out once the RND is resolved (140864ms)

√ Should pay out even if payout needs to be run multiple times (12319ms)

√ Should fail to pay out if the client didn't buy tickets in a drawing (5053ms)

√ Should pay out if the game is not fully sold out (7148ms)

√ Should allow tickets to cycle through once they expire and are released (3234ms)

√ Should not payout when drawing is released (74023ms)

√ Should not allow a user to buy more than the spent limit (364ms)

Win condition verification, ticket set: 11234567

√ Should be a full loss on 0 matches (2683ms)

√ Should require that the round be complete to verify a 7, 0 prize match (2947ms)

√ Should properly handle more than 10 promo participants, returning only 10 (4975ms)

√ Should handle payout of tickets properly for free tickets (2811ms)

Contract: Friends payouts

√ Jokerball - Should handle friend graphs (43505ms)

√ Jokerball - Should handle friend graphs for free payouts (6795ms)

√ SevenPlus - Should handle friend graphs (27857ms)

√ 6/49 - Should handle friend graphs (27367ms)

Contract: ERC-20 Tests for KiboToken

√ Should deploy a token with the proper configuration

√ Should allocate tokens per the minting function, and validate balances (55ms)

√ Should transfer tokens from 0xd86543882b609b1791d39e77f0efc748dfff7dff to

0x42adbad92ed3e86db13e4f6380223f36df9980ef (208ms)

√ Should not transfer negative token amounts (146ms)

√ Should not transfer more tokens than you have (133ms)

13

√ Should allow 0xa3883a50d7d537cec8f9bad8e8404aa8ff3078f3 to authorize

0x341106cb00828c87cd3ac0de55eda7255e04933f to transfer 1000 tokens (80ms)

√ Should allow 0xa3883a50d7d537cec8f9bad8e8404aa8ff3078f3 to zero out the

0x341106cb00828c87cd3ac0de55eda7255e04933f authorization (107ms)

√ Should allow 0x667632a620d245b062c0c83c9749c9bfadf84e3b to authorize

0x53353ef6da4bbb18d242b53a17f7a976265878d5 for 1000 token spend, and

0x53353ef6da4bbb18d242b53a17f7a976265878d5 should be able to send these tokens to

0x341106cb00828c87cd3ac0de55eda7255e04933f (332ms)

√ Should not allow 0x53353ef6da4bbb18d242b53a17f7a976265878d5 to transfer negative

tokens from 0x667632a620d245b062c0c83c9749c9bfadf84e3b (200ms)

√ Should not allow 0x53353ef6da4bbb18d242b53a17f7a976265878d5 to transfer tokens from

0x667632a620d245b062c0c83c9749c9bfadf84e3b to 0x0 (125ms)

√ Should not transfer tokens to 0x0 (75ms)

√ Should not allow 0x53353ef6da4bbb18d242b53a17f7a976265878d5 to transfer more tokens

than authorized from 0x667632a620d245b062c0c83c9749c9bfadf84e3b (174ms)

√ Should allow an approval to be set, then increased, and decreased (275ms)

Contract: Ownership Tests for KiboToken

Deployment

√ Should deploy with the owner being the deployer of the contract

Transfer

√ Should not allow a non-owner to transfer ownership (45ms)

√ Should not allow the owner to transfer to 0x0 (47ms)

√ Should allow the owner to transfer ownership (81ms)

Ensure 'KiboToken' defines the ERC20 Token Standard Interface

√ Should have the correct 'name' definition

√ Should have the correct 'approve' definition

√ Should have the correct 'totalSupply' definition

√ Should have the correct 'transferFrom' definition

√ Should have the correct 'decimals' definition

√ Should have the correct 'balanceOf' definition

14

√ Should have the correct 'symbol' definition

√ Should have the correct 'transfer' definition

√ Should have the correct 'allowance' definition

√ Should have the correct 'Transfer' definition

√ Should have the correct 'Approval' definition

Contract: KiboToken: Extra Functionality

√ Should not allow the token to be deployed with an address of 0x0 (106ms)

√ Should not allow changing the approved spending value of

0xbf3fd79af5a1f2bc9789c7745c98d0880cf78bea without first setting to zero (133ms)

√ Should allow changing the spending limit for

0xbf3fd79af5a1f2bc9789c7745c98d0880cf78bea if a zero limit is first set (195ms)

√ Should return 0 reward for the timelock contract (283ms)

√ Should emit a Deposit event containing 0x1bbb1269032bfd0b0fe0851235fc798af6bd3c9b

and amount when an ETH deposit is received (256ms)

√ Should pay out pending ETH rewards to 0xbc610b3df5c552761c4b3cc03f04b9230720908b

when it sends ETH to the contract (204ms)

√ Should send a payment to 0x8d3cca6dff867a4d5d0116cc0ac9e3348f0453eb when

getReward(0x8d3cca6dff867a4d5d0116cc0ac9e3348f0453eb) is called (344ms)

√ Should emit a Payment event for 0xb634836d3fd15b254ce8c877038708924adc8f86 when

getReward(0xb634836d3fd15b254ce8c877038708924adc8f86) is called (337ms)

√ Should pay ETH rewards to 0x4018d4e6463a71afd7171e9d397df00d8e8c18b9 when it

sends the contract a transaction without data or a value (260ms)

√ Should not call getReward when 0xbf3fd79af5a1f2bc9789c7745c98d0880cf78bea sends

ETH to the contract (105ms)

√ Should revert if the payment of a reward fails (587ms)

Contract: KiboToken Timelock Functionality

√ Should revert if setReleaseTime is called by someone other than the beneficiary

√ Should start countdown if setReleaseTime is called by the beneficiary (59ms)

√ Should not release tokens before 183 days (93ms)

√ Should release tokens after 183 days (243ms)

15

√ Should revert if a second release is attempted (356ms)

Contract: extra Prox tests

buyTicketPack

√ should fail if accounts exceed the daily limit (282ms)

√ should fail if lottery is not active (292ms)

√ should fail if lottery buyTicketPack fail (352ms)

√ should fail if lottery transferSum fail (362ms)

√ should fail if do not send enough eth (456ms)

buyFreeTicketPack


√ should fail if promo fail (209ms)

√ should fail if lottery buyFreeTicketPack fail (255ms)

buyPartnersTicketPack

√ should fail when user number is not 3 (42ms)

√ should fail when client address is Zero address (70ms)

√ should fail if lottery buyTicketPack fail (155ms)

buyFreeballTicket


√ should fail when client`s freeball state fail (120ms)

buyGroupTicket

√ should fail when fail on transferSum (229ms)

√ should fail when do not send enough eth (229ms)

Contract: User tests

User.sol

√ Should only let the proxy set the proxy address, if proxy is not 0 (49ms)

√ Should only let the ballot address set the ballot address if ballot is not 0 (43ms)

√ Should only let the owner register new partners (44ms)

16

√ Should require that addSubscriber succeeds to add partners (109ms)

√ Should only let a subscriber be added once (235ms)

√ Should allow registration of clients (1520ms)

√ Should allow client registration for a partner (648ms)

√ Should allow payment of the subscription fee (1085ms)

√ Should remove subscription tickets (707ms)

√ Should require sanity during game addition (561ms)

√ Should allow addition of tickets to clients (92ms)

√ Should let the max drawings be changed (141ms)

√ Should let the tickets for bonus (262ms)

√ Should enable games (118ms)

√ Should set and unset deductions (259ms)

√ Should only let the sevenplus game enable more freeball tickets (38ms)

√ Should allow freeball configuration (251ms)

√ Should be able to set activation settings (374ms)

√ Should allow basic configuration (783ms)

√ Should approve clients when they buy enough tickets (108ms)

√ Should handle bonus receivers properly via partnerships in multi-level structures

(291687ms)

√ Should get/manage freeball tickets (3416ms)

√ Should be able to set/manage game drawings (389ms)

√ Should allow a game address to be changed (1040ms)

√ Should not allow adding a second game at the same game address (58ms)

√ Should get game data from an address (70ms)

√ Should return empty subscription expiration date for unregistered user

√ Should get subscription expiration date (622ms)

√ Should return the amount of games

√ Should revert if game data is requested with an empty game name

√ Should revert if the game address is replaced for an invalid game ID (39ms)

17

√ Should reset Freeball tickets after the Freeball period (726ms)

√ Should not refresh available extra freeball tickets if already at max allotment (809ms)

√ Should return 0 from getFreeballTimeout if the freeball period is over (677ms)

Contract: Array Tests

√ Should revert on divisors over 1000 or where a modulo 10 is not 0 (143ms)

Contract: Multisig Wallets

√ Should not permit duplicate owners during deployment (344ms)

Internal execution

√ Should run with no confirmation when transaction under daily limit, at one signature

(181ms)

√ Should run with no confirmation when transaction under daily limit, at two signatures

(299ms)

√ Should need multiple confirmations when the daily limit is exceeded in a single transaction

when require multiple confirmations (293ms)


(191ms)

√ should not be able to execute when the data if under daily limit - sha3 signature is invalid

(108ms)

multiowned

√ should use clearPending to clear m_pending array (991ms)

confirmAndCheck

√ should able to validate confirmation by hasConfirmation (45ms)

√ should able to get confirmation if it was confirmed before (799ms)

limitedDaily

√ should be able to use limitedDaily to check daily limit requirment (754ms)

Deployment

√ Should fail if no wallets are added (130ms)

√ Should fail when the accounts are less than the required confirmation (161ms)

√ Should accept eth, including 0 eth (74ms)

18

DayLimit

√ Should have the correct amount of eth and the correct daily limit

√ Should let daily limit be changed (103ms)

√ Should let the daily spend amount be reset (97ms)

√ Should decrement the daily limit correctly (163ms)


(255ms)

√ Should need multiple confirmations when the daily limit is exceeded over multiple

transactions (414ms)

√ Should reset the daily limit daily (201ms)

Multi-owned

√ Should be able to change owners (171ms)

√ Should be able to add an owner (175ms)

√ Should be able to remove an owner (210ms)

√ Should be able to have its signing requirements changed (143ms)

Expect fail/revert

ChangeOwner

√ Should not allow an already active owner to replace another owner (120ms)

√ Should not perform any operations on non-existent owners (147ms)

AddOwner

√ Should not allow the addition of an owner already in the list (107ms)

√ Should not allow adding more than the maximum number of owners (44348ms)

RemoveOwner

√ Should not make any changes to a non-owner account (99ms)

√ Should not allow owners to go less than the number required (446ms)

ChangeRequirement

√ Should not allow the requirement to be higher than the number of owners (114ms)

ConfirmAndCheck/onlymanyowners modifier

√ Should not do anything when called by a non-owner (61ms)

√ Should require the correct number of confirmations (399ms)

19

Call execution

√ Should run with the correct number of signatures, at one signature (105ms)

√ Should run with the correct number of signatures, at two signatures (558ms)

√ Should emit a Revoke event when an operation is revoked (524ms)

√ Should do nothing if a transaction which is not confirmed is revoked (522ms)

√ Should do nothing if a non-owner attempts to revoke a transaction (516ms)

√ Should return true when hasConfirmed() is called on a confirmed operation/owner (474ms)

√ Should return false when hasConfirmed() is called on a non-confirmed operation/owner

(485ms)

Expect fail/revert

√ Should revert when sending more eth than is in the wallet (45ms)

√ Should revert when not run by an owner (39ms)

Kill

√ Should do nothing when called by a non-owner (45ms)

√ Should allow the owner to destroy (96ms)

Contract: Lotto With Promo tests

√ Should require buy ticket pack to revert if buy ticket does not return success (89ms)

Get ticket ID

√ Should get ID for new ticket

√ Should return ticket ID from drawings (93ms)

√ Should decrement client tickets (131ms)

Contract: RND

√ Returns correct followers amount

√ Require valid pusher addresses (133ms)

√ Only allow pushers to put hash

√ Require valid hash to put (55ms)

√ Should only allow unique hashes to be put (99ms)

20

√ Should require valid follower address

√ Should require both pushers to have put hash before resolving hash (153ms)

√ Should require both hash puts before follower can perform next (120ms)

√ Should allow resolving hash (901ms)

√ Should require secret to match hash to resolve (871ms)

√ Only allow resolving a hash once (850ms)

√ Should emit new random address (46ms)

√ Should return correct number of free hashes

√ Should require pusher to access number of free hashes

√ Should allow pusher to check if hash is resolved (120ms)

√ Should only allow checking if hash is resolved for pusher address

√ Should allow getting hash data for pusher (103ms)

√ Should only return hash data for pusher

√ Should allow getting random number by hash data id (978ms)

√ Should return empty random number for unresolved hash pair ID (790ms)

√ Should require a pusher address to get hash to resolve

√ Should require an active hash available to return available hash to resolve (531ms)

√ Should return the correct hashes to resolve from pusher (729ms)

√ Should do nothing in fallback function

√ Check salt should identify existing block hash in salt array (809ms)

√ Should only allow pusher to skip unresolved hash (48ms)

√ Should check that pusher operation data has not already been confirmed (242ms)

√ Should require a next resolve hash to be available for skipping (276ms)

√ Should require skip address to be pusher (264ms)

√ Should require an unresolved hash to skip (978ms)

√ Should allow skipping unresolved hash (1198ms)

√ Should require hash index to remove exist in hash storage (779ms)

√ Should only be able to remove hash if its not the current one (827ms)

√ Should allow removing hash (758ms)

21

√ Should allow replacing hash with existing (929ms)

√ Should require pusher to remove hash (331ms)

Pushers

√ Should allow changing pusher (212ms)

√ Should require changing pushers to not use existing pusher address (173ms)

√ Should require changing pushers to change existing pusher address (174ms)

√ Should return correct pusher address

√ Should allow pusher to revoke operation (394ms)

√ Should report pusher operation as confirmed (115ms)

√ Only allow pushers to have confirmed operations (120ms)

√ Should do nothing if operation does not exist to revoke (47ms)

√ Should only allow pusher to revoke operation (49ms)

Contract: SafeERC20 Tests

Failure mode tests

√ Should revert on transfer failure

√ Should revert on transferFrom failure

√ Should revert on approve failure (41ms)

Success mode tests

√ Should pass on transfer success (50ms)

√ Should pass on transferFrom success

√ Should pass on approve success (38ms)

Contract: SafeMath

√ Should skip operation on multiply by zero

√ Should revert on multiply overflow

√ Should allow regular multiple

√ Should revert on divide by zero

√ Should allow regular division

22

√ Should revert on subtraction overflow

√ Should allow regular subtraction

√ Should revert on addition overflow

√ Should allow regular addition

Contract: Sevenplus tests

√ Should validate ticket matches (110ms)

√ Should require pay to succeed when fund stores more than available to store (1265ms)



Configuration



(1036ms)





√ Should let the max sum be set (143ms)

√ Should only allow the safe address to increase the reserve (42ms)

Drawing/Payout





Payout checks

√ Should only payout after drawing is released (12398ms)

√ Should only payout if waiting list is valid (9423ms)

√ Should detect if a prize has already been paid (10571ms)

23

√ Check that client's current drawing ID tickets match counter (9491ms)

√ Should check max amounts of tickets per call during prize payout calculation (usual

tickets) (9795ms)

√ Should check max amounts of tickets per call during prize payout calculation (9331ms)



√ Should require drawing ID to be within the drawing data set (184ms)

√ Should handle zero winning numbers properly (1757ms)

√ Should handle one winning number properly (1919ms)

√ Should handle two winning numbers properly (2041ms)

√ Should handle three winning numbers properly (2215ms)

√ Should handle four winning numbers properly (1748ms)

√ Should handle five winning numbers properly (1890ms)

√ Should handle six winning numbers properly (1735ms)

√ Should handle seven winning numbers properly (1838ms)

Contract: Shareholder

Token functions

√ Should deploy a token with the proper configuration

√ Should allocate tokens per the minting function, and validate balances (42ms)

√ Should transfer tokens from 0xd86543882b609b1791d39e77f0efc748dfff7dff to

0x42adbad92ed3e86db13e4f6380223f36df9980ef (102ms)

√ Should not transfer negative token amounts (41ms)

√ Should not transfer more tokens than you have (47ms)

√ Should allow 0xa3883a50d7d537cec8f9bad8e8404aa8ff3078f3 to authorize

0x341106cb00828c87cd3ac0de55eda7255e04933f to transfer 1000 tokens (79ms)

√ Should not allow an admin to be the target of a transferFrom (159ms)

√ Should allow 0xa3883a50d7d537cec8f9bad8e8404aa8ff3078f3 to zero out the

0x341106cb00828c87cd3ac0de55eda7255e04933f authorization (164ms)

√ Should not change approval if an approval is already in place and the new approval is

non-zero (149ms)

24

√ Should allow 0x667632a620d245b062c0c83c9749c9bfadf84e3b to authorize

0x53353ef6da4bbb18d242b53a17f7a976265878d5 for 100 token spend, and

0x53353ef6da4bbb18d242b53a17f7a976265878d5 should be able to send these tokens to

0x341106cb00828c87cd3ac0de55eda7255e04933f (233ms)

√ Should not allow 0x53353ef6da4bbb18d242b53a17f7a976265878d5 to transfer negative

tokens from 0x667632a620d245b062c0c83c9749c9bfadf84e3b (98ms)

√ Should not allow transfers if transfers are disabled (76ms)

√ Should not allow 0x53353ef6da4bbb18d242b53a17f7a976265878d5 to transfer tokens

from 0x667632a620d245b062c0c83c9749c9bfadf84e3b to 0x0 (91ms)

√ Should not transfer tokens to 0x0

√ Should not allow 0x53353ef6da4bbb18d242b53a17f7a976265878d5 to transfer more

tokens than authorized from 0x667632a620d245b062c0c83c9749c9bfadf84e3b (45ms)

√ Should allow an approval to be set, then increased, and decreased (365ms)

Additional Functionality

√ Should allow the ballot address to be set (38ms)

√ Should only allow the owner to set the ballot address (46ms)

Administration transfer

√ Should not permit 0x0 to be the new administrator (47ms)

√ Should not allow the new administrator to hold tokens (130ms)

√ Should transfer admin balance to a new admin if there's admin balance available (123ms)

√ Should not allow setting the admin value over the supplyAdmin total (56ms)

√ Should remove admin balance if the new value is lower than the old one (224ms)

√ Should only allow the ballot address to set new admins (41ms)

ETH Management

√ Should accept ETH (39ms)

√ Should accept tracked deposits (184ms)

√ Should send ETH as part of sendPayout (93ms)

√ Should require that sendPayout's amount is less than the contract balance

√ Should require that the send succeeds (80ms)

√ Should let the old payout be increased (80ms)

25

Contract: Ballot

Question configuration

√ Should safely handle receiving no ETH (44ms)

√ Should handle a failure to transfer eth (233ms)

√ Should allow saving a question to storage by the owner (105ms)

√ Should return the index of a question if the question exists (182ms)

√ Should allow the changing of a question (187ms)

√ Should require that the question exist to be changed (38ms)

√ Should revert if there is no shares held by a user during getType (38ms)

Transaction init

√ Should require that a shareholder be the one to start a transaction (103ms)

√ Should not allow the destination to be 0x0 (52ms)

√ Should require that the starter be a shareholder (48ms)

√ Should require that the question exist for an admin to start the transaction (816ms)

√ Should only allow the owner to add a question

√ Should only allow starting if there is not an active vote (604ms)

√ Should require a proposal to be completed for a payout to be claimed (56ms)

√ Should require that the question be enabled for admin_can_start if the admin is to start the

transaction (545ms)

√ Should let a non-admin, but shareholder with the correct threshold number of tokens, start

a transaction if the question exists (612ms)

√ Should revert if there is no tokens held by a user during the getType check

Voting

√ Should only allow votes of 0 or 1 (6017ms)

√ Should not let a proposal be executed prior to the end of the proposal (497ms)

√ Should not let a proposal be executed twice (1898ms)

√ Should not allow a transaction destination of 0x0 (155ms)

√ Should do no payout for admin-started proposals (1299ms)

√ Should not allow a payout to a non-voter address (1309ms)

√ Should not allow a vote after the proposal is over (1541ms)

26

√ Should safely handle a failed execution (2034ms)

√ Should safely handle failed votes (1605ms)

Contract: Six From Fortynine tests



Configuration



(1514ms)





√ Should let the jackpot part be set (161ms)

√ Should let the jackpot storage count be set (164ms)

√ Should let the free jackpot be set (148ms)

√ Should let the min jackpot be set (153ms)

√ Should only allow the safe address to increase the reserve

√ Should return the drawing funds (165ms)

√ Should revert if putWinNumbers is called by an address that is not rnd

√ Should revert if buyGroupTicket is called by an address that is not the proxy (46ms)

√ Should require transferSum == msg.sender (45ms)

√ Should release funds (52ms)

√ Should get prizes to matches (63ms)

√ Should not allow 0 tickets in match (45ms)

√ Should not allow the same number twice in a ticket (176ms)

√ Should get matches (385ms)

√ Should get win groups

27

√ Should get bonus conditions

√ Should get validate options

Drawing/Payout




√ Should not let you buy a ticket if you've not purchased a group ticket (655ms)

√ Should not allow a group ticket purchase higher than the number of parts in the game

(285ms)


√ Should pay out even if payout needs to be run multiple times (24913ms)

√ Should pay out if the game is not fully sold out (12127ms)

√ Should allow funds release after the release timeout is hit (14292ms)



√ Should handle payout of tickets properly for free tickets (4838ms)

√ Should handle zero winning numbers properly (4626ms)

√ Should handle one winning number properly (4133ms)

√ Should handle two winning numbers properly (4407ms)

√ Should handle three winning numbers properly (4205ms)

√ Should handle four winning numbers properly (4167ms)

√ Should handle five winning numbers properly (4303ms)

√ Should handle six winning numbers properly (4026ms)

Contract: Proxy/ Storage tests

√ Should revert on partner registration if the username is already taken (141ms)

√ Should revert on client registration if the username is already taken (158ms)

√ Should revert on partner registration if the new partner is already a partner (144ms)

√ Should revert on client registration if the new client is already a partner (143ms)

28

√ Should revert on partner registration if the new partner is already a client (159ms)

√ Should revert on client registration if the parent is not a client (130ms)

√ Should revert on partner registration if the parent is not a partner (106ms)

√ Should return the same address if you get the partner address of a partner (66ms)

√ Should return the partner address if you get the partner address of a client (71ms)

√ Should revert when adding a client instance to a partner using a client address that is already

a partner (158ms)

√ Should revert on partner registration if the username is already taken (139ms)

√ Should revert on client registration if the username is already taken (149ms)

√ Should revert on partner registration if the new partner is already a partner (132ms)

√ Should revert on client registration if the new client is already a partner (141ms)

√ Should revert on partner registration if the new partner is already a client (156ms)

√ Should revert on client registration if the parent is not a client (159ms)

√ Should revert on partner registration if the parent is not a partner (111ms)

√ Should return the same address if you get the partner address of a partner (70ms)

√ Should return the partner address if you get the partner address of a client (72ms)

√ Should revert when adding a client instance to a partner using a client address that is already

a partner (160ms)

Safe.sol

√ Should require onlyLotto calls (75ms)

Proxy.sol

√ Should require ballot call (83ms)

√ Should only let the ballot contract set the proxy address (52ms)

√ Should only let a partner pay subscription fees (55ms)

√ It should change safe address (57ms)

√ Should set spent limit (67ms)

√ Should fail if not client call (45ms)

√ Should not allow address 0 as proxy or safe address (109ms)

Payout

√ should not use wrong client (65ms)

29

√ should not use the wrong gameid (80ms)

Storage.sol

√ Should get closest partner (86ms)

√ Should get client address

√ Should get client address 2

√ Should get client address 3

√ Should get client parents

√ Should get partner addresses 1


√ Should get partner addresses 3 (39ms)



√ Should toggle client verification (39ms)

√ Should fail client verification (48ms)

√ Should check verification

√ Shouldn't add client twice (99ms)

√ Should registration !contract (38ms)

√ Should not allow duplicates (76ms)

√ Should requre partner username >2 bytes (61ms)

√ Should requre partner == address0 (76ms)

√ Should require userstorage (72ms)

√ Should get client address

√ Should get partner parents

√ Should require registration (85ms)

√ Should require a parent exists (74ms)

√ Should require !isPartner(_client) && !isClient(_client) (76ms)

√ Should clients (74ms)

√ Should require client username >2 bytes (81ms)

√ Should require userstorage for clients (67ms)

30

√ Should require client address is not the contract (47ms)

√ Should require client value (85ms)

√ Should require client is not the contract

√ Should require partner !contract (53ms)

√ Should not allow duplicates (41ms)

31

6. Appendix B

All Contract Files Tested

Commit Hash: 97e2b1f2d9c1fe1b25dc922dc75f5963967529aa

/ballot

File Fingerprint (SHA256)

ballot.sol 203a07c14c6eee2a815ca9143fe032180163ab25016ea3ff7e330d7fe9ba9083

shareholder.sol 275712d2e42968bb849cd56fc761e91c5fbf1657a4eedd7f690b2292ea3ee0aa

interface/ballot.sol bb0d18aef11d86992c5ac6dc0597156f9a05748fb7344839e3f252d0abee0339

interface/shareholder.sol

d46560b9bba6cca1c9f886c5de00d7c267e0d14723520b10ac2b2b6a1aace8ea

/exchange


KiboToken.sol 786e8659ac099e0cfc751f393c5d64bf2ac5941d0f83169b36859d86e294949c

KiboTokenTimelock.sol

70eb33076fd8005ea0358d6709d4106b1e5b8241c4fca1286e4234b761a85989

KiboWallet.sol ebf677fffb8b1e2cca359e3b33ac6284eeb93507d42c4b33d81001ce7084acc3

/libs


array2number.sol 43870a70e5b9f403a0b430ef13f14ad39024c36ac41d0c8efc981949fce2aada

number2array.sol 0286cc7f925005210a812238b4fd77a5bc96ed7963b8da83164be7fb3e17eb04

test.sol 2a7fed43efc60e6c79c6fc67974f0addfbd7d0e1dba2d2af33c2e4ec6f79969f

/rnd_generator


rnd_jokerball.sol 75af24b313c87ffa1717b957abe66c22d2faf9352f19561ffea78d1af561d9db

rnd_sevenplus.sol a60953704c05ccff18e1f50e81ab8b49610603394a598c130962e6e952e24118

rnd_sixfromfortynine.sol

50eb6bcde6b11412da4b07ff82c2fd76c6a2935a807ef7a068683abf22970575

basic/pushers.sol 0fa89641f7fb37f4d205ef4d3667981f7938d61541381458c843ba181b6974f7

basic/rnd.sol d9d1e3b135c0710cf327f06031e6c0c280f2f8aa3ec1be2f041933136b5c4438

interface/rnd.sol 0a0f2cdc7fd834a7dda2ffeb00b852aed317f9a8bf422b283725fbf115128b7f

32

/lotto


freeball.sol 678830a98e98b622c073ac1ccd3cd4e7278e34fbec47cd856164c2a898f3f005

jokerball.sol ba6479cb0e952c7e48d686062b09cd8f00f7d3c54cda8411db20b2608dfdc492

sevenplus.sol 57f204569251c57fb9a4112aa1bfc16871783258b0925b43b548f866404f9fa3

sixfromfortynine.sol

1b18e0435afac026d9ef953ec34ab565a3a677f1a464b062111509033404e6bb

basic/lotto.sol a026bbbeaa26334e18a16458721195d7fce5172a0e28d21f939987e01f22fb58

basic/lotto_simple.sol

a05bbd05c4e285be215a76f4f2385a262729d495bb6e1f36bd0dac224c8acdf9

basic/lotto_with_groupgames.sol

9373fde572b332b64943e94e58c3c822568203dc009f6827ee58f420f7cc6476

basic/lotto_with_promo.sol

572e880b1cb004a7d4245c1299f67df576d47e3d7c7f726e6aebc2312d750c78

basic/safe.sol 30a883fb33e9936a1d527e7a8def206f1fe00b3b6e798bbe4e1b92e4bc0e0255

interface/freeball.sol

d4091af9a6917d1fcfcd50431ed88eb0053f7f23465dc031e035849951b4b418

interface/lotto.sol 6548791f4de6776af736d01fc9ee1efe6e4d9be272c1848670f8b702d7eefd02

interface/lotto_with_groupgames.sol

bf28b19ccdc229ce5e2de2e1c136548ff10281ad2039a42b9344a737b9169e56

interface/lotto_with_promo.sol

5dbdb4dca44e4dcfc8ca5b919b72607670373ba958d028cb3de0773ac0cec907

interface/safe.sol 6a88160c79ff9f3aa8738924bf41f43a6becc1d48ee1d6f5c0415c715929ddbb

/proxy


proxy.sol a426c7e01203be6657fe552b36703459431f18404961209cbdff5e2e019751c4

interface/proxy.sol a6f25dea509e33a01b23b0a112c49ece13f80ed0952ee0d692bd8434c8ccf0a2

/vendor


wallet.sol 3f2c33b82a12608250fe8628a3f0658eed821be5e4c615297181c981e9e943f2

33

/users


users.sol cdab6f53a33fdb44490008f97ddc46129bc0f5f6c23d58572081f95bf7eb726d

basic/bonuses.sol 08dea742a3ac0d07e58150c1bdfff116cb3a50d1b0b51ec2099ac33da19f21ec

basic/freeball_account.sol

101a4df391a87edc72e7332ef90f4885c145597532c8a043b0719fb86e10309e

basic/gamedata.sol 5a255479c4bcb987c4b555644ced956b65f4bab0b89351b6ab4461ace78306c0

basic/promo.sol dbb5bb5e8af57336a4cfef1e1de4f52aacc6b8d5faef56cfd5c2c2fc7a3c7a78

basic/storage.sol e27a803b677a90affb20c338fb468159fcae415beded114ddedb8cda6611a261

basic/subscription.sol

e8ecfea56adacaea56f5d2524b99b2eabe0c949e1e7eca844c2fb68e6b6f7c5e

interface/bonuses.sol

24bc8d9befa89228780840a8db2481ee343ade0e445d42319ec77deba306c49a

interface/freeball_account.sol

d1ce168cecc31b7bedf530063685c0778f5aa917e64b4812a70f9bd201810163

interface/gamedata.sol

ea29c185b6bab2cd9bf54993a3a1ad763b065a21c1a4c29d8f3ab1bf43b74901

interface/promo.sol 6fec4ae24a6092ffad4f8309cb0388be4be118c8849224f0b53eb57641d39cd6

interface/storage.sol

66389c04c83faa0747fd5d09f5efa3f8094ce5624421926482a667b2f8b88c21

interface/subscription.sol

eed7011b9546d6ce8d956f5641c4a2ac5bb046cef2056b76b69ed1eb9e068202

/zeppelin-solidity/contracts


math/SafeMath.sol 596bb5e82ff5009c31049f0cc9e5b8b95172fc7b38da5335bbdd09585c692f9c

ownership/Ownable.sol

fd49860e2f11bc70dc265e0d001048eeed921900ad2e4c9599fb4e9a8e3cae5c

token/BasicToken.sol

8621af4f22587f4cbefc40d97639820110af2b9534de9ba31e354c5ff3805550

token/ERC20.sol 115176a18bd1532f76b6a577069621f3867b83dfb5859b0ff1af578f0cea2098

token/ERC20Basic.sol

1355547bf20e382a9f76af542ecbd86edf175abd1eee6175b42615ade4a85383

token/SafeERC20.sol

24ed343436ee8ce5f5ebde3d78662bfdca443e637e61e6633c4e4982704807cf

token/StandardToken.sol

94e90d7ec0debecbc262138fe1890cd7d46cadbf984b5b41fbdf001b015ac662

34

7. Appendix C

Individual File Coverage Report

/ballot

File % Statements % Branches % Functions % Lines

ballot.sol 97.73% 89.53% 94.44% 96.55%

shareholder.sol 98.48% 92.50% 95.45% 97.14%

interface/ballot.sol 100.00% 100.00% 100.00% 100.00%

interface/shareholder.sol

100.00% 100.00% 100.00% 100.00%

/exchange


KiboToken.sol 100.00% 95.00% 100.00% 100.00%

KiboTokenTimelock.sol

100.00% 100.00% 100.00% 100.00%

KiboWallet.sol 100.00% 88.89% 100.00% 100.00%

/libs


array2number.sol 100.00% 100.00% 100.00% 100.00%

number2array.sol 100.00% 100.00% 100.00% 100.00%

test.sol 100.00% 100.00% 100.00% 100.00%

/proxy


proxy.sol 100.00% 100.00% 100.00% 100.00%

interface/proxy.sol

100.00% 100.00% 100.00% 100.00%

/rnd_generator


rnd_jokerball.sol 100.00% 100.00% 100.00% 100.00%

35

rnd_sevenplus.sol 100.00% 100.00% 100.00% 100.00%

rnd_sixfromfortynine.sol

100.00% 100.00% 100.00% 100.00%

basic/pushers.sol 100.00% 100.00% 100.00% 100.00%

basic/rnd.sol 100.00% 100.00% 100.00% 100.00%

interface/rnd.sol 100.00% 100.00% 100.00% 100.00%

/lotto


freeball.sol 100.00% 100.00% 100.00% 100.00%

jokerball.sol 94.59% 79.69% 100.00% 95.36%

sevenplus.sol 96.15% 88.89% 100.00% 96.19%

sixfromfortynine.sol

94.49% 82.14% 100.00% 95.79%

basic/lotto.sol 90.36% 73.81% 100.00% 89.53%

basic/lotto_simple.sol

85.00% 75.00% 100.00% 86.36%

basic/lotto_with_groupgames.sol

94.74% 83.33% 81.82% 95.16%

basic/lotto_with_promo.sol

95.24% 94.44% 100.00% 96.08%

basic/safe.sol 100.00% 100.00% 100.00% 100.00%

interface/freeball.sol

100.00% 100.00% 100.00% 100.00%

interface/lotto.sol 100.00% 100.00% 100.00% 100.00%

interface/lotto_with_groupgames.sol

100.00% 100.00% 100.00% 100.00%

interface/lotto_with_promo.sol

100.00% 100.00% 100.00% 100.00%

interface/safe.sol 100.00% 100.00% 100.00% 100.00%

/users


users.sol 100.00% 92.86% 100.00% 100.00%

basic/bonuses.sol 100.00% 92.11% 100.00% 100.00%

basic/freeball_account.sol

100.00% 100.00% 100.00% 100.00%

basic/gamedata.sol

98.72% 95.45% 100.00% 100.00%

36

basic/promo.sol 95.12% 78.57% 100.00% 95.00%

basic/storage.sol 100.00% 98.00% 100.00% 100.00%

basic/subscription.sol

100.00% 93.75% 100.00% 100.00%

interface/bonuses.sol

100.00% 100.00% 100.00% 100.00%

interface/freeball_account.sol

100.00% 100.00% 100.00% 100.00%

interface/gamedata.sol

100.00% 100.00% 100.00% 100.00%

interface/promo.sol

100.00% 100.00% 100.00% 100.00%

interface/storage.sol

100.00% 100.00% 100.00% 100.00%

interface/subscription.sol

100.00% 100.00% 100.00% 100.00%

/zeppelin-solidity/contracts


math/SafeMath.sol

100.00% 100.00% 100.00% 100.00%

ownership/Ownable.sol

100.00% 100.00% 100.00% 100.00%

token/BasicToken.sol

100.00% 75.00% 100.00% 100.00%

token/ERC20.sol 100.00% 100.00% 100.00% 100.00%

token/ERC20Basic.sol

100.00% 100.00% 100.00% 100.00%

token/SafeERC20.sol

100.00% 100.00% 100.00% 100.00%

token/StandardToken.sol

100% 87.50% 100.00% 100.00%

/vendor


wallet.sol 100.00% 96.43% 100.00% 100.00%

Coverage Totals

% Statements % Branches % Functions % Lines

All Files 97.30% 90.02% 98.83% 97.50%

37

k i b o c o n t ra ct a u d i t - kiboplatform.net

Documents