# Bounty Programme

### Scope of Business <a href="#t1" id="t1"></a>

Tokenlon 5.0 Smart contract：

Smart contract address：[0x03f34bE1BF910116595dB1b11E9d1B2cA5D59659](https://etherscan.io/address/0x03f34bE1BF910116595dB1b11E9d1B2cA5D59659)

### Processing Flow <a href="#t2" id="t2"></a>

#### Reporting Stage <a href="#t2-1" id="t2-1"></a>

There are two ways to do this:

1. The reporter visits "Bugrap" website and goes to "Submit Bug Bounty" (URL：<https://bugrap.io/bounties/Tokenlon>) to submit a threat intelligence. (Status: to be review)
2. Report directly to the Tokenlon team at <security@tokenlon.im>

#### Processing Stage <a href="#t2-2" id="t2-2"></a>

1. &#x20;The Tokenlon team will receive the vulnerability report within 1 working day, and start reviewing the threat (Status: Under review) while informing the development team.
2. Within three working days, the Tokenlon technical team will deal with the problem, draw conclusions and record points (Status: confirmed / ignored). They will communicate with the reporter if necessary, and ask the reporter for assistance.

#### Repairing Stage <a href="#t2-3" id="t2-3"></a>

1. The Tokenlon business department shall repair the security problems in the threat intelligence and update online (status: repaired). The repairing timeframe depends on the problem severity and the repair difficulty. Generally speaking, it is within 24 hours for the critical and high-risk problems, within 3 working days for the medium-risk problems, and within 7 working days for the low-risk problems. The App security issue is limited by the version release, and the repairing timeframe is on a case-by-case basis.
2. The reporter will review whether the security problem has been repaired (Status: reviewed/reviewed with objection).
3. After the reporter confirms that the security problem is repaired, the Tokenlon technical team will inform the Bugrap Security Team of the conclusion and the vulnerability score. Tokenlon will issue rewards with the Bugrap Security Team (status: completed).

### Vulnerability Level and Reward Standards <a href="#t3" id="t3"></a>

| Level    | Tokenlon Reward\* |
| -------- | ----------------- |
| Critical | $10000 \~ $50000  |
| High     | $2500 \~ $10000   |
| Medium   | $1000 \~ $2500    |

\*Remark: The final award depends on the severity of the vulnerability and the true impact of the vulnerability.

#### Determining Severity <a href="#determining-severity" id="determining-severity"></a>

![](/files/ldWVWZJy6CtPRrcXKkhO)

**Critical Vulnerabilities**

A critical vulnerability refers to the vulnerability that occurs to the core business of a smart contract, which could result in the tokens owned by the platform or users being transferred, stolen, or frozen. Or taking control of the business system, and thus the core system getting affected.

#### High-risk Vulnerabilities <a href="#t3-2" id="t3-2"></a>

A high-risk vulnerability refers to that owing to the incorrect processing of the contract programs, the contract get exploited and arbitraged, involving money loss but not on a large-scale. Or contract defects like smart contract overflow, precision problems, and system check bypass.

#### Medium-risk Vulnerabilities <a href="#t3-3" id="t3-3"></a>

A medium-risk vulnerability refers to a vulnerability that can affect users only by interaction. For example, the data of the user's operation is affected due to improper page access. (Tokenlon.im)

#### Vulnerability related examples <a href="#t3-4" id="t3-4"></a>

* Cause permanent asset loss or freezing of funds in the system
* User funds can be stolen
* Contract can be re-entry attacked
* Can be taken control of the business system
* Smart contract overflow

#### Other metrics <a href="#t3-5" id="t3-5"></a>

In addition to the severity, the following factors are also the criteria for the Tokenlon technical team to consider the amount of bounty.

* Have a clear description of the vulnerability
* Provide test code or instructions to reproduce the vulnerability
* Provide methods to fix vulnerabilities


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tokenlon.gitbook.io/docs/docs.en/contribute-gong-xian/bounty-programme.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.