---
title: REP-BosonToken
tags: final report, solidity, AH, AP
---
<table style="background-color: transparent; background-image: url(https://i.ibb.co/7rHDj7C/image.png); background-position: right bottom; background-repeat: no-repeat; background-size: contain; border: 0px solid transparent; margin: 0% 0% 0% 0%; padding: 0% 0% 0% 0%; table-layout: auto; width: 100%; height: 100%">
<tr>
<td style="border: 0px solid transparent">
<br/><br/>
<img src="https://i.imgur.com/T9h1pmN.png" style="background-color: transparent; filter: invert(0)" height="100pt" />
</td>
</tr>
<tr>
<td style="border: 0px solid transparent">
<h1>Boson Token</h1>
<h2></h2>
<h3>Security Assessment</h3>
<h4>March 2nd, 2021</h4>
<h4 style="color: tomato">&nbsp;</h3>
</td>
</tr>
<tr style="height: 4rem">
<td style="border: 0px solid transparent"></td>
</tr>
<tr>
<td style="border: 0px solid transparent">
By:<br/>
Alex Papageorgiou @ CertiK <br>
<a href="mailto:[e-mail]" style="color: rgb(249, 159, 28)">[e-mail]</a>
<br><br>Adrian Hetman @ CertiK <br>
<a href="mailto:[e-mail]" style="color: rgb(249, 159, 28)">[e-mail]</a>
<br>
</td>
</tr>
<tr style="height: 8rem">
<td style="border: 0px solid transparent"></td>
</tr>
</table>

<div style="page-break-after: always"></div>

## <img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/> Disclaimer

CertiK reports are not, nor should be considered, an "endorsement" or "disapproval" of any particular project or team. These reports are not, nor should be considered, an indication of the economics or value of any "product" or "asset" created by any team or project that contracts CertiK to perform a security review.

CertiK Reports do not provide any warranty or guarantee regarding the absolute bug-free nature of the technology analyzed, nor do they provide any indication of the technologies proprietors, business, business model or legal compliance.

CertiK Reports should not be used in any way to make decisions around investment or involvement with any particular project. These reports in no way provide investment advice, nor should be leveraged as investment advice of any sort.

CertiK Reports represent an extensive auditing process intending to help our customers increase the quality of their code while reducing the high level of risk presented by cryptographic tokens and blockchain technology.

Blockchain technology and cryptographic assets present a high level of ongoing risk. CertiK's position is that each company and individual are responsible for their own due diligence and continuous security. CertiK's goal is to help reduce the attack vectors and the high level of variance associated with utilizing new and consistently changing technologies, and in no way claims any guarantee of security or functionality of the technology we agree to analyze.

## What is a CertiK report?

- A document describing in detail an in depth analysis of a particular piece(s) of source code provided to CertiK by a Client.

- An organized collection of testing results, analysis and inferences made about the structure, implementation and overall best practices of a particular piece of source code.

- Representation that a Client of CertiK has completed a round of auditing with the intention to increase the quality of the company/product's IT infrastructure and or source code.

<div style="page-break-after: always"></div>

## <img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/> Overview

### Project Summary

<table>
<tr>
<td style="width: 30%"><strong><span>Project Name</span></strong></td>
<td><span>bosonprotocol</span></td>
</tr>
<tr>
<td><strong><span>Description</span></strong></td>
<td><span>A typical ERC20 implementation with enhanced features.</span></td>
</tr>
<tr>
<td><strong><span>Platform</span></strong></td>
<td><span>Ethereum; Solidity, Yul</span></td>
</tr>
<tr>
<td><strong><span>Codebase</span></strong></td>
<td><a href="https://github.com/bosonprotocol/token-contract"><span>GitHub Repository</span></a></td>
</tr>
<tr>
<td><strong><span>Commits</span></strong></td>
<td>
1. <a href="https://github.com/bosonprotocol/token-contract/commit/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1">9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1</a><br>
2. <a href="https://github.com/bosonprotocol/token-contract/commit/fa18812a7a30d18ab507e89945196aa084acdb8f">fa18812a7a30d18ab507e89945196aa084acdb8f</a>
</td>
</tr>
</table>

### Audit Summary

<table>
<tr>
<td style="width: 30%"><strong><span>Delivery Date</span></strong></td>
<td><span>March 2nd, 2021</span></td>
</tr>
<tr>
<td><strong><span>Method of Audit</span></strong></td>
<td><span>Static Analysis, Manual Review</span></td>
</tr>
<tr>
<td><strong><span>Consultants Engaged</span></strong></td>
<td><span>2</span></td>
</tr>
<tr>
<td><strong><span>Timeline</span></strong></td>
<td><span>February 24th, 2021 - February 24th, 2021</span></td>
</tr>
</table>
### Vulnerability Summary

<table>
<tr>
<td style="width: 30%"><strong><span style="background-color: transparent; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> <span>Total Issues</span></strong></td>
<td><span>5</span></td>
</tr>
<tr>
<td><strong><span style="background-color: tomato; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> <span>Total Critical</span></strong></td>
<td><span>0</span></td>
</tr>
<tr>
<td><strong><span style="background-color: darkorange; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> <span>Total Major</span></strong></td>
<td><span>0</span></td>
</tr>
<tr>
<td><strong><span style="background-color: gold; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> <span>Total Medium</span></strong></td>
<td><span>2</span></td>
</tr>
<tr>
<td><strong><span style="background-color: dodgerblue; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> <span>Total Minor</span></strong></td>
<td><span>0</span></td>
</tr>
<tr>
<td><strong><span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> <span>Total Informational</span></strong></td>
<td><span>3</span></td>
</tr>
</table>

<div style="page-break-after: always"></div>

## <img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/> Executive Summary

Standard ERC20 token with Permit and Pausable functionality. Code looks fine with some minor issues that needs to be addressed.

The team was quick to address the issues and resolved all of them.

<div style="page-break-after: always"></div>

## <img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/> Files In Scope

| ID | Contract | Location |
| :--- | :--------------- | :----------------------------------------------------------- |
| BTN | BosonToken.sol | [contracts/BosonToken.sol](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/BosonToken.sol) |
| ERC | ERC20Permit.sol | [contracts/ERC20Permit.sol](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/ERC20Permit.sol) |
| IER | IERC20Permit.sol | [contracts/IERC20Permit.sol](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/IERC20Permit.sol) |

<div style="page-break-after: always"></div>

## <img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/> File Dependency Graph

  %%{init: {'theme': 'base'},flowchartConfig: {'width': '50%'}}%%
  graph LR;
        BosonToken.sol --> ERC20Permit.sol
        BosonToken.sol --> AccessControl.sol
        
ERC20Permit.sol --> IERC20Permit.sol
        ERC20Permit.sol --> SafeMath.sol
        ERC20Permit.sol --> Pausable.sol
        

<div style="page-break-after: always"></div>

## <img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/> Findings

%%{init: {'theme': 'base'}}%%
pie
  title Finding Summary
  "Medium": 2
"Informational": 3

<table style="table-layout: fixed">
<tr style="height: 1em">
<td style="width: 5.6em; text-align: right"><span>ID</span></td>
<td><span>Title</span></td>
<td style="width: 10.75em"><span>Type</span></td>
<td style="width: 8.25em"><span>Severity</span></td>
<td style="width: 5.5em"><span>Resolved</span></td>
</tr>
<tr>
<td style="text-align: right">
<a href="#BTN-01">BTN-01</a>
</td>
<td>Unlocked Compiler Version</td>
<td>Language Specific</td>
<td>
<span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Informational
</td>
<td style="text-align: center">
<img
src="https://api.iconify.design/octicon:check-24.svg"
style="filter: invert(1); width: 1rem"
/>
</td>
</tr>
<tr>
<td style="text-align: right">
<a href="#BTN-02">BTN-02</a>
</td>
<td>BosonToken is not protected for the ERC20 approval race condition</td>
<td>Volatile Code</td>
<td>
<span style="background-color: gold; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Medium
</td>
<td style="text-align: center">
<img
src="https://api.iconify.design/octicon:check-24.svg"
style="filter: invert(1); width: 1rem"
/>
</td>
</tr>
<tr>
<td style="text-align: right">
<a href="#IER-01">IER-01</a>
</td>
<td>Unlocked Compiler Version</td>
<td>Language Specific</td>
<td>
<span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Informational
</td>
<td style="text-align: center">
<img
src="https://api.iconify.design/octicon:check-24.svg"
style="filter: invert(1); width: 1rem"
/>
</td>
</tr>
<tr>
<td style="text-align: right">
<a href="#ERC-01">ERC-01</a>
</td>
<td>Cross-chain replay attack</td>
<td>Volatile Code</td>
<td>
<span style="background-color: gold; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Medium
</td>
<td style="text-align: center">
<img
src="https://api.iconify.design/octicon:check-24.svg"
style="filter: invert(1); width: 1rem"
/>
</td>
</tr>
<tr>
<td style="text-align: right">
<a href="#ERC-02">ERC-02</a>
</td>
<td>Unlocked Compiler Version</td>
<td>Language Specific</td>
<td>
<span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Informational
</td>
<td style="text-align: center">
<img
src="https://api.iconify.design/octicon:check-24.svg"
style="filter: invert(1); width: 1rem"
/>
</td>
</tr>
</table>

<div style="page-break-after: always"></div>

### <a name="BTN-01"><img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/></a> BTN-01: Unlocked Compiler Version

| Type | Severity | Location |
| :---------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
| Language Specific | <span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Informational | <span class="informational">[BosonToken.sol L2](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/BosonToken.sol#L2)</span> |

#### <span class="informational">Description:</span>

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

#### <span class="informational">Recommendation:</span>

We advise that the compiler version is instead locked at the lowest version possible that the contract can be compiled at. For example, for version `v0.6.2` the contract should contain the following line:

pragma solidity 0.6.2;

#### <span class="informational">Alleviation:</span>

Issue resolved

<div style="page-break-after: always"></div>

### <a name="BTN-02"><img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/></a> BTN-02: BosonToken is not protected for the ERC20 approval race condition

| Type | Severity | Location |
| :------------ | :----------------------------------------------------------- | :----------------------------------------------------------- |
| Volatile Code | <span style="background-color: gold; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Medium | <span class="medium">[BosonToken.sol L7-L48](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/BosonToken.sol#L7-L48)</span> |

#### <span class="medium">Description:</span>

ERC20 implementation is not protected for the ERC20 approval race condition issue. That problem could be used in an attack that allows a spender
to transfer more tokens than the owner of the tokens ever wanted to allow the spender to transfer. Here is possible attack scenario:
1. Alice allows Bob to transfer N of Alice's tokens (N>0) by calling approve method on Token smart contract passing Bob's address and N as method arguments
2. After some time, Alice decides to change from N to M (M>0) the number of Alice's tokens Bob is allowed to transfer, so she calls approve method again, this time passing Bob's address and M as method arguments
3. Bob notices Alice's second transaction before it was mined and quickly sends another transaction that calls transferFrom method to transfer N Alice's tokens somewhere
4. If Bob's transaction will be executed before Alice's transaction, then Bob will successfully transfer N Alice's tokens and will gain an ability to transfer another M tokens
5. Before Alice noticed that something went wrong, Bob calls transferFrom method again, this time to transfer M Alice's tokens.

#### <span class="medium">Recommendation:</span>

We would advise to use OpenZeppelin ERC20 implementation as it includes `increaseApproval` and `decreaseApproval`. These functions only change the allowance by a certain value, instead of setting the new one.
It is commonly used protection against FrontRunning of ERC20's approve issue.

#### <span class="medium">Alleviation:</span>

Issue resolved

<div style="page-break-after: always"></div>

### <a name="IER-01"><img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/></a> IER-01: Unlocked Compiler Version

| Type | Severity | Location |
| :---------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
| Language Specific | <span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Informational | <span class="informational">[IERC20Permit.sol L2](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/IERC20Permit.sol#L2)</span> |

#### <span class="informational">Description:</span>

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

#### <span class="informational">Recommendation:</span>

We advise that the compiler version is instead locked at the lowest version possible that the contract can be compiled at. For example, for version `v0.6.2` the contract should contain the following line:

pragma solidity 0.6.2;

#### <span class="informational">Alleviation:</span>

Issue resolved

<div style="page-break-after: always"></div>

### <a name="ERC-01"><img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/></a> ERC-01: Cross-chain replay attack

| Type | Severity | Location |
| :------------ | :----------------------------------------------------------- | :----------------------------------------------------------- |
| Volatile Code | <span style="background-color: gold; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Medium | <span class="medium">[ERC20Permit.sol L35-L57](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/ERC20Permit.sol#L35-L57)</span> |

#### <span class="medium">Description:</span>

The constructor of the contract utilizes the chainid variable acquired during construction time f.e. the chainid of the current Ethereum chain is 1 if a fork occurs,
the new chain will have a different chainid than that of Ethereum. The PERMIT_TYPEHASH uses the chainid variable within it to prevent a permit from being replayed on both the main chain and the side chain however,
as the chainid is evaluated once during construction, the contracts of the main chain and the forked chain will have the same PERMIT_TYPEHASH thus allowing the attacker
to use the permit function on both chains whereas it should have only been used on one chain.

#### <span class="medium">Recommendation:</span>

Two ways to guard against this:

* Either compute PERMIT_TYPEHASH within the permit function. This will ensure permit is compatible on both chains however it would increase the gas cost.
* Leave the computation as is and add an additional check in the permit function that evaluates whether the current chainid is the same as the one when the contract was created. This will ensure permit is only compatible on the main Ethereum chain, however it will cost significantly less gas.

#### <span class="medium">Alleviation:</span>

Issue resolved

<div style="page-break-after: always"></div>

### <a name="ERC-02"><img src="https://i.ibb.co/jWvhSNT/image.png" style="height: 28pt; filter: invert(0)"/></a> ERC-02: Unlocked Compiler Version

| Type | Severity | Location |
| :---------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
| Language Specific | <span style="background-color: limegreen; border-radius: 50%; display: inline-block; height: 8pt; width: 8pt"></span> Informational | <span class="informational">[ERC20Permit.sol L2](https://github.com/bosonprotocol/token-contract/blob/9de583dfc3a60520b9dbde5b849d09cb4a6dd1b1/contracts/ERC20Permit.sol#L2)</span> |

#### <span class="informational">Description:</span>

The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

#### <span class="informational">Recommendation:</span>

We advise that the compiler version is instead locked at the lowest version possible that the contract can be compiled at. For example, for version `v0.6.2` the contract should contain the following line:

pragma solidity 0.6.2;

#### <span class="informational">Alleviation:</span>

Issue resolved

<div style="page-break-after: always"></div>
## Appendix

---

### Finding Categories

#### Gas Optimization

Gas Optimization findings refer to exhibits that do not affect the functionality of the code but generate different, more optimal EVM opcodes resulting in a reduction on the total gas cost of a transaction.
#### Mathematical Operations

Mathematical Operation exhibits entail findings that relate to mishandling of math formulas, such as overflows, incorrect operations etc.
#### Logical Issue

Logical Issue findings are exhibits that detail a fault in the logic of the linked code, such as an incorrect notion on how `block.timestamp` works.
#### Control Flow

Control Flow findings concern the access control imposed on functions, such as owner-only functions being invoke-able by anyone under certain circumstances.
#### Volatile Code

Volatile Code findings refer to segments of code that behave unexpectedly on certain edge cases that may result in a vulnerability.
#### Data Flow

Data Flow findings describe faults in the way data is handled at rest and in memory, such as the result of a `struct` assignment operation affecting an in-memory `struct` rather than an in-storage one.
#### Language Specific

Language Specific findings are issues that would only arise within Solidity, i.e. incorrect usage of `private` or `delete`.
#### Coding Style

Coding Style findings usually do not affect the generated byte-code and comment on how to make the codebase more legible and as a result easily maintainable.
#### Inconsistency

Inconsistency findings refer to functions that should seemingly behave similarly yet contain different code, such as a `constructor` assignment imposing different `require` statements on the input variables than a setter function.
#### Magic Numbers

Magic Number findings refer to numeric literals that are expressed in the codebase in their raw format and should otherwise be specified as `constant` contract variables aiding in their legibility and maintainability.
#### Compiler Error

Compiler Error findings refer to an error in the structure of the code that renders it impossible to compile using the specified version of the project.
#### Dead Code

Code that otherwise does not affect the functionality of the codebase and can be safely omitted.