Skip to main content

Security

Open-source​

Referring to the purpose of having Web3 or any decentralized network, they are created to demolish "trust". Sigmaswap encourages everyone to learn and understand all details in the protocol before making any decision and interaction. Everything is published through multiple platforms(i.e. docs, github, medium) to deliver updates and resources to all Sigmaswap users. Everyone is able to verify every single component in the protocol without a permission.

Formal Verification​

Since security is one of the main priorities of Sigmaswap, it is critically essential to every Sigmaswap team member to review and formally verify all components of the Sigmaswap smart contracts.

The scope of review includes:

  • Formal verification of the core smart contracts
  • Pre and post-deployed code review of smart contracts
  • Numerical error analysis
  • Loophole ( by code design and technical problems) Check
  • Finalization

Although the process is completed, the code is still considered unsafe and will not be launched to the public or taken into effect, until it is audited.

Audit​

All new features or updates must be submitted to an external smart contract auditing organization as the final stop. Each contract must pass all the safety checks of at least one designated auditor before its deployment. Users can also expect to see 2 or more contract auditors for a certain contract. Audit reports will be announced once completed.

Bug Bounty​

Sigmaswap has a bug bounty program to reward developers who can find the bugs.

Considerations when building on Sigmaswap​

When integrating Sigmaswap into another on-chain system, particular process must be taken to avoid security vulnerabilities, avenues for manipulations, and the potential loss of funds.

note

Direct interactions offer maximal flexibility but require the most work to get right. Mediated interactions offer more limited capabilities but stronger safety guarantees.

The Case of Uniswap​

According to Uniswap, there are two primary categories of risk associated with UniswapV2 that could happen at any time due to the Ethereum network system.

  • The first involves so-called "static" errors. These can include sending too many tokens to a pair during a swap (or requesting too few tokens back) or allowing transactions to linger in the mempool long enough for the sender's expectations about prices to no longer be accurate.
  • "Dynamic" risk, the second category, involves runtime pricing. Because Ethereum transactions occur in an adversarial environment, naively written smart contracts can, and will be exploited for profit. For example, suppose a smart contract checks the asset ratio in a Uniswap pool at runtime and trades against it, assuming that the ratio represents the "fair" or "market" price of these assets. In this case, 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 highly liquid pools, or at low values.)
As Sigmaswap is operated on Hedera Hashgraph, the issues mentioned above are fixed by the network design. However, situation awareness should be kept in mind as there could be unknown issues happening in the future.

Price Feed​

Data is one of the most valuable things on the internet. Uncountable exploits are caused by relying on unsafe or manipulated data sources. The best way to prevent these attacks is to introduce a price oracle. An oracle is any device that returns desired information, in this case, a pair's spot price. The best "oracle" is simply a traders' off-chain observation of the prevailing price, which can be passed into the trade as a safety check. This strategy is the best suited to retail trading venues where users initiate transactions on their own behalf. However, it is often the case that a trusted price observation is not available (e.g., in multi-step, programmatic interactions involving Sigmaswap). Without a price oracle, these interactions will be forced to trade at whatever the (potentially manipulated) rate on Sigmaswap is. For details on the Sigmaswap approach to oracles, see Oracle.

Explorer​

To verify processes and correctness of all transactions, please visit Hashscan.