Float Capital Optimizations

December 10, 2021

1. Preface

The team of Float Capital contracted byterocket to conduct a smart contract audit of on optimization upgrade. The upgrade consists of a new method of storage packing and gas optimizations. Float Capital is a  “peer-to-peer, yield-enhanced, floating synthetic asset exposure mechanism”. They describe themselves as “the easiest and safest way for users to buy synthetic assets. Users do not need to worry about over-collateralization, or suddenly getting liquidated”.

Their smart contracts are being updated to introduce a new storage packing method within the contract. A significant gas optimization is the result of this change.

There are no changes in the logic, only the storage layout changed. The new functionality is contained in the LongShort.sol  and Staker.sol files. During this audit, we only focused on changes that have been made because of this upgrade.

The team of byterocket reviewed and audited the above smart contracts in the course of this audit. We facilitated the audit on December 10th, 2021.

  • Manual Multi-Pass Code Review
  • In-Depth Protocol Analysis
  • Automated Code Review
  • Formal Report

byterocket gained access to the code via their public GitHub repository as well as a private development repository. We based the audit on the dev branch’s state from December 8th, 2021 (commit hash 18115384bab3894ad277fe5daadf88244295e14e).

2. Manual Code Review

We conducted a manual multi-pass code review of the smart contracts mentioned in section (1). Three different people went through the smart contract independently and compared their results in multiple concluding discussions.

These contracts are written according to the latest standards used within the Ethereum community and the Solidity community’s best practices. The naming of variables is very logical and understandable, which results in the contract being useful to understand. The code is very well documented and up to the latest standards.

Due to the very structured and open process that is being used for contract development at Float Capital, it was very easy for us to gain insights in certain motivations and ideas behind the changes and implementations. Additionally, the team is working on the forefront of novel testing methods and techniques for smart contracts, which also made this a very pleasant endeavor for us.

On the code level, we found no bugs or flaws. A further check with multiple automated reviewing tools (MythX, Slither, Manticore, and different fuzzing tools) did not find any additional bugs.

3. Protocol/Logic Review

Part of our audits are also analyses of the protocol and its logic. A team of three auditors went through the implementation and documentation of the implemented optimization.

We went through all of the provided documentation, tests and contracts in a very detailed manner. The opimizations where explained to us prior to the audit by the development team.

Since this upgrade contains no changes to the overall logic of the protocol, we have mainly focused on the storage layout and its usage.

We were not able to discover any problems in the storage layout implementation in the smart contract.

3.1 Optimization Implementation

The upgrade contains mostly changes to introduce storage packing, like for example this storage variable

mapping(uint32 => mapping(bool => uint256)) public override marketSideValueInPaymentToken;

has been changed from a double mapping to a mapping containing a struct:

struct MarketSideValueInPaymentToken {
 // this has a maximum size of `2^128=3.4028237e+38` units of payment  
    token which is amply sufficient for our markets
 uint128 value_long;
 uint128 value_short;
}
mapping(uint32 => MarketSideValueInPaymentToken) public override marketSideValueInPaymentToken;

Additionally, there are some minor functions that have been added in order to allow the existing logic to interact with the new storage layout efficiently and distinguish between contracts that still have data in their storage following the old logic. The functions are for example get_syntheticToken_priceSnapshot or get_syntheticToken_priceSnapshot_side. We have not found any issues in these functions or the storage changes.

4. Summary

During our code review (which was done manually and automated), we found no bugs or flaws. Our automated systems and review tools also did not find any additional ones.

The protocol review and analysis did neither uncover any game-theoretical nature problems nor any other functions prone to abuse. We have not found any logical errors in the implementation.

In general, we are delighted with the overall quality of the code and its documentation. Additionally, there are extensive tests and even a custom testing framework, covering all of the functionality of the system.

Disclaimer

As of the date of publication, the information provided in this report reflects the presently held understanding of the auditor’s knowledge of security patterns as they relate to the client’s contract(s), assuming that blockchain technologies, in particular, will continue to undergo frequent and ongoing development and therefore introduce unknown technical risks and flaws. The scope of the audit presented here is limited to the issues identified in the preliminary section and discussed in more detail in subsequent sections. The audit report does not address or provide opinions on any security aspects of the Solidity compiler, the tools used in the development of the contracts or the blockchain technologies themselves, or any issues not specifically addressed in this audit report.
The audit report makes no statements or warranties about the utility of the code, safety of the code, suitability of the business model, investment advice, endorsement of the platform or its products, the legal framework for the business model, or any other statements about the suitability of the contracts for a particular purpose, or their bug-free status.

To the full extent permissible by applicable law, the auditors disclaim all warranties, express or implied. The information in this report is provided “as is” without warranty, representation, or guarantee of any kind, including the accuracy of the information provided. The auditors hereby disclaim, and each client or user of this audit report hereby waives, releases and holds all auditors harmless from, any and all liability, damage, expense, or harm (actual, threatened, or claimed) from such use.

Stored on IPFS

We store our public audit reports on IPFS; a peer-to-peer network called the "Inter Planetary File System". This allows us to store our reports in a distributed network instead of just a single server, so even if our website is down, every report is still available.

Learn more about IPFS
Signed On-Chain

The IPFS Hash, a unique identifier of the report, is signed on-chain by both the client and us to prove that both sides have approved this audit report. This signing mechanism allows users to verify that neither side has faked or tampered with the audit.

Check the Signatures