Certik Audit and what it means for Ulti Arena

So what’s up with the audit?

At last! What a long journey it has been to be audited by Certik. It drained a lot of our attention and time. Now that it’s ready, you can check it here: https://www.certik.org/projects/ultiarena

Now before you’re gonna scream RUG! because of those 3 major issues, here’s a bit of explanation why we decided to go that way and not the other. Ready for some deep dive into the smart contract code? Here we go:

Let’s begin with those Major severities:

Ok, so what you’re gonna do with those unfixed major issues?

CertiK has pointed out two major severity issues that we decided to leave without resolution, although acknowledged. Both of the issues are related to Ulti Arena teams ownership over the contract. The ownership in our opinion is crucial for the project to continue its success in the future.

1. GLOBAL-02 Privileged ownership says about the owner’s rights to change settings of the contract, to blacklist some accounts, and withdraw BNBs that could be frozen on the contract,
2. UCC-10 Centralized risk in _addLiquidity says about the owner being the receiver of LP tokens created from liquidity tax.

First of all, we would like to assure all of you that ownership over the contract will be never in the hands of one person. We have created a secure multi-signature team wallet (Gnosis Safe) which is controlled by the Ulti Arena team. Our team members also do hold cold storage wallets, the Nano X to be exact. For the sake of your own security, we recommend you store your private keys here too: https://shop.ledger.com/pages/ledger-nano-x

What’s more, the LP tokens are deliberately in the owner’s hands — in order to migrate the PancakeSwap liquidity pool when and if its router ever updates from v2 to newer versions (FYI locked LP in v1 will never migrate to v2 — talking about PancakeSwap/UniSwap here). In the future, we will be able and will consider transferring the ownership over UltiCoin to DAO or the community.

Fine, what about the rest?

GLOBAL-01 | 3rd party dependencies
We will keep monitoring the state of PancakeRouter and in case of any vulnerabilities detected will stop liquifying and update the router address.

TLC-01 | Function and variable naming doesn’t match the operating
environment
Recommendation applied in the latest, post-audit version of the contract.

TLC-02 | Missing event emitting
We acknowledge that. Missing events won’t be added since we are right below the max contract size limit.

UCC-01 | Declaring BEP20 on the whitepaper but using ERC20
Recommendation applied in the latest, post-audit version of the contract.

UCC-02 | Missing event emitting
We acknowledge that. Missing events won’t be added since we are right below the max contract size limit.

UCC-03 | Redundant parameter swapRouter
Recommendation applied in the latest, post-audit version of the contract.

UCC-04 | Redundant code
Recommendation applied in the latest, post-audit version of the contract.

UCC-05 | Potential reentrancy
The function call of _liquifyTokens() was moved to the end of the function.

UCC-06 | Transaction limit is not as desired
This one we found odd as nowhere in our whitepaper we stated anything about transaction limits.

UCC-07 | The balance of an account could exceed accountLimit when
_rTotal shrinks
We acknowledge that. Is ok to organically exceed that limit.

UCC-08 | Potential sandwich attack
Potential sandwich attacks could happen if calling

swapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens() andswapRouter.addLiquidityETH() without setting restrictions on slippage.

For example, let’s say ULTI: BNB = 100 in the pancakeSwap pool. And we would like to make a transaction of swapping 100 ULTI for 1 BNB, while a front runner could raise the price of BNB by swapping ULTI for BNB before our transaction. As a result, we might only get 0.9 BNB.

Read more here: https://hackernoon.com/no-sandwich-please-popular-defi-attack-strategy-analysis-jk1734rf

By the way, is it worth the effort to perform sandwich attack? As per Hackernoon:

Trading as many tokens as you can afford would be the most logical way to earn the most profit unless the DEX does not require you to pay a fee. For example, Uniswap takes a 0.3% fee for every transaction and the attacker has to commit at least two transactions. Also, let’s not forget about the Gas necessary to pay for each transaction, especially if you are front-running and have to pay more. All this leads us to the following conclusion: beyond the point where the fees and commissions are higher than the victim’s trade amount, the predator does not make any profit.

The idea of the sandwich attack is not new. The concept and possible effects on all the market members have been discussed since the idea of decentralized finance came up.

Certik recommended using Oracle to get an estimation of prices and setting minimum amounts based on the prices when calling the aforementioned functions. We acknowledge that and have already signed contract with Chainlink for their Oracle price feeds and also VRF product https://docs.chain.link/docs/chainlink-vrf/. Stay tuned for some co-marketing with Chainlink! Some precoutions will be taken too. We will keep each swap transaction small so the liquidity should not be affected much by the price changes.

Additional comments:

1. All recommendations and optimizations are present in the latest commit:
https://github.com/ultiarena/ulti-coin/commit/06bb774a2112d1bcd18615a5adadd2a601dceba9

2. Some additional changes had to be made because of the contract size being right below the max contract size limit.

You heard that? We wrote so much code that we reached the smart contract size limit!

Now, get some popcorn and let’s watch this beautiful code together: https://github.com/ultiarena/ulti-coin/blob/master/contracts/UltiCoin.sol

Ulti Arena is a NFT Marketplace and Community of Game Artists and Developers