Bug Bounty Programme
This page pertains to information about the Bug Bounty Programme for Uno Re V2 App launch
Uno Re is building a fully secure decentralized insurance ecosystem to serve institutional and individual Web3 participants. The protocol's insurance platform has two core applications - one the Risk Underwriting - Investment Vaults app and our B2C Insurance Sales dApp - The Cover Portal.
The end goal vision is to become a backend composable risk hedging application that all kinds of users have access to but don’t even need to interact directly with any interface.
Addressing the Past, Building the Future
The Uno Re protocol faced a security breach, which was a direct result of centralization risks within our system. We took this setback seriously and re-engineered our core functionalities with a renewed commitment to decentralization. After a thorough evaluation by our developers and scrutiny by numerous auditors, we understand the criticality of continued vigilance. Hence, we are revitalizing our community-driven bug bounty program to engage users in identifying possible vulnerabilities in our dApp ecosystem.
Bug Bounty Program Phasewise launch Structure
To effectively manage the bug reports and fixes and coordinate the tight launch deadlines, we will be splitting the Bug Bounty Programme into 2 active sets:
Governance dApp and Contracts - Sepolia + Goreli + BSC testnet apps
Core dApp and Contracts - Sepolia + Goreli + BSC testnet apps
After this, there will be an actively running bug bounty (0days) program which will be available for the main net version of the above applications as well
Governance dApp and Contracts - ETH Mainnet app
Core dApp and Contracts - ETH + BSC Mainnet apps
This page pertains to information about the Bug Bounty Programme for the Uno Re V2 Dao app relaunch. Like last time, we’ve decided to host a combined 200,000 USD Bug Bounty program for our V2 dApp relaunch.
For Whitehats: It is highly recommended that you review the details of this program in full. Although many Bug Bounty programs have standard terms and conditions, each also has their own unique details that are critical to your success. Please note that this is not a typical community audit contest where the entire pool is distributed based on reports within a fixed timeframe.
PROGRAM SCOPE [ACTIVE SET]:
Governance dApp and Contracts
Contract Code: https://github.com/Uno-Re/unore-uno-dao/tree/master/contracts
Deployed Contract links:
UNO DAO Contracts: https://github.com/Uno-Re/unore-uno-dao/tree/master/deployments/mainnet
Frontend dApp: https://app.unore.io/governance/
Core dApp and Contracts
Contract Code: https://github.com/Uno-Re/SSIP-SSRP-contracts/tree/main/contracts
Deployed Contract links:
UNO Core Contracts: https://github.com/Uno-Re/SSIP-SSRP-contracts/tree/main/deployments/goerli
Frontend dApp: https://staging-app.unore.io/buy-cover
Api Endpoints
Peripher Apps and notes:
Gelato - This call execNotifyReward function of NotifyRewardProxy, to update reward amount in VeUnoYieldDistributor. a. execNotifyReward call notifyRewardAmount function VeUnoYieldDistributor.
RewardNotifier: Is a mapping for whitelisted address to call notifyRewardAmount function. a. Notify yield distributor for new epoch and transfer emittedToken into distributor for yield.
b. This will be true for NotifyRewardProxy contract address, so that NotifyRewardProxy can notifyRewardAmount function.
Gnosis Safe - This is used to create multisig address, multisig address will be manage by multiple owner and have minimum threshold approval for execution of transaction. a. Multisig account created using gnosis Safe: I. ClaimsDao II. Governance III. Multisig IV. Guardian Council V. Claim accessor VI. Operator
UMA - Protocol for managing request for policy id to claim and verification of disputer in policy id.
This accept bond for asserting request and dispute for policy and there is lock time for policy id to settle, before that policy id can not be settle, at the time of settlement of policy bond will transfer back to asserter or disputer on the basis of vote on dispute, if there is no dispute all bond transfer back to asserter and policy id assume to be true. I. When user request for claim policy, this request goes to UMA Optimistic Oracle v3 . II. Assertion id created for this request in OOV3, disputer will request to reject this assertion . III. UMA DVM will vote on this dispute. IV. If disputer is truthful bond of asserter and disputer will transfer to disputer else to asserter with the deduction of fee which goes to UMA.
Key Multisig accounts and EOAs:
Owner of mockOraclePriceFeed: 0xE80158dDFE013de2BDEc8eAACFF4068173b6b37a(EOA), to set asset price
MULTISIGWALLET=0xedFFe0a06914c9D6083B4B099e5b935E9E84c9a5, used in
exchangeAgent=0x97a70De3D00C9D377eaa539d54A3598bEB623A1F , to manage contract, set and update whitelist address
capitalAgent=0x115Edf96a86b378047058969bcAdf904149752e2, provides admin role, to set whitelist pool and set operator
premiumPool=0x7ff90C1C5e7cB2535e7e7992491dd1Be6c5325A3, provides admin role
SalesPolicyFactory=0x863d204b9F95eD3e83A1a9c5445a94697EeCa983, owner to set salesPolicy data and create new salesPolicy
SSIP and SSRP pools, provides admin role
OPERATOR=0xedFFe0a06914c9D6083B4B099e5b935E9E84c9a5
capitalAgent to set SCR, MLR and MCR
GOVERNANCE=0xedFFe0a06914c9D6083B4B099e5b935E9E84c9a5
premiumPool, to premium
escalationManager, to toggle disputer, asserter and set assertion data
CLAIM_ACCESSOR=0xedFFe0a06914c9D6083B4B099e5b935E9E84c9a5
SSRP pool to claim policy on behalf of user .
GUARDIAN_COUNCIL=0xedFFe0a06914c9D6083B4B099e5b935E9E84c9a5
PayoutRequest, to set capitalAgent, claimsDao and escalationManager address and update pause, assertionLiveness and uma failed.
CLAIMS_DAO=0xedFFe0a06914c9D6083B4B099e5b935E9E84c9a5
PayoutRequest to claim policy in behalf of user
Documentation for Governance dApp -
Documentation for Core dApp -
Reward Payouts and Terms:
Smart Contract Bugs:
Rewards are distributed according to the impact of the vulnerability based on the https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-2/. Some additional classification criteria and terms have been mentioned below as well. We have adopted ImmuneFi's vulnerability severity classification system, with slight modifications, as the foundation for our bug bounty campaign. Acknowledgment is due to ImmuneFi for their development of a comprehensive and practical framework.
Payout Table:
Critical Issues - Payouts will be based on Risk Ratio calculated as Funds at Risk / ( Uno Re TVL). For testnet Bug Bounty Programme program there will be an assumption of TVL upto 10M USD. If the risk ratio is at or below 0.5, the payout is calculated linearly between 0$ and 25K. If the risk ratio is above 0.5, the payout is calculated linearly between USD $25K and USD $75K; with a maximum cap of $100K. In the event that the funds at risk is greater than the Uno Re TVL, the maximum reward will not exceed USD $75K. PoC is required.
High Issues - In the range between 1000 to 5000 USD. PoC is required.
Medium Issues - In the range between 500 to 1250 USD. PoC is required.
All Critical and High issues require a PoC to be eligible for a reward. A suggestion for a fix is preferred but not compulsory for Low and Medium Smart Contract bug reports. Explanations and statements are not accepted as PoC and code is required.
Critical smart contract vulnerabilities are capped at 10% of economic damage, primarily taking into consideration funds at risk, but also PR and branding aspects, at the discretion of the team. However, there is a minimum reward of USD 20,000 per issue.
Payouts are handled by the Uno Re DAO team directly and are denominated in USD. However, payouts are done in USDT or USDC.
Enhanced Focus - Centralization Risks under our new Bug Bounty Programme:
Learning from our past mistakes we want to emphasise on attention to addressing centralization risk within the protocol and hence we are expanding the scope of the contract bug bounty program to include reporting of centralization risks. This addition aims to address potential vulnerabilities associated with centralization that may compromise the integrity and security of the contract.
We have limited the accessibility of admin/centralized operators to be able to tamper/access user funds in any scenario including, emergency upgrades. We have further restricted usage of privileged functionalities unless certain minimum criteria are maintained for the said privileged roles for ex: minimum signer limit to execute functionality like contract upgrades, etc. We encourage users to report any additional security enhancements, missed areas which allow too much centralization within network operators.
Payouts are determined based on how much damage the underlying compromise can have on the protocol participants. Reporters are encouraged to tag the issues into categories such as Loss off user funds, DOS, permalock, user griefing, etc. to accurately describe the severity. The payouts for the centralization reports are solely up to the discretion of the Uno Re DAO team and are processed accordingly at a cap of 25% of smart contract bug bounty payout table.
Exclusions for Smart Contract bugs:
Attacks that the reporter has already exploited themselves, leading to damage
Attacks that rely on social engineering
Attacks requiring access to leaked keys/credentials
Basic economic governance attacks (e.g. 51% attack)
Signer account compromise in key multi sig (threshold of 50%)
Reward Notifier account compromise (acknowledged as it's maintained by multisig)
All vulnerabilities marked in the issues section of the github repo is excluded from Bug Bounty Programme.
All acknowledged issues from Audit reports is excluded from Bug Bounty Programme.
Enhanced Focus - Frontend dApp issues or Integration Exploits with Periphery Apps:
The Bug Bounty Programme will be also accepting FE exploits that are related to contract application scope and the severity will be determined based on the classification under the Website and Apps section under https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-2/.
All 3rd Party integrations are also covered under the scope of this bounty program.
We courage users to find issues that might be lead to potential exploitation of users via a plugin compromise or insecure implementation of a third party integration.
Payouts are determined based on how much damage the underlying compromise can have on the protocol participants. Reporters are encouraged to tag the issues into categories such as Loss off user funds, DOS, permalock, user griefing, etc. to accurately describe the severity. The payouts for the centralization reports are solely up to the discretion of the Uno Re DAO team and are processed accordingly at a cap of 25% of smart contract bug bounty payout table.
Exclusions for Frontend Bugs:
Click jacking / UI redressing .
Publicly exposed API.
HTTPS/SSL/TLS Related Issues.
Session not invalidated after logout.
Missing security-related HTTP headers which do not lead directly to a vulnerability.
SSRF vulnerability that cannot obtain the relevant server information of the Intranet, but simple accessed dns log without any impact.
HTML injection and cannot execute JavaScript code .
Attacks only affecting obsolete browsers or operating systems .
Social engineering, phishing, physical, or other fraud activities .
Vulnerabilities only exploitable on out-of-date browsers or platforms.
Any activity (like DoS/DDoS) that disrupts our services.
Vulnerabilities that are already known (e.g. discovered by an internal team).
Audit Discoveries and Known Issues:
Bug reports covering previously discovered bugs are not eligible for any reward through the bug bounty program. If a bug report covers a known issue, it may be rejected together with proof of the issue being known before escalation of the bug report via our private internal discord channel which records form entries with timestamps.
How to report these Bugs/Vulnerabilities to us?
Users can submit the bug bounty reports using the form Here.
To ensure utmost transparency and fairness, we have created a channel on our discord server dedicated to the bug bounty participants. Users who are interested in testing can also request faucets from the discord channel. Join the channel using the link Here.
Once you create a submission there is a trigger alert created on public chat, which will be regularly updated by our development team based on the status of the issue in our triage cycle. Below is a quick overview of the reporting process for the same.
Reporting Process:
The following symbols represent the process of how the team will handle the reported bugs found in the program:
Bug Accepted - ⚪
Bug Rejected - 🔴
Bug Processing - 🔵
Bug Fixed - ✔️
The severity of the bug will further be represented as the following:
As and when bugs are being reported, the Developer and Security teams of Uno Re will promptly take action to fix the vulnerability.
We appreciate all the love and support we have received since the beginning. This is the start of an epic journey and we can’t wait to re-define the crypto ecosystem and take it to new heights!
Last updated
