In the contract, `SynCitySwapper`, the role, `_owner`, has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to `_owner` may allow the hacker to take advantage of this.

![](https://accelerator-tasks-prod.s3.amazonaws.com/91a0f5c398244edcb34fdfa6fef7da08/SynCitySwapper-_owner.svg)

---

In the contract, `SynCityPasses`, the role, `_owner`, has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to `_owner` may allow the hacker to take advantage of this.

![](https://accelerator-tasks-prod.s3.amazonaws.com/91a0f5c398244edcb34fdfa6fef7da08/SynCityPasses-_owner.svg)

---

In the contract, `SynCityBlueprints`, the role, `_owner`, has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to `_owner` may allow the hacker to take advantage of this.

![](https://accelerator-tasks-prod.s3.amazonaws.com/91a0f5c398244edcb34fdfa6fef7da08/SynCityBlueprints-_owner.svg)

---

In the contract, `SynCityCoupons`, the role, `_owner`, has the authority over the functions shown in the diagram below.

Any compromise to the privileged account which has access to `_owner` may allow the hacker to take advantage of this and the function `burn` is merely called by `swapper` which is used to burn any token by specified `tokenId`.

![](https://accelerator-tasks-prod.s3.amazonaws.com/0b2e21319e5143fa9bde15a927e663a5/SynCityCoupons-_owner.svg)

Centralization Related Risks

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing emit events

```solidity=37
function setMarketplace(address _marketplace) external {
  require(_marketplace != address(0), "_marketplace cannot be 0x0");
  marketplace = _marketplace;
}
```

The function `setMarketplace` is used to modify the value of `marketplace` which would get the new token is minted by function `batchTransfer`.

Privileged Function

```solidity=111
require(_conf.remaining[typeIndex] > 0, "no more tokens in this category");
```

Since the function `claimFreeToken` is used to claim a new token, it is better to change the `require` condition to greater than one.

Gas Optimization

The order of external call/transfer and storage manipulation must follow the check effect interaction pattern.

Check Effect Interaction Pattern Violated

The functions `isSignedByValidator` and `encodeForSignature` are declared as `public`, and they are used to validate the `_signature`. Why are they declared as `public`? Is it possible to be declared them as `private`?

There are similar questions on contract `SynCityPasses`.

Function Visibility Optimization

MOBLAND NFT

SynCitySwapper.sol

SynCityCoupons.sol

SynCityBlueprints.sol

SynCityPasses.sol

In the contract, `SyndicatePoolFactory`, the role, `_owner`, has authority over the functions shown in the diagram below.

Any compromise to the `_owner` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/fe08f2cc417c41a0b9967ebaf6aed09c/SyndicatePoolFactory-_owner.svg)

In the contract, `SyndicatePoolFactory`, the role, `poolExists`, has authority over the functions shown in the diagram below.

Any compromise to the `poolExists` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/fe08f2cc417c41a0b9967ebaf6aed09c/SyndicatePoolFactory-poolExists.svg)

---

In the contract, `SyndicateCorePool`, the role, `vault`, has authority over the functions shown in the diagram below.

Any compromise to the `vault` account may allow the hacker to take advantage of this authority.

![](https://accelerator-tasks-prod.s3.amazonaws.com/fe08f2cc417c41a0b9967ebaf6aed09c/SyndicateCorePool-vault.svg)

---

In the contract `SyntheticSyndicateERC20` the role `ROLE_TOKEN_CREATOR` has authority over the functions shown in the diagram below. 

- function mint(): can mint tokens to any user.

In the contract `SyntheticSyndicateERC20.sol` the role `ROLE_TOKEN_DESTROYER` has authority over the functions shown in the diagram below. 

- function burn(): burn tokens from anyone who is `ROLE_WHITE_LISTED_RECEIVER`.

---

In the contract `EscrowedSyndicateERC20`, the role `ROLE_RECEIVERS_MANAGER` has the authority over the following function:

- `updateAllowedReceivers()`: decided the user can whether receive the `Escrowed Syndicate`.

In the contract `Syndicate` and `EscrowedSyndicateERC20`, the role `ROLE_TOKEN_CREATOR` has the authority to mint tokens.

In the contract `Syndicate`, the role `ROLE_TOKEN_DESTROYER` has the authority to burn anyone's `Syndicate`.

In the contract `Syndicate`, the role `FEATURE_DELEGATIONS` has the authority to make someone delegate another user.

Any compromise to the privileged ownership account may allow a hacker to take advantage of this authority and burn tokens.

Centralization Risk

`setMigrator()` function can set migrator contract to any contract that is implemented from `IMigrator` interface by the owner. As result, invocation of `migrator.receiveDeposits()` in function migrate() may bring dangerous effects as it is unknown to the user. And the tokens in the contract will be transferred to the migrator contract. However, the project may lose the ability to upgrade and migrate if `setMigrator()` and `migrate()` are removed.

Unknown Implementation of migrator.migrate()

The main function of `Syndicate` protocol is providing `Syndicate` mining pool.

  1. the protocol publishes two `ERC20` token: Syndicate and Escrowed Syndicate.
  2. The `SyndicatePoolFactory` can create `SyndicateCorePool` and register it.
  3. The `SyndicateFlashPool` can be created by anyone and the `owner` of the `SyndicatePoolFactory` can register it into the `factory`.
  4. Each kind of token corresponds to one pool. If one kind of token is registered to a pool, it can not be registered to another pool again.
  5. The pool whose `poolToken` is not `Syndicate` will accumulate rewards and stake them to the pool whose `poolToken` is `Syndicate` by the function `stakeAsPool()`. The rewards staked by the function `stakeAsPool()` will participate in the rewards accumulation in the `Syndicate` pool as same as the normal token staked to the pool.
  6. Every stake is recorded as the `deposit` in the contract and the `deposit` has an expiry date. User can withdraw their Syndicate from the `deposit`.

And then, there are some questions:

  1. Is the pool with `Syndicate` as the `poolToken` a `SyndicateCorePool`. Are those pools whose `poolToken` are not `Syndicate` `SyndicateFlashPool`?
  2. The function `_unstake()` checks the `lockUntil` of `deposit`. However, the contract has the function `updateStakeLock` which can change the `lockUntil` of the specified `deposit`. It makes the checks in the `_unstake()` meaningless.

Financial Models

The function `_stake` lacks validation for the state variable `poolToken`. The variable `poolReserve` is used to record the balance of `SyndicateERC20` token in the contract.

Lack of validation for `poolToken`

If the `poolToken` is a deflationary token, the `amount` may be less than the input number.

The `amount` may not be accurate

All of the `SyndicateERC20` tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute `SyndicateERC20` tokens without obtaining the consensus of the community.

Initial token distribution

```solidity=20
*      - Maximum final token supply: 10,000,000 SYN
```

```solidity=769
function mint(address _to, uint256 _value) public {
  // check if caller has sufficient permissions to mint tokens
  require(isSenderInRole(ROLE_TOKEN_CREATOR), "insufficient privileges (ROLE_TOKEN_CREATOR required)");

  // non-zero recipient address check
  require(_to != address(0), "ERC20: mint to the zero address"); // Zeppelin msg

  // non-zero _value and arithmetic overflow check on the total supply
  // this check automatically secures arithmetic overflow on the individual balance
  require(totalSupply + _value > totalSupply, "zero value mint or arithmetic overflow");

  // uint192 overflow check (required by voting delegation)
  require(totalSupply + _value <= type(uint192).max, "total supply overflow (uint192)");
```

Refer to the L20 comment `Maximum final token supply: 10,000,000 SYN`. The function `mint` may issue more tokens than the issuance limit.

Potential Over Mint

```solidity=473
// depending on `FEATURE_UNSAFE_TRANSFERS` we execute either safe (default)
// or unsafe transfer
// if `FEATURE_UNSAFE_TRANSFERS` is enabled
// or receiver has `ROLE_ERC20_RECEIVER` permission
// or sender has `ROLE_ERC20_SENDER` permission
if(isFeatureEnabled(FEATURE_UNSAFE_TRANSFERS)
  || isOperatorInRole(_to, ROLE_ERC20_RECEIVER)
  || isSenderInRole(ROLE_ERC20_SENDER)) {
```

Referring to the L477 comments, the `if` condition should verify the permission of `sender` instead of `msg.sender`.

Inconsistent Comments and Code

The `DOMAIN_TYPEHASH` is different from the implement in: https://eips.ethereum.org/EIPS/eip-712#rationale-for-typehash.

- `string name` - the user-readable name of signing domain, i.e. the name of the DApp or the protocol.
- `string version` - the current major version of the signing domain. Signatures from different versions are not compatible.
- `uint256 chainId` - the EIP-155 chain id. The user agent should refuse signing if it does not match the currently active chain.
- `address verifyingContract` - the address of the contract that will verify the signature. The user-agent may do contract-specific phishing prevention.
- `bytes32 salt` - a disambiguating salt for the protocol. This can be used as a domain separator of last resort.

Not standard implement

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing error messages

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables that could be declared as immutable

The function `updateStakeLock()` calls the function `_processRewards()` and passes `false` as the variable `_withUpdate`. So, the function `_processRewards()` will accumulate the user's rewards without updating `user.subYieldRewards`. It may let the user can get the rewards repeatedly.

Lack of updates of `user.subYieldRewards`

The state variable `minLockTime` has no function to modify. If it is set a wrong number, the only way to change it will be deploying a new contract. So, it is necessary to add basic checks on this variable.

Lack of Input Validation

The function `changePoolWeight(address, uint32)` is used to change the `weight` of the `pool` but the previous rewards were ignored.

MOBLAND PROTOCOL

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

6

0

1

0

5