KyotoSwap

CertiKFiles named in the report

CertiK reviewed KyotoSwap on 21 Apr 2023: 17 findings, 0 critical; 5 marked fixed, 3 acknowledged, 9 open.

No open critical findings
Open the reportOpen KyotoSwap’s security record

Report hosted on skynet.certik.com.

Trustblock does not review code.

Findings17

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical000
High000
Medium031
Low904
MediumBurnt token not transferred to the "burn" addressFixed

In the contract `MasterChef`, the burnt token would not be transferred to the `address(0)` or the burn address(`0x000000000000000000000000000000000000dEaD`). It actually transfers the tokens to the `_owner` address. Also, almost 99%(`989202815829/1e12`) of the reward Kswap tokens will be transferred to the `_owner` address.

LowDead CodeFixed

In the contract `TokenLocker`, the function `redeem()` will call the function `LibTokenLocker.enforceLockExistsAndExpired()` to check the lock status before calling `LibTokenLocker.redeem()`. The function `LibTokenLocker.enforceLockExistsAndExpired()` will revert the transaction if the lock expiration time has not passed(`block.timestamp < lock.expiresAt`). However, the function `LibTokenLocker.redeem()` supports partial redemption before the `lock.expiresAt` by the following code snippet. The `if` condition will never be true when calling from `TokenLocker.redeem()`, otherwise, the transaction has already been reverted in the function `LibTokenLocker.enforceLockExistsAndExpired()`. On the contrary, the function `TokenLocker.deposit` supports partial redemption without calling the function `LibTokenLocker.enforceLockExistsAndExpired()`. Thus, the user can get partial redemption and all the previously locked token back. ```solidity=144 if (block.timestamp < lock.expiresAt) { reward = calculateRewardDiff( reward, lock.duration, (block.timestamp - lock.lockedAt) ); } ``` Also, the function `LibTokenLocker.redeem()` will burn all the locked amount and this contradicts the logic that the user can partially unlock and get the rewards.

LowInitial Value Of `lastRewardBlock`Fixed

The `lastRewardBlock` is initialize to `block.number + 200` when the `block.number >= _startBlockNumber`. Thus, the user may deposit immediately to the new added pool, but can only get rewards after 200 blocks.

LowMissing Zero Address ValidationFixed

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=530 treasury = _treasury; ``` - `_treasury` is not zero-checked before being used.

LowRecommended explicit pool validity checksFixed

There's no sanity check to validate if a pool is existing.

Contracts in scope

No deployed address is recorded for this audit.

The report names a repository or files. Open the report to see its scope.

Repository and files the report names (11)

  • contracts/WETH.sol
  • contracts/MasterChef.sol
  • contracts/KyotoSwapPair.sol
  • contracts/KyotoSwapERC20.sol
  • contracts/KswapToken.sol
  • contracts/KyotoSwapFactory.sol
  • contracts/token-locker/ITokenLocker.sol
  • contracts/KyotoSwapLibrary.sol
  • contracts/token-locker/TokenLocker.sol
  • contracts/token-locker/LibTokenLocker.sol
  • contracts/KyotoSwapRouter.sol

Part of KyotoSwap’s security record

KyotoSwap
Audits1 audit by 1 firmLast audit Apr 2023, by CertiK.
Critical findingsNo open critical findingsIn 1 report.
Open KyotoSwap’s security record

Security firm

CertiK

1,044 projects reviewed · 1,375 reports · latest May 2025

See CertiK’s audits

Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.

Tell us