Security
Audit & Formal Verification
Between October 30th, 2020 – November 5 th, 2020, Hacken team reviewed and formally verified crucial components of the smart contracts for Whiteswap.
Their past work includes formal verification, security assessment, blockchain protocol security.
The scope of work includes:
Commonly known vulnerabilities scanning
Analysis of code functionality
Manual audit
Bug Bounty
WhiteSwap has an open and ongoing bug bounty program. Read about Bug Bounty
Considerations When Building on WhiteSwap
When integrating WhiteSwap into another on-chain system, particular care must be taken to avoid security vulnerabilities, avenues for manipulations, and the potential loss of funds.
As a preliminary note: smart contract integrations can happen at two levels: directly with Pair contracts, or through the Router. Direct interactions offer maximal flexibility, but require the most work to get right. Mediated interactions offer more limited capabilities, but stronger safety guarantees.
There are two primary categories of risk associated with WhiteSwap. The first involves so-called “static” errors: accidentally sending too many tokens to a pair during a swap (or requesting too few tokens back), allowing transactions to linger in the mempool long enough for the sender’s expectations about prices to no longer be true, etc. These errors are typically addressed with fairly straightforward logic checks. Performing these checks is the primary reason for the existence of routers. Those who interact directly with pairs must perform these checks themselves (with the help of the Library).
The second risk category is “dynamic”, and involves runtime pricing. Because Ethereum transactions occur in an adversarial environment, naively written smart contracts can be exploited for profit. For example, if a smart contract checks the asset ratio in a WhiteSwap pool at runtime and trades against it, assuming that the ratio represents the “fair” or “market” price of these assets, it is highly vulnerable to manipulation. A malicious actor could e.g. trivially insert transactions before and after the naive transaction (a so-called “sandwich” attack) causing the smart contract to trade at a radically worse price, profit from this at the trader’s expense, and then return the contracts to their original state, all at a low cost. (One important caveat is that these types of attacks are mitigated by trading in extremely liquid pools and/or at low values).
The best way to protect against these attacks is to introduce a price oracle. The best “oracle” is simply traders’ off-chain observation of the prevailing price, which can be passed into the trade as a safety check. This strategy is best suited to retail trading venues where users initiate trades on their own behalf. However, it is often the case that a trusted price observation cannot be obtained (e.g. in multi-step, programmatic interactions involving WhiteSwap). Without a price oracle, these interactions are forced to trade at whatever the (potentially manipulated) rate on WhiteSwap is. However, an oracle can bound manipulation, and is a sine qua non. Determining the ideal oracle for a given setting is out of scope, but for details on the WhiteSwap approach to oracles, see Oracles.
Last updated