Architecture
Raphael follows a modular AMM architecture derived from the battle-proven ve(3,3) protocol family. Each responsibility lives in its own contract, and the contracts compose into the swap, liquidity and incentive systems described across these docs.
Core components
| Component | Responsibility |
|---|---|
| Factory registry | Tracks approved pool factories and pool implementations |
| Basic pool factory | Creates stable and volatile pools |
| Concentrated pool factory | Creates tick-based concentrated-liquidity pools |
| Router | Adds/removes basic liquidity and executes routed swaps |
| Nonfungible position manager | Creates and manages concentrated-liquidity NFTs |
| Quoter | Simulates candidate routes without executing a state-changing swap |
| Gauge factory | Creates staking gauges for eligible pools |
| Gauge | Accounts for staked positions and distributes $RAPH emissions |
| Voter | Records pool votes and coordinates gauges and reward contracts |
| Voting rewards | Accounts for fees and incentives owed to veRAPH voters |
| Minter | Creates and schedules $RAPH emissions |
| Vote escrow | Locks $RAPH and issues veRAPH NFT positions |
| Governor / emergency roles | Executes only the permissions present in the deployed contracts |
Swap path
A client discovers candidate pools, requests quotes, chooses a route, applies a slippage limit and submits execution through the appropriate router.
A route can combine basic and concentrated pools. Multi-hop routing should optimise the final output after accounting for pool fees, price impact and gas, not merely select the pool with the largest TVL. Routing and Quotes covers this in detail.
Liquidity and incentives
- A pool is created by a registered factory.
- Liquidity providers deposit into it.
- If approved, a gauge is created and made eligible for votes.
- veRAPH holders vote for the pool.
- The voter allocates $RAPH emissions to its gauge.
- Gauge accounting distributes $RAPH to eligible staked positions.
- Voting-reward contracts account for fees and incentives.
Immutability and permissions
Do not describe the system as fully immutable without reviewing the Raphael deployment. Factories, gauges, fees, emergency controls or implementations may have narrowly scoped administrative permissions. These should be documented contract by contract; see the verification checklist in Contract Deployments.