[{"id":3759167,"new_policy":"RootstockLabs, previously IOVLabs\n\n\nRootstockLabs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation has helped launch the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, RootstockLabs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nRootstockLabs rewards researchers that submit valid vulnerabilities to improve the RootstockLabs platforms security. \n\n# SLA\nRootstockLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days\n* Time to triage (from report submit) - 7 business days\n* Time to bounty (from triage) - 15 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RootstockLabs with considerable delay, then RootstockLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Do not violate any privacy policy, destroy any data, or interrupt or degrade our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RootstockLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RootstockLabs infrastructure or other users.\n* RootstockLabs development team, employees and all other people paid by RootstockLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RootstockLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n* Reports must include a working Proof of Concept (PoC) that demonstrates the vulnerability under realistic, production-like conditions. PoCs that rely on mocked assumptions or simulated components not present in the actual environment might be rejected.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* DoS attacks that require sending multiple network packets at any layer. We’re interested in DoS that depends on the data and can't be stopped at the network level.\n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RootstockLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\nThank you for helping keep RootstockLabs and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-07-16T13:10:40.029Z"},{"id":3745671,"new_policy":"RootstockLabs, previously IOVLabs\n\n\nRootstockLabs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation has helped launch the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, RootstockLabs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nRootstockLabs rewards researchers that submit valid vulnerabilities to improve the RootstockLabs platforms security. \n\n# SLA\nRootstockLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days\n* Time to triage (from report submit) - 7 business days\n* Time to bounty (from triage) - 15 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RootstockLabs with considerable delay, then RootstockLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Do not violate any privacy policy, destroy any data, or interrupt or degrade our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RootstockLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RootstockLabs infrastructure or other users.\n* RootstockLabs development team, employees and all other people paid by RootstockLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RootstockLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* DoS attacks that require sending multiple network packets at any layer. We’re interested in DoS that depends on the data and can't be stopped at the network level.\n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RootstockLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\nThank you for helping keep RootstockLabs and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-12-03T14:05:52.356Z"},{"id":3722931,"new_policy":"RootstockLabs, previously IOVLabs\n\n\nRootstockLabs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation has helped launch the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, RootstockLabs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nRootstockLabs rewards researchers that submit valid vulnerabilities to improve the RootstockLabs platforms security. \n\n# SLA\nRootstockLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days\n* Time to triage (from report submit) - 7 business days\n* Time to bounty (from triage) - 15 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RootstockLabs with considerable delay, then RootstockLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Do not violate any privacy policy, destroy any data, or interrupt or degrade our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RootstockLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RootstockLabs infrastructure or other users.\n* RootstockLabs development team, employees and all other people paid by RootstockLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RootstockLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RootstockLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep RootstockLabs and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-04-05T18:36:19.365Z"},{"id":3721661,"new_policy":"RootstockLabs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation has helped launch the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, RootstockLabs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nRootstockLabs rewards researchers that submit valid vulnerabilities to improve the RootstockLabs platforms security. \n\n# SLA\nRootstockLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 5 business days\n* Time to triage (from report submit) - 7 business days\n* Time to bounty (from triage) - 15 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RootstockLabs with considerable delay, then RootstockLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Do not violate any privacy policy, destroy any data, or interrupt or degrade our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RootstockLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RootstockLabs infrastructure or other users.\n* RootstockLabs development team, employees and all other people paid by RootstockLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RootstockLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RootstockLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep RootstockLabs and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-27T14:12:24.930Z"},{"id":3683722,"new_policy":"IoV Labs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation has helped launch the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, IoV Labs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nIoVLabs rewards researchers that submit valid vulnerabilities to improve the IoVLabs platforms security. \n\n# SLA\nIoVLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to IoVLabs with considerable delay, then IoVLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Do not violate any privacy policy, destroy any data, or interrupt or degrade our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants IoVLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to IoVLabs infrastructure or other users.\n* IoVLabs development team, employees and all other people paid by IoVLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the IoVLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the IoVLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep IoVLabs and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-02-15T20:17:26.886Z"},{"id":3683000,"new_policy":"IoV Labs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation is best known for creating the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, IoV Labs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nIoVLabs rewards researchers that submit valid vulnerabilities to improve the IoVLabs platforms security. \n\n# SLA\nIoVLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to IoVLabs with considerable delay, then IoVLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants IoVLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to IoVLabs infrastructure or other users.\n* IoVLabs development team, employees and all other people paid by IoVLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the IoVLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the IoVLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep IoVLabs platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-02-03T20:00:30.605Z"},{"id":3682986,"new_policy":"IoV Labs is on a mission to provide the next generation of fintech innovators with the decentralized tools and technology to build a new global economy.\nThe organisation is best known for creating the Rootstock blockchain in 2017 which builds on Bitcoin's unparalleled hashing power, security and decentralization by adding smart contract capabilities, nearly instant payments and higher scalability.  Rootstock now hosts hundreds of DeFi protocols and products built by developers around the world.\nIn 2018, IoV Labs launched the Rootstock Infrastructure Framework (RIF). Built on Rootstock, RIF reduces time to market for business and developers building cutting edge solutions using blockchain technology secured by Bitcoin.\n\nIOVLabs rewards researchers that submit valid vulnerabilities to improve the IOVLabs platforms security. \n\n# SLA\nIoVLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to IOVLabs with considerable delay, then IoVLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants IOVLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to IOVLabs infrastructure or other users.\n* IOVLabs development team, employees and all other people paid by IOVLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the IOVLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the IOVLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep IoVLabs platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-02-03T13:44:33.693Z"},{"id":3631054,"new_policy":"IOVLabs has created this bug bounty program to reward security researchers that dedicate time and effort to improve the IOVLabs platforms. \n\n# SLA\nIOVLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to IOVLabs with considerable delay, then IOVLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants IOVLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to IOVLabs infrastructure or other users.\n* IOVLabs development team, employees and all other people paid by IOVLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the IOVLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the IOVLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep IOVLabs platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-20T20:16:20.193Z"},{"id":3631046,"new_policy":"IOVLabs has created this bug bounty program to reward security researchers that dedicate time and effort to improve the IOVLabs platform. \n\n# SLA\nIOVLabs will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to IOVLabs with considerable delay, then IOVLabs may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants IOVLabs the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to IOVLabs infrastructure or other users.\n* IOVLabs development team, employees and all other people paid by IOVLabs, directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the IOVLabs codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the IOVLabs code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep IOVLabs platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-20T19:40:58.704Z"},{"id":3629121,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n# Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-01-24T16:10:06.615Z"},{"id":3629120,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project: \n  - The private key handling and storage is out of scope.\n  - Malicious ERC20 tokens are out of scope because there is a whitelisting process in place.\n\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-01-24T16:08:45.030Z"},{"id":3629006,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-01-23T15:46:43.186Z"},{"id":3629005,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n* For TokenBridge project the private key handling and storage is out of scope\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-01-23T15:45:43.504Z"},{"id":3611641,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-06-10T19:51:52.140Z"},{"id":3610012,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of RSK.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $10,000  | $5,000 | $2,500    | $1,000 |\n\nVulnerabilities which result in remote code execution will be awarded a bonus, with a total award up to **$20,000**.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-05-22T18:18:53.770Z"},{"id":3610011,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of RSK.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $10,000  | $5,000 | $2,000    | $1,000 |\n\nVulnerabilities which result in remote code execution will be awarded a bonus, with a total award up to **$20,000**.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-05-22T18:18:00.698Z"},{"id":3585898,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of RSK.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $10,000  | $4,000 | $2,000    | $1,000 |\n\nVulnerabilities which result in remote code execution will be awarded a bonus, with a total award up to **$20,000**.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and the filter API including `eth_newFilter`, `eth_blockFilter`, `eth_getLogs`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-08-16T14:26:53.017Z"},{"id":3579340,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of RSK.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $10,000  | $4,000 | $2,000    | $1,000 |\n\nVulnerabilities which result in remote code execution will be awarded a bonus, with a total award up to **$20,000**.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and methods: `eth_newFilter`, `eth_blockFilter`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-06-06T17:01:44.222Z"},{"id":3579339,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of RSK.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $10,000  | $4,000 | $2,000    | $1,000 |\n\nVulnerabilities which result in remote code execution will be awarded a bonus, with a total award up to $20,000.\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and methods: `eth_newFilter`, `eth_blockFilter`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-06-06T16:44:48.171Z"},{"id":3574592,"new_policy":"RSK has created this bug bounty program to reward security researchers that dedicate time and effort to improve the RSK platform. \n\n# SLA\nRSK will make a best effort to meet the following SLAs for hackers participating in our program:\n\n* Time to first response (from report submit) - 2 business days\n* Time to triage (from report submit) - 2 business days\n* Time to bounty (from triage) - 10 business days\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n* Public disclosure of a vulnerability makes it ineligible for a bounty. If the user reports the vulnerability to other security teams (e.g. Ethereum or ETC) but reports to RSK with considerable delay, then RSK may reduce or cancel the bounty.\n\n# Program Rules\n* Please provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n* Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.\n* When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).\n* Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.\n* Social engineering (e.g. phishing, vishing, smishing) is prohibited.\n* Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.\n* The submitter must be the person who has discovered the vulnerability. Vulnerability submission cannot be delegated.\n* The submitter grants RSK the right to use parts or all the submitted report for communicating the vulnerability to the public.\n* Only test on nodes that you own. Avoid testing that could be damaging to RSK infrastructure or other users.\n* RSK development team, employees and all other people paid by RSK , directly or indirectly, are not eligible for rewards.\n* A person who submitted a change in the RSK codebase is not eligible for rewards for vulnerabilities originating or triggered by the submitted change.\n\n# Rewards\nOur rewards are based on severity per CVSS (the Common Vulnerability Scoring Standard). Please note these are general guidelines, and that reward decisions are up to the discretion of RSK.\n\n| Critical (9.0 - 10.0) | High (7.0 - 8.9)  | Medium (4.0 - 6.9) | Low (0.1 - 3.9) |\n|----------|--------|---------|------|\n|  $7,000  | $3,000 | $1,000    | $750 |\n\n# Scope\nOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of work, etc.) and protocol implementation. Classical client security as well as security of cryptographic primitives are also part of the program. Most JSON RPC methods and CSRF attacks against them are in scope.\n\n#Out of scope vulnerabilities\nWhen reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered **out of scope**:\n \n* Findings related to the encryption or access control of the integrated wallet.\n* Attacks requirng physical access or local user level access to a user's device.\n* Previously known vulnerable libraries without a working Proof of Concept.\n* Denial of our service (DoS) not directly related to a flaw in the RSK code or environment.\n* JSON RPC `personal` module and methods: `eth_newFilter`, `eth_blockFilter`\n\nThank you for helping keep RSK's platform and users safe!\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-04-23T15:44:47.763Z"}]