Any cryptocurrency project relying on smart contract technology may want to have its code audited properly. In the case of FunFair, there are some growing concerns over the project’s alleged “trustless” nature. Although this part of the code is not necessarily used for malicious purposes, it raises some interesting questions regardless.
The FunFair Smart Contract Concerns
For those unfamiliar with FunFair, the project aims to position itself as a decentralized and trustless online casino using Ethereum’s smart contract technology. The project has been well received by the community so far. Moreover, it seems there is a lot of attention on the project’s code as of late. It is this scrutiny which highlights some potential concerns associated with the project as a whole.
As can be seen in this particular Reddit thread, the “Token” smart contract is the main cause of concern. Although it is put together rather well, there are some features which tend to make things look a bit different to the untrained eye. The “Transfer” part of the Token contract is linked to another contract. That means no one of the FunFair transactions are initiated from the Token contract itself, which tend sot obfuscate the real process a bit.
While one could argue this might be a bit of double-work first and foremost, the FunFair teams are not using this method for nefarious purposes. Unfortunately, it seems this “secondary” contract to transfer tokens is subject to some concern as well. The controller for token transfers can be set to any address by the contract owner.
There is only one owner, as this is not a multisignature address. Why that precaution was not taken, is difficult to determine. In this day and age, multisignature needs to be the go-to solution first and foremost. Even so, that is something the FunFair can easily address, if they ever feel the need to do so. It is unclear if they will do so, but it is a quality of life improvement for all parties involved.
There is also the “Ledger” contract of FunFair which has attracted some criticism in the past few days. It is the core portion of FunFair’s entire project, yet it seems the controller part of this contract could – in theory – grab all tokens from an exchange or other wallet through some of the built-in functionality. Agia, this has never been used in any capacity, but the code itself raises a fair few questions first and foremost.
It is evident these are two grave concerns which may not necessarily impact the FunFair project in an official capacity. At the same time, leaving these “loopholes” in the code can attract some attention from criminals who seek to exploit smart contract weaknesses to the fullest extent. Given the recent Oyster incident, issues like these will need to be addressed fairly soon.
One Comment