<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectButton />

<username>{{ maskedUsername }}</username><space /><text>just voted for</text><space /><projectLogo /><space /><projectName>{{ projectName }}</projectName>

Bug Bounty rewards are grouped by severity and the impact of the vulnerability. Examples and descriptions of the type of vulnerabilities that correspond to each severity level can be found below. The payout amount has a 5 tier structure with separate scalesfor website/apps and smart contracts.

Description of vulnerability and your proof of concept or validation steps

Name

Please input a title

Short description of the vulnerability and the affected asset.

The core team is situated in country(ies) that received low aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests an increased difficulty and complexity in preventing and mitigating fraud.

The core team is situated in country(ies) that received medium aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests a medium level of geographic accountability, thus reducing and mitigating the risk of fraud.

The core team is situated in country(ies) that received the best aggregated ratings in terms of international judicial cooperation, criminal justice system, anti-money laundering, and corruption. This contextual data suggests the highest level of geographic accountability, thus maximizing the risk reduction and mitigation.

Vulnerability Title

In the contract `Aggregator` the role `_owner` has authority over the functions shown in the diagram below.
![](http://accelerator-tasks-prod.s3.amazonaws.com/25d6098d-448a-4be3-8a67-b9114ef163bd/diagrams/centralization_InternalContract-Aggregator-_owner.svg)
![](http://accelerator-tasks-prod.s3.amazonaws.com/25d6098d-448a-4be3-8a67-b9114ef163bd/diagrams/centralization_InternalContract-Aggregator-owner.svg)

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

- function `destroy`: to transfer all the `PLI` tokens in the contract to the `owner` role and call the `selfdestruct(owner)` function that is not in the scope of this audit.
- function `updateRequestDetails`: to update the arrays of `oracles`, `_minimumResponses`, and `jobIds` with new values.
- function `transferPLI`: to transfer an `_amount` number of the `PLI` tokens in the contract to the `_recipient`.
- function `setAuthorization`: to set `authorizedRequesters` and `authorizedWallets`. These mappings serve the purpose of determining whether an address has the authority to invoke the `cancelRequest()` function and whether an address is granted permission to utilize another address's `PLI` tokens for calling the `requestData()` function.
- function `setOracleFee`: to set the fee for updating the data from one oracle. It is possible to set the total fee rate up to any arbitrary amount. We recommend adding reasonable boundaries for the fees.
- function `cancelRequest`: to cancel a Plugin request with `_requestId`, `_payment`, and `_expiration`.
- function `requestData`:to spend the `PLI` tokens from the `_caller` address to build requests to each oracle in the oracles array and update the answers.

In the contract `Aggregator` the role `authorizedRequesters` has authority over the function below.
- function `cancelRequest`: to cancel a Plugin request with `_requestId`, `_payment`, and `_expiration`.
- function `requestData`: to spend the `PLI` tokens from the `_caller` address to build requests to each oracle in the oracles array and update the answers.
Any compromise to the `authorizedRequesters` account may allow the hacker to take advantage of this authority.


Centralization Risks in InternalContract.sol

In the function `requestData()`, any `AuthorizedRequester` address can invoke this function and build requests to each oracle in the oracles array and update the answers by expending a certain amount of `PLI` tokens. However, the `_caller` parameter is a pass-in value, which allows `AuthorizedRequester` addresses to spend another user's `PLI` deposits, posing a security risk.

Logical issue about the `requestData()`

The contract is serving as the underlying entity to interact with the following external implementations/contracts: 
- external contracts: `PluginClient`, `AggregatorInterface`, `SignedSafeMath`, `Ownable`, and `SafeMathPlugin`.
- external functions: `setPluginToken`, `buildPluginRequest`, `request.add`, `sendPluginRequestTo`, `validatePluginCallback`, `pliToken.transfer`, `pliToken.balanceOf`, `cancelPluginRequest`, and `selfdestruct`.

The scope of the audit treats external implementations as black boxes and assumes their functional correctness. However, in the real world, these codes can be compromised and this may lead to lost or stolen assets. The related codes are not in the scope of this audit.

External Dependencies

In the function `requestData()`, according to the following code:
```solidity
      request.add("_fsyms","XDC");
      request.add("_tsyms","USDT");
      request.addInt("times", 10000);
```
, the request is assembled with several additional parameters, we would like the client to provide with us more information about the use of these parameters.

The assembled data to requests

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

Missing Emit Events

This project serves a similar purpose to the `aggregator` contract in `ChainLink`, where data updates are received from oracles located in different nodes. In `ChainLink`, various mechanisms, such as the OCR (Off-Chain Reporting) protocol, are implemented to ensure the accuracy of the data.

According to the OCR protocol, as explained by `ChainLink`:

"The OCR protocol allows nodes to aggregate their observations into a single report off-chain using a secure P2P network. A single node then submits a transaction with the aggregated report to the chain. Each report consists of many nodes' observations and has to be signed by a quorum of nodes. These signatures are verified on-chain."

We would like to inquire whether the `GoPlugIn` project incorporates similar mechanisms to ensure the credibility of the data sources.

Leaderboards

Due Diligence Tools

Resources

KYC Status