SpaceChain V2 Contract Deployment Verification
- SpaceChainV2 (SPC)
The objective of the audit was to evaluate the security of the smart contract source code, deployment, and user tokens migration procedures. During the assessment, Coinspect identified the following issues:
User tokens could be lost during the migration process if special care is not taken, Coinspect recommends this fact is properly documented in the instructions provided to token owners.
The following report details the tasks performed during this engagement and its findings.
1. Source Code Review
The goal of the new SpaceChain token V2 is to replace the existing SpaceChain ERC20 token on Ethereum (Contract Address 0x8069080a922834460c3a092fb2c1510224dc066b) in order to better support the ERC20 standard interface with the purpose of being listed by many decentralized financial products. These are the features added to the new token version:
- Increase, decrease allowance
- Bool return values
Coinspect audited the new token’s source code and evaluated the proposed upgrade mechanism to determine if it is safe for the users migrating their tokens to the new version.
The assessment covered the master branch of the repository at https://github.com/spacechain/token-v2 up to (and including) commit bd8f266c1d99cce4e222a0bae4076df4ede80746 of September 21st, 2020:
Author: Jeff Garzik <email@example.com>
Date: Mon Sep 21 19:24:30 2020 -0400
SpaceChain.sol: fix ERC20 constructor call
The scope of the audit was limited to the following Solidity source files, shown here with their sha256sum hash:
A whitebox security audit was conducted on these smart contracts. The following threat scenarios were evaluated during this audit:
- Are the user tokens safe during the migration process?
- Does the new SpaceChain Token version alter the owner’s privileges in comparison to the previous version?
- Is there any way to inflate the token supply with the new version?
- Are the migration instructions provided to the end-user safe?
The token migration process is non-custodial and voluntary. Users choose when and how many tokens they want to upgrade. Users are encouraged to upgrade first small amounts of SPC in order to make sure they understand the process.
It is worth noting that SPC v1 tokens are upgraded to SPC v2 tokens on a 1:1 basis, the token supply remains capped at 1 billion.
The token migration procedure reviewed during this engagement is described in https://github.com/spacechain/token-v2/blob/master/ETHERSCAN-MIGRATION.md. SpaceChain also intends to provide users with a website to facilitate the procedure, this website was not part of this audit.
According to the above mentioned documentation the following opt-in upgrade process should be performed by users that wish to upgrade their SPC v1 tokens to the new version:
- Call the createUpgrader() function in the new token contract to create a user-owned vault contract. (Auditor’s note: the contract is actually not user-owned)
- User sends SPC v1 tokens to the address of their vault contract.
- User calls migrateV1tokens() function in the new token contract, which mints (credits) SPC v2 tokens, and burns (debits) SPC v1 tokens from the vault contract.
Coinspect found that if tokens could be lost during a chain reorganization if inexperienced users fail to wait enough confirmations before sending their tokens to the new vault. It is suggested to document this potential problem to prevent this from happening . This finding is fully detailed in User tokens lost during migrations because of blockchain reorganizations.
With regards to the test provided, it was limited to a simple use scenario. Coinspect suggests in the future more tests are developed before deployment. For example, a test should have been included to verify a new vault was not accessible from a third account. Coinspect was not able to verify the provided test passed as it requires an account with SpaceChainV1 tokens balance in Mainnet. Also, the test provided contained strings which did not correspond to this project.
2. Deployed Binary Code Verification
As a part of the additional tasks performed to ensure the SpaceChainV2 token contract was deployed safely, Coinspect verified the deployed smart contract bytecode, in order to guarantee no backdoors or unintended vulnerabilities were introduced.
Coinspect downloaded the contract creation bytecode from the blockchain and compared it with the output of the solc solidity compiler version 0.6.12+commit.27d51765, using 200 optimization runs. The metadata was removed from the bytecode before comparing the sha256 hashes of the locally compiled code and the code deployed:
Initially, Coinspect found the locally compiled contract did not match the version deployed in the blockchain. This was caused because the version in the repository had the parameters to the ERC20 constructor inverted. This is detailed in ERC20 constructor parameters inverted. After fixing this we were able to verify the deployed contract matched the source code in the repository.
2. Contract Initialization
The new SpaceChainV2 token contract address is:
This contract was deployed by:
Contract creation transaction:
The smart contract behavior is not mandated by any parameters supplied during deployment, nor does require any additional initialization steps after being created.
Click here for the full report.