Security
Security is a property of the complete deployed system: source code, configuration, deployment process, keys, permissions, frontend, RPCs and user behaviour. No single audit, badge or checklist substitutes for the whole.
Raphael audit status
Raphael is derived from a battle-proven ve(3,3) code lineage, but an upstream report is not a Raphael audit. No Raphael-specific audit report is listed here unless it identifies the exact Raphael repository commit, configuration and deployed bytecode reviewed.
Upstream security history
The inherited contract architecture is maintained under the Velodrome V2 security programme, and its published reviews are useful evidence for unchanged inherited components, subject to exact code and scope comparison.
Primary reviews for the inherited protocol lineage:
| Component | Reviewer | Review date | Report |
|---|---|---|---|
| Velodrome V1 protocol | Code4rena | 23 to 30 May 2022 | Findings and analysis report |
| Velodrome V2 core protocol | Spearbit | Completed 16 June 2023, published 17 July 2023 | Security review PDF |
| Slipstream concentrated liquidity | Spearbit | Completed 5 December 2023, published 22 January 2024 | Security review PDF |
Further reviews cover later or narrower upstream components. They apply only if Raphael uses the reviewed component and matches the report's audited code:
| Component | Reviewer | Report date | Report |
|---|---|---|---|
| GovNFT governance contracts | Cantina | 8 April 2024 | Cantina security report |
| Superchain protocol changes | ChainSecurity | 5 November 2024 | Assessment PDF |
| Superchain Slipstream | ChainSecurity | 13 November 2024 | Assessment PDF |
| Epoch Governor | ChainSecurity | 13 January 2025 | Assessment PDF |
| Sink Gauge v2 | ChainSecurity | 14 February 2025 | Assessment PDF |
Official upstream references:
The Velodrome bounty is an upstream programme. It does not cover Raphael unless Raphael is explicitly added to its scope.
Audit scope
Upstream reports do not by themselves audit:
- Raphael-specific changes;
- Robinhood Chain deployment parameters;
- contract addresses or proxies;
- ownership and multisig configuration;
- the Raphael interface;
- third-party tokens, pools, gauges or strategies;
- changes made after the audited commit.
Before relying on an upstream report, compare Raphael's contracts against the exact commit and files listed in that report. Record every difference and obtain an independent review of material changes.
Verify before interacting
- confirm the Raphael domain;
- confirm the chain ID;
- compare the contract with the deployment registry;
- inspect whether the explorer shows verified source;
- review proxy implementation and owner roles;
- simulate the transaction;
- review token approvals and NFT operators.
Administrative controls
A transparent deployment record should identify every role that can:
- register a factory;
- change a fee;
- create, kill or revive a gauge;
- change reward implementations;
- mint emissions;
- pause or upgrade a contract;
- move treasury funds;
- alter a strategy.
Incident response
If an issue is suspected:
- stop initiating new interactions with the affected contract;
- do not follow unsolicited recovery links;
- revoke relevant approvals only through a trusted tool;
- preserve transaction hashes and signed-message details;
- consult Raphael's official incident channel;
- distinguish confirmed facts from speculation.
A failed transaction usually does not move tokens, but it still consumes gas. A successful malicious approval may remain dangerous until revoked.