Skip to main content

Audits & security

Audits

(Populate when external audits land. Each entry should include firm, scope, commit hash, link to the report PDF, and a one-line summary of severity outcomes.)

Format for each audit:

Firm Name: Audit scope, <commit hash> Report PDF, Findings summary: N high, N medium, N low, all addressed in commit <resolution-hash>.

Known issues and accepted risks

This section lists acknowledged properties of the protocol that auditors or community reviewers have flagged. Each entry includes the reason the property exists and the mitigation, if any.

Examples of issues that would land here when relevant:

  • Cross-branch redemption reverts on any single-branch failure. Documented in Risks › Cross-branch revert. Mitigated by branch shutdown removing the failing branch from the basket.
  • No fee-on-transfer collateral support. The protocol assumes ERC-20 transfer moves exactly the requested amount. Adding fee-on-transfer collaterals as branches is excluded by deployment policy.
  • Below-MCR troves can be carried for a few blocks during quiet periods. Liquidation incentives normally clear them within a block; in extreme gas spikes, delay is possible. The protocol's exposure during the delay is bounded by the gas-comp reserve.

(Populate as findings come in.)

Bug bounty program

🐛 Bounty channel and rules to be linked when the program goes live.

Expected scope (subject to the program's published rules):

  • In scope: any RAI Dollar contract under packages/contracts/contracts/ in rai-dollar/core2, including singletons (Aggregator, RDToken, FEEToken, RateParControl, MarketOracle, GlobalFeeRouter, etc.) and per-branch contracts deployed on Ethereum mainnet at addresses listed on Deployed addresses.
  • Out of scope: front-end UIs, off-chain infrastructure, theoretical attacks on Chainlink or Balancer themselves, governance disclosures not yet announced, oracle staleness within published thresholds.

Severity guidance (typical for protocols of this kind, exact bounty schedule is set by the program):

SeverityDefinition
CriticalLoss of user funds, RD supply inflation outside the protocol's rules, or permanent freeze of major funds.
HighLoss of protocol revenue, partial freeze, recovery-mode bypass, or controller manipulation beyond stated bounds.
MediumIncorrect accounting that can be unwound; griefing without permanent loss.
LowTheoretical issues that require unrealistic conditions, dust-level accounting drift, missing event emissions.

Responsible disclosure

If you've found a vulnerability:

  1. Do not disclose publicly.
  2. Submit through the bug bounty channel (link TBD) with a clear PoC.
  3. Allow reasonable time for a fix before public disclosure.
  4. The protocol team will coordinate disclosure timing once a fix is deployed.

Where to read code

  • Repo: rai-dollar/core2.
  • Branch reflected by this docs site: redemption_refactor.
  • Audit-targeted commits will be tagged when audits begin.

Where to ask security questions

  • For non-vulnerability security questions, open an issue on rai-dollar/core2.
  • For confirmed vulnerabilities, use the bug bounty channel.

What the protocol does not offer

  • No insurance. There is no protocol-level insurance fund or backstop for SP depositor losses, oracle failures, or smart contract bugs.
  • No upgrade path. Core contracts are immutable. If a critical bug is found, the response is branch shutdown + redirect of activity to a redeployed instance, not a contract upgrade.
  • No admin recovery. No admin key can recover stuck funds, override liquidations, or change parameters on a live branch.

The trade-off is intentional: the protocol is auditable as a fixed artifact, with no surprise upgrades, but the cost is that severe issues require a fresh deploy and user migration.