pNetwork-logo

pNetwork

pNetwork is an open-source multi-chain routing protocol that enables the movement and interoperability of assets, NFTs and data across more than 15 blockchains. These cross-blockchain functionalities enable, for example, the release of “wrapped” tokens called pTokens that rely on maintaining a 1-to-1 peg in-between the native blockchain and the host blockchain (e.g.

Algorand
Arbitrum
BSC
ETH
Polygon
Telos
Telos
Defi
NFT
Bridge
Crosschain Liquidity
L2
Solidity
Maximum Bounty
$200,000
Live Since
27 December 2021
Last Updated
18 November 2024
  • PoC required

  • KYC required

Rewards

pNetwork provides rewards in USDC, PNT on Algorand, denominated in USD.

Rewards by Threat Level

Smart Contract
Critical
Up to: $200,000
Primacy of Rules
High
Flat: $20,000
Primacy of Rules
Medium
Flat: $5,000
Primacy of Rules
Low
Flat: $1,000
Primacy of Rules
Critical Reward Calculation

Mainnet assets:

Reward amount is 10% of the funds directly affected up to a maximum of:

$200,000
Websites and Applications
Critical
Flat: $50,000
Primacy of Rules
High
Flat: $3,000
Primacy of Rules
Medium
Flat: $1,000
Primacy of Rules

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

All web/app bug reports must come with a PoC in order to be considered for a reward.

Critical vulnerabilities are further capped at 10% of economic damage, with the main consideration being the funds affected in addition to PR and brand considerations, at the discretion of the team. However, there is a minimum of USD 10 000 for Critical bug reports.

The following is a known issue that is considered as out of scope. There is an "unhandled exception" (which is on the list of vulnerabilities) in the ERC777; Namely that the ERC777 tokens received hook combined with a tag for automatic peg-in on sends can fail if the user ABI encodes the other information incorrectly. This will revert but with no reason because there's no way to catch the error to add a message.

pNetwork requires KYC to be done for all bug bounty hunters submitting Critical bug reports and wanting a reward. The information needed is an ID photo together with a selfie. Reports for other severity levels do not require any KYC.

Payouts are handled by the pNetwork team directly and are denominated in USD. However, payouts are done in PNT or USDC, up to the discretion of the team.

Program Overview

pNetwork is an open-source multi-chain routing protocol that enables the movement and interoperability of assets, NFTs and data across more than 15 blockchains. These cross-blockchain functionalities enable, for example, the release of “wrapped” tokens called pTokens that rely on maintaining a 1-to-1 peg in-between the native blockchain and the host blockchain (e.g. Bitcoins wrapped to operate on the Ethereum blockchain).

To know more about pNetwork, visit https://p.network/, try our dApp dapp.ptokens.io join the community at https://twitter.com/pNetworkDeFi and browse the analytic dashboard https://pnetwork.watch/

This bug bounty program is focused on their smart contracts and app and is focused on preventing:

  • Thefts and freezing of principal of any amount
  • Thefts and freezing of unclaimed yield of any amount
  • Theft of governance funds
  • Forging data returned by pNetwork nodes before it gets presented to the user by the dapp (XSS)

KYC required

The submission of KYC information is a requirement for payout processing.

Proof of Concept

Proof of concept is always required for all severities.

Prohibited Activities

Default prohibited activities
  • Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
  • Any testing with pricing oracles or third-party smart contracts
  • Attempting phishing or other social engineering attacks against our employees and/or customers
  • Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
  • Any denial of service attacks that are executed against project assets
  • Automated testing of services that generates significant amounts of traffic
  • Public disclosure of an unpatched vulnerability in an embargoed bounty
  • Any other actions prohibited by the Immunefi Rules

Feasibility Limitations

The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity. Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.

Severity
Min. - Max.
Critical
$50k -$200k
High
$3k -$20k
Medium
$1k -$5k
Low
$1k
Total Assets in Scope
40