checklist

Project Self-Questioning Checklist

Starting a Project

• What is a quick overview Simple network where crypto asset owners can publish offers to sell them and buyers ca find those offers and in a secure manner, trade FIAT for the assets. In case of dispute, a chosen arbitrator steps in a resolves the issue.
• Where is the Specification Documentation
  • TODO: add here
• Does it hold money? Yes
  • how much? Depends on the number of trades (escrows) and the quantity sellers are selling. It could be really high if we have a lot of users and they sell high values.
  • who controls it? During the trade, the assets are in the Escrow contract. Once the trade is completed, the sold assets are transfered to the buyer, or returned to the seller. The fees (1% as of 15/06/19) are then sent to the arbitrator and/or to the burning contract. That contract contains functions to trade the assets to SNT and then burn the SNT. All those contracts are owned by a multisig.
  • how complex is its flow?
    • TODO: unclear
  • is it locked up for a period of time ever?
    • In the Escrow, until the trade is resolved or a dispute is opened and resolved. The assets can also be refunded to the seller if the buyer doesn't pay the FIAT and the expiration date is reached (5 days)
    • If the Staking pool will be used, all fees and licenses cost will be sent to this contract.
    • For non SNT fees, these are sent to the KyberFeeBurner contract which will hold the funds until someone calls the swap() function with the specific asset address, and then the asset will be converted to SNT and immediatly sent to the burn address or staking pool contract.
• How many smart contracts should it take to complete?

  • The basic flow depends on 4 contracts: Proxies for SellerLicenses, ArbitratorLicenses, MetadataStore and Escrow, with interactions with ERC20 contracts.

  • Flow can get more complex when the EscrowRelay is used for gasless transactions. In this case Interaction with Gas Station Network's RelayHub contract is required.

  • How complex is their interaction?

    • Calls between contracts that generate internal transactions, and use of signatures / nonces for updating user data on the MetadataStore contract, and also for gasless transactions.
    • Optional methods that accept signatures are available too in the Escrow contract but not used in the UI
• Is this project core to your business model?
  • Does it control finances?
    • TODO
  • Does it influence user adoption? Yes
  • Does it lock up significant portions of your assets? No
  • Is it unique to your business? No
• How many users will it have?
  • Upon its deployment to mainnet?
    • TODO
  • Over time?
    • How does its footprint on the blockchain grow?
    • TODO
• How many types of users will it have? 4 types: Buyers, Sellers, Arbitrators, and Multisig for parameter setup (this multisig should be replaced by a DAO once it is available.)
  • Have you detailed their abilities within the project explicitely?
    • TODO
• How complex is the front end? Medium. The inetractions are quite simple, but there are a few steps and pages.
  • Is the FE's sole purpose to interact with the contract(s)? No. It also facilitates finding sellers, but all in all, it's all for the purpose of creating offers, interacting with trades and disputes, which are all contract functions.
• Does it intergrate with other things? Yes. It integrates with Google Maps to show the aproximate location of sellers (their own choice of precision). Also uses cryptocompare to get the asset prices.
• Will it need to be upgraded? Yes
  • How often Depends on bug fixes and new features released
  • How complex is the migration to (a) new contract(s)? It requires the deployment of the new contracts versions, which could contain an optional initialization function, and then, a transaction executing upgradeTo / upgradeToAndCall with the init function parameters should be sent (these parameters should be ABI encoded). This should be done via the multisig.
• Does it have novel/complex cryptography or math functions? No. The complex math is done in the fee calculation to determine the fee percent that is going to be burned. If the staking pool contract is going to be used, some moderate complex calculations are done there to determine the tSNT/SNT convertion rate.

Wrapping up a Project

• Have you run analyzers on the contracts? Yes
  • Which ones? Slither, Crytic, Solhint
  • Where are the results and their response write-ups?
    • TODO
• Has the specification sheet been updated throughout the project? No
  • How often?
• Have you performed any STRIDE sessions to hunt for vulnerabilities? No
  • Where are the write-ups for these?
• Has it been tested on a testnet? Yes, Rinkeby and Ropsten
  • What are the contract details for these deployments?
    • TODO (contract details? probably is referring to address, abi, etc..)
• Has it gone through an internal stress test? Small ones. We are planning on doing others with the Status QA team
• Is the front-end completed? Yes, the contract interactions are. The design and UX might be improved
• Do you have an upgrade or succession plan in place? Yes, we have upgradable contracts, with plans to upgrade the owner to a DAO or no one.
• Is front-running a potential problem? No. There's no order book. Interactions between seller and buyers are unique, so other transactions will not affect these except by decreasing the seller's balance depending on the number of transactions they participate.

---

Notes from ToB Article

These notes are used to prepare for a formal audit, and should be performed before engaging an external professional. By not doing them, you are wasting time and money.

• Have all compiler warnings been addressed?
  • Are you using the latest compiler to check for errors?
  • What compiler will you use to deploy the contract and why?
• Have tests been updated to the latest version of the code?
  • How much code coverage do you have?
• Has all unused code and libraries been eliminated from the codebase?
• Have all functions been commented to explain what their intended use is?
• Have all complex code blocks been commented to describe what they do?
• Have all complicated tests been commented to describe what they are testing, and their expected results (both positive and negative)?