Kibo Contract Audit. Prepared by Hosho July 17th, Report Version: 2.0. Copyright 2018 Hosho Group Inc.

Transcription

1 Kibo Contract Audit Prepared by Hosho July 17th, 2018 Report Version: 2.0 Copyright 2018 Hosho Group Inc.

2 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

3 Table Of Contents 1. Auditing Strategy and Techniques Applied 3 2. Structure Analysis and Test Results Summary 2.2 Coverage Report 2.3 Failing Tests 3. Complete Analysis 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 Appendix A 11 Test Suite Results 6. Appendix B 32 All Contract Files Tested 7. Appendix C 35 Individual File Coverage Report 2

4 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, 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

5 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

6 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

7 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 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

8 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

9 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

10 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

11 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

12 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) Should rnd by ID (114ms) 11

13 Should rnd by ID (132ms) 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

14 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: 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 0xd b609b1791d39e77f0efc748dfff7dff to 0x42adbad92ed3e86db13e4f f36df9980ef (208ms) Should not transfer negative token amounts (146ms) Should not transfer more tokens than you have (133ms) 13

15 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 0x53353ef6da4bbb18d242b53a17f7a d5 for 1000 token spend, and 0x53353ef6da4bbb18d242b53a17f7a d5 should be able to send these tokens to 0x341106cb00828c87cd3ac0de55eda7255e04933f (332ms) Should not allow 0x53353ef6da4bbb18d242b53a17f7a d5 to transfer negative tokens from 0x667632a620d245b062c0c83c9749c9bfadf84e3b (200ms) Should not allow 0x53353ef6da4bbb18d242b53a17f7a d5 to transfer tokens from 0x667632a620d245b062c0c83c9749c9bfadf84e3b to 0x0 (125ms) Should not transfer tokens to 0x0 (75ms) Should not allow 0x53353ef6da4bbb18d242b53a17f7a d5 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

16 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 0x1bbb bfd0b0fe fc798af6bd3c9b and amount when an ETH deposit is received (256ms) Should pay out pending ETH rewards to 0xbc610b3df5c552761c4b3cc03f04b b 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 0xb634836d3fd15b254ce8c adc8f86 when getreward(0xb634836d3fd15b254ce8c adc8f86) 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

17 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 lottery is not active (195ms) 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 if lottery is not active (55ms) 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

18 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

19 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) Should need multiple confirmations when the daily limit is exceeded in a single transaction (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

20 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) Should need multiple confirmations when the daily limit is exceeded in a single transaction (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

21 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

22 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

23 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

24 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) Should not allow double initialization (47ms) Should allow it's safe to be destroyed (81ms) Configuration Should return the RND address Should allow the users contract to change the game address, updating rnd along the way (1036ms) Should let the drawing release timeout be set (208ms) Should let the max unverified sum be set (176ms) Should let the tickets per step be set (131ms) Should let the period be set (152ms) Should let the max sum be set (143ms) Should only allow the safe address to increase the reserve (42ms) Drawing/Payout Should not permit payout before the drawing has winning numbers (131ms) Should not permit a non-registered user to try and claim payout (56ms) Should not allow a bad game ID in to attempt payout (60ms) Should pay out once the RND is resolved (3661ms) 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

25 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) Win condition verification, ticket set: Should be a full loss on 0 matches (1656ms) 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 0xd b609b1791d39e77f0efc748dfff7dff to 0x42adbad92ed3e86db13e4f f36df9980ef (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

26 Should allow 0x667632a620d245b062c0c83c9749c9bfadf84e3b to authorize 0x53353ef6da4bbb18d242b53a17f7a d5 for 100 token spend, and 0x53353ef6da4bbb18d242b53a17f7a d5 should be able to send these tokens to 0x341106cb00828c87cd3ac0de55eda7255e04933f (233ms) Should not allow 0x53353ef6da4bbb18d242b53a17f7a d5 to transfer negative tokens from 0x667632a620d245b062c0c83c9749c9bfadf84e3b (98ms) Should not allow transfers if transfers are disabled (76ms) Should not allow 0x53353ef6da4bbb18d242b53a17f7a d5 to transfer tokens from 0x667632a620d245b062c0c83c9749c9bfadf84e3b to 0x0 (91ms) Should not transfer tokens to 0x0 Should not allow 0x53353ef6da4bbb18d242b53a17f7a d5 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

27 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

28 Should safely handle a failed execution (2034ms) Should safely handle failed votes (1605ms) Contract: Six From Fortynine tests Should not allow double initialization (53ms) Should allow it's safe to be destroyed (99ms) Configuration Should return the RND address Should allow the users contract to change the game address, updating rnd along the way (1514ms) Should let the drawing release timeout be set (239ms) Should let the max unverified sum be set (212ms) Should let the tickets per step be set (166ms) Should let the period be set (152ms) 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

29 Should get bonus conditions Should get validate options Drawing/Payout Should not permit payout before the drawing has winning numbers (145ms) Should not permit a non-registered user to try and claim payout (65ms) Should not allow a bad game ID in to attempt payout (423ms) 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 once the RND is resolved (216338ms) 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) Win condition verification, ticket set: Should be a full loss on 0 matches (4569ms) 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

30 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

31 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 2 Should get partner addresses 3 (39ms) Should get partner addresses 2 Should get partner addresses 3 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

32 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

33 6. Appendix B All Contract Files Tested Commit Hash: 97e2b1f2d9c1fe1b25dc922dc75f aa /ballot File ballot.sol shareholder.sol interface/ballot.sol interface/sharehold er.sol Fingerprint (SHA256) 203a07c14c6eee2a815ca9143fe ab25016ea3ff7e330d7fe9ba d2e42968bb849cd56fc761e91c5fbf1657a4eedd7f690b2292ea3ee0aa bb0d18aef11d86992c5ac6dc f9a05748fb e3f252d0abee0339 d46560b9bba6cca1c9f886c5de00d7c267e0d b10ac2b2b6a1aace8ea /exchange File KiboToken.sol KiboTokenTimeloc k.sol KiboWallet.sol Fingerprint (SHA256) 786e8659ac099e0cfc751f393c5d64bf2ac5941d0f83169b36859d86e294949c 70eb33076fd8005ea0358d6709d4106b1e5b8241c4fca1286e4234b761a85989 ebf677fffb8b1e2cca359e3b33ac6284eeb93507d42c4b33d81001ce7084acc3 /libs File array2number.sol number2array.sol test.sol Fingerprint (SHA256) 43870a70e5b9f403a0b430ef13f14ad39024c36ac41d0c8efc981949fce2aada 0286cc7f a812238b4fd77a5bc96ed7963b8da83164be7fb3e17eb04 2a7fed43efc60e6c79c6fc67974f0addfbd7d0e1dba2d2af33c2e4ec6f79969f /rnd_generator File rnd_jokerball.sol rnd_sevenplus.sol rnd_sixfromfortyni ne.sol basic/pushers.sol basic/rnd.sol interface/rnd.sol Fingerprint (SHA256) 75af24b313c87ffa1717b957abe66c22d2faf9352f19561ffea78d1af561d9db a c05ccff18e1f50e81ab8b a598c130962e6e952e eb6bcde6b11412da4b07ff82c2fd76c6a2935a807ef7a068683abf fa89641f7fb37f4d205ef4d f7938d c843ba181b6974f7 d9d1e3b135c0710cf327f06031e6c0c280f2f8aa3ec1be2f b5c4438 0a0f2cdc7fd834a7dda2ffeb00b852aed317f9a8bf422b283725fbf115128b7f 32

34 /lotto File Fingerprint (SHA256) freeball.sol a98e98b622c073ac1ccd3cd4e7278e34fbec47cd856164c2a898f3f005 jokerball.sol ba6479cb0e952c7e48d686062b09cd8f00f7d3c54cda8411db20b2608dfdc492 sevenplus.sol 57f c57fb9a4112aa1bfc b0925b43b548f866404f9fa3 sixfromfortynine.so l 1b18e0435afac026d9ef953ec34ab565a3a677f1a464b e6bb basic/lotto.sol a026bbbeaa26334e18a d7fce5172a0e28d21f939987e01f22fb58 basic/lotto_simple.s ol a05bbd05c4e285be215a76f4f2385a262729d495bb6e1f36bd0dac224c8acdf9 basic/lotto_with_gr oupgames.sol 9373fde572b332b64943e94e58c3c dc009f6827ee58f420f7cc6476 basic/lotto_with_pr omo.sol 572e880b1cb004a7d4245c1299f67df576d47e3d7c7f726e6aebc2312d750c78 basic/safe.sol 30a883fb33e9936a1d527e7a8def206f1fe00b3b6e798bbe4e1b92e4bc0e0255 interface/freeball.so l d4091af9a6917d1fcfcd50431ed88eb0053f7f23465dc031e b4b418 interface/lotto.sol f4de6776af736d01fc9ee1efe6e4d9be272c f8b702d7eefd02 interface/lotto_with _groupgames.sol bf28b19ccdc229ce5e2de2e1c136548ff10281ad2039a42b9344a737b9169e56 interface/lotto_with _promo.sol 5dbdb4dca44e4dcfc8ca5b919b ba958d028cb3de0773ac0cec907 interface/safe.sol 6a88160c79ff9f3aa bf41f43a6becc1d48ee1d6f5c0415c715929ddbb /proxy File Fingerprint (SHA256) proxy.sol a426c7e01203be6657fe552b f cbdff5e2e019751c4 interface/proxy.sol a6f25dea509e33a01b23b0a112c49ece13f80ed0952ee0d692bd8434c8ccf0a2 /vendor File Fingerprint (SHA256) wallet.sol 3f2c33b82a fe8628a3f0658eed821be5e4c c981e9e943f2 33

35 /users File Fingerprint (SHA256) users.sol cdab6f53a33fdb f97ddc46129bc0f5f6c23d f95bf7eb726d basic/bonuses.sol 08dea742a3ac0d07e58150c1bdfff116cb3a50d1b0b51ec2099ac33da19f21ec basic/freeball_acco unt.sol 101a4df391a87edc72e7332ef90f4885c c8a043b0719fb86e10309e basic/gamedata.sol 5a255479c4bcb987c4b555644ced956b65f4bab0b89351b6ab4461ace78306c0 basic/promo.sol dbb5bb5e8af57336a4cfef1e1de4f52aacc6b8d5faef56cfd5c2c2fc7a3c7a78 basic/storage.sol e27a803b677a90affb20c338fb468159fcae415beded114ddedb8cda6611a261 basic/subscription.s ol e8ecfea56adacaea56f5d2524b99b2eabe0c949e1e7eca844c2fb68e6b6f7c5e interface/bonuses.s ol 24bc8d9befa a8db2481ee343ade0e445d42319ec77deba306c49a interface/freeball_a ccount.sol d1ce168cecc31b7bedf c0778f5aa917e64b4812a70f9bd interface/gamedata. sol ea29c185b6bab2cd9bf54993a3a1ad763b065a21c1a4c29d8f3ab1bf43b74901 interface/promo.sol 6fec4ae24a6092ffad4f8309cb0388be4be118c f0b53eb57641d39cd6 interface/storage.so l 66389c04c83faa0747fd5d09f5efa3f8094ce a667b2f8b88c21 interface/subscripti on.sol eed7011b9546d6ce8d956f5641c4a2ac5bb046cef2056b76b69ed1eb9e /zeppelin-solidity/contracts File Fingerprint (SHA256) math/safemath.sol 596bb5e82ff5009c31049f0cc9e5b8b95172fc7b38da5335bbdd09585c692f9c ownership/ownabl e.sol fd49860e2f11bc70dc265e0d001048eeed921900ad2e4c9599fb4e9a8e3cae5c token/basictoken.s ol 8621af4f22587f4cbefc40d af2b9534de9ba31e354c5ff token/erc20.sol a18bd1532f76b6a f3867b83dfb5859b0ff1af578f0cea2098 token/erc20basic. sol bf20e382a9f76af542ecbd86edf175abd1eee6175b42615ade4a85383 token/safeerc20.s ol 24ed343436ee8ce5f5ebde3d78662bfdca443e637e61e6633c4e cf token/standardtok en.sol 94e90d7ec0debecbc262138fe1890cd7d46cadbf984b5b41fbdf001b015ac662 34

36 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 % % % % interface/sharehold er.sol % % % % /exchange File % Statements % Branches % Functions % Lines KiboToken.sol % 95.00% % % KiboTokenTimelo ck.sol % % % % KiboWallet.sol % 88.89% % % /libs File % Statements % Branches % Functions % Lines array2number.sol % % % % number2array.sol % % % % test.sol % % % % /proxy File % Statements % Branches % Functions % Lines proxy.sol % % % % interface/proxy.s ol % % % % /rnd_generator File % Statements % Branches % Functions % Lines rnd_jokerball.sol % % % % 35

37 rnd_sevenplus.sol % % % % rnd_sixfromforty nine.sol % % % % basic/pushers.sol % % % % basic/rnd.sol % % % % interface/rnd.sol % % % % /lotto File % Statements % Branches % Functions % Lines freeball.sol % % % % jokerball.sol 94.59% 79.69% % 95.36% sevenplus.sol 96.15% 88.89% % 96.19% sixfromfortynine.so l 94.49% 82.14% % 95.79% basic/lotto.sol 90.36% 73.81% % 89.53% basic/lotto_simple.s ol basic/lotto_with_gr oupgames.sol basic/lotto_with_pr omo.sol 85.00% 75.00% % 86.36% 94.74% 83.33% 81.82% 95.16% 95.24% 94.44% % 96.08% basic/safe.sol % % % % interface/freeball.so l % % % % interface/lotto.sol % % % % interface/lotto_with _groupgames.sol interface/lotto_with _promo.sol % % % % % % % % interface/safe.sol % % % % /users File % Statements % Branches % Functions % Lines users.sol % 92.86% % % basic/bonuses.sol % 92.11% % % basic/freeball_acc ount.sol basic/gamedata.so l % % % % 98.72% 95.45% % % 36

38 basic/promo.sol 95.12% 78.57% % 95.00% basic/storage.sol % 98.00% % % basic/subscription.sol interface/bonuses. sol interface/freeball_ account.sol interface/gamedat a.sol interface/promo.s ol interface/storage.s ol interface/subscript ion.sol % 93.75% % % % % % % % % % % % % % % % % % % % % % % % % % % /zeppelin-solidity/contracts File % Statements % Branches % Functions % Lines math/safemath.so l ownership/ownab le.sol token/basictoken.sol % % % % % % % % % 75.00% % % token/erc20.sol % % % % token/erc20basi c.sol token/safeerc20.sol token/standardto ken.sol % % % % % % % % 100% 87.50% % % /vendor File % Statements % Branches % Functions % Lines wallet.sol % 96.43% % % Coverage Totals % Statements % Branches % Functions % Lines All Files 97.30% 90.02% 98.83% 97.50% 37