SandBox V4

CertiK19 Aug 2020Files named in the report

Audit

CertiK reviewed The Sandbox (SandBox V4) on 19 Aug 2020: 36 findings, 0 critical; 24 marked fixed, 12 open.

No open critical findings

Open the report Open The Sandbox’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings36

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	0	0
Medium	1	0
Low	11	24

MediumMisconception of RandomnessOpen

The function “_computeValue” is meant to calculate a random value for assigning the value per gem ID. The result of its computation is stored in a variable named “randomValue”.

LowDuplicate Code SegmentsOpen

The aforementioned code segments are exactly the same leading to unnecessary bytecode duplication.

LowInconsistent ImplementationOpen

The functions “_batchMint” and “batchTransferFrom” are similar, however they utilize a different variable to conduct the logic and represent the maximum of “uint256” in two different ways (“2**256 - 1” and “0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF”).

LowInefficient Struct Member AssignmentOpen

The statements between L26 and L29 can be grouped to a single instantiation and assignment as in its current state it conducts a full word update operation on each line.

LowInvalid Bit-Wise ConstantsOpen

Within the smart contracts, two bit-wise operands that are contradictory exist named “IS_NFT” and “NOT_IS_NFT”.

LowMisleading Function NameOpen

The function “_checkGemsQuantities” is meant to check the “gemQuantities” provided as arguments to the function, however it also alters them by subtracting 1 on each quantity before returning them.

LowOptimization of ID LogicOpen

The function “getValues” internally finds the maximum gem ID possible, instantiates an empty in-memory array with a length equal to that ID plus one and proceeds to utilize the array as a "mapping" of a gem's ID with its computed value.

LowRedundant Safe MathOpen

The statements of L67 conduct the same conditional checks whereby “allowance” is ensured to be greater than or equal to amount internally within the sub function of “SafeMathWithRequire”.

LowSmart Contract Structure LayoutOpen

The structure of the codebase does not conform to the official Solidity style guide of v0.6.5. An indicative excerpt of the style guide is that functions should be grouped according to their visibility and ordered: * constructor * receive function (if exists) * fallback function (if exists) * external * public * internal * private Additionally, the internal layout of a contract should be as follows: * Type declarations * State variables * Events * Functions However, these paradigms are not followed, increasing the illegibility of the codebase and rendering it harder to orient oneself within the codebase.

LowUnnecessary Named Return VariablesOpen

Within the codebase, multiple types of “return” variables are explicitly named in the function signature, however they are never utilized.

Show 2 more

LowUtilization of Utility FunctionsOpen

The functions “isApprovedForAll”, “isAuthorizedToTransfer” and “isAuthorizedToApprove” are functions that could be used within the require statements of L150 to L157, L178 to L181, L223, L257 and L274. Additionally, “isAuthorizedToTransfer” internally can call “isAuthorizedToApprove”.

LowValue Overriddence LogicOpen

The function “addCatalysts” accepts a “valueOverrides” array that signifies whether the values of a particular catalyst should be overridden. However, the logical check of L21 to L23 would make it impossible to override the value of the f.e. third catalyst without overriding all preceding values.